RFC 3193
Securing L2TP using IPsec
Securing L2TP using IPsec 🎀
okay so this is RFC 3193, and it's giving serious protocol energy 💅. It's from the Network Working Group, it's on the Standards Track, and it's dated November 2001. The authors are B. Patel (Intel), B. Aboba and W. Dixon (Microsoft), and G. Zorn and S. Booth (Cisco Systems). The title block doesn't say it obsoletes or updates any other RFC, so this one stands on its own 🦋.
Status of This Memo
this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. check the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. distribution of this memo is unlimited ✨.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. 💜
Abstract
okay so this doc is about how L2TP (Layer Two Tunneling Protocol) can use IPsec to get tunnel authentication, privacy protection, integrity checking, and replay protection 🔐. it covers both the voluntary and the compulsory tunneling cases, and it's lowkey iconic ✨.
Table of Contents
1. Introduction .................................................. 2
1.1 Terminology .................................................. 3
1.2 Requirements language ........................................ 3
2. L2TP security requirements ................................... 4
2.1 L2TP security protocol ....................................... 5
2.2 Stateless compression and encryption ......................... 5
3. L2TP/IPsec inter-operability guidelines ....................... 6
3.1. L2TP tunnel and Phase 1 and 2 SA teardown ................... 6
3.2. Fragmentation Issues ........................................ 6
3.3. Per-packet security checks .................................. 7
4. IPsec Filtering details when protecting L2TP .................. 7
4.1. IKE Phase 1 Negotiations .................................... 8
4.2. IKE Phase 2 Negotiations .................................... 8
5. Security Considerations ....................................... 15
5.1 Authentication issues ........................................ 15
5.2 IPsec and PPP interactions ................................... 18
6. References .................................................... 21
Acknowledgments .................................................. 22
Authors' Addresses ............................................... 23
Appendix A: Example IPsec Filter sets ............................ 24
Intellectual Property Statement .................................. 27
Full Copyright Statement ......................................... 281. Introduction ✨
okay so L2TP [1] is a protocol that tunnels PPP traffic over a variety of networks (think IP, SONET, ATM) 🧚. because it encapsulates PPP, L2TP inherits PPP authentication, the PPP Encryption Control Protocol (ECP, described in [10]), and the Compression Control Protocol (CCP, described in [9]). it also has tunnel authentication, which can be used to mutually authenticate the tunnel endpoints. BUT L2TP does not define tunnel protection mechanisms, so that's the gap we're here to fill 👑.
IPsec is a protocol suite that secures communication at the network layer between two peers 🔐. it's made up of the IP Security Architecture document [6], IKE (described in [7]), IPsec AH (described in [3]), and IPsec ESP (described in [4]). IKE is the key management protocol, and AH and ESP are used to protect IP traffic. it's giving teamwork 🫶.
this document proposes using the IPsec protocol suite to protect L2TP traffic over IP networks, and it talks about how IPsec and L2TP should be used together 💖. this document does not try to standardize end-to-end security. when end-to-end security is required, it is recommended that additional security mechanisms (such as IPsec or TLS [14]) be used inside the tunnel, in addition to L2TP tunnel security. layers on layers, bestie 🧁.
although L2TP does not mandate the use of IP/UDP for its transport mechanism, the scope of this document is limited to L2TP over IP networks 🌸. the exact mechanisms for enabling security for non-IP networks must be addressed in appropriate standards for L2TP over specific non-IP networks. that's a whole other chapter, not this one 🙈.
1.1. Terminology 🍓
Voluntary Tunneling In voluntary tunneling, the user creates a tunnel, usually with a tunneling client 💅. so the client sends L2TP packets to the NAS, which forwards them on to the LNS. in voluntary tunneling the NAS does not need to support L2TP, and the LAC lives on the same machine as the client. another example is the gateway-to-gateway scenario, where the tunnel is created by a network device, typically a router or network appliance. in that scenario either side may start the tunnel on demand 🌈.
Compulsory Tunneling In compulsory tunneling, a tunnel gets created without any action from the client, and the client doesn't get any choice in it 😭. so the client sends PPP packets to the NAS/LAC, which encapsulates them in L2TP and tunnels them to the LNS. in the compulsory case, the NAS/LAC must be L2TP-capable 💜.
Initiator The initiator can be the LAC or the LNS. it's the device that sends the SCCRQ and receives the SCCRP ⭐.
Responder The responder can be the LAC or the LNS. it's the device that receives the SCCRQ and replies with an SCCRP 🦋.
1.2. Requirements language 🎀
okay so in this doc, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT" are to be read as described in [2] 💅.
2. L2TP security requirements 🔥
L2TP tunnels PPP traffic over IP and non-IP public networks, so both the control and data packets of the L2TP protocol are vulnerable to attack 😬. the attacks include:
- [1] an adversary may try to discover user identities by snooping data packets 🙈.
- [2] an adversary may try to modify packets (both control and data).
- [3] an adversary may try to hijack the L2TP tunnel or the PPP connection inside the tunnel.
- [4] an adversary can launch denial of service attacks by terminating PPP connections or L2TP tunnels 💀.
- [5] an adversary may attempt to disrupt the PPP ECP negotiation to weaken or remove confidentiality protection. or, an adversary may try to disrupt the PPP LCP authentication negotiation so it weakens PPP authentication or gets access to user passwords 👀.
to handle these threats, the L2TP security protocol MUST be able to provide authentication, integrity, and replay protection for control packets. it SHOULD also be able to protect confidentiality for control packets. it MUST be able to provide integrity and replay protection of data packets, and it MAY be able to protect confidentiality of data packets. an L2TP security protocol MUST also provide a scalable approach to key management ✨.
the L2TP protocol, PPP authentication, and PPP encryption do not meet the security requirements for L2TP 😭. L2TP tunnel authentication gives mutual authentication between the LAC and the LNS at tunnel origination. it does not protect control and data traffic on a per-packet basis, so the L2TP tunnel stays vulnerable to attacks. PPP authenticates the client to the LNS, but it also doesn't provide per-packet authentication, integrity, or replay protection. PPP encryption meets confidentiality requirements for PPP traffic, but it doesn't address authentication, integrity, replay protection, and key management. on top of that, PPP ECP negotiation, outlined in [10], doesn't provide a protected ciphersuite negotiation. so PPP encryption is a weak security solution, and it doesn't help secure the L2TP control channel either 💔.
key management facilities are not provided by the L2TP protocol. still, where L2TP tunnel authentication is wanted, tunnel passwords need to be distributed 🔑.
note that several of the attacks above can be carried out on PPP packets sent over the link between the client and the NAS/LAC, before the packets get encapsulated in an L2TP tunnel 👀. strictly speaking these attacks are outside the scope of L2TP security, but to protect against them, the client SHOULD provide confidentiality, authentication, replay, and integrity protection for PPP packets sent over the dial-up link. authentication, replay, and integrity protection are not currently supported by the PPP encryption methods described in [11]-[13] 🫠.
2.1. L2TP Security Protocol 💖
the L2TP security protocol MUST provide authentication, integrity, and replay protection for control packets. it SHOULD also protect confidentiality of control packets. it MUST provide integrity and replay protection of data packets, and it MAY protect confidentiality of data packets. an L2TP security protocol MUST also provide a scalable approach to key management 👑.
to meet the above requirements, all L2TP security compliant implementations MUST implement IPsec ESP for securing both L2TP control and data packets. Transport mode MUST be supported, and tunnel mode MAY be supported. all the IPsec-mandated ciphersuites (described in RFC 2406 [4] and RFC 2402 [3]), including NULL encryption, MUST be supported. note that although an implementation MUST support all IPsec ciphersuites, it's an operator choice which ones get used 🧠. if confidentiality is not required (for example, L2TP data traffic), ESP with NULL encryption may be used. the implementations MUST implement the replay protection mechanisms of IPsec 🔁.
L2TP security MUST meet the key management requirements of the IPsec protocol suite. IKE SHOULD be supported for authentication, security association negotiation, and key management, using the IPsec DOI [5] 🗝️.
2.2. Stateless compression and encryption 🧚♀️
stateless encryption and/or compression is highly desirable when L2TP runs over IP 💅. L2TP is a connection-oriented protocol, so stateful compression/encryption is feasible, but when it runs over IP, it isn't desirable. sure, stateful methods give better compression, but without an underlying reliable delivery mechanism they magnify packet losses. that makes them problematic over the Internet, where packet loss can be significant 😩. although L2TP [1] is connection oriented, packet ordering is not mandatory, which can make stateful compression/encryption schemes hard to implement. these considerations matter less when L2TP runs over non-IP media like IEEE 802, ATM, X.25, or Frame Relay, since those media guarantee ordering and packet losses are typically low 🌷.
3. L2TP/IPsec inter-operability guidelines 🌈
the following guidelines are established to meet L2TP security requirements using IPsec in practical situations 💜.
3.1. L2TP tunnel and Phase 1 and 2 SA teardown
okay so teardown comes in two flavors 💅 graceful and non-graceful. For PPP, the graceful goodbye is the LCP TermReq and TermAck sequence 🦋. LCP keep-alive messages and L2TP tunnel hellos are how you notice when someone ghosted you without saying bye 💀. Whenever a teardown event closes the tunnel, the control connection teardown mechanism defined in [1] must be used 🎀. Once either peer deletes the L2TP tunnel, any phase 1 and phase 2 SA's still hanging around because of that tunnel between the two peers SHOULD be deleted, and phase 1 and phase 2 delete messages SHOULD be sent when that happens 🧹.
When IKE gets a phase 1 or phase 2 delete message, it should let L2TP know that it happened 📣. If L2TP has sent a ZLB ack in reply to a STOPCCN, that counts as positive proof the peer got the ZLB ack and cleaned up its L2TP tunnel state for it 🫶. At that point the L2TP tunnel state and any associated filters can be safely removed ✨.
3.2. Fragmentation Issues
so PPP's default MRU is 1500 bytes, which means fragmentation can get messy when you stack L2TP and IPsec headers on a PPP frame 🙈. One fix is to give PPP the MTU of the L2TP/IPsec tunnel's ingress/egress interface minus the overhead of those extra headers 🧚. This should happen after the L2TP tunnel is set up but before LCP negotiations begin. If the tunnel interface's MTU is smaller than PPP's default MTU, it may replace the value being used 🌸. That same value can also be proposed as the initial MRU in the LCP config req 💜.
If IPsec receives an ICMP PMTU, that value should be stored in the SA, as proposed in [6] 🔥. IPsec should also tell L2TP about it so the new MTU can be reflected in the PPP interface 🌈. Any new PMTU discoveries seen at the PPP interface should be checked against this new value and handled accordingly 💖.
3.3. Per-packet security checks
okay this part is serious 👑. When a packet shows up from a tunnel that requires security, L2TP MUST:
- [1] Check that IPsec decrypted and/or authenticated the packet 🔐. Since IPsec already verifies that the packet came in on the correct SA, L2TP can be sure it was sent by a trusted peer and didn't arrive in the clear 🙌.
- [2] Verify that the IP addresses and UDP port values in the packet match the socket info used to set up the L2TP tunnel 🛡️. This stops malicious peers from spoofing packets into other tunnels 🚫.
4. IPsec Filtering details when protecting L2TP ✨
IKE/IPsec doesn't care about the nitty-gritty of the app it's protecting 🙃, so usually there's no integration needed between the application and IPsec. BUT protocols that let the port number float during negotiation (like L2TP) can cause trouble with the current IKE framework 😬. The L2TP specification [1] says implementations MAY use a dynamically assigned UDP source port 🦋. That port change shows up in the SCCRP sent from the responder to the initiator 💫.
Even though the current L2TP spec lets the responder use a new IP address when sending the SCCRP, implementations that need L2TP protected by IPsec SHOULD NOT do that 🙅♀️. To make it work with L2TP and IPsec, when the responder picks a new IP address it MUST send a StopCCN to the initiator, with the Result and Error Code AVP present 📨. The Result Code MUST be set to 2 (General Error), and the Error Code SHOULD be set to 7 (Try Another) 💅. If the Error Code is 7, the optional error message MUST be present, and its contents MUST contain the IP address (ASCII encoded) the responder wants to use for later communication 📍. Only the ASCII encoded IP address should be in the error message. The IP address is written in dotted decimal for IPv4 or in RFC 2373 [17] format for IPv6 🌍. The initiator MUST parse the result and error code info and send a new SCCRQ to the new IP address in the error message 🎯. This keeps things simple since the initiator always knows exactly where its peer is 🧠, and it gives L2TP a controlled way to tie IPsec filters and policy to the same peer 🎀.
The filtering details needed for this behavior, plus the other mechanisms needed to protect L2TP with IPsec, are covered in the sections that follow 📚.
4.1. IKE Phase 1 Negotiations
Per IKE [7], when you use pre-shared key authentication, each peer you want secure communication with needs a key 🔑. With Main Mode (which gives identity protection), that key has to match the peer's IP address 🪪. With Aggressive Mode (which does NOT give identity protection, lol), the pre-shared key has to map to one of the valid id types defined in the IPsec DOI [5] 👀.
If the initiator gets a StopCCN where the result and error code AVP is set to "try another" and a valid IP address is in the message, it MAY bind the original pre-shared key used by IKE to the new IP address in the error message 🔁.
Okay, real talk 🥺: think about scalability when using pre-shared keys for phase 1 auth. As the number of LAC and LNS endpoints grows, pre-shared keys get harder and harder to manage 😵💫. Whenever possible, authentication with certificates is the way to go 📜✨.
4.2. IKE Phase 2 Negotiations
During IKE phase 2, the peers agree on what traffic IPsec is going to protect 🛡️. The quick mode IDs represent that agreed traffic and are made up of address space, protocol, and port info 🗂️.
When securing L2TP with IPsec, these cases have to be considered 👇:
+--------------------------------------------------+
| Initiator Port | Responder Addr | Responder Port |
+--------------------------------------------------+
| 1701 | Fixed | 1701 |
+--------------------------------------------------+
| 1701 | Fixed | Dynamic |
+--------------------------------------------------+
| 1701 | Dynamic | 1701 |
+--------------------------------------------------+
| 1701 | Dynamic | Dynamic |
+--------------------------------------------------+
| Dynamic | Fixed | 1701 |
+--------------------------------------------------+
| Dynamic | Fixed | Dynamic |
+--------------------------------------------------+
| Dynamic | Dynamic | 1701 |
+--------------------------------------------------+
| Dynamic | Dynamic | Dynamic |
+--------------------------------------------------+If you cover the most general case, you cover all of these 🧩. The most general case is the last one in the list 💯: the initiator picks a new port number and the responder picks a new address and port number 🦋. Here's the L2TP message flow for setting that up 👇:
-> IKE Phase 1 and Phase 2 to protect Initial SCCRQ
SCCRQ -> (Fixed IP address, Dynamic Initiator Port)
<- STOPCCN (Responder chooses new IP address)
-> New IKE Phase 1 and Phase 2 to protect new SCCRQ
SCCRQ -> (SCCRQ to Responder's new IP address)
<- New IKE Phase 2 to for port number change by the responder
<- SCCRP (Responder chooses new port number)
SCCCN -> (L2TP Tunnel Establishment completes)Initiators and responders usually don't change ports on the fly 🙂, but L2TP security has to handle newer stuff like load balancing and QoS ⚖️. That can mean the port and IP address float during L2TP tunnel establishment 🌊.
To support the general case, L2TP and IPsec both need mechanisms that let L2TP inject filters into the IPsec filter database 💉. Any app that floats ports and needs IPsec protection can use this technique, and it's described in the sections that follow 🎀.
The responder doesn't have to support floating its IP address and port 🙅♀️. The initiator, though, MUST let the responder float its port and SHOULD let the responder choose a new IP address (see section 4.2.3, below) 🫶.
Appendix A has examples of these cases using the process described below 📖.
4.2.1. Terminology definitions used for filtering statements
Here are the terms we'll use for filtering stuff 🧾:
I-Port: The UDP port number the Initiator picks to send and receive L2TP traffic on 🔌. It can be a static port like 1701 or an ephemeral one assigned by the socket 🌱.R-Port: The UDP port number the Responder picks to send and receive L2TP traffic on 🔌. It can be port 1701 or an ephemeral one assigned by the socket 🌱. This is the port the Responder uses after getting the initial SCCRQ 📬.R-IPAddr1: The IP address the Responder listens on for the initial SCCRQ 👂. If the responder doesn't pick a new IP address, this address gets used for all later L2TP traffic 🔁.R-IPAddr2: The IP address the Responder picks after receiving the SCCRQ 🆕. It's used to send the SCCRP, and all later L2TP tunnel traffic is sent and received on this address 📡.R-IPAddr: The IP address the responder uses to send and receive L2TP packets 📦. It's either the initial R-IPAddr1 value or a new R-IPAddr2 value 🔄.I-IPAddr: The IP address the Initiator uses to talk to its peer for the L2TP tunnel 🤝.Any-Addr: Having Any-Address means IKE should accept any single address proposed in the local address of the quick mode IDs the peer sends during IKE phase 2 negotiations 🌐. That single address can be an IP Single address, an IP Netmask address with the Netmask set to 255.255.255.255, an IP address Range with a range of 1, or a hostname that resolves to one address 🏷️. Check [5] for more on the format of quick mode IDs 📚.Any-Port: Having Any-Port means IKE should accept a value of 0 or a specific port value for the port in the quick mode IDs negotiated during IKE phase 2 🚪.
The filters in the following sections are listed from highest priority to lowest priority 👑✨.
4.2.2. Initial filters needed to protect the SCCRQ ✨
Okay bestie, so the initial filter set on the initiator AND the responder is what protects the SCCRQ 🔐, the message the initiator sends to open the L2TP tunnel. Both sides either get pre-configured with these filters, or L2TP has a way to inject this info into the IPsec filtering database 💅. Either way, this filter MUST be present before the L2TP tunnel setup messages start flowing. No cap, non-negotiable 💀
Responder Filters:
Outbound-1: None. They should be be dynamically created by IKE
upon successful completion of phase 2.
Inbound-1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst
1701
Initiator Filters:
Outbound-1: From I-IPAddr, to R-IPAddr1, UDP, src I-Port,
dst 1701
Inbound-1: From R-IPAddr1, to I-IPAddr, UDP, src 1701,
dst I-Port
Inbound-2: From R-IPAddr1, to I-IPAddr, UDP, src Any-Port,
dst I-PortWhen the initiator uses dynamic ports, L2TP must inject the filters into the IPsec filter database once its source port number is known 🦋. If the initiator uses a fixed port of 1701, these filters MAY be statically defined 🌸.
The Any-Port definition in the initiator's inbound-2 filter statement is needed to handle the potential port change that can happen when the responder changes its port number 🔄.
If a phase 2 SA bundle is not already present to protect the SCCRQ, the sending of a SCCRQ by the initiator SHOULD cause IKE to set up the necessary SAs to protect this packet 🔑. Alternatively, L2TP may also request IKE to set up the SA bundle. If the SA cannot be set up for some reason, the packet MUST be dropped 🚫.
The port numbers in the Quick Mode IDs sent by the initiator MUST contain the specific port numbers used to identify the UDP socket 🎀. The port numbers would be either I-Port/1701 or 1701/1701 for the initial SCCRQ. The quick mode IDs sent by the initiator will be a subset of the Inbound-1 filter at the responder. So the quick mode exchange finishes, and IKE should inject a specific filter set into the IPsec filter database and associate it with the phase 2 SA between the peers. These filters should persist as long as the L2TP tunnel exists. The new filter set at the responder will be:
Responder Filters:
Outbound-1: From R-IPAddr1, to I-IPAddr, UDP, src 1701,
dst I-Port
Inbound-1: From I-IPAddr, to R-IPAddr1, UDP, src I-Port,
dst 1701
Inbound-2: From Any-Addr, to R-IPAddr1, UDP, src Any-Port,
dst 1701Mechanisms SHOULD exist between L2TP and IPsec so that L2TP is not retransmitting the SCCRQ while the SA is being established 🙈. L2TP's control channel retransmit mechanisms should start once the SA has been established. This helps avoid timeouts that can happen because of slow SA establishment 🐢.
Once the phase 2 SA has been established between the peers, the SCCRQ should be sent from the initiator to the responder 📨.
If the responder does not choose a new IP address or a new port number, the L2TP tunnel can now proceed to establish 🎉.
4.2.3. Responder chooses new IP Address 🌍
This step is the process to follow when the responder chooses a new IP address. The only chance for the responder to change its IP address is after receiving the SCCRQ but before sending a SCCRP. Main character energy for the responder, but there's a strict window 🎬.
The new address the responder chooses to use MUST be reflected in the result and error code AVP of a STOPCCN message. The Result Code MUST be set to 2 (General Error) and the Error Code MUST be set to 7 (Try Another). The optional error message MUST be present, and its contents MUST contain the IP address (ASCII encoded) the Responder desires to use for subsequent communications. Only the ASCII encoded IP address should be present in the error message 💌. The IP address is encoded in dotted decimal format for IPv4 or in RFC 2373 [17] format for IPv6.
The STOPCCN Message MUST be sent using the same address and UDP port information that the initiator used to send the SCCRQ. This message will be protecting using the initial SA bundle set up to protect the SCCRQ 🛡️.
Upon receiving the STOPCCN, the initiator MUST parse the IP address from the Result and Error Code AVP and perform the necessary sanity checks to verify it's a correctly formatted address 🔍. If no errors are found, L2TP should inject a new set of filters into the IPsec filter database. If using pre-shared key authentication, L2TP MAY request IKE to bind the new IP address to the pre-shared key that was used for the original IP address 🗝️.
Since the IP address of the responder changed, a new phase 1 and phase 2 SA must be established between the peers before the new SCCRQ is sent 🔁.
Assuming the initial tunnel has been torn down and the filters needed to create the tunnel removed, the new filters for the initiator and responder will be:
Initiator Filters:
Outbound-1: From I-IPAddr, to R-IPAddr2, UDP, src I-Port,
dst 1701
Inbound-1: From R-IPAddr2, to I-IPAddr, UDP, src 1701,
dst I-Port
Inbound-2: From R-IPAddr2, to I-IPAddr, UDP, src Any-Port,
dst I-PortOnce IKE phase 2 completes, the new filter set at the responder will be:
Responder Filters:
Outbound-1: From R-IPAddr2, to I-IPAddr, UDP, src 1701,
dst I-Port
Inbound-1: From I-IPAddr, to R-IPAddr2, UDP, src I-Port,
dst 1701
Inbound-2: From Any-Addr, to R-IPAddr1, UDP, src Any-Port,
dst 1701If the responder chooses not to move to a new port number, the L2TP tunnel setup can now complete 🌈.
4.2.4. Responder chooses new Port Number 🔀
The responder MAY choose a new UDP source port to use for L2TP tunnel traffic 🦄. This decision MUST be made before sending the SCCRP. If a new port number is chosen, then L2TP must inject new filters into the IPsec filter database. The responder must start new IKE phase 2 negotiations with the initiator 🤝.
The final filter set at the initiator and responder is as follows:
Initiator Filters:
Outbound-1: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst
R-Port
Outbound-2: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst
1701
Inbound-1: From R-IPAddr, to I-IPAddr, UDP, src R-Port, dst
I-Port
Inbound-2: From R-IPAddr, to I-IPAddr, UDP, src 1701, dst
I-Port
Inbound-3: From R-IPAddr, to I-IPAddr, UDP, src Any-Port, dst
I-Port
The Inbound-1 filter for the initiator will be injected by IKE
upon successful completion of the phase 2 negotiations
initiated by the peer.
Responder Filters:
Outbound-1: From R-IPAddr, to I-IPAddr, UDP, src R-Port, dst
I-Port
Outbound-2: From R-IPAddr, to I-IPAddr, UDP, src 1701, dst
I-Port
Inbound-1: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst
R-Port
Inbound-2: From I-IPAddr, to R-IPAddr, UDP, src I-Port, dst
1701
Inbound-3: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst
1701Once the negotiations have completed, the SCCRP is sent and the L2TP tunnel can complete establishment 🏁. After the L2TP tunnel has been established, any residual SAs and their associated filters may be deleted 🧹.
4.2.5. Gateway-gateway and L2TP Dial-out considerations 🤙
In the gateway-gateway or the L2TP dial-out scenario, either side may initiate L2TP 🔄. The process outlined in the previous steps should be followed, with one addition. The initial filter set at both sides MUST include the following filter:
Inbound Filter:
1: From Any-Addr, to R-IPAddr1, UDP, src Any-Port, dst 1701When either peer decides to start a tunnel, L2TP should inject the necessary inbound and outbound filters to protect the SCCRQ 🧚. Tunnel establishment then proceeds exactly as stated in the previous sections 💜.
5. Security Considerations 🔐
5.1. Authentication issues
IPsec IKE negotiation MUST negotiate an authentication method specified in the IKE RFC 2409 [7]. In addition to IKE authentication, L2TP implementations utilize PPP authentication methods, such as those described in [15]-[16]. In this section, we discuss authentication issues 🕵️♀️.
5.1.1. Differences between IKE and PPP authentication
While PPP provides initial authentication, it does not provide per-packet authentication, integrity or replay protection 😬. This implies that the identity verified in the initial PPP authentication is not subsequently verified on reception of each packet.
With IPsec, when the identity asserted in IKE is authenticated, the resulting derived keys are used to provide per-packet authentication, integrity and replay protection ✨. As a result, the identity verified in the IKE conversation is subsequently verified on reception of each packet.
Let us assume that the identity claimed in PPP is a user identity, while the identity claimed within IKE is a machine identity. Since only the machine identity is verified on a per-packet basis, there is no way to verify that only the user authenticated within PPP is using the tunnel 🚨. In fact, IPsec implementations that only support machine authentication typically have no way to enforce traffic segregation. As a result, where machine authentication is used, once an L2TP/IPsec tunnel is opened, any user on a multi-user machine will typically be able to send traffic down the tunnel 💀.
If the IPsec implementation supports user authentication, this problem can be averted 🙌. In this case, the user identity asserted within IKE will be verified on a per-packet basis. In order to provide segregation of traffic between users when user authentication is used, the client MUST ensure that only traffic from that particular user is sent down the L2TP tunnel 🫶.
5.1.2. Certificate authentication in IKE
When X.509 certificate authentication is chosen within IKE, the LNS is expected to use an IKE Certificate Request Payload (CRP) to request from the client a certificate issued by a particular certificate authority, or may use several CRPs if several certificate authorities are trusted and configured in its IPsec IKE authentication policy 📜.
The LNS SHOULD be able to trust several certificate authorities, so that tunnel client end-points can connect to it using their own certificate credential from their chosen PKI 🎟️. Client and server side certificate revocation list checking MAY be enabled on a per-CA basis, since differences in revocation list checking exist between different PKI providers 🔎.
L2TP implementations MAY use dynamically assigned ports for both source and destination ports only if security for each source and destination port combination can be successfully negotiated by IKE 🌸.
5.1.3. Machine versus user certificate authentication in IKE ✨
okay so the certificate credentials the L2TP client shows during the IKE negotiation MAY belong to the machine OR to the L2TP user 💻🎀 when it's machine auth, the machine cert usually gets stored on the LAC and LNS during an enrollment process. when it's user certs, the user cert can live on the machine or on a smartcard 🪪
and here's the tea 🫖: a machine cert is only worth as much as how hard it is for an attacker to get one under false pretenses. so the enrollment process should be really strictly controlled 🔒 like, only admins should be able to enroll a machine with a machine cert. no randos 🙅♀️
smartcards make it way less likely the private key gets leaked, BUT they're not always the move 💅 some orgs use machine certs specifically to block non-approved hardware. and since user auth can happen inside PPP (remember the weaknesses we talked about earlier, bestie 🙈), support for machine auth in IPsec means you can authenticate the machine AND the user. dual assurance, iconic 👑
so if that double check is valuable to you, letting the machine cert move from one box to another (which would be totally possible if it sat on a smartcard) might be a bad idea 🚫
same vibe for user certs: the user enrollment process should be locked down too 🔐 if a user's password can easily get you a cert (temporary or long-term), then that cert is literally no more secure than the password itself 💀 to stop an attacker from grabbing a user cert off a stolen password, you can limit the enrollment period and then turn off password access after it ends ⏰ that way, someone who swipes the password of an unused account can't get a user cert once enrollment is closed. not me being impressed by that 😭🌸
5.1.4. Pre-shared keys in IKE 🗝️
ok this one is a whole drama 🎭 using pre-shared keys in IKE main mode is vulnerable to man-in-the-middle attacks in remote access situations 😱 in main mode, SKEYID_e has to be used before the identification payload shows up, so the pre-shared key can only be picked based on info in the IP header. but in remote access, IP addresses are usually assigned dynamically, so you often can't figure out the right pre-shared key from the IP address alone 🤷♀️
so when pre-shared keys are used for remote access, one key ends up shared by a whole group of users and it stops being an effective shared secret 🥲 neither the client nor the server identifies itself during IKE phase 1. all anyone knows is that both sides belong to the group that has the pre-shared key. which means literally anyone with the group key can act as a man-in-the-middle 👀
this doesn't happen in aggressive mode, because the identity payload goes out earlier, so the pre-shared key can be chosen based on identity ✨ BUT in aggressive mode the user identity gets exposed, and that's often seen as a no-go 🙅♀️
so where main mode is used with pre-shared keys, the server isn't authenticated unless PPP does mutual authentication 🫠 that lets a rogue server holding the group pre-shared key pretend to be the LNS and run a dictionary attack on legacy auth methods like CHAP [15]. that could crack a bunch of passwords at once 😭 and this vulnerability shows up in some existing IPsec tunnel mode implementations, so yikes 💀
to dodge this, L2TP/IPsec implementations SHOULD NOT use a group pre-shared key for IKE authentication to the LNS 🚫 and the IKE pre-shared authentication key values SHOULD be protected the same way as the user's account password used by L2TP 🔐 treat those keys like they're your password, fr fr 🫶
5.2. IPsec and PPP security interactions 💅
when L2TP is protected with IPsec, you get both PPP and IPsec security services 🎀 which ones get negotiated depends on whether the tunnel is compulsory or voluntary 🦋 there's a detailed breakdown of both scenarios below. just so you know, these scenarios are non-normative, so they don't create requirements for an implementation to count as L2TP security compliant ✨
in the scenarios below, we're assuming both L2TP clients and servers can set and get the properties of IPsec security associations, and can also influence which IPsec security services get negotiated 🧠 they can also influence the negotiation process for PPP encryption and compression 🗜️
5.2.1. Compulsory tunnel 🌈
in a compulsory tunnel, the client sends PPP frames to the LAC and usually has no idea the frames are being tunneled 🙈 or that any security services are running between the LAC and LNS. when a data packet hits the LNS, it's a PPP frame wrapped in L2TP, which is wrapped in an IP packet 📦 by checking the properties of the SA set up between the LNS and the LAC, the LNS can learn what security services are in place between itself and the LAC 🔍 so in the compulsory case, the client and the LNS have unequal knowledge of the security services between them 👀
since the LNS can tell whether confidentiality, authentication, integrity and replay protection are in place between itself and the LAC, it can use that to change how it behaves during PPP ECP [10] and CCP [9] negotiation 🧩 let's say the LNS confidentiality policy is one of these: "Require Encryption," "Allow Encryption" or "Prohibit Encryption." if IPsec confidentiality is in place, an LNS with a "Prohibit Encryption" policy acts like the policy got violated 🚨 and an LNS with "Require Encryption" or "Allow Encryption" acts like those policies are satisfied, so it wouldn't require PPP encryption or compression 💁♀️ this isn't the same as insisting PPP encryption and compression get turned off, since that call depends on client policy 🫶
the client has no idea what security is between the LAC and the LNS, and it might not trust the LAC or the wire between itself and the LAC 😤 so the client will usually want to make sure it's secure enough with end-to-end IPsec or PPP encryption/compression between itself and the LNS 🔐
a client that wants security across the entire travel path wouldn't change this behavior, even if it knew what security was between the LAC and LNS 🌸 it negotiates confidentiality with the LNS to get privacy on the wire between itself and the LAC, and it negotiates end-to-end security with the end-station to keep the LNS-to-end-station part confidential too 💜
the client usually won't trust the LAC, so it negotiates confidentiality and compression on its own 💅 that means the LAC might only want to negotiate IPsec ESP with null encryption with the LNS, and the LNS will ask for replay protection 🔁 this way confidentiality and compression don't get doubled up over the LAC-to-LNS path, which is way better for LAC scalability since encryption is handled by the client and the LNS 🎉
the client has two ways to get the confidentiality it wants 🧚 if it knows every end-station it talks to is IPsec-capable (or it just refuses to talk to non-IPsec end-stations), it can skip PPP encryption/compression and negotiate IPsec ESP with the end-stations instead 🔥 if it doesn't know that all its end-stations are IPsec capable (the most likely case, tbh 😩), it negotiates PPP encryption/compression. that might double up the compression/encryption, which only goes away if PPP compression/encryption can be turned off per packet 🙃 and since the LNS knows the client's packets are being tunneled but the client doesn't, the LNS can make sure stateless compression/encryption gets used by offering stateless methods during ECP and CCP negotiations, if those are available 🍓✨
5.2.2. Voluntary tunnel ✨
okay so bestie, in a voluntary tunnel the client sends L2TP packets to the NAS, and the NAS routes them on to the LNS 🧚. Over a dialup link, those L2TP packets get wrapped in IP and PPP. If the client can retrieve the properties of its Security Association with the LNS, it knows every security service negotiated between them. It also knows about the PPP encryption/compression services negotiated with the NAS 💅.
From the LNS side, it just sees a PPP frame inside L2TP, which is inside an IP packet. Honestly that is exactly the compulsory tunneling vibe 🙈. If the LNS retrieves the properties of the Security Association it set up with the client, it can find out what security services are in place too. So in voluntary tunneling, the client and the LNS have symmetric knowledge of the security between them 👯.
Since the LNS can tell whether confidentiality, authentication, integrity check, or replay protection is in place between itself and the client, it can use that to change its PPP ECP and CCP negotiation stance. If IPsec confidentiality is in place, the LNS can act as though a "Require Encryption" directive had been fulfilled. That means it doesn't mandate PPP encryption or compression. Typically, the LNS won't insist that PPP encryption/compression be turned off either. It leaves that choice to the client 🫶.
The client has the same knowledge about its LNS connection. So if IPsec ESP is already in place, it can act as though a "Require Encryption" directive was fulfilled, and ask that PPP encryption and compression not be negotiated. If IP compression can't be negotiated, it's usually a good idea to turn off PPP compression when there's no stateless method available, because stateful PPP compression can get messy 💀.
So in the voluntary tunneling case, the client and LNS can typically skip PPP encryption and compression, and negotiate IPsec Confidentiality, Authentication, and Integrity protection instead, plus IP Compression if it's available ✨.
This may result in duplicate encryption if the client is talking to an IPsec-capable end-station. To avoid duplicate encryption/compression, the client may negotiate two Security Associations with the LNS: one with ESP using null encryption, and one with confidentiality/compression. Packets headed to an IPsec-capable end-station run over the ESP null-encryption Security Association, and packets headed to a non-IPsec-capable end-station run over the other one. Heads up 👀: many IPsec implementations can't pull this off without letting L2TP packets on the same tunnel come from multiple UDP ports. That requires changes to the L2TP specification 🦋.
Also, the client may want confidentiality for non-tunneled packets traveling between itself and the NAS. That protects it against eavesdropping on the wire between itself and the NAS 🔒. So it may want to negotiate PPP encryption and compression with the NAS. As in compulsory tunneling, this results in duplicate encryption and possibly compression, unless PPP compression/encryption can be turned off on a per-packet basis.
6. References 📚
[1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol L2TP", RFC 2661, August 1999.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[5] Piper, D., "The Internet IP Security Domain of Interpretation of ISAKMP", RFC 2407, November 1998.
[6] Atkinson, R. and S. Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[7] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[8] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[9] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[10] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC 1968, June 1996.
[11] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol (DESE)", RFC 1969, June 1996.
[12] Sklower, K. and G. Meyer, "The PPP DES Encryption Protocol, Version 2 (DESE-bis)", RFC 2419, September 1998.
[13] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", RFC 2420, September 1998.
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, November 1998.
[15] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994, August 1996.
[16] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)," RFC 2284, March 1998.
[17] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
Acknowledgments 💖
Big thanks to Gurdeep Singh Pall, David Eitelbach, Peter Ford, and Sanjay Anand of Microsoft, John Richardson of Intel, and Rob Adams of Cisco 🫶. They all had really useful discussions about this problem space, and that made the whole thing better.
Authors' Addresses 🎀
Baiju V. Patel Intel Corp 2511 NE 25th Ave Hillsboro, OR 97124
Phone: +1 503 702 2303 EMail: baiju.v.patel@intel.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Phone: +1 425 706-6605 EMail: bernarda@microsoft.com
William Dixon Microsoft Corporation One Microsoft Way Redmond, WA 98052
Phone: +1 425 703 8729 EMail: wdixon@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004
Phone: +1 425 438 8218 Fax: +1 425 438 1848 EMail: gwz@cisco.com
Skip Booth Cisco Systems 7025 Kit Creek Road RTP, NC 27709
Phone: +1 919 392 6951 EMail: ebooth@cisco.com
Appendix A: Example IPsec Filter sets for L2TP Tunnel Establishment 🧚
This section gives examples of IPsec filter sets for L2TP tunnel establishment. The examples are for IPv4, but similar ones could just as easily be built for IPv6 💅.
A.1 Initiator and Responder use fixed addresses and ports 🦋
This is the simplest case, since nothing changes during L2TP tunnel establishment. The initiator doesn't know whether the responder will change its port number, so it still has to be ready for that case 🙈. In this example, the initiator uses IPv4 address 1.1.1.1 and the responder uses IPv4 address 2.2.2.1.
The filters for this scenario are:
A.1.1 Protect the SCCRQ 🔥
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701
Responder Filters:
Outbound-1: None, dynamically injected when IKE Phase 2 completes
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701After IKE Phase 2 completes, the filters at the initiator and responder will be:
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701
Responder Filters:
Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 1701
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 1701, dst 1701
Inbound-2: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701A.2 Gateway to Gateway Scenario where Initiator and Responder use dynamic ports 🌈
In this scenario, either side is allowed to initiate the tunnel. Since dynamic ports get used, an extra phase 2 negotiation has to happen to protect the SCCRP sent from the responder to the initiator. Other than that extra phase 2 setup, the only other difference is that L2TP on the responder has to inject an additional filter into the IPsec database once the new port number is chosen.
This example also shows the additional filter the initiator needs to allow either side to start the tunnel. In either the dial-out or the gateway to gateway scenario, this additional filter is required 💜.
For this example, the dynamic port given to the initiator is 5000 and its IP address is 1.1.1.1. The responder uses IP address 2.2.2.1 and port number 6000.
The filters for this scenario are:
A.2.1 Initial Filters to allow either side to respond to negotiations 💌
In this case, both peers must be able to accept phase 2 negotiations from L2TP peers. My-IPAddr is defined as whatever IP address the device is willing to accept L2TP negotiations on.
Responder Filters present at both peers:
Inbound-1: From Any-Addr, to My-IPAddr, UDP, src Any-Port, dst 1701Note: The source IP in the inbound-1 filter above for gateway to gateway tunnels can be IP specific, such as 1.1.1.1, not necessarily Any-Addr.
A.2.2 Protect the SCCRQ, one peer is now the initiator 🎀
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 5000
Inbound-3: From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701
Responder Filters:
Outbound-1: None, dynamically injected when IKE Phase 2 completes
Inbound-1: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701After IKE Phase 2 completes, the filters at the initiator and responder will be:
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 5000
Inbound-3: From Any-Addr, to 1.1.1.1, UDP, src Any-Port, dst 1701
Responder Filters:
Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
Inbound-2: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701A.2.3 Protect the SCCRP after port change ✨
okay so now the responder knows which port number it's going to use 🦋 L2TP needs to inject fresh filters to match this new port assignment. the responder's filter set looks like this:
Responder Filters:
Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 6000, dst 5000
Outbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 6000
Inbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
Inbound-3: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701the second phase 2 kicks off once L2TP sends the SCCRP 💌 and when those phase 2 negotiations finish, the filter sets at both the initiator and the responder look like this:
Initiator Filters:
Outbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 6000
Outbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
Inbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 6000, dst 5000
Inbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
Inbound-3: From 2.2.2.1, to 1.1.1.1, UDP, src Any-Port, dst 1701
Responder Filters:
Outbound-1: From 2.2.2.1, to 1.1.1.1, UDP, src 6000, dst 5000
Outbound-2: From 2.2.2.1, to 1.1.1.1, UDP, src 1701, dst 5000
Inbound-1: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 6000
Inbound-2: From 1.1.1.1, to 2.2.2.1, UDP, src 5000, dst 1701
Inbound-3: From Any-Addr, to 2.2.2.1, UDP, src Any-Port, dst 1701once the L2TP tunnel is successfully up and running 🎉 the original phase 2 may be deleted. that also means the Inbound-2 and Outbound-2 filter statements can be removed too. literally so clean 🧹✨
Intellectual Property Statement 💜
so the IETF doesn't take a position on whether any intellectual property or other rights claimed for this tech are valid or how far they reach 🙈 it also doesn't claim it went looking for any of those rights. if you want the IETF's procedures on rights for standards-track and standards-related docs, check BCP-11 📚 copies of rights claims that got submitted for publication, assurances about licenses, or the results of any attempt to get a general license for implementers or users can be requested from the IETF Secretariat 📬
the IETF also invites anyone who knows about copyrights, patents, patent applications, or other proprietary rights that might cover technology required to practice this standard to let them know. send that info to the IETF Executive Director 💅
Full Copyright Statement 🎀
Copyright (C) The Internet Society (2001). All Rights Reserved.
this document and translations of it can be copied and shared with others 🌸 and people can write derivative works that comment on or explain it, or help with implementing it, and publish and distribute those too, in whole or in part, with no real restrictions. the one catch is that the above copyright notice and this paragraph have to stay on all copies and derivative works 🫶 this document itself can't be modified in any way, like removing the copyright notice or references to the Internet Society or other Internet organizations. the exceptions are when it's needed for developing Internet standards (in which case the procedures for copyrights in the Internet Standards process have to be followed) or when it's needed to translate it into languages other than English 🌍
the limited permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns ♾️
this document and the information in it are provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 😭
Acknowledgement 🫶
funding for the RFC Editor function is currently provided by the Internet Society 💖
📦 where this page comes from
- ietf: rfc3193 2001-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms