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 the
Show full document text