111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US008037302B2
`
`(12) United States Patent
`Vaarala et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,037,302 B2
`Oct. 11, 2011
`
`(54) METHOD AND SYSTEM FOR ENSURING
`SECURE FORWARDING OF MESSAGES
`
`(75)
`
`Inventors: Sami Vaarala, Helsinki (FI); Antti
`Nuopponen, Espoo (FI); Panu
`Pietikainen, Espoo (FI)
`
`(73) Assignee: Mobility Patent Holding MPH Oy (FI)
`
`( *) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 927 days.
`
`(21) Appl. No.:
`
`10/490,933
`
`(22) PCTFiled:
`
`Sep.27,2002
`
`(86) PCT No.:
`
`PCT /FI02/00771
`
`§ 371 (c)(l),
`(2), ( 4) Date: Apr. 18, 2005
`
`(87) PCT Pub. No.: W003/030488
`
`PCT Pub. Date: Apr. 10, 2003
`
`(65)
`
`Prior Publication Data
`
`US 2005/0177722 AI
`
`Aug. 11, 2005
`
`(30)
`
`Foreign Application Priority Data
`
`Sep. 28, 2001
`
`(FI) ...................................... 20011911
`
`(51)
`
`Int. Cl.
`H04L 9100
`H04L29/06
`
`(2006.01)
`(2006.01)
`
`(52) U.S. Cl. ......................... 713/160; 713/162; 713/168
`(58) Field of Classification Search .................. 713/160,
`713/162, 151, 171
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`6,091,951 A * 7/2000 Sturniolo eta!. .......... 455/432.2
`6,452,915 B1 * 9/2002 Jorgensen ..................... 370/338
`6,587,680 B1 * 7/2003 Ala-Laurila eta!. .......... 455/411
`7,143,282 B2 * 1112006 Takagi eta!. ................. 713/153
`* cited by examiner
`
`Primary Examiner- Gilberta Barron, Jr.
`Assistant Examiner- Devin Almeida
`(74) Attorney, Agent, or Firm- Fasth Law Offices; Rolf
`Fasth
`
`ABSTRACT
`(57)
`The method is for ensuring secure forwarding of a message is
`performed in a telecommunication network that has at least
`one terminal from which the message is sent and at least one
`other terminal to which the message is sent. One or more
`secure connections are established between different
`addresses of the first terminal and address of the other termi(cid:173)
`nal. The connections define at least said addresses of the two
`terminals. When the first terminal moves from one address to
`another address, a secure connection, which endpoints are the
`new address of the first terminal and the address of the other
`terminal, is registered to be at least one of the active connec(cid:173)
`tions.
`
`16 Claims, 2 Drawing Sheets
`
`Mobile
`terminal
`
`Home
`Server
`
`X
`
`2
`."'-..
`lrP I Data I 3
`\
`lrP I Data I
`
`1
`
`l
`lrP lrP I Data I
`
`4
`
`I
`lrP lrP I Data I 5
`\
`6'\. lrP IRREa
`lrP IRREP
`
`I
`I
`
`Ex. 1001
`Apple v. MPH Techs. Oy
`IPR2019-00821
`
`0001
`
`

`

`U.S. Patent
`US. Patent
`
`Oct. 11,2011
`Oct. 11, 2011
`
`Sheet 1 012
`Sheet 1 of2
`
`US 8,037,302 B2
`US 8,037,302 B2
`
`FIG.1
`
`Q. w a: a:
`
`<0
`
`X
`
`'-Q)Q)
`Home
`EC!
`OQ)
`J:CI)
`
`Server
`
`terminal
`
`Mobile
`
`0002
`
`• " -u.
`
`0002
`
`

`

`U.S. Patent
`US. Patent
`
`Oct. 11,2011
`Oct. 11, 2011
`
`Sheet 2 012
`Sheet 2 of2
`
`US 8,037,302 B2
`US 8,037,302 B2
`
`FIG.2
`
`0
`w
`a::
`a::
`
`Q..
`w
`a::
`a:::
`
`N
`•
`
`C) -u.
`
`X
`
`""'"
`(I.)
`(I)
`Home
`E2
`0(1)
`J:(l)
`
`Server
`
`terminal
`
`Mobile
`
`0003
`
`0003
`
`

`

`US 8,037,302 B2
`
`1
`METHOD AND SYSTEM FOR ENSURING
`SECURE FORWARDING OF MESSAGES
`
`PRIOR APPLICATIONS
`
`This is a US national phase patent application that claims
`priority from PCT/FI02/00771, filed 27 Sep. 2002, that
`claims priority from Finnish Patent Application No.
`20011911, filed 28 Sep. 2001.
`
`TECHNICAL FIELD
`
`The method and system of the invention are intended to
`secure connections in telecommunication networks. Espe(cid:173)
`cially, the invention is meant to be used in wireless networks
`as a part of a mobile IP solution or an IPSec solution.
`
`TECHNICAL BACKGROUND
`
`An internetwork is a collection of individual networks 20
`connected with intermediate networking devices that func(cid:173)
`tion 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 25
`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 telephone net- 30
`works and other media; thereby interconnecting geographi(cid:173)
`cally disposed users.
`In fixed networks, there exist solutions to fill the need to
`protect data and resources from disclosure, to guarantee the
`authenticity of data, and to protect systems from network 35
`based attacks. IPSec is one such technology by means of
`which security is obtained.
`The IP security protocols (IPSec) provides the capability to
`secure communications across a LAN, across private and
`public wide area networks (WANs) and across the internet. 40
`IPSec can be used in different ways, such as for building
`secure virtual private networks, to gain a secure access to a
`company network (as remote access IPSec use), or to secure
`communication with other organisations, ensuring authenti(cid:173)
`cation and confidentiality and providing a key exchange 45
`mechanism. 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 encrypted and/or
`authenticated and traffic coming from a WAN is decrypted
`and/or authenticated. IPSec is defined by certain documents,
`which contain rules for the IPSec architecture.
`Two protocols are used to provide security at the IP layer,
`an authentication protocol designated by the header of the 55
`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). BothAH and ESP are vehicles for access control
`based on the distribution of cryptographic keys and the man(cid:173)
`agement 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
`If a secure two-way relationship is needed, then two security
`associations are required.
`
`2
`The term IPSec connection is used in what follows in place
`of an IPSec bundle of one or more security associations SAs,
`or a pair ofiPSec bundle-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(cid:173)
`ent.
`A security association is uniquely identified by three
`10 parameters. The first one, the Security Parameters Index
`(SPI), is a 32-bit string assigned to this SA. The SPI is carried
`in AH and ESP headers to enable the receiving system to
`select the SA under which a received packet will be pro(cid:173)
`cessed. IP destination address is the second parameter, which
`15 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.
`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 than IPSec tun-
`nelling).
`Tunnel mode provides protection to the entire IP packet
`and is used for sending messages through more than two
`components. 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 unpro(cid:173)
`tected packets generated by such hosts are tunnelled through
`external networks by tunnel mode SAs setup 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
`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
`header to the packet; thus the "IPipayload" packet becomes
`50 "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 andAH 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
`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
`60 network. The SGW 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 performs IPSec
`processing involving encapsulation of the packet in an outer
`IP header. The source IP address of this outer IP packet is this
`65 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 intermediate
`
`0004
`
`

