The A/V Edge requirements for ports and protocol have changed in Microsoft Lync Server 2010. 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
  
  

For details about port configuration and network address translation (NAT) requirements, see Determining External A/V Firewall and Port Requirements in the Planning documentation.

Lync Server 2010 implements the Interactive Connectivity Establishment (ICE) protocol for negotiating media connections with parties inside a NAT environment. The specific implementation details are found in the Microsoft Office Protocols Documents at http://go.microsoft.com/fwlink/?LinkId=145173.

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 Lync 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.

TCP 50,000 outbound is used for Lync Server, including for application and desktop sharing, file transfer, and Windows Live Messenger 2011 point-to-point A/V functionality. UDP/TCP 50,000-59,999 port ranges are used for media sessions with Microsoft 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. For details, see Determining External A/V Firewall and Port Requirements in the Planning documentation.

In Lync Server 2010, an Edge Server is a single server running all three edge services, including Access Edge service, Web Conferencing Edge service, and A/V Edge service. Edge Servers that do 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 Edge Server.

If you use multiple Edge Servers behind a hardware load balancer, you must allocate a public address for the hardware load balancer virtual IP and the A/V Edge service. The public address must provide direct routable access for your clients that access the A/V Edge over the Internet. If you use multiple Edge Servers behind a DNS load balancer, you must allocate a public address for each external address.

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 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 external 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 is illustrated in the following figure.

The following sequence of events takes place when a external 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. Within the context of this authenticated, encrypted SIP session, the user obtains authentication credentials from the A/V Authentication service by sending a SIP SERVICE request to the service.
   
   
2. The external user authenticates itself with the A/V Edge service and obtains media session ports (Lync Server 2010 uses 3478/UDP and 443/TCP) on the server for use in the upcoming call. At this point, the external 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 external 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 external 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 (Lync Server 2010 uses 3478/UDP and 443/TCP) 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 external user of the port it has obtained on the A/V Edge service for media exchange.
   
   
5. The call setup is complete. Internal and external users begin to exchange media.
   
   

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

Security of end-to-end media

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 enhance the security of the media itself, Lync Server 2010 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.

---

Call sequence to enable media traversal of NATs and firewalls