S-UPMT procedures

S-UPMT

The solutions proposed in Sections 3 and 4 did not consider any security aspects, related for example to: 1) authentication of the hosts and the virtual IP addresses; 2) confidentiality, authentication and integrity of both data traffic and UPMT signaling traffic;

3) dynamic key establishment.

In this section we provide a set of security extensions to the basic UPMT solution. The proposed solution is based on two different approaches. If IPsec is supported by both communicating peers, both signaling and data traffic between MH and AN are protected by IPsec. If IPsec is not supported by either MH or AN, a TLS channel is brought up to protect tunnelled signaling. In this case, data traffic is left unprotected.

5.1 S-UPMT procedures

UPMT signaling described in Sections 3 and 4 is insecure because it is simply mapped into SIP procedures without any kind of security mechanisms as for confidentiality, data integrity and authentication. A possible trivial solution could be the use of an underlying TLS secure channel for UPMT/SIP messages exchange. Unfortunately, this approach would require to perform a new TCP connection and establish a new TLS session (in the worst case) for each handover. Even though the resulting handover execution delay might be considered irrelevant in a “make before break” scenario, this would surely lead to a service disruption in a “break before make” scenario.

The proposed solution is based on two different approaches. If IPsec is supported by both communicating peers, both signaling and data traffic between MH and AN are protected by “secure IPsec tunnels”. If IPsec is not supported by either MH or AN, a tunneled TLS channel is brought up to protect the signaling traffic. In this case, data traffic is left unprotected.

Figure 16 S-UPMT association procedure

S-UPMT association procedure is depicted in Figure 16. The initial handshake - called UPMT Association Phase 1 – is performed outside the UPMT tunnels and is protected with TLS. The goals of this first association exchange are: (i) to mutually authenticate both parties (AN e MH); (ii) to protect UPMT Association Request (and to receive a per-association unique VIpA), (iii) to request a Security Association (SA) pair if IPsec is supported.

If the use of IPsec is agreed in Phase 1 by both MH and AN, a UPMT Association Phase 2 is performed within the same TLS channel as Phase 1 and it is intended to exchange the cryptographic material to establish the security association pair requested in Phase 1.

If IPsec is not supported, the goal of UPMT Association Phase 2 is to establish a new TLS secure channel to protect the (tunnelled) signaling traffic generated form the virtual interface. Since the TLS session is bound to MH virtual IP address, MH will not be required to set-up a new TLS channel after any possible IP reconfiguration of the real network interfaces.

In both cases, UPMT signaling traffic will be “cryptographically protected” and its session continuity will be preserved by the UPMT IP/UDP tunneling mechanism.

In the reminder of this section we describe the details of UPMT procedures. We make the assumption that every node in the UPMT domain holds a valid X509 Certificate binding a public key to the SIP URI identifying the node. Furthermore, for ANs and FHs, UPMT X509 certificates have to certificate also their public IP address(es). The definition of a X509

“UPMT profile” is outside of the scope this paper.

5.1.1 UPMT Signaling Protection

Once the initial association is complete (with mutual authentication and SAs establishment) we considered to protect the signaling traffic by either of the following mechanisms:

1. sending UPMT/SIP messages over a secure TLS channel within a non-secure IP in UDP tunnel.

2. sending UPMT/SIP messages in clear over TCP or UDP and then protect them with the same IPsec SAs used for the data traffic.

For both approaches, the mobility services for the signaling traffic is provided by UPMT approach based on virtual interfaces, or in other words, by considering the signaling data flow as a generic application data flow under UPMT control.

As for the offered security services, the two approaches rely on well known and mature standards, and can be considered equivalent. We preferred to consider as mandatory the first approach, i.e. to use TLS over insecure tunnels. In this way the signaling protection and the data protection are decoupled and the former does not depend on the latter.

Therefore we could support a scenario in which IPsec is not implemented in the MH. In this case, data traffic is sent over insecure IP in UDP tunnels, whereas signaling traffic is protected without requiring modifications to the network stack (TLS is widely and efficiently implemented in user-space).

5.1.2 UPMT Association Phase 1

