The A/V Edge requirements for ports and protocol have changed in Office Communications Server 2007 R2. Depending upon your requirements for federation with partner infrastructures and the configuration of your Edge Servers, the following ports should be considered:

• UDP 3478
  
  
• TCP 443
  
  
• UDP 50,000–59,999
  
  
• TCP 50,000–59,999
  
  

Office Communications Server 2007 R2 implements a more recent version of the Interactive Connectivity Establishment (ICE) protocol for negotiating media connections with parties inside a network address translation (NAT) environment. The specific implementation details are found in the Microsoft Office Protocols Documents at http://go.microsoft.com/fwlink/?LinkId=145173 . Because of the new ICE specifications, the port requirements for Office Communications Server 2007 R2 Audio/Video Edge service have changed. For details about the implementation of ICE in Office Communications Server 2007 R2, see the Additional Resources section at the end of this document.

The A/V Edge service is an enterprise managed resource, so restricting access to authorized users is important for security and resource considerations.

The UDP 3478 and TCP 443 ports are used by clients to request service from the A/V Edge service. A client uses these two ports to allocate UDP and TCP ports respectively for the remote party to connect to. To access the A/V Edge service, the client must first have established an authenticated SIP signaling session Communicator or Meeting Console registration to obtain A/V Edge service authentication credentials. These values are sent across the TLS-protected signaling channel and are computer generated to mitigate against dictionary attacks. Clients can then use these credentials for digest authentication with the A/V Edge service to allocate ports for use in a media session. An initial allocate request is sent from the client and responded with a 401 nonce/challenge message from the A/V Edge service. The client sends a second allocate containing the user name and a (Hash Message Authentication Code (HMAC) hash of the user name and nonce. A sequence number mechanism is also in place to prevent replay attacks. The server calculates the expected HMAC based on its own knowledge of the user name and password and if the HMAC values match, the allocate procedure is carried out. Otherwise, the packet is dropped. This same HMAC mechanism is also applied to subsequent messages within this call session. The lifetime of this user name/password value is a maximum of eight hours at which time the client reacquires a new user name/password for subsequent calls.

These port ranges are used for federated media sessions with Office Communications Server 2007 partners that require NAT/firewall traversal service from the A/V Edge service. Because the A/V Edge service is the sole process using these ports, the size of the port range does not indicate the potential surface of attack. Good security practice is to always minimize the total number of listening ports by not running unnecessary network services. If a network service is not running, it is not exploitable by a remote attacker and the surface of attack of the host computer is reduced. However, within a single service, reducing the number of ports does not provide the same benefit. The A/V Edge service software is no more exposed to attack with 10,000 ports open as it is with 10. The allocation of ports within this range is done randomly and ports not currently allocated do not listen for packets.

In Office Communications Server 2007 R2, a single consolidated edge server that does not use a load balancer can use NAT for all three service roles. This means that you do not need to provide a publicly routable IP address to the actual server, and you can use your perimeter address range. However, NAT is not supported for the internal edge of the consolidated Edge Server.

When using multiple Edge Servers behind a hardware load balancer, it is required that a public address be allocated for the hardware load balancer virtual IP and the A/V Edge service. It must provide direct routable access for your clients accessing the A/V Edge over the Internet.

This is required because addressing for a media session occurs at the IP address layer, where the presence of a NAT function can break end-to-end connectivity. For an edge server, a NAT provides only address translation; it does not provide any security through routing policy rule enforcement or packet inspection. The only potential benefit a NAT offers is to obfuscate the IP address of the server, but attempting to hide the IP address of any network server is not a reliable way to provide security. All edge servers need to be secured by the use of a properly associated firewall policy to restrict client access to the designated listening ports and by disabling any other unnecessary network services. Given compliance with these recommended practices, there is no additional benefit from the presence of a NAT.

Enabling remote users and internal users to exchange media requires an Access Edge service to handle the SIP signaling that is necessary to set up and tear down a session. It also requires an A/V Edge service to act as a relay for the transfer of the media. The call sequence, illustrated in Figure 1, is as follows.

Figure 1. Call sequence to enable media traversal of NATs and firewalls

The following sequence of events takes place when a remote user calls internal users and therefore needs to be able to send voice, VoIP, or both by means of the A/V Edge Server:

1. The remote user establishes an authenticated SIP session by having the user sign in to Office Communications Server. Within the context of this authenticated, encrypted SIP session, the user can obtain authentication credentials from the A/V Authentication service.
   
   
2. The remote user authenticates itself with the A/V Edge service and obtains media session ports (Office Communications Server 2007 R2 uses 3478/UDP) on the server for use in the upcoming call. At this point, the remote user can send packets by way of the allocated port on the public IP address of the A/V Edge service, but still cannot send media packets inside the enterprise.
   
   
3. The remote user calls the internal user by way of the SIP signaling channel provided by the Access Edge service. As part of the call setup, the internal user is informed about the port on the A/V Edge service that the remote user has available to exchange media.
   
   
4. The internal user contacts the A/V Edge service on its private IP address to be authenticated to receive media. The internal user is also allocated a port on the A/V Edge service public address (Office Communications Server 2007 R2 uses 3478/UDP) for use in the media session. After receiving the port, the internal user, again by way of the Access Edge service, answers the call and thus informs the remote user of the port it has obtained on the A/V Edge service for media exchange.
   
   

The call setup is complete. Internal and external users begin to exchange media.

In summary, to send media into the enterprise, the remote user must be authenticated and have an authenticated internal user explicitly agree to exchange media streams. Office Communications Server 2007 R2 federating with Office Communications Server 2007 continues to use the port range of 50,000 – 59,999 UDP/TCP. Federation involving two Office Communications Server 2007 R2 partners will use 3478/UDP.

The signaling channel used to negotiate a media session is protected using 128-bit TLS encryption with validation that the server certificate has a matching FQDN and trusted authority. This mechanism is very similar to the one that e-commerce sites use for online transactions. To secure the media itself, Office Communications Server implements the IETF’s SRTP protocol. The mechanism uses a 128-bit key exchange over the secure signaling channel, which the two endpoints then use to encrypt and decrypt the media stream using 128-bit Advanced Encryption Standard (AES) encryption. This ensures that even if an attacker can perform a man-in-the-middle attack of the media path, the attacker is not able to eavesdrop on the conversation or inject additional media packets. In the latter case, the client simply drops the packets.