“MAR. 26. 2004 10:41AM
`
`>
`nh =
`
` FASTH-LAW-OFFICES
`
`N0393 JOA490 932
`DT02 Rec'd PCT/PTO 2 6 MAN 2004
`
`REine 3/26/04 290.10520eN
`
`EXPRESS MAIL LABEL NO. BR625088509US
`Date of Mailing:
`26 March 2004
`
`TRANSMI
`
`TAL LETTER TO THE UNITED STATES DESIGNATED/ELECTED OFFICE
`(DO/EO/US) CONCERNING FILING UNDER 35 U.S.C. 371
`Attorney Docket No.:
`290,1052USN
`
`1.
`
`[X]
`
`pcT/FI02/00770
`Int'l. Application No.:
`27 SEPTEMBER 2002
`Int'l. Filing Date:
`28 SEPTEMBER 2001
`Priority Date Claimed:
`METHOD AND NETWORK FOR ENSURING
`Title of Invention:
`SECURB FORWARDING OF MESSAGES
`Sami Vaarala, Antti Nuopponen
`Applicant(s) for DO/ES/US:
`Applicant herewith submits to the United States
`Designated/Blected/Office (DO/EO/US)
`the foliowing items and
`other information:
`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.
`This is an express request to begin national examination
`procedures (35 U.S.C. 371(f)) at any time rather than
`delay examination until the expiration of the applicable
`time limit set in 35 U.S.C. 371(b) and PCT Articles 22
`and 39(1).
`
`[
`
`]
`
`[x]
`
`[3]
`
`(x)
`
`oo
`
`(x)
`
`aavpb
`
`[X]
`
`Tes
`
`C
`
`J
`
`A proper Demand for International Preliminary Examination
`was made by the 19th month from the earliest claimed
`priority date.
`A copy of the International Application as filed
`(35 U.S.C. 371 (c) (2)
`[
`]
`is transmitted herewith (required only if not
`transmitted by the International Bureau).
`[X] has been transmitted by the International Bureau.
`f
`}
`is not required, as the application was filed in the
`United States Receiving Office(RO/US).
`Amendments to the claims of the International Application
`under PCT Article 19 (35 U.S.C. 371(c) (3))
`{
`] are transmitted herewith (required only if not
`transmitted by the International Bureau).
`[¥] have been transmitted by the International Bureau,
`{[
`] have not been made; however,
`the time limit for
`making such amendments has NOT expired.
`[
`] 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.
`An assignment document for recording.
`
`A cover sheet in
`
`BEST AVAILABLE COPY
`0001
`
`TRANSMITTAL LETTER - Page 1 of 2
`Ex. 1020
`Apple v. MPH Techs. Oy
`IPR2019-00820
`
`0001
`
`Ex. 1020
`Apple v. MPH Techs. Oy
`IPR2019-00820
`
`

`

