Securing L2TP using IPsec
Extracted elements (27)
Stateless encryption and compression are preferred over stateful methods when L2TP runs over IP because L2TP does not mandate packet ordering, and stateful methods magnify packet losses in the absence of a reliable delivery mechanism. Stateful methods are more acceptable over ordered, low-loss media like ATM or Frame Relay.
The LNS certificate request payload (CRP) mechanism in IKE allows the LNS to trust multiple certificate authorities, enabling tunnel clients to connect using their own PKI credentials. Certificate revocation list checking MAY be enabled on a per-CA basis due to differences among PKI providers.
The responder IP address change mechanism uses StopCCN with a specific error code and ASCII-encoded address in the error message field rather than a new AVP. This reduces complexity by ensuring the initiator always knows the precise IP address of its peer, and allows L2TP to tie IPsec filters and policy to the same peer.
In compulsory tunneling, the client and LNS have unequal knowledge of security services: the LNS knows IPsec is in place between itself and the LAC, but the client does not. This asymmetry affects how each side negotiates PPP ECP and CCP compression/encryption.
L2TP allows the responder to use a dynamically assigned UDP source port (reflected in the SCCRP), which creates integration complexity with IKE/IPsec since phase 2 filter sets must be updated mid-establishment. L2TP must inject updated filters into the IPsec filter database when port changes occur.
Since the default MRU for PPP is 1500 bytes, L2TP and IPsec header overhead can cause fragmentation. The MTU provided to PPP should be the ingress/egress interface MTU minus extra header overhead, set after L2TP tunnel setup but before LCP negotiations begin.
All IPsec-mandated ciphersuites (described in RFC 2406 and RFC 2402), including NULL encryption, MUST be supported. Implementations MUST also implement replay protection mechanisms of IPsec.
All L2TP security compliant implementations MUST implement IPsec ESP for securing both L2TP control and data packets. Transport mode MUST be supported; tunnel mode MAY be supported.
For gateway-gateway and L2TP dial-out scenarios, the initial filter set at both sides MUST include an inbound filter: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701.
If a phase 2 SA bundle is not already present to protect the SCCRQ, the sending of a SCCRQ SHOULD cause IKE to set up the necessary SAs. If the SA cannot be set up for some reason, the packet MUST be dropped.
IKE SHOULD be supported for authentication, security association negotiation, and key management using the IPsec DOI. An L2TP security protocol MUST also provide a scalable approach to key management.
Implementations requiring protection of L2TP via IPsec SHOULD NOT allow the responder to change to a new IP address without sending a StopCCN. If the responder does choose a new IP address, it MUST send a StopCCN with Result Code set to 2 (General Error) and Error Code SHOULD be set to 7 (Try Another).
IPsec IKE negotiation MUST negotiate an authentication method specified in IKE RFC 2409. L2TP/IPsec implementations SHOULD NOT use a group pre-shared key for IKE authentication to the LNS.
Once the L2TP tunnel is deleted by either peer, any phase 1 and phase 2 SAs which still exist as a result of the L2TP tunnel between the peers SHOULD be deleted. Phase 1 and phase 2 delete messages SHOULD be sent when this occurs.
The initiator MUST allow the responder to float its port and SHOULD allow the responder to choose a new IP address. The initial filter set MUST be present before L2TP tunnel setup messages start to flow.
The initiator MUST parse the result and error code information from the StopCCN and send a new SCCRQ to the new IP address contained in the error message.
The L2TP security protocol MUST provide authentication, integrity and replay protection for control packets. It SHOULD protect confidentiality of control packets. It MUST provide integrity and replay protection of data packets, and MAY protect confidentiality of data packets.
The optional error message in the StopCCN MUST be present and MUST contain only the ASCII encoded IP address the Responder desires to use. The IP address is encoded in dotted decimal format for IPv4 or RFC 2373 format for IPv6.
When a packet arrives from a tunnel which requires security, L2TP MUST check that the packet was decrypted and/or authenticated by IPsec, and MUST verify that the IP addresses and UDP port values match the socket information used to setup the L2TP tunnel.
When user authentication is used in IPsec, the client MUST ensure that only traffic from that particular user is sent down the L2TP tunnel to provide traffic segregation.
An IPsec filter database is maintained with inbound and outbound filters keyed by IP address, UDP port, and direction. L2TP injects filters dynamically as port/address assignments change during tunnel establishment (SCCRQ/SCCRP exchange).
IKE Phase 1 and Phase 2 SAs are established to protect L2TP traffic. Phase 2 quick mode IDs represent traffic to be protected, comprising address space, protocol, and port information. A new Phase 2 SA may be required when the responder changes its port number.
The StopCCN message is reused to signal a responder IP address change: Result Code MUST be 2 (General Error), Error Code MUST be 7 (Try Another), and the error message field carries the ASCII-encoded new IP address in dotted-decimal (IPv4) or RFC 2373 (IPv6) format.
IPsec machine authentication does not prevent other users on a multi-user machine from using the L2TP tunnel, since only the machine identity is verified per-packet. User-level IPsec authentication or strict tunnel isolation is needed to enforce per-user traffic segregation.
Machine certificate enrollment must be strictly controlled since the value of a machine certificate is inversely proportional to the ease with which an attacker can obtain one. Similarly, user certificate enrollment periods should be time-limited to prevent attackers from using stolen passwords to obtain certificates.
Use of pre-shared keys in IKE main mode is vulnerable to man-in-the-middle attacks in remote access scenarios because pre-shared key selection can only be based on the IP address, and dynamic addressing forces use of a group pre-shared key. A rogue server with this key can mount dictionary attacks against PPP legacy auth methods like CHAP.
L2TP/IPsec tunnel establishment follows: (1) IKE Phase 1+2 to protect initial SCCRQ; (2) if responder changes IP, StopCCN triggers new IKE Phase 1+2 to the new address; (3) SCCRQ sent; (4) if responder changes port, new IKE Phase 2 initiated before SCCRP; (5) SCCRP and SCCCN complete tunnel establishment.