(12) United States Patent
`(10) Patent N0.:
`US 6,701,437 B1
`
`Hoke et al.
`(45) Date of Patent:
`Mar. 2, 2004
`
`U8006701437B1
`
`(54) METHOD AND APPARATUS FOR
`PROCESSING COMMUNICATIONS IN A
`VIRTUAL PRIVATE NETWORK
`
`(75)
`
`Inventors: Mark R. Hoke, San Jose, CA (US);
`Leslie J- Arrow, Mountain View, CA
`(US)
`
`_
`.
`(73) Ass1gnee: VPNet Technologles, Inc., San Jose,
`CA (US)
`1sc a1mer, t e term 0 t is
`u ect to an
`yd'
`1
`‘
`h
`f h'
`s bj
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`ot1ce:
`N ‘
`
`*
`
`(21) Appl. No.: 09/188,867
`
`(22) Filed:
`
`NOV. 9, 1998
`
`Related U-S- Application Data
`
`(63)
`
`Continuation—in—part of application No. 09/062,507, filed on
`Apr. 17, 1998, now Pat. No. 6,226,751.
`Int. Cl.7 .................................................. H04L 9/00
`(51)
`(52) US. Cl.
`........................ 713/201; 709/245; 709/249
`(58) Field Of Search ................................. 713/201, 200,
`713/162, 153, 154; 370/351; 709/220, 227,
`228, 230, 232, 238, 245, 249
`
`(56)
`
`References CitEd
`U.S. PATENT DOCUMENTS
`*
`
`5,835,726 A
`5,950,195 A *
`670799020 A :
`671547839 A
`6,173,399 B1 *
`6,175,917 B1 *
`6,182,226 B1 *
`6,226,751 B1 *
`
`............... 709/229
`11/1998 Shwed et a1.
`
`9/1999 Stockwell et a1.
`...... 707/4
`6/2000 L1“ ~~~~~~~~~~~~~~~~~~
`713/201
`11/2000 Afrow et al‘ "
`713/154
`1/2001 Gllbrech ...........
`713/153
`1/2001 Arrow et a1.
`..
`...... 713/1
`1/2001 Reid et al.
`.....
`713/201
`5/2001 Arrow et a1.
`............... 713/201
`
`
`
`6,353,614 B1 *
`
`3/2002 Borella et a1.
`
`.............. 370/389
`
`OTHER PUBLICATIONS
`Ferguson et al, “What is a VPN?”, Apr. 1998, Revision 1, p.
`1_22.*
`Microsoft Press Computer Dictionary, 1997, Third Edition,
`p. 86, 498*
`“Ravlin 4, Wireline Performance Encryption Speeds of 4
`MBPS” 1997, RedCreek Communications, Inc., p. 1—2.*
`“Microsoft Press Computer Dictionary” Microsoft Press, 3’“
`Edition, p. 348*
`“Virtual Private Networks Resource Guide” 1997, Ascend
`Communications, Inc., p. 1—60.*
`Airamo, “Virtual Private Networks” Nov. 28, 1997, Depart-
`ment of Computer Science Helsinki University of Technol-
`ogy, p. 1—9.*
`
`* cited by examiner
`
`Primary Examiner—Ayaz Sheikh
`Assistant Examiner—Christopher Revak
`(74) Attorney, Agent, or Firm Park, Vaughan & Fleming
`LLP
`
`ABSTRACT
`(57)
`One embodiment of the present invention provides a com-
`puter system for processing communications in a virtual
`private network. The computer system operates in a selec-
`tive mode, in which only communications transiting the
`virtual private network are processed according to specified
`virtual private network parameters, .such as. encryption,
`compress1on and authentication algorithms. Virtual private
`network communications passing between a public network
`and a private network are thus received and processed
`according to the algorithms, while other communications
`bypass the computer system. Multiple private networks may
`be served b
`a sin le COIIl uter svstem
`g
`p
`~
`
`y
`
`‘
`
`33 Claims, 8 Drawing Sheets
`
`500
`
`VFN UNIT ENCAPSULATES AND
`FORWARDS YRAFFIC
`502
`
`
`l R
`
`DUTER RECEIVES TRAFFIC, IDENTIFIES
`NEXT RECIPIENT
`504
`
`
`
`
`
`
`TRAFFIC DELIVERED To VPN UNIT
`
`506
`
`VPN UNIT PROCESSES TRAFFIC
`
`so:
`
`VPN UNIT ASSIGNS CLIENT LOCAL
`
`ADDRESS FROM PooL AND SENDS
`TRAFFIC TO ENDSTATION
`51D
`
`t
`ENDSTATIDN RECEIVES ORIGINAL
`TRAFFIC AND sENDS RESPONSE
`512
`
`
`J,
`ROUTER RECEIVES TRAFFIC TO
`FORWARD To NEXT RECIPIENT
`514
`___i___
`RETURN TRAFFIC FORWARDED To VPN
`UNIT51S
`VFN UNIT PROCESSES RETURN TRAFFIC
`518
`
`
`
`Petitioner RPX Corporation - Ex. 1012, p. 1
`
`Petitioner RPX Corporation - Ex. 1012, p. 1
`
`

`