`MAR. 26. 2004 10:42AM
`i
`
`FASTH-LAW-OFFICES
`
`2
`=P.
`NO.393
`DIi1RecdPeT/PTO 26 * Son
`0/49093¢
`
`RFinz 3/26/04
`
`290, 10520SN
`
`EXPRESS MATL LABEL NO. ER6250885090S
`Date of Mailing:
`26 March 2004
`
`13.
`14,
`
`16.
`17,
`
`19.
`
`20.
`
`21.
`
`23,
`
`
`
`{
`
`compliance with 37 C.F.R. 3,28 and 3.31 is included.
`(X) A FIRST preliminary amendment.
`[KX] Applicant qualifies for Small Entity Status (37 C.F-R.
`1,.9(f) and 1.27(b)).
`(i£ any)
`] Other items or information:
`[
`[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.
`1,44.5(a) (2) paid to U.S.P.T.O-.).
` CLAIMS AS FILED
`
`
`
`For
`Number
`Number Basic Fee $1080.00
`Filed
`Hxtra
`
`
`
` $0.00
`= 0
`Total Claims 10- 20
`x $18.00
`
`
`
`1-3 = 0
`x §86,00
`Ind, Claims
`[X] Reduction by 1/2 for filing by small entity, if
`applicable. Applicant qualifies as small entity.
`$540,00
`TOTAL FILING FEE:
`(37 C.F.R.
`] Fee for recording the enclosed assignment
`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.
`{*%) A check in the amount of §540.00 to cover the above fee
`is enclosed.
`[KX] The Commissioner is hereby authorized to charge any
`additional fees which may be required, or credit any
`overpayment to Deposit Account No. 06-0243.
`Respectfully submitted,
`
`Rate
`
`
`
`$0.00
`
`ierf-fatt
`Rolf Fasth
`Registration Number 36,999
`4
`:
`
`Send all correspondence to:
`
`Rolf Fasth, Esq.
`FASTH LAW OFFICES
`629 E, Boca Raton Road
`Phoenix, AZ
`95022
`Telephone: 602-993-9099
`Facsimile: 602-942-8364
`
`TRANSMITTAL LETTER - Page 2 of 2
`BEST AVAILABLE COPY
`
`0002
`
`0002
`
`

`

`“MAR. 26. 2004 10:41AM
`
`>
`nh =
`
` FASTH-LAW-OFFICES
`
`N0393 JOA490 932
`DT02 Rec'd PCT/PTO 2 6 MAN 2004
`
`REine 3/26/04 290.10520eN
`
`EXPRESS MAIL LABEL NO. BR625088509US
`Date of Mailing:
`26 March 2004
`
`TRANSMI
`
`TAL LETTER TO THE UNITED STATES DESIGNATED/ELECTED OFFICE
`(DO/EO/US) CONCERNING FILING UNDER 35 U.S.C. 371
`Attorney Docket No.:
`290,1052USN
`
`1.
`
`[X]
`
`pcT/FI02/00770
`Int'l. Application No.:
`27 SEPTEMBER 2002
`Int'l. Filing Date:
`28 SEPTEMBER 2001
`Priority Date Claimed:
`METHOD AND NETWORK FOR ENSURING
`Title of Invention:
`SECURB FORWARDING OF MESSAGES
`Sami Vaarala, Antti Nuopponen
`Applicant(s) for DO/ES/US:
`Applicant herewith submits to the United States
`Designated/Blected/Office (DO/EO/US)
`the foliowing items and
`other information:
`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.
`This is an express request to begin national examination
`procedures (35 U.S.C. 371(f)) at any time rather than
`delay examination until the expiration of the applicable
`time limit set in 35 U.S.C. 371(b) and PCT Articles 22
`and 39(1).
`
`[
`
`]
`
`[x]
`
`[3]
`
`(x)
`
`oo
`
`(x)
`
`aavpb
`
`[X]
`
`Tes
`
`C
`
`J
`
`A proper Demand for International Preliminary Examination
`was made by the 19th month from the earliest claimed
`priority date.
`A copy of the International Application as filed
`(35 U.S.C. 371 (c) (2)
`[
`]
`is transmitted herewith (required only if not
`transmitted by the International Bureau).
`[X] has been transmitted by the International Bureau.
`f
`}
`is not required, as the application was filed in the
`United States Receiving Office(RO/US).
`Amendments to the claims of the International Application
`under 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.
`[
`] 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.
`An assignment document for recording.
`
`A cover sheet in
`
`TRANSMITTAL LETTER - Page 1 of 2
`
`BEST AVAILABLE COPY
`0003
`
`0003
`
`

`

`MAR. 26. 2004 10:42AM
`i
`
`FASTH-LAW-OFFICES
`
`2
`=P.
`NO.393
`DIi1RecdPeT/PTO 26 * Son
`0/49093¢
`
`RFinz 3/26/04
`
`290, 10520SN
`
`EXPRESS MATL LABEL NO. ER6250885090S
`Date of Mailing:
`26 March 2004
`
`13.
`14,
`
`16.
`17,
`
`19.
`
`20.
`
`21.
`
`23,
`
`
`
`{
`
`compliance with 37 C.F.R. 3,28 and 3.31 is included.
`(X) A FIRST preliminary amendment.
`[KX] Applicant qualifies for Small Entity Status (37 C.F-R.
`1,.9(f) and 1.27(b)).
`(i£ any)
`] Other items or information:
`[
`[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.
`1,44.5(a) (2) paid to U.S.P.T.O-.).
` CLAIMS AS FILED
`
`
`
`For
`Number
`Number Basic Fee $1080.00
`Filed
`Hxtra
`
`
`
` $0.00
`= 0
`Total Claims 10- 20
`x $18.00
`
`
`
`1-3 = 0
`x §86,00
`Ind, Claims
`[X] Reduction by 1/2 for filing by small entity, if
`applicable. Applicant qualifies as small entity.
`$540,00
`TOTAL FILING FEE:
`(37 C.F.R.
`] Fee for recording the enclosed assignment
`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.
`{*%) A check in the amount of §540.00 to cover the above fee
`is enclosed.
`[KX] The Commissioner is hereby authorized to charge any
`additional fees which may be required, or credit any
`overpayment to Deposit Account No. 06-0243.
`Respectfully submitted,
`
`Rate
`
`
`
`$0.00
`
`ierf-fatt
`Rolf Fasth
`Registration Number 36,999
`4
`:
`
`Send all correspondence to:
`
`Rolf Fasth, Esq.
`FASTH LAW OFFICES
`629 E, Boca Raton Road
`Phoenix, AZ
`95022
`Telephone: 602-993-9099
`Facsimile: 602-942-8364
`
`TRANSMITTAL LETTER - Page 2 of 2
`BEST AVAILABLE COPY
`
`0004
`
`0004
`
`

`

`?
`Q@. Gct 03 19:16
`
`Innopat Oy
`
`10/490932
`Rec'd PCT/PTG +26 MAR 2004
`+358 93 2517 S378
`Pp
`
`5
`
`?
`«|
`eT) Fie 2 00
`
`77
`
`ETHOD AND NETWORK FOR £E
`MESSAGES
`
`NG SECURE FORWARDING OF
`
`L
`
`5
`
`TECHNICAL FIELD
`
`The method and network of the invention is intended to secure mobile connectionsin
`“-"" telecommunication networks: Especially,itis-meant for-IPSecconnections:.-. ..... 0.6 Rake ennbe:
`
`10 The invention provides a method for ensuring secure forwarding of a message in a
`telecommunication network, comprising at least one mobile terminal and another
`terminal, when the mobile terminal moves from a first address to a second address
`and there is a secure connection established between thefirst address of the mobile
`terminal and the other terminal, which secure connection defines at
`least
`the
`addresses of the two terminals. The invention also provides a network for performing
`such a method.
`
`15
`
`TECHNICAL BACKGROUND
`
`20
`
`A
`An internetwork is a collection of individual networks connected with intermediate
`networking devices and functions as a single large network. Different networks can be
`interconnected by routers and other networking devices to create an internetwork.
`
`
`
`25 A local area network (LAN)is a data network that coversarelatively 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
`relatively broad geographic area. Wide area networks (WANs) interconnect LANs
`across normal
`telephone
`lines and,
`for
`instance, optical networks;
`thereby
`30=interconnecting geographically disposed users.
`
`BESTAVAILABLE COPY
`
`0005
`
`0005
`
`

`

`J*Oct o3 19:16
`
`Innopat Oy
`
`+358 9 2517 5378
`
`Pes
`
`PT/ Fb ts 0077
`
`8
`
`2
`
`There is a need to protect data and resources from disclosure, to guarantee the -
`authenticity of data, and to protect systems from network based attacks. More in detail,
`there is a need for confidentiality (protecting the contents of data from being read),
`integrity (protecting the data from being modified, which is a property that
`is
`-
`independent of confidentiality), authentication (obtaining assurance about the actual
`senderof data), replay protection (guaranteging that data is fresh, and not a copy of —
`previously sent data), identity protection (keeping the identities of Parties exchanging -
`* data secretfromoutsiders), high availability; ise. denial-of-service protection:(ensuring®..2 *ers.+:
`that the system functions even when under attack) and access control. IPSec is.a
`technology providing most of these, butnot all of them. (In particular, identity protection
`is not completely handled by IPSec, and neitheris denial-of-service protection.)
`
`The IP security protocols (IPSec) provides the capability fo secure communications
`between arbitrary hosts, e.g. across a LAN, across private and public wide area -.
`networks (WANs) and across the internet. IPSec can be usedin different Ways, such
`as for building secure virtual private networks, to gain a secure access to a company
`network, or to secure communication with other organisations, ensuring authentication
`and confidentiality and providing a key exchange mechanism,
`IPSec ensures
`confidentiality
`integrity,
`authentication,
`replay
`protection,
`limited
`traffic
`flow
`confidentiality, limited identity protection, and access control based on authenticated
`identities. Even if some applications already have built in security protocols, the use of
`IPSecfurther enhances the security.
`
`~
`
`IPSec can encrypt and/or authenticate traffic at IP level. Traffic going in to a WANis
`typically compressed and encrypted andtraffic coming from a WANis decrypted and
`decompressed. IPSec is defined by certain documents, which contain niles for the
`IPSec architecture. The documents that define IPSec, are, for the time being, the
`Request For Comments (RFC)series of the Intemet Engineering Task Force (IETF),. in
`particular, RFCs 2401-2412.
`
`Two protocols are used to provide security at the IP layer, an authentication protocol
`designated by the headerof the protocol, Authentication Header (AH), and a combined
`
`10
`
`15
`
`20
`
`25
`
`30
`
`
`
`NWSEERseeare
`
`0006
`
`0006
`
`

`