`

`US 8,037,302 B2
`
`3
`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 and
`selected fields of the outer IP header.
`The key management portion ofiPSec 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 newer name for the ISAKMP/Oakley. IKE is based on the
`Diffie-Hellman key exchange algorithm, and supports RSA
`signature authentication among other modes. IKE is easily
`extensible for future and vendor-specific features without
`breaking backwards compatibility.
`The IPSec protocol solves the known security problems of
`the Internet Protocol (IP) in a satisfactory manner. However,
`it is designed for a static Internet, where the hosts using IPSec
`are relatively static. Thus, IPSec does not work well with
`mobile devices.
`For instance, if a mobile terminal moves from one network
`to another, an IPSec connection set up is required, typically 25
`using the IKE key exchange protocol. Such a set up is expen(cid:173)
`sive in terms of latency, since IKE may require several sec(cid:173)
`onds to complete. It is also expensive in terms of computation,
`because the Diffie-Hellman and authentication-related calcu(cid:173)
`lations of IKE are extremely time consuming.
`Routing means moving information across an internetwork
`from one source to another. Along the way, usually at least
`one intermediate node is encountered. Routing involves both
`the determination of the optimal routing path and the trans(cid:173)
`port of information packets. To aid the routing of information
`packets, routing algorithms initialise and maintain routing
`tables, which contain route information. Routers communi(cid:173)
`cate with each other and maintain their routing tables through
`the transmission of a variety of messages. The routing update
`message is one such message that generally consists the
`whole or part of a routing table.
`The fundamental problem with IP mobility is the fact that
`IP routing is based on fixed addresses. The address space has
`been divided into subnetworks, that reside in practically fixed
`locations with respect to network topology (the routing can be
`changed, but that is a slow process, possibly in the order of
`minutes). When a mobile host moves away from its home
`network (where its IP address is proper), there is a problem
`with the routing of the packets to the new location if the IP
`network in question does not support such movement.
`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.
`Standard Mobile IP for IPv4 utilises e.g. IP-IP and Generic
`Routing Encapsulation (GRE) tunnelling to overcome this
`problem (See more details in FIG. 1 with accompanying text).
`There are also other methods of tunnelling, and hence, IP-IP
`and GRE tunnelling are used only as examples in this text.
`Mobile IPv4 has two modes of operation. In the co-located
`care-of address mode the mobile terminal performs IP-IP
`encapsulation and decapsulation. This mode requires a bor(cid:173)
`rowed address-the co-located care-of address-from the
`visited network. The other mode is the foreign agent mode,
`where the IP-IP or other tunnelling is performed by a special
`host in the visited network, called the Foreign Agent (FA).
`
`4
`The mobile terminal communicates directly with the FA (an
`IP address is not required for this direct communication), and
`does not require a borrowed address in this mode.
`In IP-IP tunnelling, an IP address (the so called co-located
`care-of address) is borrowed from a network being visited.
`This address is topologically correct, i.e. mutable from other
`parts of the network. When a mobile terminal needs to send a
`packet to a given target computer, it first constructs an IP
`packet, whose source address is its home address, i.e. the
`10 address that is not topologically correct in the new network,
`and whose destination address is the target computer.
`Since this packet may not be directly mutable, it is encap(cid:173)
`sulated into another IP packet (by so called IP-IP encapsula-
`15 tion, oriP-IP tunnelling). The source address of this IP packet
`is the care-of address, and the target address is the so called
`home server of the mobile terminal. Upon receiving such an
`encapsulated packet, the home server unwraps the IP-IP tun(cid:173)
`nel, and proceeds to route the packet, which was inside the
`20 encapsulation.
`Reverse packets from the target computer to the mobile
`terminal are handled similarly; the packet is first routed to the
`home server, then encapsulated in IP-IP and delivered to the
`current network the mobile terminal is in. The current mobil-
`ity binding determines which current care-of address matches
`a given home address. (There may also be so-called simulta(cid:173)
`neous bindings, in which case the home address matches a set
`of care-of addresses; the packet is encapsulated and sent to
`each care-of address separately.)
`When the mobile terminal moves to a new network, an
`authenticated signalling message exchange is done between
`the mobile terminal and the home server. A Registration
`Request is sent by the mobile terminal to the home server,
`requesting an update of the current mobility binding. The
`35 server responds using a Registration Reply that may either
`accept or deny the request. When the Foreign Agent mode of
`operation is used, the registration messages go through the
`Foreign Agent.
`IP version 4 (IPv4) is the currently widely deployed Inter-
`40 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-
`45 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
`50 small, and do not usually change the essentials of the proto(cid:173)
`cols significantly.
`The IPSec protocol solves the known security problems of
`the Internet Protocol (IP) in a satisfactory manner. However,
`it is designed for a static Internet, where the hosts using IPSec
`55 are relatively static. Thus, IPSec does not work well with
`mobile devices. For instance, if a mobile terminal moves from
`one network to another, an IPSec connection set up is
`required, typically using the IKE key exchange protocol.
`Such a set up is expensive in terms oflatency, since IKE may
`60 require several seconds to complete. It is also expensive in
`terms of computation, because the Diffie-Hellman and
`authentication-related calculations ofiKE are extremely time
`consuming.
`The above description presents the essential ideas of
`65 Mobile IP.
`The mobile IP approach of prior art has some disadvan(cid:173)
`tages and problems.
`
`30
`
`0005
`
`

