111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US007937581B2
`
`c12) United States Patent
`Vaarala et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,937,581 B2
`*May 3, 2011
`
`(54) METHOD AND NETWORK FOR ENSURING
`SECURE FORWARDING OF MESSAGES
`
`(75)
`
`Inventors: Sami Vaarala, Helsinki (FI); Antti
`Nuopponen, Espoo (FI)
`
`(73) Assignee: MPH Technologies 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 0 days.
`
`This patent is subject to a terminal dis(cid:173)
`claimer.
`
`(21) Appl. No.: 12/560,481
`
`(22) Filed:
`
`Sep.16,2009
`
`(65)
`
`Prior Publication Data
`
`US 2010/0049967 AI
`
`Feb. 25, 2010
`
`Related U.S. Application Data
`
`(63) Continuation of application No. 10/490,932, filed as
`application No. PCT/FI02/00770 on Sep. 27, 2002,
`now Pat. No. 7,620,810.
`
`(30)
`
`Foreign Application Priority Data
`
`Sep. 28, 2001
`
`(FI) ...................................... 20011910
`
`(51)
`
`Int. Cl.
`H04L 9100
`
`(2006.01)
`
`(52) U.S. Cl. ........ 713/153; 713/151; 713/161; 380/247;
`709/228; 370/401; 370/338; 455/436
`(58) Field of Classification Search ................... 713/161
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`6,170,057 B1*
`112001
`Inoueetal. ................... 713/153
`6,976,177 B2 * 12/2005 Ahonen ............................ 726/3
`* cited by examiner
`
`Primary Examiner- Nasser Moazzami
`Assistant Examiner- Fikremariam Yalew
`(74) Attorney, Agent, or Firm- Fasth Law Offices; Rolf
`Fasth
`
`ABSTRACT
`(57)
`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.
`
`9 Claims, 5 Drawing Sheets
`
`3
`
`2
`
`IPsec tunnel
`
`4
`
`Ex. 1001
`Apple v. MPH Techs. Oy
`IPR2019-00820
`
`0001
`
`

`

`U.S. Patent
`US. Patent
`
`May 3, 2011
`May 3, 2011
`
`Sheet 1 of5
`Sheet 1 of 5
`
`US 7,937,581 B2
`US 7,937,581 B2
`
`><
`
`N
`
`~
`•
`(!)
`LL
`
`FIG.1
`-
`
`Q)
`c:
`c:
`.....
`:::::!
`Q) en a..
`
`
`
`lPsectunnel
`
`(.)
`
`.......- - ! - -
`
`0002
`
`0002
`
`

`

`U.S. Patent
`US. Patent
`
`May 3, 2011
`May 3, 2011
`
`Sheet 2 of5
`Sheet 2 of 5
`
`US 7,937,581 B2
`US 7,937,581 B2
`
`><
`
`N -
`
`Q)
`c
`c
`::J
`.......
`()
`Q)
`
`(/) a..
`
`
`
`lPsectunnel
`
`N
`•
`(!)
`LL
`
`FIG.2
`-
`
`(
`
`\
`
`>-
`
`\
`
`)
`
`0003
`
`0003
`
`

`

`U.S. Patent
`US. Patent
`
`May 3, 2011
`May 3, 2011
`
`Sheet 3 of5
`Sheet 3 of 5
`
`US 7,937,581 B2
`US 7,937,581 B2
`
`N
`
`(])
`"C
`0
`E
`t::::
`0
`c..
`r.n
`c
`Cti
`I,...
`+-'
`
`IPsectransportmode
`
`
`
`
`
`(.)
`(])
`r.n
`0..
`
`M
`•
`C)
`LL
`
`FIG.3
`-
`
`0004
`
`0004
`
`

`