`US. Patent
`
`hdar.2,2004
`
`Sheet170f8
`
`US 6,701,437 B1
`
`zm>
`
`:2:
`
`may
`
`
`
`_Emhm>w_OZF<MMLOFill].
`
`zm>
`
`hzm5m0<z<5
`
`ZOCKHw
`
`omr
`
`_Suhw>w
`F02F<¢wmoh
`
`zm>
`
`t2:
`
`ourz<4
`
`nhr
`
`Nhrrnr
`
`ourz<4
`
`KNHDOK
`
`VNr
`
`z<4
`
`Azoz<mmv
`
`cur
`
`0.".
`
`ourz<4
`
`Muhnom
`
`#nr
`
`meECMZuEJmDm
`
`oer
`
`awhDOm
`
`err
`
`whOEwm
`
`kzmjo
`
`omr
`
`Zm>
`
`t2:
`
`mmr
`
`02F<Mwm0
`
`Suhw>m
`
`WhOEmm
`
`Hzmfio
`
`owr
`
`zm>
`
`t2:
`
`mfir
`
`Emhm>w
`
`OZEKMmmO
`.Iill.
`
`zm>
`
`t2:
`
`mrr
`
`
`
`_Suhw>w_025<2mm0Fl.lu||nI_
`
`“0:.
`
`z<4
`
`OFF
`
`Petitioner RPX Corporation - Ex. 1012, p. 2
`
`Petitioner RPX Corporation - Ex. 1012, p. 2
`
`
`
`
`
`
`
`
`

`

`US. Patent
`
`4
`
`mS
`
`1076,SU
`
`1BM
`
`4,N0.“.
`
`m>DOmmmo<m1m.Tlomm
`|I|il|leEN|LmEcumz<E
`
`
`
`<._.<QFmrmwvamm05
`
`
`
`T|ilovmiv—AlN8|v_
`
`
`
`8wmmEN0mmMfizz?M<._.<n_
`
`55m.3ermNFD>m33>0mm
`
`
`
`20.22.»memomDOm
`
`wFNENEN
`
`
`
`20.22:memomDOm
`
`Petitioner RPX Corporation - Ex. 1012, p. 3
`
`Petitioner RPX Corporation - Ex. 1012, p. 3
`
`

`

`US. Patent
`
`Mar. 2, 2004
`
`Sheet 3 0f 8
`
`US 6,701,437 B1
`
`
`ORIGINATING ENDSTATION
`TRANSMITS PACKET
`300
`
`
`
`
`
`
`
`PASS PACKET AS
`
`IS PACKET PART OF VPN
`
`ORDINARY INTERNET
`
`TRAFFIC?
`TRAFFIC
`
`
`310
`320
`
`
`
`
`
`
`
`RECEIVE DATA PACKET AT VPN
`UNIT
`330
`
`
`
`
`
`
`COMPRESS, ENCRYPT AND
`AUTHENTICATE PACKET; APPLY
`
`POLICY RULES, FILTERING AND
`
`NETWORK ADDRESS
`
`TRANSLATION AS NECESSARY
`340
`
`
`
`
`ADD HEADER FOR TUNNEL MODE
`350
`
`
`
`
`
`FORWARD PACKET TO
`DESTINATION ADDRESS OVER
`
`THE INTERNET
`360
`
`
`
`FIG. 3
`
`Petitioner RPX Corporation - Ex. 1012, p. 4
`
`Petitioner RPX Corporation - Ex. 1012, p. 4
`
`

`

`US. Patent
`
`Mar. 2, 2004
`
`Sheet 4 0f 8
`
`US 6,701,437 B1
`
` RECEIVE PACKET FROM
`
`INTERNET
`
`
`400
`
`
`
`
`
`
`TREAT LIKE
`
`NORMAL INCOMING
`
` THE PACKET VPN TRAFFIC?
`INTERNET DATA
`
`TRAFFIC
`420
`
`
`
` REMOVE SOURCE AND
`
` DECOMPRESS, DECRYPT AND
`
` VPN UNIT RECEIVES THE PACKET
`
`
`430
`
`DESTINATION VPN UNIT
`
`ADDRESSES
`
`440
`
`AUTHENTICATE; APPLY POLICY
`
`RULES, ACCESS CONTROL RULES
`
`AND NETWORK ADDRESS
`
`TRANSLATION AS NECESSARY
`
`450
`
` DELIVER RECONSTRUCTED
`
`PACKET TO DESTINATION
`ENDSTATION
`460
`
`FIG. 4
`
`Petitioner RPX Corporation - Ex. 1012, p. 5
`
`Petitioner RPX Corporation - Ex. 1012, p. 5
`
`

`

`US. Patent
`
`Mar. 2, 2004
`
`Sheet 5 0f 8
`
`US 6,701,437 B1
`
`CLIENT INITIATES TRAFFIC
`500
`
`VPN UNIT ENCAPSULATES AND
`FORWARDS TRAFFIC
`502
`
`
`
`ROUTER RECEIVES TRAFFIC, IDENTIFIES
`NEXT RECIPIENT
`504
`
`TRAFFIC DELIVERED TO VPN UNIT
`506
`
`VPN UNIT PROCESSES TRAFFIC
`508
`
`VPN UNIT ASSIGNS CLIENT LOCAL
`ADDRESS FROM POOL AND SENDS
`TRAFFIC TO ENDSTATION
`510
`
`ENDSTATION RECEIVES ORIGINAL
`TRAFFIC AND SENDS RESPONSE
`512
`
`
`
`ROUTER RECEIVES TRAFFIC TO
`FORWARD TO NEXT RECIPIENT
`514
`
`RETURN TRAFFIC FORWARDED TO VPN
`UNIT
`516
`
`VPN UNIT PROCESSES RETURN TRAFFIC
`518
`
`FIG. 5
`
`Petitioner RPX Corporation - Ex. 1012, p. 6
`
`Petitioner RPX Corporation - Ex. 1012, p. 6
`
`

`

`US. Patent
`
`Mar. 2, 2004
`
`Sheet 6 0f 8
`
`US 6,701,437 B1
`
`VPN UNIT
`
`115 \
`
`BATTERY
`613
`
`N ETWO RK
`1 00
`
`POINTER MEMORY
`
`N ETWO RK
`
`COMMUNICATION
`PORT
`614
`
`PROCESSOR
`600
`
`RAM
`602
`
`BUS
`601
`
`604
`
`PACKET
`PROCESSING
`MODULE
`618
`
`STORAGE
`
`MEMORY
`
`STORAGE
`MEMORY
`608
`
`LOCAL
`COMMUNICATION
`
`PORT
`616
`
`LOCAL CONSOLE
`
`FIG. 6
`
`Petitioner RPX Corporation - Ex. 1012, p. 7
`
`Petitioner RPX Corporation - Ex. 1012, p. 7
`
`

`

`US. Patent
`
`Mar. 2, 2004
`
`Sheet 7 0f 8
`
`US 6,701,437 B1
`
`START
`700
`
`CREATE VPN UNIT OBJECTS
`702
`
`CREATE AND DEFINE GROUPS
`FOR EACH VPN UNIT
`704
`
`
`
`DEFINE VPN REMOTE CLIENTS
`706
`
`CREATE VPN OBJECT
`708
`
`DEFINE VPN PARAMETERS
`- AUTHENTICATION
`- ENCRYPTION
`- COMPRESSION
`- VPN PACKET FORMAT
`710
`
`ASSEMBLE GROUPS AND
`REMOTE CLIENTS INTO VPN
`712
`
`DEFINE ACCESS CONTROL
`RULES
`714
`
`
`
`DEFINE ADDRESS
`TRANSLATION RULES
`716
`
`END
`718
`
`FIG. 7
`
`Petitioner RPX Corporation - Ex. 1012, p. 8
`
`Petitioner RPX Corporation - Ex. 1012, p. 8
`
`

`

`US. Patent
`
`Mar. 2, 2004
`
`Sheet 8 0f 8
`
`US 6,701,437 B1
`
`START
`800
`
`VPN UNIT RECEIVES
`CONFIGURATION REQUEST
`802
`
`IDENTIFY VPN TO BE CONFIGURED
`804
`
`806
`
`RECEIVE VPN OPERATING
`PARAMETERS
`
`LOCAL VPN MEMBERS IDENTIFIED
`TO VPN UNIT
`808
`
`REMOTE VPN MEMBERS
`IDENTIFIED TO VPN UNIT
`
`
`
`810
`
`
`
`
`VPN CONFIGURATION DATA IS
`APPLIED AND STORED
`812
`
`VPN UNIT ACKNOWLEDGES
`CONFIGURATION REQUEST
`814
`
`END
`816
`
`FIG. 8
`
`Petitioner RPX Corporation - Ex. 1012, p. 9
`
`Petitioner RPX Corporation - Ex. 1012, p. 9
`
`

`

`US 6,701,437 B1
`
`1
`METHOD AND APPARATUS FOR
`PROCESSING COMMUNICATIONS IN A
`VIRTUAL PRIVATE NETWORK
`
`RELATED APPLICATIONS
`
`This application is a continuation-in-part of US. Pat. No.
`6,226,751 (Ser. No. 09/062,507, filed Apr. 17, 1998) and is
`related to US. Pat. No. 6,079,020 (Ser. No. 09/013,743, filed
`Jan. 27, 1998).
`
`FIELD OF THE INVENTION
`
`The present invention relates to the field of data commu-
`nications. More specifically, the present invention relates to
`a device for processing communications and a method of
`configuring such a device to selectively encrypt communi-
`cations depending upon whether they are being passed
`between members of a virtual private network.
`
`BACKGROUND
`
`Organizations rely heavily upon their ability to commu-
`nicate data electronically between their members,
`representatives, employees, etc. Such communications typi-
`cally include electronic mail and some form of file sharing
`or file transfer. In a centralized, single site organization,
`these communications are most commonly facilitated by a
`local area network (LAN) installed and/or operated by the
`organization.
`Preventing unauthorized access to data traversing an
`enterprise’s single site LAN is relatively straightforward. As
`long as intelligent network management and adequate physi-
`cal security are maintained, unauthorized access to the data
`passing across the LAN can be prevented. It is when the
`enterprise spans multiple sites that external security threats
`become a considerable problem.
`For distributed enterprises wishing to communicate data
`electronically, several options exist but each has associated
`disadvantages. One option is to interconnect the various
`offices or sites with dedicated, or private, communication
`connections, often referred to as leased lines. This is a
`traditional method used by organizations to implement a
`wide area network (WAN). The disadvantages of imple-
`menting an enterprise-owned and controlled WAN are obvi-
`ous:
`they are expensive, cumbersome and frequently
`underutilized if configured to handle the peak capacity
`requirements of the enterprise. The obvious advantage is that
`the lines are dedicated for use by the enterprise and are
`therefore reasonably secure from eavesdropping or tamper-
`ing by other parties.
`One alternative to using dedicated communication lines is
`to exchange data communications over the emerging public
`network space. For example, in recent years the Internet has
`evolved from a tool primarily used by scientists and aca-
`demics into an efficient mechanism for global communica-
`tions. The Internet provides electronic communication paths
`between millions of computers by interconnecting the vari-
`ous networks upon which those computers reside. It has
`become commonplace, even routine,
`for enterprises
`(including those in non-technical fields) to provide Internet
`access to at least some portion of the computers within the
`enterprises. For many organizations, Internet access facili-
`tates communications with customers and potential business
`partners and promotes communications between geographi-
`cally distributed members of the organization as well.
`Distributed enterprises have discovered that the Internet is
`a convenient mechanism for enabling electronic communi-
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`cations between their geographically-separated members.
`For example, even remote sites within an enterprise can
`connect to the Internet through Internet Service Providers
`(ISP). Once they have access to the Internet, the various
`members of the enterprise can communicate among the
`enterprise’s distributed sites and with other Internet sites as
`well. A significant disadvantage of using this form of intra-
`enterprise communications is the general lack of security
`afforded communications traversing public networks such as
`the Internet. The route by which a data communication
`travels from one point on the Internet to another point can
`vary on a per packet basis, and is therefore essentially
`indeterminate. Furthermore, the data protocols for transmit-
`ting information over the constituent networks of the Inter-
`net are widely known, thus leaving electronic communica-
`tions susceptible to interception and eavesdropping,
`the
`danger of which increases as packets are replicated at most
`intermediate hops. Of potentially greater concern is the fact
`that communications can be modified in transit or even
`
`initiated by or routed to an impostor. With these disconcert-
`ing risks, most enterprises are unwilling to subject their
`proprietary and confidential communications to the expo-
`sure of the public network space. For many organizations,
`therefore, it is common to not only have Internet access
`available at each site, but also to maintain existing dedicated
`communications paths for
`internal enterprise
`communications, with all of the attendant disadvantages
`described above.
`
`To address the need for means of passing secure
`communications, “virtual private networks” (VPNs) have
`been developed. A VPN allows an organization to commu-
`nicate securely across an underlying public network, such as
`the Internet, even with remote sites. Virtual private networks
`typically include one or more virtual private network units,
`sometimes known as VPN service units or VSUs. VPN
`
`service units translate or exchange data packets between the
`public network and the organization’s private WAN or LAN.
`Virtual private network units may reside in a number of
`locations, such as within an ISP or telephone company
`network or on the WAN or LAN side of a routing apparatus
`that connects the enterprise’s network to the Internet. Thus,
`VPN units in known forms of virtual private networks
`generally receive and process all data traffic passed between
`an enterprise site (whether local or remote) and the public
`network. Within one enterprise network, a VSU may serve
`multiple network segments.
`To ensure secure data communications between members
`
`of a single VPN, which may comprise one or more VPN
`groups, a VPN unit operates according to a number of
`parameters. The parameters include various compression,
`encryption, decryption and authentication algorithms, as
`well as parameters concerning security associations and
`access control. Parameters in effect for one VPN may differ
`from those used in another VPN, and may also vary between
`different groups within each VPN.
`As described above, known VPN units typically form part
`of the data path connecting an enterprise’s private LAN to
`the public network over which secure data communications
`are to be passed. This mode of operation presents at least two
`problems, however. First, because it forms part of the path
`along which all inter-network traffic travels, such a VPN unit
`constitutes a single point of failure. In other words, if a VPN
`unit fails all communications between the private and public
`networks connected to the unit are disrupted, not just the
`VPN traffic. As a second consequence of being part of the
`path for all data communications, those communications
`that need not be secured are still received and processed by
`
`Petitioner RPX Corporation - Ex. 1012, p. 10
`
`Petitioner RPX Corporation - Ex. 1012, p. 10
`
`

`

