Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

Figure 10-3. L2TPv3 Connectivity Model

[View full size image]

Figure 10-5. L2TPv3 Packet-Switched Network Layer

Chapter 13, "Advanced L2TPv3 Case Studies."

L2TPv3 with an IPv4/UDP encapsulation uses a standard 20-byte IPv4 header without options and contains an IP protocol value of 17 to signify a UDP payload. The IP header is then Chapter 2.

Compared to IPv4 encapsulation, one of the advantages of using IPv4/UDP encapsulation is that it is friendlier to applications such as Network Address Translation (NAT). Furthermore, IPv4 encapsulation provides only a header checksum, whereas UDP also offers a checksum that verifies payload integrity. This could be an issue especially when you are dealing with and confirming the reliability of L2TPv3 control messages, which are covered in the section "L2TPv3 Control Connection," later in this chapter.

Note

The Cisco implementation of L2TPv3 only supports IPv4 header encapsulation for the L2TPv3 Delivery Header. As such, the remainder of this chapter focuses on the IPv4 L2TPv3 implementation.

Demultiplexing Sublayer

The L2TPv3 Demultiplexing Sublayer field allows the IPv4 tunnel (an IPv4 source and destination pair) to carry and demultiplex multiple pseudowires. This field is the equivalent of the Demultiplexing Sublayer described in Chapter 2. L2TPv3 supports demultiplexing through a combination of a Session Identifier and Cookie values shown in Figure 10-6.

Note

Figure 10-6 illustrates the L2TPv3 Demultiplexer field for an IP implementation. The L2TPv3 Demultiplexer field in an IP/UDP implementation contains fields in addition to the Session Identifier and Cookie to differentiate and coexist with other Layer 2 tunneling protocols such as L2TPv2 and Layer 2 Forwarding (L2F).

The Session Identifier is a 4-byte field with a nonzero value that identifies a specific L2TPv3 session between two tunnel endpoints. A Session ID value of 0 is reserved for control channel communication. Like the Tunnel Identifier in UTI, the Session Identifier is locally significant; therefore, it utilizes a local and remote value to represent a bidirectional session.

The Cookie field fulfills the same role as the UTI Tunnel Key. It is an optional layer containing a variable length field (maximum of 64 bits) that protects against inadvertent insertion of Layer 2 frames into the tunnel through either misconfiguration or malicious blind attacks. When the Cookie field is negotiated through the control channel, it is consistent throughout the duration of the session.

From a security perspective, the Cookie provides a lightweight security option on the L2TPv3 payload; therefore, it covers just a small subset of attacks known as blind insertion attacks. The blind insertion attack assumes that the attacker can inject data into the core but cannot sniff out data within the PSN core. Assuming that the Session Identifier is predictable, the only barrier restricting the attacker from injecting traffic into a Layer 2 stream is to guess this random Cookie value. The maximum field length is 64 bits because such a value makes it infeasible from a resource perspective to perform a brute force attack. For example, a brute force attack to insert a 40-byte spoofed packet into a tunnelassuming the attacker can inject data at an OC-192 ratewould require approximately 18,000 years.

The Cisco implementation allows for the Session Identifier and Cookie to be either manually predefined on each tunnel endpoint or negotiated over the L2TPv3 control channel. The Cookie field can be negotiated to a 0-, 4-, or 8-byte field size, depending on the platform restrictions.

Encapsulation Sublayer

L2TPv3 uses an optional field, referred to as an Layer 2-Specific Sublayer, to convey information that is not carried in the Layer 2 Payload but that is required for the tunnel de-encapsulating endpoint to properly reconstruct the Layer 2 Payload and send the frame to the CE device. This field is the equivalent of the optional Encapsulation Sublayer that is defined in the Pseudowire Emulation Protocol Layers.

The L2TPv3 base draft specifies a default Layer 2-Specific Sublayer illustrated in Figure 10-7 that you use if it meets the Layer 2 Payload requirements. Otherwise, you can define alternate Layer 2-Specific Sublayers and use them as negotiated through an Layer 2-Specific Sublayer Type AVP control message. A Data Sequencing AVP is signaled during session negotiation to determine whether sequencing is required or what type of traffic needs to be sequenced.

A Sequence bit (S-bit) set to 1 indicates that the 24-bit Sequence Number field contains a valid value. When the S-bit is not set, the de-encapsulating endpoint must ignore the Sequence Number field. The Sequence Number in the remainder of the default Layer 2-Specific Sublayer is a 24-bit field containing a free-running counter that starts at 0.

If sequencing is enabled, the current expected sequence number on the receiving device is equal to the previous sequence number of the last in-order packet plus 1. Sequenced L2TPv3 data is accepted if the stored sequence number is equal to or greater than the current expected sequence number. Any other packets that do not fit this description are either out-of-order or duplicate packets and are discarded. Because of the finite range of sequence numbers, you must take the wrapping of the field into account by tracking a window of sequence numbers greater than the current expected value. The recommended default range is equal to half of the available sequence number space (2²⁴/2=8388608). For example, assuming a sequence number field of 24 bits, the window range of "new" sequence numbers for the current sequence number of 10,040,243 is 10,040,244 through 1,677,216 and 0 through 3,303,269.

The Sequence Field allows you to detect lost, duplicate, or out-of-order packets for an individual session. However, the criticality of preserving the correct ordering depends on the sensitivity of the encapsulated Layer 2 traffic. If the Layer 3 traffic in the Layer 2 tunneled frame is IP, the upper layer protocol might handle out-of-sequence packets. Therefore, the aforementioned Data Sequencing AVP supports the following three options:

No sequencing.

Non-IP data requires sequencing.

All data packets require sequencing.

