111111
`
`1111111111111111111111111111111111111111111111111111111111111
`US009712494B2
`
`c12) United States Patent
`Vaarala et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 9,712,494 B2
`*Jul. 18, 2017
`
`(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)
`
`(52) U.S. Cl.
`CPC ........ H04L 6310281 (2013.01); H04L 910841
`(2013.01); H04L 611256 (2013.01); H04L
`6310428 (2013.01); H04L 631123 (2013.01)
`(58) Field of Classification Search
`USPC ......................................... 709/236, 239, 245
`See application file for complete search history.
`
`(73) Assignee: MPH Technologies Oy, Espoo (FI)
`
`(56)
`
`References Cited
`
`( *) 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(cid:173)
`claimer.
`
`(21) Appl. No.: 15/372,208
`
`(22) Filed:
`
`Dec. 7, 2016
`
`(65)
`
`Prior Publication Data
`
`US 2017/0093799 Al Mar. 30, 2017
`
`Related U.S. Application Data
`
`(63) Continuation of application No. 13/685,544, filed on
`Nov. 26, 2012, which is a continuation of application
`(Continued)
`
`(30)
`
`Foreign Application Priority Data
`
`Jan. 22, 2002
`
`(FI) ...................................... 20020112
`
`(51)
`
`Int. Cl.
`H04L 9132
`G06F 15116
`H04L 29106
`H04L 9108
`H04L 29112
`
`(2006.01)
`(2006.01)
`(2006.01)
`(2006.01)
`(2006.01)
`
`2
`
`!Psec translation
`IKE translation
`
`U.S. PATENT DOCUMENTS
`
`6,718,388 B1 * 4/2004 Yarborough ........ H04L 63/0227
`709/217
`6,732,269 B1 * 5/2004 Baskey ................. H04L 63/166
`713/153
`
`(Continued)
`
`Primary Examiner- Afshawn Towfighi
`(74) Attorney, Agent, or Firm- Fasth Law Offices; Rolf
`Fasth
`
`ABSTRACT
`(57)
`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
`address to the second computer, and the unique identity is
`substituted with another unique identity. Then the message
`is forwarded to the second computer.
`
`11 Claims, 6 Drawing Sheets
`
`3
`
`Enhanced
`!Psec
`
`Standard IKE
`(optional)
`
`Modified IKE
`protocol (optional}
`
`r
`I 0
`
`Plaintext packets
`
`4
`
`Ex. 1001
`Apple v. MPH Techs. Oy
`IPR2019-00823
`
`0001
`
`

`

`US 9, 712,494 B2
`Page 2
`
`Related U.S. Application Data
`
`No. 10/500,930, filed as application No. PCT/FI03/
`00045 on Jan. 21, 2003, now Pat. No. 8,346,949.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,795,917 B1 * 9/2004 Ylonen ................... H04L 29/06
`713/160
`6,957,346 B1 * 10/2005 Kivinen .............. H04L 12/4633
`713/153
`6,985,953 B1 *
`112006 Sandhu ............... G06F 17/3089
`709/225
`7,055,027 B1 * 5/2006 Gunter .................... H04L 63/30
`709/223
`200110047487 A1 * 1112001 Linnakangas ....... H04L 63/0428
`726/12
`2002/0004900 A1 *
`G06Q 30/02
`713/155
`2002/0091921 A1 * 7/2002 Kunzinger .......... H04L 63/0428
`713/153
`
`112002 Patel
`
`* cited by examiner
`
`0002
`
`

`

