(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT)
`
`(19) World Intellectual Property Organization
`International Bureau
`
`(43) International Publication Date
`10 April 2003 (10.04.2003)
`
`
`
`||||||||||||||l|||||||||||||l|||||||||||||||||||||||||||||l|||||||||||||||||||[||||||
`
`{[0] International Publication Number
`
`PCT
`
`W0 03/030488 Al
`
`(5]) International Patent Classification’:
`IIO4Q ”H38
`
`H04L 290.36,
`
`{74) Agent: INNOPAT LTD; 120.301 556, FIN—02151 Iispoo
`(Ft).
`
`(21) International Application Number:
`
`PCTtFTUZtOtW'tI
`
`{22) International Filing Date:
`27 September 2002 (27.09.2002)
`
`(25) Filing Language:
`
`{26) Publication Language:
`
`[English
`
`English
`
`(30) Priority Data:
`2001 l9l |
`
`38 September 200| (38.09.2001 )
`
`Fl
`
`[N-
`(7]) Applicant {for at! deStgnated States except US):
`TRASECURE NETWORKS 0v [rm-1|; no. Box 33,
`FIN—02210 Iispoo (Fl).
`
`{72) Inventors; and
`(t5) InventorstApplicants (for US only): VAARALA, Sami
`[l-‘ltI-‘II; Nelj‘as Linja 22 A 24, FIN-00530 Helsinki (til).
`NUOPPONEN, Antti ll-‘UFII‘. Kaksoiskiventie 7—9 A 1,
`FIN—02760 Espoo (I’ll. PIETIKAINEN, Panu [FItFI];
`Taysikuu [0 C “)3. FIN-02210 Espoo {Fl}.
`
`(8]) Designated States matronat): An, AG, AL, AM, AT, AU,
`AZ, an, an, so, an, BY. ax, ca, (:11, (IN, coca, co,
`(:2, 1315, [)K, DM, DZ, 15c, 1515. as, 111,013, Gt), (11's, (at,
`GM, HR, 1111, ID, 11,, IN, IS,JP, K12, KG, KP, KR, KZ 1c,
`LK, LR, LS, LT, LU. LV, MA, MD. MG, MK, MN, MW,
`MX, MZ, NO, NZ, OM, PI 1, PL, 1’1", RO, RU, SD, SE. SG,
`51. SK, 31.. '1‘], TM, TN, TR. '1‘1‘. 12. UA, UG. us. 112:,
`vc, VN, Yt1, m, ZM, zw.
`
`(84) Designated States (regional): ARIPO patent {Gt-l, GM,
`K15, 1.3, MW, M'I, SD, $1., 32,
`'17., UG, ZM, ZW),
`Eurasian patent (AM, AZ. BY, KG, KZ, MD, RU, TJ. TM),
`European patent (AT, BIZ, BG, C] l, CY, CZ, DE, DK, TEE,
`ES. Fl, FR. GB. GR, IE, IT, LU. MC. NL, PT, SE. SK,
`TR), OAPI patent (BF, BJ, CF, CG, CI, CM, GA, GN, GQ,
`GW. ML, MR, NIE, SN, TD, TG).
`
`Published:
`
`— with internationat’ search report
`
`[Continued on next page]
`
`(54) Title: METI 10].) AND SYSTEM FOR ENSURING SECURE FORWARDING 0F MESSAGES
`
`Mobile
`terminal
`
`Home
`Server
`
`
`
`
`
`X
`
`
`
`|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
`
`03/030488A1
`
`(57) Abstract: The invention is concerned with a method for ensuring secure forwarding of a message is performed in a telecom—
`munication network, comprising at least one terminal front which the message is sent and at least one other terminal to which the
`message is sent. In the method, one or more secure connections are established between different addresses of the first terminal and
`0 address of the ot her terminal, the connections defining at least said addresses of the two terminals. When the first terminal moves
`from one address to another actress. a secure connection, whose endpoints are the new address of the first terminal and the address
`3
`of the other terminal, is registered to be at least one of the active connections.
`
`0001
`
`Ex. 1017
`
`Apple V. MPH Techs. Oy
`IPR2019-00821
`
`Ex. 1017
`Apple v. MPH Techs. Oy
`IPR2019-00821
`
`0001
`
`

`

`W0 03/030488 A1
`
`||||||||||||||||||||||||||||||||l||||||||||||||||l|l||||||l||||||||||||||||||||||||||
`
`For two-letter codes and other abbreviations. refer to the "Guid-
`ance Notes on Codes amiA bbrevt‘ott‘ons" apmort'ng at the begin-
`ning ofeach regutor issue ofthe PCT Gazette.
`
`0002
`
`0002
`
`

`

`W0 03(030488
`
`PCTIFIUZIIIO'IT]
`
`METHOD AND SYSTEM FOR ENSURING SECURE FORWARDING 0F MESSAGES
`
`1
`
`TECHNICAL FIELD
`
`The method and system of the invention are intended to secure connections in
`
`telecommunicatiOn networks. Especially, the invention is meant to be used in wireless
`
`networks as a part of a mobile lP solution or an lPSec solution.
`
`10
`
`TECHNICAL BACKGROUND
`
`An intemetvmrk is a collection of individual networks connected with intermediate
`
`networking devices that function as a single large network. Different networks can be
`
`15
`
`interconnected by routers and other networking devices to create an intemetwork.
`
`A local area network (LAN) is a data network that covers a relatively small geographic
`
`area.
`
`It
`
`typically connects workstations, personal computers. printers and other
`
`devices. A wide area network (WAN) is a data communication network that covers a
`
`20
`
`relatively broad geographic area. Wide area networks (WANs)
`
`interconnect LANs
`
`across telephone networks and other media; thereby interconnecting geographically
`
`disposed users.
`
`In fixed networks, there exist solutions to fill the need to protect data and resources
`
`25
`
`from displosure.
`
`to guarantee the authenticity of data, and to protect systems from
`
`network based attacks. lPSec is one such technology by means of which security is
`
`obtained.
`
`The IP security protocols (lPSec) provides the capability to secure communications
`
`30
`
`across a LAN, across private and public wide area networks (WANs) and across the
`
`internet. lPSec 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 lPSec
`
`0003
`
`0003
`
`

`

`W0 031030488
`
`PCTIFIOZIUHTFI
`
`2
`
`use], or to secure communication with other organisations, ensuring authentication and
`confidentiality and providing a key exchange mechanism. Even if some applications
`
`already have built in security protocols, the use of IPSec further enhances the security.
`
`lPSec can encrypt andlor authenticate traffic at IP level. Traffic going in to a WAN is
`
`typically encrypted andior authenticated and traffic coming from a WAN is decrypted
`andi’or authenticated. lPSec is defined by certain documents, which contain rules for
`
`the lPSec architecture.
`
`10
`
`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
`
`encryptioniauthentication protocol designated by the format of the packet for that
`protocol, Encapsulating Security Payload (ESP). Both AH and ESP are vehicles for
`access control based on the distribution of cryptographic keys and the management of
`
`15
`
`traffic flows related to these security protocols.
`
`Security association (SA) is a key concept in the authentication and the confidentiality
`mechanisms for IF. 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-
`
`20
`
`way relationship is needed, then two security associations are required.
`
`The term lPSec connection is used in what follows in place of an lPSec bundle of one
`
`or more security associations SAs, or a pair of lPSec 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
`
`25
`
`of the directions, i.e.. the algorithms and IPSec transforms used for each direction may
`
`be different.
`
`30
`
`A security association is uniquely identified by three parameters. The first one, the
`Security Parameters Index (SPI),
`is a 32-bit string assigned to this SA. The SPl
`is
`carried in AH and ESP headers to enabie the receiving system to select the SA under
`
`which a received packet will be processed.
`
`lP destination address is the second
`
`0004
`
`0004
`
`

