The firewall Dilemma

For as log as there has been networked video conferencing systems there has been a problem with Network Address Translation (NAT). NAT is how home routers or companies share a single IP address. Early video conferencing systems used multiple 64K channels that were setup in advance or by dialing a series of phone numbers so NAT was not a problem.

Once video systems became Ethernet connected the protocols that were used to establish calls started to get in the road. For the longest time the only protocol being used was a not so standard, standard called H.323. In order for vendors to claim they had an edge over their competition, there was no motivation to perform inter-op testing. Customers were forced to select and stick with one vendor in order to get a solution that worked.

Early CODEC’s were H.261 and H.263, which did a reasonable job of encoding video but were more demanding on network bandwidth. The emergence of H.264 and the eventual formation of organizations to insure H.323 inter-op brought the industry together but not until the turn of the century. H.323 is actually a wrapper protocol around sub protocols like H.261, H.263, X.245 and Q.931. Without getting into too much detail, the problem with firewall traversal is that sub-protocols use the system’s network addresses to setup media channels (Audio and Video). NAT gateways are not smart enough to find and translate all the addresses. If addresses are not translated then media channels cannot be connected and calls end up with one way audio or video.

As long as systems are configured with real routable IP addresses everything works. Many companies use real IP addresses to avoid both firewall traversal issues and to keep video off internal networks. This keeps both the security and network planners happy. Other companies purchase firewall traversal systems like H.323 Gatekeepers. GNUGK is an example of a free open source H.323 Gatekeeper.

The H.323 protocol is slowly being replaced by a much simpler protocol call Session Initiation Protocol (SIP). SIP suffers from the same firewall/NAT traversal issues. The creators of the SIP proposed additional protocols like STUN, ICE and TURN as solutions for NAT traversal, but many companies have opted for a Session Boarder Controller (SBC). The SBC functions in much the same way as an H.323 Gatekeeper. In some cases it handles both SIP and H.323.

Convincing network security people that a product is secure enough to be connected between the big bad Internet and their private network has proven to be a real challenge. I have been working my way through a book called “Counter hack reloaded” by Ed Skoudis and Tom Liston and I’d say they are wise to be concerned. The bad guys are really creative.

Concerns for network security have caused yet another evolution.

The latest solution for the age-old NAT traversal problem involves placing the traversal device in “The Cloud”. If vendors equip video devices with security keys and certificates, the video systems can establish a VPN tunnel to the cloud based gateway and use its external address as their own. The data between the devices is encrypted and only one outbound port needs to be open on the firewall.

This approach has several benefits in that it allows service providers to essentially lock video terminals in much the same way cell phones are locked to their carrier. This enables a service that creates a re-occurring revenue stream.

Carriers can do their usual amortization of the equipment cost lowering the cost centric barriers to entry for smaller enterprises. It’s only a matter of time before you will be able to go into your local service provider’s retail store and bring home a visual communication device.

This entry was posted in Network Tools and Debugging and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *