Layer Two Tunneling Protocol and Internet Protocol Security

  • Article

Layer Two Tunneling Protocol (L2TP) is a combination of PPTP and Layer 2 Forwarding (L2F), a technology proposed by Cisco® Systems, Inc. Rather than having two incompatible tunneling protocols competing in the marketplace and causing customer confusion, the IETF mandated that the two technologies be combined into a single tunneling protocol that represents the best features of PPTP and L2F. L2TP is documented in RFC 2661.

L2TP encapsulates PPP frames to be sent over IP, X.25, Frame Relay, or ATM networks. Currently, only L2TP over IP networks is defined. When sent over an IP internetwork, L2TP frames are encapsulated as User Datagram Protocol (UDP) messages. L2TP can be used as a tunneling protocol over the Internet or over private intranets.

L2TP uses UDP messages over IP internetworks for both tunnel maintenance and tunneled data. The payloads of encapsulated PPP frames can be encrypted or compressed, or both; however, Windows 2000 L2TP clients do not negotiate the use of MPPE for L2TP connections. Encryption for L2TP connections is provided by IPSec ESP.

It is possible to create L2TP connections in Windows 2000 that are not encrypted by IPSec. However, this is not a VPN connection because the private data being encapsulated by L2TP is not encrypted. Non-encrypted L2TP connections can be used temporarily to troubleshoot an L2TP over IPSec connection by eliminating the IPSec authentication and negotiation process.

L2TP assumes the availability of an IP internetwork between a L2TP client (a VPN client using the L2TP tunneling protocol and IPSec) and a L2TP server (a VPN server using the L2TP tunneling protocol and IPSec). The L2TP client might already be attached to an IP internetwork that can reach the L2TP server, or the L2TP client might have to dial into a NAS to establish IP connectivity as in the case of dial-up Internet users.

Authentication that occurs during the creation of L2TP tunnels must use the same authentication mechanisms as PPP connections such as EAP, MS-CHAP, CHAP, SPAP, and PAP.

For Internet-based L2TP servers, the L2TP server is an L2TP-enabled dial-up server with one interface on the external network, the Internet, and a second interface on the target private network.

L2TP tunnel maintenance and tunneled data have the same packet structure.

Tunnel Maintenance with L2TP Control Messages

Unlike PPTP, L2TP tunnel maintenance is not performed over a separate TCP connection. L2TP call control and management traffic is sent as UDP messages between the L2TP client and the L2TP server. In Windows 2000, the L2TP client and the L2TP server both use UDP port 1701.

note-icon

Note

The L2TP client and L2TP server in Windows 2000 always use UDP port 1701. The Windows 2000 L2TP server supports L2TP clients that use a UDP port other than 1701.

L2TP control messages over IP are sent as UDP datagrams. In the Windows 2000 implementation, L2TP control messages sent as UDP datagrams are sent as the encrypted payload of IPSec ESP as illustrated in Figure 9.11.

Cc958047.INBE11(en-us,TechNet.10).gif

Figure 9.11 L2TP Control Message

Because a TCP connection is not used, L2TP uses message sequencing to ensure delivery of L2TP messages. Within the L2TP control message, the Next-Received field (similar to the TCP Acknowledgment field) and the Next-Sent field (similar to the TCP Sequence Number field) are used to maintain the sequence of control messages. Out-of-sequence packets are dropped. The Next-Sent and Next-Received fields can also be used for sequenced delivery and flow control for tunneled data.

L2TP supports multiple calls for each tunnel. In the L2TP control message and the L2TP header for tunneled data is a Tunnel ID that identifies the tunnel and a Call ID that identifies a call within the tunnel.

Table 9.6 lists the primary L2TP control messages.

Table 9.6 L2TP Control Messages

Message Type

Purpose

Start-Control-Connection-Request

Sent by the L2TP client to establish the control connection. Each L2TP tunnel requires a control connection to be established before any other L2TP messages can be issued. It includes an Assigned Tunnel-ID that is used to identify the tunnel.

Start-Control-Connection-Reply

Sent by the L2TP server to reply to the Start-Control-Connection-Request message.

Start-Control-Connection-Connected

Sent in reply to a Start-Control-Connection-Reply message to indicate that the tunnel establishment was successful.

Outgoing-Call-Request

Sent by the L2TP client to create an L2TP tunnel. Included in the Outgoing-Call-Request message is an Assigned Call ID that is used to identify a call within a specific tunnel.

Outgoing-Call-Reply

Sent by the L2TP server in response to the Outgoing-Call-Request message.

Start-Control-Connection-Connected

Sent in reply to a received Outgoing-Call-Reply message to indicate that the call was successful.

Hello

