The Many Faces of Interactive Connectivity Establishment (ICE)

By J.D. Rosenberg



Without a doubt, one of the most challenging issues that VoIP system designers and network operators face is firewall and Network Address Translator (NAT) traversal. These days, almost every home with broadband Internet access has a NAT device — after all, NAT is the primary function of the broadband home router, the little magic that allows you to connect multiple computers to a single Internet connection. Most enterprises have one or more firewalls, and many smaller ones run NAT as well. Even some service providers use NAT; it is not uncommon for a cellular phone to have a private IP address. While NAT and firewalls are not a problem for traditional client-server protocols like those used for the web and e-mail, they are a huge problem for VoIP.

The industry has responded to this problem with many different solutions. These include Application Layer Gateways (ALGs), which add SIP awareness to NAT and firewalls, Simple Traversal of UDP Through NAT (STUN), which uses a “ping server” of sorts to allow low-cost traversal in consumer applications, and Session Border Controllers (SBCs), a close cousin to ALGs. SBCs have won the largest part of the market share of NAT and firewall traversal solutions. All of these techniques have their problems, and so the IETF worked steadily on producing a one-size-fits-all solution. That solution is called ICE: Interactive Connectivity Establishment.

ICE is a peer-to-peer cooperative NAT traversal solution, in which endpoints work with each other to discover paths through the network via a series of connectivity checks. This discovery is done in concert with network servers that help provide relaying and address translation functions. Work on ICE began in early 2003, and finally, a long four years later, it is now complete. ICE is extremely effective. It is robust, finding media paths even in the most complex network topologies. ICE makes sure that the called phone won’t ring unless a bidirectional media path is up and running. No more ghost rings and oneway audio that are common problems in VoIP. ICE is efficient, using relays and suboptimal paths only when absolutely necessary. It works across a broad range of environments without changes in configuration. It also provides lots of hooks for policy and allows for an evolutionary path from existing SBCs to ICE-based SBCs.


However, an interesting thing has begun to happen. ICE is also solving problems having little or nothing to do with firewall and NAT traversal. These include security, IPv6 transition, and dual-homing.

What does ICE have to do with security? Many VoIP systems today allow a malicious client to use the VoIP network to launch a denial-of-service (DoS) attack against a desired target. This attack, called the voice hammer, allows a single callsetup message to direct an 80 Kbps stream of packets (and possibly higher bandwidths) at a target device. This attack is easy to launch: An attacker sends a SIP INVITE message but lies about its media address, pointing to the target of the attack instead. Once the call is established, the called party will begin sending media toward the target. ICE prevents this attack. The called party won’t send any media at all until the ICE connectivity checks have taken place. Those checks happen along the media path, and in this case, they will fail since the target of the attack won’t respond to the checks. Consequently, no media is ever sent and the attack is prevented.

What does ICE have to do with IPv6 transition? One of the primary transition techniques is to use a dual-stack client, one that has both an IPv4 address and an IPv6 address. This introduces an interesting problem: When the dual-stack client makes a call, which address does it include in its INVITE as the target for media, IPv4 or IPv6? At the time it makes the call, it doesn’t know the capabilities of the called party, which could be IPv4 only, IPv6 only or dual stack. ICE has emerged as the solution to this problem. The caller includes both addresses, uses ICE’s connectivity checks to figure out which pairs work, and then uses them.

More generally, ICE helps dual-homed endpoints — those with more than one IP address. They are more common than you might think. My laptop has three IP addresses — one on the Wi-Fi network, one on the wired Ethernet, and one on my VPN. When I make a call from my softphone, which one should my laptop use? With ICE, my softphone would include all three, and then ICE would be used to dynamically figure out which one works. In fact, ICE can help me pick the one with the lowest latency, in order to optimize my experience in the call. ICE can also have configured policies to ensure only a specific address (such as my VPN), gets used.

These three applications are just the beginning. ICE can address other problems because it adds an important piece of functionality to SIP — exchange of messaging that follows the media path prior to call establishment and prior to the transmission of media. This small but important change will, I predict, make ICE a protocol for all seasons, not just the winter of NAT and firewall traversal. ICE is already considered one of the core SIP specifications by the IETF, and I anticipate we’ll see more and more reasons for this over time.


© yankandpaste® from : http://www.tmcnet.com/sip/0507/columns_speaking_sip_the_many_faces_of_ice.htm