`Vaarala et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 9,712,502 B2
`*Jul.18, 2017
`
`US0097.12502B2
`
`(54) METHOD AND SYSTEM FOR SENDING A
`MESSAGE THROUGH A SECURE
`CONNECTION
`
`(71) Applicant: MPH Technologies Oy, Espoo (FI)
`(72) Inventors: Sami Vaarala, Helsinki (FI); Antti
`Nuopponen, Espoo (FI)
`(73) Assignee: MPH Technologies Oy, Espoo (FI)
`
`(*) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`This patent is Subject to a terminal dis-
`claimer.
`
`(21) Appl. No.: 15/376,558
`
`(22) Filed:
`
`Dec. 12, 2016
`
`(65)
`
`Prior Publication Data
`US 2017/OO99266 A1
`Ar. 6, 2017
`pr. o.
`Related U.S. Application Data
`(63) Continuation of application No. 15,372,208, filed on
`Dec. 7, 2016, which is a continuation of application
`No. 13/ 685,544, filed on Nov. 26, 2012, which is a
`continuation of application No. 10/500,930, filed as
`application No. PCT/FIO3/00045 on Jan. 21, 2003,
`now Pat. No. 8,346,949.
`O
`O
`Foreign Application Priority Data
`
`(30)
`
`(52) U.S. Cl.
`CPC ...... H04L 63/0428 (2013.01); H04L 63/0281
`(2013.01); H04L 63/061 (2013.01)
`(58) Field of Classification Search
`USPC ......................................... 709/236, 239, 245
`S
`lication file f
`let
`h historv.
`ee appl1cauon Ille Ior complete searcn n1story
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`6,718.388 B1 * 4/2004 Yarborough ........ HO4L 63,0227
`709/217
`6.732,269 B1* 5/2004 Baskey ................. HO4L 63,166
`T13,153
`
`(Continued)
`
`Primary Examiner — Afshawn Towfighi
`(74) Attorney, Agent, or Firm — Fasth Law Offices; Rolf
`Fasth
`
`(57)
`
`ABSTRACT
`
`The method and system enable secure forwarding of a
`message from a first computer to a second computer via an
`intermediate computer in a telecommunication network. A
`message is formed in the first computer or in a computer that
`is served by the first computer, and in the latter case, sending
`the message to the first computer. In the first computer, a
`secure message is then formed by giving the message a
`unique identity and a destination address. The message is
`sent from the first computer to the intermediate computer
`after which the destination address and the unique identity
`are used to find an address to the second computer. The
`current destination address is substituted with the found
`
`Jan. 22, 2002 (FI) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 2002O112
`
`address to the second computer, and the unique identity is
`
`(51) Int. Cl
`h /32
`G06F 5/16
`H04L 29/06
`
`(2006.01)
`(2006.01)
`(2006.01)
`
`Substituted with another unique identity. Then the message
`is forwarded to the second computer.
`
`10 Claims, 6 Drawing Sheets
`
`Sectasiatic
`KE
`sistic
`
`
`
`
`
`Standard Psec
`
`3
`
`Eaced
`
`
`
`
`
`YS3standard IKE
`optional
`
`
`
`
`
`Pan packets
`
`ified
`protocol (optional)
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 1
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`US 9,712.502 B2
`Page 2
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,795,917 B1 * 9/2004 Ylonen ................... HO4L 29/06
`T13,160
`6,957.346 B1 * 10/2005 Kivinen .............. HO4L 12,4633
`T13,153
`6,985,953 B1* 1/2006 Sandhu ............... GO6F 17,3089
`709,225
`7,055,027 B1 * 5/2006 Gunter .................... HO4L 63.30
`709,223
`2001/0047487 A1* 11/2001 Linnakangas ....... HO4L 63,0428
`T26/12
`2002, 0004900 A1* 1/2002 Patel ...................... G06Q 30/02
`713,155
`2002/009 1921 A1* 7/2002 Kunzinger .......... HO4L 63,0428
`T13,153
`
`* cited by examiner
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 2
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`U.S. Patent
`
`US 9,712,502 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 3
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`U.S. Patent
`
`Jul.18, 2017
`
`Sheet 2 of 6
`
`US 9,712,502 B2
`
`
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 4
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`U.S. Patent
`
`US 9,712,502 B2
`
`
`
`
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 5
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`U.S. Patent
`
`Jul. 18, 2017
`
`Sheet 4 of 6
`
`US 9,712,502 B2
`
`
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 6
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`U.S. Patent
`
`Jul.18, 2017
`
`Sheet S of 6
`
`US 9,712,502 B2
`
`
`
`
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 7
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`U.S. Patent
`
`Jul.18, 2017
`
`Sheet 6 of 6
`
`US 9,712,502 B2
`
`identification type
`
`serf sily-Qualified-
`Dorsair-Nafise
`
`
`
`
`
`Distinguished Name
`Fily-Qualified-onair-
`Nafe
`Employee number and
`copay
`
`SGW
`certification wage
`i- access
`23.2.3
`Smithstetseai.e.
`GetSeace
`
`36.5.
`
`"CN-Sarri Waaraa,
`Cseretsea, Circo
`hostafa safe.co.
`
`"19070 NetSeaf
`ecologies"
`
`22.432
`233.
`
`123.43.
`
`
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 8
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`US 9,712,502 B2
`
`1.
`METHOD AND SYSTEM FOR SENDING A
`MESSAGE THROUGH A SECURE
`CONNECTION
`
`PRIORAPPLICATIONS
`
`This application is a U.S. Continuation patent application
`that claims priority from U.S. Continuation patent applica
`tion Ser. No. 15/372,208, filed 7 Dec. 2016 that claims
`priority from U.S. Continuation patent application Ser. No.
`13/685,544, filed 26 Nov. 2012 that claims priority from
`U.S. patent application Ser. No. 10/500,930, filed 19 Oct.
`2005, which claims priority from PCT/FIO3/00045, filed 21
`Jan. 2003, that claims priority from Finnish Pat. App. No.
`20020112, filed 22 Jan. 2002.
`
`10
`
`15
`
`TECHNICAL FIELD
`
`The method and system of the invention are intended to
`secure connections in telecommunication networks. Espe
`cially, it is meant for wireless Internet Service Provider (ISP)
`connections.
`
`TECHNICAL BACKGROUND
`
`25
`
`2
`cations 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 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 Internet Engineering Task
`Force (IETF), in particular, RFCs 2401-2412.
`Two protocols are used to provide security at the IPlayer;
`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) AH and ESP are however similar protocols,
`both operating by adding a protocol header. 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.
`Security association (SA) is a key concept in the authen
`tication and the confidentiality mechanisms for IP. A security
`association is a one-way relationship between a sender and
`a receiver that offers security services to the traffic carried on
`it if a secure two-way relationship is needed, then two
`security associations are required. If ESP and AH are com
`bined, 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.
`The term IPsec connection is used in what follows in
`place of an IPSec bundle of one or more security associa
`tions, 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.
`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 pro
`cessed. IP destination address is the second 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.
`In each IPSec 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 Number
`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 whether overflow of the
`sequence number counter should generate an auditable event
`and prevent further transmission of packets on this SA. An
`Anti-Replay Window is used to determine whether an
`inbound AH or ESP packet is a replay. AH information
`involves information about the authentication algorithm,
`keys and related parameters being used with AH. ESP
`information involves information of encryption and authen
`tication algorithms, keys, initialisation vectors, and related
`parameters being used with IPSec. AH information consists
`
`30
`
`35
`
`40
`
`An internetwork is a collection of individual networks
`connected with intermediate networking devices that func
`tion as a single large network. Different networks can be
`interconnected by routers and other networking devices to
`create an internetwork.
`A local area network (LAN) is a data network that covers
`a relatively small geographic area. It typically connects
`workstations, personal computers, printers and other
`devices. A wide area network (WAN) is a data communi
`cation network that covers a relatively broad geographic
`area. Wide area networks (WANS) interconnect LANs
`across normal telephone lines and, for instance, optical
`networks; thereby interconnecting geographically disposed
`USCS.
`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
`45
`confidentiality), authentication (obtaining assurance about
`she 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 from outsiders), high availability, i.e.
`denial-of-service protection (ensuring that the system func
`tions even when under attack) and access control. IPSec is
`a technology providing most of these, but not all of them. (In
`particulars identity protection is not completely handled by
`IPSec, and neither is denial-of-service protection.)
`The IP security protocols (IPSec) provides the capability
`to 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 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 integ
`rity, authentication, replay protection, limited traffic flow
`confidentiality, limited identity protection, and access con
`trol based on authenticated identities. Even if some appli
`
`50
`
`55
`
`60
`
`65
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 9
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`3
`of the authentication algorithm, keys and related parameters
`being used with AH. ESP information consists of encryption
`and authentication algorithms, keys, cryptographic initiali
`sation vectors and related parameters being used with ESP.
`The sixth parameter, Lifetime of this Security Association,
`is a time-interval and/or byte-count after which this 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 Mode is either tunnel or transport mode. Maximum
`Transfer Unit (MTU), an optional feature, defines the maxi
`mum size of a packet that can be transmitted without
`fragmentation. Optionally an MTU discovery protocol may
`be used to determine the actual MTU for a given route,
`however, Such a protocol is optional.
`Both AH and ESP support two modes used, transport and
`tunnel mode.
`Transport mode provides protection primarily for upper
`layer protocols and extends to the payload of an IP packet
`Typically, transport mode is used for end-to-end communi
`cation between two hosts. Transport mode may be used in
`conjunction with a tunnelling protocol, other than IPSec
`tunnelling, to provide a tunnelling capability.
`Tunnel mode provides protection to the entire IP packet
`and is usually used for sending messages through more than
`two components, although tunnel mode may also be used for
`end-to-end communication between two hosts. 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 gen
`erated by such hosts are tunnelled through external 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 IP packet with a new outer IP
`header. The entire original, or inner, packet travels through
`a tunnel from one point of an IP network to another: no
`routers along the way are able to examine the inner IP
`packet. Because the original packet is encapsulated, the new
`larger packet may have totally different source and destina
`tion addresses, adding to the security. In other words, the
`first step in protecting the packet using tunnel mode is to add
`a new IP header to the packet; thus the “IP payload packet
`becomes “IPIP payload’. The next step is to secure the
`packet using ESP and/or AH. In case of ESP, the resulting
`packet is “IPIESPIP 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. 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 or the like filters all
`outgoing packets to determine the need for IPSec process
`ing. If this packet from the first host to another host requires
`IPSec, the firewall performs IPSec processing and encapsu
`lates the packet in an outer IP header. The source IP address
`of this outer IP header 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
`hosts 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.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 9,712,502 B2
`
`10
`
`15
`
`4
`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,
`including the inner IP header, and selected portions of the
`outer IP header.
`The key management portion of IPSec involves the deter
`mination and distribution of secret keys. The default auto
`mated key management protocol for IPSec is referred to as
`ISAKMP/Oakley and consists of the Oakley key determi
`nation protocol and Internet Security Association and Key
`Management Protocol (ISAKMP). Internet key exchange
`(IKE) is a newer name for the ISAKMP/Oakley protocol.
`IKE is based on the Diffie-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 functionality.
`IPSec has been designed to provide confidentiality, integ
`rity, 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 tunnel has been formed by using Internet Key
`Exchange (IKE) protocol, the tunnel endpoints are fixed and
`remain constant. If IPSec 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 calcula
`tions. 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 of the computa
`tional 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.
`The problem with standard IPSec is thus that it has been
`designed for static connections. For instance, the end points
`of an IPSec tunnel mode SA are fixed. There is also no
`method for changing any of the parameters of an SA, other
`than by establishing a new SA that replaces the previous one.
`However, establishing SAs is costly in terms of both com
`putation time and network latency.
`An example of a specific scenario where these problems
`occur is described next in order to illustrate the problem.
`In the scenario, there is a standard IPSec security gateway,
`which is used by a mobile terminal e.g. for remote access.
`The mobile terminal is mobile in the sense that it changes its
`network point of attachment frequently. A mobile terminal
`can in this text thus be physically fixed or mobile. Because
`it may be connected to networks administered by third
`parties, it may also have a point of attachment that uses
`private addresses—i.e., the network is behind a router that
`performs network address translation (NAT). In addition, the
`networks used by the mobile terminal for access may be
`wireless, and may have poor quality of service in terms of
`throughput and e.g. packet drop rate.
`Standard IPSec does not work well in the scenario. Since
`IPSec connections are bound to fixed addresses, the mobile
`terminal must establish a new IPSec connection from each
`point of attachment. If an automated key exchange protocol,
`Such as IKE, is used, setting up a new IPsec connection is
`costly in terms of computation and network latency, and may
`require a manual authentication phase (for instance, a one
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 10
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`5
`time password). If IPSec connections are set up manually,
`there is considerable manual work involved in configuring
`the IPSec connection parameters.
`Standard IPSec does e.g. not work through NAT devices
`at the moment. A standard IPSec NAT traversal protocol is
`currently being specified, but the security gateway in the
`scenario might not Support an IPSec protocol extended in
`this way. Furthermore, the current IPSec NAT traversal
`protocols are not well suited to mobility.
`There are no provisions for improving quality of service
`over wireless links in the standard IPSec protocol. If the
`access network Suffers from high packet drop rates, the
`applications running in the mobile host and a host that the
`mobile terminal is communicating with will suffer from
`packet drops.
`A known method of solving some of these problems is
`based on having an intermediate host between the mobile
`terminal and the IPSec security gateway. The intermediate
`host might be a Mobile IP home agent, that provides
`mobility for the connection between the mobile terminal and
`the home agent, while the connection from the mobile node
`to the security gateway is an ordinary IPSec connection. In
`this case, packets sent by an application in the mobile client
`are first processed by IPSec, and then by Mobile IP.
`In the general case, this implies both Mobile IP and IPSec
`header fields for packets exchanged by the mobile terminal
`and the home agent. The Mobile IP headers are removed by
`the home agent prior to delivering packets to the security
`gateway, and added when delivering packets to the mobile
`terminal. Because of the use of two tunnelling protocols
`(Mobile IP and IPSec tunnelling), the solution is referred to
`as "double tunnelling in this document.
`The above method solves the mobility problem, at the cost
`of adding extra headers to packets. This may have a signifi
`cant impact on networks that have low throughput such as
`the General Packet Radio System (GPRS).
`Another known method is again to use an intermediate
`host between the mobile client and the IPSec security
`gateway. The intermediate host has an IPSec implementation
`that may support NAT traversal, and possibly some propri
`etary extensions for improving quality of service of the
`access network, for instance.
`The mobile host would now establish an IPSec connection
`between itself and the intermediate host, and would also
`establish an IPSec connection between itself and the IPSec
`45
`security gateway. This solution is similar to the first known
`method, except that two IPSec tunnels are used. It solves a
`different set of problems—for instance, NAT traversal but
`also adds packet size overhead because of double IPsec
`tunnelling.
`A third known method is to use a similar intermediate host
`as in the second known method, but establish an IPSec
`connection between the mobile terminal and the intermedi
`ate host, and another, separate IPSec connection between the
`intermediate host and the security gateway. The IPSec
`connection between the mobile terminal and the intermedi
`ate host may support NAT traversal, for instance, while the
`second IPSec connection does not need to.
`When packets are sent by an application in the mobile
`terminal, the packets are IPSec-processed using the IPSec
`connection shared by the mobile terminal and the interme
`diate host. Upon receiving these packets, the intermediate
`host undoes the IPSec-processing. For instance, if the packet
`was encrypted, the intermediate host decrypts the packet.
`The original packet would now be revealed in plaintext to
`the intermediate host. After this, the intermediate host
`IPSec-processes the packet using the IPSec connection
`
`25
`
`30
`
`35
`
`40
`
`50
`
`55
`
`60
`
`65
`
`US 9,712,502 B2
`
`10
`
`15
`
`6
`shared by the intermediate host and the security gateway,
`and forwards the packet to the Security gateway.
`This solution allows the use of an IPSec implementation
`that support NAT traversal, and possibly a number of other
`(possibly vendor specific) improvements, addressing prob
`lems such as the access network quality of service varia
`tions. Regardless of these added features, the IPSec security
`gateway remains unaware of the improvements, and is not
`required to implement any of the protocols involved in
`improving service. However, the solution has a major draw
`back: the IPsec packets are decrypted in the intermediate
`host, and thus possibly sensitive data is unprotected in the
`intermediate host.
`Consider a business scenario where a single intermediate
`host provides improved service to a number of separate
`customer networks, each having its own standard IPSec
`security gateway. Having decrypted packets of various cus
`tomer networks in plaintext form in the intermediate host is
`clearly a major security problem.
`To Summarise, the known solutions either employ extra
`tunnelling, causing extra packet size overhead, or use sepa
`rate tunnels, causing potential security problems in the
`intermediate host(s) that terminate such tunnels.
`
`THE OBJECT OF THE INVENTION
`
`The object of the invention is to develop a method for
`forwarding secure messages between two computers, espe
`cially, via an intermediate computer by avoiding the above
`mentioned disadvantages.
`Especially, the object of the invention is to forward secure
`messages in a way that enables changes to be made in the
`secure connection
`
`SUMMARY OF THE INVENTION
`
`The method and system of the invention enable secure
`forwarding of a message from a first computer to a second
`computer via an intermediate computer in a telecommuni
`cation network. It is mainly characterized in that a message
`is formed in the first computer or in a computer that is served
`by the first computer, and in the latter case, sending the
`message to the first computer. In the first computer, a secure
`message is then formed by giving the message a unique
`identity and a destination address. The message is sent from
`the first computer to the intermediate computer, whereafter
`said destination address and the unique identity are used to
`find an address to the second computer. The current desti
`nation address is substituted with the found address to the
`second computer, and the unique identity is substituted with
`another unique identity. Then the message is forwarded to
`the second computer.
`Preferably, the first computer processes the formed mes
`sage using a security protocol and encapsulates the message
`at least in an outer IP header. The outer IP header source
`address is the current address of the first computer, while the
`destination address is that of the intermediate computer. The
`message is then sent to the intermediate computer, which
`matches the outer IP header address fields together with a
`unique identifier used by the security protocol, and performs
`a translation of the outer addresses and the unique identity
`used by the security protocol. The translated packet is then
`sent to the second computer, which processes it using the
`standard security protocol in question. In the method of the
`invention, there is no extra encapsulation overhead as in the
`prior art methods. Also, the intermediate computer does not
`
`MPH Technologies Oy, Exhibit 2002
`Page 2002 - 11
`IPR2019-00824, Apple Inc. v. MPH Technologies Oy
`
`
`
`7
`need to undo the security processing, e.g. decryption, and
`thus does not compromise Security as in the prior art
`methods.
`Corresponding steps are performed when the messages
`are sent in the reverse direction, i.e. from the second
`computer to the first computer.
`Preferably, the secure message is formed by making use
`of the IPSec protocols, whereby the secure message is
`formed by using an IPsec connection between the first
`computer and the intermediate computer. The message sent
`from the first computer contains message data, an inner IP
`header containing actual sender and receiver addresses, an
`outer IP header containing the addresses of the first com
`puter and the intermediate computer, a unique identity, and
`other security parameters. The unique identity is one or more
`SPI values and the other security parameters contain e.g. the
`IPsec sequence number(s). The number of SPI values
`depends on the SA bundle size (e.g. ESP+AH bundle would
`have two SPI values). In the following, when an SA is
`referred to, the same applies to an SA bundle. The other
`related security parameters, containing e.g. the algorithm to
`be used, a traffic description, and the lifetime of the SA, are
`not sent on the wire. Only SPI and sequence number are sent
`for each IPsec processed header (one SPI and one sequence
`number if e.g. ESP only is used; two SPIs and two sequence
`numbers if e.g. ESP+AH is used, etc.).
`Thus, the unsecured data packet message is formed by the
`sending computer, which may or may not be the first
`computer. The IP header of this packet has IP source and
`destination address fields (among other things). The packet
`is encapsulated e.g. wrapped inside a tunnel, and the result
`ing packet is secured. The secured packet has a new outer IP
`header, which contains another set of IP source and desti
`nation addresses (in the outer header—the inner header is
`untouched), i.e. there are two outer addresses (source and
`destination) and two inner addresses. The processed packet
`has a unique identity, the IPsec SPI value(s).
`An essential idea of the invention is to use the standard
`protocol (IPSec) between the intermediate computer and the
`second computer and an "enhanced IPSec protocol between
`the first computer and the intermediate computer. IPsec
`protected packets are translated by the intermediate com
`puter, without undoing the IPsec processing. This avoids
`both the overhead of double tunneling and the security
`problem involved in using separate tunnels.
`The translation is performed e.g. by means of a translation
`table stored at the intermediate computer. The outer IP
`header address fields and/or the SPI-values are changed by
`the intermediate computer so that the message can be
`forwarded to the second computer.
`By modifying the translation table and parameters asso
`ciated to a given translation table entry, the properties of the
`connection between the first and the intermediate computers
`can be changed without establishing a new IPsec connec
`tion, or involving the second computer in any way.
`One example of a change in the SA between the first
`computer and the intermediate computer is the change of
`addresses for enabling mobility. This can be accomplished in
`the invention simply by modifying the translation table entry
`address fields. Signaling messages may be used to request
`Such a change. Such signalling messages may be authenti
`cated and/or encrypted, or sent in plaintext. One method of
`doing authentication and/or encryption is to use an IPsec
`connection between the first computer and the intermediate
`computer. The second computer is unaware of this IPsec
`connection, and does not need to participate in the signalling
`protocol in any way. Several other methods of signalling
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 9,712,502 B2
`
`5
`
`10
`
`15
`
`8
`exist, for instance, the IKE key exchange protocol maybe
`extended to carry Such signalling messages.
`In the signalling, e.g. a registration request is sent from
`the first computer to the intermediate computer which causes
`the intermediate computer to modify the addresses in the
`mapping table and thus, the intermediate computer can
`identify the mobile next time a message is sent.
`Preferably, as a result of a registration request, a reply
`registration is sent from the intermediate computer back to
`the first computer.
`Other examples of possible modifications to the SA—or
`in general, the packet processing behaviour between the
`first computer and the intermediate computer are the fol
`lowing.
`One example is the first computer and the intermediate
`computer performs some sort of retransmission protocol that
`ensures that the IPSec protected packets are not dropped in
`the route between the first and the intermediate computer.
`This may have useful applications when the first computer
`is connected using a network access method that has a high
`packet drop rate for instance. GPRS.
`Such a protocol can be easily based on e.g. IPsec sequence
`number field and the replay protection window, which
`provide a way to detect that packet(s) have been lost. When
`a receiving host detects missing packets, it can send a
`request message for those particular packets. The request
`can of course be piggy-backed on an existing data packet
`that is being sent to the other host. Another m