`4.
`
`O-Oet 03 19:16
`
`Innopat Oy
`
`#358 3 2517 S378
`
`pP-&
`
`3
`
`encryption/authentication protocol designated by the format of the. packet for that
`protocol, Encapsulating Security Payload (ESP). AH and ESP are however similar
`protocols, both operating by adding a protocol header. Both AH and ESP are vehicles
`for access contro! based onthe distribution of cryptographic keys and the management
`oftraffic flows related to these security protocols.
`
`5
`
`10
`
`Security association (SA) is a key conceptin the authentication and the confidentiality
`“oSs"~ “mechanisinsfor 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-
`_wayrelationship is needed, then two security associations are required. If ESP and AH
`are combined, or if ESP and/or AH are applied more than once, the term SA bundle is
`used, meaning that two or more SAs are used, Thus, SA bundle refers to one or more
`SAs applied in sequence, e.g. by first performing an ESP protection, and then an AH
`protection. The SA bundle is the combination of all SAs used to secure a packet.
`,
`
`15
`
`The term IPsec connection is used in whatfollows in place of an IPSec bundle of one
`or more security associations, or a pair of IPSec bundles — one bundie 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.
`
`A security association is uniquely identified by three parameters. The first one, the
`Security Parameters Index (SPI), is a bit string assigned to this SA. The SPI is carried
`_in AH and ESP headers to enable the receiving system to select the SA under which a
`received packet will be processed. IP destination address is the second parameter,
`wnich 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.
`
`20
`
`25
`
`30
`
`
`
`0007
`
`

`

`} Oct o3 19:16
`
`Innopat Oy
`
`- +358 9 2517 5378
`
`p.7
`
`eT / Fokhc8 OME
`
`4
`
`there is a nominal security association data, base
`In each IPSec implementation,
`(SADB)
`that defines the parameters associated with each SA. A security association
`is normally defined by the following parameters. The Sequence Number Counter is a
`32-bit value used to generate the sequence numberfield in AH or ESP- headers. The
`Sequence Counter Overflow is a flag indicating whether overflow of the sequence
`number counter should generate an auditable event and preventfurther transmission
`_ OfpacketsonthisSA. An Anti-Replay Windowis: used to determine whether an
`inbound AH or ESP packet is a replay.AH informationinvolves information about the —*
`authentication algorithm, keys and related parameters being used. with AH. ESP
`information involves information of encryption and authentication algorithms, keys,
`initialisation vectors, and related parameters being used with IPSec. The sixth
`parameter, Lifetime of this Security Association, is a time-interval and/or byte-count
`after which a SA must be replaced with a new SA (and:new SPI) or terminated plus an
`indication of which of these actions should occur. IPSec Protocol Modeis either tunnel
`or transport mode. Path MTU, which is an optional feature, defines the maximum size
`of a packetthat can be transmitted without fragmentation.
`
`Both AH and ESP support two modes used,transport and tunnel mode.
`
`Transport mode provides protection primarily for upper layer protocols and extends to
`the payload of an IP packet. Typically,
`transport mode is used:for end-to-end
`communication between two hosts. Transport mode may be used in conjunction with a
`tunnelling protocol (other that IPSec tunnelling).
`i
`
`10
`
`15
`
`20
`
`Tunnel mode provides protection to the entire IP packet and is generally used for
`sending messages through more than two components, although tunne! mode may
`also be used for end-to-end communication between two hosts. Tunnel modeis often
`used when one or both ends of a SA is a security gateway, such asafirewall or a
`router that implements iPSec. With tunne!] 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 extemal
`
`30
`
`Syeae
`
`0008
`
`0008
`
`

`

