Network Working Group                                   Alan DeKok (ed.)
INTERNET-DRAFT                                                FreeRADIUS
Category: Best Current Practice                                 G. Weber
<draft-ietf-radext-design-11.txt>
<draft-ietf-radext-design-12.txt>                 Individual Contributor
Expires: August 18, September 22, 2010
19 February
22 March 2010

                        RADIUS Design Guidelines
                      draft-ietf-radext-design-11
                      draft-ietf-radext-design-12

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 18, September 22, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info/) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Abstract

   This document provides guidelines for the design of attributes used
   by the Remote Authentication Dial In User Service (RADIUS) protocol.
   It is expected that these guidelines will prove useful to authors and
   reviewers of future RADIUS attribute specifications, both within the
   IETF as well as other Standards Development Organizations (SDOs).

Table of Contents

1.  Introduction .............................................    4    5
   1.1.  Terminology .........................................    4    5
   1.2.  Requirements Language ...............................    4    5
   1.3.  Applicability .......................................    5
2.  RADIUS Data Model ........................................    6
2.  Guidelines ...............................................    7
   2.1.  Standard Space ......................................    6
      2.1.1.  Basic  Data Types Defined in RFC 2865 ...........    7
      2.1.2.  Tagging Mechanism .............................. ..........................................    8
      2.1.3.  Complex Attribute Usage ........................    9
2.1.4. .......................................................   11
   2.2.  Vendor  Vendor-Specific Space ........................................   12 ...............................    9
   2.3.  Service definitions and RADIUS ......................   10
   2.4.  Translation of Vendor Specifications ................   10
3.  Rationale ................................................   11
   3.1.  RADIUS Operational Model ............................   11
   3.2.  Data Model Issues ........................................ ...................................   14
   3.1.
      3.2.1.  Basic Data Types ...............................   14
      3.2.2.  Tagging Mechanism ..............................   16
      3.2.3.  Complex Data Types .............................   16
   3.3.  Vendor Space ........................................   14
      3.1.1.   19
      3.3.1.  Interoperability Considerations ................   16
      3.1.2.   20
      3.3.2.  Vendor Allocations .............................   17
      3.1.3.   21
      3.3.3.  SDO Allocations ................................   17
      3.1.4.   21
      3.3.4.  Publication of specifications ..................   18
   3.2.   22
   3.4.  Polymorphic Attributes ..............................   18
   3.3.  RADIUS Operational Model ............................   19   22
4.  IANA Considerations ......................................   22   23
5.  Security Considerations ..................................   22   23
   5.1.  New Data Types and Complex Attributes ..................................   23 ...............   24
6.  References ...............................................   24   25
   6.1.  Normative References ................................   24   25
   6.2.  Informative References ..............................   24   25
Appendix A - Design Guidelines ...............................   27   28
   A.1. Types matching the RADIUS data model .................   27   28
      A.1.1. Transport of simple basic data ........................   27 types ...................   28
      A.1.2. Transport of Authentication and Security Data ...   28   29
      A.1.3. Opaque data types ...............................   28   29
   A.2. Improper Data Types ..................................   28   29
      A.2.1. Simple Basic Data Types ...............................   29 ................................   30
      A.2.2. Complex Data Types ..............................   29   30
   A.3. Vendor-Specific formats ..............................   30   31
   A.4. Changes to the RADIUS Operational Model ..............   30   31
   A.5. Allocation of attributes .............................   32   33
Appendix B - Complex Attributes ..............................   33   34
   B.1. CHAP-Password ........................................   33   34
   B.2. CHAP-Challenge .......................................   33   34
   B.3. Tunnel-Password ......................................   33   34
   B.4. ARAP-Password ........................................   34   35
   B.5. ARAP-Features ........................................   34   35
   B.6. Connect-Info .........................................   35   36
   B.7. Framed-IPv6-Prefix ...................................   36   37
   B.8. Egress-VLANID ........................................   36   37
   B.9. Egress-VLAN-Name .....................................   37   38

1.  Introduction

   This document provides guidelines for the design of RADIUS attributes
   both within the IETF as well as within other SDOs.  By articulating
   RADIUS design guidelines, it is hoped that this document will
   encourage the development and publication of high quality RADIUS
   attribute specifications.

   However, the advice in this document will not be helpful unless it is
   put to use.  As with "Guidelines for Authors and Reviewers of MIB
   Documents" [RFC4181], it is expected that this document will be used
   by authors to check their document against the guidelines prior to
   requesting review (such as an "Expert Review" described in
   [RFC3575]).  Similarly, it is expected that this document will used
   by reviewers (such as WG participants or the AAA Doctors [DOCTORS]),
   resulting in an improvement in the consistency of reviews.

   In order to meet these objectives, this document needs to cover not
   only the science of attribute design, but also the art.  Therefore,
   in addition to covering the most frequently encountered issues, this
   document attempts to provide some of the considerations motivating
   the guidelines.

   In order to characterize current attribute usage, both the basic and
   complex data types defined in the existing RADIUS RFCs are reviewed.

1.1.  Terminology

   This document uses the following terms:

Network Access Server (NAS)
     A device that provides an access service for a user to a network.

RADIUS server
     A RADIUS authentication, authorization, and/or accounting (AAA)
     server is an entity that provides one or more AAA services to a
     NAS.

1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The uses of "MUST" and "MUST NOT" in this document are limited to (a)
   requirements to follow the IETF process for IETF standards, and (b)
   quotes from other documents.  As a result, the uses of "MUST" and
   "MUST NOT" in this document do not prescribe new mandatory behavior
   within implementations.

1.3.  Applicability

   As RADIUS has become more widely accepted as a management protocol,
   its usage has become more prevalent, both within the IETF as well as
   within other SDOs.  Given the expanded utilization of RADIUS, it has
   become apparent that requiring SDOs to accomplish all their RADIUS
   work within the IETF is inherently inefficient and unscalable.  By
   articulating guidelines for RADIUS attribute design, this document
   enables SDOs out of the IETF to design their own RADIUS attributes
   within the Vendor-Specific Attribute (VSA) space.

   It is RECOMMENDED that SDOs follow the guidelines articulated in this
   document.  Doing so will ensure the widest possible applicability and
   interoperability of the specifications, while requiring minimal
   changes to existing systems.  Specifications that do not follow the
   guidelines articulated herein are NOT RECOMMENDED.  However, we
   recognize that there are some situations where SDOs or vendors
   require the creation of specifications not following these
   guidelines.  We do not forbid these specifications, but it is
   RECOMMENDED that they are created only if they have a limited scope
   of applicability, and all attributes defined in those specifications
   are VSAs, as discussed Appendix A.5, below.

   It is RECOMMENDED that SDOs and vendors seek review of RADIUS
   attribute specifications from the IETF.  However, when specifications
   are SDO specific, re-use existing data types, and follow these
   guidelines, they do not require IETF review.

   In order to enable IETF review of such specifications, the authors
   recommend that:

      * SDOs make their RADIUS attribute specifications publicly
      available;

      * SDOs request review of RADIUS attribute specifications by
      sending email to the AAA Doctors [DOCTORS] or equivalent mailing
      list;

      * IETF and SDO RADIUS attribute specifications are reviewed
      according to the guidelines proposed in this document;

      * Reviews of specifications are posted to the RADEXT WG mailing
      list, the AAA Doctors mailing list [DOCTORS] or another IETF
      mailing list suggested by the Operations & Management Area
      Directors of the IETF.

   These reviews can assist with creation of specifications that meet
   the SDO requirements, and which are also compatible with the
   traditional data model and uses of RADIUS.  While these reviews
   require access to public specifications, the review process does not
   require publication of an IETF RFC.

   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes (such as Service-Type) that
   can be used to, in effect, provide new RADIUS commands require
   greater expertise and deeper review, as do changes to the RADIUS
   operational model as discussed below in Section 3.3. ZZZ.  Such changes
   MUST NOT be undertaken outside the IETF and when handled within the
   IETF require "IETF Consensus" for adoption, as noted in [RFC3575]
   Section 2.1.

2.  RADIUS Data Model  Guidelines

   The Remote Authentication Dial In User Service (RADIUS) defined in
   [RFC2865] and [RFC2866] uses elements known as attributes in order to
   represent authentication, authorization and accounting data.

   Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
   not define a formal data definition language.  The data type of
   RADIUS attributes is not transported on the wire.  Rather, the data
   type of a RADIUS attribute is fixed when an attribute is defined.
   Based on the RADIUS attribute type code, RADIUS clients and servers
   can determine the data type based on preconfigured entries within a
   data dictionary.

   Two

   To explain the implications of this early RADIUS design decision we
   distinguish two types of data types, namely "basic" and "complex".
   Basic data types use one of the existing RADIUS data types as defined
   below, encapsulated in a [RFC2865] format RADIUS attribute, or in a
   [RFC2865] format RADIUS VSA.  All other data formats are "complex
   types".

   RADIUS attributes are also divided into two distinct attribute spaces are defined:
   spaces: the standard space, and a Vendor-Specific space.  Attributes
   in the standard space generally
   are composed of a type, length, value (TLV) triplet, although complex
   attributes have also been defined.  The Vendor-Specific space is
   encapsulated within a single follow the [RFC2865] attribute type (Vendor-Specific
   Attribute). format, with
   allocation managed by the Internet Assigned Number Authority (IANA).

   The format of this Vendor-Specific space is defined by individual
   vendors, but to be the same TLV encoding used by the standard space is
   recommended in [RFC2865] Section 5.26.  The similarity between
   attribute formats has enabled implementations to leverage common
   parsing functionality, although in some cases contents of the attributes in
   "String" field of the Vendor-Specific space have begun to diverge from the common format. Attribute ([RFC2865] Section
   5.26).  See Section 2.2, below, for a more in-depth discussion.

2.1.  Standard Space

   The following subsections describe common data types and formats
   within the RADIUS standard attribute space.  Common exceptions are
   identified.

