7.5 Encrypting Remote Sessions

Encryption is an integral part of the IP VPN process. While there are many ways to encrypt traffic over a VPN, there are three methods that are generally used. These methods ”PPTP, L2TP, and IPSec ”are considered standards, and all are extensively documented.

That being said, IP VPN is a growing area, and there are still lots of compatibility problems between different vendor implementations of these protocols. Before deciding on an IP VPN solution, ensure that all possible connectivity combinations have been thoroughly tested . If compatibility problems are found, report them to the respective vendors and ask for a resolution. In order for IP VPN to gain mass acceptance, it will be necessary for vendor interoperability to grow.

7.5.1 PPTP

The Point-to-Point Tunneling Protocol (PPTP) was specifically designed for the dial-up ISP market. Microsoft, in conjunction with Ascend, 3Com, ECI Telematics, and US Robotics, introduced PPTP in 1996 as a way for dial-up users to securely connect to a remote network.

PPTP runs over a PPP connection. A user connects to any ISP that accepts PPP connections, which is the currently accepted dial access standard protocol. Once the PPP connection has been established to the ISP, a connection is then made to the PPTP NAS located on the corporate network. Data can then be transmitted across the PPTP connection. PPTP will transport TCP, IPX, and NetBEUI packets across the VPN.

The official PPTP specification, outlined in RFC 1171/2637, uses TCP port 1723, and IANA assigned IP ID 47 for Generic Routing Encapsulation (GRE) protocol. PPTP clients are available for just about every major operating system including Windows, MacOS, Linux, Solaris, and BSD.

When PPTP was first introduced it came under a lot of fire. Bruce Schneier, president of Counterpane Systems, released a paper detailing some of the flaws with Microsoft's implementation of PPTP. Because Microsoft was the only major operating system vendor with a PPTP implementation at the time, security experts often derided the protocol. However, PPTP's ease of use and its ubiquity made it very popular with small businesses and network administrators. The problem with PPTP, in general, is that the specification does not outline minimum security precautions that a vendor should follow in order to implement it.

Microsoft is not the only company in which PPTP security weaknesses were found. In July 2001 Cisco issued a security warning indicating that it was possible to crash Cisco routers by issues malformed by PPTP packets. This bug is present in all versions of IOS 12.1, 12.2, and earlier. Routers are only susceptible to the attacks if PPTP is enabled, which it is not by default.

PPTP is a tunneling, not a transport, protocol. To transport data, PPTP uses GRE. GRE is defined in RFC 1701, RFC 1702, and RFC 2784. It can be used in conjunction with any protocol as a means of encapsulating data for transport, though PPTP is the most common association. PPTP is used to establish the tunnel, then PPP data packets are used to transmit the GRE encapsulated data.

PPTP has gained wide acceptance because of the support of Microsoft. A PPTP client has been bundled with all versions of Windows since Windows 98; a client was even made available for Windows 95. Unfortunately , the security vulnerabilities associated with the protocol have caused concern among security experts, who have largely abandoned it in favor of L2TP or IPSec.

7.5.2 L2TP

Cisco, Microsoft, Ascend Communications, and Redback Networks released the Layer 2 Tunneling Protocol (L2TP) as RFC 2661 in 1999. Like PPTP, L2TP was designed as a way to tunnel information across an Internet connection. Data is encrypted, and the destination address is hidden by the encryption, creating a secure connection.

The significant advantage that L2TP provides over PPTP is that L2TP can be used to encrypt traffic across ATM, SONET, Ethernet, and other means of data transport. L2TP is not limited to PPP connections only. L2TP uses UDP Port 1701 to send data across the tunnel. As with PPTP, L2TP is capable of encapsulating and tunneling non-IP packets, such as AppleTalk or IPX. This makes L2TP very useful for joining disparate networks with different protocols.