`O@ Oct 03 19:17
`
`Innopat Oy
`
`+358 9 2517 5378
`
`PT/ Fe *® 2700779
`
`5
`
`networks by tunnel mode SAs set up by the JPSec software in the firewall or secure
`router at boundary of the loca! 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 innerIP packet.’ Becausé the original packet is encapsulated, “thénew larger’
`packet may havetotally different sourceand destination addresses, adding to the
`security. In other words, the-first step in protecting the packet using tunne! modeis-to
`add a new IP header to the packet; thus the “IP|payload" packet becomes
`“IP |IP | payload".-The next step is to secure the packet using ESP ‘and/or AH. In case
`of ESP, the resulting packet is "IP|ESP|IP|payload". The whole inner packet is
`covered by the ESP and/or AH protection. AH also protects parts of the outer header,
`in addition to the whole inner packet.
`,
`
`~
`
`in such a way that if a host on a network
`The IPSec tunnel mode operates e.g.
`‘ generates an IP packet with a destination address of another host.on another network,
`the packet is routed from the originatinghost to a security gateway (SGW),firewall or
`other secure router at the boundary ofthefirst network. The SGW orthelikefilters 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 and
`encapsulates the packet in an outer |P header. The source IP address of this outer IP
`headeris 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 theother host’s
`firewall with intermediate routers examining only the outer IP header. At the other host
`firewall, the outer IP headeris strippedoff and the inner packet is. delivered to the other
`host
`
`ESP in tunne] 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, including the inner IP header, and selected portions of the outer IP header.
`
`10
`
`15
`
`20
`
`25
`
`SOIT
`
`0009
`
`0009
`
`

`

`0: @ct 03 °19717
`
`Innopat Oy
`
`#358 39 2517 5378
`
`p-3
`
`PO/ Fl’ ty ga77a
`
`6
`
`The key management portion of IPSec involves the determination and distribution of
`secret keys. The default automated key managementprotocol for IPSec is referred to
`as ISAKMP/Oakley and consists of the Oakley key determination protoco! and internet
`Security Association and Key Management Protocol (ISAKMP). Internet key exchange
`(IKE) is a newer name for the ISAKMP/Oakley protocol, [KE is based on the Diffie-
`Hellman algorithm and supports RSA signature authentication among other modes.
`IKE is an extensible protocol, and allows future and EN features to be
`added without compromising functionality.”
`
`10
`
`15
`
`IPSec has been designed to provide confidentiality, integrity, and replay protection for
`IP packets. However, IPSec is intended to work with static network topology, where:
`hosts are fixed to certain subnetworks. For instance, when an IPSec tunne! has been
`formed by using Internet Key Exchange (IKE) protocol, the tunnel endpoints are fixed
`
`and remain constant. if |PSec is used with a mobile host, the IKE key exchange will:
`have to be redone from every new visited network. This is problematic, .because IKE
`key exchanges involve computationally expensive Diffie-Hellman key exchange
`algorithm calculations and possibly RSA calculations. Furthermore, the key exchange
`requires at least three round trips (six messages). if using the IKE aggressive mode -
`followedby IKE quick mode, and nine messages if using IKE main modefollowed by
`IKE quick mode. Fhis may be a big problem in high latency networks, such as General
`
`Packet Radio Service (GPRS) regardless of the computational expenses.
`
`:
`
`In this text, the term mobility and mobile terminal does not only mean physical mobility,
`instead the term mobility is in the first hand meant moving from one. network to
`
`“25
`
`another, which can be performed by a physically fixed terminal as well..
`
`The problem with standard I|PSec tunnel end points are that they are fixed. A SA is
`
`bound to a certain IP address, and if it is changed, the existing IPSec SA becomes
`
`30
`
`useless because it has been established by using different endpoint addresses. The
`problem has been discussed in the IETF standardisation forum, www.lIETF_org,
`wherein an idea to support mobility for IPSec ESP tunnels by meansof signalling to
`
`0010
`
`0010
`
`

