Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3
Extracted elements (22)
MPLS over L2TPv3 is preferred over plain IP or GRE encapsulation of MPLS because border routers can simply refuse all MPLS packets rather than maintaining complex per-source/destination ACLs, reducing the attack surface for label-spoofing attacks.
The L2-Specific Sublayer defined in RFC 3931 is intentionally omitted by default for MPLS over L2TPv3 because it is generally not needed; its absence simplifies the encapsulation and is reflected in the standard header diagram.
The L2TPv3 Cookie was chosen to provide a middle ground between plain IP/GRE (limited spoofing protection) and full IPsec (higher operational and processing overhead). A randomly seeded Cookie is much harder to guess than a source IP address, thwarting blind packet-insertion attacks.
Generic IP encapsulation procedures for MPLS over L2TPv3 (fragmentation, MTU, TTL, EXP/DSCP handling) follow the 'Common Procedures' defined in Section 5 of RFC 4023 for IP encapsulation of MPLS and are not separately specified here.
MPLS over L2TPv3 may be advantageous over RFC 4023 when two routers are already adjacent over an L2TPv3 tunnel established for another reason, or when hardware is optimized for L2TPv3 classification (e.g., already handling HDLC or Frame Relay over L2TPv3).
The tunnel tail and tunnel head are LSP adjacencies; the topmost label of any packet sent through the tunnel must be one distributed by the tunnel tail to the tunnel head, per RFC 3031 label distribution adjacency rules.
If a control protocol is used to set up IPsec-secured L2TPv3 tunnels, the control protocol MUST have an authentication mechanism, and this MUST be used when the tunnel is set up.
If an MPLS packet is received without IPsec encapsulation, and its topmost label is in the set distributed exclusively to IPsec-secured tunnel heads, then the packet MUST be discarded.
If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given Security Association (SA) is the one expected.
Manual keying MUST be supported. If automatic keying is implemented, IKE in main mode with preshared keys MUST be supported.
MPLS over L2TPv3 encapsulated packets should be considered as originating at the tunnel head and destined for the tunnel tail; IPsec transport mode SHOULD thus be used.
The Cookie MUST be selected as a cryptographically random value per RFC 4086, with the additional restriction that it not be the same as a recently used value for a given Session ID.
The L2TPv3 Session ID MUST be present in all MPLS over L2TPv3 encapsulated packets.
The tunnel tail MUST know precisely which labels it has distributed to tunnel heads of IPsec-secured tunnels. Those labels MUST NOT be distributed by the tunnel tail to any LSP adjacencies other than IPsec-secured tunnel heads.
When an MPLS/L2TPv3 flow carries payload traffic not known to be TCP-friendly and runs across an unprovisioned path that could become congested, the application MUST employ additional mechanisms to ensure that offered load is reduced appropriately during congestion.
When securing L2TPv3 with IPsec, the implementation MUST support ESP with null encryption. ESP with encryption MAY be supported if confidentiality is required. Securing L2TPv3 using IPsec MUST provide authentication and integrity.
The L2TPv3 Cookie is a variable-length field (maximum 64 bits) carrying a randomly assigned value. It provides an additional guarantee that a data packet has been directed to the proper L2TP session, supplementing the Session ID lookup.
The L2TPv3 Session ID is a 32-bit identifier field locally selected as a lookup key for the context of an L2TP Session. At minimum, session context contains Cookie presence/value, L2-Specific Sublayer type, and the tunneled encapsulation type.
In the absence of IPsec, source-address-only filtering at domain boundaries is insufficient protection unless the MPLS over L2TPv3 decapsulator also validates the IP source address. Destination address filtering may be impossible when tunnels traverse the public Internet.
The L2TPv3 Cookie does not provide encryption but, when used as a sufficiently random 64-bit secret value, acts as a packet source authentication check resistant to brute-force spoofing. It validates the Session ID on each packet and complements IPsec protection.
Three main threats exist when transporting MPLS between PEs via IP tunnels: packet insertion by a third party, packet viewing (confidentiality), and packet alteration (integrity). Mitigations include access lists, authentication, encryption, and context validation via the L2TPv3 Cookie.
MPLS over L2TPv3 frames are structured as: IP header (IPv4 or IPv6), followed by L2TPv3 header (Session ID + optional Cookie), followed by the complete MPLS Label Stack, followed by the MPLS Payload. The L2-Specific Sublayer is generally absent.