Making a Secure Pass-Through for Video Conferencing Traffic

Video conferencing involves a mix of protocols, some of which speak across a group of well-defined network ports, and others of which can pick a port at random from a huge range. Unfortunately, security policy generally dictates that ports be blocked unless they can be associated with a specific application — huge ranges from which an address can be selected at random don’t fit that vision very well. Furthermore, network address translation (NAT) hides a lot of details about what is going on inside the firewall from things outside the firewall. What follows are some tips for allowing video conferencing sessions to flow securely in environments with firewalls and NAT devices.

1. Take the wall.

H.323 is the dominant standard for video conferencing. It uses several specific ports for control channels, using TCP ports 389, 1002, 1503, 1718–1720 and 1731. However, the standard allows the actual video and audio data, User Data Protocol (UDP) traffic rather than TCP, to use dynamically selected ports anywhere in the 1024–65535 range. (The call-control protocol H.245 also dynamically selects a port in that range.) Some manufacturers have smaller ranges they work with; for example, some Sony endpoints grab addresses only in the 41000–49200 range; even so, the range is still large.

The straightforward approach to resolving the problem is to simply open up all of the necessary ports on the firewall. On the plus side, this is easy, and any firewall can do it.  The drawback is that opening up a range this wide makes security folks crazy and seriously undercuts security. The narrower the opening, the better.

A more strategic approach includes using firewall features to snoop into the call set-up traffic to the extent needed to identify the dynamically selected ports that each call will use, and dynamically allowing that traffic to flow. This creates an ideal match of security and requirements. The hitch? Not all firewalls can do it.

The forward-looking and vendor-neutral approach is to work with H.460-enabled systems. The H.460 extensions to the H.323 standard were created to resolve security-device traversal problems for the H.323 traffic. Endpoints that can work with H.460 devices, combined with an H.460-compliant device to broker connections among them, make the associations needed to get both control and content traffic flowing properly.

Find out how firewalls are configured in the organization and whether they can perform conferencing-aware dynamic-range opening or are H.460 tolerant. Assess endpoints and UC systems for H.460 support as well.

2. Pick a NATural approach.

Extending conferencing’s reach to external users (whether staff or those from other companies), IT runs afoul not only of the address range issue but also of NAT. These devices present a small set (often just one) of IP addresses to the world, hiding all of the actual clients and servers that are on the inside of the network. This greatly reduces the “threat surface” of the organization by giving outside entities a very small area to probe for weaknesses. On the plus side, this makes opening the firewall easier, as you don’t have to open all the ports to every host on the network — just to the NAT device, since it channels all traffic to the right place. On the other hand, NAT easily breaks the use model for VPN-based internal users: internal endpoints — which VPN nodes are — want the real addresses, but those get lost in the NAT shuffle.

Here, too, the solution is to work with H.460-compliant systems. The standard solves the problems of NAT traversal by using an H.460 connection broker to circumvent the address-hiding nature of NAT for H.323 calls.

3. Ensure that UC teams think about security.

Unified communications staff must be mindful of how systems they propose to deploy, such as H.323-based video calling, will affect configuration of and load on security devices. Moreover, UC staff must fold security assessment and acceptance into acquisition criteria for new solutions and into solution engineering and deployment plans.

4. Ensure that security teams consider UC.

Security teams need to be aware that as the desire and need for video calling increases, a robust solution that works across any security perimeter devices needs to be put in place — one that neither breaks security nor the bank. Security folks need to be mindful that UC is required functionality and must not be broken by new devices, services or configurations.

5. Get both groups to work together.

This may sound obvious, but in our benchmark interviews with enterprise IT folks, we continue to hear this is a lesson yet to be learned in many an IT shop: UC and security teams must work together to discuss the UC and security deployment plans.
It’s not enough to be mindful of the implications; the teams need to work together on a continuing basis. UC features and requirements change regularly, and security threats and responses evolve constantly. An ongoing relationship with security is a simple necessity for UC staffs, and vice versa.