`
`1111111111111111111111111111111111111111111111111111111111111
`US0097 623 97B2
`
`c12) United States Patent
`Vaarala et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 9,762,397 B2
`*Sep.12,2017
`
`(54) METHOD AND SYSTEM FOR SENDING A
`MESSAGE THROUGH A SECURE
`CONNECTION
`
`(71) Applicant: MPH TECHNOLOGIES OY, Espoo
`(FI)
`
`(72)
`
`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 0 days.
`
`This patent is subject to a terminal dis(cid:173)
`claimer.
`
`(21) Appl. No.: 13/685,544
`
`(22) Filed:
`
`Nov. 26, 2012
`
`(65)
`
`Prior Publication Data
`
`US 2013/0080781 Al
`Mar. 28, 2013
`US 2017/0093580 A9
`Mar. 30, 2017
`Related U.S. Application Data
`
`(63) Continuation of application No. 10/500,930, filed as
`application No. PCT/FI03/00045 on Jan. 21, 2003,
`now Pat. No. 8,346,949.
`
`(30)
`
`Foreign Application Priority Data
`
`Jan. 22, 2002
`
`(FI) ...................................... 20020112
`
`(51)
`
`Int. Cl.
`H04L 9132
`G06F 15116
`
`(2006.01)
`(2006.01)
`(Continued)
`
`(52) U.S. Cl.
`CPC .......... H04L 913244 (2013.01); H04L 910844
`(2013.01); H04L 2911249 (2013.01);
`(Continued)
`(58) Field of Classification Search
`USPC ......................................... 709/236, 239, 245
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`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
`
`(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
`address to the second computer, and the unique identity is
`substituted with another unique identity. Then the message
`is forwarded to the second computer.
`
`2 Claims, 6 Drawing Sheets
`
`IPsec translation
`IKE translation
`
`2
`
`3
`
`Enhanced
`IPsec
`
`Standard IPsec
`
`Standard IKE
`(optional)
`
`Modified IKE
`protocol (optional)
`
`Plaintext packets
`
`4 D
`
`Ex. 1001
`Apple v. MPH Techs. Oy
`IPR2019-00825
`
`0001
`
`
`
`US 9, 762,397 B2
`Page 2
`
`(51)
`
`(2006.01)
`(2006.01)
`(2006.01)
`
`Int. Cl.
`H04L 29106
`H04L 9108
`H04L 29/12
`(52) U.S. Cl.
`CPC ........ H04L 611256 (2013.01); H04L 6310272
`(2013.01); H04L 6310428 (2013.01); H04L
`631061 (2013.01); H04L 63108 (2013.01);
`H04L 631164 (2013.01); H04L 29/1216
`(2013.01); H04L 29/12481 (2013.01); H04L
`61/157 (2013.01); H04L 61/2557 (2013.01);
`H04L 2209/80 (2013.01)
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,985,953 B1 *
`
`6,795,917 B1 * 9/2004 Ylonen ................... H04L 29/06
`713/160
`6,957,346 B1 * 10/2005 Kivinen .............. H04L 12/4633
`713/153
`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
`112002 Patel ...................... G06Q 30/02
`713/155
`2002/0091921 A1 * 7/2002 Kunzinger .......... H04L 63/0428
`713/153
`
`2002/0004900 A1 *
`
`* cited by examiner
`
`0002
`
`
`
`e •
`
`00
`•
`~
`~
`~
`
`~ = ~
`
`rFJ
`('D
`
`N
`
`~
`
`'? ....
`0 ....
`
`IPsec translation
`IKE translation
`
`2
`
`3
`
`Enhanced
`IPsec
`
`1
`
`Standard IPsec
`
`Standard IKE
`(optional)
`
`Modified IKE
`protocol (optional)
`
`FIG. 1
`
`N
`
`-....l
`
`Plaintext packets
`
`4
`
`('D
`('D
`
`rFJ =(cid:173)
`.....
`....
`0 .....
`0\
`
`d
`rJl
`
`'"'..c
`-....l
`0'1
`
`'..c
`
`N w
`-....l = N
`
`0003
`
`
`
`U.S. Patent
`U.S. Patent
`
`Sep.12,2017
`Sep.12,2017
`
`Sheet 2 of 6
`Sheet2 0f6
`
`US 9,762,397 B2
`US 9,762,397 B2
`
`><
`1-
`(/)
`0
`I
`
`,_
`(])
`.........
`::J
`0..
`E
`8
`"'0 c
`8 (])
`
`(/)
`
`0..
`E
`0
`(.)
`(])
`
`......... . ~
`
`"'0
`(])
`E ,_
`2
`c
`
`XHmOI559:8vcoomm.quoBEBEEE.
`
`
`
` @3800EE
`
`._
`
`C"')
`
`~
`
`r
`
`~
`
`C\1
`
`~II'
`
`•
`
`N.0."—
`(!) -u.
`
`l!) ,,
`
`CD
`
`0004
`
`,_
`......
`Q)
`::J
`0..
`E
`0
`(.)
`
`'r"
`
`0004
`
`
`
`c-SPI-2
`c-SPI-1
`c-addr-2
`c-addr-1
`195.1.2.3 212.90.65.1 Ox80000001 Ox12341234
`...
`. ..
`. ..
`...
`
`s-addr-2
`212.90.65.1
`. ..
`
`s-SPI-3
`s-addr-3 s-SPI-2
`103.6.5.4 Ox1230012 Ox56785678
`. ..
`. ..
`. ..
`
`FIG. 3
`
`e •
`
`00
`•
`~
`~
`~
`
`~ = ~
`
`rFJ
`('D
`
`N
`
`~
`
`'? ....
`0 ....
`
`N
`
`-....l
`
`rFJ =(cid:173)
`.....
`
`('D
`('D
`
`(.H
`
`0 .....
`0\
`
`d
`rJl
`
`'"'..c
`-....l
`0'1
`
`'..c
`
`N w
`-....l = N
`
`0005
`
`
`
`U.S. Patent
`U.S. Patent
`
`Sep.12,2017
`Sep. 12, 2017
`
`Sheet 4 of 6
`Sheet 4 of 6
`
`US 9,762,397 B2
`US 9,762,397 B2
`
`.,.
`
`~
`
`~
`
`C'\1
`
`('>")
`
`~,
`
`A
`
`,.......
`
`~,
`
`<D
`
`r.
`
`0 ~
`~ ~,
`
`l()
`"<:j"
`~ ~,
`
`.. ~
`
`"'
`
`'"'
`
`co
`
`'r"
`
`.. ~
`
`-u.
`
`a..
`E
`0
`(.)
`(I)
`
`~
`"0
`(I)
`E
`'--2
`c
`
`'-
`(I)
`........
`::J a..
`E
`0
`()
`
`Computer
`
`Intermediatecomp.Secondcomputer
`
`
`
`FIG.4 First
`
`'r"
`
`l()
`
`"<:j"
`
`r
`
`co Q)
`
`~
`
`C'\1
`'r"
`
`('>")
`'r"
`
`,.......
`<0
`~ 'r"
`
`0006
`
`0006
`
`
`
`Mapping Stage 1
`field
`c-addr-1
`c-addr-2
`c-icky
`c-rcky
`c-userid
`
`195.1.2.3
`212.90.65.1
`CKY1
`0
`joe@netseal.com
`
`Stage 2
`
`Stage 3
`
`Stage 4
`
`195.1.2.3
`212.90.65.1
`CKY1
`0
`joe@netseal.com
`
`195.1.2.3
`212.90.65.1
`CKY1
`0
`joe@netseal.com
`
`195.1.2.3
`212.90.65.1
`CKY1
`CKY4
`joe@netseal.com
`
`s-addr-2
`s-addr-3
`s-icky
`s-rcky
`
`n/a
`n/a
`n/a
`n/a
`
`212.90.65.1
`103.6.5.4
`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
`•
`~
`~
`~
`
`~ = ~
`
`rFJ
`('D
`
`N
`
`~
`
`'? ....
`0 ....
`
`N
`
`-....l
`
`('D
`('D
`
`rFJ =(cid:173)
`.....
`Ul
`0 .....
`0\
`
`d
`rJl
`'.0'-.C
`-....l
`0'1
`
`'..c
`
`N w
`-....l = N
`
`0007
`
`
`
`U.S. Patent
`
`Sep.12,2017
`
`Sheet 6 of 6
`
`US 9,762,397 B2
`
`Identification type
`
`Identification value
`
`User@Fully-Qualified-
`Domain-Name
`user@Fully-Qualified-
`Domain-Name
`Distinguished Name
`
`Fully-Qualified-Domain-
`Name
`Employee number and
`company
`...
`
`* .smith@netseal.com
`
`*@netseal.com
`
`"CN=Sami Vaarala,
`DC=netseal, DC=com"
`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,762,397 B2
`
`1
`METHOD AND SYSTEM FOR SENDING A
`MESSAGE THROUGH A SECURE
`CONNECTION
`
`PRIOR APPLICATION
`
`This application is a U.S. Continuation patent application
`based on U.S. patent application Ser. No. 10/500,930, filed
`19 Oct. 2005.
`
`TECHNICAL FIELD
`
`2
`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;
`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
`10 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(cid:173)
`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(cid:173)
`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
`25 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(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
`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-
`40 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 anAH
`45 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
`50 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
`55 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-
`60 tication 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 initiali-
`65 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
`
`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) 15
`connections.
`
`TECHNICAL BACKGROUND
`
`An internetwork is a collection of individual networks 20
`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 30
`across normal telephone lines and, for instance, optical
`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 35
`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),
`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(cid:173)
`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(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.
`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
`
`0009
`
`
`
`US 9,762,397 B2
`
`3
`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 30
`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 35
`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 40
`packet using ESP and/or AH. In case of ESP, the resulting
`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 destination
`address of another host on another network, the packet is
`routed from the originating host to a security gateway
`(SGW), firewall or the secure router at the boundary of the 50
`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 performs IPSec processing and encapsulates the
`packet in an outer IP header. The source IP address of this 55
`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 intermediate, routers examining only the outer
`IP header At the other host firewall, the outer IP header is 60
`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,
`including the inner IP header, and selected portions of the
`outer IP header.
`
`4
`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
`(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
`10 extensible protocol, and allows future and vendor-specific
`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
`15 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
`20 network. This is problematic, because IKE key exchanges
`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
`25 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(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,
`45 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(cid:173)
`time password). If IPSec connections are set up manually,
`there is considerable manual work involved in configuring
`65 the IPSec connection parameters.
`Standard IPSec does e.g. not work through NAT devices
`at the moment. A standard. IPSec NT traversal protocol is
`
`0010
`
`
`
`US 9,762,397 B2
`
`6
`!ems 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
`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
`10 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 turmels.
`
`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
`
`5
`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 surfers from high packet drop rates, the
`applications running in the mobile host and a host that the
`mobile terminal is commnnicating 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 15
`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 20
`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 25
`(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 30
`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- 35
`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 40
`security gateway. This solution is similar to the first known
`method, except that two IPSec turmels are used. It solves a
`different set of problems-for instance, NAIL 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 50
`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 nndoes 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 65
`that support. NAT traversal, and possibly a number of other
`(possibly vendor specific) improvements, addressing prob-
`
`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(cid:173)
`nation address is substituted with the found address to the
`45 second computer, and the nnique 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
`matches the outer IP header address fields together with a
`55 unique identifier used by the security protocol, and performs
`a translation of the outer addresses and the nnique 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
`60 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.
`
`0011
`
`
`
`US 9,762,397 B2
`
`7
`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
`SPI values and the other security parameters contain e.g. the 10
`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 15
`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 ills and two sequence 20
`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 25
`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 30
`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" 35
`between the first computer and the intermediate computer.
`IPsec-protected packets are translated by the intermediate
`computer, 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 55
`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 60
`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 65
`the first computer to the intermediate com