`

`W0 031030488
`
`PCTIF 102i'0l177l
`
`3
`
`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.
`
`Both AH and ESP support two modes used, transport and tunnel mode.
`
`10
`
`15
`
`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
`
`communication between two hosts. Transport mode may be used in conjunction with a
`
`tunnelling protocol (other than lPSec tunnelling).
`
`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 3 SA is a security gateway. such as a firewall or a router that
`
`implements lPSec. With tunnel mode, a number of hosts on networks behind firewalls
`
`may engage in secure communications without implementing lPSec. The unprotected
`
`packets generated by such hosts are tunnelled through external networks by tunnel
`
`mode SAs setup by the lPSec software in the firewall or secure router at boundary of
`
`20
`
`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 lP packet with a
`
`new outer IP header. The entire original, or inner, packet travels through a tunnel from
`
`25
`
`one point of an lP network to another: no routers along the way are able to examine
`
`the inner lP 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 "lPipayload" packet becomes
`
`"IP I IP I payload". The next step is to secure the packet using ESP andior AH. In case
`
`of ESP,
`
`the resulting packet
`
`is "lPIESPIlPIpayload". The whole inner packet
`
`is
`
`0005
`
`0005
`
`

`

`W0 031030488
`
`PCTIF 102i'0tl77l
`
`4
`
`covered by the ESP and AH protection. AH also protects parts of the outer header, in
`
`addition to the whole inner packet.
`
`The lPSec tunnel mode operates eg.
`
`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 network. The SGW filters all outgoing
`packets to-determine the need for lPSec processing. if this packet from the first host to
`
`another host
`
`requires lPSec,
`
`the firewall performs
`
`lPSec processing involving
`
`10
`
`encapsulation of the packet in an outer IP header. The source lP address of this outer
`
`IP packet 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 intermediate routers examining only the outer lP header. At the other host
`
`firewall. the outer lP header is stripped off and the inner packet is delivered to the other
`
`15
`
`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.
`
`20
`
`The key management portion of lPSec involves the determination and distribution of
`
`secret keys. The default automated key management protocol for lPSec is referred to
`
`as ISAKMPIOakley and consists of the Oakley key determination protocol and lntemet
`
`Security Association and Key Management Protocol (ISAKMP). Internet Key Exchange
`
`25
`
`(IKE) is a newer name for the iSAKMPlOakley.
`
`lKE 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.
`
`30
`
`The lPSec 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 IPSsec are relatively static. Thus, lPSec does not work well with mobile devices.
`
`0006
`
`0006
`
`

`

`W0 031030488
`
`PCTIFIOZIUHTFI
`
`S
`
`For instance.
`
`if a mobile terminal moves from one network to another, an IF’Sec
`
`connection set up is required, typically using the ”(E key exchange protocol. Such a
`
`set up is expensive in terms of latency. since lKE may require several seconds to
`
`complete.
`
`it is also expensive in terms of computation, because the Diffie-Heilman
`
`and authentication-related calculations of ”(E 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 transport of information
`
`packets. To aid the routing of information packets, routing algorithms initialise and
`
`maintain routing tables. which contain route information. Routers communicate 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 an 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 lP 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 va4 utilises e.g.
`
`lP-IP and Generic Routing Encapsulation
`
`(GRE)
`
`tunnelling to overcome this problem (See more details in figure 1 with
`
`accompanying text). There are aiso other methods of tunnelling, and hence. IP-lP and
`
`GRE tunnelling are used only as examples in this text. Mobile va4 has two modes of
`
`operation. In the co-located care-of address mode the mobile terminal performs IP-lP
`
`10
`
`15
`
`20
`
`25
`
`30
`
`0007
`
`0007
`
`

`