`

`US 8,037,302 B2
`
`6
`
`5
`
`5
`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-
`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. In the manual prior 10
`art key management, the signalling authentication mecha(cid:173)
`nism requires the mobile host and the home server to share a
`secret authentication key and the distribution of that key,
`which is carried out manually, is not very practical. Finally, 15
`the current Mobile IP protocol does not define a method for
`working through Network Address Translation (NAT)
`devices.
`Said problem with Network Address Translation (NAT)
`devices, even ifNAT devices are able to translate addresses of 20
`private networks in messages to public IP addresses so that
`the messages can be sent through internet, is, however, that
`currently no standard for making Mobile IP work through
`NAT devices. NAT devices are widely deployed because the
`use of private addresses requires less public IP addresses than 25
`would otherwise be needed.
`
`[RFC3115]
`G. Dommety, and K. Leung, Mobile IP Vendor/Organization-
`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
`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(cid:173)
`net Protocol, RFC 2401, November 1998.
`ftp :/ /ftp.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/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.
`[RFC2405]
`C. Madson, N. Doraswamy, The ESP DES-CBC Cipher
`The following is a list of useful references for understand(cid:173)
`Algorithm With Explicit IV, RFC 2405, November 1998.
`ing the technology behind the invention.
`[RFC2406]
`IP in general, UDP and TCP:
`S. Kent, and R. Atkinson, IP Encapsulating Security Payload
`[RFC7681]
`(ESP), RFC 2406, November 1998.
`J. Postel, User Datagram Protocol, RFC 768, August 1980.
`ftp :/ /ftp.isi.edu/in -notes/rfc2406 .txt
`ftp :/ /ftp.isi.edu/in-notes/rfc7 68 .txt
`[RFC2407]
`[RFC791]
`D. Piper, The internet IP Security Domain of Interpretation
`J. Postel, Internet Protocol, RFC 791, September 1981.
`for ISAKMP, RFC 2407, November 1998.
`ftp:/ /ftp.isi.edu/in-notes/rfc791.txt
`ftp :/ /ftp.isi.edu/in -notes/rfc407. txt
`[RFC792]
`40 [RFC2408]
`J. Postel, Internet Control Message Protocol, RFC 792, Sep-
`D. Maughan, M. Schneider, M. Schertler, and J. Turner, Inter(cid:173)
`tember 1981.
`net Security Association and Key Management Protocol
`ftp :/ /ftp.isi.edu/in-notes/rfc7 92 .txt
`(ISAKMP), RFC 2408, November 1998.
`[RFC793]
`ftp :/ /ftp.isi.edu/in -notes/rfc2408 .txt
`J. Postel, Transmission Control Protocol, RFC 793, Septem- 45 [RFC2409]
`ber 1981.
`D. Harkins, and D. Carrel, The Internet Key Exchange (IKE),
`ftp :/ /ftp.isi.edu/in-notes/rfc7 93 .txt
`RFC 2409, November 1998.
`[RFC826]
`ftp :/ /ftp.isi.edu/in -notes/rfc2409 .txt
`D. C. Plummer, An Ethernet Address Resolution Protocol,
`[RFC2410]
`RFC 826, November 1982.
`50 R. Glenn, S. Kent, The NULL Encryption Algorithm and Its
`ftp :/ /ftp.isi.edu/in-notes/rfc826 .txt
`Use With IPsec, RFC 2410, November 1998.
`[RFC2460]
`[RFC2411]
`S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6)
`R. Thayer, N. Doraswamy, R. Glenn, IP Security Document
`Specification, RFC 2460, December 1998.
`Roadmap, RFC 2411, November 1998.
`Mobile IP; IP-IP; DHCP:
`[RFC2412]
`[RFC2002]
`H. Orman, The OAKLEY Key Determination Protocol, RFC
`C. Perkins, IP Mobility Support, RFC 2002, October 1996.
`2412, November 1998.
`ftp :/ /ftp.isi.edu/in-notes/rfc2002. txt
`NAT:
`[RFC2003]
`60 [RFC2694]
`C. Perkins, IP Encapsulation Within IP, RFC 2003, October
`P. Srisuresh, G. Tsirtsis, P. Akkiraju, and A. Heffernan, DNS
`1996.
`extensions to Network Address Translators (DNS_ALG),
`ftp :/ /ftp.isi.edu/in-notes/rfc2003. txt
`RFC 2694, September 1999.
`[RFC2131]
`[RFC3022]
`R. Drams, Dynamic Host Configuration Protocol, RFC 2131, 65 P. Shisuresh, K. Egevang, Traditional IP Network Address
`March 1997.
`Translator (Traditional NAT), RFC 3022, January 2001.
`ftp:/ftp.isi.edu/in-notes/rfc2131.txt
`ftp:/ /ftp.isi.edu/in-notes/rfc3022.txt
`
`REFERENCES
`
`30
`
`35
`
`55
`
`0006
`
`

`

`US 8,037,302 B2
`
`7
`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 described above.
`
`SUMMARY OF THE INVENTION
`
`The method of the invention for ensuring secure forward(cid:173)
`ing of a message is performed in a telecommunication net(cid:173)
`work, comprising at least one terminal from which the mes(cid:173)
`sage is sent and at least one other terminal to which the
`message is sent. In the method, one or more secure connec(cid:173)
`tions are established between different addresses of the first
`terminal and address of the other terminal, the connections
`defining at least said addresses of the two terminals. When the
`first terminal moves from one address to another address, a
`secure connection, whose endpoints are the new address of
`the first terminal and the address of the other terminal, is
`registered to be at least one of the active connections.
`If there does not already exist such a secure connection
`between the new address and the other terminal, a new secure
`connection between the new address and the other terminal
`address has to be formed.
`The terminals might have several active connections. In the
`invention, the terminal might in one embodiment also have
`only one secure active connection at a time, which can be
`changed in according with the invention to be defined to be
`between the address the terminal moves to and the address of
`the other 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.
`The invention is moreover concerned with a system, which
`is able to perform the method of the invention. The charac(cid:173)
`teristics of the system are defined by the system main claim,
`the subclaim defining the functions that can be performed by
`the system of the invention.
`The secure connections are preferably established by form(cid:173)
`ing Security Associations (SAs) using the IPSec protocols 40
`and the message to be forwarded consists of IP packets. The
`key exchange being a part of the forming of a secure connec(cid:173)
`tion is performed manually or automatically with IKE or
`some other automated key exchange protocol.
`When a new secure connection is formed, it is registered 45
`for immediate and/or later use. The registration for later use is
`made using a connection table, which is maintained by both
`hosts participating in the forming of the secure connection.
`The connection table is also used e.g. when the first terminal
`moves, and needs to determine whether a secure tunnel 50
`already exists for the new address. The table can be e.g. a
`Security Association DataBase (SADB), which is the nomi(cid:173)
`nal place to store IPSec SAs in the IPSec model.
`In the preferred embodiment, IPSec security associations
`are used as secure connections. The table, through which the 55
`existence of a given IPSec SA (in either the first terminal or
`the other terminal) is determined, is then the IPSec Security
`Association DataBase (SADB).
`The actual connection( s) to be used is registered by means
`of a signalling message or signalling message exchange 60
`between the first terminal and the other terminal, for example
`by means of Registration Request and possibly Registration
`Reply messages.
`The request message may update a set of security associa(cid:173)
`tions, for instance, a single security association, a security 65
`association bundle, an IPSec connection, a group of IPSec
`connections, or any combinations of these. In practice, it is
`
`8
`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
`case of updating a single IPSec connection is discussed, with(cid:173)
`out limiting the invention to this behaviour.
`The new address of the first terminal can also be updated
`10 automatically by the other terminal when the first terminal
`sends a message from its new address.
`The active SA is a stored mobility binding that maps a
`given terminal address to one or more IPSec tunnel mode SAs
`15 (or zero such SAs, if the terminal in question is not con(cid:173)
`nected). These mobility bindings are manipulated when Reg(cid:173)
`istration Request and Registration Reply messages are pro(cid:173)
`cessed when sending packets to the first terminal. It is
`possible to restrict traffic from the first terminal to only the
`20 IPSec SAs that are currently registered in the mobility bind(cid:173)
`ing, but allowing traffic from all shared SAs is also reason(cid:173)
`able.
`The mobility binding is necessary, since each of the shared
`IPSec security associations is valid for securing traffic. There
`25 has to be some way for the first terminal to determine which
`security association(s) to actually use when processing pack(cid:173)
`ets. The mobility binding serves this purpose in the invention.
`The first terminal may use any IPSec tunnel SA it shares
`with the other terminal. It is possible to restrict traffic from the
`30 first terminal to only the IPSec SAs that are currently regis(cid:173)
`tered, but this is not an essential feature. Thus, the first termi(cid:173)
`nal may use any IPSec tunnel SA it shares with the other
`terminal when sending packets. The other terminal may
`restrict traffic only to IPSec SAs that are currently active in
`35 the mobility binding, but allowing traffic from all shared SAs
`is also reasonable.
`The invention can be used for direct end-to-end communi-
`cation, in which case the secure turmel is established between
`these end computers. If applied to IPSec, this could corre(cid:173)
`spond to either an IPSec transport mode or tunnel mode SA
`The message might also be sent first to an intermediate com-
`puter, whereby the outer address of the IPSec tunnel is
`unwrapped by the intermediate computer and the message is
`forwarded as plain text to the end destination computer.
`Thus, in the solution of the invention, an IPSec security
`association is used instead of the IP-IP tunnelling. The inven(cid:173)
`tion can also be used for tunnelling with IPSec transport mode
`and an external turmelling mechanism, such as Layer 2 Tun(cid:173)
`nelling Protocol (L2TP).
`The invention provides the following advantages.
`IPSec key management and strong authentication can be
`leveraged for this application involving asymmetric (RSA)
`authentication, the use of the Diffie-Hellman key exchange
`algorithm, the possibility to use certificates etc.
`The IPSec symmetric encryption and authentication meth(cid:173)
`ods can be used to protect both signalling and data traffic. This
`provides confidentiality and integrity and any future devel(cid:173)
`opments of IPSec can be taken advantage of.
`The NAT traversal problem can be solved by using any
`available NAT traversal mechanisms for IPSec. One is cur(cid:173)
`rently being standardised for IPSec, but any other IPSec NAT
`traversal mechanism may be used.
`The invention can be used in different networks, such as
`IPv4 and IPv6.
`In the following the invention is described more in detail by
`means of an advantageous embodiment in an example net(cid:173)
`work but is not restricted to the details thereof.
`
`0007
`
`

`