`US 6,701,437 B1
`
`3
`the VPN unit, even though they are not VPN traffic.
`Therefore, current VPN unit configurations cannot help
`delaying all data communications, including those that are
`not being passed between members of a VPN.
`An additional disadvantage to the current method of
`configuring VPNs and VPN units is that a VPN unit cannot
`be “hot-swapped.” In other words, an installed VPN unit
`cannot be replaced without disrupting all data communica-
`tions between the private and public networks. Further, each
`individual VPN unit
`is presently capable of processing
`communications for only a single private network that is
`connected to a public network through the VPN unit. A
`separate VPN unit is thus generally required for each private
`network.
`
`There is, therefore, a need in the art for a VPN unit that
`can be configured to operate as part of a virtual private
`network without receiving and processing all data commu-
`nications passing between the interconnected public and
`private networks. There also eXist requirements for a VPN
`unit that can be replaced without disrupting all data com-
`munications and a VPN unit capable of serving multiple
`private networks. Methods of operating VPN units such as
`these, and methods of operating a VPN comprising such
`VPN units are also needed.
`
`SUMMARY
`
`The present invention provides a virtual private network
`(VPN) unit for selectively processing secure communica-
`tions for members of a virtual private network. One embodi-
`ment of the present invention is used in a VPN operating
`over a public data network connected to an organization’s
`private network (e.g., a LAN or WAN). The organization’s
`private network includes one or more endstations that are
`members of the VPN. In this first embodiment, a VPN unit
`serving the VPN member endstations contains a processor,
`storage memories, and a communication port. A method of
`configuring the VPN unit is also provided, whereby VPN
`communications (e.g., communications requiring secure
`transmission between members of a VPN) are processed by
`the VPN unit but other communications bypass it.
`The VPN unit is linked by a communication port to an
`interconnection between the public network and the private
`network. Data communications sent from the private net-
`work are received and processed by the VPN unit if they are
`to be secured for transmission across the VPN (i.e., they
`constitute VPN traffic). Data communications sent from the
`private network bypass the VPN unit, however, and pass
`directly to the public network if they are not VPN traffic.
`Conversely, communications directed to the private network
`from the public network are delivered to the VPN unit if they
`constitute VPN traffic but otherwise pass directly to the
`private network.
`To enable this selective mode of operation in a present
`embodiment of the invention, the VPN unit is configured to
`exchange VPN traffic with the public network in tunnel
`format. VPN data packets adhering to tunnel format com-
`prise a header and a body. The header includes source and
`destination addresses corresponding to the VPN units serv-
`ing the origination and destination VPN members, respec-
`tively. The body comprises the original data packet gener-
`ated by the originating VPN member,
`including the
`addresses of the origination and destination endstations. The
`source VPN unit receives the original packet from the
`originating VPN member, appends the header, and encrypts
`the body before transmitting the VPN packet toward its
`destination. The destination VPN unit receives the VPN
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`from the public network, removes the header,
`packet
`decrypts the body, and forwards the original packet toward
`the destination endstation.
`
`A VPN unit operating in this selective mode of operation
`will not be a single point of failure for all data traffic passing
`between the organization’s private network and the public
`network, and can be replaced without disrupting non-VPN
`traffic. Advantageously, non-VPN traffic bypasses the VPN
`unit, thereby avoiding any delay that may be imparted by the
`VPN unit. In an alternative embodiment of the invention,
`multiple private networks are connected to a single VPN
`unit.
`
`DESCRIPTION OF THE FIGURES
`
`FIG. 1 illustrates a public network 100 including VPN
`units 115, 125, 135, 145, and 155 operating under control of
`VPN management station 160 in accordance with an aspect
`of the present invention.
`FIG. 2 is a block diagram illustrating the configuration of
`VPN data packets constructed according to the transport and
`tunnel formats.
`
`FIG. 3 is a flow chart illustrating the process by which a
`VPN data packet is transmitted from one member of a VPN
`to another member of the VPN, in tunnel mode format, over
`a public data network in accordance with an aspect of the
`present invention.
`FIG. 4 is a flow chart illustrating the process by which a
`tunnel mode VPN data packet is received over a public data
`network by one member of a VPN, from another member of
`the VPN,
`in accordance with an aspect of the present
`invention.
`
`FIG. 5 is a flow chart illustrating a process for exchanging
`VPN traffic between a remote client and VPN members
`
`served by a VPN unit operating in selective mode.
`FIG. 6 is a block diagram illustrating a portion of the
`internal structure of VPN unit 115 from FIG. 1 in accordance
`
`with an aspect of the present invention. FIG. 7 is a flow chart
`illustrating some of the operations performed by VPN unit
`115 during its configuration and the configuration of a VPN.
`FIG. 8 is a flow chart illustrating some of the operations
`performed to configure VPN unit 115 to operate in selective
`mode in accordance with an embodiment of the invention.
`
`DEFINITIONS
`
`Configuration Parameters—parameters sent to a VPN unit
`to configure the VPN unit to appropriately handle commu-
`nications between members of VPNs.
`
`Group of Nodes—a group of nodes on a public network.
`In one variation,
`these nodes belong to the same local
`network. In another variation, these nodes are specified by at
`least one net/mask pair.
`Local Address—an address on the same private network
`(or local network), wherein the private network is separated
`logically or physically from a public data network.
`Local Network—a private network (or a local network)
`separated logically or physically from a public data network.
`Net/Mask Pair—a specification for a group of network
`addresses including a network ID and a network address
`mask.
`
`Network Group—same as group of nodes.
`Non-local Address—an address on a different private
`network (or local network), wherein private networks are
`separated logically or physically from a public data network.
`VPN traffic—communications intended to be transmitted
`
`within a virtual private network.
`
`Petitioner RPX Corporation - Ex. 1012, p. 11
`
`Petitioner RPX Corporation - Ex. 1012, p. 11
`
`

`

`US 6,701,437 B1
`
`5
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`The following description is presented to enable any
`person skilled in the art to make and use the invention, and
`is provided in the context of a particular application and its
`requirements. Various modifications to the disclosed
`embodiments will be readily apparent to those skilled in the
`art, and the general principles defined herein may be applied
`to other embodiments and applications without departing
`from the spirit and scope of the present invention. Thus, the
`present invention is not intended to be limited to the embodi-
`ments shown, but
`is to be accorded the widest scope
`consistent with the principles and features disclosed herein.
`For example, the present invention is described predomi-
`nantly in terms of utilizing the Internet as a communications
`medium. However, the concepts discussed herein are broad
`enough to accomplish the implementation of secure virtual
`private networks over other public or relatively unsecure
`communications media. In addition, although the invention
`is implemented in the form of a virtual private network unit,
`the concepts and methods of the invention are readily
`adaptable to communication devices performing other func-
`tions.
`
`Throughout this detailed description, numerous specific
`details are set forth, such as particular encryption or key
`management protocols,
`in order to provide a thorough
`understanding of the present invention. To one skilled in the
`art, however, it will be understood that the present invention
`may be practiced without such specific details. In other
`instances, well-known control structures and system com-
`ponents have not been shown in detail
`in order not
`to
`obscure the present invention.
`The present invention is not limited to any one particular
`implementation technique. Those of ordinary skill in the art
`will be able to implement the invention with various tech-
`nologies without undue experimentation once the function-
`ality to be carried out by such components is described. In
`many instances, components implemented by the present
`invention are described at an architectural, functional level.
`Many of the elements may be configured using well-known
`structures, particularly those designated as relating to vari-
`ous compression or encryption techniques. Additionally, for
`logic to be included within the system of the present
`invention, functionality and flow diagrams are described in
`such a manner that those of ordinary skill in the art will be
`able to implement the particular methods without undue
`experimentation. It should also be understood that the tech-
`niques of the present invention may be implemented using
`a variety of technologies. For example, the VPN unit to be
`described further herein may be implemented in software
`running on a computer system, or implemented in hardware
`utilizing either a combination of microprocessors or other
`specially designed application specific integrated circuits,
`programmable logic devices, or various combinations
`thereof.
`
`Description of a Virtual Private Network (VPN)
`
`FIG. 1 illustrates a public network 100, such as the
`Internet, including VPN units 115, 125, 135, 145 and 155
`operating under the control of VPN management station 160
`in accordance with an embodiment of the present invention.
`Public network 100 may be any type of communication
`channel, including, but not limited to, data networks such as
`the Internet.
`
`Headquarters local area network (LAN) 110, including
`three endstations 111, 112 and 113, is coupled to public
`
`6
`network 100 through router 114. In FIG. 1, VPN unit 115 is
`coupled to the connection between router 114 and LAN 110.
`In an alternative embodiment of the invention, however,
`VPN unit 115 is coupled to the connection between router
`114 and public network 100.
`Branch LAN 120, which includes endstations 121, 122
`and 123, is connected to public network 100 through VPN
`unit 125 and router 124. LAN 130 is coupled to public
`network 100 through router 134. LAN 130 comprises VPN
`unit 135 and a plurality of computers, illustratively 131 and
`132. In addition, LANs (which may, alternatively, comprise
`segments of LAN 130) 170, 180 connect to public network
`100 through VPN unit 135 and LAN 130.
`FIG. 1 thus illustrates great flexibility in the placement
`and configuration of VPN units. They may be located within
`a private LAN or LAN segment or between a private LAN
`and a public LAN. They may, in addition, serve multiple
`LANs or LAN segments.
`Data communications within headquarters LAN 110,
`branch LAN 120, LAN 130 and other LANs or LAN
`segments participating in a virtual private network may
`adhere to any of a wide variety of network protocols, the
`most common of which are Ethernet and Token Ring. In one
`embodiment of the invention, however, a VPN unit may be
`configured to require a particular protocol (e.g., Ethernet).
`VPN units 145 and 155 couple remote clients 140 and
`150, respectively, to public network 100. Remote clients are
`systems coupled to public network 100 from remote loca-
`tions. It is frequently desirable for members of an enterprise
`who are travelling or working from home or other remote
`locations to exchange data with members of the enterprise
`situated at other locations. For example, remote clients 140
`and 150 may communicate with headquarters LAN 110 over
`long distance telephone lines or other point-to-point links.
`As another example, client 140 may,
`from one remote
`location, communicate through VPN units 145 and 155 with
`client 150, at another remote location, without the partici-
`pation of other VPN units or members of LANs 110, 120 or
`130.
`
`Advantageously, remote clients 140 and 150 have access
`to public network 100 through local Internet service pro-
`viders (ISPs). In one embodiment, VPN units 145 and 155
`are implemented as hardware modules.
`In another
`embodiment, VPN units 145 and 155 are implemented as
`software modules within remote clients 140 and 150, respec-
`tively.
`For purposes of the present invention, each of VPN units
`115, 125, 135, 145 and 155 serves its remote client or local
`area network to enable the exchange of secure communica-
`tions among the remote clients and stations within the local
`area networks via the Internet (or other public network).
`VPN units 115, 125, 135, 145 and 155 include operating
`systems 116, 126, 136, 146 and 156, respectively, which
`control
`the operation of the respective VPN units. An
`illustrative internal structure of VPN unit 115 is described in
`more detail below with reference to FIG. 5.
`
`Note that while VPN unit 115 is simply coupled to an
`interconnection between headquarters LAN 110 and public
`network 100, VPN unit 125 comprises an integral part of the
`communication path between branch LAN 120 and public
`network 100. Therefore, in the embodiment of the invention
`depicted in FIG. 1, only selected data communications
`passing between public network 100 and LAN 110 are
`handled by VPN unit 115. All communications passing
`between public network 100 and LAN 120, however, must
`be processed by VPN 125. To ensure the necessary security
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Petitioner RPX Corporation - Ex. 1012, p. 12
`
`Petitioner RPX Corporation - Ex. 1012, p. 12
`
`

`

