7 Network Working Group B. Aboba
8 Request for Comments: 2809 Microsoft
9 Category: Informational G. Zorn
14 Implementation of L2TP Compulsory Tunneling via RADIUS
18 This memo provides information for the Internet community. It does
19 not specify an Internet standard of any kind. Distribution of this
24 Copyright (C) The Internet Society (2000). All Rights Reserved.
28 This document discusses implementation issues arising in the
29 provisioning of compulsory tunneling in dial-up networks using the
30 L2TP protocol. This provisioning can be accomplished via the
31 integration of RADIUS and tunneling protocols. Implementation issues
32 encountered with other tunneling protocols are left to separate
38 In voluntary tunneling, a tunnel is created by the user,
39 typically via use of a tunneling client.
42 In compulsory tunneling, a tunnel is created without any
43 action from the user and without allowing the user any
47 This is a server which terminates a tunnel. In L2TP
48 terminology, this is known as the L2TP Network Server
58 Aboba & Zorn Informational [Page 1]
60 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
64 The Network Access Server (NAS) is the device that clients
65 contact in order to get access to the network. In L2TP
66 terminology, a NAS performing compulsory tunneling is
67 referred to as the L2TP Access Concentrator (LAC).
69 RADIUS authentication server
70 This is a server which provides for
71 authentication/authorization via the protocol described in
75 In order to provide for the routing of RADIUS
76 authentication requests, a RADIUS proxy can be employed.
77 To the NAS, the RADIUS proxy appears to act as a RADIUS
78 server, and to the RADIUS server, the proxy appears to act
79 as a RADIUS client. Can be used to locate the tunnel
80 endpoint when realm-based tunneling is used.
82 2. Requirements language
84 In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
85 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
90 Many applications of tunneling protocols involve dial-up network
91 access. Some, such as the provisioning of secure access to corporate
92 intranets via the Internet, are characterized by voluntary tunneling:
93 the tunnel is created at the request of the user for a specific
94 purpose. Other applications involve compulsory tunneling: the tunnel
95 is created without any action from the user and without allowing the
98 Examples of applications that might be implemented using compulsory
99 tunnels are Internet software upgrade servers, software registration
100 servers and banking services. These are all services which, without
101 compulsory tunneling, would probably be provided using dedicated
102 networks or at least dedicated network access servers (NAS), since
103 they are characterized by the need to limit user access to specific
106 Given the existence of widespread support for compulsory tunneling,
107 however, these types of services could be accessed via any Internet
108 service provider (ISP). The most popular means of authorizing dial-
109 up network users today is through the RADIUS protocol. The use of
110 RADIUS allows the dial-up users' authorization and authentication
114 Aboba & Zorn Informational [Page 2]
116 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
119 data to be maintained in a central location, rather than on each NAS.
120 It makes sense to use RADIUS to centrally administer compulsory
121 tunneling, since RADIUS is widely deployed and was designed to carry
122 this type of information. New RADIUS attributes are needed to carry
123 the tunneling information from the RADIUS server to the NAS. Those
124 attributes are defined in [3].
126 3.1. Advantages of RADIUS-based compulsory tunneling
128 Current proposals for routing of tunnel requests include static
129 tunneling, where all users are automatically tunneled to a given
130 endpoint, and realm-based tunneling, where the tunnel endpoint is
131 determined from the realm portion of the userID. User-based tunneling
132 as provided by integration of RADIUS and tunnel protocols offers
133 significant advantages over both of these approaches.
135 Static tunneling requires dedication of a NAS device to the purpose.
136 In the case of an ISP, this is undesirable because it requires them
137 to dedicate a NAS to tunneling service for a given customer, rather
138 than allowing them to use existing NASes deployed in the field. As a
139 result static tunneling is likely to be costly for deployment of a
142 Realm-based tunneling assumes that all users within a given realm
143 wish to be treated the same way. This limits flexibility in account
144 management. For example, BIGCO may desire to provide Janet with an
145 account that allows access to both the Internet and the intranet,
146 with Janet's intranet access provided by a tunnel server located in
147 the engineering department. However BIGCO may desire to provide Fred
148 with an account that provides only access to the intranet, with
149 Fred's intranet access provided by a tunnel network server located in
150 the sales department. Such a situation cannot be accommodated with
151 realm-based tunneling, but can be accommodated via user-based
152 tunneling as enabled by the attributes defined in [3].
154 4. Authentication alternatives
156 RADIUS-based compulsory tunneling can support both single
157 authentication, where the user is authenticated at the NAS or tunnel
158 server, or dual authentication, where the user is authenticated at
159 both the NAS and the tunnel server. When single authentication is
160 supported, a variety of modes are possible, including telephone-
161 number based authentication. When dual-authentication is used, a
162 number of modes are available, including dual CHAP authentications;
170 Aboba & Zorn Informational [Page 3]
172 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
175 CHAP/EAP authentication; CHAP/PAP(token) authentication; and EAP/EAP
176 authentication, using the same EAP type for both authentications. EAP
179 The alternatives are described in more detail below.
181 4.1. Single authentication
183 Single authentication alternatives include:
186 NAS authentication with RADIUS reply forwarding
187 Tunnel server authentication
189 4.1.1. NAS authentication
191 With this approach, authentication and authorization (including
192 tunneling information) occurs once, at the NAS. The advantages of
193 this approach are that it disallows network access for unauthorized
194 NAS users, and permits accounting to done at the NAS. Disadvantages
195 are that it requires that the tunnel server trust the NAS, since no
196 user authentication occurs at the tunnel server. Due to the lack of
197 user authentication, accounting cannot take place at the tunnel
198 server with strong assurance that the correct party is being billed.
200 NAS-only authentication is most typically employed along with LCP
201 forwarding and tunnel authentication, both of which are supported in
202 L2TP, described in [2]. Thus, the tunnel server can be set up to
203 accept all calls occurring within authenticated tunnels, without
204 requiring PPP authentication. However, this approach is not
205 compatible with roaming, since the tunnel server will typically only
206 be set up to accept tunnels from a restricted set of NASes. A typical
207 initiation sequence looks like this:
209 Client and NAS: Call Connected
210 Client and NAS: PPP LCP negotiation
211 Client and NAS: PPP authentication
212 NAS to RADIUS Server: RADIUS Access-request
213 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
214 NAS to Tunnel Server: L2TP Incoming-Call-Request w/LCP forwarding
215 Tunnel Server to NAS: L2TP Incoming-Call-Reply
216 NAS to Tunnel Server: L2TP Incoming-Call-Connected
217 Client and Tunnel Server: NCP negotiation
226 Aboba & Zorn Informational [Page 4]
228 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
231 The process begins with an incoming call to the NAS, and the PPP LCP
232 negotiation between the client and the NAS. In order to authenticate
233 the client, the NAS will send a RADIUS Access-Request to the RADIUS
234 server and will receive a RADIUS Access-Accept including tunnel
235 attributes, or an Access-Reject.
237 In the case where an L2TP tunnel is indicated, the NAS will now bring
238 up a control connection if none existed before, and the NAS and
239 tunnel server will bring up the call. At this point, data will begin
240 to flow through the tunnel. The NAS will typically employ LCP
241 forwarding, although it is also possible for the tunnel server to
242 renegotiate LCP. If LCP renegotiation is to be permitted, the NAS
243 SHOULD NOT send an LCP CONFACK completing LCP negotiation. Rather
244 than sending an LCP CONFACK, the NAS will instead send an LCP
245 Configure-Request packet, described in [6]. The Client MAY then
246 renegotiate LCP, and from that point forward, all PPP packets
247 originated from the client will be encapsulated and sent to the
250 Since address assignment will occur at the tunnel server, the client
251 and NAS MUST NOT begin NCP negotiation. Instead, NCP negotiation will
252 occur between the client and the tunnel server.
254 4.1.2. NAS authentication with RADIUS reply forwarding
256 With this approach, authentication and authorization occurs once at
257 the NAS and the RADIUS reply is forwarded to the tunnel server. This
258 approach disallows network access for unauthorized NAS users; does
259 not require trust between the NAS and tunnel server; and allows for
260 accounting to be done at both ends of the tunnel. However, it also
261 requires that both ends share the same secret with the RADIUS server,
262 since that is the only way that the tunnel server can check the
265 In this approach, the tunnel server will share secrets with all the
266 NASes and associated RADIUS servers, and there is no provision for
267 LCP renegotiation by the tunnel server. Also, the tunnel server will
268 need to know how to handle and verify RADIUS Access-Accept messages.
270 While this scheme can be workable if the reply comes directly from a
271 RADIUS server, it would become unmanageable if a RADIUS proxy is
272 involved, since the reply would be authenticated using the secret
273 shared by the client and proxy, rather than the RADIUS server. As a
274 result, this scheme is impractical.
282 Aboba & Zorn Informational [Page 5]
284 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
287 4.1.2.1. Tunnel server authentication
289 In this scheme, authentication and authorization occurs once at the
290 tunnel server. This requires that the NAS determine that the user
291 needs to be tunneled (through RADIUS or NAS configuration). Where
292 RADIUS is used, the determination can be made using one of the
295 Telephone-number based authentication
298 4.1.2.2. Telephone-number based authentication
300 Using the Calling-Station-Id and Called-Station-Id RADIUS attributes,
301 authorization and subsequent tunnel attributes can be based on the
302 phone number originating the call, or the number being called. This
303 allows the RADIUS server to authorize users based on the calling
304 phone number or to provide tunnel attributes based on the Calling-
305 Station-Id or Called-Station-Id. Similarly, in L2TP the tunnel
306 server MAY choose to reject or accept the call based on the Dialed
307 Number and Dialing Number included in the L2TP Incoming-Call-Request
308 packet sent by the NAS. Accounting can also take place based on the
309 Calling-Station-Id and Called-Station-Id.
311 RADIUS as defined in [1] requires that an Access-Request packet
312 contain a User-Name attribute as well as either a CHAP-Password or
313 User-Password attribute, which must be non-empty. To satisfy this
314 requirement the Called-Station-Id or Calling-Station-Id MAY be
315 furnished in the User-Name attribute and a dummy value MAY be used in
316 the User-Password or CHAP-Password attribute.
318 In the case of telephone-number based authentication, a typical
319 initiation sequence looks like this:
321 Client and NS: Call Connected
322 NAS to RADIUS Server: RADIUS Access-request
323 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
324 NAS to Tunnel Server: L2TP Incoming-Call-Request
325 Tunnel Server to NAS: L2TP Incoming-Call-Reply
326 NAS to Tunnel Server: L2TP Incoming-Call-Connected
327 Client and Tunnel Server: PPP LCP negotiation
328 Client and Tunnel Server: PPP authentication
329 Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
330 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
331 Client and Tunnel Server: NCP negotiation
338 Aboba & Zorn Informational [Page 6]
340 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
343 The process begins with an incoming call to the NAS. If configured
344 for telephone-number based authentication, the NAS sends a RADIUS
345 Access-Request containing the Calling-Station-Id and the Called-
346 Station-Id attributes. The RADIUS server will then respond with a
347 RADIUS Access-Accept or Access-Reject.
349 The NAS MUST NOT begin PPP authentication before bringing up the
350 tunnel. If timing permits, the NAS MAY bring up the tunnel prior to
351 beginning LCP negotiation with the peer. If this is done, then LCP
352 will not need to be renegotiated between the peer and tunnel server,
353 nor will LCP forwarding need to be employed.
355 If the initial telephone-number based authentication is unsuccessful,
356 the RADIUS server sends a RADIUS Access-Reject. In this case, the NAS
357 MUST send an LCP-Terminate and disconnect the user.
359 In the case where tunnel attributes are included in the RADIUS
360 Access-Accept, and an L2TP tunnel is indicated, the NAS will now
361 bring up a control connection if none existed before. This is
362 accomplished by sending an L2TP Start-Control-Connection-Request
363 message to the tunnel server. The tunnel server will then reply with
364 an L2TP Start-Control-Connection-Reply. If this message indicates an
365 error, or if the control connection is terminated at any future time,
366 then the NAS MUST send an LCP-Terminate and disconnect the user.
368 The NAS will then send an L2TP Incoming-Call-Request message to the
369 tunnel server. Among other things, this message will contain the Call
370 Serial Number, which along with the NAS-IP-Address and Tunnel-
371 Server-Endpoint is used to uniquely identify the call. The tunnel
372 server will reply with an L2TP Incoming-Call-Reply message. If this
373 message indicates an error, then the NAS MUST send an LCP-Terminate
374 and disconnect the user. If no error is indicated, the NAS then
375 replies with an L2TP Incoming-Call-Connected message.
377 At this point, data can begin to flow through the tunnel. If LCP
378 negotiation had been begun between the NAS and the client, then LCP
379 forwarding may be employed, or the client and tunnel server will now
380 renegotiate LCP and begin PPP authentication. Otherwise, the client
381 and tunnel server will negotiate LCP for the first time, and then
382 move on to PPP authentication.
384 If a renegotiation is required, at the time that the renegotiation
385 begins, the NAS SHOULD NOT have sent an LCP CONFACK completing LCP
386 negotiation, and the client and NAS MUST NOT have begun NCP
387 negotiation. Rather than sending an LCP CONFACK, the NAS will
388 instead send an LCP Configure-Request Packet, described in [6]. The
389 Client MAY then renegotiate LCP, and from that point forward, all PPP
390 packets originated from the client will be encapsulated and sent to
394 Aboba & Zorn Informational [Page 7]
396 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
399 the tunnel server. When LCP re-negotiation has been concluded, the
400 NCP phase will begin, and the tunnel server will assign an address to
403 If L2TP is being used as the tunnel protocol, and LCP renegotiation
404 is required, the NAS MAY in its initial setup notification include a
405 copy of the LCP CONFACKs sent in each direction which completed LCP
406 negotiation. The tunnel server MAY then use this information to avoid
407 an additional LCP negotiation. With L2TP, the initial setup
408 notification can also include the authentication information required
409 to allow the tunnel server to authenticate the user and decide to
410 accept or decline the connection. However, in telephone-number based
411 authentication, PPP authentication MUST NOT occur prior to the NAS
412 bringing up the tunnel. As a result, L2TP authentication forwarding
413 MUST NOT be employed.
415 In performing the PPP authentication, the tunnel server can access
416 its own user database, or alternatively can send a RADIUS Access-
417 Request. The latter approach is useful in cases where authentication
418 forwarding is enabled, such as with roaming or shared use networks.
419 In this case, the RADIUS and tunnel servers are under the same
420 administration and are typically located close together, possibly on
421 the same LAN. Therefore having the tunnel server act as a RADIUS
422 client provides for unified user administration. Note that the tunnel
423 server's RADIUS Access-Request is typically sent directly to the
424 local RADIUS server rather than being forwarded via a proxy.
426 The interactions involved in initiation of a compulsory tunnel with
427 telephone-number based authentication are summarized below. In order
428 to simplify the diagram that follows, we have left out the client.
429 However, it is understood that the client participates via PPP
430 negotiation, authentication and subsequent data interchange with the
450 Aboba & Zorn Informational [Page 8]
452 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
457 NAS Tunnel Server RADIUS Server
458 --- ------------- -------------
462 with Called-Station-Id,
463 and/or Calling-Station-Id
474 Start-Control-Connection-Request
477 Start-Control-Connection-Reply
482 Incoming-Call-Request
483 message to Tunnel Server
484 Send Incoming-Call-Reply
487 Incoming-Call-Connected
488 message to Tunnel Server
490 Send data through the tunnel
506 Aboba & Zorn Informational [Page 9]
508 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
513 Since authentication will occur only at the tunnel-server, tunnel
514 initiation must occur prior to user authentication at the NAS. As a
515 result, this scheme typically uses either the domain portion of the
516 userID or attribute-specific processing on the RADIUS server. Since
517 the user identity is never verified by the NAS, either the tunnel
518 server owner must be willing to be billed for all incoming calls, or
519 other information such as the Calling-Station-Id must be used to
520 verify the user's identity for accounting purposes.
522 In attribute-specific processing RADIUS may be employed and an
523 attribute is used to signal tunnel initiation. For example, tunnel
524 attributes can be sent back if the User-Password attribute contains a
525 dummy value (such as "tunnel" or "L2TP"). Alternatively, a userID
526 beginning with a special character ('*') could be used to indicate
527 the need to initiate a tunnel. When attribute-specific processing is
528 used, the tunnel server may need to renegotiate LCP.
530 Another solution involves using the domain portion of the userID; all
531 users in domain X would be tunneled to address Y. This proposal
532 supports compulsory tunneling, but does not provide for user-based
535 In order for the NAS to start accounting on the connection, it would
536 need to use the identity claimed by the user in authenticating to the
537 tunnel server, since it did not verify the identity via RADIUS.
538 However, in order for that to be of any use in accounting, the tunnel
539 endpoint needs to have an account relationship with the NAS owner.
540 Thus even if a user has an account with the NAS owner, they cannot
541 use this account for tunneling unless the tunnel endpoint also has a
542 business relationship with the NAS owner. Thus this approach is
543 incompatible with roaming.
545 A typical initiation sequence involving use of the domain portion of
546 the userID looks like this:
548 Client and NAS: Call Connected
549 Client and NAS: PPP LCP negotiation
550 Client and NAS: Authentication
551 NAS to Tunnel Server: L2TP Incoming-Call-Request
552 Tunnel Server to NAS: L2TP Incoming-Call-Reply
553 NAS to Tunnel Server: L2TP Incoming-Call-Connected
554 Client and Tunnel Server: PPP LCP re-negotiation
555 Client and Tunnel Server: PPP authentication
556 Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
557 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
558 Client and Tunnel Server: NCP negotiation
562 Aboba & Zorn Informational [Page 10]
564 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
567 The process begins with an incoming call to the NAS, and the PPP LCP
568 negotiation between the Client and NAS. The authentication process
569 will then begin and based on the domain portion of the userID, the
570 NAS will now bring up a control connection if none existed before,
571 and the NAS and tunnel server will bring up the call. At this point,
572 data MAY begin to flow through the tunnel. The client and tunnel
573 server MAY now renegotiate LCP and will complete PPP authentication.
575 At the time that the renegotiation begins, the NAS SHOULD NOT have
576 sent an LCP CONFACK completing LCP negotiation, and the client and
577 NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP
578 CONFACK, the NAS will instead send an LCP Configure-Request packet,
579 described in [6]. The Client MAY then renegotiate LCP, and from that
580 point forward, all PPP packets originated from the client will be
581 encapsulated and sent to the tunnel server. In single authentication
582 compulsory tunneling, L2TP authentication forwarding MUST NOT be
583 employed. When LCP re-negotiation has been concluded, the NCP phase
584 will begin, and the tunnel server will assign an address to the
587 In performing the PPP authentication, the tunnel server can access
588 its own user database, or it MAY send a RADIUS Access-Request. After
589 the tunnel has been brought up, the NAS and tunnel server can start
618 Aboba & Zorn Informational [Page 11]
620 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
623 The interactions are summarized below.
627 NAS Tunnel Server RADIUS Server
628 --- ------------- -------------
636 Start-Control-Connection-Request
642 Start-Control-Connection-Reply
647 Incoming-Call-Request
648 message to Tunnel Server
649 Send Incoming-Call-Reply
652 Incoming-Call-Connected
653 message to Tunnel Server
655 Send data through the tunnel
661 4.2. Dual authentication
663 In this scheme, authentication occurs both at the NAS and the tunnel
664 server. This requires the dial-up client to handle dual
665 authentication, with attendant LCP re-negotiations. In order to allow
666 the NAS and tunnel network server to authenticate against the same
667 database, this requires RADIUS client capability on the tunnel
668 network server, and possibly a RADIUS proxy on the NAS end.
674 Aboba & Zorn Informational [Page 12]
676 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
679 Advantages of dual authentication include support for authentication
680 and accounting at both ends of the tunnel; use of a single
681 userID/password pair via implementation of RADIUS on the tunnel
682 network server; no requirement for telephone-number based
683 authentication, or attribute-specific processing on the RADIUS
686 Dual authentication allows for accounting records to be generated on
687 both the NAS and tunnel server ends, making auditing possible. Also
688 the tunnel endpoint does not need to have an account relationship
689 with the NAS owner, making this approach compatible with roaming.
691 A disadvantage of dual authentication is that unless LCP forwarding
692 is used, LCP will need to be renegotiated; some clients do not
693 support it at all, and others only support only a subset of the dual
694 authentication combinations. Feasible combinations include
695 PAP/PAP(token), PAP/CHAP, PAP/EAP, CHAP/PAP(token), CHAP/CHAP,
696 CHAP/EAP, EAP/CHAP, and EAP/EAP. EAP is described in [5].
698 In the case of a dual authentication, a typical initiation sequence
701 Client and NAS: PPP LCP negotiation
702 Client and NAS: PPP authentication
703 NAS to RADIUS Server: RADIUS Access-request
704 RADIUS server to NAS: RADIUS Access-Accept/Access-Reject
705 NAS to Tunnel Server: L2TP Incoming-Call-Request
706 Tunnel Server to NAS: L2TP Incoming-Call-Reply
707 NAS to Tunnel Server: L2TP Incoming-Call-Connected
708 Client and Tunnel Server: PPP LCP re-negotiation (optional)
709 Client and Tunnel Server: PPP authentication
710 Tunnel Server to RADIUS Server: RADIUS Access-request (optional)
711 RADIUS server to Tunnel Server: RADIUS Access-Accept/Access-Reject
712 Client and Tunnel Server: NCP negotiation
714 The process begins with an incoming call to the NAS. The client and
715 NAS then begin LCP negotiation. Subsequently the PPP authentication
716 phase starts, and the NAS sends a RADIUS Access-Request message to
717 the RADIUS server. If the authentication is successful, the RADIUS
718 server responds with a RADIUS Access-Accept containing tunnel
721 In the case where an L2TP tunnel is indicated, the NAS will now bring
722 up a control connection if none existed before, and the NAS and
723 tunnel server will bring up the call. At this point, data MAY begin
724 to flow through the tunnel. The client and tunnel server MAY now
725 renegotiate LCP and go through another round of PPP authentication.
726 At the time that this renegotiation begins, the NAS SHOULD NOT have
730 Aboba & Zorn Informational [Page 13]
732 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
735 sent an LCP CONFACK completing LCP negotiation, and the client and
736 NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP
737 CONFACK, the NAS will instead send an LCP Configure-Request packet,
738 described in [6]. The Client MAY then renegotiate LCP, and from that
739 point forward, all PPP packets originated from the client will be
740 encapsulated and sent to the tunnel server. When LCP re-negotiation
741 has been concluded, the NCP phase will begin, and the tunnel server
742 will assign an address to the client.
744 If L2TP is being used as the tunnel protocol, the NAS MAY in its
745 initial setup notification include a copy of the LCP CONFACKs sent in
746 each direction which completed LCP negotiation. The tunnel server MAY
747 then use this information to avoid an additional LCP negotiation.
748 With L2TP, the initial setup notification can also include the
749 authentication information required to allow the tunnel server to
750 authenticate the user and decide to accept or decline the connection.
751 However, this facility creates a vulnerability to replay attacks, and
752 can create problems in the case where the NAS and tunnel server
753 authenticate against different RADIUS servers. As a result, where
754 user-based tunneling via RADIUS is implemented, L2TP authentication
755 forwarding SHOULD NOT be employed.
757 In performing the PPP authentication, the tunnel server can access
758 its own user database, or it MAY send a RADIUS Access-Request. After
759 the tunnel has been brought up, the NAS and tunnel server can start
762 The interactions involved in initiation of a compulsory tunnel with
763 dual authentication are summarized below.
786 Aboba & Zorn Informational [Page 14]
788 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
793 NAS Tunnel Server RADIUS Server
794 --- ------------- -------------
812 Start-Control-Connection-Request
815 Start-Control-Connection-Reply
820 Incoming-Call-Request
821 message to Tunnel Server
822 Send Incoming-Call-Reply
825 Incoming-Call-Connected
826 message to Tunnel Server
828 Send data through the tunnel
842 Aboba & Zorn Informational [Page 15]
844 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
847 5. Termination sequence
849 The tear down of a compulsory tunnel involves an interaction between
850 the client, NAS and Tunnel Server. This interaction is virtually
851 identical regardless of whether telephone-number based
852 authentication, single authentication, or dual authentication is
853 being used. In any of the cases, the following events occur:
855 Tunnel Server to NAS: L2TP Call-Clear-Request (optional)
856 NAS to Tunnel Server: L2TP Call-Disconnect-Notify
858 Tunnel termination can occur due to a client request (PPP
859 termination), a tunnel server request (Call-Clear-Request), or a line
860 problem (call disconnect).
862 In the case of a client-requested termination, the tunnel server MUST
863 terminate the PPP session. The tunnel server MUST subsequently send a
864 Call-Clear-Request to the NAS. The NAS MUST then send a Call-
865 Disconnect-Notify message to the tunnel server, and will disconnect
868 The NAS MUST also respond with a Call-Disconnect-Notify message and
869 disconnection if it receives a Call-Clear-Request from the tunnel
870 server without a client-requested termination.
872 In the case of a line problem or user hangup, the NAS MUST send a
873 Call-Disconnect-Notify to the tunnel server. Both sides will then
876 The interactions involved in termination of a compulsory tunnel are
877 summarized below. In order to simplify the diagram that follows, we
878 have left out the client. However, it is understood that the client
879 MAY participate via PPP termination and disconnection.
898 Aboba & Zorn Informational [Page 16]
900 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
905 NAS Tunnel Server RADIUS Server
906 --- ------------- -------------
909 Call-Disconnect-Notify
910 message to tunnel server
913 ELSE IF client requests
919 Call-Disconnect-Notify
920 message to tunnel server
926 6. Use of distinct RADIUS servers
928 In the case that the NAS and the tunnel server are using distinct
929 RADIUS servers, some interesting cases can arise in the provisioning
930 of compulsory tunnels.
932 6.1. Distinct userIDs
934 If distinct RADIUS servers are being used, it is likely that distinct
935 userID/password pairs will be required to complete the RADIUS and
936 tunnel authentications. One pair will be used in the initial PPP
937 authentication with the NAS, and the second pair will be used for
938 authentication at the tunnel server.
940 This has implications if the NAS attempts to forward authentication
941 information to the tunnel server in the initial setup notification.
942 Since the userID/password pair used for tunnel authentication is
943 different from that used to authenticate against the NAS, forwarding
944 authentication information in this manner will cause the tunnel
945 authentication to fail. As a result, where user-based tunneling via
946 RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be
954 Aboba & Zorn Informational [Page 17]
956 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
959 In order to provide maximum ease of use in the case where the
960 userID/password pairs are identical, tunnel clients typically attempt
961 authentication with the same userID/password pair as was used in the
962 initial PPP negotiation. Only after this fails do they prompt the
963 user for the second pair. Rather than putting up an error message
964 indicating an authentication failure, it is preferable to present a
965 dialog requesting the tunnel userID/password combination.
967 A similar issue arises when extended authentication methods are being
968 used, as is enabled by EAP, described in [5]. In particular, when
969 one-time passwords or cryptographic calculators are being used,
970 different passwords will be used for the first and second
971 authentications. Thus the user will need to be prompted to enter the
974 6.2. Multilink PPP issues
976 It is possible for the two RADIUS servers to return different Port-
977 Limit attributes. For example, it is conceivable that the NAS RADIUS
978 server will only grant use of a single channel, while the tunnel
979 RADIUS server will grant more than one channel. In this case, the
980 correct behavior is for the tunnel client to open a connection to
981 another NAS in order to bring up a multilink bundle on the tunnel
982 server. The client MUST NOT indicate to the NAS that this additional
983 link is being brought up as part of a multilink bundle; this will
984 only be indicated in the subsequent negotiation with the tunnel
987 It is also conceivable that the NAS RADIUS server will allow the
988 client to bring up multiple channels, but that the tunnel RADIUS
989 server will allow fewer channels than the NAS RADIUS server. In this
990 case, the client should terminate use of the excess channels.
994 In the provisioning of roaming and shared use networks, one of the
995 requirements is to be able to route the authentication request to the
996 user's home RADIUS server. This authentication routing is
997 accomplished based on the userID submitted by the user to the NAS in
998 the initial PPP authentication. The userID is subsequently relayed by
999 the NAS to the RADIUS server in the User-Name attribute, as part of
1000 the RADIUS Access-Request.
1002 Similarly, [2] refers to use of the userID in determining the tunnel
1003 endpoint, although it does not provide guidelines for how RADIUS or
1004 tunnel routing is to be accomplished. Thus the possibility of
1005 conflicting interpretations exists.
1010 Aboba & Zorn Informational [Page 18]
1012 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
1015 The use of RADIUS in provisioning of compulsory tunneling relieves
1016 the userID from having to do double duty. Rather than being used both
1017 for routing of the RADIUS authentication/authorization request as
1018 well for determination of the tunnel endpoint, the userID is now used
1019 solely for routing of RADIUS authentication/authorization requests.
1020 Tunnel attributes returned in the RADIUS Access-Response are then
1021 used to determine the tunnel endpoint.
1023 Since the framework described in this document allows both ISPs and
1024 tunnel users to authenticate users as well as to account for
1025 resources consumed by them, and provides for maintenance of two
1026 distinct userID/password pairs, this scheme provides a high degree of
1027 flexibility. Where RADIUS proxies and tunneling are employed, it is
1028 possible to allow the user to authenticate with a single
1029 userID/password pair at both the NAS and the tunnel endpoint. This is
1030 accomplished by routing the NAS RADIUS Access-Request to the same
1031 RADIUS server used by the tunnel server.
1035 [1] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote
1036 Authentication Dial In User Service (RADIUS)", RFC 2138, April
1039 [2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
1040 Palter, B., "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
1043 [3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
1044 Goyret, I., "RADIUS Attributes for Tunnel Protocol Support",
1047 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1048 Levels", BCP 14, RFC 2119, March 1997.
1050 [5] Blunk, L. anf J. Vollbrecht, "PPP Extensible Authentication
1051 Protocol (EAP)", RFC 2284, March 1998.
1053 [6] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
1054 51, RFC 1661, July 1994.
1066 Aboba & Zorn Informational [Page 19]
1068 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
1071 9. Security Considerations
1073 In PPP-based tunneling, PPP security is negotiated between the client
1074 and the tunnel server, and covers the entire length of the path. This
1075 is because the client does not have a way to know that they are being
1076 tunneled. Thus, any security the NAS may negotiate with the tunnel
1077 server will occur in addition to that negotiated between the client
1080 In L2TP compulsory tunneling, this means that PPP encryption and
1081 compression will be negotiated between the client and the tunnel
1082 server. In addition, the NAS may bring up an IPSEC security
1083 association between itself and the tunnel server. This adds
1084 protection against a number of possible attacks.
1086 Where RADIUS proxies are deployed, the Access-Reply sent by the
1087 RADIUS server may be processed by one or more proxies prior to being
1088 received by the NAS. In order to ensure that tunnel attributes
1089 arrive without modification, intermediate RADIUS proxies forwarding
1090 the Access-Reply MUST NOT modify tunnel attributes. If the RADIUS
1091 proxy does not support tunnel attributes, then it MUST send an
1092 Access-Reject to the NAS. This is necessary to ensure that the user
1093 is only granted access if the services requested by the RADIUS server
1096 Since RADIUS tunnel attributes are used for compulsory tunneling,
1097 address assignment is handled by the tunnel server rather than the
1098 NAS. As a result, if tunnel attributes are present, the NAS MUST
1099 ignore any address assignment attributes sent by the RADIUS server.
1100 In addition, the NAS and client MUST NOT begin NCP negotiation, since
1101 this could create a time window in which the client will be capable
1102 of sending packets to the transport network, which is not permitted
1103 in compulsory tunneling.
1105 10. Acknowledgements
1107 Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions
1108 of this problem space, and to Allan Rubens of Tut Systems and
1109 Bertrand Buclin of AT&T Labs Europe for their comments on this
1112 Most of the work on this document was performed while Glen Zorn was
1113 employed by the Microsoft Corporation.
1122 Aboba & Zorn Informational [Page 20]
1124 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
1129 The RADIUS Working Group can be contacted via the current chair:
1132 Livingston Enterprises
1134 Pleasanton, California 94588
1136 Phone: +1 510-426-0770
1137 EMail: cdr@livingston.com
1139 12. Authors' Addresses
1142 Microsoft Corporation
1146 Phone: +1 425-936-6605
1147 EMail: bernarda@microsoft.com
1152 500 108th Avenue N.E., Suite 500
1156 Phone: +1 425 438 8218
1157 FAX: +1 425 438 1848
1158 EMail: gwz@cisco.com
1178 Aboba & Zorn Informational [Page 21]
1180 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
1183 13. Intellectual Property Statement
1185 The IETF takes no position regarding the validity or scope of any
1186 intellectual property or other rights that might be claimed to
1187 pertain to the implementation or use of the technology described in
1188 this document or the extent to which any license under such rights
1189 might or might not be available; neither does it represent that it
1190 has made any effort to identify any such rights. Information on the
1191 IETF's procedures with respect to rights in standards-track and
1192 standards-related documentation can be found in BCP-11. Copies of
1193 claims of rights made available for publication and any assurances of
1194 licenses to be made available, or the result of an attempt made to
1195 obtain a general license or permission for the use of such
1196 proprietary rights by implementors or users of this specification can
1197 be obtained from the IETF Secretariat.
1199 The IETF invites any interested party to bring to its attention any
1200 copyrights, patents or patent applications, or other proprietary
1201 rights which may cover technology that may be required to practice
1202 this standard. Please address the information to the IETF Executive
1234 Aboba & Zorn Informational [Page 22]
1236 RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000
1239 14. Full Copyright Statement
1241 Copyright (C) The Internet Society (2000). All Rights Reserved.
1243 This document and translations of it may be copied and furnished to
1244 others, and derivative works that comment on or otherwise explain it
1245 or assist in its implementation may be prepared, copied, published
1246 and distributed, in whole or in part, without restriction of any
1247 kind, provided that the above copyright notice and this paragraph are
1248 included on all such copies and derivative works. However, this
1249 document itself may not be modified in any way, such as by removing
1250 the copyright notice or references to the Internet Society or other
1251 Internet organizations, except as needed for the purpose of
1252 developing Internet standards in which case the procedures for
1253 copyrights defined in the Internet Standards process must be
1254 followed, or as required to translate it into languages other than
1257 The limited permissions granted above are perpetual and will not be
1258 revoked by the Internet Society or its successors or assigns.
1260 This document and the information contained herein is provided on an
1261 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1262 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1263 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1264 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1265 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1269 Funding for the RFC Editor function is currently provided by the
1290 Aboba & Zorn Informational [Page 23]