Internet Security Protocol (IPsec)

The  TCP/IP  stack  was  initially  used  mainly  in  academic  environments,  where  designers were not particularly concerned about security issues. Nevertheless, the  significant growth of the Internet, driven by e‐commerce demanded the creation of  new  services  that  incorporated  sound  security  provisions.  Hence,  the  Internet  Engineering Task Force (IETF) established a working group whose objective was to  develop an IP security protocol suite. This was named IPsec [KA98]. The function of  IPsec is to secure Internet communication at the network layer. IPsec supports both  IPv4 and IPv6 [DH98] with a set of extensively configurable security services. IPsec is 

an obligatory component of IPv6 that succeeded the IPv4. However, the use of IPsec  is optional within IPv4. 

The tasks of IPsec cover data confidentiality, data integrity, access control, data  origin authentication and anti‐replay protection. 

Due to the fact that IPsec is method‐independent, it can be implemented by using a  wide range of different cryptographic algorithms. 

2.5.2.1 Overview

IPsec is a set of cryptographic protocols for securing packet flows and key exchanges.  

Two of these packet flow protocols, namely the Encapsulating Security Payload (ESP)  [KA98a] provides authentication, data confidentiality and message integrity, whereas  the  Authentication  Header  (AH)  [KA98b]  provides  authentication  and  message  integrity, but does not offer confidentiality. The AH was originally only used for  integrity while the ESP was only used for encryption. The function of authentication  was subsequently added to the ESP header. 

Key establishment and management are crucial tasks for the architecture and are  performed by the Internet Key Exchange (IKE) [HC98] protocol as introduced in  Section 2.5.3. 

Standards produced by the IETF are referred to as Request For Comments (RFCs). The  connections between IPsec related RFCs are depicted in Figure 5. 

Figure 5: IPsec Related RFCs 

2.5.2.2 Modes of Operation

Depending on the type of node, IPsec is intended to operate in two different modes: 

Transport Mode and Tunnel Mode. The former simply attaches IPsec extension headers  and is commonly used for host to host communication, whereas the latter provides a  secure tunnel between two gateways. The tunnel mode can be used to implement  portal‐to‐portal communication security between intermediate nodes. Security is  provided for several machines or even to a whole sub‐network by a single gateway  node that is typically a firewall or router. Traffic destined for a final host, traverses  the security gateway. The gateway encapsulates the traffic and forwards it to a  second gateway via tunneling. Similar to IP‐in‐IP encapsulation, the IPsec tunnel  involves two IP headers: An inner header containing the original sender and receiver  and an outer header where the tunnel endpoints act as sender and receiver. Figure 6  illustrates IP datagrams in transport and tunnel mode. (1) represents a standard non  IPsec datagram which is extended by inserting AH in order to authenticate the entire  datagram in (2). In (3) a new outer header is attached for transferring the message in  tunnel mode. This header authenticates both inner and outer headers; (4) represents  the  ESP  usage  in  transport  mode.  The  payload  and  trailer are  encrypted  and  optionally authenticated by the ESP authentication extension; (5) shows ESP in  tunnel mode with a new outer header attached. The inner header is encrypted and  thus is invisible in transit within the tunnel. (6) Illustrates the case when both AH  and ESP are utilized in order to provide authentication for the IP header in transport  mode.  

Figure 6: IPsec Modes of Operation 

The inner IP header is encrypted and not visible on traverse. A security gateway can  be installed on an end point of the connection in order to provide security for  network access. When both gateways are on an intermediate node, the tunnel is  completely transparent to the endpoints and can thus be used to achieve a Virtual  Private Network (VPN) [BKW05]. Hence, transport mode in this case is inadequate. 

Tunnel mode can also be applied for host‐to‐host communications, but it is especially  useful when at least one of the endpoints is a security gateway.  

2.5.2.3 Technical Details

IPsec  involves  two  extension  headers:  The  Authentication  Header  (AH)  and  the  Encapsulated Security Payload (ESP). One of them or both can be attached to an IP  packet in order to provide security properties. 

Authentication Header 