`US 6,701,437 B1
`
`7
`for communications between VPN members, in the illus-
`trated embodiment VPN traffic involving endstations within
`LAN 110 conform to a “tunnel” format while VPN traffic
`
`involving endstations in LAN 120 may conform to either the
`“tunnel” or “transport” format, both of which are described
`below.
`
`VPN management station 160 illustratively has control
`over all VPN units participating in the management station’s
`virtual private network. In a present embodiment of the
`invention, VPN management station 160 issues commands
`and configuration information to VPN units 115, 125, 135,
`145 and 155 through public network 100. Although FIG. 1
`depicts only one VPN management station, in an alternative
`embodiment of the invention multiple management stations
`serve a virtual private network.
`VPN management station 160 may be implemented in
`software running on a computer system, or alternatively may
`be implemented in hardware utilizing a combination of
`microprocessors or other specially designed application spe-
`cific integrated circuits, programmable logic devices, or
`various combinations thereof. VPN management station 160
`illustratively maintains a database concerning the VPN units
`it manages, to include various information such as configu-
`ration data, VPN unit identities, etc. The database may be
`located on the management station or another computer
`system coupled to the management station.
`According to an embodiment of the invention, VPN unit
`115 is configured to send and receive data communications
`between members of a virtual private network that includes
`one or more endstations attached to headquarters LAN 110.
`However, VPN unit 115 only receives and processes data
`directed to or from a VPN member located within LAN 110
`
`when the data are to be secured while in transit (e.g., the data
`constitutes VPN traffic). Because not all communications
`passing between headquarters LAN 110 and public network
`100 constitute VPN traffic, only a portion of the data packets
`passed between the interconnected networks are received by
`VPN unit 115. VPN communications directed from LANs
`
`110, 120 and 130 to VPN members external to the originat-
`ing LAN are encrypted before being passed to the public
`network, while those passed in the other direction are
`decrypted before being passed to the destination LAN. In a
`present embodiment of the invention, however, a VPN unit
`operating in selective mode, such as VPN unit 115, does not
`receive or process communications that are not VPN traffic.
`To enable this selective mode of operation, VPN traffic
`sent or received by endstations within headquarters LAN
`110 conform to a “tunnel” format. In this tunnel format, data
`packets generated by an endstation in LAN 110 are received
`by VPN unit 115 where they are encrypted and encapsulated
`within VPN packets addressed to the VPN unit serving the
`destination endstation. Conversely, when VPN unit 115
`receives a VPN packet from public network 100, it strips off
`the destination address (which corresponds to VPN unit
`115), decrypts the remainder, and forwards the packet to
`LAN 110 for delivery to the appropriate station.
`In this embodiment of the invention, a VPN unit operating
`in selective mode is linked to a LAN/public network inter-
`connection through a network communication port. The
`VPN unit may have multiple network communication ports.
`In one alternative embodiment of the invention in which a
`selective mode VPN unit has two or more network commu-
`
`nication ports, the VPN unit connects to multiple private or
`public networks and/or interconnections between a private
`and a public network. Illustratively, each connection is
`through a different network communication port, although in
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`8
`other alternative embodiments, multiple