Summary

  • RFC 3193 required IPsec ESP to protect L2TP control and data packets, but protection depended on coordinating IPsec selectors with an L2TP endpoint that could change its address or UDP port during tunnel setup.
  • IKE could authenticate a machine on every protected packet while PPP authenticated a user only at session setup; unless the client segregated traffic, packet integrity did not prove that only the intended user used the tunnel.

The clean version of a tunnel is a tube. Put traffic into one end, wrap it in security, and unwrap it at the other. RFC 3193 described something more awkward and therefore more useful: a secure L2TP tunnel was a live agreement among several pieces of state that did not learn the same facts at the same time.

L2TP carried PPP. It had its own tunnel setup, control messages, session state, keep-alives and teardown. It could use UDP port 1701, but it did not have to keep every source port fixed. A responder could select a different port while replying. The 2001 L2TP specification even allowed a responder to choose a different IP address. Those freedoms made sense to an application concerned with load balancing, endpoint choice or evolving socket state.

IPsec saw a different problem. Its Phase 2 negotiation described the traffic to protect using selectors: addresses, IP protocol and ports. The Security Association was not simply “security for whatever L2TP later decides.” It covered a negotiated set of packets. If L2TP changed the socket tuple while IPsec continued enforcing the old selectors, either legitimate tunnel traffic would fall outside the protected set or an overly broad filter would admit traffic that the tunnel had never chosen.

RFC 3193's central engineering move was to make the application disclose its evolving facts to the security layer. The initial filter had to exist before the first Start-Control-Connection-Request, or SCCRQ, was sent. If no suitable Phase 2 SA existed, sending that request should cause IKE to build one; if the SA could not be established, the packet had to be dropped. Once L2TP knew a dynamically chosen source port, it had to inject that information into the IPsec filter database. Once IKE completed Quick Mode, it could install the more specific filter associated with the SA.

This was not a cosmetic preference. The first control packet opened the tunnel. Sending it in the clear while promising to protect later traffic would leave the act that created the control relationship outside the relationship's security boundary. RFC 3193 therefore made “filter present before SCCRQ” a temporal condition, not merely a configuration recommendation.

The responder's freedom to move made the choreography harder. If it selected a new IP address, the RFC did not let it silently answer from somewhere else and ask IPsec to infer continuity. The responder had to use the original protected path to send a Stop-Control-Connection-Notification with a general error and “Try Another,” carrying the new address. The initiator parsed and sanity-checked that address, installed new policy and established new Phase 1 and Phase 2 SAs before sending a new SCCRQ. A change of peer address was represented as a controlled restart with new cryptographic state.

A port change followed a different sequence. The responder could choose a new UDP source port before sending its SCCRP, but L2TP then had to inject new filters and the responder had to initiate another Phase 2 negotiation. The initiating side had already allowed for a possible port change with a broader inbound setup rule; the completed exchange narrowed the protected path to the socket that the tunnel actually selected. Residual setup SAs and filters could be removed after establishment.

These details explain why “UDP 1701 plus IPsec” was not a sufficient description. The protected object moved from an initial rendezvous tuple to a negotiated tunnel tuple. At each step, L2TP possessed application state that IKE did not invent. IKE possessed an authenticated SA result that L2TP had to inspect rather than assume. RFC 3193 joined those observations through explicit notifications and filter injection.

It also joined their lifecycles without collapsing them. PPP could end gracefully with LCP termination. L2TP could close its control connection or detect a failed peer with hellos. IKE could receive a Phase 1 or Phase 2 delete. When the L2TP tunnel disappeared, remaining SAs created for it should be deleted and delete messages should be sent. When IKE learned that the peer had deleted security state, it was supposed to notify L2TP. Only after the relevant acknowledgement could tunnel state and associated filters be removed safely.

The word “should” matters. The RFC described cooperative cleanup across components, not one atomic database transaction. An L2TP tunnel record, an IKE Phase 1 association, one or more Phase 2 SAs and the installed filters were separate objects. A good implementation could coordinate their removal; a log showing that one object vanished could not, by itself, prove that every related object had vanished.

The same separation appeared in packet reception. For a tunnel requiring security, L2TP had two mandatory checks. First, it checked that IPsec had decrypted or authenticated the packet. That established that the packet arrived through the expected SA rather than in the clear. Second, it checked that the packet's IP addresses and UDP ports matched the socket information used to create the L2TP tunnel. A trusted peer could still send a protected packet toward the wrong tunnel. Cryptographic membership and application-context membership were separate tests.

Encapsulation also had a physical cost. PPP commonly assumed a 1500-byte receive unit, while L2TP and IPsec added headers. RFC 3193 proposed passing the interface MTU minus this overhead down to PPP before LCP negotiation. If IPsec later learned a smaller path MTU through ICMP, it should store that value in the SA and notify L2TP so the PPP-facing value could change. Here again, the security layer's observation was not useful to the carried protocol until it crossed an explicit interface.

Compression exposed a similar mismatch. L2TP was connection-oriented, but packet ordering over IP was not mandatory. Stateful compression or encryption could amplify a single loss because later packets depended on state that the receiver no longer shared. The RFC preferred stateless methods for this setting. “There is a tunnel” did not mean the path behaved like a reliable ordered byte stream.

The most important boundary, however, was identity.

PPP authentication and IKE authentication could answer different questions. PPP might authenticate a user at the start of a session. IKE might authenticate the machine that owned a credential and then derive keys used to verify every protected packet. Per-packet verification was stronger evidence about continued possession of the IKE key, but it did not inherit an identity that IKE had never asserted.

RFC 3193 made the consequence explicit. Suppose PPP asserted a user identity while IKE asserted a machine identity. On a multi-user machine, an IPsec implementation that authenticated only the machine typically could not enforce traffic segregation among local users. Once the L2TP/IPsec tunnel was open, another user on that machine might be able to send traffic through it. The packet could be authentic, integral and replay-protected under the machine's SA while still lacking proof that the PPP-authenticated user originated it.

User authentication within IKE could narrow that gap, but only with an additional enforcement obligation: the client had to ensure that only traffic from that user entered the tunnel. A user certificate, an authenticated IKE identity and a packet protected under derived keys were still not self-executing isolation. Local traffic selection was part of the security claim.

The RFC's certificate discussion therefore concerned enrollment and custody as well as cryptography. An LNS might trust several certification authorities. Revocation checking could differ by CA. Machine enrollment had to be controlled because a machine certificate was only as meaningful as the process that issued it. User certificates stored on smartcards reduced one private-key risk but could undermine a policy intended to bind access to approved hardware. A credential's format did not decide what authority its issuance process conveyed.

Pre-shared keys made this even clearer. In remote access, clients often had dynamic addresses. Under IKE Main Mode, the responder might need the shared key before receiving an identity payload, so it could not select a unique key by user identity. Deployments could fall back to one group key. At that point, knowing the key proved group membership, not the identity of a particular client or server. Anyone who obtained the group key could impersonate the LNS in the relevant threat model and use the position to attack legacy PPP authentication. RFC 3193 advised implementations not to use a group pre-shared key to authenticate the LNS.

Aggressive Mode moved the identity early enough to select a key, but exposed the identity. Certificates scaled better, but depended on enrollment and trust configuration. The RFC did not offer one magic credential. It documented a choice among identity privacy, key selection, operational scale and issuance control.

Finally, the meaning of “the tunnel is protected” depended on where the tunnel began. In compulsory tunneling, the client sent PPP frames to a LAC and might not know that the LAC later wrapped them in L2TP and IPsec. The LNS could inspect the LAC–LNS SA; the client could not rely on that protection for the wire between itself and the LAC. Client and LNS had unequal knowledge.

In voluntary tunneling, the client itself originated L2TP and could inspect the SA to the LNS. Client and LNS could share knowledge of the protection between them and adjust PPP encryption or compression accordingly. Even then, traffic beyond the LNS was a different segment. The RFC said at the beginning what its diagrams could not change: L2TP tunnel security was not end-to-end security.

That restraint is the historical value of RFC 3193. It did not merely add an encryption label to a tunneling protocol. It specified where application state had to enter security policy, where security results had to return to the application, and which identities remained outside each receipt. The tunnel worked because its layers exchanged bounded facts—not because one layer was allowed to impersonate the rest.