(12) United States Patent
`US 6,496,867 B1
`(10) Patent N0.:
`Beser et al.
`
`Dec. 17, 2002(45) Date of Patent:
`
`US006496867B1
`
`(54) SYSTEM AND METHOD TO NEGOTIATE
`PRIVATE NETWORK ADDRESSES FOR
`INITIATING TUNNELING ASSOCIATIONS
`THROUGH PRIVATE AND/OR PUBLIC
`NETWORKS
`
`(75)
`
`(73)
`
`(21)
`
`(22)
`
`(51)
`(52)
`(58)
`
`(56)
`
`Inventors: Nurettin B. Beser, Evanston, IL (US);
`Michael B0rella, Naperville, IL (US)
`
`Assignee: 3Com Corporation, Santa Clara, CA
`(US)
`
`Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`Appl. No.: 09/384,120
`
`Filed:
`
`Aug. 27, 1999
`
`Int. Cl.7 ........................ G06F 15/16; G06F 15/173
`US. Cl.
`........................ 709/245; 709/227; 709/225
`Field of Search ................................. 709/220, 222,
`709/225, 226, 227, 228, 229, 245, 218,
`217; 370/401, 349; 713/201
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5,159,592 A
`5,227,778 A
`5,550,984 A
`5,636,216 A
`5,708,655 A
`5,793,763 A
`5,812,819 A
`5,867,660 A
`5,872,847 A
`6,018,767 A *
`6,236,652 B1 *
`6,253,327 B1 *
`6,377,982 B1 *
`
`10/1992 Perkins
`7/1993 Vacon et 81.
`8/1996 Gelb
`6/1997 Fox et 81.
`1/1998 Toth et 81.
`8/1998 Mayes et 81.
`9/1998 Rodwin et 81.
`2/1999 Schmidt et 81.
`2/1999 Boyle et 81.
`1/2000 Fijolek et al.
`.............. 709/218
`5/2001 Preston et al.
`370/349
`
`
`6/2001 Zhang et al.
`..
`713/201
`4/2002 Rai et al.
`.................... 709/217
`
`6,381,646 B2 *
`6,400,722 B1 *
`OTHER PUBLICATIONS
`
`4/2002 Zhang et al.
`6/2002 Chuah et al.
`
`............... 709/227
`............... 370/401
`
`Lee et al., “The Next Genration of the Internet: Aspects of
`teh Internet Protocol Version 6”, IEEE Network, Jan./Feb.
`1988, pp. 28—33.*
`“Internet Engineering Task Force”, Request for Comments
`791, Internet Protocol, Sep. 1981, pp. 1 to 45.
`“Internet Engineering Task Force”, Request for Comments
`1853, IP in IP Tunneling, Oct. 1995, pp. 1 to 8.
`“Internet Engineering Task Force”, Request for Comments
`1701, Generic Routing Encapsulation (GRE), Oct. 1994, pp.
`1 to 8.
`
`“Internet Engineering Task Force”, Request for Comments
`1241, AScheme for an Internet Encapsulation Protocol, Jul.
`1991, pp. 1 to 17.
`
`(List continued on next page.)
`
`Primary Examiner—Le Hien Luu
`(74) Attorney, Agent, or Firm—McDonnell, Boehnen,
`Hulbert & Berghoff
`
`(57)
`
`ABSTRACT
`
`A method for initiating a tunneling association in a data
`network. The method includes negotiating private addresses,
`such as private Internet Protocol addresses, for the ends of
`the tunneling association. The negotiation is performed on a
`public network, such as the Internet, through a trusted-third-
`party without revealing the private addresses. The method
`provides for hiding the identity of the originating and
`terminating ends of the tunneling association from the other
`users of the public network. Hiding the identities may
`prevent interception of media flow between the ends of the
`tunneling association or eavesdropping on Voice-over-
`Internet-Protocol calls. The method increases the security of
`communication on the data network without imposing a
`computational burden on the devices in the data network.
`
`41 Claims, 17 Drawing Sheets
`
`100
`
`1 /
`
`\
`
`RECEIVE A REQUEST TO INITIATE A
`TUNNELING ASSOCIATION ON A FIRST
`NETWORK DEVICE
`
`
`
` NEGOTIATE A FIRST PRIVATE NETWORK \
`
`__i‘
`INFORM A TRUSTED-THIRD-PARTY
`NETWORK DEVICE OF THE REQUEST ON \
`A PUBLIC NETWORK
`
`:ASSOCIATE A PUBLIC NETWORK
`DEVICE ON THE TRUSTED-THIRD-PARTY
`ADDRESS FOR A SECOND NETWORK —\
`NETWORK DEVICE
`
`—1—\
`ADDRESS ON THE FIRST NETWORK
`DEVICE AND A SECOND PRIVATE
`NETWORK ADDRESS ON THE SECOND
`NETWORK DEVICE THROUGH THE
`PUBLIC NETWORK
`
`102
`
`104
`
`106
`
`108
`
`I
`
`Petitioner RPX Corporation - Ex. 1009, p. 1
`
`Petitioner RPX Corporation - Ex. 1009, p. 1
`
`

`

`US 6,496,867 B1
`
`Page 2
`
`OTHER PUBLICATIONS
`
`“ITU—T Recommendation H.323”, Series H: Audiovisual
`and Multimedia Systems (Systems and Terminal Equipment
`for audiovisual Services), Telecommunication Standardiza-
`tion Sector of ITU, International Telecommunication Union,
`Feb. 1998, 125 pages.
`“ITU—T Recommendation H.255 .0”, Series H: Audiovisual
`and Multimedia Systems (Transmission Multiplexing and
`Synchronization), Telecommunication Standardization Sec-
`tor of ITU, International Telecommunication Union, Feb.
`1998, 157 pages.
`“Internet Engineering Task Force”, Request for Comments
`2663, IP Network Address Translator (NAT) Terminology
`and Considerations, Aug. 1999, pp. 1 to 30.
`“Internet Engineering Task Force”, Request for Comments
`1631, The IP Network Address Translator (NAT), May 1994,
`pp. 1 to 10.
`“Internet Engineering Task Force”, Internet Draft, Negoti-
`ated AddressReuse (NAR), May 1998, pp. 1 to 22.
`“Internet Engineering Task Force”,
`Internet—Draft, NAT
`Bypass for End 2 End ‘Sensitive’ Applications, Jan. 1998,
`pp. 1 to5.
`“Internet Engineering Task Force”, Interne—Draft, Network
`Address Translation—Protocol Translation (NAT—PT), Jan.
`1999, pp. 1 to 15.
`“Internet Engineering Task Force”, Internet—Draft, IP Host
`Network Address (and Port) Translation, Nov. 1998, pp. 1 to
`14.
`
`“Internet Engineering Task Force”, Internet Draft, Distrib-
`uted Network Address Translation, Oct. 1998, pp. 1 to 24.
`“Internet Engineering Task Force”,
`Internet—Draft, DNS
`Extensions to Network Address Translators (DNSiALG),
`Oct. 1998, pp. 1 to 27.
`
`“Internet Engineering Task Force”, Internet—Draft, Security
`for IP Network Address Translator (NAT) Domains, Nov.
`1998, pp. 1 to 11.
`“Internet Engineering Task Force”, Internet—Draft, The IP
`Network Address Translator (NAT), Feb. 1998, pp. 1 to 24.
`“Internet Engineering Task Force”, Internet—Draft, Tradi-
`tional IP Network Address Translator (Traditional NAT),
`Oct. 1998, pp. 1 to 17.
`“Internet Engineering Task Force”, Internet—Draft, IP Net-
`work Address Translator (NAT) Terminology and Consid-
`erations, Oct. 1998,, pp. 1 to 28.
`“Internet Engineering Task Force”, Internet Draft, A Multi-
`homing solution using NATs, Nov. 1998, pp. 1 to 32.
`“Internet Engineering Task Force”, Internet Draft, Network
`Address Translation Issues with IPsec, Feb. 1998, pp. 1 to
`12.
`
`“Internet Engineering Task Force”, Internet Draft, IP Secu-
`rity, Nov. 1997, pp. 1 to 12.
`“Internet Engineering Task Force”, Internet Draft, Architec-
`tural Implications of NAT, Oct. 1998, pp. 1 to 14.
`“Internet Engineering Task Force”, Internet Draft, IP Relo-
`cation Through Twice Network Address Translators (RAT),
`Feb. 1999, pp. 1 to 20.
`“Internet Engineering Task Force”, Internet Draft, Reverse
`Twice Network Address Translators (RAT), Dec. 1998, pp.
`1 to 24.
`
`“Internet Engineering Task Force”, Internet Draft, Implica-
`tions of NATs on the TCP/IP Architecture, Feb. 1999, pp. 1
`to 7.
`
`“Internet Engineering Task Force”, Internet Draft, Mobile IP
`Extension for Private Internets Support, Feb. 1999, pp. 1 to
`24.
`
`* cited by examiner
`
`Petitioner RPX Corporation - Ex. 1009, p. 2
`
`Petitioner RPX Corporation - Ex. 1009, p. 2
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 1 0f 17
`
`US 6,496,867 B1
`
`FIG. 1
`
`PRIVATE
`
`NETWORK
`
`Petitioner RPX Corporation - Ex. 1009, p. 3
`
`Petitioner RPX Corporation - Ex. 1009, p. 3
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 2 0f 17
`
`US 6,496,867 B1
`
`FIG. 2
`
`50
`
`APPLICATION LAYER
`
`TFTP
`
`DHCP
`
`/
`
`UDP
`MGMT
`
`62
`
`64
`
`66
`
`as
`
`TRANSPORT
`LAYER
`
`so
`
`
`
`56
`
`NETWORK
`LAYER
`
`MAC
`
`54
`
`52
`
`PHYS'CAL
`MEDIA
`INTERFACE
`
`DATA LINK
`LAYER
`
`PHYSICAL
`LAYER
`
`Petitioner RPX Corporation - Ex. 1009, p. 4
`
`Petitioner RPX Corporation - Ex. 1009, p. 4
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 3 0f 17
`
`US 6,496,867 B1
`
`FIG. 3
`INTERNET PROTOCOL PACKET
`
`so
`/
`
`
`
`
`
` PAYLOAD
`
`g4
`
`
`
`Petitioner RPX Corporation - Ex. 1009, p. 5
`
`Petitioner RPX Corporation - Ex. 1009, p. 5
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 4 0f 17
`
`US 6,496,867 B1
`
`FIG. 4
`
`START
`
`100
`
`/
`
`RECEIVE A REQUEST To INITIATE A
`TUNNELING ASSOCIATION ON A FIRST
`NETWORK DEVICE
`
`INFORM A TRUSTED-THIRD-PARTY
`
`NETWORK DEVICE OF THE REQUEST ON
`
`A PUBLIC NETWORK
`
`PUBLIC NETWORK
`
`ASSOCIATE A PUBLIC NETWORK
`
`ADDRESS FOR A SECOND NETWORK
`
`DEVICE ON THE TRUSTED-THIRD-PARTY
`NETWORK DEVICE
`
`NEGOTIATE A FIRST PRIVATE NETWORK
`
`ADDRESS ON THE FIRST NETWORK
`DEVICE AND A SECOND PRIVATE
`NETWORK ADDRESS ON THE SECOND
`
`NETWORK DEVICE THROUGH THE
`
`102
`
`104
`
`106
`
`108
`
`Petitioner RPX Corporation - Ex. 1009, p. 6
`
`Petitioner RPX Corporation - Ex. 1009, p. 6
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 5 0f 17
`
`US 6,496,867 B1
`
`FIG. 5
`
`START
`
`110
`
`/
`
`RECEIVE A REQUEST TO INITIATE A VOIP
`ASSOCIATION ON A FIRST NETWORK
`
`DEVICE
`
`NETWORK
`
`112
`
`114
`
`"6
`
`118
`
`INFORM A TRUSTED-THIRD-PARTY
`
`NETWORK DEVICE OF THE REQUEST ON
`
`A PUBLIC NETWORK
`
`ASSOCIATE A PUBLIC IP ADDRESS FOR A
`
`SECOND NETWORK DEVICE ON THE
`
`TRUSTED-THIRD-PARTY NETWORK
`DEVICE
`
`NEGOTIATE A FIRST PRIVATE IP
`ADDRESS ON THE FIRST NETWORK
`DEVICE AND A SECOND PRIVATE IP
`
`ADDRESS ON THE SECOND NETWORK
`DEVICE THROUGH THE PUBLIC
`
`Petitioner RPX Corporation - Ex. 1009, p. 7
`
`Petitioner RPX Corporation - Ex. 1009, p. 7
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 6 0f 17
`
`US 6,496,867 B1
`
`FIG. 6
`
`13°
`
`TH IRD-PARTY
`
`NETWORK
`
`DEVICE
`
`TERMINATING
`
`TELEPHONY
`
`1_6
`
`ORIGINATING
`
`TELEPHONY
`
`DEVICE
`
`fl
`
`FIRST
`NETWORK
`DEVICE
`H
`
` TRUSTED-
`
`
`
`DEVICE
`
`g
`
`
`SECOND
`NETWORK
`
`DEVICE
`
`
`3_Q
`
`Petitioner RPX Corporation - Ex. 1009, p. 8
`
`Petitioner RPX Corporation - Ex. 1009, p. 8
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 7 0f 17
`
`US 6,496,867 B1
`
`FIG. 7
`
`START
`
`140
`
`/
`
`SELECT THE FIRST PRIVATE NETWORK
`
`
`
`
`
`NETWORK DEVICE
`
`
`ADDRESS FROM A FIRST POOL OF
`
`PRIVATE ADDRESSES ON THE FIRST
`
`COMMUNICATE THE FIRST PRIVATE
`
`NETWORK ADDRESS FROM THE FIRST
`
`PUBLIC NETWORK
`
`NETWORK DEVICE TO THE SECOND
`
`NETWORK DEVICE THROUGH THE
`
`SELECT THE SECOND PRIVATE
`
`
`
`NETWORK ADDRESS FROM A SECOND
`
`
`
`POOL OF PRIVATE ADDRESSES ON THE
`SECOND NETWORK DEVICE
`
`
`
`142
`
`144
`
`146
`
`148
`
`COMMUNICATE THE SECOND PRIVATE
`
`NETWORK ADDRESS FROM THE
`
`SECOND NETWORK DEVICE TO THE
`
`PUBLIC NETWORK
`
`FIRST NETWORK DEVICE THROUGH THE
`
`Petitioner RPX Corporation - Ex. 1009, p. 9
`
`Petitioner RPX Corporation - Ex. 1009, p. 9
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 8 0f 17
`
`US 6,496,867 B1
`
`FIG. 8
`
`START
`
`150
`
`»/
`
`SELECT THE FIRST PRIVATE IP ADDRESS
`FROM A FIRST POOL OF PRIVATE IP
`
`ADDRESSES ON THE FIRST NETWORK
`
`
`
` 152
`
`DEVICE
`
`COMMUNICATE THE FIRST PRIVATE IP
`
`ADDRESS FROM THE FIRST NETWORK
`
`DEVICE TO THE SECOND NETWORK
`
`DEVICE THROUGH THE TRUSTED-THIRD-
`
`PARTY NETWORK DEVICE ON THE
`
`154
`
`PUBLIC NETWORK
`
`
`
`SELECT THE SECOND PRIVATE IP
`ADDRESS FROM A SECOND POOL OF
`
`
`PRIVATE IP ADDRESSES ON THE SECOND
`NETWORK DEVICE
`
`
`COMMUNICATE THE SECOND PRIVATE IP
`
`DEVICE ON THE PUBLIC NETWORK
`
`ADDRESS FROM THE SECOND
`NETWORK DEVICE TO THE FIRST
`NETWORK DEVICE THROUGH THE
`
`TRUSTED-THIRD-PARTY NETWORK
`
`156
`
`158
`
`Petitioner RPX Corporation - Ex. 1009, p. 10
`
`Petitioner RPX Corporation - Ex. 1009, p. 10
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 9 0f 17
`
`US 6,496,867 B1
`
`FIG. 9
`
`15°
`
`
` TRUSTED-
`
`
`
`FIRST
`THIRD-PARTY
`SECOND
`NETWORK
`NETWORK
`NETWORK
`
`
`
`
`DEVICE
`DEVICE
`DEVICE
`
`
`
`
`1_4
`Q
`L6
`
`
`
`
`
`
`
`SELECT FIRST
`
`
`
`PRIVATE IP
`ADDRESS
`
` SELECT
`
`SECOND
`
`
`PRIVATE IP
`
`
`ADDRESS
`.______|
`
`
`THIRD PACKET 1 6
`
`Petitioner RPX Corporation - Ex. 1009, p. 11
`
`Petitioner RPX Corporation - Ex. 1009, p. 11
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 10 0f 17
`
`US 6,496,867 B1
`
`FIG. 10
`
`START
`
`170
`
`/
`
`
`
`
`SELECT MULTIPLE PRIVATE NETWORK
`ADDRESSES FROM A POOL OF PRIVATE
`
`ADDRESSES ON THE FIRST NETWORK
`
`
`DEVICE
`
`
`
`172
`
`COMMUNICATE THE MULTIPLE PRIVATE
`NETWORK ADDRESSES FROM THE FIRST
`NETWORK DEVICE TO THE SECOND
`NETWORK DEVICE THROUGH THE
`
`PUBLIC NETWORK
`
`ADDRESS AND THE SECOND PRIVATE
`NETWORK ADDRESS FROM THE
`
` SELECT THE FIRST PRIVATE NETWORK
`
`
`
`
`
`MULTIPLE PRIVATE ADDRESSES ON THE
`
`
`SECOND NETWORK DEVICE
`
`
`
`174
`
`176
`
`COMMUNICATE THE FIRST PRIVATE
`NETWORK ADDRESS AND THE SECOND
`PRIVATE NETWORK ADDRESS FROM
`THE SECOND NETWORK DEVICE TO THE
`
`PUBLIC NETWORK 178
`
`FIRST NETWORK DEVICE THROUGH THE
`
`Petitioner RPX Corporation - Ex. 1009, p. 12
`
`Petitioner RPX Corporation - Ex. 1009, p. 12
`
`

`

`US. Patent
`
`Dec. 17,2002
`
`Sheet 11 0f 17
`
`US 6,496,867 B1
`
`FIG. 11
`
`START
`
`180
`
`/
`
`SELECT MULTIPLE PRIVATE IP
`
`
`
`ADDRESSES FROM A POOL OF PRIVATE
`
`
`
`IP ADDRESSES ON THE FIRST NETWORK
`
`
`
`DEVICE
`
`COMMUNICATE THE MULTIPLE PRIVATE
`
`DEVICE ON THE PUBLIC NETWORK
`
`IP ADDRESSES FROM THE FIRST
`
`NETWORK DEVICE TO THE SECOND
`
`NETWORK DEVICE THROUGH THE
`
`TRUSTED-THIRD-PARTY NETWORK
`
`182
`
`184
`
`186
`
`188
`
` SELECT THE FIRST PRIVATE IP ADDRESS
`
`
`
`
`AND THE SECOND PRIVATE IP ADDRESS
`
`FROM THE MULTIPLE PRIVATE IP
`
`ADDRESSES ON THE SECOND NETWORK
`DEVICE
`
`
`
`
`COMMUNICATE THE FIRST PRIVATE IP
`
`ADDRESS AND THE SECOND PRIVATE IP
`
`DEVICE ON THE PUBLIC NETWORK
`
`ADDRESS FROM THE SECOND
`
`NETWORK DEVICE TO THE FIRST
`
`NETWORK DEVICE THROUGH THE
`
`TRUSTED-THIRD-PARTY NETWORK
`
`Petitioner RPX Corporation - Ex. 1009, p. 13
`
`Petitioner RPX Corporation - Ex. 1009, p. 13
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 12 0f 17
`
`US 6,496,867 B1
`
`FIG. 12
`
`19°
`
`TRUSTED-
`
`/
`
`
`FIRST
`NETWORK
`
`
`1_4
`
`
`DEVICE
`
`THIRD-PARTY
`NETWORK
`
`
`SECOND
`NETWORK
`
`
`DEVICE
`
`
`1_6
`
`
`_3_Q
`
`DEVICE
`
` SELECT
`
`MULTIPLE
`
`PRIVATE IP
`
`ADDRESSES
`
`——————————
`
`186
`
`
`
`SELECT FIRST AND
`
`SECOND PRIVATE IP
`
`
`ADDRESSES
`
` FOURTH PACKET m
`
` THIRD PACKET 19
`
`Petitioner RPX Corporation - Ex. 1009, p. 14
`
`Petitioner RPX Corporation - Ex. 1009, p. 14
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 13 0f 17
`
`US 6,496,867 B1
`
`FIG. 13
`
`START
`
`210
`/
`
`COMMUNICATE THE PUBLIC IP ADDRESS
`OF THE SECOND NETWORK DEVICE TO
`
`THE FIRST NETWORK DEVICE
`
`SELECT THE FIRST PRIVATE IP ADDRESS
`
`FROM A FIRST POOL OF PRIVATE IP
`
`
`
`ADDRESSES ON THE FIRST NETWORK
`
`DEVICE
`
`
`
`
`212
`
`214
`
`216
`
`218
`
`220
`
`COMMUNICATE THE FIRST PRIVATE IP
`
`ADDRESS FROM THE FIRST NETWORK
`
`
`
`
`
`
`
`DEVICE THROUGH THE PUBLIC
`
`
`NETWORK
`
`
`DEVICE TO THE SECOND NETWORK
`
`SELECT THE SECOND PRIVATE IP
`
`
`
`ADDRESS FROM A SECOND POOL OF
`
`
`PRIVATE IP ADDRESSES ON THE SECOND
`
`
`NETWORK DEVICE
`
`
` COMMUNICATE THE SECOND PRIVATE IP
`
`
`
`
`
`
`NETWORK DEVICE TO THE FIRST
`
`ADDRESS FROM THE SECOND
`
`NETWORK DEVICE THROUGH THE
`
`
`
`PUBLIC NETWORK
`
`Petitioner RPX Corporation - Ex. 1009, p. 15
`
`Petitioner RPX Corporation - Ex. 1009, p. 15
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 14 0f 17
`
`US 6,496,867 B1
`
`FIG. 14
`
`23°
`
`
` TRUSTED-
`
`
`FIRST
`THIRD-PARTY
`SECOND
`
`
`
`
`NETWORK
`NETWORK
`NETWORK
`
`
`
`
`DEVICE
`DEVICE
`DEVICE
`
`
`
`
`g,
`
`
`
`
`m
`
`SELECT FIRST
`
`
`
`PRIVATE |P
`ADDRESS
`
`
`
`
`214
`
` SELECT
`
`SECOND
`
`PRIVATE IP
`
`__________
`
`218
`
`
`ADDRESS
` THIRD PACKET 2 6
`
`Petitioner RPX Corporation - Ex. 1009, p. 16
`
`Petitioner RPX Corporation - Ex. 1009, p. 16
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 15 0f 17
`
`US 6,496,867 B1
`
`FIG. 15
`START
`
`250
`/
`
`COMMUNICATE THE PUBLIC IP ADDRESS
`OF THE SECOND NETWORK DEVICE TO
`
`THE FIRST NETWORK DEVICE
`
`DEVICE
`
`SELECT MULTIPLE PRIVATE |P
`
`ADDRESSES FROM A POOL OF PRIVATE
`
`IP ADDRESSES ON THE FIRST NETWORK
`
`
`
`COMMUNICATE THE MULTIPLE PRIVATE
`
`IP ADDRESSES FROM THE FIRST
`
`
`
`NETWORK DEVICE TO THE SECOND
`
`NETWORK DEVICE THROUGH THE
`
`
`
`PUBLIC NETWORK
`
`
`
`
`
`
` SELECT THE FIRST PRIVATE IP ADDRESS
`
`
`
`
`
`
`AND THE SECOND PRIVATE IP ADDRESS
`
`FROM THE MULTIPLE PRIVATE IP
`
`ADDRESSES ON THE SECOND NETWORK
`
`
`
`DEVICE
`
`COMMUNICATE THE FIRST PRIVATE IP
`
`ADDRESS AND THE SECOND PRIVATE IP
`
`PUBLIC NETWORK
`
`ADDRESS FROM THE SECOND
`
`NETWORK DEVICE TO THE FIRST
`
`NETWORK DEVICE THROUGH THE
`
`252
`
`254
`
`256
`
`258
`
`260
`
`Petitioner RPX Corporation - Ex. 1009, p. 17
`
`Petitioner RPX Corporation - Ex. 1009, p. 17
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 16 0f 17
`
`US 6,496,867 B1
`
`FIG. 16
`
`27°
`
`
`
`TRUSTED-
`
`
`
`FIRST
`THIRD-PARTY
`SECOND
`
`
`
`N ETWORK
`NETWORK
`NETWORK
`
`
`
`
`DEVICE
`DEVICE
`DEV|CE
`
`
`
`
`g
`
`
`
`254
`
`E
`
`SELECT
`
`
`MULTIPLE
`
`
`PRIVATE IP
`
`ADDRESSES
`
`
`
`
`
`
`SELECT FIRST AND
`SECOND PRIVATE IP
`
`
`
`ADDRESSES
`
`Petitioner RPX Corporation - Ex. 1009, p. 18
`
`Petitioner RPX Corporation - Ex. 1009, p. 18
`
`

`

`US. Patent
`
`Dec. 17, 2002
`
`Sheet 17 0f 17
`
`US 6,496,867 B1
`
`FIG. 17
`
`END1
`
`ennz
`
`310
`
`/
`
`32°
`
`EE
`E
`
`DEW
`
`EE
`E
`
`312
`
`PUBUC
`NEHNORK
`
`12
`
`314
`
`DEV2
`
`324
`
`E
`E"
`
`ENDS
`
`DEV3
`
`316
`
`326
`
`3.3
`E
`
`END4
`
`Petitioner RPX Corporation - Ex. 1009, p. 19
`
`Petitioner RPX Corporation - Ex. 1009, p. 19
`
`

`

`US 6,496,867 B1
`
`1
`SYSTEM AND METHOD TO NEGOTIATE
`PRIVATE NETWORK ADDRESSES FOR
`INITIATING TUNNELING ASSOCIATIONS
`THROUGH PRIVATE AND/OR PUBLIC
`NETWORKS
`
`FIELD OF INVENTION
`
`The present invention relates to communications in data
`networks. More specifically,
`it relates to a method for
`initiating a tunneling association in a data network.
`BACKGROUND OF THE INVENTION
`
`Computer users are becoming increasingly concerned
`about the privacy of their communications over the Internet.
`Privacy concerns are an important factor in the continued
`growth and acceptance of the Internet by society. As the use
`of the Internet increases, more and more sensitive informa-
`tion is being transmitted over this global network. Compa-
`nies who cannot afford a private network often transfer
`sensitive corporate information over the Internet. Also,
`private citizens are increasingly relying on the Internet for
`banking and commercial transactions and frequently have to
`transfer private or personal information over the Internet,
`such as credit card numbers, social security numbers, or
`medical information.
`
`Unfortunately, the Internet is not a very secure network.
`Information is transmitted over the Internet inside Internet
`
`Protocol (“IP”) packets. These packets typically pass
`through several routers between transmission by a source
`computer and reception by a destination computer. At each
`leg of their journey the packets can be intercepted and
`inspected. Moreover, the Internet Protocol that is used on
`global computer networks (such as the Internet) and on
`many private networks (such as intranets) is not a highly
`secure protocol. For example, because IP packets include a
`source address in a header, a hacker or cracker may intercept
`all
`IP packets from a particular source IP address.
`Consequently, the hacker may be able to accumulate all
`transmissions from the source.
`
`Typically, it is easy to map users to source IP addresses.
`A determined hacker may extract the source IP address from
`an IP packet and deduce that
`they are coming from a
`computer whose IP address is already known. Knowing the
`location of the source, the hacker may then be able to deduce
`the identity of the user who sent the IP packet. Even if the
`hacker cannot exactly identify the user or computer, he may
`glean sufficient information as to its approximate physical or
`virtual location. In globally addressed IP subnets it is easy to
`determine the location or organization of the source com-
`puter. For example, an appropriate Domain Name Server
`(“DNS”) inquiry may correlate the IP address with a domain
`name, and domain names are typically descriptive of the
`user, location, or the user’s organization.
`Of course, the sender may encrypt the information inside
`the IP packets before transmission, e.g. with IP Security
`(“IPSec”). However, accumulating all the packets from one
`source address may provide the hacker with suflicient infor-
`mation to decrypt the message. Moreover, encryption at the
`source and decryption at the destination may be infeasible
`for certain data formats. For example, streaming data flows,
`such as multimedia or Voice-over-Internet-Protocol
`
`(“VoIP”), may require a great deal of computing power to
`encrypt or decrypt the IP packets on the fly. The increased
`strain on computer power may result in jitter, delay, or the
`loss of some packets. The expense of added computer power
`might also dampen the customer’s desire to invest in VoIP
`equipment.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`Nonetheless, even if the information inside the IP packets
`could be concealed, the hacker is still capable of reading the
`source address of the packets. Armed with the source IP
`address, the hacker may have the capability of tracing any
`VoIP call and eavesdropping on all calls from that source.
`One method of thwarting the hacker is to establish a Virtual
`Private Network (“VPN”) by initiating a tunneling connec-
`tion between edge routers on the public network. For
`example, tunneling packets between two end-points over a
`public network is accomplished by encapsulating the IP
`packet to be tunneled within the payload field for another
`packet that is transmitted on the public network. The tun-
`neled IP packets, however, may need to be encrypted before
`the encapsulation in order to hide the source IP address.
`Once again, due to computer power limitations, this form of
`tunneling may be inappropriate for the transmission of
`multimedia or VoIP packets.
`Another method for tunneling is network address trans-
`lation (see e.g., “The IP Network Address Translator”, by P.
`Srisuresh and K. Egevang, Internet Engineering Task Force
`(“IETF”), Internet Draft <draft-rfced-info-srisuresh-05.txt>,
`February 1998). However, this type of address translation is
`also computationally expensive, causes security problems
`by preventing certain types of encryption from being used,
`or breaks a number of existing applications in a network that
`cannot provide network address translation (e. g., File Trans-
`fer Protocol (“FTP”)). What is more, network address trans-
`lation interferes with the end-to-end routing principal of the
`Internet
`that recommends that packets flow end-to-end
`between network devices without changing the contents of
`any packet along a transmission route (see e.g., “Routing in
`the Internet,” by C. Huitema, Prentice Hall, 1995, ISBN
`0-131-321-927). Once again, due to computer power
`limitations, this form of tunneling may be inappropriate for
`the transmission of multimedia or VoIP packets.
`It is therefore desirable to establish a tunneling associa-
`tion that hides the identity of the originating and terminating
`ends of the tunneling association from the other users of a
`public network. Hiding the identities may prevent a hacker
`from intercepting all media flow between the ends.
`SUMMARY OF THE INVENTION
`
`In accordance with preferred embodiments of the present
`invention, some of the problems associated with initiating a
`tunneling association are overcome. A method and system
`for initiating a tunneling association is provided. One aspect
`of the invention includes a method for initiating a tunneling
`association between an originating end of the tunneling
`association and a terminating end of the tunneling associa-
`tion. The method includes receiving a request to initiate the
`tunneling association on a first network device. The first
`network device is associated with the originating end of the
`tunneling association, and the request includes a unique
`identifier for the terminating end of the tunneling associa-
`tion. A trusted-third-party network device is informed of the
`request on a public network. Apublic network address for a
`second network device is associated with the unique iden-
`tifier for the terminating end of the tunneling association on
`the trusted-third-party network device. The second network
`device is associated with the terminating end of the tunnel-
`ing association. A first private network address on the first
`network device and a second private network address on the
`second network device are negotiated through the public
`network. The first private network address is assigned to the
`originating end of the tunneling association and the second
`private network address is assigned to the terminating end of
`the tunneling association.
`
`Petitioner RPX Corporation - Ex. 1009, p. 20
`
`Petitioner RPX Corporation - Ex. 1009, p. 20
`
`

`