`~Psec translation
`IKE translation
`
`Standard !Psec
`
`Standard IKE
`(optional)
`
`I
`
`2
`
`'
`
`Enhanced
`iPsec
`
`I
`
`I
`
`1
`
`I
`
`I
`
`Modified IKE
`protocol (optional)
`
`3
`
`l
`
`~
`\ Plaintext packets
`
`~ l l
`
`FIG~ 1
`
`e •
`
`00
`•
`~
`~
`~
`
`~ = ~
`
`~ = :-....
`0 ....
`
`~CIO
`N
`
`-....l
`
`('D
`
`rFJ =-('D
`.....
`....
`0 .....
`0\
`
`d
`rJl
`
`'"'..c
`-....l
`""""' N
`~
`'..c
`
`~ = N
`
`0003
`
`

`

`U.S. Patent
`U.S. Patent
`
`Jul. 18, 2017
`Jul. 18, 2017
`
`Sheet 2 of 6
`Sheet 2 of 6
`
`US 9,712,494 B2
`US 9,712,494 B2
`
`HQfiTX
`
`•!I'>
`
`
`
`M
`
`"''it'
`
`j&..
`
`~
`
`C\1
`
`A
`
`l.i)
`
`1!1?
`
`86mmcamguter Firmmmguter
`
`Bntenneééaiiecamp;
`
`'I"'""
`
`<0 ,,
`
`0004
`
`0004
`
`

`

`e •
`
`00
`•
`~
`~
`~
`
`~ = ~
`
`c .. aaar .. 1 c .. addr .. 2
`c .. spJ .. 2
`c .. Sfl .. 1
`195.1.2.3 212.90.65.1 Ox80000001 Ox12341234
`. ..
`_L_ .. --------------- ...
`
`...
`
`-----------------~ ------------------------------
`
`~ s .. adar .. a
`212.90.65.1
`,_ . ..
`
`~-------------------------
`
`s .. addr .. 3 s..SPI .. 2
`s~SPI .. 3
`103.6.5,4 Ox1230012 Ox56785678
`...
`.. .
`...
`------
`
`FIG& 3
`
`2' :-....
`0 ....
`
`~CIO
`N
`
`-....l
`
`rFJ =(cid:173)
`.....
`
`('D
`('D
`
`(.H
`
`0 .....
`0\
`
`d
`rJl
`
`'"'..c
`-....l
`""""' N
`~
`'..c
`
`~ = N
`
`0005
`
`

`

`U.S. Patent
`U.S. Patent
`
`Jul. 18, 2017
`Jul. 18, 2017
`
`Sheet 4 of 6
`Sheet 4 of 6
`
`US 9,712,494 B2
`US 9,712,494 B2
`
`4
`
`4
`
`•
`
`,....
`00
`
`I"
`
`........
`u...
`
`863mmmmpuier FiratEntemediaiecamp.
`
`
`
`
`
`Cgmgutegr
`
`N
`
`,.
`
`('f)
`'
`
`,.......
`'
`
`«>
`
`'II'
`
`,....
`
`0
`
`~ T-~11" - ...-,!!"
`
`"¢'
`
`11.0
`
`~
`
`-
`
`"¢
`
`,
`
`tO
`
`co CD
`lr
`
`en
`N
`-~ ~'IF
`
`«> r-
`Y"',
`
`'IF
`
`0006
`
`0006
`
`

`

`Mapping Stag~ 1
`field
`c-addrM1
`195.1.2.3
`CH~ddr-2 212.90.65.1
`CKY1
`c~icky
`0
`c~rcky
`joe@netseai.com
`c~userid
`
`> • • •
`
`Stage 2
`
`Stage 3
`
`Stage 4
`
`195.1.2.3
`212.90.65.1
`CKY1
`0
`jqe@netseal. com
`
`195.1.2.3
`212.90.65.1
`CKY1
`0
`joe@netseaLcom
`
`195.1.2.3
`212.90.65.1
`CKY1
`CKY4
`joe~~_ea!.com
`
`nla
`s~addr~2
`nla
`~Hilddr-3
`s-lcky
`n/a
`s~rcky ___ n/a
`
`~--~-------------------------------------------------- -----------------------------------------------
`
`212.90.65.1
`103.6.ft4
`CKY2
`0
`
`212.90.65.1
`103.6.5.4
`CKY2
`CKY3
`
`-----------------------------------
`
`--
`
`--------------
`
`212.90.65.1
`103.6.5.4
`CKY2
`CKY3
`
`--------------------------------------------------
`
`FIG. 5
`
`e •
`
`00
`•
`~
`~
`~
`
`~ = ~
`
`2' :-....
`0 ....
`
`~CIO
`N
`
`-....l
`
`('D
`('D
`
`rFJ =(cid:173)
`.....
`Ul
`0 .....
`0\
`
`d
`rJl
`
`'"'..c
`-....l
`""""' N
`~
`'..c
`
`~ = N
`
`0007
`
`

`

`U.S. Patent
`
`Jul. 18, 2017
`
`Sheet 6 of 6
`
`US 9,712,494 B2
`
`~~~------~-----------------------------------
`
`Identification type
`
`User@Fu!ly-Qua!ified-
`Domain-Name
`user@FuiiJt:-Oualified-
`Domain-Nam~
`Distinguished Name
`
`Fully-Qualified-Domain-
`Name
`Employee number and
`company
`...
`
`Identification value
`---------------------------
`*.smith@netseal.com
`
`*@netseal.ggm
`
`"CN=Sami Vaarala,
`DC=netsea!, DC=oom"
`host4.roammate.com
`
`"190170 I NetSeal
`Technologies"
`. ..
`
`SGW
`address
`123.1.2.3
`
`103.6.5.4
`
`122.4.3.2
`--
`123.3.2.1
`
`123.4.3.2
`
`. ..
`
`--
`
`---------
`
`FIG. 6
`
`0008
`
`

`

`US 9,712,494 B2
`
`1
`METHOD AND SYSTEM FOR SENDING A
`MESSAGE THROUGH A SECURE
`CONNECTION
`
`PRIOR APPLICATIONS
`
`This application is a U.S. Continuation Patent Application
`based on 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/FI03/00045, filed 21
`Jan. 2003, that claims priority from Finnish Pat. App. No.
`20020112, filed 22 Jan. 2002.
`
`TECHNICAL FIELD
`
`The method and system of the invention are intended to
`secure connections in telecommunication networks. Espe(cid:173)
`cially, it is meant for wireless Internet Service Provider (ISP)
`connections.
`
`TECHNICAL BACKGROUND
`
`An internetwork is a collection of individual networks
`connected with intermediate networking devices that func(cid:173)
`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(cid:173)
`cation network that covers a relatively broad geographic
`area. Wide area networks (WANS) interconnect LANs
`across normal telephone lines and, for instance, optical 35
`networks; thereby interconnecting geographically disposed
`users.
`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
`she actual sender of data), replay protection (guaranteeing
`that data is fresh, and not a copy of previously sent data),
`identities of parties
`identity protection (keeping
`the
`exchanging data secret from outsiders), high availability, i.e.
`denial-of-service protection (ensuring that the system func(cid:173)
`tions even when under attack) and access control. IPSec is 50
`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(cid:173)
`rity, authentication, replay protection, limited traffic flow
`confidentiality, limited identity protection, and access con(cid:173)
`trol based on authenticated identities. Even if some appli(cid:173)
`cations already have built in security protocols, the use of
`IPSec further enhances the security.
`
`2
`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 IP layer;
`10 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,
`15 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-
`20 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-
`25 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
`30 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(cid:173)
`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
`40 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(cid:173)
`cessed. IP destination address is the second parameter,
`45 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 anAH
`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
`55 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 audible event
`and prevent further transmission of packets on this SA. An
`Anti-Replay Window is used to determine whether an
`60 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(cid:173)
`tication algorithms, keys, initialisation vectors, and related
`65 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
`
`0009
`
`

`

`US 9,712,494 B2
`
`3
`and authentication algorithms, keys, cryptographic initiali(cid:173)
`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(cid:173)
`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(cid:173)
`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(cid:173)
`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(cid:173)
`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 "IPipayload" packet
`becomes "IPIIPipayload". The next step is to secure the
`packet using ESP and/or AH. In case of ESP, the resulting 45
`packet is "IPIESPIIPipayload". 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 50
`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- 55
`in g. If this packet from the first host to another host requires
`IPSec, the firewall performs IPSec processing and encapsu(cid:173)
`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 60
`other local network. This packet is now routed to the other
`host's firewall with intermediate routers examining only the
`outer IP header At the other host firewall, the outer IP header
`is stripped off and the inner packet is delivered to the other
`host.
`ESP in tunnel mode encrypts and optionally authenticates
`the entire inner IP packet, including the inner IP header AH
`
`4
`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(cid:173)
`mination and distribution of secret keys. The default auto(cid:173)
`mated key management protocol for IPSec is referred to as
`ISAKMP/Oakley and consists of the Oakley key determi(cid:173)
`nation protocol and Internet Security Association and Key
`Management Protocol (ISAKMP). Internet key exchange
`10 (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
`15 features to be added without compromising functionality.
`IPSec has been designed to provide confidentiality, integ(cid:173)
`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
`20 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
`25 involve computationally expensive Diffie-Hellman key
`exchange algorithm calculations and possibly RSA calcula(cid:173)
`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
`30 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(cid:173)
`tional expenses.
`In this text, the term mobility and mobile terminal does
`35 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
`40 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(cid:173)
`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
`65 costly in terms of computation and network latency, and may
`require a manual authentication phase (for instance, a one(cid:173)
`time password). If IPSec connections are set up manually,
`
`0010
`
`

`

`US 9,712,494 B2
`
`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(cid:173)
`lems such as the access network quality of service varia(cid:173)
`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
`10 improving service. However, the solution has a major draw(cid:173)
`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(cid:173)
`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(cid:173)
`rate tunnels, causing potential security problems in the
`intermediate host(s) that terminate such tunnels.
`
`15
`
`5
`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 20
`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 25
`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 30
`(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(cid:173)
`cant impact on networks that have low throughput such as 35
`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- 40
`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 55
`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(cid:173)
`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
`
`THE OBJECT OF THE INVENTION
`
`The object of the invention is to develop a method for
`forwarding secure messages between two computers, espe(cid:173)
`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(cid:173)
`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-
`50 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(cid:173)
`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
`60 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
`65 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
`
`0011
`
`

`

`US 9,712,494 B2
`
`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(cid:173)
`puter and the intermediate computer, a unique identity, and
`other security parameters. The unique identity is one or more 15
`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 turmel, and the result(cid:173)
`ing packet is secured. The secured packet has a new outer IP
`header, which contains another set of IP source and desti(cid:173)
`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(cid:173)
`protected packets are translated by the intermediate com(cid:173)
`puter, without undoing the IPsec processing. This avoids
`both the overhead of double turmeling 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(cid:173)
`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(cid:173)
`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 60
`such a change. Such signalling messages may be authenti(cid:173)
`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 65
`connection, and does not need to participate in the signalling
`protocol in any way. Several other meth