`
`1111111111111111111111111111111111111111111111111111111111111
`US008346949B2
`
`c12) United States Patent
`Vaarala et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 8,346,949 B2
`Jan.1,2013
`
`(54) METHOD AND SYSTEM FOR SENDING A
`MESSAGE THROUGH A SECURE
`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) PCTFiled:
`
`Jan.21,2003
`
`(86) PCTNo.:
`
`PCT /FI03/00045
`
`§ 371 (c)(l),
`(2), ( 4) Date: Oct. 19, 2005
`
`(87) PCT Pub. No.: W003/063443
`
`PCT Pub. Date: Jul. 31, 2003
`
`(65)
`
`Prior Publication Data
`
`US 2006/0173968 AI
`
`Aug. 3, 2006
`
`(30)
`
`Foreign Application Priority Data
`
`Jan. 22, 2002
`
`(FI) ...................................... 20020112
`
`(51)
`
`Int. Cl.
`G06F 15116
`(2006.01)
`(52) U.S. Cl. ............................................ 709/229; 726/3
`(58) 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 Ylonen
`6,957,346 B1
`10/2005 Kivinen et al.
`6,985,953 B1 *
`................ 709/229
`112006 Sandhu et al.
`7,055,027 B1 * 5/2006 Gunteretal. ................. 713/151
`200110047487 A1 * 1112001 Linnakangasetal. ........ 713/201
`2002/0004900 A1 *
`1/2002 Patel ............................. 713/155
`2002/0091921 A1 * 7/2002 Kunzinger .................... 713/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(cid:173)
`sage from a first computer to a second computer via an inter(cid:173)
`mediate computer in a telecommunication network. A mes(cid:173)
`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
`
`IPsec translation
`IKE translation
`
`Standard IPsec
`
`Standard IKE
`(optional)
`
`Modified IKE
`protocol (optional)
`
`Enhanced
`IPsec
`
`Plaintext packets
`
`Ex. 1001
`Apple v. MPH Techs. Oy
`IPR2019-00822
`
`0001
`
`
`
`IPsec
`
`Enhanced I
`
`1
`
`I
`
`IPsec translation
`IKE translation
`
`2
`
`Standard IPsec
`
`~I
`
`Standard IKE
`{optional)
`
`I
`
`Modified IKE
`protocol {optional)
`
`I
`
`FIG. 1
`
`3
`
`~
`
`I
`
`Plaintext packets
`
`A
`
`~
`00
`•
`~
`~
`~
`
`~ = ~
`
`~
`
`~ := .... ~
`0 ....
`
`N
`
`(.H
`
`('D
`
`rFJ =-('D
`.....
`....
`0 .....
`0\
`
`d
`rJl
`00 w
`~
`0'1
`\c
`~
`
`\C = N
`
`0002
`
`
`
`U.S. Patent
`US. Patent
`
`Jan.l,2013
`Jan. 1, 2013
`
`Sheet 2 of 6
`Sheet 2 of 6
`
`US 8,346,949 B2
`US 8,346,949 B2
`
`><
`t(cid:173)
`C/J
`0
`:I:
`
`X.50:
`
`~~
`
`.....
`JB
`~
`0..
`E
`0
`0
`"C c:
`8 Q)
`
`(/)
`a.
`E
`
`
`
`
`
`C')
`
`'V
`
`4,..
`
`~r
`
`• CJ -LL
`
`C\1
`
`.~ ..
`
`lt) ,,
`
`N.0."—
`
`.mSano28me.anoofiuwccfls
`
`
`
`8 * ·-"0
`
`Q)
`
`E
`£ c:
`
`..... s :l a.
`.9258EE
`
`E
`8
`~ ·-u..
`
`~
`
`<0
`
`~,
`
`0003
`
`0003
`
`
`
`c-SPI-2
`c-SPI-1
`c-addr-1 c-addr-2
`195.1.2.3 212.90.65.1 Ox80000001 Ox12341234
`- - • • • -------------------~---·-·
`
`- - -
`
`' - - - - - - - - - - - • • •
`
`s-SPI-3
`s-addr-3 s-SPI-2
`s-addr-2
`212.90.65.1 103.6.5.4 Ox1230012 Ox56785678
`
`[_L___
`
`- - - -
`
`._ . . __________
`
`• • •
`
`• • •
`
`'
`
`I
`
`~
`00
`•
`~
`~
`~
`
`~ = ~
`
`~
`
`~ := .... ~
`0 ....
`
`N
`
`(.H
`
`FIG. 3
`
`rFJ =(cid:173)
`.....
`
`('D
`('D
`
`(.H
`
`0 .....
`0\
`
`d
`rJl
`00 w
`~
`0'1
`\c
`~
`
`\C = N
`
`0004
`
`
`
`U.S. Patent
`US. Patent
`
`Jan. 1, 2013
`Jan.l,2013
`
`Sheet 4 of6
`Sheet 4 of 6
`
`US 8,346,949 B2
`US 8,346,949 B2
`
`L.. 2
`::::s c.
`E
`0
`0
`"C c
`
`8 Q) en
`
`.n
`
`q.
`
`~~
`
`·~
`
`~~
`
`('I')
`
`1r
`
`N
`
`·~
`
`,......
`, ..
`
`CD
`
`j~
`
`or-
`or-,lr
`
`0
`or-
`
`·~
`
`10
`or-,,.
`
`v
`or-
`
`·~
`
`m
`or-
`
`~
`
`•
`
`C) -LL
`
`or-, , ......
`
`......
`
`CD
`
`or-
`
`,.
`
`v
`
`ll)
`
`0)
`
`m
`1
`
`N
`('I')
`or-, • or-
`
`0005
`
`Intermediatecomp.Secondcomputer
`
`
`
`FIG.4 First
`
`Q)
`
`ci.
`E
`8
`~ "C
`E Q) -c
`Computer
`
`....
`~
`::::s c.
`E
`0
`(..)
`
`i? u:
`
`0005
`
`
`
`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
`
`I
`
`212.90.65.1
`103.6.5.4
`CKY2
`CKY3 -
`
`-
`
`- -
`
`-
`
`212.90.65.1
`103.6.5.4
`CKY2
`CKY3
`
`- -
`
`-- --
`
`---
`
`---
`
`----
`
`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
`
`-
`
`- - - - - · - -
`
`FIG. 5
`
`~
`00
`•
`~
`~
`~
`
`~ = ~
`
`~
`
`~ := .... ~
`0 ....
`
`N
`
`(.H
`
`('D
`('D
`
`rFJ =(cid:173)
`.....
`Ul
`0 .....
`0\
`
`d
`rJl
`00 w
`~
`0'1
`\c
`~
`
`\C = N
`
`0006
`
`
`
`U.S. Patent
`
`Jan. 1,2013
`
`Sheet 6 of 6
`
`US 8,346,949 B2
`
`Identification type
`
`Identification value
`
`User@Fully-Qualified-
`Domain-Name
`user@Fuii~-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. roam mate. 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
`
`0007
`
`
`
`US 8,346,949 B2
`
`1
`METHOD AND SYSTEM FOR SENDING A
`MESSAGE THROUGH A SECURE
`CONNECTION
`
`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 work- 20
`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(cid:173)
`phone lines and, for instance, optical networks; thereby inter- 25
`connecting geographically disposed users.
`There is a need to protect data and resources from disclo(cid:173)
`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 30
`from being read) integrity (protecting the data from being
`modified, which is a property that is independent of confiden(cid:173)
`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- 35
`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(cid:173)
`viding most of these, but not all of them. (In particulars 40
`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) 45
`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(cid:173)
`cation with other organisations, ensuring authentication and
`confidentiality and providing a key exchange mechanism. 50
`IPSec ensures confidentiality integrity, authentication, replay
`protection, limited traffic flow confidentiality, limited identity
`protection, and access control based on authenticated identi(cid:173)
`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(cid:173)
`ments (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
`
`2
`of the packet for that protocol, Encapsulating Security Pay(cid:173)
`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(cid:173)
`tographic keys and the management of traffic flows related to
`these security protocols.
`Security association (SA) is a key concept in the authenti(cid:173)
`cation and the confidentiality mechanisms for IP. A security
`association is a one-way relationship between a sender and a
`10 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 andAH are combined, or if
`ESP and/or AH are applied more than once, the term SA
`15 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 pro(cid:173)
`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 ofiPSec 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(cid:173)
`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(cid:173)
`ber field inAH 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(cid:173)
`Replay Window is used to determine whether an inboundAH
`or ESP packet is a replay. AH information involves informa(cid:173)
`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
`55 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
`65 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.
`
`0008
`
`
`
`US 8,346,949 B2
`
`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(cid:173)
`cation between two hosts. Transport mode may be used in
`conjunction with a tunnelling protocol, other than IPSec tun(cid:173)
`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 25
`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 30
`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 packet is
`"IPIESPIIPipayload". The whole inner packet is covered by 35
`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 40
`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- 45
`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(cid:173)
`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 55
`tunnel mode authenticates the entire inner IP packet, includ(cid:173)
`ing the inner IP header, and selected portions of the outer IP
`header.
`The key management portion ofiPSec 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 determina(cid:173)
`tion protocol and Internet Security Association and Key Man(cid:173)
`agement Protocol (ISAKMP). Internet key exchange (IKE) is
`a newer name for the ISAKMP/Oakley protocol. IKE is based 65
`on the Diffie-Hellman algorithm and supports RSA signature
`authentication among other modes. IKE is an extensible pro-
`
`4
`tocol, 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
`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
`10 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-
`15 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
`20 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 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. How(cid:173)
`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
`50 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 the
`IPSec connection parameters.
`Standard IPSec does e.g. not work through NAT devices at
`60 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 appli-
`
`0009
`
`
`
`US 8,346,949 B2
`
`25
`
`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 10
`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 15
`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(cid:173)
`bile IP and IPSec tunnelling), the solution is referred to as 20
`"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 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(cid:173)
`sions for improving quality of service of the access network, 30
`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 35
`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(cid:173)
`nelling.
`A third known method is to use a similar intermediate host
`as in the second known method, but establish an IPSec con(cid:173)
`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(cid:173)
`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(cid:173)
`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(cid:173)
`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(cid:173)
`lems such as the access network quality of service variations.
`Regardless of these added features, the IPSec security gate(cid:173)
`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-
`
`6
`back: the IPsec packets are decrypted in the intermediate host,
`and thus possibly sensitive data is unprotected in the interme(cid:173)
`diate host.
`Consider a business scenario where a single intermediate
`host provides improved service to a number of separate cus(cid:173)
`tomer networks, each having its own standard IPSec security
`gateway. Having decrypted packets of various customer net(cid:173)
`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(cid:173)
`rate turmels, causing potential security problems in the inter(cid:173)
`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(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 telecommunica(cid:173)
`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(cid:173)
`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,
`40 and the unique identity is substituted with another unique
`identity. Then the message is forwarded to the second com(cid:173)
`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
`50 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
`55 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
`60 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
`65 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
`
`0010
`
`
`
`US 8,346,949 B2
`
`7
`computer contains message data, an inner IP header contain(cid:173)
`ing actual sender and receiver addresses, an outer IP header
`containing the addresses of the first computer and the inter(cid:173)
`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(cid:173)
`ues). In the following, when an SA is referred to, the same
`applies to an SA bnndle. The other related security param(cid:173)
`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(cid:173)
`puter. The IP header of this packet has IP source and des tina(cid:173)
`tion address fields (among other things). The packet is encap(cid:173)
`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(cid:173)
`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(cid:173)
`mediate computer so that the message can be forwarded to the
`second computer.
`By modifying the translation table and parameters associ(cid:173)
`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(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
`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(cid:173)
`ping table and thus, the intermediate computer can identify
`the mobile next time a message is sent. Preferably, as a result 65
`of a registration request, a reply registration is sent from the
`intermediate computer back to the first computer.
`
`8
`Other examples of possible modifications to the SA-or in
`general, the packet processing behaviour-between the first
`computer and the