`W0 031030488
`
`PCTIF 102l0il77l
`
`6
`
`encapsulation and decapsulation. This mode requires a borrowed address - the co-
`
`located care-of address - from the visited network. The other mode is the foreign agent
`
`mode, where the lP-lP or other tunnelling is performed by a special host in the visited
`
`network, called the Foreign Agent (FA). The mobile terminal communicates directly
`
`with the FA (an lP address is not required for this direct communication), and does not
`
`require a borrowed address in this mode.
`
`In lP-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.
`
`10
`
`routable 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, is the address that is not topologically correct in the new
`
`network, and whose destination address is the target computer.
`
`15
`
`Since this packet may not be directly routable, it is encapsulated into another [P packet
`
`(by so called lP-lP encapsuiation, or lP-lP 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 lP-lP tunnel, 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 mobility binding
`
`25
`
`determines which current care—of address matches a given home address. (There may
`
`also be so-cailed simultaneous 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.)
`
`30
`
`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
`
`0008
`
`0008
`
`

`

`W0 031030488
`
`PCTIF 102i'00771
`
`7
`
`update of the current mobility binding. The 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.
`
`lP version 4 (IPv4) is the currently widely deployed Internet Protocol version.
`
`Its major
`
`disadvantage is the small number of unique, public IP addresses.
`
`lP version 6 (IPv6)
`
`has a much larger address space. which fixes the most important va4 problem known
`
`today. va6 atso changes some other things in the Internet Protocol, for example, how
`
`fragmentation of packets is done, but these changes are quite small. Most protocols
`
`have separate definitions on how they are used within the va4 and the in6 context.
`
`For instance. there are separate versions of lPSec and Mobile IP for use with in4 and
`
`IPv6. HoweverI such modifications to protocols are quite small, and do not usually
`
`change the essentials of the protocols significantly.
`
`The lPSec protocol solves the known security problems of the lnternet Protocol (lP) in
`
`a satisfactory manner. However,
`
`it is designed for a static lntemet, where the hosts
`
`using lPSec are relatively static. Thus, lPSec does not work well with mobile devices.
`
`For instance,
`
`if a mobile terminal moves from one network to another. an lPSec
`
`connection set up is required, typically Using the IKE key exchange protocol. Such a
`
`set up is expensive in terms of latency, since IKE may require several seconds to
`
`complete. it is also expensive in terms of computation, because the Diffie-Hellman and
`
`authentication-related calculations of ME are extremely time consuming.
`
`The above description presents the essential ideas of Mobile lP.
`
`The mobile iP approach of prior art has some disadvantages and problems.
`
`The standard Mobile IP protocol provides a mobile terminal with a mobile connection,
`
`and defines mechanisms for performing efficient handovers from one network to
`
`another. However, Mobile lP has several disadvantages. The security of Mobile lP is
`
`very limited. The mobility signalling messages are authenticated, but not encrypted.
`
`and user data traffic is completely unprotected. Also.
`
`there is no key exchange
`
`IO
`
`15
`
`20
`
`25
`
`30
`
`0009
`
`0009
`
`

`

`W0 031030488
`
`PCTIF 102i'00771
`
`8
`
`mechanism for establishing the cryptographic keys required for authenticating the
`
`mobility signalling. Such keys need to be typically distributed manually.
`
`In the manual
`
`prior art key management, the signalling authentication mechanism 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. the current Mobile
`
`lP protocol does not define a method for working through Network Address Translation
`
`(NAT) devices.
`
`Said problem with Network Address Translation (NAT) devices, even if NAT devices
`
`are able to translate addresses of private networks in messages to public lP 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
`
`would otherwise be needed.
`
`IO
`
`15
`
`REFERENCES
`
`The following is a list of useful references for understanding the technology behind the
`
`20
`
`invention.
`
`IP in general, UDP and TCP:
`
`[RFCTSB]
`
`25
`
`30
`
`J. Postel, User Datagram Protocol. RFC 7'68, August 1980.
`
`flgji‘ftg.isiedufin-noteslrfcmatg
`
`[RF0791]
`
`J. Postel, intemetProtocol. RFC 791, September 1981.
`
`ftgilflpisiedufin-noteslrffig‘l .00.
`
`[RFC792}
`
`J. Postel, intemet Control Message Protocot. RFC 792. September 1981.
`
`0010
`
`0010
`
`

`

