Remove vulnerability from SIP-based VoIP networks--Part II

• Hop-by-hop
• End-to-middle
• End-to-end

Transport layer security (TLS) used to HTTPS can also be used to secure SIP (SIPS) on a hop-by-hop basis. Using the uniform resource indicator (URI), SIPS indicates that TLS must be used for every hop from end-to-end. Security mechanism agreements and requirements for end-to-middle security help to coordinate implementation efforts in reaching interoperability.

End-to-end security can be supported using secure/multipurpose Internet mail extensions (S/MIME). The media stream can be secured using Secure Real-time Transport Protocol (SRTP). Virtual private networking (VPN) protocols such as IPSec may also be used to encrypt all communications between trusted entities when no intermediaries are present.

Encryption schemes require that both participants know the set of encryption/decryption transformations. Only a key is needed to establish secure communications. The keys are exchanged by some secure means and are authenticated as genuine keys by binding the identity of the originating entity using a digital signature mechanism.

The primary exchange mechanisms are:

• Pre-shared keys (PSK)
• Public key infrastructure (PKI)

The key exchange mechanism has a profound effect on which mechanisms are practical for use in securing SIP-based VoIP. PSK is fast and simple, but it does not scale well for secure VoIP, as keys would have to be maintained for every possible caller. PKI, on the other hand, requires an elaborate distribution scheme and adds processing overheads.

Any encryption scheme always means additional data processing. This means that SIP devices would need better processing capabilities to be able to use encryption without significantly adding to the latency of the real-time communications. This leads to more costs as well as practical limitations, as many SIP-based VoIP devices are designed for handheld mobile use running on batteries.

Consider the data shown in Table 1.

And the data shown in Table 2.

Firewall and NAT Traversal
Firewalls and NATs are the fundamental building blocks of network security. They also pose the toughest challenges to VoIP traversal. Most firewalls use packet filters operating at the OSI IP layer. Modern firewalls also incorporate a relay mechanism or gateway in order to compensate for the effect of these filters on desired traffic.

NATs, on the other hand, hide internal (LAN) devices from the external network (WAN). Connections need to be initiated from inside the NAT. This causes a fundamental problem for VoIP, as no unsolicited incoming calls could be possible. In addition, SIP signaling messages carry IP address and port information of the VoIP device inside the NAT.

SIP devices outside the NAT relying on information contained in these SIP messages would be unable to reach SIP devices within the NAT. Some early SIP implementations got around this problem by ignoring the information contained in the message and relying on the underlying IP header or by probing an external host to determine the NAT mapping.

However, symmetric NAT does not lend itself easily to such solutions, as every connection to an external host uses a new mapping. As a result, special schemes need to be developed in order to address these traversal issues. The principal schemes of NAT traversal are listed as follows:

• Manual configuration with or without use of outbound proxy
• Application level gateways
• Symmetric SIP response [25] and symmetric RTP
• Simple traversal of UDP through NAT (STUN)
• Traversal using relay NAT (TURN)
• Interactive connectivity establishment (ICE)
• Session border controllers (SBC)