Implementation of L2TP Compulsory Tunneling via RADIUS
RFC 2809
| Document | Type | RFC - Informational (April 2000) | |
|---|---|---|---|
| Authors | Glen Zorn , Dr. Bernard D. Aboba | ||
| Last updated | 2013-03-02 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| IESG | Responsible AD | (None) | |
| Send notices to | (None) |
RFC 2809
sent an LCP CONFACK completing LCP negotiation, and the client and NAS MUST NOT have begun NCP negotiation. Rather than sending an LCP CONFACK, the NAS will instead send an LCP Configure-Request packet, described in [6]. The Client MAY then renegotiate LCP, and from that point forward, all PPP packets originated from the client will be encapsulated and sent to the tunnel server. When LCP re-negotiation has been concluded, the NCP phase will begin, and the tunnel server will assign an address to the client. If L2TP is being used as the tunnel protocol, the NAS MAY in its initial setup notification include a copy of the LCP CONFACKs sent in each direction which completed LCP negotiation. The tunnel server MAY then use this information to avoid an additional LCP negotiation. With L2TP, the initial setup notification can also include the authentication information required to allow the tunnel server to authenticate the user and decide to accept or decline the connection. However, this facility creates a vulnerability to replay attacks, and can create problems in the case where the NAS and tunnel server authenticate against different RADIUS servers. As a result, where user-based tunneling via RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be employed. In performing the PPP authentication, the tunnel server can access its own user database, or it MAY send a RADIUS Access-Request. After the tunnel has been brought up, the NAS and tunnel server can start accounting. The interactions involved in initiation of a compulsory tunnel with dual authentication are summarized below. Aboba & Zorn Informational [Page 14] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 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 ENDIF Aboba & Zorn Informational [Page 15] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 5. Termination sequence The tear down of a compulsory tunnel involves an interaction between the client, NAS and Tunnel Server. This interaction is virtually identical regardless of whether telephone-number based authentication, single authentication, or dual authentication is being used. In any of the cases, the following events occur: Tunnel Server to NAS: L2TP Call-Clear-Request (optional) NAS to Tunnel Server: L2TP Call-Disconnect-Notify Tunnel termination can occur due to a client request (PPP termination), a tunnel server request (Call-Clear-Request), or a line problem (call disconnect). In the case of a client-requested termination, the tunnel server MUST terminate the PPP session. The tunnel server MUST subsequently send a Call-Clear-Request to the NAS. The NAS MUST then send a Call- Disconnect-Notify message to the tunnel server, and will disconnect the call. The NAS MUST also respond with a Call-Disconnect-Notify message and disconnection if it receives a Call-Clear-Request from the tunnel server without a client-requested termination. In the case of a line problem or user hangup, the NAS MUST send a Call-Disconnect-Notify to the tunnel server. Both sides will then tear down the call. The interactions involved in termination of a compulsory tunnel are summarized below. In order to simplify the diagram that follows, we have left out the client. However, it is understood that the client MAY participate via PPP termination and disconnection. Aboba & Zorn Informational [Page 16] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 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 ENDIF 6. Use of distinct RADIUS servers In the case that the NAS and the tunnel server are using distinct RADIUS servers, some interesting cases can arise in the provisioning of compulsory tunnels. 6.1. Distinct userIDs If distinct RADIUS servers are being used, it is likely that distinct userID/password pairs will be required to complete the RADIUS and tunnel authentications. One pair will be used in the initial PPP authentication with the NAS, and the second pair will be used for authentication at the tunnel server. This has implications if the NAS attempts to forward authentication information to the tunnel server in the initial setup notification. Since the userID/password pair used for tunnel authentication is different from that used to authenticate against the NAS, forwarding authentication information in this manner will cause the tunnel authentication to fail. As a result, where user-based tunneling via RADIUS is implemented, L2TP authentication forwarding SHOULD NOT be employed. Aboba & Zorn Informational [Page 17] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 In order to provide maximum ease of use in the case where the userID/password pairs are identical, tunnel clients typically attempt authentication with the same userID/password pair as was used in the initial PPP negotiation. Only after this fails do they prompt the user for the second pair. Rather than putting up an error message indicating an authentication failure, it is preferable to present a dialog requesting the tunnel userID/password combination. A similar issue arises when extended authentication methods are being used, as is enabled by EAP, described in [5]. In particular, when one-time passwords or cryptographic calculators are being used, different passwords will be used for the first and second authentications. Thus the user will need to be prompted to enter the second password. 6.2. Multilink PPP issues It is possible for the two RADIUS servers to return different Port- Limit attributes. For example, it is conceivable that the NAS RADIUS server will only grant use of a single channel, while the tunnel RADIUS server will grant more than one channel. In this case, the correct behavior is for the tunnel client to open a connection to another NAS in order to bring up a multilink bundle on the tunnel server. The client MUST NOT indicate to the NAS that this additional link is being brought up as part of a multilink bundle; this will only be indicated in the subsequent negotiation with the tunnel server. It is also conceivable that the NAS RADIUS server will allow the client to bring up multiple channels, but that the tunnel RADIUS server will allow fewer channels than the NAS RADIUS server. In this case, the client should terminate use of the excess channels. 7. UserID Issues In the provisioning of roaming and shared use networks, one of the requirements is to be able to route the authentication request to the user's home RADIUS server. This authentication routing is accomplished based on the userID submitted by the user to the NAS in the initial PPP authentication. The userID is subsequently relayed by the NAS to the RADIUS server in the User-Name attribute, as part of the RADIUS Access-Request. Similarly, [2] refers to use of the userID in determining the tunnel endpoint, although it does not provide guidelines for how RADIUS or tunnel routing is to be accomplished. Thus the possibility of conflicting interpretations exists. Aboba & Zorn Informational [Page 18] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 The use of RADIUS in provisioning of compulsory tunneling relieves the userID from having to do double duty. Rather than being used both for routing of the RADIUS authentication/authorization request as well for determination of the tunnel endpoint, the userID is now used solely for routing of RADIUS authentication/authorization requests. Tunnel attributes returned in the RADIUS Access-Response are then used to determine the tunnel endpoint. Since the framework described in this document allows both ISPs and tunnel users to authenticate users as well as to account for resources consumed by them, and provides for maintenance of two distinct userID/password pairs, this scheme provides a high degree of flexibility. Where RADIUS proxies and tunneling are employed, it is possible to allow the user to authenticate with a single userID/password pair at both the NAS and the tunnel endpoint. This is accomplished by routing the NAS RADIUS Access-Request to the same RADIUS server used by the tunnel server. 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. Aboba & Zorn Informational [Page 19] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 9. Security Considerations In PPP-based tunneling, PPP security is negotiated between the client and the tunnel server, and covers the entire length of the path. This is because the client does not have a way to know that they are being tunneled. Thus, any security the NAS may negotiate with the tunnel server will occur in addition to that negotiated between the client and NAS. In L2TP compulsory tunneling, this means that PPP encryption and compression will be negotiated between the client and the tunnel server. In addition, the NAS may bring up an IPSEC security association between itself and the tunnel server. This adds protection against a number of possible attacks. Where RADIUS proxies are deployed, the Access-Reply sent by the RADIUS server may be processed by one or more proxies prior to being received by the NAS. In order to ensure that tunnel attributes arrive without modification, intermediate RADIUS proxies forwarding the Access-Reply MUST NOT modify tunnel attributes. If the RADIUS proxy does not support tunnel attributes, then it MUST send an Access-Reject to the NAS. This is necessary to ensure that the user is only granted access if the services requested by the RADIUS server can be provided. Since RADIUS tunnel attributes are used for compulsory tunneling, address assignment is handled by the tunnel server rather than the NAS. As a result, if tunnel attributes are present, the NAS MUST ignore any address assignment attributes sent by the RADIUS server. In addition, the NAS and client MUST NOT begin NCP negotiation, since this could create a time window in which the client will be capable of sending packets to the transport network, which is not permitted in compulsory tunneling. 10. Acknowledgements Thanks to Gurdeep Singh Pall of Microsoft for many useful discussions of this problem space, and 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 performed while Glen Zorn was employed by the Microsoft Corporation. Aboba & Zorn Informational [Page 20] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 11. Chair's Address The RADIUS Working Group can be contacted via 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 Aboba & Zorn Informational [Page 21] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 13. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Aboba & Zorn Informational [Page 22] RFC 2809 L2TP Compulsory Tunneling via RADIUS April 2000 14. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is 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. Aboba & Zorn Informational [Page 23]