`W0 03l031l488
`
`PCTlFIOZlUUTr‘l
`
`flgjiflgjsiedw'm-n oleslrfc792,brt
`
`[RFC793]
`
`J. Postel, Transmission Control Protocol, RFC 793. September 1981.
`
`figllflgisi.edufin-notesirfc793.m
`
`[RFC828]
`
`D.C. Plummer. An Ethernet Address Resolution Protocol. RFC 826, November
`
`1 982.
`
`11939119st eduli n-notesi#0826th
`
`[RFCZ480]
`
`S. Deering, R. Hinden, lnternet Protocol, Version 6 {in6) Specification. RFC
`
`2460, December 1998.
`
`Mobile IP; lP-IP; DHCP:
`
`[RFC2002]
`
`C. Perkins. iP Mobility Support, RFC 2002. October 1996.
`
`flgjifigjsiedulin-noteslrfczoogbd
`
`[RF02003]
`
`C. Perkins. iP Encapsulation Within iP, RFC 2003, October 1996.
`
`figJiftgjsiedulin-notesirfczooa.txt
`
`[RFC21 31]
`
`R. Droms. Dynamic Host Configuration Protocoi, RFC 2131, March 1997.
`
`flgzllfigjsi.edufln-noteslifc21 31 .txl
`
`10
`
`15
`
`20
`
`25
`
`30
`
`[RF03115]
`
`G. Dommety, and K. Leung. Mobile lP Vendor/Organization-specitic Extensions,
`
`RFC 3115. April 2001.
`
`ftprilftgjsiedufin-notesirfcfl 15.txt
`
`0011
`
`0011
`
`

`

`W0 031030488
`
`PCTiFIOZi'UElTil
`
`[MOBILEIPVB]
`
`10
`
`D. B. Johnson, C. Perkins, Mobiiity Support in in6, Work in progress (Internet-
`
`Draft is available), July 2000.
`
`[DHCPVS]
`
`J. Bound, M. Carney, C. Perking. RDrorns. Dynamic Host Configuration
`
`Protocoi for ins (DHCPvé‘), Work in progress (lntemet-Draft is available), June
`
`10
`
`15
`
`2001.
`
`lPSec standards:
`
`{RFCZ401}
`
`S. Kent. and R. Atkinson, Security Architecture forthe internet Protocoi, RFC
`
`2401. November 1998.
`
`11 m .isi.eduiin- at
`
`401m
`
`[RFCZ402]
`
`S. Kent. and R. Atkinson, iP Authentication Header, RFC 2402, November
`
`20
`
`1 998.
`
`fig:ii‘ftgisiedufin-ngtesterIlOtht
`
`[RFC2403]
`
`25
`
`30
`
`C. Madson, R. Glenn. The Use of HMAC-MD5-96 within ESP and AH, RFC
`
`2403, November 1998.
`
`[RFC2404]
`
`C. Madson, R. Glenn, The Use of HMAC-SHA-1-96 within ESP and AH, RFC
`
`2404, November 1998.
`
`[RFC2405]
`
`C. Madson. N. Doraswamy, The ESP DES-CBC Cipher Algorithm With Explicit
`
`IV, RFC 2405. November 1998.
`
`0012
`
`0012
`
`

`

`W0 031030488
`
`PCTIFIOZTUHTFI
`
`11
`
`[RF 02406]
`
`S. Kent, and R. Atkinson, TP Encapsuiating Security Payioao‘ (ESP), RFC 2406,
`
`November 1998.
`
`figii'flgjsi.edufin-notesrrfc2408bd
`
`{RF02407]
`
`D. Piper, The internet iP Security Domain of interpretation for iSAKMP. RFC
`
`240?. November 1998.
`
`flgflflgisi.edui’in-flotestrfc2407.tx1
`
`[RFCZ4081
`
`D. Maugham, M. Schneider, M. Schertler, and J. Turner, internet Security
`
`Association and Key Management Protocoi (ISAKMP), RFC 2408, November
`
`1998.
`
`flgjifigjsi.edur'tn-notesirfczwaixt
`
`[RFCZ409]
`
`D. Harkins. and D. Carrel, The internet Key Exchange (iKE), RFC 2409.
`
`November 1998.
`
`figflfig isi.edui1n-notestr_f02409.b<t
`
`[RFCZ410]
`
`R. Glenn, 3. Kent. The NULL finch/prion Aigonthm and its Use With iPsec, RFC
`
`2410, November 1998.
`
`[RF02411]
`
`10
`
`15
`
`20
`
`25
`
`R. Thayer. N. Doraswamy, R. Glenn, IP Security Document Roadmap, RFC
`
`2411, November 1998.
`
`30
`
`[RFC2412]
`
`H. Orman, The OAKLEY Key Determination Protocot, RFC 2412, November
`
`1998.
`
`0013
`
`0013
`
`

`

