SolutionBase: Understanding networking options for Live Communication Server 2005

When you're getting ready to deploy Live Communications Server 2005, it's important to understand the different options you have in configuring servers. This article explains networking topology options available in LCS 2005.

Microsoft's Live Communication Server 2005 can play a great role in providing secure IM across the enterprise and between organizations. Microsoft has expanded LCS' features in the product's networking capabilities to make it easier to deploy LCS within an organization, as well as between business partners. In this article, I explore the networking topology options available in LCS 2005.

A look at server roles

The introduction of support for remote user access and federation (the capability for multiple organizations to participate in an LCS infrastructure) in LCS 2005 introduced some new deployment wrinkles. Both new features ultimately require access from the outside world to provide secure authentication. One alternative for remote users was to deploy a VPN solution, enabling the remote users to first establish a secure connection to the network where LCS was deployed. This solution naturally worked well where VPN was required for other reasons, but added an extra layer of complexity where LCS was the only reason for VPN.

A second, hardly workable, solution was to place user credentials in a perimeter network where they were accessible to the outside world. Exposing user credentials in this way, even when protected by a solid firewall, left an organization wide open to security hacks. To address these remote access requirements, Microsoft introduced two new server roles in LCS 2005--Access Proxy and Director.

An Access Proxy server sits in the perimeter network and serves to route incoming and outgoing SIP traffic. The server uses two network interfaces, one on the perimeter network and one on the internal LAN. The external interface listens for incoming SIP traffic and while it does not provide authentication, it does examine incoming message headers. Incoming requests that are valid for any of the internal LCS domains for which it is configured are forwarded to the next hop server through the internal interface.

The internal interface listens for outgoing SIP traffic. Again, the server analyzes the message headers to determine what action to take. Traffic for clients connected directly to the Access Proxy is sent to the remote clients. Traffic destined for a remote domain is routed to the target domain if that domain is listed on the server's partner list. Otherwise, the traffic is routed to the default domain, if defined. The server can also use a block list to identify domains whose traffic should be blocked, and when such a domain is detected in the message header, the traffic is dropped.

The other server role is Director. A Director server sits on the internal LAN but does not host users. Instead, it serves to authenticate users and route traffic to the appropriate LCS pool. An Access Proxy server communicates with a Director over a configured static route using Mutual Transport Layer Security (MTLS) to provide server-to-server authentication and end-to-end encryption between the servers.

Network topologies in LCS 2005

LCS 2005 supports four network topologies to provide connectivity between clients and LCS services. Each serves a particular connectivity need. These include

  • Remote User Access
  • Federation
  • Branch Office

Remote user access

LCS 2005 provides much better support for remote users that need access to the secure IM and presence information offered by LCS from the Internet. Although you can still use VPN as a means to give remote users access, the new server roles in LCS 2005 provide the framework for access without VPN. In this scenario, SIP traffic arrives from the client at an Access Proxy server located in the perimeter network, and is then passed into the LAN and to a Director server for processing. The internal LCS servers take care of authentication.

Direct federation

In LCS 2005, federation makes it possible to establish trust relationships between your network and one or more external networks, such as those of your business partners or subsidiaries. Federation enables users in disparate networks to initiate secure IM sessions and subscribe to presence information across network boundaries, including the Internet.

LCS 2005 supports two types of federation. The first is direct federation. With this topology model, two organizations establish a mutual trust. Each deploys at least one Access Proxy, one Director, and one backend server running LCS Standard Edition or Enterprise Edition. The two networks communicate over an encrypted MTLS connection. So, both servers must exchange valid certificates. Federation between two enterprise networks can rely on certificates issued by an enterprise certification authority (CA), such as a Windows 2000 Server or Windows Server 2003 computer running Certificate Services. Federation with a public network requires certificates issued by a public CA.

As an LCS administrator, you can control federation on a group or user basis. For example, you might allow federated access to one group that needs to use IM and presence information with a particular business partner, but deny it to others. You can also block federated partners from using IM or receiving presence information for specific local users.

LCS 2005 supports up to 300 direct federation associations, each requiring a separate peer link. Direct federation is therefore a good solution for a relatively small number of partnerships, but becomes more difficult to manage as the number of links increases. That's where clearing house federation comes into play.

Clearing house federation

In a clearing house federation topology, a single domain provides routing and authentication services for other domains. In effect, this central domain serves as an LCS clearing house for those domains. As a clearing house, the central domain exchanges traffic among the domains participating in the federation. Every organization in the federation controls how it uses the clearing house. For example, you could configure your domain to accept federation with all clients served by the clearing house, or allow access to some and deny access to others. You can use a combination of direct federation and clearing house federation arrangements to provide the structure you need for dealing with all of your business partners.

A variation on this topology is restricted clearing house federation. In this variation, the clearing house determines which members it will host. Each organization can still control how it uses the clearing house, however. For example, some organizations might use the clearing house for all LCS traffic, while others use a combination of the clearing house and direct federation with specific partners.

Branch office

This topology works much the same as remote user access, which I've already described. In a branch office topology scenario, each branch office uses the Internet as the connection to the main office. You deploy an Access Proxy server inside the branch office's perimeter network, and the proxy communicates with the Access Proxy server inside the home office's perimeter network.

SIP-PSTN gateway

The fourth topology supported by LCS 2005 expands on the SIP-PSTN gateway support in the previous version. LCS 2005 can serve PC-to-phone connectivity through its SIP-PSTN gateway. With LCS 2003, you could dedicate a standalone LCS server to function as the gateway for all calls. With LCS 2005, an LCS Standard Edition home server or an Enterprise server pool can serve as the gateway. The gateway needs to provide authentication services, so you can't use a server running in Access Proxy or Director server roles as the gateway.