2.1.1.  Basic  Data Types Defined in RFC 2865

   [RFC2865] and [RFC2866] utilize

   RADIUS defines a limited set of data types types, defined in [RFC2865]
   Section 5, which states the following: as "basic data
   types".  The format of the value field is one of five following data types.  Note
      that type "text" is qualifies as "basic data types":
      * 32-bit unsigned integer, in network byte order.

      * Enumerated data types, represented as a subset of type "string".

      text      1-253 octets containing UTF-8 encoded 10646 [RFC3629]
                characters.  Text 32-bit unsigned integer
        with a list of length zero (0) MUST NOT be sent;
                omit the entire attribute instead. name to value mappings.  (e.g., Service-Type)

      * Interface-Id (8 octet string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of length zero (0)
                MUST NOT be sent; omit the entire attribute instead. in network byte order)

      * IPv4 address   32 bit value, most significant octet first.

      integer   32 bit unsigned value, most significant octet first. in network byte order.

      * IPv6 address in network byte order.

      * IPv6 prefix.

      * time as 32 bit unsigned value, most significant octet first -- in network byte order, and in
        seconds since 00:00:00 UTC, January 1, 1970.  The
                standard Attributes do not use this data type but it is
                presented here for possible use in future attributes.

   In addition to

      * string (i.e., binary data), totalling 253 octets or less in
        length. This includes the opaque encapsulation of data types defined in [RFC2865], subsequent RADIUS
   specifications
        structures defined attributes using additional basic data types.
   These specifications did not explicitly define new data types as was
   done outside of RADIUS.  See also Appendix A.1.3,
        below.

      * UTF-8 text, totalling 253 octets or less in [RFC2865].  They did not consistently indicate length.

   Note that the format length limitations for VSAs of type String and Text are
   less than 253 octets, due to the value field using additional overhead of the same conventions Vendor-
   Specific format.

   The following data also qualifies as [RFC2865].  As "basic data types":

      * Attributes grouped into a
   result, logical container, using the data type
        [RFC2868] tagging mechanism.  This approach is ambiguous in some cases, and may not be
   consistent among different implementations.

   It NOT RECOMMENDED,
        but is out permissible where the alternatives are worse.

      * Attributes requiring the transport of more than 247 octets of
        Text or String data.  This includes the scope opaque encapsulation
        of this document to resolve all potential
   ambiguities within existing RADIUS specifications.  However in order
   to prevent future ambiguities, it is recommended that future RADIUS
   attribute specifications explicitly define newly created data types
   at the beginning structures defined outside of the document, RADIUS.

   Nested groups or attributes do not qualify as "basic data types", and indicate clearly the
   SHOULD NOT be used.

   All other data type formats are defined to be used for each attribute.

   [RFC3162] utilizes but does not explicitly define the following "complex data
   types:

   IPv6 address   128 bit value, in network byte order.
   IPv6 prefix    8 bits of reserved, 8 bits of prefix length, up to
                  128 bits of value, in network byte order.

   Examples of the IPv6 address type include NAS-IPv6-Address defined in

   [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
   Section 2.4.  The IPv6 prefix type is used in [RFC3162] Section 2.3, types", and
   are NOT RECOMMENDED.  However, there may be situations where complex
   attributes are beneficial because they reduce complexity in [RFC4818] Section 3.

   While the Framed-Interface-Id attribute defined in [RFC3162] Section
   2.2 included a value field of 8 octets, the data type was not
   explicitly indicated, and therefore non-
   RADIUS systems.  Unfortunately, there is controversy over whether are no "hard and fast" rules
   for where the format of this attribute was intended complexity would best be located.  Each situation has
   to be an 8 octet String or
   whether decided on a special Interface-Id type was intended.

   Given that case-by-case basis.

   See Appendix B for an audit of existing attributes of type "IPv6 address" complex data
   types, including a discussion of benefits and "IPv6 prefix" are
   already in use, it drawbacks.

2.2.  Vendor-Specific Space

   The Vendor-Specific space is RECOMMENDED that RADIUS server implementations
   include support for these additional basic types, in addition defined to be the
   types defined in [RFC2865].  Where contents of the intent is to represent a
   specific IPv6 address,
   "String" field of the "IPv6 address" type SHOULD be used.
   Although Vendor-Specific Attribute ([RFC2865] Section
   5.26).  As discussed there, it is possible intended for vendors to use support
   their own Attributes not suitable for general use.  It is RECOMMENDED
   that vendors follow the "IPv6 Prefix" type guidelines outlined here, which are intended
   to enable maximum interoperability with a prefix
   length of 128 minimal changes to represent an IPv6 address, this usage is NOT
   RECOMMENDED.  Implementations supporting existing
   systems.

   Following these guidelines means that RADIUS servers can be updated
   to support the Framed-Interface-Id
   attribute may select a data type of their choosing (most likely an 8
   octet String or vendor's equipment by editing a special Interface-Id data type).

   It is worth noting that since RADIUS dictionary.  If
   these guidelines are not followed, then the vendor's equipment can
   only supports unsigned integers
   of 32 bits, attributes using signed integer data types or unsigned
   integer types of other sizes will require code changes, and SHOULD be
   avoided.

   For [RFC2865] supported via code changes in RADIUS VSAs, the length limitation of the String server implementations.
   Such code changes add complexity and
   Text types is 247 octets instead of 253 octets, due delay to implementations.

   Vendor RADIUS Attribute specifications SHOULD allocate attributes
   from the additional
   overhead of the Vendor-Specific Attribute.

2.1.2.  Tagging Mechanism

   [RFC2868] defines vendor space, rather than requesting an attribute grouping mechanism based on allocation from the use of
   a one octet tag value.  Tunnel attributes
   RADIUS standard attribute space.

   All VSA schemes that refer to the same
   tunnel are grouped together by virtue of using do not follow the same tag value.

   This tagging mechanism has some drawbacks.  There [RFC2865] recommendations are a limited
   number of unique tags (31).  The tags
   NOT RECOMMENDED.  All data formats other than described above as
   "basic data types" are NOT RECOMMENDED.  These non-standard formats
   will typically not well suited for use
   with arbitrary binary data values, because it is be implementable without RADIUS server code
   changes.

   Although [RFC2865] does not always possible
   to tell if mandate it, implementations commonly
   assume that the first byte after Vendor Id can be used as a key to determine the Length is on-
   the-wire format of a VSA.  Vendors therefore SHOULD NOT use multiple
   formats for VSAs that are associated with a particular Vendor Id.  A
   vendor wishing to use multiple VSA formats SHOULD request one Vendor
   Id for each VSA format that they will use.

   Notwithstanding the tag or above recommendations, the first
   byte format of the untagged value (assuming the tag Vendor-
   Specific space is optional).

   Other limitations of under the tagging mechanism are that when integer
   values complete control of individual vendors
   and SDOs.  The guidelines outlined here are tagged, the value portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string recommendations, and tagged-integer.  These
   types increase
   do not define any requirements or restrictions on the complexity of implementing Vendor-Specific
   space.

2.3.  Service definitions and managing RADIUS
   systems.

   For these reasons, the tagging scheme described in RFC 2868

   RADIUS specifications define how an existing service or protocol can
   be provisioned using RADIUS.  Therefore, it is NOT
   RECOMMENDED for use as expected that a generic grouping mechanism.

2.1.3.  Complex Attribute Usage

   The RADIUS
   attribute encoding is summarized specification will reference documents defining the
   protocol or service to be provisioned.  Within the IETF, a RADIUS
   attribute specification SHOULD NOT be used to define the protocol or
   service being provisioned.  New services using RADIUS for
   provisioning SHOULD be defined elsewhere and referenced in [RFC2865]:

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

   However, some standard the RADIUS
   specification.

   New attributes, or new values of existing attributes, SHOULD NOT be
   used to define new RADIUS commands.  RADIUS attributes do not follow this format.
   Attributes that use sub-fields instead are intended
   to:

      * authenticate users

      * authorize users (i.e., service provisioning or changes to
        provisioning)

      * account for user activity (i.e., logging of using a basic data type session activity)

   New commands (i.e., the Code field in the packet header) are
   known
   allocated only through "IETF Consensus" as "complex attributes".  As described below, noted in [RFC3575] Section
   2.1.  Specifications also SHOULD NOT use new attributes to modify the definition
   interpretation of
   complex attributes can lead existing RADIUS commands.

2.4.  Translation of Vendor Specifications

   The limitation on changes to interoperability the RADIUS protocol effectively
   prohibits VSAs from changing fundamental aspects of RADIUS operation,
   such as modifying RADIUS packet sequences, or adding new commands.
   However, the requirement for clients and deployment
   issues, so they need servers to be introduced with care.

   In general, complex attributes sent from the RADIUS server able to
   operate in the
   client can absence of VSAs has proven to be supported by concatenating the values into less of a String
   data type field.  However, separating these values into different
   attributes, each with its own type and length, would have the
   following benefits:

      * constraint,
   since it is easier still possible for the user a RADIUS client and server to enter the data as well-known
        types, rather than complex structures;

      * it enables additional error checking by leveraging the
        parsing and validation routines mutually
   indicate support for well-known types;

      * it simplifies implementations by eliminating special-case
        attribute-specific parsing.

   One VSAs, after which behavior expectations can be
   reset.

   Therefore, RFC 2865 provides considerable latitude for development of
   new attributes within the fundamental goals vendor space, while prohibiting development
   of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes. variants.  This flexibility implies that RADIUS server implementations
   typically provide support for basic data types, and define
   attributes
   in a data dictionary.  This architecture enables a new attribute to can often be supported by developed within the addition of a dictionary entry, vendor space without requiring
   other RADIUS server code changes.

   On the RADIUS client, code changes are typically required
   loss (and possibly even with gain) in order to
   implement functionality.

   As a new attribute.  The result, translation of RADIUS client typically has to
   compose attributes developed within the
   vendor space into the standard space may provide only modest
   benefits, while accelerating the exhaustion of the standard attribute dynamically when sending.  When receiving, a
   space.  We do not expect that all RADIUS client needs to attribute specifications
   requiring interoperability will be able to parse developed within the attribute IETF, and carry out
   allocated from the requested service.  As a result, a detailed understanding standards space.  A more scalable approach is to
   recognize the flexibility of the
   new attribute is required on clients, and data dictionaries are less
   useful on clients than on servers.

   Given these considerations, vendor space, while working toward
   improvements in the introduction quality and availability of a new basic or
   complex RADIUS attribute will typically require code changes on the RADIUS
   client.  The magnitude
   specifications, regardless of changes where they are developed.

   It is therefore NOT RECOMMENDED that specifications intended solely
   for the complex attribute could use by a vendor or SDO use be
   greater, due to translated into the potential need for custom parsing logic. standard space.

3.  Rationale

   This section outlines the rationale behind the above recommendations.

3.1.  RADIUS Operational Model

   The RADIUS server can be configured to send a new static attribute by
   entering its type and data format in the operational model includes several assumptions:

      * The RADIUS server dictionary,
   and then filling in the value protocol is stateless;

      * Provisioning of services is not possible within an
        Access-Reject;

      * There is a policy based on the attribute
   name, data type distinction between authorization checks and type-specific value.  For data types not
   supported by current user
        authentication;

      * The protocol provices for authentication and integrity
        protection of packets;

      * The RADIUS protocol is a Request/Response protocol;

      * The protocol defines packet length restrictions.

   While RADIUS server dictionaries, changes to implementations may keep state, the
   dictionary code can RADIUS
   protocol is stateless, although information may be required in order passed from one
   protocol transaction to allow another via the new type to be
   supported by and configured on State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use of the State Attribute are inherently incompatible with RADIUS server.

   Code changes can also be required as
   defined in policy management [RFC2865], and in the
   RADIUS server's receive path.  These changes are due need to limitations
   in RADIUS server policy languages, which typically only provide be redesigned.  See [RFC5080]
   Section 2.1.1 for
   limited operations (such as comparisons or arithmetic operations) on
   the existing data types.  Many existing RADIUS policy languages
   typically are not capable a more in-depth discussion of parsing sub-elements, or providing
   sophisticated matching functionality.

   Given these limitations, the introduction use of new types can require
   code changes on the RADIUS server which would be unnecessary if basic
   data types had been used instead.  In addition, attribute-specific
   parsing means more complex software to develop and maintain.  More
   complexity can lead State
   Attribute.

   As noted in [RFC5080] Section 2.6, the intent of an Access-Reject is
   to more error prone implementations,
   interoperability problems, and even security vulnerabilities.  These
   issues can increase costs deny access to network administrators as well as
   reducing reliability and introducing deployment barriers.  We
   therefore RECOMMEND that the introduction requested service.  As a result, RADIUS does
   not allow the provisioning of new complex data types services within RADIUS attribute specifications be avoided.  A potential
   exception to this recommendation occurs for attributes that an Access-Reject.
   Documents which include provisioning of services within an Access-
   Reject are inherently require code changes on both the client and server.  For
   example, as described in Appendix B, complex attributes have been
   used in situations involving authentication incompatible with RADIUS, and security attributes
   that need to be dynamically computed and verified.
   redesigned.

   As can be seen noted in Appendix B, most of the existing complex attributes
   involve [RFC5080] Section 2.1.1, a RADIUS Access-Request may not
   contain user authentication attributes or security functionality.  Supporting this
   functionality requires code changes on both the RADIUS client and
   server, regardless of the attribute format.  As a result, in most
   cases, State Attribute linking
   the use of complex attributes Access-Request to represent these methods is
   acceptable, and does not create additional interoperability or
   deployment issues.

   The only other exception to the recommendation against complex types
   is for types that can be treated an earlier user authentication.  Such an
   Access-Request, known as opaque data by the RADIUS server.
   For example, the EAP-Message attribute, defined in [RFC3579] Section
   3.1 contains a complex data type that is an EAP packet.  Since these
   complex types do not need authorization check, provides no
   assurance that it corresponds to be parsed by the a live user.  RADIUS server, the
   issues arising from policy language limitations do not arise.
   Similarly, since specifications
   defining attributes of these complex types can be configured
   on the server using a data type of String, dictionary limitations are
   also not encountered.  Appendix A.1 below includes a series of
   checklists that may containing confidential information (such as
   Tunnel-Password) should be used careful to analyze a design for RECOMMENDED and
   NOT RECOMMENDED behavior prohibit such attributes from
   being returned in relation response to complex types.

   If the RADIUS Server simply passes the contents of an attribute authorization check.  Also,
   [RFC5080] Section 2.1.1 notes that authentication mechanisms need to
   some non-RADIUS portion
   tie a sequence of the network, then the data Access-Request/Access-Challenge packets together
   into one authentication session.  The State Attribute is opaque, and
   SHOULD be defined to be of type String.  A concrete way of judging RECOMMENDED
   for this requirement is whether or purpose.

   While [RFC2865] did not the attribute definition in the
   RADIUS document contains delineated fields for sub-parts require authentication and integrity
   protection of the data.
   If those fields need to be delineated in RADIUS, then the data is not
   opaque, and it SHOULD be separated into individual RADIUS attributes.

   An examination of existing RADIUS RFCs discloses a number of complex
   attributes that Access-Request packets, subsequent
   authentication mechanism specifications such as RADIUS/EAP [RFC3579]
   and Digest Authentication [RFC5090] have already been defined.  Appendix B includes a
   listing of complex attributes used within [RFC2865], [RFC2868],
   [RFC2869], [RFC3162], [RFC4818], mandated authentication and [RFC4675].  The discussion of
   these attributes includes reasons why a complex type
   integrity protection for certain RADIUS packets.  [RFC5080] Section
   2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
   including Access-Request packets performing authorization checks.  It
   is acceptable,
   or suggestions expected that specifications for how the attribute could have been defined to
   follow the new RADIUS data model.

   In other cases, the data authentication
   mechanisms will continue this practice.

   The RADIUS protocol as defined in the complex type are described textually.
   This [RFC2865] is possible because the data types are not sent within the
   attributes, but are a matter for endpoint interpretation.  An
   implementation can define additional data types, request-response
   protocol spoken between RADIUS clients and use these data
   types today by matching them to the attribute's textual description.

   Despite the above caveats, there may be situations where complex
   attributes are beneficial because they reduce complexity servers.  A single RADIUS
   Access-Request packet will solicit in response at most a single
   Access-Accept, Access-Reject or Access-Challenge packet, sent to the non-
   RADIUS systems.  Unfortunately, there are no "hard
   IP address and fast" rules
   for where port of the complexity would best be located.  Each situation has
   to be decided on a case-by-case basis.

2.1.4. RADIUS specifications define how an existing service or protocol can
   be provisioned using RADIUS.  Therefore, it is expected that a RADIUS
   attribute specification will reference documents defining the
   protocol or service to be provisioned.  Within the IETF, a RADIUS
   attribute specification SHOULD NOT be used to define the protocol or
   service being provisioned.  New services using RADIUS for
   provisioning SHOULD be defined elsewhere and referenced in the RADIUS
   specification.

   New attributes, or new values of existing attributes, SHOULD NOT be
   used to define new RADIUS commands.  RADIUS attributes are intended
   to:

      * authenticate users

      * authorize users (i.e., service provisioning or changes to
        provisioning)

      * account for user activity (i.e., logging of session activity)

   New commands (i.e., the Code field in the packet header) are
   allocated only through "IETF Consensus" as noted in [RFC3575] Section
   2.1.  Specifications also SHOULD NOT use new attributes to modify the
   interpretation of existing RADIUS commands.

2.2.  Vendor Space

   As noted in [RFC2865] Section 5.26, the VSA format is defined as
   follows:

    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       |            Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor-Id (cont)           |  String...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   The high-order octet of the Vendor-Id field is 0 and the low-order 3
   octets are the Structure of Management Information (SMI) Network
   Management Private Enterprise Code (PEC) of the Vendor in network
   byte order.

   While the format of the String field is defined by the vendor,
   [RFC2865] Section 5.26 notes:

      It SHOULD be encoded as a sequence of vendor type / vendor length
      / value fields, as follows.  The Attribute-Specific field is
      dependent on the vendor's definition of that attribute.  An
      example encoding of the Vendor-Specific attribute using this
      method follows:

       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       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           | Vendor type   | Vendor length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Multiple sub-attributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

   Note Client that originated the Vendor type field in the recommended VSA format is only Access-
   Request.  Similarly, a single octet, like the RADIUS type field. While this limitation
   results in an efficient encoding, there are situations Change-of-Authorization (CoA)-Request
   packet [RFC5176] will solicit in which response at most a
   vendor single CoA-ACK or SDO will eventually wish
   CoA-NAK packet, sent to define more than 255
   attributes. Also, an SDO can be comprised of multiple subgroups, each
   of whom can desire autonomy over the definition of attributes within
   their group.  The most interoperable way to IP address these issues is
   for and port of the vendor Dynamic
   Authorization Client (DAC) that originated the CoA-Request. A single
   Disconnect-Request packet will solicit in response at most a single
   Disconnect-ACK or SDO Disconnect-NAK packet, sent to request allocation of multiple Vendor
   identifiers.

   However, instead of doing this, vendors have defined the following
   non-standard VSA formats:

   * Vendor types of 16 bits, followed by an 8 bit length and
     then attribute-specific data.

   * Vendor types of 32 bits, followed by no length field, IP address and
     then attribute-specific data.

   * Vendor types
   port of the RFC format, but where some VSAs are
     defined as "grouped" or TLV attributes.  These attributes Dynamic Authorization Client (DAC) that originated the
   Disconnect-Request.  Changes to this model are then used likely to carry sub-attributes.

   * "Bare" ASCII strings that immediately follow require
   major revisions to existing implementations and so this practice is
   NOT RECOMMENDED.

   The Length field in the Vendor-Id,
      without using a Vendor type or Vendor length.

   All VSA schemes RADIUS packet header is defined in [RFC2865]
   Section 3.  It is noted there that do not follow the [RFC2865] recommendations are maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers SHOULD NOT RECOMMENDED.  These non-standard formats will typically not be
   implementable without
   assume that a RADIUS server code changes.  This includes all
   the above formats, as well as Vendor types of more implementation can successfully process RADIUS
   packets larger than 8 bits,
   vendor lengths of 4096 octets.

   Even when packets are less than 8 bits, vendor lengths of more 4096 octets, they may be larger than 8
   bits and Vendor-Specific contents that are not in Type-Length-Value
   format.

   Although [RFC2865] does not mandate it, implementations commonly
   assume that
   the Vendor Id can Path Maximum Transmission Unit (PMTU).  Any packet larger than
   the PMTU will be used fragmented, making communications more brittle as
   firewalls and filtering devices often discard fragments.  Transport
   of fragmented UDP packets appears to be a key poorly tested code path on
   network devices.  Some devices appear to determine the on-
   the-wire format be incapable of transporting
   fragmented UDP packets, making it difficult to deploy RADIUS in a VSA.  Vendors therefore SHOULD NOT use multiple
   formats for VSAs that
   network where those devices are associated with deployed.  We RECOMMEND that RADIUS
   messages be kept as small possible.

   If a particular Vendor Id.  A
   vendor wishing situation is envisaged where it may be necessary to use multiple VSA formats SHOULD request carry
   authentication, authorization or accounting data in a packet larger
   than 4096 octets, then one Vendor
   Id for each VSA format that they will use.

3.  Data Model Issues

   Since the closure of the following approaches is
   RECOMMENDED:

     1. Utilization of a sequence of packets.
        For RADIUS Working Group, authentication, a sequence of Access-Request/ Access-
        Challenge packets would be used.  For this to be feasible,
        attribute designers need to enable inclusion of attributes that
        can consume considerable space within Access-Challenge packets.
        To maintain compatibility with existing NASes, either the popularity and
   prevalence use of RADIUS has continued to grow.  In addition
        Access-Challenge packets needs to
   increasing demand be permissible (as with
        RADIUS/EAP, defined in [RFC3579]), or support for allocation receipt of attributes within an
        Access-Challenge needs to be indicated by the NAS (as in RADIUS
   standard attribute space,
        Location [RFC5580]). Also, the number of vendors specification needs to clearly
        describe how attribute splitting is to be signalled and SDOs creating new how
        attributes included within the Vendor-Specific attribute space has grown, and
   this has lead to some divergence in approaches sequence are to RADIUS attribute
   design.

   In general, standard RADIUS attributes be interpreted,
        without requiring stateful operation.  Unfortunately, previous
        specifications have a more constrained data
   model than attributes within not always exhibited the vendor space. required foresight.
        For example, vendors
   and SDOs have evolved even though very large filter rules are
        conceivable, the NAS-Filter-Rule Attribute defined in [RFC4849]
        is not permitted in an Access-Challenge packet, nor is a
        mechanism specified to allow a set of NAS-Filter-Rule attributes
        to be split across an Access-Request/Access-Challenge sequence.

        In the case of RADIUS accounting, transporting large amounts of
        data model would require a sequence of Accounting-Request packets.
        This is a non-trivial change to support new functions such as RADIUS, since RADIUS accounting
        clients would need to be modified to split the attribute grouping stream
        across multiple Accounting-Requests, and billing servers would
        need to be modified to re-assemble and interpret the attribute fragmentation, with different groups
   taking different approaches.

   Given these enhancements, it has become difficult for vendors or SDOs
        stream.

     2. Utilization of names rather than values.
        Where an attribute relates to translate attributes from a policy that could conceivably be
        pre-provisioned on the NAS, then the vendor space to name of the more stringent
   standards space.  For example, a Vendor-Specific attribute using sub-
   elements pre-provisioned
        policy can be transmitted in an attribute, rather than the
        policy itself, which could require allocation be quite large.  An example of several standard space
   attributes using basic data types.  In this case not only would
   translation require substantial additional
        is the Filter-Id Attribute defined in [RFC2865] Section 5.11,
        which enables a set of pre-provisioned filter rules to be
        referenced by name.

     3. Utilization of Packetization Layer Path MTU Discovery
        techniques, as specified in [RFC4821].  As a last resort, where
        the above techniques cannot be made to work, it would further
   deplete may be possible
        to apply the RADIUS standard attribute space.  Given these
   limitations, translation of vendor attributes techniques described in [RFC4821] to discover the standards space
   is not necessarily desirable, particularly if
        maximum supported RADIUS packet size on the VSA specification
   is publicly available path between a
        RADIUS client and a home server.  While such an approach can
        avoid the complexity of utilization of a sequence of packets,
        dynamic discovery is likely to be implemented within time consuming and cannot be
        guaranteed to work with existing RADIUS
   clients and servers. implementations.  As a
        result, this technique is not generally applicable.

3.2.  Data Model Issues

   The RADIUS data types are poorly defined.  While [RFC2865] Section 5
   defines basic data types, later specifications did not follow this
   practice.  This led implementations to define their own names for
   data types, leading to non-standard names for those types.

   In such situations, the costs may substantially
   outweigh addition, the benefits.  It is possible that some number of the enhancements
   made within the vendor space may eventually become available vendors and SDOs creating new attributes
   within the standard Vendor-Specific attribute space.  However, the divergence of the
   standard space has grown, and vendor this has
   lead to some divergence in approaches to RADIUS attribute spaces is most likely a permanent
   feature, design.
   For example, vendors and should be recognized as such.

3.1.  Vendor Space

   The usage SDOs have evolved the data model for to support
   new functions such as more data types, along with attribute grouping
   and attribute fragmentation, with different groups taking different
   approaches.  These approaches are often incompatible, leading to
   additional complexity in RADIUS VSAs is described implementations.

   This section describes the history of the RADIUS data model, in an
   attempt to codify existing practices, and to avoid repeating old
   mistakes.

3.2.1.  Basic Data Types

   [RFC2865] and [RFC2866] utilize data types defined in [RFC2865]
   Section
   6.2:

      Note that RADIUS defines a mechanism for Vendor-Specific
      extensions (Attribute 26) and 5, which states the use following:

      The format of the value field is one of five data types.  Note
      that should be encouraged
      instead type "text" is a subset of allocation type "string".

      text      1-253 octets containing UTF-8 encoded 10646 [RFC3629]
                characters.  Text of global length zero (0) MUST NOT be sent;
                omit the entire attribute types, for functions
      specific only to one vendor's implementation instead.

      string    1-253 octets containing binary data (values 0 through
                255 decimal, inclusive).  Strings of RADIUS, where no
      interoperability is deemed useful.

   Nevertheless, many new attributes have been defined in length zero (0)
                MUST NOT be sent; omit the vendor
   specific space in situations where interoperability is entire attribute instead.

      address   32 bit value, most significant octet first.

      integer   32 bit unsigned value, most significant octet first.

      time      32 bit unsigned value, most significant octet first --
                seconds since 00:00:00 UTC, January 1, 1970.  The
                standard Attributes do not only
   useful, use this data type but it is required.  For example, SDOs outside the IETF (such as
   the IEEE 802 and the 3rd Generation Partnership Project (3GPP)) have
   been assigned Vendor-Ids, enabling them to define their own VSA
   format and assign Vendor types within their own space.

   The use of VSAs by SDOs outside the IETF has gained in popularity for
   several reasons:

Efficiency
     As with SNMP, which defines an "Enterprise" Object Identifier (OID)
     space suitable
                presented here for possible use by vendors as well as other SDOs, the
     definition of Vendor-Specific in future attributes.

   Subsequent RADIUS specifications also defined attributes has become a common
     occurrence using new
   data types.  These specifications did not explicitly define those
   data types as part of standards activity outside was done in [RFC2865].  They did not consistently
   indicate the IETF.  For
     reasons format of efficiency, it is easiest if the RADIUS attributes
     required to manage a standard are developed within value field using the same SDO
     that develops the standard itself. conventions as
   [RFC2865].  As noted in "Transferring MIB
     Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few
     vendors are willing to simultaneously fund individuals to
     participate within an SDO to complete a standard, as well as to
     participate in the IETF in order to complete result, the associated RADIUS
     attributes specification.

Attribute scarcity
     The standard RADIUS attribute space data type is limited to 255 unique
     attributes.  Of these, only about half remain available for
     allocation.  In the Vendor-Specific space, the number of attributes
     available ambiguous in some cases,
   and may not be consistent among different implementations.

   It is a function out of the format scope of the this document to resolve all potential
   ambiguities within existing RADIUS specifications.  However in order
   to prevent future ambiguities, it is recommended that future RADIUS
   attribute (the size specifications explicitly define newly created data types
   at the beginning of the Vendor document, and indicate clearly the data type field).

   Along with these advantages, some limitations of VSA usage are noted
   in [RFC2865] Section 5.26:

      This Attribute is available to allow vendors
   to support their own
      extended Attributes not suitable be used for general usage.  It MUST NOT
      affect each attribute.

   [RFC3162] utilizes but does not explicitly define the operation following data
   types:

   IPv6 address   128 bit value, in network byte order.
   IPv6 prefix    8 bits of the RADIUS protocol.

      Servers not equipped reserved, 8 bits of prefix length, up to interpret
                  128 bits of value, in network byte order.

   Examples of the vendor-specific information
      sent by a client MUST ignore it (although it may be reported).
      Clients which do not receive desired vendor-specific information
      SHOULD make an attempt to operate without it, although they may do
      so (and report they are doing so) IPv6 address type include NAS-IPv6-Address defined in a degraded mode.
   [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
   Section 2.4.  The limitation on changes to IPv6 prefix type is used in [RFC3162] Section 2.3,
   and in [RFC4818] Section 3.

   While the RADIUS protocol effectively
   prohibits VSAs from changing fundamental aspects Framed-Interface-Id attribute defined in [RFC3162] Section
   2.2 included a value field of RADIUS operation,
   such as modifying RADIUS packet sequences, or adding new commands.
   However, 8 octets, the requirement for clients data type was not
   explicitly indicated, and servers to be able to
   operate in therefore there is controversy over whether
   the absence format of VSAs has proven this attribute was intended to be less of an 8 octet String or
   whether a constraint,
   since special Interface-Id type was intended.

   Given that attributes of type "IPv6 address" and "IPv6 prefix" are
   already in use, it is still possible for a RECOMMENDED that RADIUS client and server to mutually
   indicate implementations
   include support for VSAs, after which behavior expectations can be
   reset.

   Therefore, RFC 2865 provides considerable latitude for development of
   new attributes within these additional basic types, in addition to the vendor space, while prohibiting development
   of protocol variants.  This flexibility implies that RADIUS
   attributes can often
   types defined in [RFC2865].  Where the intent is to represent a
   specific IPv6 address, the "IPv6 address" type SHOULD be developed within used.
   Although it is possible to use the vendor space without
   loss (and possibly even "IPv6 Prefix" type with gain) in functionality.

   As a result, translation prefix
   length of RADIUS attributes developed within the
   vendor space into 128 to represent an IPv6 address, this usage is NOT
   RECOMMENDED.  Implementations supporting the standard space Framed-Interface-Id
   attribute may provide only modest
   benefits, while accelerating the exhaustion select a data type of the standard attribute
   space.  We do not expect their choosing (most likely an 8
   octet String or a special Interface-Id data type).

   It is worth noting that all since RADIUS attribute specifications
   requiring interoperability only supports unsigned integers
   of 32 bits, attributes using signed integer data types or unsigned
   integer types of other sizes will require code changes, and SHOULD be developed within
   avoided.

   For [RFC2865] RADIUS VSAs, the IETF, and
   allocated from length limitation of the standards space.  A more scalable approach String and
   Text types is 247 octets instead of 253 octets, due to
   recognize the flexibility additional
   overhead of the vendor space, while working toward
   improvements in Vendor-Specific Attribute.

3.2.2.  Tagging Mechanism

   [RFC2868] defines an attribute grouping mechanism based on the quality and availability use of RADIUS attribute
   specifications, regardless
   a one octet tag value.  Tunnel attributes that refer to the same
   tunnel are grouped together by virtue of where they using the same tag value.

   This tagging mechanism has some drawbacks.  There are developed.

3.1.1.  Interoperability Considerations

   Vendors and SDOs a limited
   number of unique tags (31).  The tags are reminded that not well suited for use
   with arbitrary binary data values, because it is not always possible
   to tell if the standard RADIUS attribute
   space, and first byte after the enumerated Length is the tag or the first
   byte of the untagged value space for enumerated attributes, are
   reserved for allocation through work published via (assuming the IETF, as noted
   in [RFC3575] Section 2.1.  Some vendors and SDOs have in tag is optional).

   Other limitations of the past
   performed self-allocation by assigning vendor-specific meaning to
   "unused" tagging mechanism are that when integer
   values from are tagged, the standard RADIUS attribute ID or enumerated value space.  This self-allocation results in interoperability
   issues, portion is reduced to three bytes
   meaning only 24-bit numbers can be represented.  The tagging
   mechanism does not offer an ability to create nested groups of
   attributes.  Some RADIUS implementations treat tagged attributes as
   having additional data types tagged-string and tagged-integer.  These
   types increase the complexity of implementing and is counter-productive.  Similarly, managing RADIUS
   systems.

   For these reasons, the Vendor-Specific
   enumeration practice discussed tagging scheme described in [RFC2882] Section 2.2.1 RFC 2868 is NOT
   RECOMMENDED.

   If it is not possible to follow the IETF process, vendors and SDOs
   SHOULD self-allocate an attribute from their Vendor-Specific space,
   and define an appropriate value
   RECOMMENDED for it.

   As use as a side note, [RFC2865] Section 5.26 uses the term "Vendor-Specific
   Attribute" to refer to an generic grouping mechanism.

3.2.3.  Complex Data Types

   The RADIUS attribute encoding format which can be used by
   individual vendors to define attributes not suitable for general
   usage. is summarized in [RFC2865]:

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

   However, since then VSAs have also become widely used by SDOs
   defining attributes intended for multi-vendor interoperability. As
   such, these some standard attributes are do not specific to any single vendor, and the
   term "Vendor-Specific" may be misleading.  An alternate term which
   better describes follow this format.
   Attributes that use case is SDO-Specific Attribute (SSA).

   The design and specification of VSAs for multi-vendor usage SHOULD be
   undertaken with the same level sub-fields instead of care using a basic data type as standard RADIUS attributes.
   Specifically,
   discussed in the provisions of above sections are defined to be "complex types".
   As described below in this document that apply section the creation of complex types can
   lead to standard interoperability and deployment issues, so they need to be
   introduced with care.

   In general, complex types sent from the RADIUS attributes also apply server to SSAs or VSAs for multi-vendor usage.

3.1.2.  Vendor Allocations

   Vendor RADIUS Attribute specifications SHOULD allocate attributes
   from the vendor space, rather than requesting an allocation from client
   can be supported by concatenating the
   RADIUS standard attribute space.

   As discussed in [RFC2865] Section 5.26, values into a String data type
   field.  However, separating these values into different attributes,
   each with its own type and length, would have the vendor space following benefits:

      * it is intended easier for vendors the user to support their own Attributes not suitable enter the data as well-known
        types, rather than complex structures;

      * it enables additional error checking by leveraging the
        parsing and validation routines for general
   use.  However, well-known types;

      * it is RECOMMENDED that vendors follow simplifies implementations by eliminating special-case
        attribute-specific parsing.

   One of the guidelines
   outlined here, which are intended to enable maximum interoperability
   with minimal changes fundamental goals of the RADIUS protocol design was to existing systems.

   Following these guidelines means that
   allow RADIUS servers can to be updated configured to support the vendor's equipment by editing a new attributes
   without requiring server code changes.  RADIUS server implementations
   typically provide support for basic data types, and define attributes
   in a data dictionary.  If
   these guidelines are not followed, then the vendor's equipment can
   only  This architecture enables a new attribute to
   be supported via code changes in by the addition of a dictionary entry, without requiring
   other RADIUS server implementations.
   Such code changes add complexity and delay to implementations.

3.1.3.  SDO Allocations

   SDO RADIUS Attribute specifications SHOULD allocate attributes from changes.

   On the vendor space, rather than requesting an allocation from RADIUS client, code changes are typically required in order to
   implement a new attribute.  The RADIUS client typically has to
   compose the attribute dynamically when sending.  When receiving, a
   RADIUS standard client needs to be able to parse the attribute space, for attributes matching any and carry out
   the requested service.  As a result, a detailed understanding of the
   following criteria:

      * attributes relying
   new attribute is required on clients, and data types not defined within RADIUS

      * attributes intended primarily for use within an SDO

      * attributes intended primarily for use within a group dictionaries are less
   useful on clients than on servers.

   Given these considerations, the introduction of SDOs.

   Any a new RADIUS attributes basic or values intended for interoperable use
   across a broad spectrum of the Internet Community SHOULD follow the
   normal IETF process, and SHOULD result in allocations from
   complex attribute will typically require code changes on the RADIUS
   standard space.
   client.  The recommendation magnitude of changes for SDOs to allocate attributes from a vendor
   space rather than via the IETF process is a recognition that SDOs may
   desire complex attribute could be
   greater, due to assert change control over their own the potential need for custom parsing logic.

   The RADIUS specifications.
   This change control server can be obtained by requesting configured to send a PEC from new static attribute by
   entering its type and data format in the
   Internet Assigned Number Authority (IANA), for use as a Vendor-Id RADIUS server dictionary,
   and then filling in the value within a Vendor-Specific attribute.  Further allocation of attributes
   inside of policy based on the attribute
   name, data type and type-specific value.  For data types not
   supported by current RADIUS server dictionaries, changes to the VSA space defined by that Vendor-Id is subject solely
   dictionary code can be required in order to allow the discretion of new type to be
   supported by and configured on the SDO.  Similarly, RADIUS server.

   Code changes can also be required in policy management and in the use of data types
   (complex
   RADIUS server's receive path.  These changes are due to limitations
   in RADIUS server policy languages, which typically only provide for
   limited operations (such as comparisons or not) within that VSA space is solely under arithmetic operations) on
   the discretion existing data types.  Many existing RADIUS policy languages
   typically are not capable of parsing sub-elements, or providing
   sophisticated matching functionality.

   Given these limitations, the SDO.  It is RECOMMENDED that SDOs follow introduction of new types can require
   code changes on the guidelines
   outlined here, RADIUS server which would be unnecessary if basic
   data types had been used instead.  In addition if "ad-hoc" types are intended
   used, attribute-specific parsing means more complex software to enable maximum
   develop and maintain.  More complexity can lead to more error prone
   implementations, interoperability
   with minimal changes problems, and even security
   vulnerabilities.  These issues can increase costs to existing systems.

   It should be understood network
   administrators as well as reducing reliability and introducing
   deployment barriers.  We therefore RECOMMEND that SDOs do not have to rehost VSAs into the
   standards space solely for the purpose introduction of obtaining IETF review.
   Rehosting puts pressure
   new types and complex data types within RADIUS attribute
   specifications be avoided.  A potential exception to this
   recommendation occurs for attributes that inherently require code
   changes on both the standards space, client and server.  For example, as described in
   Appendix B, complex attributes have been used in situations involving
   authentication and may be harmful security attributes that need to
   interoperability, since it be dynamically
   computed and verified.

   As can create two ways to provision be seen in Appendix B, most of the same
   service.  Rehosting may also require existing complex attributes
   involve authentication or security functionality.  Supporting this
   functionality requires code changes to on both the RADIUS data model
   which will affect implementations that do not intend to support client and
   server, regardless of the
   SDO specifications.

3.1.4.  Publication attribute format.  As a result, in most
   cases, the use of specifications

   SDOs are encouraged complex attributes to represent these methods is
   acceptable, and does not create additional interoperability or
   deployment issues.

   The only other exception to seek early review of SSA specifications by the
   IETF.  This review may recommendation against complex types
   is for types that can be initiated treated as opaque data by sending mail to the AAA
   Doctors list [DOCTORS], with RADIUS server.
   For example, the understanding EAP-Message attribute, defined in [RFC3579] Section
   3.1 contains a complex data type that this review is a
   voluntary-based service offered on best-effort basis. an EAP packet.  Since the IETF
   is these
   complex types do not a membership organization, in order need to enable be parsed by the RADIUS SSA
   specification to be reviewed, it is RECOMMENDED that it server, the
   issues arising from policy language limitations do not arise.
   Similarly, since attributes of these complex types can be made
   publicly available; this also encourages interoperability.  Where configured
   on the
   RADIUS SSA specification is embedded within server using a data type of String, dictionary limitations are
   also not encountered.  Appendix A.1 below includes a larger document which
   cannot series of
   checklists that may be made public, used to analyze a design for RECOMMENDED and
   NOT RECOMMENDED behavior in relation to complex types.

   If the RADIUS Server simply passes the contents of an attribute to
   some non-RADIUS portion of the network, then the data is opaque, and value definitions
   SHOULD be published instead as an Informational RFC, as with
   [RFC4679].  This process SHOULD defined to be followed instead of requesting
   IANA allocations from within the standard RADIUS attribute space.

   Similarly, vendors are encouraged to make their specifications
   publicly available, for maximum interoperability.  However, it type String.  A concrete way of judging
   this requirement is whether or not
   necessary the attribute definition in the
   RADIUS document contains delineated fields for them to request publication sub-parts of their VSA specifications
   as Informational RFCs by the IETF.

   All other specifications, including new authentication,
   authorization, and/or security mechanisms SHOULD data.
   If those fields need to be allocated via delineated in RADIUS, then the
   standard data is not
   opaque, and it SHOULD be separated into individual RADIUS space, as noted in [RFC3575] Section 2.1.

3.2.  Polymorphic Attributes

   A polymorphic attribute attributes.

   An examination of existing RADIUS RFCs discloses a number of complex
   attributes that have already been defined.  Appendix B includes a
   listing of complex attributes used within [RFC2865], [RFC2868],
   [RFC2869], [RFC3162], [RFC4818], and [RFC4675].  The discussion of
   these attributes includes reasons why a complex type is one whose format acceptable,
   or meaning is dynamic.
   For example, rather than using a fixed data format, an attribute's
   format might change based on suggestions for how the contents of another attribute.  Or, attribute could have been defined to
   follow the meaning of an attribute may depend on earlier packets in a
   sequence. RADIUS server dictionary entries are typically static, enabling data model.

   In other cases, the
   user to enter data in the contents of an attribute without support for
   changing complex type are described textually.
   This is possible because the format based on dynamic conditions.  However, this
   limitation on static data types does are not prevent implementations from
   implementing policies that return different attributes based on sent within the
   contents of received attributes; this is
   attributes, but are a common feature of existing
   RADIUS implementations.

   In general, polymorphism is NOT RECOMMENDED.  Polymorphism rarely
   enables capabilities that would not be available through matter for endpoint interpretation.  An
   implementation can define additional data types, and use of
   multiple attributes.  Polymorphism requires code changes in these data
   types today by matching them to the
   RADIUS server in attribute's textual description.

   Despite the above caveats, there may be situations where complex
   attributes with fixed formats would
   not require such changes.  Thus, polymorphism increases are beneficial because they reduce complexity
   while decreasing generality, without delivering any corresponding
   benefits.

   Note that changing an attribute's format dynamically is not in the same
   thing as using a fixed format non-
   RADIUS systems.  Unfortunately, there are no "hard and computing fast" rules
   for where the attribute itself
   dynamically.  RADIUS authentication attributes such as User-Password,
   EAP-Message, etc. while being computed dynamically, use a fixed
   format.

3.3.  RADIUS Operational Model

   The RADIUS operational model includes several assumptions:

      * The RADIUS protocol is stateless;

      * Provisioning of services is not possible within an
        Access-Reject;

      * There is complexity would best be located.  Each situation has
   to be decided on a distinction between authorization checks and user
        authentication;

      * case-by-case basis.

3.3.  Vendor Space

   The protocol provices usage model for authentication and integrity
        protection of packets;

      * The RADIUS protocol VSAs is a Request/Response protocol;

      * The protocol defines packet length restrictions.

   While described in [RFC2865] Section
   6.2:

      Note that RADIUS server implementations may keep state, defines a mechanism for Vendor-Specific
      extensions (Attribute 26) and the RADIUS
   protocol is stateless, although information may use of that should be passed from one
   protocol transaction encouraged
      instead of allocation of global attribute types, for functions
      specific only to another via the State Attribute.  As a
   result, documents which require stateful protocol behavior without
   use one vendor's implementation of the State Attribute are inherently incompatible with RADIUS as RADIUS, where no
      interoperability is deemed useful.

   Nevertheless, many new attributes have been defined in [RFC2865], the vendor
   specific space in situations where interoperability is not only
   useful, but is required.  For example, SDOs outside the IETF (such as
   the IEEE 802 and need to be redesigned.  See [RFC5080]
   Section 2.1.1 for a more in-depth discussion of the 3rd Generation Partnership Project (3GPP)) have
   been assigned Vendor-Ids, enabling them to define their own VSA
   format and assign Vendor types within their own space.

   The use of VSAs by SDOs outside the State
   Attribute.

   As noted IETF has gained in [RFC5080] Section 2.6, popularity for
   several reasons:

Efficiency
     As with SNMP, which defines an "Enterprise" Object Identifier (OID)
     space suitable for use by vendors as well as other SDOs, the
     definition of Vendor-Specific RADIUS attributes has become a common
     occurrence as part of standards activity outside the intent IETF.  For
     reasons of an Access-Reject efficiency, it is
   to deny access to easiest if the requested service.  As a result, RADIUS does
   not allow the provisioning of services within an Access-Reject.
   Documents which include provisioning of services within an Access-
   Reject are inherently incompatible with RADIUS, and need attributes
     required to be
   redesigned. manage a standard are developed within the same SDO
     that develops the standard itself.  As noted in [RFC5080] Section 2.1.1, a RADIUS Access-Request may not
   contain user authentication attributes or a State Attribute linking
   the Access-Request "Transferring MIB
     Work from IETF Bridge MIB WG to IEEE 802.1 WG" [RFC4663], today few
     vendors are willing to simultaneously fund individuals to
     participate within an earlier user authentication.  Such an
   Access-Request, known as an authorization check, provides no
   assurance that it corresponds SDO to complete a live user.  RADIUS specifications
   defining attributes containing confidential information (such standard, as well as
   Tunnel-Password) should be careful to prohibit such attributes from
   being returned
     participate in response to an authorization check.  Also,
   [RFC5080] Section 2.1.1 notes that authentication mechanisms need the IETF in order to
   tie a sequence of Access-Request/Access-Challenge packets together
   into one authentication session.  The State Attribute is RECOMMENDED
   for this purpose.

   While [RFC2865] did not require authentication and integrity
   protection of RADIUS Access-Request packets, subsequent
   authentication mechanism specifications such as RADIUS/EAP [RFC3579]
   and Digest Authentication [RFC5090] have mandated authentication and
   integrity protection for certain RADIUS packets.  [RFC5080] Section
   2.1.1 makes this behavior RECOMMENDED for all Access-Request packets,
   including Access-Request packets performing authorization checks.  It
   is expected that specifications for new RADIUS authentication
   mechanisms will continue this practice. complete the associated RADIUS
     attributes specification.

Attribute scarcity
     The standard RADIUS protocol as defined in [RFC2865] attribute space is limited to 255 unique
     attributes.  Of these, only about half remain available for
     allocation.  In the Vendor-Specific space, the number of attributes
     available is a request-response
   protocol spoken between RADIUS clients and servers.  A single RADIUS
   Access-Request packet will solicit function of the format of the attribute (the size of
     the Vendor type field).

   Along with these advantages, some limitations of VSA usage are noted
   in response at most a single
   Access-Accept, Access-Reject or Access-Challenge packet, sent [RFC2865] Section 5.26:

      This Attribute is available to allow vendors to support their own
      extended Attributes not suitable for general usage.  It MUST NOT
      affect the
   IP address and port operation of the RADIUS Client that originated protocol.

      Servers not equipped to interpret the Access-
   Request.  Similarly, vendor-specific information
      sent by a single Change-of-Authorization (CoA)-Request
   packet [RFC5176] will solicit client MUST ignore it (although it may be reported).
      Clients which do not receive desired vendor-specific information
      SHOULD make an attempt to operate without it, although they may do
      so (and report they are doing so) in response at most a single CoA-ACK or
   CoA-NAK packet, sent to degraded mode.

3.3.1.  Interoperability Considerations

   Vendors and SDOs are reminded that the IP address standard RADIUS attribute
   space, and port of the Dynamic
   Authorization Client (DAC) that originated enumerated value space for enumerated attributes, are
   reserved for allocation through work published via the CoA-Request. A single
   Disconnect-Request packet will solicit IETF, as noted
   in response at most a single
   Disconnect-ACK or Disconnect-NAK packet, sent [RFC3575] Section 2.1.  Some vendors and SDOs have in the past
   performed self-allocation by assigning vendor-specific meaning to
   "unused" values from the IP address standard RADIUS attribute ID or enumerated
   value space.  This self-allocation results in interoperability
   issues, and
   port of the Dynamic Authorization Client (DAC) that originated is counter-productive.  Similarly, the
   Disconnect-Request.  Changes to this model are likely to require
   major revisions to existing implementations and so this Vendor-Specific
   enumeration practice discussed in [RFC2882] Section 2.2.1 is NOT
   RECOMMENDED.

   The Length field in the RADIUS packet header is defined in [RFC2865]
   Section 3.  It

   If it is noted there that not possible to follow the maximum length of a RADIUS
   packet is 4096 octets.  As a result, attribute designers IETF process, vendors and SDOs
   SHOULD NOT
   assume that self-allocate an attribute from their Vendor-Specific space,
   and define an appropriate value for it.

   As a RADIUS implementation can successfully process RADIUS
   packets larger than 4096 octets.

   Even when packets are less than 4096 octets, they may be larger than
   the Path Maximum Transmission Unit (PMTU).  Any packet larger than side note, [RFC2865] Section 5.26 uses the PMTU will be fragmented, making communications more brittle as
   firewalls and filtering devices often discard fragments.  Transport
   of fragmented UDP packets appears term "Vendor-Specific
   Attribute" to refer to an encoding format which can be a poorly tested code path on
   network devices.  Some devices appear used by
   individual vendors to define attributes not suitable for general
   usage.  However, since then VSAs have also become widely used by SDOs
   defining attributes intended for multi-vendor interoperability. As
   such, these attributes are not specific to any single vendor, and the
   term "Vendor-Specific" may be misleading.  An alternate term which
   better describes this use case is SDO-Specific Attribute (SSA).

   The design and specification of VSAs for multi-vendor usage SHOULD be incapable
   undertaken with the same level of transporting
   fragmented UDP packets, making it difficult to deploy care as standard RADIUS in a
   network where those devices are deployed.  We RECOMMEND attributes.
   Specifically, the provisions of this document that apply to standard
   RADIUS
   messages be kept as small possible.

   If a situation is envisaged where it may be necessary attributes also apply to carry
   authentication, authorization SSAs or accounting data in a packet larger VSAs for multi-vendor usage.

3.3.2.  Vendor Allocations

3.3.3.  SDO Allocations

   SDO RADIUS Attribute specifications SHOULD allocate attributes from
   the vendor space, rather than 4096 octets, then one requesting an allocation from the
   RADIUS standard attribute space, for attributes matching any of the
   following approaches is
   RECOMMENDED:

     1. Utilization of criteria:

      * attributes relying on data types not defined within RADIUS

      * attributes intended primarily for use within an SDO

      * attributes intended primarily for use within a sequence group of packets.
        For SDOs.

   Any new RADIUS authentication, attributes or values intended for interoperable use
   across a sequence broad spectrum of Access-Request/ Access-
        Challenge packets would be used.  For this the Internet Community SHOULD follow the
   normal IETF process, and SHOULD result in allocations from the RADIUS
   standard space.

   The recommendation for SDOs to be feasible,
        attribute designers need allocate attributes from a vendor
   space rather than via the IETF process is a recognition that SDOs may
   desire to enable inclusion assert change control over their own RADIUS specifications.
   This change control can be obtained by requesting a PEC from the
   Internet Assigned Number Authority (IANA), for use as a Vendor-Id
   within a Vendor-Specific attribute.  Further allocation of attributes that
        can consume considerable
   inside of the VSA space within Access-Challenge packets.
        To maintain compatibility with existing NASes, either defined by that Vendor-Id is subject solely
   to the discretion of the SDO.  Similarly, the use of
        Access-Challenge packets needs to be permissible (as with
        RADIUS/EAP, defined in [RFC3579]), data types
   (complex or support for receipt not) within that VSA space is solely under the discretion
   of an
        Access-Challenge needs to be indicated by the NAS (as in RADIUS
        Location [RFC5580]). Also, SDO.  It is RECOMMENDED that SDOs follow the specification needs guidelines
   outlined here, which are intended to clearly
        describe how attribute splitting is enable maximum interoperability
   with minimal changes to existing systems.

   It should be signalled understood that SDOs do not have to rehost VSAs into the
   standards space solely for the purpose of obtaining IETF review.
   Rehosting puts pressure on the standards space, and how
        attributes included within may be harmful to
   interoperability, since it can create two ways to provision the sequence are same
   service.  Rehosting may also require changes to be interpreted,
        without requiring stateful operation.  Unfortunately, previous
        specifications have the RADIUS data model
   which will affect implementations that do not always exhibited intend to support the required foresight.
        For example, even though very large filter rules
   SDO specifications.

3.3.4.  Publication of specifications

   SDOs are
        conceivable, encouraged to seek early review of SSA specifications by the NAS-Filter-Rule Attribute defined in [RFC4849]
   IETF.  This review may be initiated by sending mail to the AAA
   Doctors list [DOCTORS], with the understanding that this review is a
   voluntary-based service offered on best-effort basis.  Since the IETF
   is not permitted in an Access-Challenge packet, nor is a
        mechanism specified membership organization, in order to allow a set of NAS-Filter-Rule attributes enable the RADIUS SSA
   specification to be split across an Access-Request/Access-Challenge sequence.

        In reviewed, it is RECOMMENDED that it be made
   publicly available; this also encourages interoperability.  Where the case of
   RADIUS accounting, transporting large amounts of
        data would require a sequence of Accounting-Request packets.
        This SSA specification is embedded within a non-trivial change to RADIUS, since RADIUS accounting
        clients would need to larger document which
   cannot be modified to split made public, the RADIUS attribute stream
        across multiple Accounting-Requests, and billing servers would
        need to value definitions
   SHOULD be modified to re-assemble and interpret published instead as an Informational RFC, as with
   [RFC4679].  This process SHOULD be followed instead of requesting
   IANA allocations from within the standard RADIUS attribute
        stream.

     2. Utilization space.

   Similarly, vendors are encouraged to make their specifications
   publicly available, for maximum interoperability.  However, it is not
   necessary for them to request publication of names their VSA specifications
   as Informational RFCs by the IETF.

   All other specifications, including new authentication,
   authorization, and/or security mechanisms SHOULD be allocated via the
   standard RADIUS space, as noted in [RFC3575] Section 2.1.

3.4.  Polymorphic Attributes

   A polymorphic attribute is one whose format or meaning is dynamic.
   For example, rather than values.

        Where an attribute relates to using a policy that could conceivably be
        pre-provisioned fixed data format, an attribute's
   format might change based on the NAS, then contents of another attribute.  Or,
   the meaning of an attribute may depend on earlier packets in a
   sequence.

   RADIUS server dictionary entries are typically static, enabling the name of
   user to enter the pre-provisioned
        policy can be transmitted in contents of an attribute, rather than attribute without support for
   changing the
        policy itself, which could be quite large.  An example format based on dynamic conditions.  However, this
   limitation on static types does not prevent implementations from
   implementing policies that return different attributes based on the
   contents of received attributes; this is the Filter-Id Attribute defined in [RFC2865] Section 5.11,
        which enables a set common feature of pre-provisioned filter rules to existing
   RADIUS implementations.

   In general, polymorphism is NOT RECOMMENDED.  Polymorphism rarely
   enables capabilities that would not be
        referenced by name.

     3. Utilization available through use of Packetization Layer Path MTU Discovery
        techniques, as specified in [RFC4821].  As a last resort, where
        the above techniques cannot be made to work, it may be possible
        to apply the techniques described
   multiple attributes.  Polymorphism requires code changes in [RFC4821] to discover the
        maximum supported RADIUS packet size on the path between a
   RADIUS client and a home server.  While server in situations where attributes with fixed formats would
   not require such changes.  Thus, polymorphism increases complexity
   while decreasing generality, without delivering any corresponding
   benefits.

   Note that changing an approach can
        avoid attribute's format dynamically is not the complexity of utilization of same
   thing as using a sequence of packets,
        dynamic discovery is likely to be time consuming fixed format and cannot be
        guaranteed to work with existing computing the attribute itself
   dynamically.  RADIUS implementations.  As authentication attributes such as User-Password,
   EAP-Message, etc. while being computed dynamically, use a
        result, this technique is not generally applicable. fixed
   format.

4.  IANA Considerations

   This document does not require that the IANA update any existing
   registry or create any new registry, but includes information that
   affects the IANA, which:

      * includes specific guidelines for Expert Reviewers appointed
        under the IANA considerations of [RFC3575]

      * includes guidelines that recommend against self allocation from
        the RADIUS standard attribute space in other SDO RADIUS
        Attribute specifications.

      * recommends that SDOs request a Private Enterprise Code (PEC)
        from the IANA, for use as a Vendor-Id within a Vendor-Specific
        attribute.

5.  Security Considerations

   This specification provides guidelines for the design of RADIUS
   attributes used in authentication, authorization and accounting.
   Threats and security issues for this application are described in
   [RFC3579] and [RFC3580]; security issues encountered in roaming are
   described in [RFC2607].

   Obfuscation of RADIUS attributes on a per-attribute basis is
   necessary in some cases.  The current standard mechanism for this is
   described in [RFC2865] Section 5.2 (for obscuring User-Password
   values) and is based on the MD5 algorithm specified in [RFC1321].
   The MD5 and SHA-1 algorithms have recently become a focus of scrutiny
   and concern in security circles, and as a result, the use of these
   algorithms in new attributes is NOT RECOMMENDED.  In addition,
   previous documents referred to this method as generating "encrypted"
   data.  This terminology is no longer accepted within the
   cryptographic community.

   Where new RADIUS attributes use cryptographic algorithms, algorithm
   negotiation SHOULD be supported.  Specification of a mandatory-to-
   implement algorithm is REQUIRED, and it is RECOMMENDED that the
   mandatory-to-implement algorithm be certifiable under FIPS 140
   [FIPS].

   Where new RADIUS attributes encapsulate complex data types, or
   transport opaque data, the security considerations discussed in
   Section 2.1.4 5.1 SHOULD be addressed.

   Message authentication in RADIUS is provided largely via the Message-
   Authenticator attribute.  See [RFC3579] Section 3.2, and also
   [RFC5080] 2.2.2, which says that client implementations SHOULD
   include a Message-Authenticator attribute in every Access-Request.

   In general, the security of the RADIUS protocol is poor.  Robust
   deployments SHOULD support a secure communications protocol such as
   IPSec.  See [RFC3579] Section 4, and [RFC3580] Section 5 for a more
   in-depth explanation of these issues.

   Implementations not following the suggestions outlined in this
   document may be subject to a problems such as ambiguous protocol
   decoding, packet loss leading to loss of billing information, and
   denial of service attacks.

5.1.  New Data Types and Complex Attributes

   The introduction of complex data types brings the potential for the
   introduction of new security vulnerabilities.  Experience shows that
   the common data types have few security vulnerabilities, or else that
   all known issues have been found and fixed.  New data types require
   new code, which may introduce new bugs, and therefore new attack
   vectors.

   Some systems permit complex attributes to be defined via a method
   that is more capable than traditional RADIUS dictionaries.  These
   systems can reduce the security threat of new types significantly,
   but they do not remove it entirely.

   RADIUS servers are highly valued targets, as they control network
   access and interact with databases that store usernames and
   passwords.  An extreme outcome of a vulnerability due to a new,
   complex type would be that an attacker is capable of taking complete
   control over the RADIUS server.

   The use of attributes representing opaque data does not reduce this
   threat.  The threat merely moves from the RADIUS server to the system
   that consumes that opaque data.

   The threat is particularly severe when the opaque data originates
   from the user, and is not validated by the NAS.  In those cases, the
   RADIUS server is potentially exposed to attack by malware residing on
   an unauthenticated host.

   Any system consuming opaque data that originates from a RADIUS system
   SHOULD be properly isolated from that RADIUS system, and SHOULD run
   with minimal privileges.  Any potential vulnerabilities in the non-
   RADIUS system will then have minimal impact on the security of the
   system as a whole.

6.  References

6.1.  Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
          Authentication Dial In User Service (RADIUS)", RFC 2865, June
          2000.

[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
          Authentication Dial In User Service)", RFC 3575, July 2003.

6.2.  Informative References

[RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of
          management information for TCP/IP-based internets", STD 16,
          RFC 1155, May 1990.

[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
          Network Management Protocol (SNMP)", STD 15, RFC 1157, May
          1990.

[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
          April 1992.

[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
          Implementation in Roaming", RFC 2607, June 1999.

[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.,
          and I. Goyret, "RADIUS Attributes for Tunnel Protocol
          Support", RFC 2868, June 2000.

[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions",
          RFC 2869, June 2000.

[RFC2882] Mitton, D, "Network Access Servers Requirements: Extended
          RADIUS Practices", RFC 2882, July 2000.

[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC
          3162, August 2001.

[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
          In User Service) Support For Extensible Authentication
          Protocol (EAP)", RFC 3579, September 2003.

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., Roese, J., "IEEE
          802.1X Remote Authentication Dial In User Service (RADIUS)
          Usage Guidelines", RFC3580, September 2003.

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
          RFC 3629, November 2003.

[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB
          Documents", RFC 4181, September 2005.

[RFC4663] Harrington, D., "Transferring MIB Work from IETF Bridge MIB WG
          to IEEE 802.1 WG", RFC 4663, September 2006.

[RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for
          Virtual LAN and Priority Support", RFC 4675, September 2006.

[RFC4679] Mammoliti, V., et al., "DSL Forum Vendor-Specific RADIUS
          Attributes", RFC 4679, September 2006.

[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix
          Attribute", RFC 4818, April 2007.

[RFC4821] Mathis, M. and Heffner, J, "Packetization Layer Path MTU
          Discovery", RFC 4821, March 2007.

[RFC4849] Congdon, P. et al, "RADIUS Filter-Rule Attribute", RFC 4849,
          April 2007.

[RFC5080] Nelson, D. and DeKok, A, "Common Remote Authentication Dial In
          User Service (RADIUS) Implementation Issues and Suggested
          Fixes", RFC 5080, December 2007.

[RFC5090] Sterman, B. et al., "RADIUS Extension for Digest
          Authentication", RFC 5090, February 2008.

[RFC5176] Chiba, M. et al., "Dynamic Authorization Extensions to Remote
          Authentication Dial In User Service (RADIUS)", RFC 5176,
          January 2008.

[DOCTORS] AAA Doctors Mailing list <aaa-doctors@ops.ietf.org>

[FIPS]    FIPS 140-3 (DRAFT), "Security Requirements for Cryptographic
          Modules", http://csrc.nist.gov/publications/fips/fips140-3/

[IEEE-802.1Q]
          IEEE Standards for Local and Metropolitan Area Networks: Draft
          Standard for Virtual Bridged Local Area Networks,
          P802.1Q-2003, January 2003.

[RFC5580] Tschofenig, H. (Ed.), "Carrying Location Objects in RADIUS and
          Diameter", RFC 5580, August 2009.

Appendix A - Design Guidelines

   The following text provides guidelines for the design of attributes
   used by the RADIUS protocol.  Specifications that follow these
   guidelines are expected to achieve maximum interoperability with
   minimal changes to existing systems.

A.1. Types matching the RADIUS data model

A.1.1. Transport of simple basic data types

   Does the data fit within the basic data types described in Section
   2.1.1, as outlined below?  If so, it SHOULD be encapsulated in a
   [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS
   VSA that uses one of the existing RADIUS data types. types:

      * 32-bit unsigned integer, in network byte order.

      * Enumerated data types, represented as a 32-bit unsigned integer
        with a list of name to value mappings.  (e.g., Service-Type)

      * Interface-Id (8 octet string in network byte order)

      * IPv4 address in network byte order.

      * IPv6 address in network byte order.

      * IPv6 prefix.

      * time as 32 bit unsigned value, in network byte order, and in
        seconds since 00:00:00 UTC, January 1, 1970.

      * string (i.e., binary data), totalling 253 octets or less in
        length. This includes the opaque encapsulation of data
        structures defined outside of RADIUS.  See also Appendix A.1.3,
        below.

      * UTF-8 text, totalling 253 octets or less in length.

   Note that the length limitations for VSAs of type String and Text are
   less than 253 octets, due to the additional overhead of the Vendor-
   Specific format.

   The following data also qualifies as "simple "basic data types":

      * Attributes grouped into a logical container, using the
        [RFC2868] tagging mechanism.  This approach is NOT
        RECOMMENDED (see Section 2.1.2), but is permissible where
        the alternatives are worse.

      * Attributes requiring the transport of more than 247 octets of
        Text or String data.  This includes the opaque encapsulation
        of data structures defined outside of RADIUS.  See also Section
        A.1.3, below.

   Nested groups or attributes do not qualify as "simple "basic data types", and
   SHOULD NOT be used.

A.1.2. Transport of Authentication and Security Data

   Does the data provide authentication and/or security capabilities for
   the RADIUS protocol, as outlined below?  If so, it SHOULD be
   encapsulated in a [RFC2865] format RADIUS attribute.  It SHOULD NOT
   be encapsulated in a [RFC2865] format RADIUS VSA.

      * Complex data types that carry authentication methods which
        RADIUS servers are expected to parse and verify as part of
        an authentication process.

      * Complex data types that carry security information intended
        to increase the security of the RADIUS protocol itself.

   Any data type carrying authentication and/or security data that is
   not meant to be parsed by a RADIUS server is an "opaque data type",
   as defined below.

A.1.3. Opaque data types

   Does the attribute encapsulate an existing data structure defined
   outside of the RADIUS specifications?  Can the attribute be treated
   as opaque data by RADIUS servers (including proxies?)  If both
   questions can be answered affirmatively, a complex structure MAY be
   used in a RADIUS specification.

   The specification of the attribute SHOULD define the encapsulating
   attribute to be of type String.  The specification SHOULD refer to an
   external document defining the structure.  The specification SHOULD
   NOT define or describe the structure, as discussed above in Section
   2.1.3.

A.2. Improper Data Types

   All data types other than the ones described above in Appendix A.1
   and Appendix B SHOULD NOT be used.  This section describes in detail
   a number of data types that are NOT RECOMMENDED in new RADIUS
   specifications.  Where possible, replacement data types are
   suggested.

A.2.1. Simple Basic Data Types

   Does the attribute use any of the following data types?  If so, the
   data type SHOULD be replaced with the suggested alternatives, or it
   SHOULD NOT be used at all.

      * Signed integers of any size.
        SHOULD NOT be used.  SHOULD be replaced with one or more
        unsigned integer attributes.  The definition of the attribute
        can contain information that would otherwise go into the sign
        value of the integer.

      * 8 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save three bytes.

      * 16 bit unsigned integers.
        SHOULD be replaced with 32-bit unsigned integer.  There is
        insufficient justification to save two bytes.

      * Unsigned integers of size other than 32
        SHOULD be replaced by an unsigned integer of 32 bits.
        There is insufficient justification to define a new size of
        integer.

      * Integers of any size in non-network byte order
        SHOULD be replaced by unsigned integer of 32 bits in network
        There is no reason to transport integers in any format other
        than network byte order.

      * Multi-field text strings.
        Each field SHOULD be encapsulated in a separate attribute.

      * Polymorphic attributes.
        Multiple attributes, each with a static data type SHOULD be
        defined instead.

      * Nested AVPs.
        Attributes should be defined in a flat typespace.

A.2.2. Complex Data Types

   Does the attribute:

   * define a complex data type not described in Appendix B,
   * that a RADIUS server and/or client is expected to parse,
     validate, or create the contents of via a dynamic computation?
     i.e. A type that cannot be treated as opaque data (Section A.1.3)

   * involve functionality that could be implemented without code
     changes on both the client and server?  (i.e. a type that doesn't
     require dynamic computation and verification, such as those
     performed for authentication or security attributes)

   If so, this data type SHOULD be replaced with simpler types, as
   discussed above in Appendix A.2.1.  Also see Section 2.1.3 for a
   discussion of why complex types are problematic.

A.3. Vendor-Specific formats

   Does the specification contain Vendor-Specific attributes that match
   any of the following criteria?  If so, the data type should be
   replaced with the suggested alternatives, or should not be used at
   all.

      * Vendor types of more than 8 bits.
        SHOULD NOT be used.  Vendor types of 8 bits SHOULD be used
        instead.

      * Vendor lengths of less than 8 bits.  (i.e., zero bits)
        SHOULD NOT be used.  Vendor lengths of 8 bits SHOULD be used
        instead.

      * Vendor lengths of more than 8 bits.
        SHOULD NOT be used.  Vendor lengths of 8 bits SHOULD be used
        instead.

      * Vendor-Specific contents that are not in Type-Length-Value
        format.
        SHOULD NOT be used.  Vendor-Specific attributes SHOULD be in
        Type-Length-Value format.

   In general, Vendor-Specific attributes SHOULD follow the [RFC2865]
   suggested format.  Vendor extensions to non-standard formats are NOT
   RECOMMENDED as they can negatively affect interoperability.

A.4. Changes to the RADIUS Operational Model

   Does the specification change the RADIUS operation model, as outlined
   in the list below?  If so, then another method of achieving the
   design objectives SHOULD be used.  Potential problem areas include:

      * Defining new commands in RADIUS using attributes.

        The addition of new commands to RADIUS MUST be handled via
        allocation of a new Code, and not by the use of an attribute.
        This restriction includes new commands created by overloading
        the Service-Type attribute to define new values that modify
        the functionality of Access-Request packets.

      * Using RADIUS as a transport protocol for data unrelated to
        authentication, authorization, or accounting.  Using RADIUS to
        transport authentication methods such as EAP is explicitly
        permitted, even if those methods require the transport of
        relatively large amounts of data.  Transport of opaque data
        relating to AAA is also permitted, as discussed above in
        Section 2.1.3. However, if the specification does not relate
        to AAA, then RADIUS SHOULD NOT be used.

      * Assuming support for packet lengths greater than 4096 octets.
        Attribute designers cannot assume that RADIUS implementations
        can successfully handle packets larger than 4096 octets.
        If a specification could lead to a RADIUS packet larger than
        4096 octets, then the alternatives described in Section 3.3
        SHOULD be considered.

      * Stateless operation.  The RADIUS protocol is stateless, and
        documents which require stateful protocol behavior without the
        use of the State Attribute need to be redesigned.

      * Provisioning of service in an Access-Reject.  Such provisioning
        is not permitted, and MUST NOT be used.  If limited access needs
        to be provided, then an Access-Accept with appropriate
        authorizations can be used instead.

      * Lack of user authentication or authorization restrictions.
        In an authorization check, where there is no demonstration of a
        live user, confidential data cannot be returned.  Where there
        is a link to a previous user authentication, the State attribute
        needs to be present.

      * Lack of per-packet integrity and authentication.
        It is expected that documents will support per-packet
        integrity and authentication.

      * Modification of RADIUS packet sequences.
        In RADIUS, each request is encapsulated in it's own packet, and
        elicits a single response that is sent to the requester.  Since
        changes to this paradigm are likely to require major
        modifications to RADIUS client and server implementations, they
        SHOULD be avoided if possible.
      For further details, see Section 3.3.

A.5. Allocation of attributes

   Does the attribute have a limited scope of applicability, as outlined
   below?  If so, then the attributes SHOULD be allocated from the
   Vendor-Specific space.

      * attributes intended for a vendor to support their own systems,
      and not suitable for general usage

      * attributes relying on data types not defined within RADIUS

      * attributes intended primarily for use within an SDO

      * attributes intended primarily for use within a group of SDOs.

   Note that the points listed above do not relax the recommendations
   discussed in this document.  Instead, they recognize that the RADIUS
   data model has limitations.  In certain situations where
   interoperability can be strongly constrained by the SDO or vendor, an
   expanded data model MAY be used.  We recommend, however, that the
   RADIUS data model SHOULD be used, even if it is marginally less
   efficient than alternatives.

   When attributes are used primarily within a group of SDOs, and are
   not applicable to the wider Internet community, we expect that one
   SDO will be responsible for allocation from their own private space.

Appendix B - Complex Attributes

   This section summarizes RADIUS attributes with complex data types
   that are defined in existing RFCs.

   This appendix is published for informational purposes only, and
   reflects the usage of attributes with complex data types at the time
   of the publication of this document.

B.1. CHAP-Password

   [RFC2865] Section 5.3 defines the CHAP-Password Attribute which is
   sent from the RADIUS client to the RADIUS server in an Access-
   Request.  The data type of the CHAP Identifier is not given, only the
   one octet length:

    0                   1                   2
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  CHAP Ident   |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Since this is an authentication attribute, code changes are required
   on the RADIUS client and server to support it, regardless of the
   attribute format.  Therefore, this complex data type is acceptable in
   this situation.

B.2. CHAP-Challenge

   [RFC2865] Section 5.40 defines the CHAP-Challenge Attribute which is
   sent from the RADIUS client to the RADIUS server in an Access-
   Request.  While the data type of the CHAP Identifier is given, the
   text also says:

      If the CHAP challenge value is 16 octets long it MAY be placed in
      the Request Authenticator field instead of using this attribute.

   Defining attributes to contain values taken from the RADIUS packet
   header is NOT RECOMMENDED.  Attributes should have values that are
   packed into a RADIUS AVP.

B.3. Tunnel-Password

   [RFC2868] Section 3.5 defines the Tunnel-Password Attribute, which is
   sent from the RADIUS server to the client in an Access-Accept.  This
   attribute includes Tag and Salt fields, as well as a string field
   which consists of three logical sub-fields: the Data-Length (one
   octet) and Password sub-fields (both of which are required), and the
   optional Padding sub-field.  The attribute appears as follows:

    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       |   Salt
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Salt (cont)  |   String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Since this is a security attribute and is encrypted, code changes are
   required on the RADIUS client and server to support it, regardless of
   the attribute format.  Therefore, this complex data type is
   acceptable in this situation.

B.4. ARAP-Password

   [RFC2869] Section 5.4 defines the ARAP-Password attribute, which is
   sent from the RADIUS client to the server in an Access-Request.  It
   contains four 4 octet values, instead of having a single Value field:

    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     |             Value1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value2
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |             Value4
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   As with the CHAP-Password attribute, this is an authentication
   attribute which would have required code changes on the RADIUS client
   and server regardless of format.

B.5. ARAP-Features

   [RFC2869] Section 5.5 defines the ARAP-Features Attribute, which is
   sent from the RADIUS server to the client in an Access-Accept or
   Access-Challenge.  It contains a compound string of two single octet
   values, plus three 4-octet values, which the RADIUS client
   encapsulates in a feature flags packet in the ARAP protocol:

   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     |     Value1    |    Value2     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value3                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value4                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Value5                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Unlike the previous attributes, this attribute contains no encrypted
   component, nor is it directly involved in authentication.  The
   individual sub-fields therefore could have been encapsulated in
   separate attributes.

   While the contents of this attribute is intended to be placed in an
   ARAP packet, the fields need to be set by the RADIUS server.  Using
   standard RADIUS data types would have simplified RADIUS server
   implementations, and subsequent management.  The current form of the
   attribute requires either the RADIUS server implementation, or the
   RADIUS server administrator, to understand the internals of the ARAP
   protocol.

B.6. Connect-Info

   [RFC2869] Section 5.11 defines the Connect-Info attribute, which is
   used to indicate the nature of the connection.

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

   Even though the type is Text, the rest of the description indicates
   that it is a complex attribute:

      The Text field consists of UTF-8 encoded 10646 _8_ characters.
      The connection speed SHOULD be included at the beginning of the
      first Connect-Info attribute in the packet.  If the transmit and
      receive connection speeds differ, they may both be included in the
      first attribute with the transmit speed first (the speed the NAS
      modem transmits at), a slash (/), the receive speed, then
      optionally other information.
      For example, "28800 V42BIS/LAPM" or "52000/31200 V90"

      More than one Connect-Info attribute may be present in an
      Accounting-Request packet to accommodate expected efforts by ITU
      to have modems report more connection information in a standard
      format that might exceed 252 octets.

   This attribute contains no encrypted component, and is it not
   directly involved in authentication.  The individual sub-fields could
   therefore have been encapsulated in separate attributes.

   Since the form of the text string is well defined, there is no
   benefit in using a text string.  Instead, an integer attribute should
   have been assigned for each of the transmit speed and the receive
   speed.  A separate enumerated integer should have been assigned for
   the additional information, as is done for the NAS-Port-Type
   attribute.

B.7. Framed-IPv6-Prefix

   [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and
   [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix
   Attribute; these attributes are sent from the RADIUS server to the
   client in an Access-Accept.

    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     |  Reserved     | Prefix-Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                Prefix                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The sub-fields encoded in these attributes are strongly related, and
   there was no previous definition of this data structure that could be
   referenced.  Support for this attribute requires code changes on both
   the client and server, due to a new data type being defined.  In this
   case it appears to be acceptable to encode them in one attribute.

B.8. Egress-VLANID

   [RFC4675] Section 2.1 defines the Egress-VLANID Attribute which can
   be sent by a RADIUS client or server.

       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     |            Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              Value (cont)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   While it appears superficially to be of type Integer, the Value field
   is actually a packed structure, as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Tag Indic.   |        Pad            |       VLANID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The length of the VLANID field is defined by the [IEEE-802.1Q]
   specification.  The Tag indicator field is either 0x31 or 0x32, for
   compatibility with the Egress-VLAN-Name, as discussed below.  The
   complex structure of Egress-VLANID overlaps with that of the base
   Integer data type, meaning that no code changes are required for a
   RADIUS server to support this attribute.  Code changes are required
   on the NAS, if only to implement the VLAN ID enforcement.

   Given the IEEE VLAN requirements and the limited data model of
   RADIUS, the chosen method is likely the best of the possible
   alternatives.

B.9. Egress-VLAN-Name

   [RFC4675] Section 2.3 defines the Egress-VLAN-Name Attribute which
   can be sent by a RADIUS client or server.

       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 Indic.  |   String...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Tag Indicator is either the character '1' or '2', which in ASCII
   map to the identical values for Tag Indicator in Egress-VLANID,
   above.  The complex structure of this attribute is acceptable for
   reasons identical to those given for Egress-VLANID.

Acknowledgments

   We would like to acknowledge David Nelson, Bernard Aboba, Emile van
   Bergen, Barney Wolff and Glen Zorn for contributions to this
   document.

Authors' Addresses

   Greg Weber
   Knoxville, TN  37932
   USA

   Email: gdweber@gmail.com

   Alan DeKok
   The FreeRADIUS Server Project
   http://freeradius.org/

   Email: aland@freeradius.org