`W0 03l030488
`
`PCTlFIOZlUHTll
`
`12
`
`NAT:
`
`[RFC2894]
`
`P. Srisuresh, G. Tsirtsis, P. Akkiraju. and A. Hefiernan. DNS extensions to
`
`Network Address Translators {DNS__ALG), RFC 2694, September 1999.
`
`[RFC3022]
`
`P. Shisuresh, K. Egevang. Traditional lP Nehvork Address Translator
`
`(Traditional NAT), RFC 3022, January 2001.
`
`ftp:llflg.isi.edufin-noteslrfc3022.brt
`
`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.
`
`10
`
`15
`
`20
`
`SUMMARY OF THE INVENTION
`
`The method of the invention for ensuring secure fonivarding of a message is performed
`
`in a telecommunication network, comprising at least one terminal from which the
`
`message is sent and at least one other terminal to which the message is sent. in the
`
`25
`
`method. one or more secure connections 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
`
`30
`
`the active connections.
`
`0014
`
`0014
`
`

`

`W0 031030488
`
`PCTIFIOZIUHTFI
`
`13
`
`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 characteristics 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 forming Security Associations
`
`(SAs) using the lPSec protocols and the message to be forwarded consists of IP
`
`packets. The key exchange being a part of the forming of a secure connection is
`
`performed manually or automatically with IKE or some other automated key exchange
`
`protocol.
`
`10
`
`IS
`
`20
`
`When a new secure connection is formed,
`
`it is registered for immediate andlor later
`
`25
`
`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 eg. when the first
`
`terminal moves, and needs to
`
`determine whether a secure tunnel already exists for the new address. The table can
`
`be eg. a Security Association DataBase (SADB), which is the nominal place to store
`
`30
`
`lPSec .SAs in the IPSec model.
`
`0015
`
`0015
`
`

`

`W0 031030488
`
`PCTIFIOZIUHTFI
`
`14
`
`In the preferred embodiment,
`
`IPSec security associations are used as secure
`
`connections. The table, through which the existence of a given lPSec SA (in either the
`
`first
`
`terminal or
`
`the other
`
`terminal)
`
`is determined,
`
`is
`
`then the lPSec Security
`
`Association DataBase (SADB).
`
`The actual connection(s) to be used is registered by means of a signalling message or
`
`signalling message exchange between the first terminal and the other terminal, for
`
`example by means of Registration Request and possibly Registration Reply
`
`messages.
`
`10
`
`The request message may update a set of security associations, for instance, a single
`
`security association, a security association bundle, an IPSec connection, a group of
`
`lPSec connections. or any combinations of these.
`
`In practice.
`
`it is useful to update
`
`either a single lPSec connection or a group of lPSec connections. The latter may be
`
`15
`
`important if separate lPSec 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 separate requests for each IPSec connection.
`
`In the
`
`following, the case of updating a single lPSec connection is discussed, without limiting
`
`the invention to this behaviour.
`
`20
`
`The new address of the first terminal can also be updated 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
`
`25
`
`more lPSec tunnel mode SAs (or zero such SAs.
`
`if the terminal in question is not
`
`connected). These mobility bindings are manipulated when Registration Request and
`
`Registration Reply messages are processed when sending packets to the first
`
`terminal. It is possible to restrict traffic from the first terminal to only the lPSec SAs that
`
`are currently registered in the mobility binding, but allowing traffic from all shared SAs
`
`30
`
`is also reasonable.
`
`The mobility binding is necessary,
`
`since each of
`
`the shared lPSec security
`
`associations is valid for securing traffic. There has to be some way for the first terminal
`
`0016
`
`0016
`
`

`