L2TP, as with PPTP, is encryption agnostic. Tunnel traffic can be encrypted in any manner that is agreed upon by the user opening the tunnel and the tunnel terminator. While remaining encryption agnostic , both Microsoft and Cisco are pushing for tunnel encryption using IPSec. In November 2001, they released RFC 3193, which details the process of encrypting L2TP sessions using IPSec.

7.5.3 IPSec

IPSec is often lumped with PPTP and L2TP as a VLAN tunneling protocol. IPSec is not really a tunneling protocol; instead, it is a suite of protocols designed to extend the security of IP-based networks using authentication and encryption. One of the ways in which IPSec secures IP packets is through the use of the Encapsulation Security Payload (ESP) part of the IPSec header. ESP can act as a means to tunnel data, hence the confusion many people have with regard to IPSec and tunneling protocols.

IPSec gives vendors a wide range of security options; unfortunately, this also leads to interoperability problems between vendors. The IETF IPSec working group has set minimum standards of security for each aspect of the IPSec suite. The minimum levels of security do not provide enough protection for an enterprise environment. Most implementations of the IPSec suite should be able to negotiate security levels, but when dealing with different vendors this negotiation, and therefore the connection, may fail.

An IPSec packet consists of three portions:

1. IP header

2. Authentication header (AH)

3. ESP

The IP header is the same as a standard IP header, which allows IPSec packets to traverse the same equipment as traditional IP packets, without having to make any changes to the equipment.

An IPSec packet header will look similar to Figure 7.5. It is constructed the same way as a standard IP packet header. The fragment offset field is used to indicate the start of the ESP, and the protocol field lists ESP, instead of the usual TCP or UDP.

Figure 7.5. A typical IP packet header

The AH follows the IP header. The AH is used to authenticate information about the packet itself; it does not encrypt the data. The AH can be used with ESP, in tunneling mode, or by itself. It is optional.

The AH consists of six fields (outlined in Figure 7.6): They are: next header, payload length, reserved, security parameters index, sequence number, and authentication data. The purpose of each field is outlined in Table 7.1.

Figure 7.6. IPSec authentication header

Table 7.1. Authentication Header Fields

Field	Function
Next Header	Indicates the protocol that follows the AH
Payload Length	The length of the AH
Reserved	Future use; currently set to 0
Security Parameters Index	Security parameter used in the datastream
Sequence Number	Used to keep packets in order
Authentication Data	Key, or other form of authentication

The authentication header uses either SHA-1 or MD5 one-way hash algorithm for protection of the data. The next header field refers to either a TCP or UDP protocol, or ESP, when AH is used in conjunction with ESP.

The ESP will either follow the AH or it will come directly after the IP header if there is no AH. The ESP contains the data being transmitted, as well as the protocol information (TCP or UDP).

There are two levels of security with the ESP. The entire payload is authenticated in the same manner as the AH and the payload data is encrypted, providing two layers of data integrity protection within the payload. There are seven fields within the ESP: SPI, sequence number, payload data, padding, pad length, next header, and authentication data.

The SPI, sequence number, and authentication data function in the same manner as they do in the AH. The only difference is that the authentication data field in the ESP is optional, whereas it is required within the AH.

The payload data is a variable-length field that contains the data information. As mentioned previously, this field is encrypted. Encryption information for the data is found in the SPI.

Padding, pad length, and next header are all optional fields that are used for encryption. Up to 255 bytes of padding can be added to the ESP to fill space left over by the payload data. It can be used to either align the authentication data to a four-byte boundary or to create additional space when an encryption algorithm requires that plain text be the multiple of some number of bytes. The breakdown of these fields is shown in Figure 7.7.

Figure 7.7. The IPSec ESP

IPSec can be used for tunneling in one of two ways:

1. The ESP allows a tunnel to be created simply using the IPSec suite. The ESP transmits encrypted data while encapsulating the original source and destination IP address within the payload data.

2. IPSec can be used as the encryption protocol for other protocols, such as L2TP and PPTP.

As vendor interoperability improves , IPSec will most likely become the default VPN protocol.