@CHIP-RTOS - IP Security Overview

    IPC@CHIP® Documentation Index

IP Security Overview

IP Security API
IP Security data structures
IPsec NAT-Transversal

IP Security (IPsec) can provide data encryption and/or authentication.   This is implemented at the IP level for either IPv4 or IPv6.   IP Security is implemented with two additional IP header types:

  • Authentication Header (AH)
  • Encapsulated Security Payload (ESP)
In the discussion below the transport of the following IP message will be considered:


The use of TCP as the upper protocol here is taken only for illustration.   Any other upper layer protocol would work in the same manner.

IP Security offers a choice of two different encapsulation modes:
  • Transport Mode - In this mode the IP packet travels directly between two peers.

  • Tunnel Mode - In this mode the IP packet is re-addressed to first be passed to a specified remote security gateway computer.   The IPC@CHIP® computer plays the role as the local gateway computer at which the tunnel begins.   The gateway computers will use the original IP header that is nested inside the tunneled IP packet to forward this packet to it's final destination in plain text form, after performing the necessary decryption and authentication.

Authentication Header

The Authentication Header provides a hash value over the encapsulated message and the IP header.   This hash value can be used by the receiving side to verify that the message has originated from the intended source and that no bit of the message has been altered in route.   The resulting IP packet will look as follows, depending on whether tunnel or transport mode is selected.

The AH protocol cannot be used when a NAT device is in the path between IPsec peers.   The fundamental problem here is that NAT devices make changes to the IP header, which invalidates the AH hash value.


Encapsulated Security Payload

The Encapsulated Security Payload protocol provides encryption of the IP message.   It may also optionally be used to append a hash value for message authentication.   However, note that the ESP authentication does not cover the IP header (see diagrams below) as does the heavier duty AH type authentication.


ESP and AH Combined

The illustration below shows the conventional way of combining ESP and AH.   (The specifications for these protocol would allow other variations as well.)   When ESP and AH are both applied to IP messages, the ESP is applied first as the inner protocol.   This is then wrapped with the AH header.


For tunnel mode, the ESP protocol is used in tunnel mode while the AH operates in transport mode.   Note that the optional authentication offered by ESP is not used in this example where both ESP and AH are used.   The AH should provide adequate authentication.

IPsec NAT-Transversal

In IPv4 networks, Network Address Translator (NAT) functionality is commonly found inside routers connecting to the Internet.   The AH protocol cannot be used when a NAT device is in the path between IPsec peers.   ESP protocol can be made to work across NAT devices by encapsulating the ESP data inside UDP datagram.

The IPC@CHIP® implementation provides negotiation of IPsec NAT-Transversal per RFC-3947 and ESP protocol encapsulation with UDP per RFC-3948.   The "draft 2" of the RFC-3947 ("draft-ietf-ipsec-nat-t-ike-02") negotiation is also supported.   The "draft 2" support enables operation with current (year 2007) Microsoft Windows XP NAT-Transversal implementations for ESP transport mode.   ESP tunnel mode operation between Microsoft Windows XP and the IPC@CHIP® has not been achieved.   However, ESP tunnel mode operation between @Chip-RTOS devices across a NAT will work.

By default, this NAT-transversal capability is enabled.   It can be deselected with the CHIP.INI [IPSEC] NAT entry.

End of document