Data protection

The basic idea of the proposed solution is to apply IPsec on the inner packets of the tunnels, independently from the external IP+UDP encapsulation. This is one of the advantages of the proposed overlay approach. Since the IP addresses within the tunnels established between a MH and a given Anchor Node never change, a rekeying of the IPsec Security Associations (SA) bound to these inner IP addresses is not required when a MH moves among different access networks. This represents an advantage compared to other IPsec based mobility management solutions in which each handover results in the SA rekeying.

Figure 20 shows S-UPMT protocol stack, which consists of the following layers:

1. a per-application forwarding layer responsible for retrieving the IP in UDP tunnel parameters and performing NAT on the local virtual IP address.

2. An IPsec layer responsible for packet encryption, integrity, authentication.

3. An IP header compression layer responsible for reducing the overhead introduced by the additional IP header of the IPsec tunnel mode SA. The IPsec tunnel header is replaced by a compressed header (COH).

4. An IP+UDP encapsulation layer. Note that this tunneling mechanism is also the standard encapsulation method for IPsec NAT traversal. For this reason the UPMT IPsec extension still provides NAT traversal support.

Figure 20 S-UPMT protocol stack

The details of the tunneling and IPSec operations change in the MH-to-AN scenario with respect to the MH-to-FH or MH-to-MH scenarios. In the first case, since the AN is not the end point of the application data flows protected by IPsec, the tunnel Security Association must be in tunnel mode (as in any IPsec end-point to security gateway scenario). In the other cases (MH-to-FH or MH-to-MH) IPSec can be used in transport mode. The need of tunnel mode for the MH-to-AN case is a drawback from the point of view of the overhead that is introduced, but we will see that header compression techniques may alleviate the problem.

5.2.1 MH-to-AN tunnel operation details

Let us consider the following scenario. A legacy web browser on MH is communicating with a legacy web server LS at the address LS_addr through a TCP socket open with source port sport destination port dport. MH starts up with a fixed virtual IP address VIpA_fix, associates with AN1 obtaining a per-association unique virtual address VIpA_pau1 and establishes a SA_tunnel pair. The operation performed in the MH on a generic HTTP packet from MH to LS can be summarized by the following steps (see Figure 21):

1. At IP/TCP level the packet is routed through the virtual interface viface and thus the source address is IP.src=VIpA_fix. As it enters the UPMT layer, the HTTP packet is identified by the following application flow: (tcp, VIpA_fix, LS_addr, sport, dport).

The PAFT look up results in the following tunnel parameters: (iface_out, sport), (AN1, dport). Moreover, the VIpA_fix is finally NATed into the unique virtual IP address VIpA_pau1 assigned from AN1.

2. The packet is passed to a standard IPsec layer to be encrypted, authenticated and tunneled in a further IPv4 tunnel header. See Section 5.1.4 for the details about the Security Policies and Security Associations management.

3. The IP tunnel header (of the IPsec SA) is compressed as described in Section 5.2.3.

4. The packet is encapsulated within the proper IP in UDP tunnel according to the PAFT look-up in step 1 and it is sent towards LS.

Figure 21 Packet transformation through S-UPMT stack

The IP+UDP encapsulation mechanism makes the IPsec inner packet traverse the NAT without any further operation. The tunnelled packet is then received by AN1. The following operations are performed by AN1:

1. The IP+UDP encapsulation header is removed and the tunnel parameters (IP.src, IP.dst, UDP.source_port, UDP.destination_port) are stored.

2. The IPsec tunnel header is decompressed as described in Section 5.2.3.

3. The inner packet is passed to the IPsec layer for decryption, Massage Authentication Code verification and tunnel removal.

4. The returned packet (supposedly the original HTTP packet: Figure 21, step 1) is associated to the tunnel parameters retrieved in Figure 21, step 2 and the PAFT is updated.

5. Address IP.src of the original HTTP packet is finally masqueraded with the public AN1 IP address and sent to LS.

As for the inverse path from LS to MH, the operations performed on the HTTP reply packet are symmetric and can briefly summarized as follows:

• At AN1: (i) IP.src NAT reversion (VIpA_pau1); (ii) PAFT look-up; (iii) IPsec operations (encryption, MAC computation, tunneling); (iv) IP+UDP packet encapsulation (PAFT look-up).

• At MH: (i) IPsec tunnel header decompression; (ii) IP+UDP header removal; (iii) IPsec operations (decryption, MAC verification, tunnel removal); (iv) VIpA_fix restoration and packet delivery to the IP/TCP stack.

5.2.2 End to End tunnel operation details

The operations described in the previous sections are slightly modified in case of direct communication between two UPMT aware nodes. This can be the case of MH-to-FH or MH-to-MH.

Figure 22 End-to-end tunnel operations

The main differences are the following:

1. the IP+UDP tunnel endpoints are the same endpoints of the application flow, hence IPsec can be used in transport mode. This reduces the overhead introduced by IPsec and simplifies the overall SAs negotiation.

2. The tunneled packets are de-capsulated directly by the application flow end-point. For each received tunneled packet, the encapsulation header is removed, the PAFT is updated and the inner packet is forwarded to local upper layers. In some cases, when the end-to-end tunnel is set up with a redirection procedure from a pre-existing tunnel (section 4.4.1) a NAT operation is needed to hide the redirection to the upper layers and preserve the existing sockets..

3. If IP header compression is used, some changes are needed with respect to the approach depicted in the previous sections.

5.2.3 UPMT header compression

The proposed tunneling approach for mobility management is responsible for introducing a overhead due to the additional IP+UDP encapsulation header, that can be quantified in 28 bytes (20 bytes of IP header without options, 8 bytes of UDP header). Nevertheless, end-to-end header compression can be performed in the proposed solution because inner packets are handled only at the two ends of the IP in UDP tunnel link between the mobile node and the anchor node. In other words, the IP in UDP tunnel can be seen as a point-to-point link with unreliable packet delivery, univocally identified by the 4-tuple (IP.src, IP.dst, L4.source port, L4.destination port).

IP header compression is a well known issue and plenty of solutions have been proposed in literature. Without considering novel header compression approaches, we can cite three IETF standardized solutions: compressed TCP (CTCP) by Van Jacobson [25], IP Header Compression (IPHC) and its RTP extension (CRTP) [26][27], and Robust Header Compression (ROHC) [28]. ROHC seems to be the most suitable solution for the following two reasons: (i) ROHC provide a robust context repairing mechanism well suited for lossy links; (ii) on top of ROHC base framework is possible to design specific profiles to build up the actual compression protocol.

Even though the use of ROHC in S-UPMT is possible, the integration of ROHC along with the creation of a ROHC profile for S-UPMT are out of the scope of this paper. What we propose is a simple header compression solution aimed to compress the 20 bytes of

the IP tunnel header plus 8 bytes of ESP header in a 8 byte compressed header (COH, see Figure 23).

The COH consists of the following fields:

• TAG: this octet is set to the binary value 10000000. The first bit is set to 1 and the other seven are not considered in this paper (they could carry additional information on the compressed header format that are not required for the proposed solution).

This field is basically used to distinguish a COH packet from a valid IPv4 or IPv6 header, which have the first 4 bits respectively set to 0100 (IPv4) or 0110 (IPv6).

• sa_ref: a per-association unique reference (sa_ref) to the 3-tuple (spi_n, sec_tun_src, sec_tun_dst), where spi_n is the IPsec Security Parameter Index, sec_tun_src and sec_tun_dst are respectively the source and destination IP address of the external IP header for the tunnel mode security association (see Section 5.1.4). Since sa_ref is 3 bytes value, the SPIs negotiated at association time have to be less then (2²⁴ - 1)).

• Sequence Number: ESP Sequence Number as in the uncompressed packet.

Figure 23 Original IP/ESP header and COH

This compression profile is justified by the following considerations:

• The first octet of the IP header is fixed and set to 0x45 (Vers: IPv4, HL: 20 bytes).

• IP Protocol field is fixed and set to 0x32 (ESP)

• IP TOS field is not considered by UPMT IPsec layer.

• IP Total Length can be inferred from the IP+UDP encapsulation header.

• IP Time To Live can be set to a fixed value (e.g.: 0x40).

• IP Header Checksum verification is ignored and IP checksum is simply recalculated by the de-compressor before applying IPsec.

• Because the inner packet is handled only at the two ends of the tunnel, and the MTU are properly configured, fragmentation of the inner IP payload never occurs

(see next section for details). Therefore, the following IP header fields are ignored:

ID, Flags, Fragment Offset.

• IP Source and Destination addresses and ESP SPI fields are univocally bound to the value sa_ref as described in Section 5.1

Since there is no need to establish a context between the two communicating parties, the compressor can start at any time to send compressed packets and the COH is constructed as described above. Compressed and uncompressed packets can co-exist on a tunnel.

The de-compressor performs the following operations on a de-capsulated IP packet:

1. UPMT de-compression is skipped if the first bit is set to 0. Otherwise, the packet is considered compressed and processing as follows.

2. The 3-tuple (spi_n, sec_tun_src, sec_tun_dst) is retrieved for the IP in UDP tunnel from which the packet has been received.

3. The original IP-ESP header is reconstructed as follows: (i) ignored fields are set to 0; (ii) fixed fields are set as described before in this section; (iii) IP source and destination addresses and ESP SPI are set to the values retrieved in point 2; (iv) IP checksum is recalculated; (v) ESP Sequence Number is set to the value carried in the COH.

5.2.4 IP Fragmentation support

In the previous section we did not consider the IP fragmentation for inner packets. The fragmentation of inner packets can be avoided in the MH-to-AN scenario, because we can turn it into fragmentation of the outer packet.

On the MH side the fragmentation of the inner packet can be avoided by encapsulating it into the external IP-UDP packet that will be fragmented if needed.

On the AN side where the external NAT is performed, if IP fragments arrive coming from the Corresponding Host, they will be reconstructed before NAT operations. The IP packet that needs to enter in a tunnel will be encapsulated into the external IP-UDP packet that will be fragmented if needed.

In case we want to consider a more generic UMPT framework that needs to support fragmented packets over the MH to AN link, two approaches are possible: (i) fragmented packets are left uncompressed; (ii) one of the reserved bit in COH header are set to “1” to indicate a different compression mode and COH format (this is not addressed in this document).

We note that fragmentation can be avoided by setting the Maximum Transfer Unit (MTU) of the virtual interface as follows:

MTU_viface = MTU_min – UPMT_tun_hdr_len

where: MTU_min is minimum MTU value among all physical interfaces under UPMT control; UPMT_tun_hdr_len is the length of the IP+UDP encapsulation header, i.e: 28 bytes.

This approach works in case of applications that retrieve the MTU of the outgoing interface to set the MAX PDU. Solutions to avoid fragmentation in other cases (for example when applications perform MTU Path Discovery) are not covered in this work.