rfc2809.txt

radius服务器

   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: [phone]
   EMail: [e-mail]

12.  Authors' Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   Phone: [phone]
   EMail: [e-mail]


   Glen Zorn
   Cisco Systems, Inc.
   500 108th Avenue N.E., Suite 500
   Bellevue, WA 98004
   USA

   Phone: [phone]
   FAX:   [phone]
   EMail: [e-mail]



















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]