RADIUS Attributes for Tunnel Protocol Support
RFC 2868
Document | Type |
RFC - Informational
(June 2000; Errata)
Updated by RFC 3575
Updates RFC 2865
|
|
---|---|---|---|
Authors | Ignacio Goyret , John Shriver , Matt Holdrege , Glen Zorn , Dory Leifer , Allan Rubens | ||
Last updated | 2020-01-21 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 2868 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group G. Zorn Request for Comments: 2868 Cisco Systems, Inc. Updates: RFC 2865 D. Leifer Category: Informational A. Rubens Ascend Communications J. Shriver Intel Corporation M. Holdrege ipVerse I. Goyret Lucent Technologies June 2000 RADIUS Attributes for Tunnel Protocol Support Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks. 1. Motivation Many applications of tunneling protocols such as L2TP involve dial-up network access. Some, such as the provision of access to corporate intranets via the Internet, are characterized by voluntary tunneling: the tunnel is created at the request of the user for a specific purpose. Other applications involve compulsory tunneling: the tunnel is created without any action from the user and without allowing the user any choice in the matter. In order to provide this functionality, new RADIUS attributes are needed to carry the tunneling information from the RADIUS server to the tunnel end points; this document defines those attributes. Specific recommendations for, and examples of, the application of these attributes for L2TP can be found in RFC 2809. Zorn, et al. Informational [Page 1] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 2. Specification of Requirements In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [14]. 3. Attributes Multiple instances of each of the attributes defined below may be included in a single RADIUS packet. In this case, the attributes to be applied to any given tunnel SHOULD all contain the same value in their respective Tag fields; otherwise, the Tag field SHOULD NOT be used. If the RADIUS server returns attributes describing multiple tunnels then the tunnels SHOULD be interpreted by the tunnel initiator as alternatives and the server SHOULD include an instance of the Tunnel-Preference Attribute in the set of Attributes pertaining to each alternative tunnel. Similarly, if the RADIUS client includes multiple sets of tunnel Attributes in an Access-Request packet, all the Attributes pertaining to a given tunnel SHOULD contain the same value in their respective Tag fields and each set SHOULD include an appropriately valued instance of the Tunnel-Preference Attribute. 3.1. Tunnel-Type Description This Attribute indicates the tunneling protocol(s) to be used (in the case of a tunnel initiator) or the the tunneling protocol in use (in the case of a tunnel terminator). It MAY be included in Access-Request, Access-Accept and Accounting-Request packets. If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel initiator, it SHOULD be taken as a hint to the RADIUS server as to the tunnelling protocols supported by the tunnel end-point; the RADIUS server MAY ignore the hint, however. A tunnel initiator is not required to implement any of these tunnel types; if a tunnel initiator receives an Access-Accept packet which contains only unknown or unsupported Tunnel-Types, the tunnel initiator MUST behave as though an Access-Reject had been received instead. If the Tunnel-Type Attribute is present in an Access-Request packet sent from a tunnel terminator, it SHOULD be taken to signify the tunnelling protocol in use. In this case, if the RADIUS server determines that the use of the communicated protocol is not authorized, it MAY return an Access-Reject packet. If a tunnel terminator receives an Access-Accept packet which contains Zorn, et al. Informational [Page 2] RFC 2868 RADIUS Tunnel Authentication Attributes June 2000 one or more Tunnel-Type Attributes, none of which represent theShow full document text