rfc2868.txt

This program is a RADIUS RFC-compliant daemon, which is derived from original Livingston Enterprise

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
      tunneling protocol in use, the tunnel terminator SHOULD behave as
      though an Access-Reject had been received instead.

   A summary of the Tunnel-Type Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |     Value
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Value (cont)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      64 for Tunnel-Type

   Length
      Always 6.

   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the Tag field is unused, it MUST be zero (0x00).

   Value
      The Value field is three octets and contains one of the following
      values, indicating the type of tunnel to be started.

   1      Point-to-Point Tunneling Protocol (PPTP) [1]
   2      Layer Two Forwarding (L2F) [2]
   3      Layer Two Tunneling Protocol (L2TP) [3]
   4      Ascend Tunnel Management Protocol (ATMP) [4]
   5      Virtual Tunneling Protocol (VTP)
   6      IP Authentication Header in the Tunnel-mode (AH) [5]
   7      IP-in-IP Encapsulation (IP-IP) [6]
   8      Minimal IP-in-IP Encapsulation (MIN-IP-IP) [7]
   9      IP Encapsulating Security Payload in the Tunnel-mode (ESP) [8]
   10     Generic Route Encapsulation (GRE) [9]
   11     Bay Dial Virtual Services (DVS)
   12     IP-in-IP Tunneling [10]








Zorn, et al.                 Informational                      [Page 3]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


3.2.  Tunnel-Medium-Type

   Description

      The Tunnel-Medium-Type Attribute indicates which transport medium
      to use when creating a tunnel for those protocols (such as L2TP)
      that can operate over multiple transports.  It MAY be included in
      both Access-Request and Access-Accept packets; if it is present in
      an Access-Request packet, it SHOULD be taken as a hint to the
      RADIUS server as to the tunnel media supported by the tunnel end-
      point.  The RADIUS server MAY ignore the hint, however.

   A summary of the Tunnel-Medium-Type Attribute format is given below.
   The fields are transmitted left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |      Tag      |    Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      65 for Tunnel-Medium-Type

   Length
      6

   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  Valid values for this field are 0x01 through 0x1F,
      inclusive.  If the Tag field is unused, it MUST be zero (0x00).

   Value
      The Value field is three octets and contains one of the values
      listed under "Address Family Numbers" in [14].  For the sake of
      convenience, a relevant excerpt of this list is reproduced below.

   1      IPv4 (IP version 4)
   2      IPv6 (IP version 6)
   3      NSAP
   4      HDLC (8-bit multidrop)
   5      BBN 1822
   6      802 (includes all 802 media plus Ethernet "canonical format")
   7      E.163 (POTS)
   8      E.164 (SMDS, Frame Relay, ATM)



Zorn, et al.                 Informational                      [Page 4]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


   9      F.69 (Telex)
   10     X.121 (X.25, Frame Relay)
   11     IPX
   12     Appletalk
   13     Decnet IV
   14     Banyan Vines
   15     E.164 with NSAP format subaddress

3.3.  Tunnel-Client-Endpoint

   Description

      This Attribute contains the address of the initiator end of the
      tunnel.  It MAY be included in both Access-Request and Access-
      Accept packets to indicate the address from which a new tunnel is
      to be initiated.  If the Tunnel-Client-Endpoint Attribute is
      included in an Access-Request packet, the RADIUS server should
      take the value as a hint; the server is not obligated to honor the
      hint, however.  This Attribute SHOULD be included in Accounting-
      Request packets which contain Acct-Status-Type attributes with
      values of either Start or Stop, in which case it indicates the
      address from which the tunnel was initiated.  This Attribute,
      along with the Tunnel-Server-Endpoint and Acct-Tunnel-Connection-
      ID attributes, may be used to provide a globally unique means to
      identify a tunnel for accounting and auditing purposes.

   A summary of the Tunnel-Client-Endpoint Attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |       Tag     |    String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      66 for Tunnel-Client-Endpoint.

   Length
      >= 3











Zorn, et al.                 Informational                      [Page 5]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F, it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F, it SHOULD be
      interpreted as the first byte of the following String field.

   String
      The format of the address represented by the String field depends
      upon the value of the Tunnel-Medium-Type attribute.

      If Tunnel-Medium-Type is IPv4 (1), then this string is either the
      fully qualified domain name (FQDN) of the tunnel client machine,
      or it is a "dotted-decimal" IP address.  Conformant
      implementations MUST support the dotted-decimal format and SHOULD
      support the FQDN format for IP addresses.

      If Tunnel-Medium-Type is IPv6 (2), then this string is either the
      FQDN of the tunnel client machine, or it is a text representation
      of the address in either the preferred or alternate form [17].
      Conformant implementations MUST support the preferred form and
      SHOULD support both the alternate text form and the FQDN format
      for IPv6 addresses.

      If Tunnel-Medium-Type is neither IPv4 nor IPv6, this string is a
      tag referring to configuration data local to the RADIUS client
      that describes the interface and medium-specific address to use.

3.4.  Tunnel-Server-Endpoint

   Description

      This Attribute indicates the address of the server end of the
      tunnel.  The Tunnel-Server-Endpoint Attribute MAY be included (as
      a hint to the RADIUS server) in the Access-Request packet and MUST
      be included in the Access-Accept packet if the initiation of a
      tunnel is desired.  It SHOULD be included in Accounting-Request
      packets which contain Acct-Status-Type attributes with values of
      either Start or Stop and which pertain to a tunneled session.
      This Attribute, along with the Tunnel-Client-Endpoint and Acct-
      Tunnel-Connection-ID Attributes [11], may be used to provide a
      globally unique means to identify a tunnel for accounting and
      auditing purposes.






Zorn, et al.                 Informational                      [Page 6]

RFC 2868        RADIUS Tunnel Authentication Attributes        June 2000


   A summary of the Tunnel-Server-Endpoint Attribute format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |     Tag       |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
      67 for Tunnel-Server-Endpoint.

   Length
      >= 3

   Tag
      The Tag field is one octet in length and is intended to provide a
      means of grouping attributes in the same packet which refer to the
      same tunnel.  If the value of the Tag field is greater than 0x00
      and less than or equal to 0x1F, it SHOULD be interpreted as
      indicating which tunnel (of several alternatives) this attribute
      pertains.  If the Tag field is greater than 0x1F, it SHOULD be
      interpreted as the first byte of the following String field.

   String
      The format of the address represented by the String field depends
      upon the value of the Tunnel-Medium-Type attribute.

      If Tunnel-Medium-Type is IPv4 (1), then this string is either the
      fully qualified domain name (FQDN) of the tunnel client machine,
      or it is a "dotted-decimal" IP address.  Conformant
      implementations MUST support the dotted-decimal format and SHOULD
      support the FQDN format for IP addresses.