`US 6,496,867 B1
`
`3
`the method and system of the present
`For example,
`invention may provide for the initiation of a Voice-over-
`Internet-Protocol association between an originating tele-
`phony device and a terminating telephony device. The
`method and system described herein may help ensure that
`the addresses of the ends of the tunneling association are
`hidden on the public network and may increase the security
`of communication without an increased computational bur-
`den.
`
`The foregoing and other features and advantages of
`preferred embodiments of the present invention will be more
`readily apparent from the following detailed description,
`which proceeds with references to the accompanying draw-
`1ngs.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`invention are
`Preferred embodiments of the present
`described with reference to the following drawings,
`wherein:
`
`FIG. 1 is a block diagram illustrating a network system;
`FIG. 2 is a block diagram illustrating a protocol stack for
`a network device;
`FIG. 3 is a block diagram illustrating the structure of an
`Internet Protocol packet;
`FIG. 4 is a flow diagram illustrating a method for initi-
`ating a tunneling association;
`FIG. 5 is a flow diagram illustrating a method for initi-
`ating a Voice-over-Internet-Protocol association;
`FIG. 6 is a block diagram illustrating the message flow of
`the method illustrated in FIG. 5;
`FIG. 7 is a flow diagram illustrating a method for nego-
`tiating private network addresses;
`FIG. 8 is a flow diagram illustrating a method for nego-
`tiating private Internet Protocol addresses;
`FIG. 9 is a block diagram illustrating the message flow of
`the method illustrated in FIG. 8;
`FIG. 10 is a flow diagram illustrating a method for
`negotiating private network addresses;
`FIG. 11 is a flow diagram illustrating a method for
`negotiating private Internet Protocol addresses;
`FIG. 12 is a block diagram illustrating the message flow
`of the method illustrated in FIG. 11;
`FIG. 13 is a flow diagram illustrating a method for
`negotiating private Internet Protocol addresses;
`FIG. 14 is a block diagram illustrating the message flow
`of the method illustrated in FIG. 13;
`FIG. 15 is a flow diagram illustrating a method for
`negotiating private Internet Protocol addresses;
`FIG. 16 is a block diagram illustrating the message flow
`of the method illustrated in FIG. 15; and
`FIG. 17 is a block diagram illustrating a configuration of
`network devices.
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENTS
`
`FIG. 1 is a block diagram illustrating an exemplary data
`network 10 for an illustrative embodiment of the present
`invention. The data network 10 includes a public network 12
`(e.g.
`the Internet or a campus network), a first network
`device 14, and a second network device 16. The public
`network 12 is public in the sense that it may be accessible
`by many users who may monitor communications on it.
`Additionally, there may be present multiple private networks
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`20. Also, a trusted-third-party network device 30 is con-
`nected to the public network 12. Data packets may be
`transferred to/from the first network device 14, the second
`network device 16, and the trusted-third-party network
`device 30 over the public network 12. For example, the three
`devices may be assigned public network addresses on the
`Internet. The first network device 14 and the second network
`device 16 may be modified routers or modified gateways.
`The trusted-third-party 30 may be a back-end service, a
`domain name server, or the owner/manager of database or
`directory services. Moreover,
`the trusted-third-party net-
`work device 30 may not be located in one physical location
`but may be distributed over several locations and the infor-
`mation may be replicated over the several
`locations.
`However, other data network types and network devices can
`also be used and the present invention is not limited to the
`data network an network devices described for an illustrative
`embodiment.
`
`In one exemplary preferred embodiment of the present
`invention,
`the first network device 14 and/or the second
`network device 16 is an edge router. An edge router routes
`data packets between one or more networks such as a
`backbone network (e.g. public network 12) and Local Area
`Networks (e.g. private network 20). Edge routers include
`those provided by 3Com Corporation of Santa Clara, Calif.,
`Lucent Technologies of Murray Hill, N.J., Livingston
`Enterprises, Inc. of Pleasanton, Calif., Ascend Communica-
`tions of Alameda, Calif., Cisco Systems of San Jose, Calif.,
`and others.
`
`In another exemplary preferred embodiment of the
`present invention, the first or second network device (14 or
`16) is a cable modem (“CM”) or cable modem termination
`system (“CMTS”). Cable modems and cable modem termi-
`nation systems offer customers higher-speed connectivity to
`the Internet, an intranet, Local Area Networks (“LANs”) and
`other computer networks via cable television networks. CMs
`and CMTSs include those provided by 3Com Corporation of
`Santa Clara, Calif., Motorola Corporation of Arlington
`Heights, 111., Hewlett-Packard Co. of Palo Alto, Calif., Bay
`Networks of Santa Clara, Calif., Scientific-Atlanta of
`Norcross, Ga., General Instruments of Horsham, Pa., and
`others.
`
`The data network also includes network devices (24, 26)
`that are originating and terminating ends of data flow. In
`another exemplary preferred embodiment of the present
`invention,
`these network devices (24, 26) are telephony
`devices or multimedia devices. Multimedia devices include
`
`Web-TV sets and decoders, interactive video-game players,
`or personal computers running multimedia applications.
`Telephony devices include VoIP devices (portable or
`stationary) or personal computers running facsimile or audio
`applications. However, the ends of the data flow may be
`other types of network devices and the present invention is
`not restricted to telephony or multimedia devices.
`Network devices and routers for preferred embodiments
`of the present invention include network devices that can
`interact with network system 10 based on standards pro-
`posed by the Institute of Electrical and Electronic Engineers
`(“IEEE”), International Telecommunications Union-
`Telecommunication Standardization Sector (“ITU”), Inter-
`net Engineering Task Force (“IETF”), or Wireless Applica-
`tion Protocol (“WAP”) Forum. However, network devices
`based on other standards could also be used. IEEE standards
`can be found on the World Wide Web at the Universal
`
`Resource Locator (“URL”) “www.ieee.org.” The ITU,
`(formerly known as the CCITT) standards can be found at
`the URL “www.itu.ch.” IETF standards can be found at the
`
`Petitioner RPX Corporation - Ex. 1009, p. 21
`
`Petitioner RPX Corporation - Ex. 1009, p. 21
`
`

`