The Cisco sequencing implementation only drops out-of-order frames and does not attempt to reorder out-of-sequence packets. You should understand the implications of this behavior prior to enabling sequencing relative to the Layer 2 protocol.

L2TPv3 Control Connection

L2TPv3 supports an optional control connection mechanism, which handles peer capability negotiation and detection in addition to pseudowire creation, maintenance, and teardown. This section explores L2TPv3's control connection by examining how control messages are encapsulated and what the different negotiation phases are for control channel initialization and session negotiation.

Unlike AToM, which uses link Layer Distribution Protocol (LDP) for LSP tunneling (PSN tunnel signaling) and directed LDP for virtual circuit (VC) label distribution (pseudowire/PE maintenance), L2TPv3 utilizes a single reliable, inband control plane for both purposes. This control plane setup phase begins with an L2TP Control Connection (sometimes referred to in L2TP terminology as the L2TP tunnel) establishment phase for advertising and negotiating capabilities between peers. After the L2TP Control Connection is established, individual pseudowire sessions (referred to in L2TP terminology as L2TP sessions) are set up in the Session Negotiation phase as needed based on the attachment circuit state.

Note

There are three variations on the control plane implementation of L2TPv3. L2TPv3 in its simplest mode of operation, known as Manual Mode, obviates the need for a control plane protocol and simply requires predefined session IDs and cookies. The second variation, called Manual Mode with Keepalive, negotiates the Control Connection phase but not the Session Negotiation phase. This offers a simple dead-peer detection mechanism that is similar to what is available in UTI with keepalives. Dynamic Mode negotiates both the Control Connection phase as well as the Session Negotiation phase for each pseudowire session.

As mentioned earlier in the section "Introducing L2TPv3," L2TPv3 essentially borrowed from L2TPv2's control channel signaling and expanded upon it by defining additional AVPs. These AVPs are used as an extensible mechanism to identify message types within the control channel. In addition to identifying the nature of the PW session or control channel, the control messages can indicate or define the operational state of the attachment circuits. The next sections describe control message encapsulation and control channel signaling in more detail.

Control Message Encapsulation

Because the L2TPv3 control channel is sent inband with L2TPv3 data packets, it is necessary to have some method of differentiating control channel messages from data packets. To understand how this is accomplished, you must examine the control message formatting. Figure 10-6 and 10-7 examined the encapsulation for L2TPv3 data messages only. The formatting of L2TPv3 control messages over IP differs slightly, as shown in Figure 10-8.

Figure 10-8 illustrates the encapsulation for L2TPv3 Control Messages, assuming that an IPv4 header is used. As described in the earlier "Demultiplexing Sublayer" section, L2TPv3 data packets utilize a nonzero Session Identifier. The Session Identifier value of 0 is reserved for control channel messages and distinguishes data packets from control messages. The remaining fields are unique to the control message encapsulation and are examined individually:

T, L, S You must set the Type bit (T-bit) to 1 to indicate that this is a control message. You must also set the Length bit (L-bit) and Sequence bit (S-bit) to 1 to indicate that length and sequence numbers are present in the L2TPv3 control message header. Do not confuse the sequence numbers with the Sequence Number field in the Layer 2-Specific Sublayer. The former are sequence numbers that are used in the control message header for reliable delivery.

Version The Version field indicates which version of L2TP is in use. Set this value to 3 to indicate L2TPv3.

Length The Length field indicates the total size of the control message calculated from the beginning of the message starting with the T-bit.

Control Connection ID The Control Connection Identifier contains a locally significant field to represent the control channel (L2TPv3 tunnel). The nonzero Control Connection IDs are exchanged during the L2TP Control Channel phase by using the Assigned Control Connection ID AVP.

Ns Ns, or the sequence number sent, indicates the sequence number for this control message. This field begins at 0 and increments by 1 for each control message that is sent to the peer.

Nr Nr is the sequence number expected to be received in the next control message. Ns and Nr provide a simple sliding window mechanism to handle control message transmission, retransmission, and detection of lost or duplicate control message packets.

Following the control message header are one or more AVPs. Each AVP follows a consistent format that contains the following fields:

M When the Mandatory bit (M-bit) is set, it indicates that the associated Control Connection or PW Session must be shut down if the recipient does not recognize this AVP. If a Control Connection occurs, a Stop Control Connection (STOPCCN) message is sent. If a PW Session occurs, a Call Disconnect Notification (CDN) message is sent.

H The Hidden bit (H-bit) indicates to the recipient whether the AVP content is passed in clear text or obfuscated in some manner to hide sensitive information. For this AVP encryption to occur, a shared secret must be defined on both endpoints, Control Message Authentication must be enabled, and a Random Vector AVP must be sent.

AVP Length The AVP Length field indicates the length of the entire AVP, as highlighted in Figure 10-8.

Vendor ID The Vendor ID is a 2-byte field that follows Internet Assigned Numbers Authority (IANA) assigned values that are defined in RFC 1700 in the "SMI Network Management Private Enterprise Codes" section. This allows vendors to define private Attribute Types. A Vendor ID field of 0 represents that this Attribute Type is an Internet Engineering Task Force (IETF) adopted attribute value that is defined in the L2TPv3 base draft.

Attribute Type The Attribute Type contains a 2-byte field representing the Attribute Message. You must interpret this field's value relative to the Vendor ID field.

Attribute Value The Attribute Value contains the actual content of the defined Vendor ID Attribute Type. The length of this field is the Attribute Length minus 6 bytes for Attribute Header fields.

L2TPv3 Control Channel Signaling

Control channel signaling operates in two phases: control connection establishment followed by session establishment (optional).

Figure 10-9 builds upon the network layout in Figure 10-3 and shows the control connection establishment that is required to build the control channel between the two L2TPv3 endpoints, R1 and R2, and subsequent control channel messages.