`U.S. Patent
`US. Patent
`
`May 3, 2011
`May 3, 2011
`
`Sheet 4 of5
`Sheet 4 of 5
`
`US 7,937,581 B2
`US 7,937,581 B2
`
`><
`HostX
`........
`(/)
`0
`I
`
`AddressB
`
`
`
`
`
`
`
`
`
`
`
`
`
`~
`
`
`
`
`
`
`
`.0 .0 .0 .0 .0 .0 .0 .0 .0
`2b
`8b 9b
`1b
`5b
`3b
`6b
`7b
`4b
`r--
`c.o
`T""" N
`LO
`CX) 0')
`("')
`""'"
`
`
`
`
`
`
`
`
`
`
`
`
`
`1
`
`
`
`
`
`
`
`<1:
`<(
`(/)
`rn
`rn
`rn
`rn
`rn
`rn
`rn
`rn
`rn
`33mmwmmwmmw
`(/) w
`r--
`c.o
`LO
`N
`("')
`CX)
`0')
`T"""
`ex-vamcoNooou
`""'"
`'-
`"o
`"'0
`'c
`"'0
`<(
`<1:
`
`V
`.
`•
`
`(!) -u.
`
`9 L
`
`I.
`
`I—
`1-
`0:
`0:::
`<(
`<1:
`0:::
`[I
`0
`g
`0:::
`E
`0...
`
`0005
`
`0005
`
`

`

`U.S. Patent
`U.S. Patent
`
`May 3, 2011
`May 3, 2011
`
`Sheet 5 015
`Sheet 5 of 5
`
`US 7,937,581 B2
`US 7,937,581 B2
`
`ll-
`
`~
`
`A"
`
`A"
`
`A
`
`><
`HostX
`+-' en
`0
`I
`
`CD
`m
`en
`a
`en
`Q)
`.03
`I....
`'o
`'"0
`‘0
`'"0
`<(
`<
`
`< a
`
`
`
`
`
`cum
`ro
`ro
`0
`Ow—x—x—
`'\"'"""
`'\"'"""
`'\"'"""
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`,
`
`<(
`en en
`ro
`ro
`ro
`ro
`ro
`ro
`ro
`ro
`ro
`wacucucucucvcucvmcu
`t--. co
`c.o
`N
`('f) ~ I.()
`(J)
`Q)
`'\"'"""
`gvmmvmcorxoocn
`,
`I....
`'0
`'"0
`'"0
`‘O__v____+__1___v_:____
`~
`<(
`<E
`
`•
`
`FIG.5
`(!) -LL
`
`0006
`
`0006
`
`

`

`US 7,937,581 B2
`
`1
`METHOD AND NETWORK FOR ENSURING
`SECURE FORWARDING OF MESSAGES
`
`PRIOR APPLICATIONS
`
`This is a continuation patent application that claims prior(cid:173)
`ity from U.S. patent application Ser. No. 10/490,932, filed 22
`Nov. 2004, now U.S. Pat. No. 7,620,810 that claims priority
`from PCT/FI02/00770, filed 27 Sep. 2002, that claims prior-
`ity from Finnish Patent Application No. 20011910, filed 28 10
`Sep. 2001.
`
`TECHNICAL FIELD
`
`2
`protection, limited traffic flow confidentiality, limited identity
`protection, and access control based on authenticated identi(cid:173)
`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
`(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
`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
`20 vehicles for access control based on the distribution of cryp(cid:173)
`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
`25 association is a one-way relationship between a sender and a
`receiver that offers security services to the traffic carried on it.
`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.
`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 bi-directional traffic protection. There is
`no implication of symmetry of the directions, i.e., the algo(cid:173)
`rithms and IPSec transforms used for each direction may be
`different.
`A security association is uniquely identified by three
`parameters. The first one, the Security Parameters Index
`(SPI), is a bit string assigned to this SA. The SPI is carried in
`AH and ESP headers to enable the receiving system to select
`the SA nnder 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(cid:173)
`ber field inAH or ESP headers. The Sequence Counter Over-
`flow is a flag indicating whether overflow of the sequence
`number counter should generate an auditable event and pre-
`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,
`
`The method and network of the invention is intended to 15
`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
`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 30
`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 35
`relatively small geographic area. It typically connects work(cid:173)
`stations, personal computers, printers and other devices. A
`wide area network (WAN) is a data communication network
`that covers a relatively broad geographic area. Wide area
`networks (WANs) interconnect LANs across normal tele- 40
`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 45
`a need for confidentiality (protecting the contents of data
`from being read), integrity (protecting the data from being
`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 50
`fresh, and not a copy of previously sent data), identity pro(cid:173)
`tection (keeping the identities of parties exchanging data
`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- 55
`viding most of these, but not all of them. (In particular, iden(cid:173)
`tity protection is not completely handled by IPSec, and nei(cid:173)
`ther is denial-of-service protection.)
`The IP security protocols (IPSec) provides the capability to
`secure communications between arbitrary hosts, e.g. across a 60
`LAN, across private and public wide area networks (WANs)
`and across the internet. IPSec can be used in different ways,
`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 65
`confidentiality and providing a key exchange mechanism.
`IPSec ensures confidentiality integrity, authentication, replay
`
`0007
`
`

`

`US 7,937,581 B2
`
`3
`keys, initialisation vectors, and related parameters being used
`with IPSec. The sixth parameter, Lifetime of this Security
`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 5
`occur. IPSec Protocol Mode is either tunnel or transport
`mode. Path MTU, which is an optional feature, defines the
`maximum size of a packet that can be transmitted without
`fragmentation.
`BothAH and ESP support two modes used, transport and 10
`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).
`Turmel mode provides protection to the entire IP packet
`and is generally used for sending messages through more than
`two components, although turmel mode may also be used for
`end-to-end communication between two hosts. Turmel 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 turmel 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 turmelled 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
`header. The entire original, or inner, packet travels through a
`tunnel from one point of an IP network to another: no routers 35
`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
`addresses, adding to the security. In other words, the first step
`in protecting the packet using tunnel mode is to add a new IP 40
`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
`"IPIESPIIPipayload". The whole inner packet is covered by
`the ESP and/or AH protection. AH also protects parts of the 45
`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
`address of another host on another network, the packet is
`routed from the originating host to a security gateway (SGW), 50
`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
`the first host to another host requires IPSec, the firewall per(cid:173)
`forms IPSec processing and encapsulates the packet in an 55
`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
`packet is now routed to the other host's firewall with inter(cid:173)
`mediate 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
`the entire inner IP packet, including the inner IP header. AH in
`tunnel mode authenticates the entire inner IP packet, includ(cid:173)
`ing the inner IP header, and selected portions of the outer IP
`header.
`
`4
`The key management portion of IPSec involves the deter(cid:173)
`mination and distribution of secret keys. The default auto(cid:173)
`mated key management protocol for IPSec is referred to as
`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(cid:173)
`rity, and replay protection for IP packets. However, IPSec is
`15 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
`constant. If IPSec is used with a mobile host, the IKE key
`20 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(cid:173)
`tions. Furthermore, the key exchange requires at least three
`25 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
`Radio Service (GPRS) regardless of the computational
`30 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 turmel 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
`60 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
`65 links with small throughput.
`The documents that define IP in general are the RFC stan(cid:173)
`dards RFC 768, RFC 791, RFC 793, RFC 826 andRFC 2460.
`
`0008
`
`

`

`5
`RFC 2002, RFC 2003, RFC 2131, RFC 3115, MOBILE Ipv4
`and IPv6, and DHCPV6 define Mobile IP, IP-IP and DHCP.
`
`REFERENCES
`
`US 7,937,581 B2
`
`6
`
`10
`
`[RFC2405]
`C. Madson, N. Doraswamy, The ESP DES-CBC Cipher
`Algorithm With Explicit IV, RFC 2405, November 1998.
`[RFC2406]
`5 S. Kent, and R. Atkinson, IP Encapsulating Security Payload
`(ESP), RFC 2406, November 1998.
`ftp :/ /ftp.isi.edu/in -notes/rfc2406 .txt
`[RFC2407]
`D. Piper, The internet IP Security Domain of Interpretation
`foriSAKMP, RFC 2407, November 1998.
`ftp :/ /ftp.isi.edu/in -notes/rfc2407 .txt
`[RFC2408]
`D. Maughan, M. Schneider, M. Schertler, andJ. Turner, Inter(cid:173)
`net Security Association and Key Management Protocol
`(ISAKMP), RFC 2408, November 1998.
`ftp :/ /ftp.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 -notes/rfc2409 .txt
`[RFC2410]
`R. Glenn, S. Kent, The NULL Encryption Algorithm and Its
`Use With IPsec, RFC 2410, November 1998.
`[RFC2411]
`25 R. Thayer, N. Doraswamy, R. Glenn, IP Security Document
`Roadmap, RFC 2411, November 1998.
`[RFC2412]
`H. Orman, The OAKLEY Key Determination Protocol, RFC
`2412, November 1998.
`30 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
`
`The following is a list of useful references of standards
`mentioned.
`IP in General, TCP and UDP:
`[RFC768]
`J. Postel, User Datagram Protocol, RFC 768, August 1980.
`ftp :/ /ftp.isi.edu/in-notes/rfc7 68 .txt
`[RFC791]
`J. Postel, Internet Protocol, RFC 791, September 1981.
`ftp:/ /ftp.isi.edu/in-notes/rfc791.txt
`[RFC792]
`J. Postel, Internet Control Message Protocol, RFC 792, Sep-
`tember 1981.
`ftp :/ /ftp.isi.edu/in-notes/rfc7 92 .txt
`[RFC793]
`J. Postel, Transmission Control Protocol, RFC 793, Septem- 20
`ber 1981.
`ftp :/ /ftp.isi.edu/in-notes/rfc7 93 .txt
`[RFC826]
`D. C. Plummer, An Ethernet Address Resolution 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.
`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, October 35
`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
`[RFC3115]
`G. Dommety, and K. Leung, Mobile IPVendor/Organization-
`specific Extensions, RFC 3115, April2001.
`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
`Configuration Protocol for IPv6 (DHCPv6), Work m
`progress (Internet-Draft is available), June 2001.
`IPsec Standards:
`[RFC2401]
`S. Kent, and R. Atkinson, Security Architecture for the Inter-
`net Protocol, RFC 2401, November 1998.
`ftp :/ /ftp.isi.edu/in-notes/rfc240 1. txt
`[RFC2402]
`S. Kent, and R. Atkinson, IP Authentication Header, RFC
`2402, November 1998.
`ftp :/ /ftp.isi.edu/in-notes/rfc2402. txt
`[RFC2403]
`C. Madson, R. Glenn, The Use of HMAC-MD5-96 within
`ESP andAH, RFC 2403, November 1998.
`[RFC2404]
`C. Madson, R. Glenn, The Use ofHMAC-SHA-1-96 within
`ESP andAH, RFC 2404, November 1998.
`
`15
`
`40
`
`45
`
`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
`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-
`50 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(cid:173)
`ing at least the addresses of the two terminals is established.
`55 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
`60 network to another. Such a terminal can physically be a
`mobile terminal or a fixed terminal.
`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
`65 be protected e.g. by IPSec encryption and/or authentication,
`possibly using the same IPSec SA that is used for traffic
`protection purposes.
`
`0009
`
`

`

`US 7,937,581 B2
`
`8
`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
`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
`10 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-
`15 net Protocol version. Its major disadvantage is the small num(cid:173)
`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-
`20 tion of packets is done, but these changes are quite small.
`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 modifications to protocols are quite
`25 small, and do not usually change the essentials of the proto(cid:173)
`cols 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
`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
`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- 30
`lished between addresses A and X tunnel can be changed by
`using the defined signalling to be between addresses Band 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 35
`overhead compared to Diffie-Hellman 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) 40
`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 new 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 50
`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 55
`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 60
`connections, or any combinations of these. In practice, it is
`useful to update either a single IPSec connection or a group of
`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
`
`45
`
`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, but naturally, the invention covers also such networks.
`sent in plaintext as the IPSec tunnel only exist between
`computers 1 and 2.
`The network of FIG. 3 is a network, wherein the IPSec
`65 messages are sent between an end-to-end connection between
`two computers 1, 2 only whereby IPSec transport mode can
`be used instead of tunnel mode.
`
`0010
`
`

`

`US 7,937,581 B2
`
`10
`9
`FIG. 4 describes the prior art solution to enable mobility for
`the address change. Both signals lOa and lla can be
`IPSec connections. As a diagram, this is the standard IPSec
`encrypted and/or authenticated. The encryption and/or
`authentication is preferably performed by using IPSec, in
`procedure when establishing a tunnel between addresses A
`and X, and then B and X.
`which case it is preferable to use the same IPSec SA for
`The protocol begins with the IKE main mode requiring 6
`protecting both data and registration traffic.
`messages in total, see steps la-6a in FIG. 4. The protocol
`lla is optional in the invention. The preferable encryption
`involves strong user authentication, policy negotiation and
`method is IPSec, preferably wit