UPMT Phase 1 is protected and authenticated with TLS. MH and AN are configured so that mutual authentication is performed by X509 certificate verification. Upon TLS handshake successful completion, MH sends a UPMT association request indicating the intention to use IPsec, if supported.

AN1 replies with a UPMT association response containing a per-association unique virtual IP address (VIpA_mh) and an indication regarding the use of IPsec. If IPsec is supported and requested by both parties, the same TLS session will be used in UPMT Phase 2 to establish the IPsec SA pairs; otherwise the TLS session is closed and the binding between VIpA_mh and MH certificate is stored by AN1.

5.1.3 UPMT Association Phase 2 – TLS protection mode

In case IPsec is not used, in UPMT Phase 2 a new TLS secure channel is established.

All messages exchanged after Phase 1 are protected using TLS over insecure IP in UDP tunnels. This means that once the initial UPMT association is completed mobile node has to connect a new TLS socket to the anchor node and route its packets through UPMT virtual interface, so that all subsequent messages will carry the per-association unique VIpA as IP source address. Authentication of MH is still performed by verification of MH UPMT X509 certificate within the TLS handshake. If we assume that AN keeps the list of VIpAs assigned to MH, authentication of MHsip_uri also authorizes the use of the VIpA as source address for TLS messages.

As long as the timeout of the underlying TCP socket is not expired, the TCP connection is always active, and TCP three-way handshake is not required due to readdressing of the real network interfaces. Note that, in order to avoid closure of the TLS session, a UPMT KeepAlive messages should be periodically sent by MH before the signaling idle time reach the TCP timeout. If supported by the TCP implementation, TCP keepalive option may be enabled and used in place of UPMT keepalive messages.

5.1.4 UPMT Association Phase 2 – IPsec protection mode

If IPsec is used between MH and AN, UPMT Phase 2 is performed within the same TLS session as in UPMT Phase 1 to dynamically establish a IPsec SA pair. The actual protocol used to set-up the IPsec SAs is irrelevant as long as the channel used is “secure”. Well known standard key establishment protocol (like IKEv2 [9]) could be used, but we can more simply exchange the SA parameters and secrets within the TLS secure channel brought up in Phase 2.

Indeed, the chosen solution is to transfer over the TLS channel brought up in Phase 2 a master secret key and the supported SA parameters. Figure 17 shows the details of a UPMT-S Association Phase 3: MH sends a UPMT SA-Request message to AN containing the following values:

1. MKS: is a master key secret chosen by MH, from which all cryptographic keys are derived (e.g., by expansion with secure Pseudo Random Function - PRF). This approach is similar to TLS RSA key transfer, in which the MKS is chosen by the client and sent to the server encrypted with the server public key.

2. MHparam: is the list of IPsec SA parameters: (i) SA type: transport or tunnel (in this case, i.e. MH-AN communication, this value is “tunnel mode”); (ii) Cipher suite: is a list of cryptographic, MAC algorithms and PRF supported by MH, in order of preference; (iii) MH SPI: a (random) security parameter index for the SA from MH to AN; (iv) sa_ref: a unique reference to the 3-ple (SPI; IP source address, IP destination address) for the MH incoming SA.

AN replies with a UPMT SA-Response message containing the list of parameters ANParam that contains the following values: (i) the chosen IPsec cipher suite; (ii) the SPI for the SA from AN to MH; (iii) sa_ref: a unique reference to the 3-ple (SPI; IP source address, IP destination address) for the AN incoming SA.

Figure 17 S-UPMT Phase 2 details

Upon successful completion of Phase 3, both AN1 and MH expands the MSK to obtain the required keys (accordingly to the chosen cipher suite) and set-up the resulting IPsec SA pair.

Let us consider the case of a tunnel mode SA pair between MH and AN with public IP address ANaddr. The SPIs are denoted as spi_mh and spi_an. The IP address of the IPsec tunnel for MH and AN are respectively VIpA_mh and ANaddr. The resulting Security Policy Database (SPD) and Security Association Database (SAD) for MH (SPD and SAD for AN are symmetric) are the following:

MH SPD-S:

IF (IP.src = VIpA_pau1) & (IP.dst != ANaddr) & (proto=”any”) THEN use SA1 IF (IP.src != ANaddr) & (IP.dst = VIpA_pau1) & (proto=”any”) THEN use SA2

