White Paper - IPsec in VoIP Networks
TISPAN Security
In a mobile 3GPP SIP-based network IPsec presents no problem because there are no NAPT devices between the phone and the IMS core. Similarly, using IPsec ESP in tunnel mode to interconnect networks is unlikely to have to traverse NAPTs. However, to secure the signalling from phone to server in a broadband or Internet based network an alternative solution must be used.
TISPAN has recognised that NAT traversal is not possible with the IMS security solutions in TS 33.203 releases 5 and 6. It has agreed to use UDP encapsulated IPsec according to RFC 3948. TS 33.203 defines a security negotiation mechanism (RFC 3329) which includes a Mode parameter, TISPAN has extended the parameters to include "UDP-enc-tun". The encapsulation occurs in two stages: the original clear SIP/UDP message is encapsulated using IPsec ESP, then this encapsulated in another UDP header. The message is sent from port 4500 to port 4500. The intermediate NAPT device can change the source IP and port numbers without affecting the IPsec payload. De-encapsulation is the reverse process.
Conclusion
As NAPT devices are a fact of life for most broadband, WiFi and WiMax networks and IPsec is incompatible with NAPT it has been necessary for TISPAN to extend the 3GPP security mechanisms to deliver SIP signalling over IPsec. The ability to negotiate a secure signalling connection with the IMS will reduce service theft (toll fraud), increase privacy and will build consumer confidence in the next generation of multimedia service. TISPAN's extension of the 3GPP security framework to include UDP encapsulated IPsec means that any number of intermediate NAT or NAPT devices can be traversed. The NAT devices have access to the encapsulating UDP port numbers and can perform address and port translation in the normal way. The use of a common standard for the negotiation and delivery of a secure signalling path will greatly improve device interoperability.
Since this is an extension of the existing IMS security framework it means that other mechanisms such as key exchange remain unchanged.
There are other advantages in using IPsec as opposed to the alternative which was under consideration – TLS. TLS sits above the transport layer so port numbers are still visible to intermediate NAPTs. However, typically only the server is authenticated, and the client remains unauthenticated. TLS demands the use of TCP, whereas IPsec can use either UDP or TCP. The use of TCP in large scale deployments raises concerns about the overhead of maintaining a large number of connections with numerous UAs. Thus, TCP is not well liked by service providers since the overheads associated with its mass use are significant compared to UDP.
TISPAN's extension to the IMS security framework to include UPD encapsulated IPsec delivers the capability of delivering secure VoIP signalling whilst maintaining the ability to traverse intermediate NAPT devices. ■
References
RFC 4301: Security Architecture for the Internet Protocol: (obsoletes RFC 2401)
RFC 4302: IP Authentication Header: (obsoletes RFC 2402)
RFC 4303: IP Encapsulating Security Payload (ESP): (obsoletes RFC 2406)
RFC 3261: SIP: Session Initiation Protocol
RFC 3948: UDP Encapsulation of IPsec ESP Packets
RFC 3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP)
ETSI TS 133 203 Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); 3G security; Access security for IP-based services
ETSI TS 133 210 Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); 3G security; Network Domain Security (NDS); IP network layer security
|
IPsec and VoIP
