IPC@CHIP® RTOS-PPC – API Documentation
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:
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:
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.
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.
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.
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-PPC 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.