(12) United States Patent
`Vaarala et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,346,949 B2
`Jan. 1, 2013
`
`USOO8346949B2
`
`(54)
`
`METHOD AND SYSTEM FOR SENDINGA
`MESSAGE THROUGH ASECURE
`CONNECTION
`
`(75)
`
`Inventors: Sami Vaarala, Espoo (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 959 days.
`
`(21)
`
`Appl. No.:
`
`10/500,930
`
`(22)
`
`(86)
`
`PCT Fled:
`
`Jan. 21, 2003
`
`PCT NO.:
`S371 (c)(1),
`(2), (4) Date:
`
`PCT/FO3/OOO45
`
`Oct. 19, 2005
`
`(87)
`
`PCT Pub. No.: WOO3FO63443
`
`PCT Pub. Date: Jul. 31, 2003
`
`(65)
`
`Prior Publication Data
`US 2006/O173968A1
`Aug. 3, 2006
`
`(30)
`Jan. 22, 2002
`
`Foreign Application Priority Data
`
`(FI) ...................................... 2002O112
`
`(51)
`
`(52)
`(58)
`
`Int. C.
`(2006.01)
`G06F 15/16
`U.S. Cl. ............................................ 709/229; 726/3
`Field of Classification Search .................. 709/236,
`709/229, 245
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`6,718,388 B1
`4/2004 Yarborough et al.
`6,732,269 B1
`5/2004 Baskey et al.
`6,795,917 B1
`9, 2004 Yonen
`6,957,346 B1 10/2005 Kivinen et al.
`6,985,953 B1* 1/2006 Sandhu et al. ................ 709,229
`7,055,027 B1 * 5/2006 Gunter et al. ..........
`T13/151
`2001/0047487 A1* 1 1/2001 Linnakangas et al. ........ 713/201
`2002, 0004900 A1* 1 2002 Patel ......................
`T13,155
`2002/0091921 A1* 7/2002 Kunzinger .................... T13,153
`OTHER PUBLICATIONS
`Ari Luotonen, “Tunneling SSL. Through a WWW Proxy” Internet
`draft memo, Mar. 26, 1997.
`Ari Luotonen, “Tunneling TCP based protocols through Web proxy
`servers' Internet draft memo, Aug. 1998.
`* cited by examiner
`Primary Examiner — Ian N Moore
`Assistant Examiner — Afshawn Towfighi
`(74) Attorney, Agent, or Firm — Fasth Law Offices: Rolf
`Fasth
`ABSTRACT
`(57)
`The method and system enable secure forwarding of a mes
`sage from a first computer to a second computer via an inter
`mediate computer in a telecommunication network. A mes
`sage 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 address to the second
`computer, and the unique identity is substituted with another
`unique identity. Then the message is forwarded to the second
`computer.
`
`29 Claims, 6 Drawing Sheets
`
`Psec translation
`IKE translation
`
`Standard IPsec
`
`Standard KE
`(optional)
`
`Modified KE
`protocol (optional)
`
`
`
`
`
`
`
`
`
`Enhanced
`Psec
`
`
`
`
`
`
`
`Plaintext packets
`4.
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 1
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 2
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`U.S. Patent
`
`Jan. 1, 2013
`
`Sheet 2 of 6
`
`US 8,346,949 B2
`
`X JLSOH
`
`
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 3
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`U.S. Patent
`
`Jan. 1, 2013
`
`Sheet 3 of 6
`
`US 8,346,949 B2
`
`
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 4
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`U.S. Patent
`
`Jan. 1, 2013
`
`Sheet 4 of 6
`
`US 8,346,949 B2
`
`
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 5
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 6
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`U.S. Patent
`
`Jan. 1, 2013
`
`Sheet 6 of 6
`
`US 8,346,949 B2
`
`
`
`
`
`
`
`
`
`address
`
`Domain-Name
`userOFully-Qualified-
`Domain-Name
`
`OnetSeal.com
`
`103.65.4
`
`DC=netSeal, DC=com."
`
`Name
`Employee number and
`COOa?
`
`"19017O / NetSeal
`Technologies"
`
`123.4.3.2
`
`
`
`F.G. 6
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 7
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`US 8,346,949 B2
`
`1.
`METHOD AND SYSTEM FOR SENDINGA
`MESSAGE THROUGH A SECURE
`CONNECTION
`
`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.
`
`10
`
`TECHNICAL BACKGROUND
`
`2
`of the packet for that protocol, Encapsulating Security Pay
`load (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 cryp
`tographic keys and the management of traffic flows related to
`these security protocols.
`Security association (SA) is a key concept in the authenti
`cation 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 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,
`SAbundle refers to one or more SAS applied in sequence, e.g.
`by first performing an ESP protection, and then an AH pro
`tection. 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 associations, 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 algo
`rithms 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, 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 num
`ber field in AH or ESP headers. The Sequence Counter Over
`flow is a flag indicating whether overflow of the sequence
`number counter should generate an auditable event and pre
`vent 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 informa
`tion 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. AH information consists of the authentication
`algorithm, keys and related parameters being used with AH.
`ESP information consists of encryption and authentication
`algorithms, keys, cryptographic initialisation 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 maximum 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.
`
`15
`
`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 work
`stations, 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 tele
`phone lines and, for instance, optical networks; thereby inter
`connecting geographically disposed users.
`There is a need to protect data and resources from disclo
`Sure, 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 confiden
`tiality), 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 pro
`tection (keeping the identities of parties exchanging data
`secret from outsiders), high availability, i.e. denial-of-service
`protection (ensuring that the system functions even when
`under attack) and access control. IPSec is a technology pro
`viding 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 IPsecurity 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 communi
`cation 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 identi
`ties. Even if some applications already have built in security
`protocols, the use of IPSec further enhances the security.
`IPSec can encrypt and/or authenticate traffic at IP level.
`Traffic going in to a WAN is typically 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
`60
`define IPSec, are, for the time being, the Request For Com
`ments (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
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`65
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 8
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`3
`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 tun
`nelling, 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 generated 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 destination
`addresses, adding to the Security. In other words, the first step
`in protecting the packet using tunnel mode is to add a new IP
`header to the packet; thus the “IPlpayload” 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
`“IPIESPIPlpayload’. 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 ifa
`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 processing. If this packet from
`the first host to another host requires IPSec, the firewall per
`forms IPSec processing and encapsulates 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 host’s firewall with inter
`mediate routers examining only the outer IP header At the
`other host firewall, the outer IP header is stripped off and the
`inner packet is delivered to the other host.
`ESP in tunnel mode encrypts and optionally authenticates
`the entire inner IP packet, including the inner IP header AH in
`tunnel mode authenticates the entire inner IP packet, includ
`ing 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 determina
`tion protocol and InternetSecurity Association and Key Man
`agement 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 pro
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 8,346,949 B2
`
`10
`
`15
`
`4
`tocol, 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 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.
`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 arefixed. 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. How
`ever, establishing SAS is costly in terms of both computation
`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
`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 supportan 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 appli
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 9
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`5
`cations 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 (Mo
`bile 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 proprietary exten
`sions 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
`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 tun
`nelling.
`A third known method is to use a similar intermediate host
`as in the second known method, but establish an IPSec con
`nection between the mobile terminal and the intermediate
`host, and another, separate IPSec connection between the
`intermediate host and the security gateway. The IPSec con
`45
`nection between the mobile terminal and the intermediate
`host may support NAT traversal, for instance, while the sec
`ond 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 intermedi
`ate 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 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 variations.
`Regardless of these added features, the IPSec security gate
`way 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
`
`25
`
`30
`
`35
`
`40
`
`50
`
`55
`
`60
`
`65
`
`US 8,346,949 B2
`
`10
`
`15
`
`6
`back: the IPsec packets are decrypted in the intermediate host,
`and thus possibly sensitive data is unprotected in the interme
`diate host.
`Consider a business Scenario where a single intermediate
`host provides improved service to a number of separate cus
`tomer networks, each having its own standard IPSec Security
`gateway. Having decrypted packets of various customer net
`works 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 inter
`mediate 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 telecommunica
`tion 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 com
`puter to the intermediate computer, whereafter said destina
`tion address and the unique identity are used to find an address
`to the second computer. The current destination 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 com
`puter.
`The advantageous embodiments have the characteristics of
`the Subclaims,
`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
`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
`
`MPH Technologies Oy, Exhibit 2001
`Page 2001 - 10
`IPR2019-00825, Apple Inc. v. MPH Technologies Oy
`
`

`

`7
`computer contains message data, an inner IP header contain
`ing actual sender and receiver addresses, an outer IP header
`containing the addresses of the first computer and the inter
`mediate 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 val
`ues). In the following, when an SA is referred to, the same
`applies to an SA bundle. The other related security param
`eters, 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 com
`puter. The IP header of this packet has IP source and destina
`tion address fields (among other things). The packet is encap
`Sulated e.g. wrapped inside a tunnel, and the resulting packet
`is secured. The secured packet has a new outer IP header,
`which contains another set of IP source and destination
`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-pro
`tected packets are translated by the intermediate computer,
`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 inter
`mediate computer so that the message can be forwarded to the
`second computer.
`By modifying the translation table and parameters associ
`ated 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 connection,
`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
`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 map
`ping 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.
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 8,346,949 B2
`
`5
`
`10
`
`15
`
`8
`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 following.
`One example is the first computer and the intermediate
`computer perform 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 pro
`vide 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 method of doing the
`retransmissions may be based on using an extra protocol
`inside which the IPSec packets are wrapped for transmission
`between the first and intermediate computer. In any case, the
`second computer remains unaware of Such a retransmission
`protocol.
`Another example is performing a Network Address Trans
`lation (NAT) traversal encapsulation between the first and the
`intermediate computer. This method could be based on e.g.
`using UDP encapsulation for transmission of packets
`between the first and the intermediate computer. The second
`computer remains unaware about this processing and does not
`even need to support NAT traversal at all. This is beneficial
`because there are several existing IPSec products that have no
`support for NAT traversal.
`The system of the invention is a telecommunication net
`work for secure forwarding of messages and comprises at
`least a first computer, a second computer and an intermediate
`computer. It is characterized in that the first and the second
`computers have means to perform IPSec processing, and the
`intermediate computer have means to perform IPSec transla
`tion and possibly key exchange protocol. Such