RADIUS Attributes for Tunnel Protocol Support
RFC 2868

Document Type RFC - Informational (June 2000; Errata)
Updated by RFC 3575
Updates RFC 2865
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html 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