`US 8,037,302 B2
`
`9
`FIGURES
`
`FIG. 1 describes the mobile IP tunneling of prior art by
`means of a signalling diagram
`FIG. 2 describes the method of the invention by means of a
`signalling diagram
`
`DETAILED DESCRIPTION
`
`10
`Reverse packets from X to the mobile terminal are handled
`similarly; the packet is first routed to the home server in step
`3, then encapsulated in IP-IP and delivered to the current
`network (in step 4) the mobile terminal is in. The mobility
`binding determines which care-of address( es) the packet is
`forwarded to.
`In the method of the invention, an IPSec turmel mode or
`transport mode security association is used instead of the
`IP-IP tunnelling. FIG. 2 describes an example of the method
`10 of the invention for sending messages when a mobile terminal
`moves to a new address.
`A secure connection, preferably an IPSec security associa(cid:173)
`tion (SA) or more specifically one IPsec SA bundle for each
`direction of communication is established between the care(cid:173)
`of-address and the home server address, e.g. the care-of-
`address of the mobile terminal and the home server address.
`The SA can also include additional parameters and attributes,
`possibly relating to standard or non-standard IPSec exten(cid:173)
`sions, such as NAT traversal, which are conventionally used
`in SAs. A message to be sent through this tunnel is marked
`IP/IPSec/IP/Data in FIG. 2, illustrating that the message con(cid:173)
`tains a data part with a destination IP address and can be sent
`through an IPSec tunnel, while encapsulated with an outer IP
`header.
`Reverse packets from X to the mobile terminal are handled
`similarly; the packet is first routed to the home server in step
`3, then IPSec processed using the IPSec tunnel mode SA,
`during which an outer IP header is added to the packet and
`30 delivered to the current network(s) (in step 4) the mobile
`terminal is in.
`When IPSec transport mode is used, the mobile termina