'F—"MAR. 25. 2004 10:41AM
`if
`
`FASTH-LAW-OFFIC£S
`
`910.3931 (1/ 4 90 932
`0102 ne'chme'z 6m 2001
`
`‘
`
`an“ snuu snowmen
`
`EXPRESS MAIL LABEL NO. ER625088509US
`Date of Mailing:
`26 March 2004
`
`TRANSMITEAL LETTER TO THE UNITED STREES DESIGNAEED/ELECTED OFFICE
`(DO/EO/UB) CONCERNING FILING UNDER 35 U.S.C. 371
`
`Attorney Docket No.:
`
`290.1052USN
`
`Int'l. Application No.:
`Int'l. Filing Date:
`Priority Date Claimed:
`Title of Invention:
`
`Applicant(s} for DO/ES/US:
`
`PCT/FI02/00770
`27 SEPTEMBER 2002
`23 SEPTEMBER 2001
`METHOD AND NETWORK FOR ENSURING
`SECURE FORWARDING OF MESSAGES
`Sami Vaarala, Antti Nuopponen
`
`Applicant herewith submits to the United States
`Designeted/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.
`
`2.
`
`[
`
`] This is a SECOND or SUBSEQUENT submission of items
`concerning a filing under 37 U.S.C. 371.
`
`1
`
`3.
`
`4.
`
`5.
`
`7.
`
`9.
`
`11.
`
`12.
`
`[X] 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)-
`
`[H] A proper Demand for International Preliminary Examination
`was made by the 19th month from the earliest claimed
`priority date.
`
`a.
`
`[x] A copy of the International Application as filed
`(35 U.S.C. 371(c)(2)
`[
`1
`is transmitted herewith {required only if not
`transmitted by the International Bureau).
`[X] has been transmitted by the International Bureau.
`[
`I
`is not required, as the application was filed in the
`United States Receiving OfficetRO/US).
`
`b.
`c
`
`a.
`
`[X] Amendments to the claims of the International Application
`under PCT Article 19 (35 U.S.C. 371(c)(3))
`t
`] are transmitted herewith (required only if not
`transmitted by the International Bureau).
`[K] have been transmitted by the International Bureau.
`[
`1 haVe not been made; however,
`the time limit for
`making such amendments has NOT expired.
`] have not been made and will not be made-
`
`b.
`c.
`
`d.
`
`I
`
`[X] An oath or declaration of the inventor
`{35 U.S.C. 371(c)(4)).
`
`(unsigned)
`
`L
`
`L
`
`1 An Information Disclosure Statement under 37 C.F.R. 1.97
`and 1.93.
`
`] 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
`-+
`
`nr:nx siesta!
`
`290.1052usn
`
`FASTH-LAW-OFFICES
`
`N0.393
`P.
`2
`10/49 093
`0111 Hec’dPGTIPTO
`2 6 m
`EXPRESS MAIL LABEL NO. ER625UBBSOBUS
`Date of Mailing:
`26 March 2004
`
`in.
`
`compliance with 37 C.F.R. 3.28 and 3.31 is included.
`
`13.
`
`[x]
`
`A FIRST preliminary amendment.
`
`14.
`
`[x1
`
`Applicant qualifies for Small Entity Status {37 C.F.R.
`1.9(f) and 1.27(b)).
`
`16.
`
`[
`
`1
`
`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.
`1.44.5(alt2) paid to U.S.P.T.O.).
`
`For
`
`
`CLAIMS AS FILED
`Number Basic Fee $1080.00
`Extra
`
`Number
`Filed
`
`Rate
`
`
`
`
`
`
`Total Claims
`
`10 — 20
`
`= 0
`
`a $18.00
`
`$0.00
`
`Ind. Claims
`
`1 - 3
`
`3 $86.00
`
`$0.00
`
`19.
`
`[x]
`
`Reduction by 1/2 for filing by small entity, if
`applicable. Applicant qualifies as small entity.
`TOTAL FILING FEE:
`
`$540.00
`
`20.
`
`[
`
`1
`
`21.
`
`{x}
`
`23. on
`
`Fee for recording the enclosed assignment {3? C.F.R.
`l.21(h)).
`The assignment must be accompanied by an
`appropriate cover sheet
`(37 C.F.R. 3.23, 3.31).
`$40.00
`per property.
`A check in the amount of $540.00 to cover the above fee
`is enclosed.
`
`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.
`
`Q
`
`in
`
`R0 f Fasth
`
`Registration Number 36,999
`
`Send all correspondence to:
`
`Rolf Fasth, Esq.
`FASTH LAW OFFICES
`629 E. Boca Baton Road
`85022
`Phoenix, AZ
`Telephone: 602-993-9099
`Facsimile: 602-942-8364
`
`TRANSMITTAL LETTER — Page 2 of 2
`
`BEST AVAILABLE COPY
`0002
`
`0002
`
`