Sent by either the L2TP client or L2TP server as a keep-alive mechanism. If the Hello is not acknowledged, the L2TP tunnel is eventually terminated.

WAN-Error-Notify

Sent by the L2TP server to all VPN clients to indicate error conditions on the PPP interface of the L2TP server.

Set-Link-Info

Sent by the L2TP client or L2TP server to set PPP-negotiated options.

Call-Disconnect-Notify

Sent by either the L2TP server or L2TP client to indicate that a call within a tunnel is to be terminated.

Stop-Control-Connection-Notification

Sent by either the L2TP server or L2TP client to indicate that a tunnel is to be terminated.

For the exact structure of L2TP control messages, please see the L2TP Internet draft.

L2TP Data Tunneling

L2TP data tunneling is performed through multiple levels of encapsulation.

Figure 9.12 shows the resulting structure of L2TP over IPSec tunneled data.

Cc958047.INBE12(en-us,TechNet.10).gif

Figure 9.12 L2TP Packet Encapsulation

L2TP Encapsulation

The initial PPP payload is encapsulated with a PPP header and an L2TP header.

UDP Encapsulation

The L2TP encapsulated packet is then encapsulated with a UDP header with the source and destination ports set to 1701.

IPSec Encapsulation

Based on IPSec policy, the UDP message is encrypted and encapsulated with an IPSec Encapsulating Security Payload (ESP) header and trailer and an IPSec Authentication (Auth) trailer.

IP Encapsulation

The IPSec packet is encapsulated with a final IP header containing the source and destination IP addresses of the VPN client and VPN server.

To be sent on a LAN or WAN link, the IP datagram is finally encapsulated with a header and trailer for the data-link layer technology of the outgoing physical interface. For example, when IP datagrams are sent on an Ethernet interface, the IP datagram is encapsulated with an Ethernet header and trailer. When IP datagrams are sent over a point-to-point WAN link such as an analog phone line or ISDN, the IP datagram is encapsulated with a PPP header and trailer.

De-encapsulation of L2TP over IPSec Tunneled Data

Upon receipt of the L2TP over IPSec tunneled data, the L2TP client or L2TP server:

  1. Processes and removes the data-link header and trailer.

  2. Processes and removes the IP header.

  3. Uses the IPSec ESP Auth trailer to authenticate the IP payload and the IPSec ESP header.

  4. Uses the IPSec ESP header to decrypt the encrypted portion of the packet.

  5. Processes the UDP header and sends the L2TP packet to L2TP.

  6. L2TP uses the Tunnel ID and Call ID in the L2TP header to identify the specific L2TP tunnel.

  7. Uses the PPP header to identify the PPP payload and forward it to the proper protocol driver for processing.

L2TP over IPSec Packets and Windows 2000 Networking Architecture

Figure 9.13 illustrates the path that tunneled data takes through the Windows 2000 networking architecture from a VPN client over a remote access VPN connection using an analog modem. The following steps outline the process:

  1. An IP datagram, IPX datagram, or NetBEUI frame is submitted by the appropriate protocol to the virtual interface that represents the VPN connection using NDIS.

  2. NDIS submits a packet to NDISWAN, which optionally compresses and provides a PPP header consisting of only the PPP Protocol ID field. No Flags or FCS fields are added.

  3. NDISWAN submits the PPP frame to the L2TP protocol driver, which encapsulates the PPP frame with a L2TP header. In the L2TP header, the Tunnel ID and the Call ID are set to the appropriate value identifying the tunnel.

  4. The L2TP protocol driver then submits the resulting packet to the TCP/IP protocol driver with information to send the L2TP packet as a UDP message from UDP port 1701 to UDP port 1701 with the IP addresses of the VPN client and the VPN server.

  5. The TCP/IP protocol driver constructs an IP packet with the appropriate IP header and UDP header. IPSec then analyzes the IP packet and matches it with a current IPSec policy. Based on the settings in the policy, IPSec encapsulates and encrypts the UDP message portion of the IP packet using the appropriate ESP headers and trailers.
    The original IP header with the Protocol field set to 50 is added to the front of the ESP packet.
    The TCP/IP protocol driver then submits the resulting packet to the interface that represents the dial-up connection to the local ISP using NDIS.

  6. NDIS submits the packet to NDISWAN.

  7. NSIDWAN provides PPP headers and trailers and submits the resulting PPP frame to the appropriate WAN miniport driver representing the dial-up hardware.

Cc958047.INBE13(en-us,TechNet.10).gif

Figure 9.13 L2TP Packet Development

note-icon

Note

It is possible to negotiate an encrypted PPP connection for the dial-up connection with an ISP. This is not necessary and not recommended because the private data being sent, the tunneled PPP frame, is already encrypted with IPSec. The additional level of encryption is not needed and can impact performance.