MH SAD:

SA1: OUT, spi_mh, ESP, tunnel mode(sec_tun_mh, sec_tun_an1) SA2: IN, spi_an1, ESP, tunnel mode(sec_tun_an1, sec_tun_mh)

We want to stress the fact that we consider two different Phase 2. This is because IPsec protocol suite could be not implemented in the mobile node and UPMT and thus, in this case signaling messages can still be protected with TLS (which is typically implemented in user-space), whereas tunnelled data traffic are either transmitted in clear or protected with other security mechanisms.

5.1.5 Tunnel Server Redirection procedure

In Section 4.4.1 a procedure for changing one end point of a tunnel link and redirect an already established encapsulated data flow from one tunnel server to another has been proposed as part of some UPMT extensions to improve scalability. Integration of the relevant signaling flow and data protection into S-UPMT needs careful consideration, since changing the tunnel server implies changes in the IPsec SA protecting the data flow.

Figure 18 shows the protected Tunnel Server Redirection procedure. Let us assume that FH is a fixed node with a public IP address FHaddr, SIP URI FHsip_uri and UPMT capabilities. We define the pair (FHaddr, FHudp_port) on which the UPMT tunnel server is listening for UPMT encapsulated data flow as Tunnel Server Address – TSA. Furthermore, let us assume that MH has successfully associated with AN, obtained a virtual address VIpA and a tunnelled data flow addressed to FH is properly received and forwarded by AN.

As soon as FH receives the first packet, it understands that an UPMT anchor node acting as UPMT NAT on behalf of a mobile node and initiates a association procedure with AN.

Upon successful TLS authentication, FH sends a UPMT AssocReq including the same FHsip_uri authenticated within the TLS handshake and an indication of a possible tunnel redirection (TSreq - which also includes FH’s TSA and an indication of the application flow - app_flow - to redirect). Again, we assume that FH owns a PKC binding a public key to the SIP URI (and the IP addresses) identifying the node.

AN acknowledges FH with an AssocResp message and sends to MH a Tunnel Server (TS) Redirect containing the following values:

1. FH Tunnel Server Address - TSA

2. An indication of the NAT association (NAT Binding Indication – NATBI) between the application flow (app_flow) at the ingress of the second level NAT in the AN and the source IP and port (IP_nat, PORT_nat) at the egress of the AN NAT.

3. FHsip_uri is authenticated by AN within the TLS handshake.

Figure 18 Tunnel server redirection

MH can decide to communicate directly with FH for the specified application flow. If so, MH starts a UPMT Association Procedure by sending a AssocReq message to FH. The association takes place as described in the previous sections except for the following aspects:

1. MH includes the NAT binding indication (NATBI) in the AssocReq message.

2. Since MH and FH are the endpoints of the data flow, IPsec transport mode is used.

This indication is included the SA parameters exchanged in phase 2.

3. The IPsec parameters sent in the SA parameters exchanged in phase 2 don’t include the tunnel IP addresses.

4. VIpA_pau2 univocally identifies MH at FH.

Upon successful completion of the association procedure: (1) FH will store in its PAFT the binding between app_flow and the new tunnel; (2) MH will update the local PAFT for the application flow indicated in the NATBI and send packets towards FH over a new tunnel. To preserve session continuity, FH will locally NAT the source IP address and port of the incoming packet according to the NATBI.

5.1.6 S-UPMT signaling overview

Figure 19 shows a possible complete UPMT messages flow between MH and AN when IPsec is used. As described in the sections above, MH and AN authenticate against each others with a TLS handshake. MH obtains a virtual IP address locally unique at AN and request IPsec to protect both data and signaling traffic. MH and AN perform Association Phase 2 to exchange the key material and set-up the SAs negotiated in Phase 1. At this point MH request a tunnel and starts sending packet within this tunnel. MH registers a new tunnel for a second network interface and handoff the application data to this tunnel. AN updates the PAFT and start forwarding the response packet for this application flow in the new tunnel. After a period during which MH doesn’t send any packet within Tunnel 1, a keep-alive is sent to refresh the NAT binding for that IP/UDP flow.

Figure 19 S-UPMT Signaling