`

`i0-Oct OF 19:17
`
`Innopat Oxy
`
`.
`
`|.
`
`+358 9 2517 5378
`
`p-.10
`
`We F bk ef agrTg
`
`7
`
`update the address of one end |after a movement was mentioned by Francis Dupont.
`No solutions have however bee presented until this date.
`
`The standard Mobile IP protoco} 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
`very limited. The mobility signalling messages are authenticated, but not encrypted,
`‘and usér data traffic is completely unprotected. Also,
`théreis*no key exchange
`mechanism for establishing the
`cryptographic keys required for authenticating the
`mobility signalling, Such keys |need to be typically distributed manually. Finally, the
`current Mobile IP protocol does
`not define a method for working through Network
`
`Address Translation (NAT) devices.
`
`10
`
`A wayto solve this problem istouse e.g. Mobile IP to handle the mobility of the host,
`and use IPSec on top of the static IP address provided by the Mobile IP. Thus, the
`15
`IPSec SAs are bound to static addresses, and the IPSec SAs can survive mobility of
`the host. However, this approach
`suffers from packet size overhead of both Mobile IP
`ect performance considerably when using links with
`and IPSec tunnels, which can.
`
`small throughput.
`
`20
`
`
`
`
`
`
`The documents that define IP in general are the RFC standards RFC 768, RFC 791,
`RFC 793, RFC 826 and RFC 2460. RFC 2002, RFC 2003, RFC 2131, RFC 3115,
`MOBILEIpv4 and IPv6, and DHCPV6 define Mobile IP, IP-IP and DHCP.
`
`25
`
`
`Prior art solutions in this technical area are presented in WO 01 39538, WO 00 41427,
`WO 01 24560, US 2001/009025 and EP 1 24 397.
`
`30
`
`In WO 01 39538,WO 00 41427), WO 01 24560 and EP 1 24 397, a secure connection,
`which in the two first emntioned
`onesis an iPSec SA connection, is transferred from
`one access poini
`to another|in a hand-over situation of a mobile terminal. US
`2001/009025 generally presents
`a secure communication method by means of an IP
`Sec SA connection.
`
`‘ART 34 AMDT
`
`CoSRSee
`
`0011
`
`

`

`——— So —_—_-
`
`pr /
`
`fF
`
`ft
`
`@® «7007790
`
`REFERENCES
`
`Thefollowingis a list of useful references of standards mentioned.
`
`5
`
`IP ingeneral, TCP and UDP:
`
`[RFC768]
`
`~ ftpvAtp.isi.edu/in-notes/fic76B.tc
`
`= 9 -
`
`J. Postel, UserDatagram Protocol, RFC 768, August 1980.
`
`are
`
`Boge Hae
`
`10
`
`15
`
`20
`
`[RFC791]
`J. Postel, intemet Protocol, RFC 791, September 1981.
`fip://ftp.isi.
`otes/ric79
`
`[RFC792]
`J. Postel, Internet Contro! Message Protocol, RFC 792, September 1981.
`ftp-//itp.isi.edu
`c792.
`
`[RFC793]
`J. Postel, Transmission Control Protocol, RFC 793, September 1981. -
`d
`edu/in-potesirte
`:
`
`[RFC826]
`D.C. Plummer, An Efthemmet Address Resolution Profoco/, RFC 826, November
`
`25
`
`1982.
`
`ftp:/Atp.isi.edu/in-note:
`
`[RFC2460]
`S. Deering, R. Hinden, Internet Protocol, Version 6 (IPv6) Specification, RFC
`2460, December 1998.
`
`30
`
`Emofaneervoit
`
`IN Abt.
`
`
`
` At 34 ANOT
`
`IT: 1 TEESE
`
`0012
`
`0012
`
`

`