`W0 031030488
`
`PCTIFIOZIUHTFI
`
`15
`
`to determine. which security association(s) to actually use when processing packets.
`
`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 first terminal to only the IPSec SAs that are currentiy
`
`registered, but this is not an essential feature. Thus, the first terminal 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 the mobility
`
`binding, but allowing traffic from all shared SAs is also reasonable.
`
`10
`
`The invention can be used for direct end-to-end communication,
`
`in which case the
`
`secure tunnel is established between these and computers.
`
`if applied to iPSec, this
`
`could correspond to either an iPSec transport mode or tunnel mode SA. The message
`
`might also be sent first to an intermediate computer, whereby the outer address of the
`
`15
`
`iPSec tunnel
`
`is unwrapped by the intermediate computer and the message is
`
`forwarded as plain text to the and destination computer.
`
`Thus, in the solution of the invention, an IPSec security association is used instead of
`
`the lP—IP tunnelling. The invention can also be used for tunnelling with IPSec transport
`
`20
`
`mode and an external tunnelling mechanism. such as Layer 2 Tunneiling Protocol
`
`(L2TP).
`
`The invention provides the following advantages.
`
`25
`
`IPSec key management and strong authentication can be leveraged for this application
`
`involving asymmetric (RSA) authentication. the use of the Diffie—Heilman key exchange
`
`algorithm, the possibility to use certificates etc.
`
`The iPSec symmetric encryption and authentication methods can be used to protect
`
`30
`
`both signalling and data traffic. This provides confidentiality and integrity and any
`
`future developments of IPSec can be taken advantage of.
`
`0017
`
`0017
`
`

`

`W0 031030488
`
`PCTIFIOZIUHTFI
`
`16
`
`The NAT traversal problem can be solved by using any available NAT traversal
`
`mechanisms for IPSec. One is currently 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 network but is not restricted to the details thereof.
`
`FIGURES
`
`Figure 1 describes the mobile IP tunnelling of prior art by means of a signalling
`
`diagram
`
`Figure 2 describes the method of the invention by means of a signalling diagram
`
`DETAILED DESCRIPTION
`
`The data communication in figure 1 takes place from a mobile terminal to a target host
`
`X via an intermediate computer, which works as a home server for host X.
`
`Packets sent from the home address of the mobile terminal can be directly routed to
`
`the target address X by the intermediate computer, since the home address is
`
`registered in routing tables by means of which the routing takes place.
`
`IO
`
`15
`
`20
`
`25
`
`Figure 1 describes a method of prior art, wherein lP-IP tunnelling is used for routing
`
`data packets when the mobile host moves from one address to another. i.e. from the
`
`30
`
`home address to a new address.
`
`0018
`
`0018
`
`

`

`W0 031030488
`
`PCTIFIOZIUHTI'I
`
`1?
`
`Mobile lP also supports the so-called triangular routing mode. where the packets sent
`
`by the mobile terminal are routed directly to the recipient of the packet. bypassing the
`
`home server, while packets sent to the mobile terminal are first routed to the home
`
`server and then lP-tP tunnelled to the mobile terminal. This mode is more efficient, but
`
`is incompatible with so-called ingress filtering routers, which do not route lP packets
`
`whose source addresses are topologically incorrect, as is the case with a mobile
`
`terminal that is away from the home network. The details of this mode are different. but
`
`the general idea is the same. The more general case where lP-IP tunnelling is used
`
`for traffic between the mobile terminal and the home server in both directions is
`
`IO
`
`discussed in the following text.
`
`In figure 1, when a mobile terminal being in a visited network intends to send a packet
`
`to a target host X using its current care—of address, which is an ad