`

`'F—"MAR. 25. 2004 10:41AM
`.5
`
`FASTH-LAW-OFFIC£S
`
`910.3931 (1/ 4 90 932
`umzndecTrPTo'z 6m not
`
`‘
`
`an“ snuu awnfimmu
`
`EXPRESS MAIL LABEL NO. ER625088509US
`Date of Mailing:
`26 March 2004
`
`TRANSMITEAL LETTER TO THE UNITED STAEES DESIGNAIED/ELECTED OFFICE
`(DO/EO/UB) CONCERNING FILING UNDER 35 U.S.C. 371
`
`Attorney Docket No.:
`
`290.105205N
`
`Int'l. Application No.:
`Int'l. Filing Date:
`Priority Date Claimed:
`Title of Invention:
`
`Applicant(s} for DO/ES/US:
`
`PCT/FI02/00770
`27 SEPTEMBER 2002
`23 SEPTEMBER 2001
`METHOD AND NETWORK FOR ENSURING
`SECURE FORWARDING OF MESSAGES
`Sami Vaarala, Antti Nuopponen
`
`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.
`
`2.
`
`[
`
`] This is a SECOND or SUBSEQUENT submission of items
`concerning a filing under 37 U.S.C. 371.
`
`1
`
`3.
`
`4.
`
`5.
`
`7.
`
`9.
`
`11.
`
`12.
`
`[x] This is an express request to begin national examination
`procedures {35 0.8.0. 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)-
`
`[H] A proper Demand for International Preliminary Examination
`was made by the 19th month from the earliest claimed
`priority date.
`
`a.
`
`[x] A copy of the International Application as filed
`(35 U.S.C. 371(c)(2)
`[
`1
`is transmitted herewith {required only if not
`transmitted by the International Bureau).
`[X] has been transmitted by the International Bureau.
`[
`1
`is not required, as the application was filed in the
`United States Receiving OfficetRO/US).
`
`b.
`c
`
`a.
`
`[X] Amendments to the claims of the International Application
`under PCT Article 19 (35 U.S.C. 371(c)(3))
`t
`] are transmitted herewith (required only if not
`transmitted by the International Bureau).
`[K] have been transmitted by the International Bureau.
`[
`1 hays not been made; however,
`the time limit for
`making such amendments has NOT expired.
`] have not been made and will not be made-
`
`b.
`c.
`
`d.
`
`I
`
`[X] An oath or declaration of the inventor
`{35 U.S.C. 371(c)(4)).
`
`(unsigned)
`
`L
`
`L
`
`1 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
`-+
`
`nr:nx siesta!
`
`290.1052usn
`
`FASTH-LAW-OFFICES
`
`N0.393
`P.
`2
`10/49 093
`0111 Hec’dPGTIPTO
`2 6 m
`EXPRESS MAIL LABEL NO. ER625UBBSOBUS
`Date of Mailing:
`26 March 2004
`
`in.
`
`compliance with 37 C.F.R. 3.28 and 3.31 is included.
`
`13.
`
`[x]
`
`A FIRST preliminary amendment.
`
`14.
`
`[x1
`
`Applicant qualifies for Small Entity Status {37 C.F.R.
`1.9(f) and 1.27(b)).
`
`16.
`
`[
`
`1
`
`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.
`1.44.5(alt2) paid to U.S.P.T.O.).
`
`For
`
`
`CLAIMS AS FILED
`Number Basic Fee $1080.00
`Extra
`
`Number
`Filed
`
`Rate
`
`
`
`
`
`
`Total Claims
`
`10 — 20
`
`= 0
`
`a $18.00
`
`$0.00
`
`Ind. Claims
`
`1 - 3
`
`3 $86.00
`
`$0.00
`
`19.
`
`[x]
`
`Reduction by 1/2 for filing by small entity, if
`applicable. Applicant qualifies as small entity.
`TOTAL FILING FEE:
`
`$540.00
`
`20.
`
`[
`
`1
`
`21.
`
`{x}
`
`23. on
`
`Fee for recording the enclosed assignment {3? C.F.R.
`l.21(h)).
`The assignment must be accompanied by an
`appropriate cover sheet
`(37 C.F.R. 3.23, 3.31).
`$40.00
`per property.
`A check in the amount of $540.00 to cover the above fee
`is enclosed.
`
`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.
`
`Q
`
`in
`
`R0 f Fasth
`
`Registration Number 36,999
`
`Send all correspondence to:
`
`Rolf Fasth, Esq.
`FASTH LAW OFFICES
`629 E. Boca Baton Road
`85022
`Phoenix, AZ
`Telephone: 602-993-9099
`Facsimile: 602-942-8364
`
`TRANSMITTAL LETTER — Page 2 of 2
`
`BEST AVAILABLE COPY
`0004
`
`0004
`
`

`

`(1»- Dcc 053 19:16
`
`Innopat. 05
`
`ton-909 32
`Redd PCT/PTO 2 6 MAR 2004
`+358 9 251? 5378
`p
`
`'
`
`1,"
`it'
`it‘llFl-J-iflfl
`
`?7
`
`ETHOD AND NETWORK FOR E
`
`NG SECURE FORWARDING OF
`
`I.
`
`M
`
`5
`
`TECHNICAL FIELD
`
`The method and network of the invention is intended to some mobile connections in
`
`' “telecommunication networkerspeciallyyit-isrmeantfor~lPSec.connections.--.- -
`
`.
`
`to
`
`‘l'he invention provides a method for ensuring secure fomarding 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 the first address of the mobile
`
`terminal and the other tenninal. which secure connection defines at
`
`least
`
`the
`
`15
`
`addresses of the two terminals. The invention also provides a network for perforating
`such a method.
`
`TECHNICAL BACKGROUND
`
`20
`
`_
`
`An intemetworls 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 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
`
`relatively broad geographic area. Vlfide area networks (WANs) interconnect LANs
`
`across normal
`
`telephone
`
`lines and.
`
`for
`
`instance. optical networks;
`
`thereby
`
`30
`
`interconnecting geographically disposed users.
`
`BESTAVAILABLE com
`
`0005
`
`0005
`
`

`

`)tflct 05 19:15
`
`Innopat 03
`
`+358 3'2517 537B
`
`P.5
`
`‘
`
`5
`
`to
`
`15‘
`
`20
`
`25
`
`30
`
`PCT/Flii':ii’007?@
`
`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
`sender of data). replay protection (guaranteeing that data is fresh. and not a copy of '
`previously sent data). identity protection (keeping the identities of parties exchanging »
`" data secret'fror‘n‘ outsiders). high availability; i;e; denial—of—service protectiorn(ensuring= .
`that the system functions even when under attack) and access control- IPSec is -a
`technology providing most of these. but not all of them- (In particular. identity protection
`is not completely handled by IPSec. and neither is denial-of-service protection.)
`
`.--:-.- .-
`
`-
`
`The IP security protocols (lPSec) provides the capability to sea-ire communications
`between arbitrary hosts. e.g. across a LAN, across private and public wide area .,
`networks (WANs) and across the intamet. IPSec can be used in different ways such
`as for building secure virtual private networks to gain a secure access to a company
`network or to secure 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
`IPSec further enhances the security-
`
`'
`
`IPSec can encrypt andlcr authenticate traffic at [P level. Traffic going in to a WAN is
`typically compressed and encrypted and traffic coming from a WAN is decrypted and
`decompressed- IPSec is defined by certain documents, which contain rules for the
`iPSec architecture. The documents that define iPSec, are. for the time being. the
`Request For Comments (RFC) series of the lntemet Engineering Task Force (lEl‘F).. in
`particular, RFCs 2401 —2412.
`
`Two protocols are used to provide security at the IP layer, an authentication protocol
`designated by the header of the protocol, Authentication Header {AH}. and a combined
`
`J'F‘w
`if"...{nw‘hlfir'mflv‘i‘rq-m
`
`
`0006
`
`0006
`
`

`

`rI
`
`tract. _03 15:36
`
`Innopat. 05
`
`+359 9 2517 5379
`
`p.s
`
`3
`
`encryptionfauthentication protocol designated by the format of the. packet for that
`protocol. Encapsmating Security Payload (ESP). AH and ESP are however similar
`
`protocols. both operating by adding a protocol header. Both AH and ESP are vehicle's
`
`for access control based on the distribution of cryptographic keys and the management
`of traffic flows related to these security protocols.
`
`Security association (SA) is a key concept in the authentication and the confidentiality
`‘mechanisrnsfor IP'.__A"security association-is'a- onemy-relationship-behueen'a sender'- --
`
`‘
`
`and a receiver that ofiers security services to the traffic un’ied on it..lf a secure two-
`
`way relationship is needed, then two security associations are required. If- ESP‘and AH
`
`are combined. or if ESP andlor AH are applied more than once. the term SA bundle is
`
`used. meaning thattwo or more Site are used. Thus. SA bundle refers to one or more
`SAs applied in sequence. egg. 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
`
`The term IPsec connection is used in what follows in place of an lPSec bundle of one
`or more security associations. or a pair of lPSec bundles —— one bundle for each
`
`direction —- of one or more security associations. This term thus covers both
`unidirectional and bi—directionat tiafiic 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 SP! is carried
`
`_ in AH and ESP headers to enable the receiving system to select the SA under which a
`
`received packet will be processed. tP destination address is the second parameter,
`which is the address ofthe 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
`
`10
`
`15
`
`20
`
`25
`
`security protocol identifier indicates Mic-titer the association is an AH or ESP security
`association.
`
`3O
`
`
`
`0007
`
`

`

`J
`
`flhcc 053 19:15
`
`Innopat Us
`
`.. +353 3 2517 5378
`
`psi
`
`pgrrgsr'
`
`I‘iflflfi’fl
`
`4
`
`In each lPSeo implementation.
`
`there is a nominal security association data, base
`
`(SADB)
`
`that defines the parameters associated with each SA. A security association
`
`is normally defined by the following parameters. The Sequence Numtyer Counter is a
`
`32-bit value used to generate the sequence number field in AH or ESP-headers. The
`
`Sequence Counter Overflow is a flag indicating Mather overflow of the sequence
`
`number counter should generate an auditable event and prevent further transmission
`
`ofpackets on this SA Arr Anti-Replay Window is- used to determine. whether an
`_‘-‘*"'~'.w .r_‘--.Rf“!
`Inbound AH °" ESP Pam“at '5 a "éP'aYAH rnfonnation involves intern-ration about'th'e
`
`_.
`
`'
`
`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 lPSec. The sixth
`
`parameter. Lifetime of this Security Association. is a time—intents! andior byte-count
`
`after which a SA must be replaced with a new SA (and: new SPI) or terminated plus an
`
`indication ofwhich of these actions should owur. IPSec Protocol Mode is either tunnel
`
`or transport mode. Path MTU. which is an optional feature. defines the maximum size
`
`of a packet that can be transmitted without fragmentation.
`
`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 lPSec tunnelling}.
`
`.
`
`10
`
`15
`
`20
`
`Tunnel mode provides protection to the entire IP padtet and is generally used for
`
`sending messages through more than two components, although tunnel mode may
`
`also be used for end-to—end communimtion between two hosts- Tunnel mode isioften
`used when one or both ends of a SA is a security gateway, such as a firewall or a
`
`router that implements lPSec. lMth tunnel mode, a number of hosts on networks
`
`3O
`
`behind firewalls may engage in secure communications without implementing IPSec
`
`The unprotected packets generated by such hosts are tunnelled through external
`
`I'll:
`hm." J‘Hmwm
`
`0008
`
`0008
`
`

`

`O”- Oct. 03- 13:17
`
`Innopat. 05
`
`+353 3 2517 537a
`
`p.a
`
`PET/Flii’giflfl7i’fl
`
`5
`
`networks by tunnel mode SAs set up by the iPSec software in the firewall or secure
`
`router at boundary of the local network.
`
`To achieve this, after the AH or ESP fields are added to the .IP packet. the entire
`
`packet plus security fields are treated as the payload of a new outer IF? packet with a
`
`new outer lP,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
`' ‘ih'tié‘ii’inéi‘iii‘paéketf eéééuse‘ the original peeket'is 'ehiaosulated."tfi‘e"new larger
`packet may have totally different source. and destination addressesuadding to the
`security. In other words. the-first step in protecting the packet using tunnel mode ls‘to
`
`'
`
`add a new IP header to the packet thus the "IPI payload"- packet becomes
`“IP I IF I payload". The next step is to secure the packet using ESP'andior AH. In case
`of ESP. the resulting packet is "iPIESPIIPIpaonad". The whole inner packet .is
`covered by the ESP andior AH protection. AH also protects parts ofthe outer header.
`in addition to the whole inner packet.
`
`10
`
`15
`
`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 [St-3M, firewall or
`other sewre router at the boundary of the first network, The SGW or the like filters all
`
`20
`
`outgoing packets to determine the need for lPSec prooessing. if this packet from the
`
`first host to another host requires IPSec. the firewall perfon'ns tPSec processing and
`
`encapsulates the packet in an outer lP header. The source IP address of this outer lP
`
`header is this firewall and the. destination address may be a firewall that forms the
`
`25
`
`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. Atthe 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 audienticates 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 lP header.
`
`0009
`
`0009
`
`

`

`D‘Gct US'ISII?
`
`Innapat US
`
`+358 8 2517 5378
`
`'ifi‘EFflFi-ii‘ilflili7fl
`
`6
`
`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 iSAiOVlPIOakiey and consists of the Oakley key determination protocol and lntemet
`
`Security Association and Key Management Protocol (ISAKMP). lntemet key exchange
`(IKE) is a newer name for the lSAKMPIOakley protocol. IKE is based on the Difiie—
`
`Hellman algorithm and SUpports RSA signature authentication among other modes.
`
`IKE is an extensible protocol, and allows future and vendor-specific features to be
`
`added without—compromising mnotionality_r- A
`
`10
`
`15
`
`lPSec has been designed to provide confidentiality. integrity. and replay protection for
`
`IP packets. However. lPSec is intended to work with static network topology. where-
`hosts are fixed to certain subnetworlts. For instance. when an lPSec turmel has been
`
`fDlTl‘led by using Internet Key Exchange (IKE) protocol. the tunnel endpoints are fixed
`
`and remain constant. If IPSec is used with a mobile host, the "(E key exchange will-
`
`have to be redone from every new visited network. This is problematic..because IKE
`key exchanges involve computationally expensive Dime-Hellman key exchange
`algorithm calculations and possibly FtSA calculations. Furthermore, the key exchange
`
`requires at least three round trips (six messages). if using the IKE aggressive mode '
`
`followed by IKE quick mode, and nine messages if using IKE main mode followed by
`
`IKE quick mode. This may be a big problem in high latency networks. such as General
`
`Packet Radio Service (GPRS) regardless ofthe 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
`another. which can be performed by a physically fixed terminal as well,
`
`’25
`
`The problem with standard IPSec tunnel and points are that they are fixed. A SA is
`
`bound to a certain iP address. and if it is changed, the existing lPSec SA becomes
`
`useless because it has been established by using difierent endpoint addresses. The
`
`30
`
`problem has been discussed in the IETF standardisation forum, wwaETFor-g,
`
`wherein an idea to support mobility for IPSec ESP tunnels by means of signalling to
`
`0010
`
`0010
`
`

`

`ll]"Dct. as "1's:'17
`
`Innopat es
`
`'
`
`.
`
`_
`
`+353 9 2517 5379
`
`9.1.3
`
`liii‘ifi F i
`
`ii-
`
`3:5 [Siiéii‘ri'fi
`
`'1'
`
`update the address of one end after a movement was mentioned by Francis Dupent.
`No solutions have however has presented until this date.
`
`The standard Mobile IP protoco provides a mobile terminal with a mobile connection.
`
`and defines mechanisms for
`
`erforming efficient handovers ‘from one network to
`
`another. However, Mobile IP 11 5 several disadvantages. The security of Mobile IP is
`
`very limited. The mobility sign lling messages are authenfiuted, but not encrypted.
`
`'and user data—traffic is sci-rip etely unprotected. 'Also.
`
`thére' is“ no key'exchange-
`
`mechanism for establishing ih
`
`cryptographic keys required for authenticating the
`
`mobility signalling. Such keys need to be typically distributed manually. Finally. the
`
`current Mobile iP protocoldo
`
`
`
`not define a method for working through Network
`
`Address Translation (NA‘D devi es.
`
`A way to solve this problem is
`
`
`
`use e.g- Mobile IP to handie the mobility of the host,
`
`and use lPSec on top of the s atic IP address provided by the Mobile IP. Thus. the
`
`10
`
`15
`
`IPSec SAs are bound to static ddresses. and the lPSec SAs can survive mobility of
`
`the host. However, this approa
`
`and IPSec tunnels. which can.
`
`suffers from packet size overhead of both Mobile IP
`
`eotperfonnanoe considerabiy when using links with _
`
`
`
`
`
`small throughput
`
`20'
`
`The documents that define IF‘
`
`i general are the RFC standards RFC 768. RFC 791,
`
`RFC 793. RFC 826 and RFC 460. RFC 2002, RFC 2003, RFC 2131, RFC 3115,
`
`MOBILE Ipv4 and IPv6, and D CPVB define Mobile IP, IP—iP and DHCP.
`
`25
`
`Prior art solutions in this techni
`
`
`
`l area are presented in W0 01 39538. W0 00 41427.
`
`W0 01 24560, US 2001 {00902 and EP 1 24 397.
`
`In W0 01 39533,'W0 DD 4142 , W0 01 24560 and EP 1 24 397. a secure connection.
`
`which in the two first emntion
`ones is an lPSec SA connection. is transferred from
`one access point
`to another in a hand-over situation of a mobiie terminal. US
`
`3O
`
`2001i009025 generally presen
`
`a secure communication method by means of an IP
`
`Sec SA connection.
`
`
`
`0011
`
`

`

`”-w u— --.——
`
`REFERENCES
`
`~.
`
`The following is a list of useful references of standards mentioned.
`
`5
`
`IP in general, TCP and UDP:
`
`[RFCYBBI-
`
`_
`
`J. Pastel. User Datagram Protocol. RFC 768. August 1980.
`
`'-'fig‘Jfingj,‘eggglnflnleslrfc768.m -
`
`-
`
`'
`
`.; -
`
`,
`
`IO
`
`[RFCTQ1]
`
`J. Pastel. Internet Preface}. RFC 791', September 1981-
`n -
`-is'.
`ates! 79
`.
`
`15
`
`[RFC?92]
`
`J. Pastel, Internet Contra! Message Protocol. RFC 792. September 1 981.
`n um -
`.
`u
`c792.
`
`[RFCYQS]
`
`20
`
`J. Pastel. Transmissan Control Fremont. RFC-793. September 1991-.
`
`-
`
`‘J
`
`a
`
`r
`
`1
`
`'
`
`[RFCBZS]
`
`D.C. Plummer. An Ethernet Address Resoiuflan Prom. RFC 826, November
`
`25
`
`1982.
`
`a -
`
`.isi.ed :
`
`nte
`
`[RFCZ460]
`
`S. Deering. R- Hinden. Internet Protocol, Versfon 6(1Pv6) Specification. RFC
`
`30
`
`2460, December 1998.
`
` anfanEezoil' Q“ (“-1.
`
`0012
`
`

`

`'-
`
`s
`
`10
`
`Ell/Fl 5":‘23'13073’0
`
`9
`
`Mobile IP; lP-IP; DHCP:
`
`[RFCZODZ]
`
`C. Perkins, lP Mobifiar Support, RFC 2002. October 1996.
`11:!
`'.edu—oteslc20 m
`
`{RFC2003}
`
`C. Perkins, IP Enwosulation MH‘flh IP, RFC 2003. October 1996.
`
`newEistedgaflotgmfgg00342;;
`
`_.
`
`[RF02131]
`
`R. Drums. Dynamic Host Configuration Protocol. RFC 2131, March 1 997.
`fl 2
`adufin-n as!
`31.131
`‘
`
`15
`
`[RF-1:31 15]
`
`G. Dommety, and K. Leung. Mobile IP Vendor/Organization—speoific Extensions.
`RFC 3115. April 2001.
`ft 9'
`.is
`n-n
`[1’03
`
`5.13:!
`
`20
`
`[350311.51va} .
`
`D. B. Johnson. C. Perkins. Mobflfly Suppodin IPv6. Work in progress (Internet-
`Drafl is available), July 2000.
`
`[DHCPVS]
`
`25
`
`J. Bound. M. Carney. C- Parking, R.Droms, Dynamic Host Configuration
`Protocol for IPv6 (DHCPVE). Work in progress (Mamet-Draft is available). June
`2001.
`
`30
`
`lPsec standards:
`
`[RFc24o1 1
`
`Emnfansszeit 30-0kt-
`
`3.333“ :31: 3333333
`
`Ililffii‘afiu‘ifii‘lfl. 1*".
`
`0013
`
`0013
`
`

`

`PEWFE-fizzanr?n
`
`10
`
`s. Kent. and R. Atkinson, Seemity Architecture for the Internet Protocol, RFC
`
`2401. November 1993.
`
`it 3'
`
`.isi.edufin at
`
`c.2401 on
`
`5
`
`[Rf-T324021
`
`S. Kent, and R. Atkinson, (P Authentication Header. RFC 24.02. November
`
`1 998.
`
`flgllngSLedufin-HOISSIEQAOZE
`
`lo
`
`[RFCZ403}
`
`C. Madson, R. Glenn, The Use of HMAC—MD5-96 within ESP and AH. RFC
`
`2403. November 1998.
`
`[RF02404]
`
`15
`
`C. Madson, R. Glenn. The Use of HMAC—SHA-1-96 within ESP and AH, RFC
`
`2404. November 1998.
`
`[RFC-2405]
`
`_
`
`20
`
`C. Madson, N. Doraswamy. The ESP DES-CBC, Cipher Algorithm With Explicit
`
`IV. RFC 2405. November 1998.
`
`‘
`
`-
`
`[RFc24061
`
`S. Kent. and R. Atkinson. IP Enmpsuiafing Sewrt'ly Payload (ESP), RFC 2406,
`November 1998.
`
`25
`
`m .isi.edufin- at
`
`4 e.
`
`}
`
`[RFC2407]
`
`D. Piper. The infemet IP Security Domain of Interpretation forISAKMP, RFC
`2407, November 1998-
`
`30
`
`yr
`
`.iei.edufln—noteslrfc2407.
`
`[RF-02408]
`
`
`Empfansszeit 30-0“. Hue-tee":
`'
`'
`
`0014
`
`

`

`PET/VIE?fl "iflfl??fi
`
`11
`
`D. Maugham, M. Sbhneider. M. Scherfler. and J. Turner, Internet Secudbr
`Assoofafion and Key Management Protocol (ISAKMP), RFC 2408, November .
`1998.
`
`figjflo‘lsiedufln-noteslrfcztlogm
`
`5
`
`10
`
`15
`
`[RF 02409]
`
`D. Harkins. and D. Carrel, The Intemet Key Exchange (IKE), RFC 2409.
`
`November 1 998.
`
`- gmQ.i§{.edufln~nggesmg409,g
`
`[RFC2410]
`R. olefin, s. Kent. The NULL Encryption Algofithm and Its Use With IPsec, RFC
`2410, November 1 998.
`
`[RFC24‘I 1].
`R. “wafer, N. Doraswamy. R. Glenn, IP Secun‘ty Document Roadmap, RFC
`241 1 . November 1 998.
`
`20
`
`[RFCZ412]
`H. omen, The OAKLEY Key Detenninafion Protocof, RFC 2412, November
`1 998.
`'
`
`NAT:
`
`25
`
`[RFC2694]
`
`P. Srisuresh, G. Tsirtsis, P. Akkiraju, andA Heffeman. DNS extmsfons to
`
`Network Address Translators (DNS__ALG), RFC 2694. September 1999.
`
`[RFcaozz]
`
`30
`
`P. Shiswesh, K. Egevang. Traditional {P NeMorkAddress Translator
`
`(Tradibbnal NA 1). RFC 3022. January 2001-
`
`[badestggufinfloteyrfcaOflm
`
`'
`
`Enpfansszeit 30.0kt-
`
`'T"
`If:lfi?figaa - m“ '
`
`0015
`
`

`

`J
`PET/Fifil‘lflfl?7fl
`
`12
`
`THE oer-act OF THE INVENTION
`
`The object of the Invention is to ensure secure forwarding of messages from and to.
`mobile terminals by avoiding the problems of prior art
`
`SUMMARY OF THE INVENTION
`
`The method and network of the invention is to ensure secure forwarding of a message
`in a telecommunication 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 between the first address of the first terminal and the
`other terminal defining at least the addresses of the m 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 the first 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 5
`terminal can physically be a mobile terminal or a fixed terminal.
`
`10
`
`15
`
`20
`
`The secure connectionis an lPSec connection established by forming one or more
`Security Associations (5A5) using the iPSec protocols. The request andior the reply
`message can be protected e.g. by lPSec encryption andfor authentication. possibly
`using the same lPSec SA that is used for traffic protection purposes.
`
`in general. registration request and registration reply are Mobile lP 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 be related to Mobile lP.
`
`30
`
`The method of the inventions-n be used in different kinds of networks. If the first
`terminal and the other terminal form an end-to-end connection, the secure connection
`
`Emrfanaszeii 30.01511. Iilmfgmrm
`
`0016
`
`0016
`
`

`

`PCT-fFi"EIU[i?7li
`
`13
`
`both of the first terminal and the other terminal can be a security gateway protecting
`
`one or more computers. whereby lPSec tunnel mode, or lPSec transport mode
`
`together with a tunnelling protocol (such as Layer 2 Tunnelling Protocol, L2TP), is used
`
`for the secure connection between the first terminal and the other terminal.
`
`If both terminals are mobile. at special solution is required for the situation Mien both
`
`terminals move simultaneously in case of a so milled f‘double jump" situation. This
`
`solution can be implemented e.g. by using a centralised registry of current locations of
`
`hosts, although othersolutions‘ exist for the problem. However, the "changeable" lPSec .,
`
`_
`
`tunnel or transport mode 3A5 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 lPSec security association. that is, the symmetric
`
`encryption and authentication algorithms used for packet processing. along with their
`
`keys and other parameters, to be moved from one nettmrk to'another. To be more
`precise. an existing lPSec tunnel endpoint can be moved in the invention from one
`
`point of attachment to another. For instance. an lPSec tunnel established between
`
`addresses A and x tunnel can be changed by using the defined signalling to be .
`
`ID
`
`15
`
`between addresses B and X, using oniy a single round trip for signalling [2 messages),
`
`__
`
`20
`
`or half a round trip (1 message.
`
`if a reply message is not. used) for signalling. The
`
`solution requires minimal computational overhead compared to {lime-Hellman or_
`
`strong authentication calculations.
`
`The signalling mechanism is preferably similar to the one in Mobile _IP. Le. a
`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 RREOJRREP message pair
`
`is sent from the new network, and once property authenticated. the sender lPSec
`
`tunnel endpoint is updated from the old network to the new network.
`
`25
`
`30
`
`In case the security association used for protecting user traffic is also used far
`
`signalling purposes, the reception of the RREQ message by the other end of the SA
`
`,1 shaft“?
`.
`
`Empiansszeii 30.0ii. irirfiggmogsgea
`
`are"?
`-.
`
`_)._
`
`0017
`
`0017
`
`

`

`14
`
`requires a change in a normal lPSec implementation to accept a packet that appears
`to belong to a certain lPSec tunnel, but comes from a wrong address (Le. the tunnel is
`currently between A and X, and the RREQ comes from address 3). This is only
`necessary for the RREQ message. Such an implementation is provided by the
`invention;
`it is necessary to modify lPSec if lPSec is used for the RREQIRREP
`signalling.
`in that case.
`it is required specifically for processing of the RREQ and
`RREP messages, ifthe reply message is to be used.
`I
`
`' The request message may-update a set-of'security 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
`eith