The  AH  is  intended  to  guarantee  connectionless  integrity  and  data  origin  authentication of IP datagrams. It also includes an optional anti replay protection by  using the sliding window technique and discarding old packets. AH protects all fields  of an IP datagram by attaching an AH extension header to the IP packet as illustrated  in Figure 7. Fields that change during transfer have been excluded.  

Figure 7: AH Packet Format 

The fields of the AH have the following definitions: 

• Next Header: Identifies the protocol of the transferred data (e.g. TCP or UDP) 

• Payload Length: The overall size of the AH packet. 

• RESERVED: Reserved for future use (all zero until used). 

• Security  Parameters  Index  (SPI):  Identifies  the  security  parameters  in  combination with the IP address. 

• Sequence Number: A monotonically increasing number for the sliding window  in order to prevent replay‐attacks. 

• Authentication Data: Is an Integrity Check Value (ICV) for authenticating the  entire IP  datagram and is computed  by either symmetric or asymmetric  encryption algorithms. A hash [MIS95, Rob94] or HMAC [KBC97, MG98,  MG98a] as presented in 2.3.6 is commonly used for that purpose. 

In order to verify a received datagram, the receiver computes the ICV over all the  appropriate fields, filling the mutable IP header field with zeros and using the 

specified authentication algorithm. When the value attached to the packet coincides  with the ICV, then the datagram is verified as having been sent by the claimed  sender.  

The AH protection in transport mode covers the entire payload, including the upper  layer protocol data and all those fields of the IP header which have not been  modified in transit. In contrast, the AH in tunnel mode, encapsulates the IP datagram  with a new IP header in order to enable the protection to extend to the payload and  the whole header. 

Encapsulated Security Payload 

The ESP extension header, as illustrated in Figure 8, also provides data origin  authentication and confidentiality.  

Next Header Pad Length

Security Parameter Index (SPI) Sequence Number

Authentication Data Padding (0-255 bytes)

Payload

• Security  Parameters  Index  (SPI):  Identifies  the  security  parameters  in  combination with the IP address. 

• Sequence  Number:  A  monotonically  increasing  number,  used  to  prevent  replay‐attacks. 

• Payload  Data: The  actual  data  to be  transferred  which  has been  either  authenticated, encrypted, or both. 

• Padding: Used with some block ciphers in order to fit the data into the full  length of a block. 

• Pad Length: Size of padding in bits. 

• Next Header: Identifies the protocol of the transferred data. 

• Authentication Data: Contains the data used to authenticate the packet. 

In contrast to AH, ESP does not authenticate any IP header field when used in  transport mode. However, in tunnel mode, ESP covers the whole IP datagram. 

Confidentiality is achieved by encrypting the payload plus padding and by inserting  the resulting cyphertext in the datagram. Thus, replacing the original plaintext. 

Security Databases  

The protection of IPsec is based on a set of requirements defined in two databases. 

The Security Policy Database (SPD) and the Security Association Database (SAD). The  former specifies general policies and is applied to all IP traffic inbound or outbound  from a host or security gateway. The latter is more specific and contains parameters  associated with an individual connection. 

The SPD specifies which security services are on offer to IP datagrams and the  method in which they are applied. The database has to be consulted for all inbound  and outbound traffic, including that of non‐IPsec traffic. The purpose of this is to  distinguish between packets that need IPsec processing, those that are allowed to  bypass it and packets that should be dropped. This filter acts according to the source  and destination address as well as to the corresponding ports.  

When an IP datagram is required to be protected by IPsec, a query is made to the  SAD. The SAD specifies details on the services that should be provided, as well as  the protocols and algorithms to be used. The following entries are required to form a  security association (SA). This is referred to as a simplex connection between nodes: 

• Authentication mechanism for AH 

• Encryption mechanism for ESP 

• Authentication mechanisms for ESP 

• Lifetime of the SA (Time in seconds and maximum amount of traffic in  Kbytes) 

• Replay protection (only in conjunction with IKE)  

• Encapsulation mode (Tunnel or Transport) 

Securing  a  bidirectional  data  stream  between  two  hosts  always  involves  the  establishment of at least two SAs, one in each direction. IPsec SAs are security  policies defined for communication between two or more entities; the relationship  between the entities is represented by a key.