White Paper - IPsec in VoIP Networks
IPsec is widely used to provide secure access to corporate private networks. IPsec is specified by TISPAN and 3GPP IMS for both access, core and interconnect applications. However, IPsec and the current range of corporate network edge Network Address and Port Translators (NAPTs) are not compatible with the Next Gen services provided by VoIP architectures. This technical note describes the problems with IPsec, VoIP and NAT traversal and the selection of UDP encapsulated IPsec by TISPAN as a solution.
Background
IP does not have any in-built security capabilities, thus IPsec was introduced to provide the required security services. These include: encryption, authentication, integrity validation and anti-replay. IPsec operates at the network layer (layer 3) making it more flexible than TLS since it can encapsulate both UDP and TCP. However, IPsec assumes that the end-to-end connection does not have to traverse intermediate devices such as NATs which alter the authenticated packets.
NATs are widely deployed throughout the business world (near 100% of all business networks) and also by many domestic IP users; since about 50% of domestic network edge devices have NAT functionality in them (e.g. ADSL modems). More correctly these devices should be call NAPTs – Network Address and Port Translators – unfortunately, as we shall see, IPsec obscures some of this information.
IPsec Details
IPsec has several different modes of operation: Authentication Header (AH) and Encapsulating Security Payload (ESP). These in turn have two connection modes, tunnel mode and transport mode. ETSI and 3GPP specify the use of IPsec ESP tunnel mode in TS 33.210 (interconnect and core) and ESP transport mode in TS 33.203 (access).
AH or ESP?
IPsec Authentication Header (AH) provides authentication of origin, message integrity checking and prevention of replay attacks. In AH mode there is no encryption of the payload, only the header is involved.
IPsec Encapsulating Security Payload (ESP) offers message integrity, data confidentiality, prevention of replay attacks and optionally authentication.
Transport or Tunnel?
In general transport mode is used to secure end-to-end communications between two devices, whilst tunnel mode is used to connect two networks. This is reflected in the 3GPP selection of ESP transport mode for access and tunnel for interconnect.
In transport mode IPsec AH protects both the payload and the IP header fields and inserts a new header between the original IP header and the payload. In tunnel mode the whole IP packet is encapsulated within an AH and new IP header.
The AH header allows the recipient to detect out of sequence packets, and authenticate the sender. It also protects the integrity of the payload and header, the recipient recalculates the hash and a mismatch indicates data tampering or incorrect key, the packet it therefore discarded.
For this reason IPsec AH is incompatible with NATs of any type since the function of a NAT is to alter the packet header, specifically the IP address. The AH mechanism will then cause the packet to be discarded as the calculation of the data integrity will indicate that the packet has been altered.
ESP in both transport and tunnel modes encapsulates and encrypts the required data and appends it to the original IP header (only changing the protocol field), therefore ESP is more 'NAT friendly'. Transport mode ESP encapsulates just the payload, i.e. the UDP or TCP part, whilst tunnel mode encapsulates the whole IP packet. There is no check that the encrypted portion matches the non-encrypted portion, and so NATs can be readily traversed.
In order to provide a secure path for VoIP signalling applications it can be seen that ESP with authentication provides the required security and authentication combination. However, 3GPP have assumed this will operate in a NAT free network.
|
IPsec and VoIP