`US 6,496,867 B1
`
`5
`URL “www.ietf.org.” The WAP standards can be found at
`the URL “www.wapforum.org.”
`It will be appreciated that the configuration and devices of
`FIG. 1 are for illustrative purposes only and the present
`invention is not restricted to network devices such as edge
`routers, cable modems, cable modem termination systems,
`domain name servers, and telephony or multimedia devices.
`Many other network devices are possible. Moreover,
`the
`configuration of data network 10 is not restricted to one
`public network 12 and one private network 20 as shown in
`FIG. 1. Many different configurations of the data network 10
`with multiple public networks and/or multiple private net-
`works at various positions in the data network 10 are
`possible.
`An operating environment for network devices and modi-
`fied routers of the present invention include a processing
`system with at least one high speed Central Processing Unit
`(“CPU”) and a memory. In accordance with the practices of
`persons skilled in the art of computer programming,
`the
`present invention is described below with reference to acts
`and symbolic representations of operations or instructions
`that are performed by the processing system, unless indi-
`cated otherwise. Such acts and operations or instructions are
`referred to as being “computer-executed” or “CPU
`executed.”
`
`It will be appreciated that acts and symbolically repre-
`sented operations or instructions include the manipulation of
`electrical signals or biological signals by the CPU. An
`electrical system or biological system represents data bits
`which cause a resulting transformation or reduction of the
`electrical signals or biological signals, and the maintenance
`of data bits at memory locations in a memory system to
`thereby reconfigure or otherwise alter the CPUs operation,
`as well as other processing of signals. The memory locations
`where data bits are maintained are physical locations that
`have particular electrical, magnetic, optical, or organic prop-
`erties corresponding to the data bits.
`The data bits may also be maintained on a computer
`readable medium including magnetic disks, optical disks,
`organic memory, and any other volatile (e.g., Random
`Access Memory (“RAM”)) or non-volatile (e.g., Read-Only
`Memory (“ROM”)) mass storage system readable by the
`CPU. The computer readable medium includes cooperating
`or interconnected computer readable medium, which exist
`exclusively on the processing system or be distributed
`among multiple interconnected processing systems that may
`be local or remote t