IP Security for Local Communication Systems

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Joanie Rhine

Microsoft Solutions Framework

Best Practices for Enterprise Security

Note: This white paper is one of a series. Best Practices for Enterprise Security ( https://www.microsoft.com/technet/archive/security/bestprac/bpent/bpentsec.mspx ) contains a complete list of all the articles in this series. See also the Security Entities Building Block Architecture ( https://www.microsoft.com/technet/archive/security/bestprac/bpent/sec2/secentbb.mspx ).

On This Page

The Focus of This Paper
Security Risks
Customer Profile
The Business Case for IP Security
IPSec Overview
Implementing IPSec Policy in Windows 2000
Conclusion
References

The Focus of This Paper

The MSF white paper Data Security and Data Availability for End Systems outlines a number of security threats to IP networks. The violations range from sniffing and other passive attacks to more malicious and involved attacks like identity spoofing and denial of services. A 1999 CSI/FBI Computer Crime and Security Survey estimated that unauthorized access and theft of proprietary information cost an average of $4,486,000 per year. The study also determined that 70% of unauthorized access is done from inside a company. It's important not to underestimate the enemy inside. While these attacks are not necessarily due to hackers' activity or disgruntled employees, it is certain that loss of information may be due to accidents or errors. Nevertheless, protecting information from inside and using multiple security mechanisms is the base of defense in depth.

Security Risks

In attempting to secure a customer environment, it is important to consider things like physical security, firewalls, and strong passwords. However, this approach does little to protect against attacks from inside the company. While data may be protected when stored in a database or on disk, many applications transmit data and passwords in plaintext—strong perimeter security does nothing to prevent a valid internal user from capturing data and password information as it is transmitted over the wire. So the question for us becomes, "How do we provide security in the form of nonrepudiation, integrity, authenticity of information, and confidentiality?"

Additionally, many customers today are leveraging the power of the Internet for connectivity. Using tunneling protocols, a remote user or separate networks can connect to a local ISP and use the connection to the Internet to gain access to another network. This approach uses the existing IP network as the medium for remote access. This enables a company to avoid costly point-to-point links and dedicated WAN technologies. Traditionally, remote access over dial-up lines has not been a significant security concern because the connection that was established was point-to-point using ordinary phone lines. A user (or router) dialed a phone number directly attached to the remote access device. A malicious act required some mechanism for accessing the data itself as it traveled over the phone lines. It was assumed that since these remote access connections were made over a company's telephone network, snooping the data would be much more difficult. Interestingly, a point-to-point dial-up connection possesses no more inherent security than the Internet, but there is a greatly reduced potential for the public at large finding a means to eavesdrop on the conversation across dial-up links. This is due mainly to the design, including the locality of the equipment and the lack of accessibility to the components involved. Take a dial-up connection between a client in Los Angeles and a server in Seattle. A malicious user would have no mechanism for gaining access to the wires and switches if they themselves were in Florida. However, on the Internet, eavesdropping can be far more easily achieved because the knowledge of the components is more common and access to those components can be gained regardless of distance. So, in order for a customer to benefit from the cost effectiveness and convenience of tunneling through the Internet, technologies need to be available and implemented that protect against these risks.

Customer Profile

Our customer is a large financial services institution (known from this point forward as the Bank) with approximately 5,000 users. Most of the users, approximately 3,500, are located at the corporate headquarters in San Francisco. The other 1,500 are dispersed among ten branch offices throughout the United States. The Bank has recently completed a domain migration to Microsoft Windows 2000 and has implemented a single domain forest Active Directory™ directory service architecture. The migration of all client computers from Windows NT 4.0 will be completed within the next two months.

Each of the branch offices is defined as an Active Directory site and has a minimum of two domain controllers, one of which is acting as a global catalog server. The corporate headquarters in San Francisco is home to several file and print servers, as well as numerous line-of-business applications. Most of the branch offices access the data in the corporate headquarters frequently throughout the day. All of the branch offices, except for Reno and Orlando, have dedicated WAN links of at least 256 kilobits per second (kbps) for connectivity to corporate headquarters. Prior to the upgrade to Windows 2000, Reno and Orlando were connecting to headquarters via a router-to-router Virtual Private Network (VPN) connection using Point-to-Point Tunneling Protocol (PPTP). They are now interested in examining the advantages and disadvantages of using Level 2 Tunneling Protocol (L2TP) and Internet Protocol Security (IPSec).

The Bank has two primary objectives related to data security and availability.

• Protect confidential financial data that is maintained in a SQL database and updated frequently by authorized individuals over the network. This includes sensitive financial information for several large customers and information about mergers and acquisitions.

• Use L2TP/IPSec to connect the Reno and Orlando branch offices to corporate headquarters.

The goal in this paper is to provide a framework for the Bank to ensure that data, as it is transmitted over the corporate network or across the Internet, is authentic, unaltered, and confidential.

The Business Case for IP Security

IP Security (IPSec) provides a model for securing data as it's transmitted across a network. IPSec is an Internet Engineering Task Force (IETF) standard defined in Requests for Comments (RFCs) 2401–2411. For the first time the IP protocol (or the network layer) is modified to provide security. IPSec provides authentication, integrity, and, optionally, confidentiality. The sending computer secures the data prior to transmission and the receiving computer decodes the data after it has been received. Based on cryptographic keys, IPSec can be used to secure computers, sites, domains, application communication, dial-up users, and extranet communication. As part of a comprehensive security plan using stringent controls and perimeter security, IPSec ensures protection of your transmitted data. It will not secure the data while it is stored on disk. In the following sections, we will examine the specific details of IPSec, including how it works and the protocols and standards support as well as look at how the Bank chose to implement IP Security as part of their security model.

Network security is a broad and oftentimes ambiguous term. Are we talking about physical restrictions on what traffic is allowed and disallowed? Is it ensuring the authenticity of data that is sent, like a signature on a letter? Or, perhaps, is it the ability to trust that the data that is received has not been altered and remains immune to eavesdropping. In reality, all of these are aspects of network security. IPSec addresses three primary concerns with transmitting data over the wire:

• Authenticity and nonrepudiation

• Integrity

• Confidentiality

Data traveling by way of IP has no inherent security. As discussed earlier, it is fairly simple to intercept IP traffic, forge IP addresses, and perform any number of other unscrupulous acts. There are no assurances that packets received are from the claimed sender or that the data has remained unaltered in transit.

Today's enterprise environments need a secure method by which data can be sent over both corporate networks and the Internet. IPSec as well as additional technologies like L2TP can provide this functionality. Given this, one might ask, "So why not just secure everything?" Unfortunately, things are never that simple. Issues like interoperability, performance implications, and simplicity all need to be examined to successfully determine an IPSec plan. In order to successfully examine these questions and understand the business advantages provided by IPSec, it is first necessary gain a preliminary understand of the technology.

IPSec Overview

As the name implies, IPSec provides security for IP datagrams. Based on the assumption that most networks are not secure, and thus require additional components to protect data as it travels over the wire, IPSec provides source authentication, integrity checking, and content confidentiality.

Securing data is nothing new; there are many different ways to provide that security. Some applications provide security services at the application layer including Secure Sockets Layer (SSL) or Transport Layer Security (TLS). In the case of these protocols, the application makes calls to the underlying security provider to provide these services. Even though most of the implementation details can be abstracted (for example, in Windows 2000, the Security Support Provider Interface, or SSPI, provides a common interface for applications to access underlying security components) the application needs to at minimum be "security aware." IPSec eliminates this requirement by moving security down to the network layer. This allows applications to remain independent of the underlying security infrastructure. IP datagrams are protected regardless of the application that initially generated the traffic. In other words, applications are not IPSec-aware. The security rules are defined by the administrator regardless of the application running; IPSec is transparent to applications. The implications of this are tremendous—IPSec provides the ability to authenticate, secure, and optionally encrypt any data traveling over any IP network, including the Internet. IPSec provides end-to-end security between computers and networks.

How IPSec Works

IPSec provides security of IP datagrams. It is end to end, implying that only the sender and the recipient need to be aware of the details concerning security. Devices in between the two parties do not need to worry about encryption, secret keys, and so on, in order to forward the data along. This is significant to a customer like the Bank for two reasons. First, the wire over which the data is traveling may be insecure. This means that in most cases, the underlying network infrastructure does not need to be modified. Second, implementation is relatively simple. Only the hosts that need to communicate need to understand IPSec. Intermediary devices like routers need not be IPSec-aware. For customers this means that a high level of security can be implemented without enormous cost or a significant change to their network infrastructure. It is, however, important to note that firewalls and other devices that block specific types of traffic need special consideration and will be discussed later.

The Windows 2000 implementation of IPSec is based on industry standards defined by the IETF IPSec working group. IPSec works by identifying traffic that needs to be secured and then applying the defined level of security. So, for example, the Bank could identify traffic that meets certain criteria such as source IP address or host name, and choose an appropriate level of security based on that identification.

Using IPSec, data can be secured between specific hosts, network routers, or firewalls or between hosts and routers or firewalls. Using industry standard authentication and encryption algorithms, IPSec leverages existing technologies and provides a comprehensive approach to safeguarding network traffic. The protection of IP datagrams is provided by two protocols, Authentication Header (AH) and Encapsulating Security Payload (ESP). AH is used to guarantee data integrity, provide antireplay protection, and ensure host authentication. ESP provides similar functionality to AH; however, ESP also includes optional data confidentiality. It is important to note that neither AH nor ESP provides the actual cryptographic algorithms to implement the features above, but instead AH and ESP leverage existing cryptographic and authentication algorithms.

There are four main components to IPSec in Windows 2000:

• IPSec protocols

• Security associations

• Security policy

• IPSec driver

IPSec Protocols

Two protocols, AH and ESP, work to provide authentication, integrity, and confidentiality. These protocols can be configured to protect the entire IP payload, or just the upper-layer protocols of the IP payload. Using the protocols separately, or in combination, the Bank can achieve simple authentication and integrity checking, as well as encryption of the data as it travels over the wire.

Authenticating Header

AH, as defined by RFC 2402, provides integrity of transmitted data through keyed hashing. Currently supported hashing algorithms include HMAC MD5 and HMAC SHA. (HMAC or Hashed Message Authentication Code is a secret key algorithm that creates a digital signature of the data that can be verified by the recipient. MD5 results in a 128-bit value, while SHA results in a 160-bit value. SHA is typically more secure, but not as fast as MD5.) Note that AH hashes the IP header and payload, but does not include portions of the datagram that are presumed to change, such as the hop count. Because both the header and payload are hashed, AH can verify addressing information and guarantee that the IP data has not been tampered with.

Antireplay services are also a function of AH. Serially increasing sequence numbers and a sliding receive window provide antireplay assurances for both AH and ESP.

AH does not provide confidentiality in the form of data encryption—that is a function of ESP.

Encapsulating Security Payload

ESP is an Internet protocol defined in RFC 2406. Used alone or in combination with AH, ESP provides data integrity and encryption. Encryption algorithms supported by ESP include DES-CBC, 56-bit DES, and 3DES. ESP also provides integrity checking using HMAC MD5 and HMAC SHA. Antireplay services are implemented in the same manner as AH.

Note that the authentication, integrity, and encryption algorithms are determined as part of the security negotiation between the endpoints for IPSec communication. This process is referred to as a security association and will be discussed in the following sections.

Both protocols can be used in two different modes, referred to as transport and tunnel modes. The underlying operations of AH and ESP do not change based on the mode of operations—the only thing that changes is that data is signed for integrity purposes. Transport mode is used to protect packets where the endpoint for communications is also the cryptographic endpoint. In tunnel mode, the cryptographic endpoint is a security gateway providing security on behalf of another network. In this case, the IPSec packet is authenticated, verified, and possibly decrypted prior to being forwarded to the communications endpoint. Tunnel mode could be used in a scenario to create a router-to-router VPN. (For more information on VPNs and routing, see Chapter 9, "Virtual Private Networking," in the Windows 2000 Server Resource Kit Internetworking Guide.) In transport mode, a header is placed between the IP portion of the datagram and the upper layer headers, while in tunnel mode, the entire IP packet is encapsulated in another IP datagram and an IPSec header is placed between the two IP headers.

It is important to note that although IPSec in tunnel mode can be used alone to support remote access, the work toward a pure IPSec VPN is still in progress. The most significant issues currently are interoperability with different vendor implementations, and the inability to tunnel multicast and broadcast traffic. The latter hinders the ability to create router-to-router VPN connections using IPSec tunnel mode. The solution for now is to use L2TP/IPSec for tunneling remote access connections. The implementation of L2TP and IPSec will be discussed later.

Because of the way that IPSec is implemented in Windows 2000, the Bank may opt to apply different levels of IPSec in areas with specific requirements. This provides the flexibility to define areas requiring low, medium, and high security and apply IPSec accordingly. For example, the Bank may have determined that authentication and integrity are required in all areas, but that confidentiality is only necessary in certain high security environments. In this case, the application would be as follows:

• For areas requiring confidentiality, both ESP and AH are required. Be aware that encryption of data is computationally expensive. This should be a consideration in all plans to use the encryption features of ESP.

• For areas not requiring confidentiality, AH is sufficient to provide authentication and integrity.

Security Associations

Before two hosts can communicate using IPSec, they must first establish the guidelines for that session (for example, the authentication method and the encryption algorithm). Consider the security association (SA) as the agreement between the two parties regarding the specific security settings to employ. For example, if Host A wants to communicate with Host B, they must agree on certain security settings. Will they use AH or ESP for integrity, Kerberos or certificates for authentication, and so on.

Security associations are unidirectional, meaning that separate SAs must be established to define the security parameters for incoming and outgoing traffic. In addition, multiple associations will exist if a host is communicating with one or more IPSec hosts simultaneously. Security associations are stored in a database on each IPSec computer. Within the database, each SA is identified by a Security Parameter Index (SPI) that is included in every AH or ESP header. The recipient uses this SPI to decide what SA to use to process incoming packets.

The IETF has defined the framework for the establishment of security associations for the associated key exchange. Internet Key Exchange (IKE) manages the creation of security associations and generates the keys used to secure the information. IKE uses Diffie-Hellman to generate and manage keys. The Diffie-Hellman technique provides the ability to generate the symmetric keys that will be used by both parties to encrypt and decrypt the data. Symmetric cryptography requires a secure channel to exchange the keys, and IKE provides this channel.

Note: If a security association cannot be established, the IPSec policy can be configured to either block communications or send data without requiring the negotiation of the SA.

Security Policy

The basis of IP security is to identify specific types of traffic and to make sure that traffic is secure. Our Bank would like to secure traffic between branch offices and the corporate network over a VPN connection. Secure in the context of IPSec could mean authenticated, unmodified, and possibly encrypted. Determining what traffic to secure and the level of security to be implemented is defined in the security policy. Windows 2000 provides policy-based administration in which IPSec policies can be associated with computers, sites, domains, or organizational units. Policies should be defined based on the required or desired security of the organization.

The implementation of IPSec policy is controlled through the use of rules. Rules govern how and when IPSec policy is invoked based on source, destination, and type of IP traffic. Rules contain filters that allow for identifying a specific type of traffic and applying security actions when a match occurs. For more information about creating and applying IPSec Policy, see "Implementing IPSec Policy in Windows 2000" later in this paper.

The following are the properties of a rule:

• IP Filter List defines which traffic will be secured with this rule.

• Filter Action lists security actions that will take place upon an IP filter list match.

• Authentication Methods specifies whether to use Kerberos, certificates or shared secrets to authenticate each computer.

• Tunnel Settings specifies if the rule applies to a tunnel.

• Connection Type allows the administrator to specify what connections this rule applies to. The three choices are All network connections, LAN, or Remote access.

  All network connections requires the examination of all traffic (incoming or outgoing) by the host that the policy is applied to. For example, setting this policy on a SQL server that maintains a financial database means that all connections to and from the server requires examination to determine specific security actions to take.

  LAN requires all LAN traffic to this host be examined.

  Finally, Remote access examines all communications with the server over remote access connections.

Windows 2000 automatically contains a default response rule. This ensures that the computer will respond for requests for secure communications even if a rule is not defined for a computer requesting security communications. For example, if host B is requesting secure communications from Host A, but Host A does not have an inbound filter defined for Host B, the default response rule will be invoked and security will be negotiated between Host A and Host B. The rule is designated for all defined policies, but does not have to be active.

IPSec Driver

The IPSec driver is loaded at startup if an IP policy has been defined. It is responsible for monitoring all IP traffic and securing packets based on the requirements of the IPSec policy. The IPSec driver is responsible for:

• Reviewing each IP packet that comes in or goes out for a match to a specific IP policy filter.

• Requesting security associations for new connections.

• Implementing policy that specifies a method of authentication (Kerberos or certificates, for example).

• Updating and deleting security associations.

Process Overview

The IP security process is as follows:

• An IP packet matches an IP filter that is part of an IP security policy. For example, an outbound filter specifies all TCP traffic directed at port 23 (telnet) should be secured.

• IKE negotiates a security association that is stored in its database.

• As outgoing packets are received by the IPSec driver, the defined security methods are applied.

Note: For more information on the components of IPSec, see Chapter 8, "Internet Protocol Security," in the Windows 2000 Server Resource Kit TCP/IP Core Networking Guide.

Business Requirements

Now that we understand the basics of IPSec, we can evaluate it as a solution for the Bank. This will need to include an examination of the customer's current environment and the specific issues of interoperability, performance, and integration of the technologies into the existing infrastructure. With this, we can determine how IPSec can provide the desired security solutions.

In addition, once the advantages have been established, it is necessary to look at the business requirements—what areas need to be secured, and what level of security is required.

As we discussed earlier, the Bank has several security requirements. The first requirement of the Bank is to guarantee that sensitive information accessed on specific servers and updated over the network be authentic, not subject to repudiation, and confidential. This includes the ability to authenticate the source and destination hosts, guarantee the integrity of the data that is transmitted, and provide encryption services.

Second, there are the branch offices in Reno and Orlando that connect to the corporate headquarters via the Internet. This enables the Bank to provide widespread connectivity between branch offices without having to provide point-to-point links between each branch and the corporate headquarters. All that is required on both ends is a connection to the Internet and the local network. However, the Internet is a public network that provides little inherent security. How can the Bank leverage the convenience of using the Internet to connect remote sites with the corporate headquarters, while maintaining the highest levels of security?

Both of these requirements can be met using the technologies provided by IPSec and Windows 2000. In the next section, we will examine how the Bank can use IPSec and Windows 2000 to meet these goals.

Implementing IPSec Policy in Windows 2000

In general, IPSec policies can be implemented to meet the security requirements of the computer, domain, or organizational unit. Determining the security requirements of the Bank will enable us to understand at what level to apply IPSec policy. The scenario that we have identified for the Bank is the desire to authenticate all hosts communicating with the secure servers housing the financial data at corporate headquarters. This data resides on physically secure servers that have been assigned static IP addresses. A public key infrastructure (PKI) has already been implemented internally for intranet communications, so the Bank would like to provide IPSec host authentication using x.509 certificates. This data also needs to be secured using the encryption services provided by IPSec. Since all the Banks communications are within the boundaries of the United States, 3DES encryption provides the strongest algorithms. Additionally, remember the branch offices in Reno and Orlando? They are currently using router-to-router VPN connections to headquarters using PPTP. Based on the inherent security risks of using a public network like the Internet as the backbone for this connectivity, and the inability of PPTP to provide host authentication, the Bank has chosen to implement Layer 2 Tunneling Protocol (L2TP) with IPSec for authentication, integrity, and confidentiality. We will discuss the specific details and advantages of L2TP in a later section.

At this point, we have identified the needs of the Bank and are ready to implement. Windows 2000 provides the interface to create and manage IPSec implementation locally or as part of Group Policy implementation in Active Directory.

Predefined Policies

By default, Windows 2000 includes three predefined policies: Client, Secure Server, and Server. Our first task for the Bank is to determine if any of the default policies will apply or if it will be necessary to create a custom policy to meet their needs. None of the preconfigured policies are active by default. The policies are as follows:

• Client (Respond Only) allows the client to respond to other computers requesting security according to the settings in the default response rule. With this policy active, the client will never request security, but will negotiate IPSec based on the connecting host. This would allow the Bank to configure client computers to respond to requests for secure communications, but without initiating the request.

• Secure Server (Require Security) allows the server to require IPSec negotiation prior to allowing a connection. This policy will allow unsecured incoming communications, but outgoing traffic will always be secured. This policy could be implemented by the Bank in scenarios where data must always be secured.

• Server (Request Security) allows the server to request IPSec negotiation, but will allow unsecured communications if the other computer is not IPSec aware. The Bank could use this policy to implement security between IPSec enabled computers without sacrificing interoperability with non-IPSec-enabled computers.

To view local IPSec policies

Open the Microsoft Management Console and add the IP Security Policy Management snap-in:

1. Click Start, click Run, type MMC, and then click OK.

2. In MMC, click Console, click Add/Remove Snap-in, and then click Add.

3. Click IP Security Policy Management, and then click Add.

In most instances, the default policies will provide the required security. However, you can customize the policies, or create new policies, to meet additional security concerns.

Using IPSec Policy at the Bank

It is clear at this point that the Bank has certain security requirements that can be supported through IPSec and associated technologies. However, developing an IPSec implementation strategy involves more than the technologies themselves. Before deploying IPSec, the architect also needs to consider the features that are desired as well as the time, effort, and costs involved in making the technology a success for the customer. Additional questions to consider:

• What will be the impact on performance? Implementing IPSec will increase processor utilization, increase IP traffic, and increase IP packet size.

• What effect will this have on the existing network? For the Bank, the additional processing power on the few machines that will actually be using IPSec and the load on the network were outweighed by the security concerns. That is not to say this is the case in every environment. Careful consideration of all the facts is required for a successful implementation. If performance does become an issue, dedicated network cards may be an appropriate solution.1

Creating Policy for the Domain

So here we are: we have evaluated the business needs of the Bank and identified the relevant technologies, and now we are ready to implement. The Bank wants to ensure that all traffic between secure servers hosting confidential information and hosts accessing that data is guaranteed to be authentic, unmodified, and encrypted. The authentication will leverage an existing PKI using x.509 certificates. Integrity checking will be provided using HMAC-MD5, and data encryption will be implemented using 3DES. This can be done using the Group Policy feature of Windows 2000 to disseminate the IPSec rule. Recall that IPSec policy can be implemented at the local computer, domain, or organizational unit level. Since the policy being implemented for the Bank only applies to a handful of servers, it is wise to place those servers in an organizational unit. Then, policy can be applied to the organizational unit, and servers will have the policy applied by virtue of residing in the particular organizational unit. This will eliminate unnecessary processing on all other client computers.

There is one additional element to be considered—the client computers. By default, no IPSec policies are applied to hosts in a Windows 2000 environment. However, in order for clients to respond appropriately when security is requested by the secure servers, we must apply a policy that provides those instructions. The host computers need to be able to respond to authentication requests using certificates and to negotiate the desired encryption. This can be accomplished by modifying the default domain policy to support certificates and assigning the client policy at the domain level.

Assigning and Modifying the Default Client Policy to Allow Certificate-based Authentication

The Bank has implemented an internal certificate authority (CA) that is responsible for issuing and maintaining all client certificates. The policy can be modified by editing the default response rule to specify the certificate authority.

1. On the Rules tab of the Client (Respond Only) property sheet, select the Default Response filter action and then click Edit

   

2. On the Authentication Methods tab of the Edit Rule property sheet, click Add.

   

3. On the New Authentication Method property sheet, select Use a certificate from this certificate authority (CA), and click Browse.

4. Select the desired certificate authority and click OK.

   Note: Once the certificate authority has been added, ensure it is listed before Kerberos authentication to eliminate unnecessary validation attempts.

   

5. In the details pane, right-click the Client (Respond Only) policy, and then click Assign.

   

Host computers processing this policy will respond to requests for secure communications and will negotiate the security association, but the same host will not use secure communications if the client does not request it.

Configuring the Secure Servers to Require IPSec

The next step is to configure a policy for our servers that requires certificate-based authentication, integrity, and encryption. In addition, the policy does not allow any non-IPSec communications. This guarantees that only trusted parties that have been specified in the policy will be allowed access.

The configuration requires three steps.

• First, the Secure Server IPSec policy must be modified to require valid certificates for authentication.

• Second, a filter must be defined that specifies traffic coming from any source to our secure servers. This step is simplified by using the Add Filter Wizard. This allows specifying traffic from "any IP address" to "my IP address" as affected by this policy. The fact that the policy will be applied only to computers in the SecureServers organizational unit will ensure that all traffic to and from those computers will be authentic, unmodified, and encrypted.

• Third, the Bank has additionally chosen to implement 3DES as the default encryption algorithm. This modification can also be made through the policy.

  Note: By default, all filters are "mirrored." This specifies that packets with source and destination addresses reversed will also match the filter. For more information on configuring IPSec policies, see Chapter 8, "Internet Protocol Security," in the Windows 2000 Server Resource Kit TCP/IP Core Networking Guide.

Implementing IPSec as a VPN Solution

Our second requirement for the Bank was to implement IPSec as part of an overall VPN strategy for securing data between branch offices and corporate headquarters. As noted previously, IPSec can be used with Layer 2 Tunneling Protocol (L2TP) to secure traffic between hosts as well as between routers and/or gateways. Before looking at the Bank's implementation of IPSec over a VPN, let's briefly discuss the concept of VPN.

A virtual private network (VPN) allows communication between two computers over a shared or public network such as the Internet. The connection appears to the client as a dedicated point-to-point link. Data transmitted through the VPN is encapsulated with a header that allows it to be routed across the public network. Once the packet is received at the VPN server, the header is stripped and the packet is forwarded to its destination within the private network. The public network provides the infrastructure for sending the data. The establishment of the VPN is handled by various tunneling protocols, for example, Point-to-Point Tunneling Protocol (PPTP) or Layer 2 Tunneling Protocol (L2TP). See the following tables for comparison of L2TP/IPSec and PPTP, and recommended usages.

Supported features	PPTP	L2TP/IPSec
User authentication with passwords/radius	Yes	Yes
User authentication with smart card/token	Yes, with EAP2	Yes, with EAP
Host authentication	No, only user	Yes, with a PKI infrastructure using x.509 certificates
Network address translation (NAT) capable	Yes	Not at present
Non-IP protocol	Yes	Yes
Internal IP address for tunnel client	Yes	Yes
IP broadcast, multicast	Yes	Yes
Encryption method	Microsoft Point-to-Point Encryption (MPPE) providing 40-bit or 128-bit encryption	40-bit DES, 56-bit DES, and 3DES using 128-bit encryption

Feature	PPTP or L2TP/IPSec?
Need to provide NAT services	PPTP
Strongest security	L2TP/IPSec
Compatibility with Windows 9x and Windows NT	PPTP
Hardware acceleration of encryption technologies	IPSec
Policy based implementation	IPSec

Encryption of encapsulated data is provided through separate protocols like IPSec. This ensures that data intercepted during transmission will be unintelligible. Note that L2TP connections can be made without IPSec; however, this is not considered a VPN without the guaranteed data privacy provided by IPSec. In addition, IPSec can be used to create a tunnel without L2TP, but there are several implications of this that are beyond the scope of our discussion.3 When the IPSec driver receives an L2TP packet, it checks to see if the packet is encompassed by an IPSec policy. Based on the settings in the policy, IPSec encapsulates the message using the appropriate ESP headers and trailers.

Computer authentication of L2TP over IPSec requires that a certificate be installed on both the VPN client and the VPN server. In cases where this is not desirable, a preshared key can be configured to provide authentication of the VPN client and server.

Note: This is not as secure as machine certificates, but does provide an alternative for smaller organizations that do not have a certificate infrastructure in place. For more information on configuring certificates, see Chapter 12, "Planning Your Public Key Infrastructure," in the Microsoft Windows 2000 Server Resource Kit Deployment Planning Guide; Chapter 13, "Choosing Security Solutions That Use Public Key Technology," in the Microsoft Windows 2000 Server Resource Kit Distributed Systems Guide; and Chapter 16, "Windows 2000 Certificate Services and Public Key Infrastructure," in the Microsoft Windows 2000 Server Resource Kit Distributed Systems Guide. For more information on configuring L2TP over IPSec for use with a preshared key, see Chapter 9, "Virtual Private Networking," in the Windows 2000 Server Resource Kit Internetworking Guide.

Using IPSec and L2TP to Secure Branch Office Traffic

By default, all computers and users in a Windows 2000 domain authenticate using the Kerberos V5 protocol. IPSec utilizes Windows 2000 security services to provide authentication of connecting hosts. However, use of public key certificates is an alternative method in situations that include Internet access, communications with computers that do not support Kerberos V5 or any L2TP-based remote access. In fact, the Windows 2000 implementation of L2TP/IPSec requires certificate-based authentication for the participating hosts. Use of certificates for machine authentication requires at least one trusted certificate authority (CA). The Bank has implemented a stand-alone root CA to provide certificates to client computers. Also note that Windows 2000 provides support for most industry-standard CAs such as VeriSign and Entrust.

The Bank is currently providing Windows 2000 PPTP support for connectivity between branch offices and corporate headquarters. The branch office router connects to the Internet then use PPTP to access the VPN server and the corporate network. Because of the inherent insecurity of the Internet, the network administrator would like to implement tunneling using L2TP and IPSec. The Bank has permanent connections (T1) to the Internet from the branch office and corporate HQ routers. The connection to the LAN is an adapter installed in the Windows 2000 router.

The implementation

In order to use L2TP over an IPSec connection, both the VPN server and client must have machine certificates to authenticate. Recall that this was configured in the first scenario as part of the default policy for the Bank. Windows 2000 Routing and Remote Access provides support for both PPTP and L2TP tunnels. For more information on configuring Routing and Remote Access in Windows 2000, see online Help or Chapter 7, "Remote Access Server," in the Windows 2000 Server Resource Kit Internetworking Guide.

On the branch office router, it is necessary to configure the connection that will be used to access the corporate HQ router. This would be the interface connected to the Internet. Configuring this interface for the Bank included specifying the tunnel endpoint. Note that since this connection is used for a router-to-router connection, settings must be mirrored on both sides of the tunnel. The process employed for the Bank is outlined below. Most of the process is wizard-driven and can be invoked from Routing and Remote Access. For more information, see online Help for configuring L2TP-based router-to-router VPN.

To configure a router-to-router VPN solution using L2TP/IPSec

1. In the tree pane of the Routing and Remote Access snap-in, right-click Routing Interfaces, and then click New Demand-dial Interface. The Demand Dial Interface Wizard appears.

   

2. Type the name of the new interface and click Next.

   

3. For Connection Type, select Connect using virtual private networking (VPN), and then click Next.

   

4. For VPN Type, select Layer 2 Tunneling Protocol (L2TP), and then click Next.

   

5. For Destination Address, type the host name or IP address, and then click Next.

   

6. For Protocols and Security, select Route IP packets on this interface and click Next.

   

7. For Dial Out Credentials, type the user name, domain, and password, confirm the password, and then click Next.

   

8. Click Finish to complete the configuration process.

Any additional options that need to be configured for the connection, such as the IP address for the interface, security, and so forth, can be configured on the properties sheet for the interface.

VPN servers that provide an access point from the outside world to the corporate network may require special filtering to make sure that IPSec packets are not rejected at the VPN server. To prevent traffic other than L2TP/IPSec from being routed to the corporate network, the VPN server must be configured using the Routing and Remote Access snap-in to as follows:

• TCP ports 50 and 51 for inbound and outbound IPSec AH and ESP traffic.

• UDP port 500, inbound and outbound, for IKE negotiation traffic.

Be aware that these steps need to be completed on both sides of the connection for the router-to-router VPN to function properly. For more information on creating these connections, see the following chapters in the Windows 2000 Server Resource Kit Internetworking Guide: Chapter 2, "Routing and Remote Access Service"; Chapter 7, "Remote Access Server"; and Chapter 9, "Virtual Private Networking."

Conclusion

Planning an IPSec implementation requires an understanding of the underlying technologies as well as how they are implemented and administered in Windows 2000. Windows 2000 provides an integrated deployment and management infrastructure to simplify your IPSec deployment.

In order to be successful at implementing IPSec, several things should be considered. First, evaluate the nature and type of information being sent over the network and the need to secure that data. Is it sensitive proprietary information? Some areas of your network may require increased levels of security while other areas may be fine as is. A classification of areas that require high security, medium security, and low security may be helpful in documenting a project plan. Successful planning involves evaluating the risk and susceptibility to attack and determining a strategy based on the information gathered.

In addition, identify how data is traveling throughout the network—How is it being routed? Is it accessed from outside the corporate network (via VPN connections)? A successful plan will balance the security needs of you environment with the implementation and administration of a security plan. Windows 2000 provides an integrated architecture through the support of IPSec, L2TP, Group Policy, Kerberos, and certificates to make implementing security in your environment as simple as possible.

References

For further information on implementing specific configurations discussed in this paper, please refer to the following.

Microsoft Corp. Microsoft Windows 2000 Server Resource Kit Deployment Planning Guide (https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/w2rkbook/dpg.asp). Redmond, WA: Microsoft Press, 2000.

Microsoft Corp. Microsoft Windows 2000 Server Resource Kit Distributed Systems Guide. Redmond, WA: Microsoft Press, 2000.

Microsoft Corp. Microsoft Windows 2000 Server Resource Kit TCP/IP Core Networking Guide. Redmond, WA: Microsoft Press, 2000.

1 If the computational overhead of IPSec is sufficiently high, consider implementing a hardware solution. Offload network interface cards (NICs) allow for the offloading of much of the IPSec processing to the NIC. 3Com and Intel are currently supporting offload capabilities in several NICs. Performance tests completed by Intel indicate a tremendous performance boost from offloading the computations to the NIC. Contact specific vendors for more information.

2 EAP stands for Extensible Authentication Protocol, which allows for negotiation between the client and remote access server regarding what authentication method to use. Examples would be extensions for biometric devices, token cards, and so on.

3 Most notably, IPSec tunnel mode is mostly a unicast-based connection between subnets. Interoperability for multicast and broadcast and routing protocols is not well defined. In addition, most of the IPSec tunnel mode solutions are proprietary implementations that are difficult to integrate with separate vendor solutions. For these reasons, L2TP/IPsec seems to be a more viable solution for now.