`—— +
`
`c-=
`
`i "2700774
`
`Mobile IP; IP-IP; DHCP:
`
`[RFC2002]
`C. Perkins, /P Mobility Support, RFC 2002, October 1996.
`fto:/Aitp.isi.edu/in-notes/rfic2002. bt
`
`10
`
`15
`
`{RFC2003]
`C. Perkins, /P Encapsulation Within IP, RFC 2003, October 1996.
`fip:/fip
`isi.edu/in-notes/rfc2003.b¢
`»
`DP
`ert
`Asin
`Shut
`
`(RFC2131]
`R. Droms, Dynamic Host Configuration Protocol, RFC 2131, March 1997.
`fipy/,
`edu/in-notes/
`31 bet
`:
`
`[RFC3115]
`G. Dommety, and K. Leung, Mobile IP Vendor/Organization-specific Extensions,
`RFC 3115, April 2001.
`fip-//itp.is
`in-n
`fc3115.ba
`
`a,
`‘
`.
`[MOBILEIPv6]
`D. B. Johnson, C. Perkins, Mobility Supportin IPv6, Work in progress(Internet-
`Draft is available), July 2000.
`
`25
`
`[DHCPV6]
`J. Bound, M. Carney, C. Perking, R.Droms, Dynamic Host Configuration
`Protocol forIPv6 (DHCPv6), Work in progress (Internet-Draft is available), June
`2001.
`
`30
`
`IPsec standards:
`
`[RFC2401]
`
`ART 34 AMDT
`Enpfangszeit 30.Okt- 17: | Gaxneeneeeeeee=
`
`0013
`
`

`

`PTV Fie 27 Oa77 g
`
`10
`
`S. Kent, and R. Atkinson, Security Architecture for the Internet Protocol, RFC
`2401, November 1998,
`
`fto//ftp.isi.edu/in-notes/ric2401 be
`
`5
`
`[RFC2402]
`
`S. Kent, and R. Atkinson, /P Authentication Header, RFC 2402, November
`
`1998.
`
`Jiftp isiedufin-notes/rfc2402
`
`10
`
`[RFC2403}
`C. Madson, R. Glenn, The Use of HMAC-MD5-96 within ESP and AH, RFC
`2403, November 1998.
`
`15
`
`,
`
`20
`
`25
`
`{(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-CBCCipherMeare With Explicit
`
`IV, RFC 2405, November 1998.
`
`[RFC2406]
`S. Kent, and R. Atkinson, /P Encapsulating Security Payload (ESP), RFG 2406,
`November 1998.
`Jiftp.isi.edufin-not
`
`406.
`
`[RFC2407]
`D. Piper, The intemet IP Security Domain ofineterataticts forISAKMP, RFC
`2407, November 1998.
`
`30
`
`fip:/MRtp.isi.edu/sin-notes/rfc2407.b¢
`
`[RFC2408]
`
` Empfansszeit 30.0kt.
`
`0014
`
`

`

`PT 7 Fd ™@
`
`* O07 7G
`
`D. Maughan, M. Schneider, M. Schertler, and J. Turner, /nternet Secunity
`Association and Key Management Protocol (ISAKMP), RFC 2408, November.
`1998,
`
`fip/Atp.(si.edu/in-notes/ric2408tt
`
`[RFC2409]
`D. Harkins, and D. Carrel, The Internet Key Exchange (IKE), RFC 2409,
`November 1998.
`
`' RovAtp.isi,edu/in-notes/ric2409.ba
`
`[RFC2410}
`R. Glenn, S. Kent, The NULL Encryption Algorithm and Its Use With IPsec, RFC
`2410, November 1998.
`
`[RFC2411]
`R. Thayer, N. Doraswamy, R. Glenn, JP Security Document Roadmap, RFC
`2411, November 1998.
`
`10
`
`1S
`
`20
`
`[RFC2412]
`H. Orman, The OAKLEY Key Determination Protocol, RFC 2412, November
`1998,
`
`NAT:
`
`[RFC2694]
`P. Srisuresh, G. Tsirtsis, P. Akkiraju, and A. Heffernan, DVS extensions to
`Network Address Translators (DNS_ALG), RFC 2694, September 1999.
`
`[RFC3022]
`
`30
`
`P. Shisuresh, K. Egevang, Traditional [P Network Address Translator
`(Traditional NAT), RFC 3022, January 2001.
`fip://tp.isi.edu/in-notes/rfc3022.b¢
`;
`
`Eapfansszeit 30.0kt. 17: |eeSaree
`
`
`=aSea.
`
`0015
`
`

`

`PT/ Fis £/700770
`
`THE OBJECT OF THE INVENTION
`
`12
`
`The object of the invention is to ensure secure forwarding of messages from and to
`mobile terminals by avoiding the problemsofprior art.
`
`SUMMARYOF THE INVENTION
`
`10
`
`15
`
`20
`
`The method and network of the invention is to ensure secure forwarding of a message
`in a telecommunication network, comprising at least one first terminal and another
`terminal. In the method, the first terminal moves from a first address to a second
`address. A secure connection betweenthefirst address of the first terminal and the
`other terminal defining at least the addressesof the two terminals is established. The
`first terminal moves from the first address to a second address. The connection is
`changed to be between the second address and the other terminal by means of a ~
`request from thefirst terminal and preferably, a reply back to the first terminal.
`
`In the invention, the first terminal is movable from one network to another. Such a-
`terminal can physically be a mobile terminal or a fixed terminal.
`
`The secure connection is an |PSec connection established by forming one or more
`Security Associations (SAs) using the IPSec protocols. The request and/or the reply
`message can be protected e.g. by IPSec encryption and/or authentication, possibly
`using the same !PSec SAthat is used fortraffic protection purposes.
`
`In general, registration request and registration reply are Mobile IP terms while the
`invention is not bound to Mobile !P. In the invention, the terms request and reply are
`used in the generic sense, and may or may not berelated to Mobile IP.
`
`30
`
`The method of the inventioncan be used in different kinds of networks. If the first
`terminal and the other terminal form an end-to-end connection, the secure connection
`may be an IPSec tunnel mode ortransport mode connection. Furthermore, one of or
`= eae Se
`arace aR Ais
`BESS Siehhs t
`
`Empfansszeit 30.O0kt. 17: | Riewmenimeeteeaesa
`
`0016
`
`0016
`
`

`

`PCT / F i
`
`Feal
`
`/o00770
`
`13
`
`both of the first terminal and the other terminal can be a security gateway protecting
`one or more computers, whereby IPSec tunnel mode, or IPSec transport mode
`together with a tunnelling protocol (such as Layer 2 Tunnelling Protocol, L2TP), is used
`for the secure connection betweenthefirst terminal and the other terminal.
`
`If both terminals are mobile, a special solution is required for the situation when both,
`terminals move simultaneously in case of a so called "double jump" situation. This
`solution can be implemented e.g. by using a centralised registry of current locations of
`hosts, although otherSolutionsexist for the problem. However, the "changeable" IPSec __
`tunnel or transport mode SAs of the invention could be used in that case, too.
`
`The applicant'has solved the above problems of prior art by defining a signalling
`mechanism that allows an existing |PSec security association, that is, the syrnmetric
`encryption and authentication algorithms used for packet processing, along with their
`keys and other parameters, to be moved from one network to another. To be more
`precise, an existing IPSec tunnel endpoint can be moved in the invention from one
`point of attachment to another. For instance, an |PSec tunnel established between
`addresses A and X tunnel can be changed by using the defined signalling to be |
`between addresses B and X, using only a single roundtrip for signalling (2 messages),
`.
`or half a round trip (1 message,
`if a reply message is not.used) for signalling. The
`solution requires minimal computational overhead compared to Diffie-Hellman or
`strong authentication calculations.
`
`ie. a
`The signalling mechanism is preferably similar to the one in Mobile IP,
`registration request (RREQ) is sent to the other end of the SA followed by a
`registration reply (RREP) back to the sender of the RREQ message, both of which are
`extensible for future features and optional attributes. The RREQ/RREP message pair
`is sent from the new network, and once properly authenticated, the sender IPSec
`tunnel endpoint is updated from the old network to the new network.
`
`In case the security association used for protecting user traffic is also used for
`Signalling purposes, the reception of the RREQ message bythe other end of the SA
`
`10
`
`15
`
`20
`
`25
`
`30
`
`nore| rales he
` c— eye ae
`Emptansszeii 30-Okt. 17:1 7EXRHERHAESOS
`
`0017
`
`0017
`
`

`

`14
`
`requires a change in a normalIPSec implementation to accept a packet that appears
`to belong to a certain IPSec tunnel, but comes from a wrong address(i.e. the tunnel is
`currently between A and X, and the RREQ comes from address B). This is only
`necessary for the RREQ message. Such an implementation is provided by the
`invention;
`it is necessary to modify IPSec if IPSec is used for the RREQ/RREP
`signalling.
`In that case,
`it is required specifically for processing of the RREQ and
`RREP messages,if the reply messageis to be used.
`
`' The request message mayupdate a setofsecurity associations, for instance, asingle_ -
`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
`importantif separate IPSec connections are usedfordifferent kindsof traffic. A single
`request message can then updat