RFC 2809
Implementation of L2TP Compulsory Tunneling via RADIUS
RFC 2809: Implementation of L2TP Compulsory Tunneling via RADIUS 🎀
- Network Working Group 💖
- Written by B. Aboba (Microsoft) and G. Zorn (Cisco) ✨
- Category: Informational 🦋
- Date: April 2000 🌸
- Obsoletes and updates: the header doesn't list anything it obsoletes or updates 🧚
Status of this Memo ✨
okay so first things first, this memo is giving informational. It's for the Internet community to read, it does NOT specify an Internet standard of any kind 💅 Distribution is unlimited, so share it with everyone bestie 🫶
Copyright Notice 🌈
Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒
Abstract 🦋
this doc talks about the implementation issues that pop up when you set up compulsory tunneling in dial-up networks using the L2TP protocol 🌸 You can get that setup by integrating RADIUS with tunneling protocols. Issues with other tunneling protocols? Those get their own separate documents, not this one 💅
1. Terminology 💜
let's get the vocab down first, bestie 📚
- Voluntary Tunneling: the user creates the tunnel, usually by using a tunneling client 🎀
- Compulsory Tunneling: the tunnel gets created with zero action from the user, and the user gets zero choice in the matter 😭
- Tunnel Network Server: a server that terminates a tunnel. In L2TP lingo, this is the L2TP Network Server (LNS) 🍓
- Network Access Server: the Network Access Server (NAS) is the device clients contact to get onto the network 🌐 In L2TP terms, a NAS doing compulsory tunneling is called the L2TP Access Concentrator (LAC) ✨
- RADIUS authentication server: a server that handles authentication and authorization using the protocol described in [1] 🔐
- RADIUS proxy: this exists so RADIUS authentication requests can be routed. To the NAS, the RADIUS proxy acts like a RADIUS server, and to the RADIUS server, it acts like a RADIUS client 🔁 It can also be used to locate the tunnel endpoint when realm-based tunneling is in use 🧚
2. Requirements language 🎀
in this doc, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT" get interpreted as described in [4]. So if you see those capitals, they're doing the official BCP 14 job 💅
3. Introduction 💖
okay this part sets the scene, and it's so relatable 🌸 Tons of tunneling protocol applications involve dial-up network access. Some of them, like giving someone secure access to corporate intranets over the Internet, are voluntary tunneling. That's when the user asks for the tunnel for a specific purpose 🦋 Others use compulsory tunneling, where the tunnel shows up with no action from the user and no choice for them either 😭
Examples of compulsory tunnel apps are Internet software upgrade servers, software registration servers, and banking services 💳 Without compulsory tunneling, these would probably run on dedicated networks, or at least dedicated network access servers (NAS), since they need to limit user access to specific hosts 🙈
But here's the twist: once compulsory tunneling is widely supported, these services could be reached through any Internet service provider (ISP) 🌈 The most popular way to authorize dial-up users today is the RADIUS protocol 👑 RADIUS lets the dial-up users' authorization and authentication data live in one central place, instead of on each NAS 🧚 Making sense, right? It makes sense to use RADIUS to centrally administer compulsory tunneling, because RADIUS is widely deployed and was built to carry exactly this kind of info 🔥 New RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the NAS, and those attributes are defined in [3] ✨
3.1. Advantages of RADIUS-based compulsory tunneling 💜
so the current ways to route tunnel requests are static tunneling and realm-based tunneling 🗺️ Static tunneling sends all users automatically to one given endpoint. Realm-based tunneling figures out the tunnel endpoint from the realm portion of the userID. User-based tunneling, which comes from integrating RADIUS with tunnel protocols, has big advantages over both of those 👑
Static tunneling needs a NAS device dedicated to the job 😬 For an ISP, that's a problem, because they'd have to dedicate a NAS to tunneling for a given customer, instead of using the existing NASes they already have out in the field. So static tunneling is likely to be costly for deploying a global service 💸
Realm-based tunneling assumes every user in a given realm wants to be treated the same way 🙃 That limits flexibility in account management, and that's a vibe-killer 💀 For example, BIGCO might want to give Janet an account that allows access to both the Internet and the intranet, with her intranet access provided by a tunnel server in the engineering department 💼 But BIGCO might want Fred to have an account that only gives him intranet access, with his intranet access provided by a tunnel network server in the sales department 🫠 Realm-based tunneling can't handle that situation. User-based tunneling, enabled by the attributes defined in [3], totally can 🙌
4. Authentication alternatives 🦋
RADIUS-based compulsory tunneling can support both single authentication and dual authentication 🔐 With single authentication, the user gets authenticated at the NAS or the tunnel server. With dual authentication, the user gets authenticated at both the NAS and the tunnel server. When single authentication is supported, there are a few modes, including telephone-number based authentication 📞 When dual authentication is used, the modes include dual CHAP authentications; CHAP/EAP authentication; CHAP/PAP(token) authentication; and EAP/EAP authentication, using the same EAP type for both authentications. EAP is described in [5] 🧁
The alternatives are described in more detail below 👀
4.1. Single authentication 🌸
Single authentication alternatives include:
- NAS authentication
- NAS authentication with RADIUS reply forwarding
- Tunnel server authentication
4.1.1. NAS authentication 💖
so with this approach, authentication and authorization (including the tunneling info) happen once, at the NAS 🎯 The perks: it blocks network access for unauthorized NAS users, and it lets accounting happen at the NAS 💅 The downsides: the tunnel server has to trust the NAS, since no user authentication happens at the tunnel server 😬 Without user authentication, accounting can't happen at the tunnel server with strong assurance that the correct party is getting billed 🧾
NAS-only authentication usually goes hand in hand with LCP forwarding and tunnel authentication, and L2TP supports both of those, as described in [2] 🎀 So the tunnel server can be set up to accept all calls coming in through authenticated tunnels, without needing PPP authentication. BUT this approach isn't compatible with roaming, because the tunnel server will typically only be set up to accept tunnels from a restricted set of NASes 🙅♀️ A typical initiation sequence looks like this:
Client and NAS: Call Connected
Client and NAS: PPP LCP negotiation
Client and NAS: PPP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: NCP negotiationthe process starts with an incoming call to the NAS, plus the PPP LCP negotiation between the client and the NAS 📞 To authenticate the client, the NAS sends a RADIUS Access-Request to the RADIUS server, and it gets back either a RADIUS Access-Accept that includes tunnel attributes, or an Access-Reject 🔑
If an L2TP tunnel is indicated, the NAS brings up a control connection if there wasn't one already, and then the NAS and tunnel server bring up the call 🚀 Right then, data starts flowing through the tunnel 🌊 The NAS typically uses LCP forwarding, though the tunnel server can also renegotiate LCP 🔄 If LCP renegotiation is going to be allowed, the NAS SHOULD NOT send an LCP CONFACK to complete LCP negotiation. Instead of a CONFACK, the NAS sends an LCP Configure-Request packet, described in [6] 📦 The Client MAY then renegotiate LCP, and from that point on, every PPP packet from the client gets encapsulated and sent to the tunnel server 🎁
Address assignment happens at the tunnel server, so the client and NAS MUST NOT begin NCP negotiation. NCP negotiation happens between the client and the tunnel server instead 🫶
4.1.2. NAS authentication with RADIUS reply forwarding 🍓
with this approach, authentication and authorization happen once at the NAS, and the RADIUS reply gets forwarded to the tunnel server 💌 The good stuff: it blocks network access for unauthorized NAS users, it doesn't require trust between the NAS and the tunnel server, and accounting can happen at both ends of the tunnel 🙌 The catch is that both ends have to share the same secret with the RADIUS server, since that's the only way the tunnel server can check the RADIUS Access-Reply 🔐
In this approach, the tunnel server shares secrets with all the NASes and their associated RADIUS servers, and there's no provision for the tunnel server to renegotiate LCP. The tunnel server also needs to know how to handle and verify RADIUS Access-Accept messages 🧠
This scheme can work if the reply comes directly from a RADIUS server. But it gets unmanageable if a RADIUS proxy is involved, because the reply would be authenticated with the secret shared by the client and proxy, not the RADIUS server 😵 So honestly? This scheme is impractical 🙅♀️
4.1.2.1. Tunnel server authentication 🌈
in this scheme, authentication and authorization happen once at the tunnel server 🎯 For that to work, the NAS has to figure out that the user needs to be tunneled, either through RADIUS or through NAS configuration. When RADIUS is used, that determination can be made using one of the following methods:
- Telephone-number based authentication
- UserID
4.1.2.2. Telephone-number based authentication 📞💖
okay so using the Calling-Station-Id and Called-Station-Id RADIUS attributes, your authorization and tunnel attributes can be based on the phone number that started the call, or the number being called 🦋 the RADIUS server can authorize users by their calling phone number, or hand out tunnel attributes based on the Calling-Station-Id or Called-Station-Id. it's giving customizable ✨ and in L2TP, the tunnel server MAY choose to reject or accept the call based on the Dialed Number and Dialing Number inside the L2TP Incoming-Call-Request packet that the NAS sends. accounting can also happen based on the Calling-Station-Id and Called-Station-Id 📊
now the tea 🫖 RADIUS as defined in [1] requires that an Access-Request packet has a User-Name attribute AND either a CHAP-Password or User-Password attribute, and that password field must be non-empty 😭 so to get past that, the Called-Station-Id or Calling-Station-Id MAY be furnished in the User-Name attribute, and a dummy value MAY be used in the User-Password or CHAP-Password attribute. it's a workaround but it's a clever one 🧚
here's what a typical initiation sequence looks like when telephone-number based authentication is in play 🎀
Client and NS: Call Connected
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP negotiation
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiationthe process starts when a call comes into the NAS 📲 if it's set up for telephone-number based authentication, the NAS sends a RADIUS Access-Request containing the Calling-Station-Id and the Called-Station-Id attributes. then the RADIUS server replies with either a RADIUS Access-Accept or Access-Reject 💅
the NAS MUST NOT begin PPP authentication before bringing up the tunnel. 🚫 if the timing works out, the NAS MAY bring up the tunnel before it starts LCP negotiation with the peer 🌸 if it does that, then LCP doesn't have to be renegotiated between the peer and the tunnel server, and LCP forwarding doesn't need to be used either ✨
if the initial telephone-number based authentication doesn't work out, the RADIUS server sends a RADIUS Access-Reject. in that case, the NAS MUST send an LCP-Terminate and disconnect the user 💀
if the RADIUS Access-Accept has tunnel attributes in it and says it's an L2TP tunnel, the NAS is going to bring up a control connection (if there isn't already one) 🔌 it does this by sending an L2TP Start-Control-Connection-Request message to the tunnel server, and the tunnel server answers with an L2TP Start-Control-Connection-Reply. now, if that reply shows an error, OR if the control connection gets terminated at any point later on, then the NAS MUST send an LCP-Terminate and disconnect the user. no exceptions bestie 🙅♀️
next up, the NAS sends an L2TP Incoming-Call-Request message to the tunnel server. this message includes the Call Serial Number, and that, together with the NAS-IP-Address and Tunnel-Server-Endpoint, is what uniquely identifies the call 🔑 the tunnel server replies with an L2TP Incoming-Call-Reply message. if that reply indicates an error, the NAS MUST send an LCP-Terminate and disconnect the user. if no error shows up, the NAS replies with an L2TP Incoming-Call-Connected message 🎉
at this point, data can start flowing through the tunnel 🌊 if LCP negotiation had already started between the NAS and the client, then LCP forwarding may be employed, or else the client and tunnel server will renegotiate LCP and start PPP authentication. otherwise, the client and tunnel server negotiate LCP for the very first time, and then move on to PPP authentication 🫶
if a renegotiation is needed, then when it starts, the NAS SHOULD NOT have sent an LCP CONFACK that completes LCP negotiation, and the client and NAS MUST NOT have begun NCP negotiation 🙈 instead of sending an LCP CONFACK, the NAS sends an LCP Configure-Request Packet, which is described in [6]. the Client MAY then renegotiate LCP, and from that point on, every PPP packet from the client gets encapsulated and sent to the tunnel server 🦋 once LCP re-negotiation is wrapped up, the NCP phase begins, and the tunnel server assigns an address to the client 🎀
if L2TP is the tunnel protocol and LCP renegotiation is required, the NAS MAY include a copy of the LCP CONFACKs sent in each direction (the ones that completed LCP negotiation) in its initial setup notification. the tunnel server MAY then use that info to skip an extra LCP negotiation. with L2TP, the initial setup notification can also carry the authentication information the tunnel server needs to authenticate the user and decide whether to accept or decline the connection. BUT (and this is a big but) in telephone-number based authentication, PPP authentication MUST NOT occur before the NAS brings up the tunnel, so L2TP authentication forwarding MUST NOT be employed 🚨
when it's time for the PPP authentication, the tunnel server can check its own user database, or it can send a RADIUS Access-Request instead 🗂️ the second option is handy when authentication forwarding is turned on, like with roaming or shared-use networks. in that setup, the RADIUS and tunnel servers belong to the same administration and usually sit close together, maybe even on the same LAN 🏠 so having the tunnel server act as a RADIUS client gives you unified user administration, which is honestly so clean 🧹 also, the tunnel server's RADIUS Access-Request usually goes straight to the local RADIUS server instead of getting forwarded through a proxy 📮
here's a summary of the initiation interactions for a compulsory tunnel with telephone-number based authentication 🧚♀️ to keep the diagram simple, we left out the client, but just know the client is still in the picture, doing PPP negotiation, authentication, and data exchange with the Tunnel Server 💜
INITIATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call connected
Send RADIUS
Access-Request
with Called-Station-Id,
and/or Calling-Station-Id
LCP starts
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting4.1.2.3. User-Name 🎀
okay so, authentication only happens at the tunnel-server, which means tunnel initiation has to happen before the user gets checked at the NAS 😭. That's why this scheme usually leans on either the domain part of the userID or attribute-specific processing on the RADIUS server 💅. And since the NAS never verifies who the user is, the tunnel server owner either has to be down to get billed for every incoming call, or something like the Calling-Station-Id has to be used to verify the user's identity for accounting 🧚.
Attribute-specific processing is where RADIUS comes in, and an attribute is used to signal tunnel initiation ✨. For example, tunnel attributes can be sent back if the User-Password attribute contains a dummy value (such as "tunnel" or "L2TP"). Another option is a userID that begins with a special character ('*') to say "hey, start a tunnel" 🦋. When attribute-specific processing is used, the tunnel server might need to renegotiate LCP.
Then there's the domain portion approach, where all users in domain X get tunneled to address Y 🌸. It supports compulsory tunneling, but it doesn't give you user-based tunneling, so it's a bit of a limited vibe.
For the NAS to start accounting on the connection, it would need to use the identity the user claimed when authenticating to the tunnel server, since it never checked that identity via RADIUS 🙈. But here's the catch: for that to actually be useful for accounting, the tunnel endpoint needs an account relationship with the NAS owner. So even if a user has an account with the NAS owner, they can't use that account for tunneling unless the tunnel endpoint also has a business relationship with the NAS owner. Basically, this approach is incompatible with roaming 💀.
A typical initiation sequence using the domain portion of the userID looks like this 🍓:
Client and NAS: Call Connected
Client and NAS: PPP LCP negotiation
Client and NAS: Authentication
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP re-negotiation
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiationThe process starts with an incoming call to the NAS, plus the PPP LCP negotiation between the Client and NAS 📞. Then authentication begins, and based on the domain portion of the userID, the NAS brings up a control connection if there wasn't one already, and the NAS and tunnel server bring up the call 🔥. At this point, data MAY begin to flow through the tunnel. The client and tunnel server MAY now renegotiate LCP and finish PPP authentication 🫶.
When that renegotiation kicks off, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP negotiation, and the client and NAS MUST NOT have started NCP negotiation 🙅♀️. Instead of an LCP CONFACK, the NAS sends an LCP Configure-Request packet, described in [6]. The Client MAY then renegotiate LCP, and from that point on, every PPP packet from the client gets encapsulated and sent to the tunnel server 🦋. In single authentication compulsory tunneling, L2TP authentication forwarding MUST NOT be employed 🚫. Once LCP renegotiation wraps up, the NCP phase begins, and the tunnel server assigns an address to the client 🌈.
When it comes to PPP authentication, the tunnel server can check its own user database, or it MAY send a RADIUS Access-Request 🧠. Once the tunnel is up, the NAS and tunnel server can start accounting ✨.
The interactions are summarized below 👑:
INITIATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
Authentication
phase starts
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
ENDIF
IF no control
connection exists
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting4.2. Dual authentication 💅
In this scheme, authentication happens at both the NAS and the tunnel server 👯. That means the dial-up client has to handle dual authentication, with all the LCP re-negotiations that come with it 😤. To let the NAS and tunnel network server check against the same database, the tunnel network server needs RADIUS client capability, and the NAS end possibly needs a RADIUS proxy 🫠.
Now for the good stuff. Dual authentication gives you support for authentication and accounting at both ends of the tunnel 📊. You get to use a single userID/password pair through RADIUS on the tunnel network server 🔑. And you don't need telephone-number based authentication or attribute-specific processing on the RADIUS server 🙌.
Dual authentication creates accounting records on both the NAS and tunnel server ends, so auditing is totally possible 🕵️♀️. Plus, the tunnel endpoint doesn't need an account relationship with the NAS owner, which makes this approach compatible with roaming 🌍.
But it isn't all sunshine. Unless LCP forwarding is used, LCP will need to be renegotiated 🥲. Some clients don't support it at all, and others only support a subset of the dual authentication combinations. The feasible combinations are PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP, CHAP/EAP, EAP/CHAP, and EAP/EAP. EAP is described in [5] 📚.
For a dual authentication, a typical initiation sequence looks like this 🎀:
Client and NAS: PPP LCP negotiation
Client and NAS: PPP authentication
NAS to RADIUS Server: RADIUS Access-request
RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
NAS to Tunnel Server: L2TP Incoming-Call-Request
Tunnel Server to NAS: L2TP Incoming-Call-Reply
NAS to Tunnel Server: L2TP Incoming-Call-Connected
Client and Tunnel Server: PPP LCP re-negotiation (optional)
Client and Tunnel Server: PPP authentication
Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
Client and Tunnel Server: NCP negotiationThe process starts with an incoming call to the NAS 📞. The client and NAS then kick off LCP negotiation, and after that the PPP authentication phase starts. The NAS sends a RADIUS Access-Request message to the RADIUS server 📨. If authentication succeeds, the RADIUS server replies with a RADIUS Access-Accept containing tunnel attributes ✅.
If an L2TP tunnel is indicated, the NAS brings up a control connection if there isn't one yet, and the NAS and tunnel server bring up the call 🚀. Data MAY start flowing through the tunnel at this point. The client and tunnel server MAY now renegotiate LCP and go through another round of PPP authentication 🔁. When that renegotiation begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP negotiation, and the client and NAS MUST NOT have started NCP negotiation 🙅♀️. The NAS sends an LCP Configure-Request packet instead of an LCP CONFACK, as described in [6]. The Client MAY then renegotiate LCP, and from then on, all PPP packets from the client are encapsulated and sent to the tunnel server 🦋. Once LCP re-negotiation is done, the NCP phase begins, and the tunnel server assigns an address to the client 🌸.
If L2TP is the tunnel protocol, the NAS MAY include a copy of the LCP CONFACKs sent in each direction that completed LCP negotiation in its initial setup notification ✨. The tunnel server MAY then use that info to skip an extra LCP negotiation 🧠. With L2TP, the initial setup notification can also carry the authentication information the tunnel server needs to authenticate the user and decide whether to accept or decline the connection 🔐.
⚠️ Heads up, bestie: this facility creates a vulnerability to replay attacks 😱. It can also cause problems when the NAS and tunnel server authenticate against different RADIUS servers. So where user-based tunneling via RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be employed 🚨.
When it comes to PPP authentication, the tunnel server can check its own user database, or it MAY send a RADIUS Access-Request 🗝️. After the tunnel is up, the NAS and tunnel server can start accounting 📈.
The interactions involved in starting a compulsory tunnel with dual authentication are summarized below 🧚♀️:
INITIATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
Call accepted
LCP starts
PPP authentication
phase starts
Send RADIUS
Access-Request
with userID and
authentication data
IF authentication
succeeds
Send ACK
ELSE Send NAK
IF NAK DISCONNECT
ELSE
IF no control
connection exists
Send
Start-Control-Connection-Request
to Tunnel Server
Send
Start-Control-Connection-Reply
to NAS
ENDIF
Send
Incoming-Call-Request
message to Tunnel Server
Send Incoming-Call-Reply
to NAS
Send
Incoming-Call-Connected
message to Tunnel Server
Send data through the tunnel
Re-negotiate LCP,
authenticate user,
bring up IPCP,
start accounting
ENDIF5. Termination sequence ✨
okay so tearing down a compulsory tunnel is a whole group project 🫶 the client, the NAS, and the Tunnel Server all have to coordinate. and the vibe is basically identical whether you're using telephone-number based authentication, single authentication, or dual authentication. 💅 these are the events that happen in every case:
Tunnel Server to NAS: L2TP Call-Clear-Request (optional)
NAS to Tunnel Server: L2TP Call-Disconnect-NotifySo a teardown can start three ways: the client asks to end things (PPP termination) 🙅♀️, the tunnel server asks to end things (Call-Clear-Request) 📞, or something goes wrong on the line (call disconnect) 💔.
If the client is the one requesting termination, the tunnel server MUST terminate the PPP session 🧚. After that, the tunnel server MUST send a Call-Clear-Request to the NAS. Then the NAS MUST send a Call-Disconnect-Notify message to the tunnel server, and it will disconnect the call 💀.
And the NAS MUST also reply with a Call-Disconnect-Notify message and disconnect if it gets a Call-Clear-Request from the tunnel server when the client didn't ask for the termination. no cap, that's a whole plot twist 😭
If it's a line problem or the user hangs up, the NAS MUST send a Call-Disconnect-Notify to the tunnel server. Then both sides tear down the call together 🌸
Here's the termination summary. We left the client out of the diagram to keep it simple, but just know the client MAY take part through PPP termination and disconnection 🎀
TERMINATION SEQUENCE
NAS Tunnel Server RADIUS Server
--- ------------- -------------
IF user disconnected
send
Call-Disconnect-Notify
message to tunnel server
Tear down the call
stop accounting
ELSE IF client requests
termination
send
Call-Clear-Request
to the NAS
Send
Call-Disconnect-Notify
message to tunnel server
Disconnect the user
Tear down the call
stop accounting
ENDIF6. Use of distinct RADIUS servers 🔥
okay this is where it gets spicy 🌶️ if the NAS and the tunnel server each use their own RADIUS server, some interesting situations can come up when you're setting up compulsory tunnels.
6.1. Distinct userIDs 🪪
If you're using distinct RADIUS servers, it's pretty likely you'll need different userID/password pairs to finish the RADIUS and tunnel authentications. The first pair handles the initial PPP authentication with the NAS, and the second pair handles authentication at the tunnel server 💕
This matters if the NAS tries to forward authentication info to the tunnel server in the initial setup notification. Since the tunnel pair is different from the NAS pair, forwarding the info like that will make tunnel authentication fail 💀 So where user-based tunneling via RADIUS is in use, L2TP authentication forwarding SHOULD NOT be employed.
For maximum ease of use when the pairs are identical, tunnel clients usually try the same userID/password pair that was used in the initial PPP negotiation first 🥹 Only if that fails do they ask the user for the second pair. Honestly it's way better to show a dialog asking for the tunnel userID/password combo than to throw an authentication failure error at someone 🙈
A similar thing happens with extended authentication methods, like the ones EAP enables, described in [5]. Specifically, if you're using one-time passwords or cryptographic calculators, different passwords get used for the first and second authentications. So the user will need to be prompted to enter the second password 🔐
6.2. Multilink PPP issues 🧩
The two RADIUS servers might send back different Port-Limit attributes 👀 For example, the NAS RADIUS server might only grant a single channel while the tunnel RADIUS server grants more than one. In that case, the correct move is for the tunnel client to open a connection to another NAS so it can bring up a multilink bundle on the tunnel server. The client MUST NOT tell the NAS that this extra link is part of a multilink bundle, because that only gets indicated later in the negotiation with the tunnel server 🫣
It can also go the other way: the NAS RADIUS server lets the client bring up multiple channels, but the tunnel RADIUS server allows fewer than that. In this case, the client should stop using the excess channels 🦋
7. UserID Issues 🆔
When you're setting up roaming and shared use networks, you need to be able to route the authentication request to the user's home RADIUS server 🏠 That routing is done based on the userID the user submits to the NAS in the initial PPP authentication. The NAS then passes that userID along to the RADIUS server in the User-Name attribute, as part of the RADIUS Access-Request 📨
[2] also talks about using the userID to figure out the tunnel endpoint, but it doesn't explain how RADIUS or tunnel routing should actually work. So there's a real chance of conflicting interpretations 🙃
Using RADIUS for compulsory tunneling takes that double duty off the userID 🙌 It used to be used both to route the RADIUS authentication/authorization request AND to pick the tunnel endpoint. Now the userID is used ONLY for routing RADIUS authentication/authorization requests, and the tunnel attributes returned in the RADIUS Access-Response decide the tunnel endpoint. Main character energy ✨
Because this framework lets both ISPs and tunnel users authenticate people and account for the resources they use, AND it keeps two separate userID/password pairs, it's super flexible 💜 When RADIUS proxies and tunneling are both in play, the user can even authenticate with one single userID/password pair at both the NAS and the tunnel endpoint. That works by routing the NAS RADIUS Access-Request to the same RADIUS server the tunnel server uses 🎀
8. References 📚
[1] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and Palter, B., "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and Goyret, I., "RADIUS Attributes for Tunnel Protocol Support", Work in Progress.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Blunk, L. anf J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
9. Security Considerations 🚨
Okay this section is SERIOUS, bestie 😤 In PPP-based tunneling, PPP security is negotiated between the client and the tunnel server, and it covers the ENTIRE path 🛡️ The reason is that the client has no way of knowing it's being tunneled. So any security the NAS negotiates with the tunnel server happens ON TOP OF what's negotiated between the client and the NAS.
In L2TP compulsory tunneling, that means PPP encryption and compression get negotiated between the client and the tunnel server. The NAS can also bring up an IPSEC security association between itself and the tunnel server. That adds protection against a bunch of possible attacks 🔒
When RADIUS proxies are deployed, the Access-Reply from the RADIUS server might get processed by one or more proxies before the NAS receives it. To make sure tunnel attributes arrive without being changed, intermediate RADIUS proxies forwarding the Access-Reply MUST NOT modify tunnel attributes. And if a RADIUS proxy doesn't support tunnel attributes, it MUST send an Access-Reject to the NAS 🚫 This is what makes sure the user only gets access if the services the RADIUS server asked for can actually be provided.
Since RADIUS tunnel attributes drive compulsory tunneling, address assignment is handled by the tunnel server instead of the NAS 🧚 So if tunnel attributes are present, the NAS MUST ignore any address assignment attributes sent by the RADIUS server. On top of that, the NAS and client MUST NOT begin NCP negotiation. Why? Because that could open a window where the client can send packets to the transport network, and that's NOT allowed in compulsory tunneling 💀
10. Acknowledgements 🫶
Thanks to Gurdeep Singh Pall of Microsoft for lots of super useful chats about this problem space 💖 And thanks to Allan Rubens of Tut Systems and Bertrand Buclin of AT&T Labs Europe for their comments on this document 🌷
Most of the work on this document was done while Glen Zorn was working at Microsoft Corporation 💼
11. Chair's Address 📮
The RADIUS Working Group can be reached through the current chair 💌
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
Phone: +1 510-426-0770 EMail: cdr@livingston.com
12. Authors' Addresses 🖊️
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Phone: +1 425-936-6605 EMail: bernarda@microsoft.com
Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, WA 98004 USA
Phone: +1 425 438 8218 FAX: +1 425 438 1848 EMail: gwz@cisco.com
13. Intellectual Property Statement ⚖️
Okay, legal stuff, but it's important 🧾 The IETF doesn't take a position on whether any intellectual property or other rights claimed to cover the technology in this document are valid or in scope, or whether any license to those rights might or might not be available. It also doesn't say it has tried to find any such rights. Info about the IETF's rules for rights in standards-track and standards-related documentation is in BCP-11. Copies of rights claims that were made available for publication, plus any assurances of licenses that will be made available, or the results of an attempt to get a general license or permission for implementers or users of this spec, can be obtained from the IETF Secretariat 📬
The IETF invites anyone interested to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that might cover technology required to practice this standard 🌈 Please send that info to the IETF Executive Director 💜
14. Full Copyright Statement 💖
Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀
Okay so the Internet Society owns this doc, but they're super generous about sharing ✨ You can copy this document and hand it to other people, and you can make derivative works that comment on it, explain it, or help you implement it. You can publish and distribute those too, in whole or in part, with no restrictions of any kind, as long as the copyright notice and this paragraph are included on every copy and derivative work. 🫶
The one catch is that this document itself may not be modified in any way. That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. 🙈 The exceptions are when it's needed for developing Internet standards, where the procedures for copyrights defined in the Internet Standards process must be followed, or when it's translated into languages other than English. 🌈
The limited permissions above are perpetual, and the Internet Society or its successors or assigns will not revoke them. Forever and ever 🦋💜
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. 💀 Read the fine print, bestie!
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society. 👑
📦 where this page comes from
- ietf: rfc2809 2000-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms