MAR. 26. 2004 11: 29AM
`..,. .
`..
`
`RF:nr 3/26/0~ 290.10530SN
`
`FASTH-LAW-OFFICES
`
`10/4 909·33 NO. 395
`P. 1
`OT02 Rec'd PCTJPTO 2 6 MAR 2004
`EXPRESS MAIL LABEL NO. ER625088340US
`Date of Mailing:
`26 March 2004
`
`~RANSMITTAt LETTER TO THE UNITED STATES DESIQNATEO/ELECTED OFFICE
`(DO/EO/US) CONCERNING FILINQ UNDIR 35 U.S.C. 371
`
`Int'l. Application No.:
`Int'l. Filing Date:
`Priority Date Claimed:
`Title of Invention:
`
`Applicant(s) for DO/ES/US:
`
`Attorney Docket No.:
`
`290.1053USN
`
`PCT/FI02/00771
`27 SEPTEMBER 2002
`29 SEPTEMBER 2001
`METHOD AND SYSTEM FOR ENSURING
`SECURE FORWARDING OF MESSAGES
`Sami Vaarala, Antti Nuopponen, Panu
`Pietikainen
`
`2.
`
`Applicant herewith submits to the United States
`Designated/Elected/Office (DO/EO/US) the following items and
`other information:
`1.
`[X] This is a FIRST submission of items concerning a filing
`under 35 U.S.C. 371.
`[ ] This is a SECOND or SUBSEQUENT submission of items
`concerning a filing under 37 U.S.C. 371.
`[X] This is an express request to begin national examination
`procedures (35 u.s.c. 37l(f)) at any time rather than
`delay examination until the expiration of the applicable
`time limit set in 35 u.s.c. 37l(b) and PCT Articles 22
`and 39 ( 1) .
`
`3.
`
`/
`
`4.
`
`5.
`
`7.
`
`9.
`
`11.
`
`a.
`
`b.
`c.
`
`[X]
`
`a.
`b.
`c.
`
`d.
`
`(X] A proper Demand for International Preliminary Examination
`was made by the 19th month from the earliest claimed
`priority date.
`[X] A copy of the International Application as filed
`(35 u.s.c. 371(c) (2)
`[ J is transmitted herewith (required only if not
`transmitted oy the International Bureau).
`[X] has been transmitted by the International Bureau.
`[ ] is not required, as the application ~as filed in the
`United States Receiving Office(RO/US).
`Amenqments to the claims of the International Application
`unde~ PCT Article 19 (35 U.S.C. 371(c) (3))
`[ ] are transmitted herewith (required only if not
`transmitted by the International Bureau) .
`(X] have been transmitted by the International Bureau.
`[ ] have not been made; however, the time limit for
`making such amendments has NOT expired.
`[ J have not been made and will not be made.
`An oath or declaration of the inventor (unsigned)
`(35 U.S.C. 371 (C) (4)).
`An Information Disclosure Statement under 37 C.F.R. 1.97
`and 1.98.
`
`[X]
`
`[
`
`]
`
`TRANSMITTAL LETTER - Page 1 of 2
`
`0001
`
`Ex. 1002
`Apple v. MPH Techs. Oy
`IPR2019-00821
`
`

`

`MAR. 26. 2004 11: 30AM
`
`FASTH-LAW-OFFICES
`
`.....
`
`IU": nr 3/26/04 290 .1053USN
`
`/ L/96 933
`Ni B5
`0111 Rec'd PBT/PTO 2 6 MAR 2004
`EXPRESS MAIL LABEL NO. ER625088340US
`Date of Mailing:
`26 March 2004
`12. [ ] An assignment document for recording. A cover sheet in
`compliance with 37 C.F.R. 3.28 and 3.31 is included.
`[X] A FIRST preliminary amendment.
`
`13.
`
`14.
`
`[XJ Applicant qualifies for Small Entity Status (37 C.F.R.
`1 • 9 (f) and 1. 2 7 (b) ) .
`16. [ ] Other items or information:
`
`(if any)
`
`17. [X] Basic National Filing Fee of $1080.00 is submitted
`(Neither international preliminary examination fee (37
`c.F.R. 1.482) nor international search fee 37 C.F.R.
`l. 4 4 . 5 (a) ( 2) paid to U.S. P. T. 0. ) .
`
`For
`
`CLAIMS AS FILED
`Number Number Easic Fee $1080.00
`Extra
`Filed
`
`Total Claims 17 - 20
`Ind. Claims
`2 - 3
`
`I"" 0
`
`Rate
`X $18.00 """ $0.00
`X $86.00 = $0.00
`
`- 0
`[X] Reduction by 1/2 for filing by small entity, if
`applicable. Applicant qualifies as small entity.
`TOTAL FILING FEE:
`$540.00
`20. [ J Fee for recording the enclosed assignment (37 C.F.R.
`1.21(h)). The assignment must be accompanied by an
`appropriate cover sheet (37 C.F.R. 3.28, 3.31). $40.00
`per property.
`[X] A check in the amount of $540.00 to cover the above fee
`is enclosed.
`[X] The Commissioner is hereby authorized to charge any
`additional fees which may be required, or credit any
`overpayment to Deposit Account No. 06-0243.
`
`19.
`
`21.
`
`23.
`
`Send all correspondence to:
`
`Rolf Fasth, Esq.
`FASTH LAW OFFICES
`629 E. Boca Raton Road
`Phoenix, AZ
`85022
`Telephone: 602-993-9099
`Facsimile: 602-942-8364
`
`Respectfully submitted,
`
`~\tfj~
`
`Registration Number 36,999
`
`TRANSMITTAL LETTER - Page 2 of 2
`
`0002
`
`

`

`wo 03/030488
`
`1
`
`~ec'd PCT/PTO 26 MARZ004
`t;D,Jo~~~~ 0 9 3 ~j
`
`METHOD AND SYSTEM FOR ENSURING SECURE FORWARDING OF MESSAGES
`
`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 IP solution or an IPSec solution.
`
`TECHNICAL BACKGROUND
`
`An internetwork is a collection of individual networks connected with intermediate
`networking devices that function as a single large network. Different networks can be
`interconnected by routers and other networking devices to create an internetwork.
`
`5
`
`10
`
`I 5
`
`A local area network (LAN) is a data network that covers a relatively small geographic
`
`It typically connects workstations, personal computers, printers and other
`area.
`devices. A wide area network (WAN) is a data communication network that covers a
`relatively broad geographic area. Wide area networks (WANs) interconnect LANs
`
`20
`
`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 disClosure, to guarantee the authenticity of data, and to protect systems from
`network based attacks. IPSec is one such technology by means of \Nhich security is
`obtained.
`
`The IP security protocols (IPSec) provides the capability to secure communications
`across a LAN, across private and public wide area net\vorks (WANs) and across the
`
`30
`
`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 (as remote access IPSec
`
`0003
`
`

`

`wo 03/030488
`
`PCTIFI02/00771
`
`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.
`
`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 protocol, Authentication Header {AH), and a combined
`encryption/authentication 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
`traffic flows related to these security protocols.
`
`s
`
`10
`
`15
`
`Security association (SA) is a key concept in the authentication 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-
`20 way relationship is needed, then two security associations are required.
`
`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 of IPSec 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 algorithms and IPSec transforms used for each direction may
`be different.
`
`25
`
`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 SPI is
`
`30
`
`carried in AH and ESP headers to enable the receiving system to select the SA under
`which a received packet wilt be processed. I P destination address is the second
`
`0004
`
`

`

`wo 03/030488
`
`PCT/FI02/00771
`
`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.
`
`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 IPSec 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 a SA is a security gateway, such as a firewall or a router that
`implements IPSec. With tunnel mode, a number of hosts on networks behind firewalls
`may engage in secure communications without implementing IPSec. The unprotected
`packets generated by such hosts are tunnelled through external networks by tunnel
`mode SAs 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 J P 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
`thus the "1 P I payload" packet becomes
`add a new I P header to the packet;
`"IP liP I payload". The next step is to secure the packet using ESP and/or AH. In case
`of ESP, the resulting packet is "IP I ESP liP I payload". The whole inner packet is
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`0005
`
`

`

`wo 03/030488
`
`PCTIFI02/00771
`
`covered by the ESP and AH protection. AH also protects parts of the outer header, in
`addition to the whole inner packet.
`
`4
`
`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 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
`I P 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 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 seleded fields of the outer IP header.
`
`The key management portion of IPSec involves the determination and distribution of
`secret keys. The default automated key management protocol for IPSec is referred to
`as ISAKMP/Oakley and consists of the Oakley key determination protocol and Internet
`Security Association and Key Management 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, 'Nhere the hosts
`using IPSsec are relatively static. Thus, IPSec does not work well with mobile devices.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`0006
`
`

`

`wo 03/030488
`
`PCTIFI02/00771
`
`5
`
`For instance, if a mobile terminal moves from one netWork to another, an IPSec
`connection set up is required, typically using the JKE 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 IKE are extremely time consuming.
`
`5
`
`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
`1 o 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.
`
`15
`
`20
`
`25
`
`30
`
`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 1Pv4 utilises e.g. IP-lP and Generic Routing Encapsulation
`(GRE) tunnelling to overcome this problem (See more details in figure 1 with
`accompanying text). There are also other methods of tunnelling, and hence, JP-IP and
`GRE tunnelling are used only as examples in this text. Mobile 1Pv4 has two modes of
`operation. In the co-located care-of address mode the mobile terminal performs IP-IP
`
`0007
`
`

`

`wo 03/030488
`
`PCTIFI02/00771
`
`6
`
`encapsulation and decapsulation. Ttlis mode requires a borrowed address - the co(cid:173)
`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). The mobile terminal communicates directly
`5 with the FA {an JP address is not required for this direct communication), and does not
`require a borrowed address in this mode.
`
`I o
`
`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.
`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, i.e. 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 routabfe, it is encapsulated into another IP packet
`(by so called IP-IP encapsulation, or IP-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 JP-JP tunnel, and proceeds to route the packet, which was inside the
`encapsulation.
`
`20
`
`25
`
`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
`determin.es which current care-of address matches a given home address. (There may
`also be so-called 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
`
`

`

`wo 03/030488
`
`PCTIFI02/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.
`
`5
`
`10
`
`IP version 4 (1Pv4) is the currently widely deployed Internet Protocol version. Its major
`disadvantage is the small number of unique, public IP addresses. IP version 6 (1Pv6)
`has a much larger address space, which fixes the most important 1Pv4 problem known
`today. JPv6 also 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 1Pv4 and the 1Pv6 context.
`For instance, there are separate versions of IPSec and Mobile IP for use with 1Pv4 and
`I Pv6. However, such modifications to protocols are quite small, and do not usually
`change the essentials of the protocols significantly.
`
`I 5
`
`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 nel\wrk to another, an IPSec
`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 IKE are extremely time consuming.
`
`The above description presents the essential ideas of Mobile IP.
`
`The mobile IP approach of prior art has some disadvantages and problems.
`
`20
`
`25
`
`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 IP has several disadvantages. The security of Mobile IP is
`
`30
`
`very limited. The mobility signalling messages are authenticated, but not encrypted,
`and user data traffic is· completely unprotected. Also, there is no key exchange
`
`0009
`
`

`

`wo 03/030488
`
`PCTIFI02/00771
`
`8
`
`mechanism for establishing the ayptographic keys required for authenticating the
`mobility signaUing. 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
`IP protocol does not define a method for working through Network Address Translation
`{NAT) devices.
`
`5
`
`Said problem With Network Address Translation (NAn devices, even if NAT devices
`I o are ab(e to translate addresses of private networks in messages to public I P 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.
`
`15
`
`REFERENCES
`
`The following is a Jist of useful references for understanding the technology behind the
`invention.
`
`20
`
`IP in general, UDP and TCP:
`
`[RFC768]
`J. Postel, User Datagram Protocol, RFC 768, August 1980.
`ftp://flp.isi.edu/in-notes/rfc768.txt
`
`[RFC791]
`J. Postel, Internet Protocol, RFC 791, September 1981.
`ftp:l/flp.isi.edu/in-notes/rfc791.txt
`
`25
`
`30
`
`[RFC792]
`
`J. Postel, Internet Control Message Protocol, RFC 792, September 1981.
`
`0010
`
`

`

`WO 03/030488
`
`PCTIFI02/00771
`
`ftp:/lftp.isi.edulin-notes/rfc792.txt
`
`9
`
`[RFC793]
`J. Postel, Transmission Control Protocol, RFC 793, September 1981.
`ftp://ftp.isi .edu/in-notes/rfc 793. 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 (/Pv6) Specification, RFC
`2460, December 1998.
`
`Mobile IP; IP-IP; DHCP:
`
`[RFC2002)
`C. Perkins, IP Mobility Support, RFC 2002, October 1996.
`ftp:llftp.isi.edu/in-noteslrfc2002.txt
`
`[RFC2003]
`C. Perkins, IP Encapsulation Within IP, RFC 2003, October 1996.
`ftp://ftp.isi.edu/in-noteslrfc2003.txt
`
`[RFC213.1]
`
`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 IP Vendor/Organization-specific Extensions,
`RFC 3115, April 2001.
`ftp://ftp.isi.edulin-notes/rfc3115.txt
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`0011
`
`

`

`WO 03/030488
`
`PCTIFI02/00711
`
`1.0
`
`[MOBILEIPV6]
`D. B. Johnson, C. Perkins, Mobility Support in 1Pv6, Work in progress (Internet(cid:173)
`Draft is available), July 2000.
`
`[DHCPV6]
`J. Bound, M. Carney, C. Perking, R Droms, Dynamic Host Configuration
`Protocol for /Pv6 (DHCPv6), Work in progress (Internet-Draft is available), June
`2001.
`
`I P Sec standards:
`
`[RFC2401]
`S. Kent, and R. Atkinson, Security Architecture for the Internet Protocol, RFC
`2401, November 1998.
`ftp:/lftpJsi.edulin-notes/rfc2401.txt
`
`[RFC2402]
`S. Kent, and R. Atkinson, IP Authentication Header, RFC 2402, November
`1998.
`ftp://ftp. isf. edulin-notes/rfc2402. txt
`
`[RFC2403]
`C. Madson, R. Glenn, The Use of HMAC-MDS-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. ·
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`0012
`
`

`

`WO 03/030488
`
`PCT/FI02/00771
`
`11
`
`[RFC2406]
`S. Kent, and R. Atkinson, /P 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 for ISAKMP, RFC
`2407, November 1998.
`np:Jiftp.isi. edulin-notes/rfc2407. txt
`
`[RFC2408]
`D. Maughan, M. Schneider, M. Schertler, and J. Turner, Internet Security
`Assodation 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 W1th IPsec, RFC
`2410, November 1998.
`
`[RFC2411]
`R. Thayer, N. Doraswamy, R. Glenn. IP Security Document Roadmap, RFC
`2411, November 1998.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`[RFC2412]
`H. Orman, The OAKLEY Key Determination Protocol, RFC 2412, November
`1998.
`
`0013
`
`

`

`wo 03/030488
`
`NAT:
`
`PCT /FI02/00771
`
`12
`
`[RFC2694]
`P. Srisuresh, G. Tsirtsis, P. Akkiraju, and A. Heffernan, DNS extensions to
`Network Address Translators (DNS_ALG), RFC 2694, September 1999.
`
`5
`
`[RFC3022]
`P. Shisuresh, K Egevang, Traditiona/IP Network Address Translator
`(Traditional NAT), RFC 3022, January 2001.
`ftp://ftp.isi.edulin-notes/rfc3022.txt
`
`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.
`
`I 0
`
`15
`
`20 SUMMARY OF THE. INVENTION
`
`The method of the invention for ensuring secure forwarding 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
`
`

`

`WO 03/030488
`
`PCTIFI02/00771
`
`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.
`
`5
`
`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.
`
`10
`
`In the invention, the first terminal is movable from one netv.lork 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
`15 main claim, the subclaim defining the functions that can be performed by the system of
`the invention.
`
`20
`
`25
`
`The secure connections are preferably established by forming Security Associations
`{SAs) using the IPSec 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.
`
`When a new secure connection is formed, it is registered 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 already exists for the new address. The table can
`
`be e.g. a Security Association DataBase (SADB), which is the nominal place to store
`IPSec .SAs in the IPSec model.
`
`30
`
`0015
`
`

`

`wo 03/030488
`
`PCT/FI02/00771
`
`14
`
`fPSec security associations are used as secure
`In the preferred embodiment.
`connections. The table, through which the 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 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 associations, for instance, a single
`security association, a security association bundle, an IPSec connection, a group of
`IPSec 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 separate requests for each IPSec connection. In the
`following, the case of updating a single IPSec connection is discussed, without limiting
`the invention to this behaviour.
`
`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.
`
`5
`
`10
`
`15
`
`20
`
`The active SA is a stored mobility binding that maps a given terminal address to one or
`25 more IP.Sec 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 IPSec SAs that
`are currently registered in the mobility binding, but allowing traffic from all shared SAs
`is also reasonable.
`
`30
`
`The mobility binding is necessary, since each of the shared IPSec security
`associations is valid for securing traffic. There has to be some way for the first terminal
`
`0016
`
`

`

`wo 03/030488
`
`PCTIFI02/00771
`
`to determine. which security association(s) to actually use when processing packets.
`The mobility binding serves this purpose in the invention.
`
`15
`
`5
`
`10
`
`15
`
`The first terminal may use any IPSec tunnel SA it shares with the other terminal. It is
`possible to restrid traffic from the first terminal to only the IPSec SAs that are currently
`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 restrid traffic only to IPSec SAs that are currently adive in the mobility
`binding, but allowing traffic from all shared SAs is also reasonable.
`
`The invention can be used for direct end-to-end communication, in which case the
`secure tunnel is established between these end 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
`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-tP tunnelling. The invention can also be used for tunnelling with IPSec transport
`20 mode and an external tunnelling mechanism, such as Layer 2 Tunnelling Protocol
`{L2TP).
`
`The invention provides the following advantages.
`
`25
`
`30
`
`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 methods can be used to protect
`both signalling and data traffic. This provides confidentiality and integrity and any
`future developments of IPSec can be taken advantage of.
`
`0017
`
`

`

`wo 03/030488
`
`PCTIFI02/00771
`
`16
`
`The NAT traversal problem can be solved by using any available NAT traversal
`mechanisms for IPSec. One is currently being standardised for JPSec, but any other
`IPSec NAT traversal mechanism may be used.
`
`5
`
`The invention can be used in different networks, such as 1Pv4 and 1Pv6.
`
`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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`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 YIOrks 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.
`
`Figure 1 describes a method of prior art, 'Nherein IP-IP tunnelling is used for routing
`data packets when the mobile host moves from one address to another, i.e. from the
`home address to