`
`1111111111111111111111111111111111111111111111111111111111111
`US007620810B2
`
`c12) United States Patent
`Vaarala et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,620,810 B2
`Nov. 17, 2009
`
`(54) METHOD AND NETWORK FOR ENSURING
`SECURE FORWARDING OF MESSAGES
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`(75)
`
`Inventors: Sami Vaarala, Helsinki (FI); Antti
`Nuopponen, Espoo (FI)
`
`(73) Assignee: Mobility Patent Holding MPH Oy,
`Espoo (FI)
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 536 days.
`
`(21) Appl. No.:
`
`10/490,932
`
`(22) PCTFiled:
`
`Sep.27,2002
`
`(86) PCTNo.:
`
`PCT /FI02/00770
`
`§ 371 (c)(l),
`(2), ( 4) Date: Nov. 22, 2004
`
`(87) PCT Pub. No.: W003/030487
`
`PCT Pub. Date: Apr. 10, 2003
`
`(65)
`
`Prior Publication Data
`
`US 2005/0083947 Al
`
`Apr. 21, 2005
`
`(30)
`
`Foreign Application Priority Data
`
`Sep. 28, 2001
`
`(FI)
`
`.................................. 20011910
`
`(51)
`
`Int. Cl.
`H04L 9100
`(2006.01)
`(52) U.S. Cl. ....................... 713/161; 713/151; 380/247;
`455/432.1; 455/436; 370/401
`(58) Field of Classification Search ................. 713/161;
`380/247
`See application file for complete search history.
`
`6,170,057 B1 *
`6,418,130 B1 *
`6,587,680 B1 *
`6,839,338 B1 *
`6,839,770 B1
`6,904,466 B1 *
`6,976,177 B2 *
`7,146,428 B2 *
`7,174,018 B1*
`7,245,405 B2
`7,325,063 B2
`2002/0066036 A1 *
`
`Inoue eta!. ................. 713/153
`112001
`7/2002 Cheng eta!. ................ 370/331
`7/2003 Ala-Laurila eta!. ......... 455/411
`112005 Amara eta!.
`............... 370/338
`1/2005 Dillon
`6/2005 Ishiyarna et al ............. 709/245
`12/2005 Ahonen ......................... 726/3
`12/2006 Luo
`........................... 709/237
`2/2007 Patil eta!. ................... 380/258
`7/2007 Friedman
`1/2008 Dillon
`5/2002 Makineni eta!. ............ 713/201
`
`(Continued)
`
`OTHER PUBLICATIONS
`
`IBM, "IP Mobility Support," Memo: Oct. 1996.
`
`(Continued)
`
`Primary Examiner-Nasser G Moazzami
`Assistant Examiner-Fikremariam Yalew
`(7 4) Attorney, Agent, or Firm-Fasth Law Offices; RolfFasth
`
`(57)
`
`ABSTRACT
`
`The method and network ensure secure forwarding of ames(cid:173)
`sage in a telecommunication network that has at least one first
`terminal and another terminal. The first terminal moves from
`a first address to a second address. A secure connection
`between the first address of the first terminal and the other
`terminal defining at least the addresses of the two terminals is
`established. When the first terminal moves from the first
`address to a second address, the connection is changed to be
`between the second address and to the other terminal by
`means of a request from the first terminal and preferably a
`reply back to the first terminal.
`
`7 Claims, 5 Drawing Sheets
`
`3
`
`X
`
`1
`I
`
`2
`
`IPsec tunnel
`
`Ex. 1019
`Apple v. MPH Techs. Oy
`IPR2019-00820
`
`0001
`
`
`
`US 7,620,810 B2
`Page 2
`
`U.S. PATENT DOCUMENTS
`2003/0166397 A1 * 9/2003 Aura .......................... 455/410
`OTHER PUBLICATIONS
`
`The Internet Society, "Securing L2TP using IPsec," Memo: Nov.
`2001.
`
`The Internet Society, "IP Mobility Support for IPv4," Memo: Aug.
`2002.
`The Internet Society, "Layer Two Tunneling Protocol-Version 3
`(L2TPv3)," Memo: Mar. 2005.
`* cited by examiner
`
`0002
`
`
`
`U.S. Patent
`U.S. Patent
`
`Nov. 17,2009
`Nov.17, 2009
`
`Sheet 1 of 5
`Sheet 1 of 5
`
`US 7,620,810 B2
`US 7,620,810 B2
`
`~
`•
`(!)
`u.
`
`FIG.1
`-
`
`,,..----,
`
`><
`
`\
`
`
`
`Q)
`c::
`oO
`c::
`Cc
`Cc
`——o_é
`Q) en
`oO
`a..
`a
`ou
`
`:J -0
`
`@“
`
`~-t--
`
`0003
`
`0003
`
`
`
`U.S. Patent
`U.S. Patent
`
`Nov. 17, 2009
`Nov. 17,2009
`
`Sheet 2 of 5
`Sheet 2 of 5
`
`US 7,620,810 B2
`US 7,620,810 B2
`
`N
`GN
`•
`C)
`O
`LL
`i
`
`-
`
`=a
`
`'
`
`+
`
`)
`
`>-
`>
`
`(
`
`'
`
`0004
`
`~ -0
`
`B
`15
`c
`Cc
`c
`5
`CD
`VJ a..
`
`o®o a
`
`\
`(
`Cc
`
`X
`x<
`
`+0]
`
`\.
`|
`
`N
`
`—
`
`0004
`
`
`
`U.S. Patent
`U.S. Patent
`
`Nov. 17,2009
`Novy. 17, 2009
`
`Sheet 3 of 5
`Sheet 3 of 5
`
`US 7,620,810 B2
`US 7,620,810 B2
`
`iPsectransportmode
`
`Q)
`~
`0
`E
`'t:=
`0
`0.
`(I) c:
`..,
`~
`0
`Q) en
`D.
`
`
`
`
`
`FIG.3
`~
`•
`-
`CJ
`LL
`
`0005
`
`0005
`
`
`
`U.S. Patent
`U.S. Patent
`
`Nov. 17,2009
`Novy. 17, 2009
`
`Sheet 4 of 5
`Sheet 4 of 5
`
`US 7,620,810 B2
`US 7,620,810 B2
`
`>< -(/)
`
`0
`:t:
`
`AddressBHostX
`
`co
`
`(/)
`(/)
`~
`"0
`"0
`<(
`
`•r.
`
`I"
`
`•r.
`
`~
`
`·~
`
`'I"
`
`·~
`
`·~
`
`..
`
`~
`
`| | | |
`
`.0 .c .c .c .0 .c .c .0 .c
`....- N
`"'';t LO <0 "" (X)
`0'>
`(")
`-
`~
`
`dr
`
`1
`
`cu
`N
`
`cu
`(")
`
`cu
`....-
`
`AddressA 1a
`
`PRIORART
`
`~
`<(
`a::
`0
`a:: a.
`
`cu
`
`cu
`
`cu
`
`cu
`
`cu
`0)
`
`cu
`"'';t LO <0 "" (X)
`7a
`,r
`
`~,
`
`FIG.4
`• " -LL
`
`0006
`
`0006
`
`
`
`U.S. Patent
`U.S. Patent
`
`Nov. 17, 2009
`Nov. 17, 2009
`
`Sheet 5 of 5
`Sheet 5 of 5
`
`US 7,620,810 B2
`US 7,620,810 B2
`
`~~
`
`·~
`
`~~
`
`'"'
`
`' ~ ·~
`
`co
`co
`...-,,
`| 2©
`...-
`0
`...-
`TT Ee
`
`>< -en
`
`n
`“”
`0
`Oo
`:I:
`<x
`
`xo
`
`2
`
`”
`
`©3<
`
`x
`
`co
`
`N ,.
`
`co
`co
`co
`co
`co
`co
`co
`,...... 00 0)
`('t') ~ It) co
`©
`,,
`,,
`wv
`S
`,r
`
`<”
`
`co
`...-
`oO
`S-
`fas
`
`3<
`
`•
`
`FIG.5
`(!) -u.
`
`0007
`
`0007
`
`
`
`US 7,620,810 B2
`
`1
`METHOD AND NETWORK FOR ENSURING
`SECURE FORWARDING OF MESSAGES
`
`PRIOR APPLICATIONS
`
`This is a US national phase patent application that claims
`priority from PCT/FI02/00770, filed 27 Sep. 2002, that
`claims priority from Finnish Patent Application No.
`20011910, filed 28 Sep. 2001.
`
`TECHNICAL FIELD
`
`2
`ties. Even if some applications already have built in security
`protocols, the use of IPSec further enhances the security.
`IPSec can encrypt and/or authenticate traffic at IP level.
`Traffic going in to a WAN is typically compressed and
`encrypted and traffic coming from a WAN is decrypted and
`decompressed. IPSec is defined by certain documents, which
`contain rules for the IPSec architecture. The documents that
`define IPSec, are, for the time being, the Request For Com(cid:173)
`ments (RFC) series of the Internet Engineering Task Force
`10 (IETF), in particular, RFCs 2401-2412.
`Two protocols are used to provide security at the IP layer;
`an authentication protocol designated by the header of the
`protocol, Authentication Header (AH), and a combined
`encryption/authentication protocol designated by the format
`15 of the packet for that protocol, Encapsulating Security Pay(cid:173)
`load (ESP). AH and ESP are however similar protocols, both
`operating by adding a protocol header. Both AH and ESP are
`vehicles for access control based on the distribution of cryp-
`tographic keys and the management of traffic flows related to
`these security protocols.
`Security association (SA) is a key concept in the authenti(cid:173)
`cation and the confidentiality mechanisms for IP. A security
`association is a one-way relationship between a sender and a
`receiver that offers security services to the traffic carried on it
`25 if a secure two way relationship is needed, then two security
`associations are required. If ESP andAH are combined, or if
`ESP and/or AH are applied more than once, the term SA
`bundle is used, meaning that two or more SAs are used. Thus,
`SA bundle refers to one or more SAs applied in sequence, e.g.
`30 by first performing an ESP protection, and then an AH pro(cid:173)
`tection. The SA bundle is the combination of all SAs used to
`secure a packet.
`The term IPsec connection is used in what follows in place
`of an IPSec bundle of one or more security associations, or a
`pair ofiPSec bundles-one bundle for each direction--of one
`or more security associations. This term thus covers both
`unidirectional and bidirectional traffic protection. There is no
`implication of symmetry of the directions, i.e., the algorithms
`and IPSec transforms used for each direction may be differ-
`40 ent.
`A security association is uniquely identified by three
`parameters. The first one, the Security Parameters Index
`(SPI), is a bit string assigned to this St The SPI is carried inAH
`and ESP headers to enable the receiving system to select the
`SA under which a received packet will be processed. IP
`destination address is the second parameter, which is the
`address of the destination end point of the SA, which may be
`an end user system or a network system such as a firewall or
`a router. The third parameter, the security protocol identifier
`indicates whether the association is an AH or ESP security
`association.
`In each IPSec implementation, there is a nominal security
`association data base (SADB) that defines the parameters
`associated with each SA. A security association is normally
`defined by the following parameters. The Sequence Number
`Counter is a 32-bit value used to generate the sequence num-
`ber field inAH or ESP-headers. The Sequence Counter Over(cid:173)
`flow is a flag indicating whether overflow of the sequence
`number counter should generate an auditable event and pre(cid:173)
`vent further transmission of packets on this SA. An Anti(cid:173)
`Replay Window is used to determine whether an inboundAH
`or ESP packet is a replay. AH information involves informa(cid:173)
`tion about the authentication algorithm, keys and related
`parameters being used with AH. ESP information involves
`information of encryption and authentication algorithms,
`keys, initialisation vectors, and related parameters being used
`with IPSec. The sixth parameter, Lifetime of this Security
`
`The method and network of the invention is intended to
`secure mobile connections in telecommunication networks.
`Especially, it is meant for IPSec connections.
`The invention provides a method for ensuring secure for(cid:173)
`warding of a message in a telecommunication network com(cid:173)
`prising at least one mobile terminal and another terminal,
`when the mobile terminal moves from a first address to a
`second address and there is a secure connection established 20
`between the first address of the mobile terminal and the other
`terminal, which secure connection defines at least the
`addresses of the two terminals. The invention also provides a
`network for performing such a method.
`
`TECHNICAL BACKGROUND
`
`An internetwork is a collection of individual networks
`connected with intermediate networking devices and func(cid:173)
`tions as a single large network. Different networks can be
`interconnected by routers and other networking devices to
`create an internetwork.
`A local area network (LAN) is a data network that covers a
`relatively small geographic area. It typically connects work(cid:173)
`stations, personal computers, printers and other devices A 35
`wide area network (WAN) is a data communication network
`that covers a relatively broad geographic area. Wide area
`networks (WANs) interconnect U-Ns across normal tele(cid:173)
`phone lines and, for instance, optical networks; thereby inter(cid:173)
`connecting geographically disposed users.
`There is a need to protect data and resources from disclo(cid:173)
`sure, to guarantee the authenticity of data, and to protect
`systems from network based attacks. More in detail, there is
`a need for confidentiality (protecting the contents of data
`from being read), integrity (protecting the data from being 45
`modified, which is a property that is independent of confiden(cid:173)
`tiality), authentication (obtaining assurance about the actual
`sender of data), replay protection (guaranteeing that data is
`fresh, and not a copy of previously sent data), identity pro(cid:173)
`tection (keeping the identities of parties exchanging data 50
`secret from outsiders), high availability, i.e. denial-of-service
`protection (ensuring that the system functions even when
`under attack) and access control. IPSec is a technology pro(cid:173)
`viding most of these, but not all of them. (In particular, iden(cid:173)
`tity protection is not completely handled by IPSec, and nei- 55
`ther is denial-of-service protection.)
`The IP security protocols (IPSec) provides the capability to
`secure communications between arbitrary hosts, e.g. across a
`LAN, across private and public wide area networks (WANs)
`and across the internet IPSec can be used in different ways, 60
`such as for building secure virtual private networks, to gain a
`secure access to a company network, or to secure communi(cid:173)
`cation with other organisations, ensuring authentication and
`confidentiality and providing a key exchange mechanism.
`IPSec ensures confidentiality integrity, authentication, replay 65
`protection, limited traffic flow confidentiality, limited identity
`protection, and access control based on authenticated identi-
`
`0008
`
`
`
`US 7,620,810 B2
`
`3
`Association, is a time-interval and/or byte-count after which
`a SA must be replaced with a new SA (and: new SPI) or
`terminated plus an indication of which of these actions should
`occur. IPSec Protocol Mode is either tunnel or transport
`mode. Path MTU, which is an optional feature, defines the 5
`maximum size of a packet that can be transmitted without
`fragmentation.
`Both AH and ESP support two modes used, transport and
`tunnel mode.
`Transport mode provides protection primarily for upper
`layer protocols and extends to the payload of an IP packet.
`Typically, transport mode is used for end-to-end communi(cid:173)
`cation between two hosts. Transport mode may be used in
`conjunction with a tunnelling protocol (other that IPSec tun(cid:173)
`nelling).
`Tunnel mode provides protection to the entire IP packet
`and is generally used for sending messages through more than
`two components, although tunnel mode may also be used for
`end-to-end communication between two hosts. Tunnel mode
`is often used when one or both ends of a SA is a security
`gateway, such as a firewall or a router that implements IPSec.
`With tunnel mode, a number of hosts on networks behind
`firewalls may engage in secure communications without
`implementing IPSec. The unprotected packets generated by
`such hosts are tunnelled through external networks by tunnel
`mode SAs set up by the IPSec software in the firewall or
`secure router at boundary of the local network.
`To achieve this, after the AH or ESP fields are added to the
`IP packet, the entire packet plus security fields are treated as
`the payload of a new outer IP packet with a new outer IP 30
`header. The entire original, or inner, packet travels through a
`tunnel from one point of an IP network to another no routers
`along the way are able to examine the inner IP packet.
`Because the original packet is encapsulated, the new larger
`packet may have totally different source and destination 35
`addresses, adding to the security. In other words, the first step
`in protecting the packet using tunnel mode is to add a new IP
`header to the packet; thus the "IPipayload" packet becomes
`"IPIIPipayload". The next step is to secure the packet using
`ESP and/or AH. In case of ESP, the resulting packet is 40
`"IPIESPIIPipayload". The whole inner packet is covered by
`the ESP and/or AH protection. AH also protects parts of the
`outer header, in addition to the whole inner packet.
`The IPSec tunnel mode operates e.g. in such a way that if a
`host on a network generates an IP packet with a destination 45
`address of another host on another network, the packet is
`routed from the originating host to a security gateway (SGW),
`firewall or other secure router at the boundary of the first
`network. The SGW or the like filters all outgoing packets to
`determine the need for IPSec processing. If this packet from 50
`the first host to another host requires IPSec, the firewall per(cid:173)
`forms IPSec processing and encapsulates the packet in an
`outer IP header. The source IP address of this outer IP header
`is this firewall and the destination address may be a firewall
`that forms the boundary to the other local network. This 55
`packet is now routed to the other hosts firewall with interme(cid:173)
`diate routers examining only the outer IP header. At the other
`host firewall, the outer IP header is stripped off and the inner
`packet is delivered to the other host.
`ESP in tunnel mode encrypts and optionally authenticates 60
`the entire inner IP packet, including the inner IP header. AH in
`tunnel mode authenticates the entire inner IP packet including
`the inner IP header, and selected portions of the outer IP
`header.
`The key management portion ofiPSec involves the deter- 65
`mination and distribution of secret keys. The default auto(cid:173)
`mated key management protocol for IPSec is referred to as
`
`4
`ISAKMP/Oakley and consists of the Oakley key determina(cid:173)
`tion protocol and Internet Security Association and Key Man(cid:173)
`agement Protocol (ISAKMP). Internet key exchange (IKE) is
`a newername for the ISAKMP/Oakley protocol. IKE is based
`on the Diffie-Hellman algorithm and supports RSA signature
`authentication among other modes. IKE is an extensible pro(cid:173)
`tocol, and allows future and vendor-specific features to be
`added without compromising functionality.
`IPSec has been designed to provide confidentiality, integ-
`10 rity, and replay protection for IP packets. However, IPSec is
`intended to work with static network topology, where hosts
`are fixed to certain subnetworks. For instance, when an IPSec
`tunnel has been formed by using Internet Key Exchange
`(IKE) protocol, the tunnel endpoints are fixed and remain
`15 constant If IPSec is used with a mobile host the IKE key
`exchange will have to be redone from every new visited
`network. This is problematic, because IKE key exchanges
`involve computationally expensive Diffie-Hellman key
`exchange algorithm calculations and possibly RSA calcula-
`20 tions. Furthermore, the key exchange requires at least three
`round trips (six messages) if using the IKE aggressive mode
`followed, by IKE quick mode, and nine messages if using
`IKE main mode followed by IKE quick mode. This may be a
`big problem in high latency networks, such as General Packet
`25 Radio Service (GPRS) regardless of the computational
`expenses.
`In this text, the term mobility and mobile terminal does not
`only mean physical mobility, instead the term mobility is in
`the first hand meant moving from one network to another,
`which can be performed by a physically fixed terminal as
`well.
`The problem with standard IPSec tunnel end points are that
`they are fixed. A SA is bound to a certain IP address, and if it
`is changed, the existing IPSec SA becomes useless because it
`has been established by using different endpoint addresses.
`The problem has been discussed in the IETF standardisation
`forum, www.IETF.org, wherein an idea to support mobility
`for IPSec ESP tunnels by means of signalling to update the
`address of one end after a movement was mentioned by Fran(cid:173)
`cis Dupont. No solutions have however been presented until
`this date.
`The standard Mobile IP protocol provides a mobile termi(cid:173)
`nal with a mobile connection, and defines mechanisms for
`performing efficient handovers from one network to another.
`However, Mobile IP has several disadvantages. The security
`of Mobile IP is very limited. The mobility signalling mes(cid:173)
`sages are authenticated, but not encrypted, and user data
`traffic is completely unprotected. Also, there is no key,
`exchange mechanism for establishing the cryptographic keys
`required for authenticating the mobility signalling. Such keys
`need to be typically distributed manually. Finally, the current
`Mobile IP protocol does not define a method for working
`through Network Address Translation (NAT) devices.
`A way to solve this problem is to use e.g. Mobile IP to
`handle the mobility of the host, and use IPSec on top of the
`static IP address provided by the Mobile IP. Thus, the IPSec
`SAs are bound to static addresses, and the IPSec SAs can
`survive mobility of the host. However, this approach suffers
`from packet size overhead of both Mobile IP and IPSec tun(cid:173)
`nels, which can affect performance considerably when using
`links with small throughput.
`The documents that define IP in general are the RFC stan(cid:173)
`dards RFC 768, RFC 791, RFC 7933, RFC 826 and RFC
`2460. RFC2002, RFC2003, RFC 2131, RFC 3115, MOBILE
`Ipv4 and IPv6, and DHCPV6 define Mobile IP, IP-IP and
`DHCP.
`
`0009
`
`
`
`US 7,620,810 B2
`
`5
`Prior art solutions in this technical area are presented in
`wo 01 39538, wo 00 41427, wo 01 24560, us 2001/
`009025 and EP 1 24 397.
`In W00139538, W00041427, W00124560andEP 124
`397, a secure connection, which in the two first emntioned 5
`ones is an IPSec SA connection, is transferred from one
`access point to another in a hand-over situation of a mobile
`terminal. US 2001/009025 generally presents a secure com(cid:173)
`munication method by means of an IP Sec SA connection.
`
`REFERENCES
`
`The following is a list of useful references of standards
`mentioned.
`IP in general, TCP and UDP:
`[RFC768]
`J. Postel, User Datagram Protocol, RFC 7 68, August 1980.
`ftp:/ /ftp.isi.edu/in -notes/rfc7 688 .txt
`[RFC791]
`J. Postel, Internet Protocol, RFC 791, September 1981. 20
`ftp:/ /ftp.isi.edu/in-notes/rfc791.text
`[RFC792]
`J. Postel, Internet Control Message Protocol, RFC 792,
`September 1981. ftp://ftp.isi.edu/in-notes/rfc792.txt
`[RFC793]
`J. Postel, Transmission Control Protocol, RFC 793, Sep(cid:173)
`tember 1981. ftp://ftp.isi.edu/in-notes/rfc793.txt
`[RFC826]
`D. C. Plummer, An Ethernet Address Resoluffon Protocol,
`RFC 826, November 1982. ftp://ftp.isi.edu/in-notes/
`rfc826.txt
`[RFC2460]
`S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6)
`Specification, RFC 2460, December 1998.
`
`15
`
`25
`
`6
`C. Madson, R. Glenn, The Use ofHMAC-MD596 within
`ESP andAH, RFC 2403, November 1998.
`[RFC2404]
`C. Madson, R. Glenn, The Use ofHMAC-SHA-1-96 win
`ESP andAH, RFC 2404, November 1998.
`[RFC2405]
`C. Madson, N. Doraswamy, The ESP DES-CBC Cipher
`Algorithm With Explicit IV, RFC 2405, November
`1998.
`10 [RFC2406]
`S. Kent, and R. Atkinson, IP Encapsulating Security Pay(cid:173)
`load (ESP), RFC 2406, November 1998. ftp://ft(cid:173)
`p.isi.edu/in-notes/rfc2406.txt
`[RFC2407]
`D. Piper, The internet IP Security Domain ofinterpretation
`for ISAKMP, RFC 2407, November 1998. ftp://ft(cid:173)
`p.isi.edu/in-notes/rfc2407.txt
`[RFC2408]
`D. Maughan, M. Schneider, M. Scheater, and J. Turner,
`Internet Security Association and Key Management Pro(cid:173)
`tocol (ISAKMP), RFC 2408, November 1998. ftp://ft(cid:173)
`p.isi.edu/in-notes/rfc2408.txt
`[RFC2409]
`D. Harkins, and D. Carrel, The Internet Key Exchange
`(IKE), RFC 2409, November 1998. ftp://ftp.isi.edu/in(cid:173)
`notes/rfc2409 .txt
`[RFC2410]
`R. Glenn, S. Kent, The NULL Encryption Algorithm and Its
`Use With IPsec, RFC 2410, November 1998.
`30 [RFC2411]
`R. Thayer, N. Doraswamy, R. Glenn, IP Security Docu(cid:173)
`ment Roadmap, RFC 2411, November 1998.
`[RFC2412]
`H. Orman, The OAKLEY Key Determination Protocol,
`RFC 2412, November 1998.
`NAT:
`[RFC2694]
`P. Srisuresh, G. Tsirtsis, P. Akkiraju, and A Heffernan, DNS
`Extensions to Network Address Translators (DNS_
`ALG), RFC 2694, September 1999.
`[RFC3022]
`P. Shisuresh, K. Egevang, Traditional IP Network Address
`Translator (Traditional NAT), RFC 3022, January 2001
`ftp:/ /ftp .isi .edu/in -notes/rfc3022 .txt
`
`35
`
`Mobile IP; IP-IP; DHCP:
`[RFC2002]
`C. Perkins, IP Mobility Support, RFC 2002, October 1996.
`ftp:/ /ftp.isi.edu/in -notes/rfc2002 .txt
`[RFC2003]
`C. Perkins, IP Encapsulation Within IP, RFC 2003, Octo(cid:173)
`ber 1996. ftp://ftp.isi.edu/in-notes/rfc2003.txt
`[RFC2131]
`R. Drams, Dynamic Host Configuration Protocol, RFC
`2131, March 1997. ftp://ftp.isi.edu/in-notes/rfc2131.txt 45
`[RFC3115]
`G. Dommety, and K. Leung, Mobile IP Vendor/Organiza(cid:173)
`tion-specific Extensions, RFC 3115, April 2001. ftp://
`ftp.isi.edu/in-notes/rfc3115.txt
`[MOBILEIPv6]
`D. B. Johnson, C. Perkins, Mobility Support in IPv6, Work
`in progress (Internet-Draft is available), July 2000.
`[DHCPV6]
`J. Bound, M. Carney, C. Perking, R. Drams, Dynamic Host 55
`Configuration Protocol for IPv6 (DHCPv6), Work in
`progress (Internet-Draft is available), June 2001.
`IPsec Standards:
`[RFC2401]
`S. Kent, and R. Atkinson, Security Architecture for the
`Internet Protocol, RFC 2401, November 1998. ftp://ft(cid:173)
`p.isi.edu/in-notes/rfc2401.txt
`[RFC2402]
`S. Kent, and R. Atkinson, IP Authentication Header, RFC
`2402, November.
`1998.
`ftp://ftp.isi.edu/in-notes/ 65
`rfc2402.txt
`[RFC2403]
`
`40
`
`THE OBJECT OF THE INVENTION
`
`The object of the invention is to ensure secure forwarding
`of messages from and to mobile terminals by avoiding the
`50 problems of prior art.
`
`SUMMARY OF THE INVENTION
`
`The method and network of the invention is to ensure
`secure forwarding of a message in a telecommunication net(cid:173)
`work, comprising at least one first terminal and another ter(cid:173)
`minal. In the method, the first terminal moves from a first
`address to a second address. A secure connection between the
`first address of the first terminal and the other terminal defin-
`60 ing at least the addresses of the two terminals is established.
`The first terminal moves from the first address to a second
`address. The connection is changed to be between the second
`address and the other terminal by means of a request from the
`first terminal and preferably, a reply back to the first terminal.
`In the invention, the first terminal is movable from one
`network to another. Such a terminal can physically be a
`mobile terminal or a fixed terminal.
`
`0010
`
`
`
`US 7,620,810 B2
`
`8
`IPSec connections. The latter may be important if separate
`IPSec connections are used for different kinds of traffic. A
`single request message can then update all (or a certain set) of
`such connections to a new address, instead of requiring sepa(cid:173)
`rate requests for each IPSec connection. In the following, the
`case of updating a single IPSec connection is discussed, with(cid:173)
`out limiting the invention to this behaviour.
`Another method of performing the signalling is to use a
`separate protocol. The protocol should preferably provide
`10 encryption and/or authentication of the signalling messages.
`The IKE protocol already has messages defined for e.g. delet(cid:173)
`ing IPSec SAs. One method of providing the necessary sig(cid:173)
`nalling would be by adding a new IKE notification message
`type that requests a change in an existing IPSec SA Such a
`15 message should provide its own encryption and/or authenti(cid:173)
`cation to avoid requiring an IKE connection set up from the
`new address, which would require extra messaging.
`IP version 4 (IPv4) is the currently widely deployed Inter(cid:173)
`net Protocol version. Its major disadvantage is the small num-
`20 ber of unique, public IP addresses. IP version 6 (IPv6) has a
`much larger address space, which fixes the most important
`IPv4 problem known today. IPv6 also changes some other
`things in the Internet Protocol, for example, how fragmenta(cid:173)
`tion of packets is done, but these changes are quite small.
`25 Most protocols have separate definitions on how they are used
`within the IPv4 and the IPv6 context.
`For instance, there are separate versions of IPSec and
`Mobile IP for use with IPv4 and IPv6. However, such modi(cid:173)
`fications to protocols are quite small, and do not usually
`change the essentials of the protocols significantly. The
`invention can be applied to both IPv4 and IPv6.
`In the following, the invention is further described by
`means of figures and some examples. The intention is not to
`restrict the invention to the details of the following descrip(cid:173)
`tion or to the details of protocols such as the IPSec and IKE
`protocols which might be changed in the future.
`
`7
`The secure connection is an IPSec connection established
`by forming one or more Security Associations (SAs) using
`the IPSec protocols. The request and/or the reply message can
`be protected e.g. by IPSec encryption and/or authentication,
`possibly using the same IPSec SA that is used for traffic
`protection purposes.
`In general, registration request and registration reply are
`Mobile IP terms while the invention is not bound to Mobile IP.
`In the invention, the terms request and reply are used in the
`generic sense, and may or may not be related to Mobile IP.
`The method of the invention can be used in different kinds
`of networks. If the first terminal and the other terminal form
`an end-to-end connection, the secure connection may be an
`IPSec tunnel mode or transport mode connection. Further(cid:173)
`more, one of or both of the first terminal and the other terminal
`can be a security gateway protecting one or more computers,
`whereby IPSec tunnel mode, or IPSec transport mode
`together with a tunnelling protocol (such as Layer 2 Tunnel(cid:173)
`ling Protocol, L2TP), is used for the secure connection
`between the first terminal and the other terminal.
`If both terminals are mobile, a special solution is required
`for the situation when both terminals move simultaneously in
`case of a so called "double jump" situation. This solution can
`be implemented e.g. by using a centralised registry of current
`locations ofhosts, although other solutions exist for the prob(cid:173)
`lem. However, the "changeable" IPSec tunnel or transport
`mode SAs of the invention could be used in that case, too.
`The applicant has solved the above problems of prior art by
`defining a signalling mechanism that allows an existing IPSec
`security association, that is, the symmetric encryption and 30
`authentication algorithms used for packet processing, along
`with their keys and other parameters, to be moved from one
`network to another. To be more precise, an existing IPSec
`tunnel endpoint can be moved in the invention from one point
`of attachment to another. For instance, an IPSec tunnel estab- 35
`lished between addresses A and X tunnel can be changed by
`using the defined signalling to be between addresses B and X
`using only a single round trip for signalling (2 messages), or
`half a round trip (1 message, if a reply message is not used) for
`signalling. The solution requires minimal computational 40
`overhead compared to Diffie-Helman or strong authentica(cid:173)
`tion calculations.
`The signalling mechanism is preferably similar to the one
`in Mobile IP, i.e. a registration request (RREQ) is sent to the
`other end of the SA followed by a registration reply (RREP) 45
`back to the sender of the RREQ message, both of which are
`extensible for future features and optional attributes. The
`RREQ/RREP message pair is sent from the new network, and
`once properly authenticated, the sender IPSec tunnel end(cid:173)
`point is updated from the old network to the now network.
`In case the security association used for protecting user
`traffic is also used for signalling purposes, the reception of the
`RREQ message by the other end of the SA requires a change
`in a normal IPSec implementation to accept a packet that
`appears to belong to a certain IPSec tunnel, but comes from a 55
`wrong address (i.e. the tunnel is currently between A and X,
`and the RREQ comes from address B). This is only necessary
`for the RREQ message. Such an implementation is provided
`by the invention; it is necessary to modify IPSec if IPSec is
`used for the RREQ/RREP signalling. In that case, it is 60
`required specifically for processing of the RREQ and RREP
`messages, if the reply message is to be used.
`The request message may update a set of security associa(cid:173)
`tions, for instance, a single security association, a security
`association bundle, an IPSec connection, a group of IPSec 65
`connections, or any combinations of these. In practice, it is
`useful to update either a single IPSec connection or a group of
`
`50
`
`FIGURES
`
`FIG. 1 illustrates an example of a telecommunication net(cid:173)
`work to be used in the invention.
`FIG. 2 illustrates a second example of a telecommunication
`network to be used in the invention.
`FIG. 3 illustrates a third example of a telecommunication
`network to be used in the invention.
`FIG. 4 describes the prior art solution to enable mobility for
`IPSec connections.
`FIG. 5 describes the method of the invention to enable
`mobility for IPSec connections.
`
`DETAILED DESCRIPTION
`
`FIG. 1 illustrates an example of a telecommunication net(cid:173)
`work to be used in the invention. Thus, in FIG. 1, computer 1
`may be a client computer and computer 2 a destination com(cid:173)
`puter, to which the secure messages are sent in the invention
`by means of an IPSec tunnel established between computer 1
`and computer 2. Computer 2 might be a security gateway for
`a third computer 3. Then, the messages sent from computer 2
`to computer 3 are sent in plaintext. The security gateway can
`be a common security gateway for e.g. a company LAN,
`whereby there are several computers in the LAN protected by
`computer 2. The other protected computers are not shown in
`FIG. 1, bu