Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6929

Remote Authentication Dial In User Service (RADIUS) Protocol Extensions

Pages: 68
Proposed Standard
Updates:  286535756158
Part 1 of 3 – Pages 1 to 20
None   None   Next

Top   ToC   RFC6929 - Page 1
Internet Engineering Task Force (IETF)                          A. DeKok
Request for Comments: 6929                                Network RADIUS
Updates: 2865, 3575, 6158                                        A. Lior
Category: Standards Track                                     April 2013
ISSN: 2070-1721

          Remote Authentication Dial-In User Service (RADIUS)
                          Protocol Extensions

Abstract

The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6929. Copyright Notice Copyright (c) 2013 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.
Top   ToC   RFC6929 - Page 2

Table of Contents

1. Introduction ....................................................3 1.1. Caveats and Limitations ....................................5 1.1.1. Failure to Meet Certain Goals .......................5 1.1.2. Implementation Recommendations ......................5 1.2. Terminology ................................................6 1.3. Requirements Language ......................................7 2. Extensions to RADIUS ............................................7 2.1. Extended Type ..............................................8 2.2. Long Extended Type .........................................9 2.3. TLV Data Type .............................................12 2.3.1. TLV Nesting ........................................14 2.4. EVS Data Type .............................................14 2.5. Integer64 Data Type .......................................16 2.6. Vendor-Id Field ...........................................16 2.7. Attribute Naming and Type Identifiers .....................17 2.7.1. Attribute and TLV Naming ...........................17 2.7.2. Attribute Type Identifiers .........................18 2.7.3. TLV Identifiers ....................................18 2.7.4. VSA Identifiers ....................................18 2.8. Invalid Attributes ........................................19 3. Attribute Definitions ..........................................21 3.1. Extended-Type-1 ...........................................21 3.2. Extended-Type-2 ...........................................22 3.3. Extended-Type-3 ...........................................23 3.4. Extended-Type-4 ...........................................24 3.5. Long-Extended-Type-1 ......................................25 3.6. Long-Extended-Type-2 ......................................26 4. Vendor-Specific Attributes .....................................27 4.1. Extended-Vendor-Specific-1 ................................28 4.2. Extended-Vendor-Specific-2 ................................29 4.3. Extended-Vendor-Specific-3 ................................30 4.4. Extended-Vendor-Specific-4 ................................31 4.5. Extended-Vendor-Specific-5 ................................32 4.6. Extended-Vendor-Specific-6 ................................34 5. Compatibility with Traditional RADIUS ..........................35 5.1. Attribute Allocation ......................................35 5.2. Proxy Servers .............................................36
Top   ToC   RFC6929 - Page 3
   6. Guidelines .....................................................37
      6.1. Updates to RFC 6158 .......................................37
      6.2. Guidelines for Simple Data Types ..........................38
      6.3. Guidelines for Complex Data Types .........................38
      6.4. Design Guidelines for the New Types .......................39
      6.5. TLV Guidelines ............................................40
      6.6. Allocation Request Guidelines .............................40
      6.7. Allocation Request Guidelines for TLVs ....................41
      6.8. Implementation Guidelines .................................42
      6.9. Vendor Guidelines .........................................42
   7. Rationale for This Design ......................................42
      7.1. Attribute Audit ...........................................43
   8. Diameter Considerations ........................................44
   9. Examples .......................................................44
      9.1. Extended Type .............................................46
      9.2. Long Extended Type ........................................47
   10. IANA Considerations ...........................................50
      10.1. Attribute Allocations ....................................50
      10.2. RADIUS Attribute Type Tree ...............................50
      10.3. Allocation Instructions ..................................52
           10.3.1. Requested Allocation from the Standard Space ......52
           10.3.2. Requested Allocation from the Short
                   Extended Space ....................................52
           10.3.3. Requested Allocation from the Long
                   Extended Space ....................................52
           10.3.4. Allocation Preferences ............................52
           10.3.5. Extending the Type Space via the TLV Data Type ....53
           10.3.6. Allocation within a TLV ...........................53
           10.3.7. Allocation of Other Data Types ....................54
   11. Security Considerations .......................................54
   12. References ....................................................54
      12.1. Normative References .....................................54
      12.2. Informative References ...................................55
   13. Acknowledgments ...............................................55
   Appendix A. Extended Attribute Generator Program ..................56

1. Introduction

Under current allocation pressure, we expect that the RADIUS Attribute Type space will be exhausted by 2014 or 2015. We therefore need a way to extend the type space so that new specifications may continue to be developed. Other issues have also been shown with RADIUS. The attribute grouping method defined in [RFC2868] has been shown to be impractical, and a more powerful mechanism is needed. Multiple Attributes have been defined that transport more than the 253 octets of data originally envisioned with the protocol. Each of these attributes is handled as a "special case" inside of RADIUS implementations, instead of as a general method. We therefore also
Top   ToC   RFC6929 - Page 4
   need a standardized method of transporting large quantities of data.
   Finally, some vendors are close to allocating all of the Attributes
   within their Vendor-Specific Attribute space.  It would be useful to
   leverage changes to the base protocol for extending the Vendor-
   Specific Attribute space.

   We satisfy all of these requirements through the following changes
   given in this document:

   * Defining an "Extended Type" format, which adds 8 bits of "Extended
     Type" to the RADIUS Attribute Type space, by using one octet of the
     "Value" field.  This method gives us a general way of extending the
     Attribute Type space (Section 2.1).

   * Allocating 4 attributes as using the format of "Extended Type".
     This allocation extends the RADIUS Attribute Type space by
     approximately 1000 values (Sections 3.1, 3.2, 3.3, and 3.4).

   * Defining a "Long Extended Type" format, which inserts an additional
     octet between the "Extended Type" octet and the "Value" field.
     This method gives us a general way of adding more functionality to
     the protocol (Section 2.2).

   * Defining a method that uses the additional octet in the "Long
     Extended Type" to indicate data fragmentation across multiple
     Attributes.  This method provides a standard way for an Attribute
     to carry more than 253 octets of data (Section 2.2).

   * Allocating 2 attributes as using the format "Long Extended Type".
     This allocation extends the RADIUS Attribute Type space by an
     additional 500 values (Sections 3.5 and 3.6).

   * Defining a new "Type-Length-Value" (TLV) data type.  This data type
     allows an attribute to carry TLVs as "sub-Attributes", which can in
     turn encapsulate other TLVs as "sub-sub-Attributes".  This change
     creates a standard way to group a set of Attributes (Section 2.3).

   * Defining a new "Extended-Vendor-Specific" (EVS) data type.  This
     data type allows an attribute to carry Vendor-Specific Attributes
     (VSAs) inside of the new Attribute formats (Section 2.4).

   * Defining a new "integer64" data type.  This data type allows
     counters that track more than 2^32 octets of data (Section 2.5).

   * Allocating 6 attributes using the new EVS data type.  This
     allocation extends the Vendor-Specific Attribute Type space by over
     1500 values (Sections 4.1 through 4.6).
Top   ToC   RFC6929 - Page 5
   * Defining the "Vendor-Id" for Vendor-Specific Attributes to
     encompass the entire 4 octets of the Vendor field.  [RFC2865]
     Section 5.26 defined it to be 3 octets, with the fourth octet being
     zero (Section 2.6).

   * Describing compatibility with existing RADIUS systems (Section 5).

   * Defining guidelines for the use of these changes for IANA,
     implementations of this specification, and for future RADIUS
     specifications (Section 6).

   As with any protocol change, the changes defined here are the result
   of a series of compromises.  We have tried to find a balance between
   flexibility, space in the RADIUS message, compatibility with existing
   deployments, and difficulty of implementation.

1.1. Caveats and Limitations

This section describes some caveats and limitations of the proposal.

1.1.1. Failure to Meet Certain Goals

One goal that was not met by the above modifications is to have an incentive for standards to use the new space. That incentive is being provided by the exhaustion of the standard space.

1.1.2. Implementation Recommendations

It is RECOMMENDED that implementations support this specification. It is RECOMMENDED that new specifications use the formats defined in this specification. The alternative to the above recommendations is a circular argument of not implementing this specification because no other standards reference it, and also not defining new standards referencing this specification because no implementations exist. As noted earlier, the standard space is almost entirely allocated. Ignoring the looming crisis benefits no one.
Top   ToC   RFC6929 - Page 6

1.2. Terminology

This document uses the following terms: Silently discard This means the implementation discards the packet without further processing. The implementation MAY provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. Invalid attribute This means that the Length field of an Attribute is valid (as per [RFC2865], Section 5, top of page 25) but the contents of the Attribute do not follow the correct format, for example, an Attribute of type "address" that encapsulates more than four, or less than four, octets of data. See Section 2.8 for a more complete definition. Standard space This refers to codes in the RADIUS Attribute Type space that are allocated by IANA and that follow the format defined in Section 5 of [RFC2865]. Extended space This refers to codes in the RADIUS Attribute Type space that require the extensions defined in this document and are an extension of the standard space, but that cannot be represented within the standard space. Short extended space This refers to codes in the extended space that use the "Extended Type" format. Long extended space This refers to codes in the extended space that use the "Long Extended Type" format. The following terms are used here with the meanings defined in BCP 26 [RFC5226]: "namespace", "assigned value", "registration", "Private Use", "Reserved", "Unassigned", "IETF Review", and "Standards Action".
Top   ToC   RFC6929 - Page 7

1.3. Requirements Language

In this document, several words are used to signify the requirements of the specification. 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].

2. Extensions to RADIUS

This section defines two new Attribute formats: "Extended Type" and "Long Extended Type". It defines a new Type-Length-Value (TLV) data type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 data type. It defines a new method for naming attributes and identifying Attributes using the new Attribute formats. It finally defines the new term "invalid attribute" and describes how it affects implementations. The new Attribute formats are designed to be compatible with the Attribute format given in [RFC2865] Section 5. The meaning and interpretation of the Type and Length fields are unchanged from that specification. This reuse allows the new formats to be compatible with RADIUS implementations that do not implement this specification. Those implementations can simply ignore the "Value" field of an attribute or forward it verbatim. The changes to the Attribute format come about by "stealing" one or more octets from the "Value" field. This change has the effect that the "Value" field of [RFC2865] Section 5 contains both the new octets given here and any attribute-specific Value. The result is that "Value"s in this specification are limited to less than 253 octets in size. This limitation is overcome through the use of the "Long Extended Type" format. We reiterate that the formats given in this document do not insert new data into an attribute. Instead, we "steal" one octet of Value, so that the definition of the Length field remains unchanged. The new Attribute formats are designed to be compatible with the Attribute format given in [RFC2865] Section 5. The meaning and interpretation of the Type and Length fields is unchanged from that specification. This reuse allows the new formats to be compatible with RADIUS implementations that do not implement this specification. Those implementations can simply ignore the "Value" field of an attribute or forward it verbatim.
Top   ToC   RFC6929 - Page 8

2.1. Extended Type

This section defines a new Attribute format, called "Extended Type". A summary of the Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type This field is identical to the Type field of the Attribute format defined in [RFC2865] Section 5. Length The Length field is one octet and indicates the length of this Attribute, including the Type, Length, "Extended-Type", and "Value" fields. Permitted values are between 4 and 255. If a client or server receives an Extended Attribute with a Length of 2 or 3, then that Attribute MUST be considered to be an "invalid attribute" and handled as per Section 2.8, below. Extended-Type The Extended-Type field is one octet. Up-to-date values of this field are specified according to the policies and rules described in Section 10. Unlike the Type field defined in [RFC2865] Section 5, no values are allocated for experimental or implementation-specific use. Values 241-255 are reserved and MUST NOT be used. The Extended-Type is meaningful only within a context defined by the Type field. That is, this field may be thought of as defining a new type space of the form "Type.Extended-Type". See Section 3.5, below, for additional discussion. A RADIUS server MAY ignore Attributes with an unknown "Type.Extended-Type". A RADIUS client MAY ignore Attributes with an unknown "Type.Extended-Type".
Top   ToC   RFC6929 - Page 9
   Value

      This field is similar to the "Value" field of the Attribute format
      defined in [RFC2865] Section 5.  The format of the data MUST be a
      valid RADIUS data type.

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

      The addition of the Extended-Type field decreases the maximum
      length for attributes of type "text" or "string" from 253 to
      252 octets.  Where an Attribute needs to carry more than
      252 octets of data, the "Long Extended Type" format MUST be used.

   Experience has shown that the "experimental" and "implementation-
   specific" attributes defined in [RFC2865] Section 5 have had little
   practical value.  We therefore do not continue that practice here
   with the Extended-Type field.

2.2. Long Extended Type

This section defines a new Attribute format, called "Long Extended Type". It leverages the "Extended Type" format in order to permit the transport of attributes encapsulating more than 253 octets of data. A summary of the Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type This field is identical to the Type field of the Attribute format defined in [RFC2865] Section 5. Length The Length field is one octet and indicates the length of this Attribute, including the Type, Length, Extended-Type, and "Value" fields. Permitted values are between 5 and 255. If a client or
Top   ToC   RFC6929 - Page 10
      server receives a "Long Extended Type" with a Length of 2, 3, or
      4, then that Attribute MUST be considered to be an "invalid
      attribute" and handled as per Section 2.8, below.

      Note that this Length is limited to the length of this fragment.
      There is no field that gives an explicit value for the total size
      of the fragmented attribute.

   Extended-Type

      This field is identical to the Extended-Type field defined above
      in Section 2.1.

   M (More)

      The More field is one (1) bit in length and indicates whether or
      not the current attribute contains "more" than 251 octets of data.
      The More field MUST be clear (0) if the Length field has a value
      of less than 255.  The More field MAY be set (1) if the Length
      field has a value of 255.

      If the More field is set (1), it indicates that the "Value" field
      has been fragmented across multiple RADIUS attributes.  When the
      More field is set (1), the Attribute MUST have a Length field of
      value 255, there MUST be an attribute following this one, and the
      next attribute MUST have both the same Type and "Extended Type".
      That is, multiple fragments of the same value MUST be in order and
      MUST be consecutive attributes in the packet, and the last
      attribute in a packet MUST NOT have the More field set (1).

      That is, a packet containing a fragmented attribute needs to
      contain all fragments of the Attribute, and those fragments need
      to be contiguous in the packet.  RADIUS does not support
      inter-packet fragmentation, which means that fragmenting an
      attribute across multiple packets is impossible.

      If a client or server receives an attribute fragment with the
      "More" field set (1) but for which no subsequent fragment can be
      found, then the fragmented attribute is considered to be an
      "invalid attribute" and handled as per Section 2.8, below.

   Reserved

      This field is 7 bits long and is reserved for future use.
      Implementations MUST set it to zero (0) when encoding an attribute
      for sending in a packet.  The contents SHOULD be ignored on
      reception.
Top   ToC   RFC6929 - Page 11
      Future specifications may define additional meaning for this
      field.  Implementations therefore MUST NOT treat this field as
      invalid if it is non-zero.

   Value

      This field is similar to the "Value" field of the Attribute format
      defined in [RFC2865] Section 5.  It may contain a complete set of
      data (when the Length field has a value of less than 255), or it
      may contain a fragment of data.

      The "Value" field is one or more octets.

      Implementations supporting this specification MUST use the
      identifier of "Type.Extended-Type" to determine the interpretation
      of the "Value" field.

      Any interpretation of the resulting data MUST occur after the
      fragments have been reassembled.  The length of the data MUST be
      taken as the sum of the lengths of the fragments (i.e., "Value"
      fields) from which it is constructed.  The format of the data
      SHOULD be a valid RADIUS data type.  If the reassembled data does
      not match the expected format, all fragments MUST be treated as
      "invalid attributes", and the reassembled data MUST be discarded.

      We note that the maximum size of a fragmented attribute is limited
      only by the RADIUS packet length limitation (i.e., 4096 octets,
      not counting various headers and overhead).  Implementations MUST
      be able to handle the case where one fragmented attribute
      completely fills the packet.

   This definition increases the RADIUS Attribute Type space as above
   but also provides for transport of Attributes that could contain more
   than 253 octets of data.

   Note that [RFC2865] Section 5 says:

      If multiple Attributes with the same Type are present, the order
      of Attributes with the same Type MUST be preserved by any proxies.
      The order of Attributes of different Types is not required to be
      preserved.  A RADIUS server or client MUST NOT have any
      dependencies on the order of attributes of different types.  A
      RADIUS server or client MUST NOT require attributes of the same
      type to be contiguous.

   These requirements also apply to the "Long Extended Type" Attribute,
   including fragments.  Implementations MUST be able to process
   non-contiguous fragments -- that is, fragments that are mixed
Top   ToC   RFC6929 - Page 12
   together with other attributes of a different Type.  This will allow
   them to accept packets, so long as the Attributes can be correctly
   decoded.

2.3. TLV Data Type

We define a new data type in RADIUS, called "tlv". The "tlv" data type is an encapsulation layer that permits the "Value" field of an Attribute to contain new sub-Attributes. These sub-Attributes can in turn contain "Value"s of data type TLV. This capability both extends the Attribute space and permits "nested" attributes to be used. This nesting can be used to encapsulate or group data into one or more logical containers. The "tlv" data type reuses the RADIUS Attribute format, as given below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV-Type | TLV-Length | TLV-Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV-Type The TLV-Type field is one octet. Up-to-date values of this field are specified according to the policies and rules described in Section 10. Values 254-255 are "Reserved" for use by future extensions to RADIUS. The value 26 has no special meaning and MUST NOT be treated as a Vendor-Specific Attribute. As with the Extended-Type field defined above, the TLV-Type is meaningful only within the context defined by "Type" fields of the encapsulating Attributes. That is, the field may be thought of as defining a new type space of the form "Type.Extended-Type.TLV-Type". Where TLVs are nested, the type space is of the form "Type.Extended-Type.TLV-Type.TLV-Type", etc. A RADIUS server MAY ignore Attributes with an unknown "TLV-Type". A RADIUS client MAY ignore Attributes with an unknown "TLV-Type". A RADIUS proxy SHOULD forward Attributes with an unknown "TLV-Type" verbatim.
Top   ToC   RFC6929 - Page 13
   TLV-Length

      The TLV-Length field is one octet and indicates the length of this
      TLV, including the TLV-Type, TLV-Length, and TLV-Value fields.  It
      MUST have a value between 3 and 255.  If a client or server
      receives a TLV with an invalid TLV-Length, then the Attribute that
      encapsulates that TLV MUST be considered to be an "invalid
      attribute" and handled as per Section 2.8, below.

   TLV-Value

      The TLV-Value field is one or more octets and contains information
      specific to the Attribute.  The format and length of the TLV-Value
      field are determined by the TLV-Type and TLV-Length fields.

      The TLV-Value field SHOULD encapsulate a standard RADIUS data
      type.  Non-standard data types SHOULD NOT be used within TLV-Value
      fields.  We note that the TLV-Value field MAY also contain one or
      more attributes of data type TLV; data type TLV allows for simple
      grouping and multiple layers of nesting.

      The TLV-Value field is limited to containing 253 or fewer octets
      of data.  Specifications that require a TLV to contain more than
      253 octets of data are incompatible with RADIUS and need to be
      redesigned.  Specifications that require the transport of empty
      "Value"s (i.e., Length = 2) are incompatible with RADIUS and need
      to be redesigned.

      The TLV-Value field MUST NOT contain data using the "Extended
      Type" formats defined in this document.  The base Extended
      Attributes format allows for sufficient flexibility that nesting
      them inside of a TLV offers little additional value.

   This TLV definition is compatible with the suggested format of the
   "String" field of the Vendor-Specific Attribute, as defined in
   [RFC2865] Section 5.26, though that specification does not discuss
   nesting.

   Vendors MAY use attributes of type "TLV" in any Vendor-Specific
   Attribute.  It is RECOMMENDED to use type "TLV" for VSAs, in
   preference to any other format.

   If multiple TLVs with the same TLV-Type are present, the order of
   TLVs with the same TLV-Type MUST be preserved by any proxies.  The
   order of TLVs of different TLV-Types is not required to be preserved.
   A RADIUS server or client MUST NOT have any dependencies on the order
   of TLVs of different TLV-Types.  A RADIUS server or client MUST NOT
   require TLVs of the same TLV-Type to be contiguous.
Top   ToC   RFC6929 - Page 14
   The interpretation of multiple TLVs of the same TLV-Type MUST be that
   of a logical "and", unless otherwise specified.  That is, multiple
   TLVs are interpreted as specifying an unordered set of values.
   Specifications SHOULD NOT define TLVs to be interpreted as a logical
   "or".  Doing so would mean that a RADIUS client or server would make
   an arbitrary and non-deterministic choice among the values.

2.3.1. TLV Nesting

TLVs may contain other TLVs. When this occurs, the "container" TLV MUST be completely filled by the "contained" TLVs. That is, the "container" TLV-Length field MUST be exactly two (2) more than the sum of the "contained" TLV-Length fields. If the "contained" TLVs overfill the "container" TLV, the "container" TLV MUST be considered to be an "invalid attribute" and handled as described in Section 2.8, below. The depth of TLV nesting is limited only by the restrictions on the TLV-Length field. The limit of 253 octets of data results in a limit of 126 levels of nesting. However, nesting depths of more than 4 are NOT RECOMMENDED. They have not been demonstrated to be necessary in practice, and they appear to make implementations more complex. Reception of packets with such deeply nested TLVs may indicate implementation errors or deliberate attacks. Where implementations do not support deep nesting of TLVs, it is RECOMMENDED that the unsupported layers are treated as "invalid attributes".

2.4. EVS Data Type

We define a new data type in RADIUS, called "evs", for "Extended- Vendor-Specific". The "evs" data type is an encapsulation layer that permits the EVS-Value field of an Attribute to contain a Vendor-Id, followed by an EVS-Type, and then vendor-defined data. This data can in turn contain valid RADIUS data types or any other data as determined by the vendor. This data type is intended for use in attributes that carry vendor- specific information, as is done with the Vendor-Specific Attribute (Attribute number 26). It is RECOMMENDED that this data type be used by a vendor only when the Vendor-Specific Attribute Type space has been fully allocated. Where [RFC2865] Section 5.26 makes a recommendation for the format of the data following the Vendor-Id, we give a strict definition. Experience has shown that many vendors have not followed the [RFC2865] recommendations, leading to interoperability issues. We hope here to give vendors sufficient flexibility as to meet their needs while minimizing the use of non-standard VSA formats.
Top   ToC   RFC6929 - Page 15
   The "evs" data type MAY be used in Attributes having the format of
   "Extended Type" or "Long Extended Type".  It MUST NOT be used in any
   other Attribute definition, including standard RADIUS attributes,
   TLVs, and VSAs.

   A summary of the "evs" data type format is shown below.  The fields
   are transmitted from left to right.

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

   Vendor-Id

      The 4 octets of the Vendor-Id field are the Network Management
      Private Enterprise Code [PEN] of the vendor in network byte order.

   EVS-Type

      The EVS-Type field is one octet.  Values are assigned at the sole
      discretion of the vendor.

   EVS-Value

      The EVS-Value field is one or more octets.  It SHOULD encapsulate
      a standard RADIUS data type.  Using non-standard data types is NOT
      RECOMMENDED.  We note that the EVS-Value field may be of data type
      TLV.  However, it MUST NOT be of data type "evs", as the use cases
      are unclear for one vendor delegating Attribute Type space to
      another vendor.

      The actual format of the information is site or application
      specific, and a robust implementation SHOULD support the field as
      undistinguished octets.  While we recognize that vendors have
      complete control over the contents and format of the EVS-Value
      field, we recommend that good practices be followed.

      Further codification of the range of allowed usage of this field
      is outside the scope of this specification.

   Note that unlike the format described in [RFC2865] Section 5.26, this
   data type has no "Vendor-Length" field.  The length of the EVS-Value
   field is implicit and is determined by taking the "Length" of the
   encapsulating RADIUS attribute and then subtracting the length of the
Top   ToC   RFC6929 - Page 16
   Attribute header (2 octets), the "Extended Type" (1 octet), the
   Vendor-Id (4 octets), and the EVS-Type (1 octet).  That is, for
   "Extended Type" Attributes the length of the EVS-Value field is eight
   (8) less than the value of the Length field, and for "Long Extended
   Type" Attributes the length of the EVS-Value field is nine (9) less
   than the value of the Length field.

2.5. Integer64 Data Type

We define a new data type in RADIUS, called "integer64", which carries a 64-bit unsigned integer in network byte order. This data type is intended to be used in any situation where there is a need to have counters that can count past 2^32. The expected use of this data type is within Accounting-Request packets, but this data type SHOULD be used in any packet where 32-bit integers are expected to be insufficient. The "integer64" data type can be used in Attributes of any format, standard space, extended attributes, TLVs, and VSAs. A summary of the "integer64" data type format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attributes having data type "integer64" MUST have the relevant Length field set to eight more than the length of the Attribute header. For standard space Attributes and TLVs, this means that the Length field MUST be set to ten (10). For "Extended Type" Attributes, the Length field MUST be set to eleven (11). For "Long Extended Type" Attributes, the Length field MUST be set to twelve (12).

2.6. Vendor-Id Field

We define the Vendor-Id field of Vendor-Specific Attributes to encompass the entire 4 octets of the Vendor field. [RFC2865] Section 5.26 defined it to be 3 octets, with the fourth octet being zero. This change has no immediate impact on RADIUS, as the maximum Private Enterprise Code defined is still within 16 bits.
Top   ToC   RFC6929 - Page 17
   However, it is best to make advance preparations for changes in the
   protocol.  As such, it is RECOMMENDED that all implementations
   support four (4) octets for the Vendor-Id field, instead of
   three (3).

2.7. Attribute Naming and Type Identifiers

Attributes have traditionally been identified by a unique name and number. For example, the Attribute "User-Name" has been allocated number one (1). This scheme needs to be extended in order to be able to refer to attributes of "Extended Type", and to TLVs. It will also be used by IANA for allocating RADIUS Attribute Type values. The names and identifiers given here are intended to be used only in specifications. The system presented here may not be useful when referring to the contents of a RADIUS packet. It imposes no requirements on implementations, as implementations are free to reference RADIUS attributes via any method they choose.

2.7.1. Attribute and TLV Naming

RADIUS specifications traditionally use names consisting of one or more words, separated by hyphens, e.g., "User-Name". However, these names are not allocated from a registry, and there is no restriction other than convention on their global uniqueness. Similarly, vendors have often used their company name as the prefix for VSA names, though this practice is not universal. For example, for a vendor named "Example", the name "Example-Attribute-Name" SHOULD be used instead of "Attribute-Name". The second form can conflict with attributes from other vendors, whereas the first form cannot. It is therefore RECOMMENDED that specifications give names to Attributes that attempt to be globally unique across all RADIUS Attributes. It is RECOMMENDED that a vendor use its name as a unique prefix for attribute names, e.g., Livingston-IP-Pool instead of IP-Pool. It is RECOMMENDED that implementations enforce uniqueness on names; not doing so would lead to ambiguity and problems. We recognize that these suggestions may sometimes be difficult to implement in practice. TLVs SHOULD be named with a unique prefix that is shared among related attributes. For example, a specification that defines a set of TLVs related to time could create attributes called "Time-Zone", "Time-Day", "Time-Hour", "Time-Minute", etc.
Top   ToC   RFC6929 - Page 18

2.7.2. Attribute Type Identifiers

The RADIUS Attribute Type space defines a context for a particular "Extended-Type" field. The "Extended-Type" field allows for 256 possible type code values, with values 1 through 240 available for allocation. We define here an identification method that uses a "dotted number" notation similar to that used for Object Identifiers (OIDs), formatted as "Type.Extended-Type". For example, an attribute within the Type space of 241, having Extended-Type of one (1), is uniquely identified as "241.1". Similarly, an attribute within the Type space of 246, having Extended-Type of ten (10), is uniquely identified as "246.10".

2.7.3. TLV Identifiers

We can extend the Attribute reference scheme defined above for TLVs. This is done by leveraging the "dotted number" notation. As above, we define an additional TLV Type space, within the "Extended Type" space, by appending another "dotted number" in order to identify the TLV. This method can be repeated in sequence for nested TLVs. For example, let us say that "245.1" identifies RADIUS Attribute Type 245, containing an "Extended Type" of one (1), which is of type "TLV". That attribute will contain 256 possible TLVs, one for each value of the TLV-Type field. The first TLV-Type value of one (1) can then be identified by appending a ".1" to the number of the encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, the sequence "245.2.3.4" identifies RADIUS attribute 245, containing an "Extended Type" of two (2), which is of type "TLV", which in turn contains a TLV with TLV-Type number three (3), which in turn contains another TLV, with TLV-Type number four (4).

2.7.4. VSA Identifiers

There has historically been no method for numerically addressing VSAs. The "dotted number" method defined here can also be leveraged to create such an addressing scheme. However, as the VSAs are completely under the control of each individual vendor, this section provides a suggested practice but does not define a standard of any kind. The Vendor-Specific Attribute has been assigned the Attribute number 26. It in turn carries a 32-bit Vendor-Id, and possibly additional VSAs. Where the VSAs follow the format recommended by [RFC2865] Section 5.26, a VSA can be identified as "26.Vendor-Id.Vendor-Type".
Top   ToC   RFC6929 - Page 19
   For example, Livingston has Vendor-Id 307 and has defined an
   attribute "IP-Pool" as number 6.  This VSA can be uniquely identified
   as 26.307.6, but it cannot be uniquely identified by name, as other
   vendors may have used the same name.

   Note that there are few restrictions on the size of the numerical
   values in this notation.  The Vendor-Id is a 32-bit number, and the
   VSA may have been assigned from a 16-bit Vendor-Specific Attribute
   Type space.  Implementations SHOULD be capable of handling 32-bit
   numbers at each level of the "dotted number" notation.

   For example, the company USR has historically used Vendor-Id 429 and
   has defined a "Version-Id" attribute as number 32768.  This VSA can
   be uniquely identified as 26.429.32768 but again cannot be uniquely
   identified by name.

   Where a VSA is a TLV, the "dotted number" notation can be used as
   above: 26.Vendor-Id.Vendor-Type.TLV1.TLV2.TLV3, where the "TLVn"
   values are the numerical values assigned by the vendor to the
   different nested TLVs.

2.8. Invalid Attributes

The term "invalid attribute" is new to this specification. It is defined to mean that the Length field of an Attribute permits the packet to be accepted as not being "malformed". However, the "Value" field of the Attribute does not follow the format required by the data type defined for that Attribute, and therefore the Attribute is "malformed". In order to distinguish the two cases, we refer to "malformed" packets and "invalid attributes". For example, an implementation receives a packet that is well formed. That packet contains an Attribute allegedly of data type "address" but that has Length not equal to four. In that situation, the packet is well formed, but the Attribute is not. Therefore, it is an "invalid attribute". A similar analysis can be performed when an attribute carries TLVs. The encapsulating attribute may be well formed, but the TLV may be an "invalid attribute". The existence of an "invalid attribute" in a packet or attribute MUST NOT result in the implementation discarding the entire packet or treating the packet as a negative acknowledgment. Instead, only the "invalid attribute" is treated specially. When an implementation receives an "invalid attribute", it SHOULD be silently discarded, except when the implementation is acting as a proxy (see Section 5.2 for discussion of proxy servers). If it is
Top   ToC   RFC6929 - Page 20
   not discarded, it MUST NOT be handled in the same manner as a well-
   formed attribute.  For example, receiving an Attribute of data type
   "address" containing either less than four octets or more than
   four octets of data means that the Attribute MUST NOT be treated as
   being of data type "address".  The reason here is that if the
   Attribute does not carry an IPv4 address, the receiver has no idea
   what format the data is in, and it is therefore not an IPv4 address.

   For Attributes of type "Long Extended Type", an Attribute is
   considered to be an "invalid attribute" when it does not match the
   criteria set out in Section 2.2, above.

   For Attributes of type "TLV", an Attribute is considered to be an
   "invalid attribute" when the TLV-Length field allows the
   encapsulating Attribute to be parsed but the TLV-Value field does not
   match the criteria for that TLV.  Implementations SHOULD NOT treat
   the "invalid attribute" property as being transitive.  That is, the
   Attribute encapsulating the "invalid attribute" SHOULD NOT be treated
   as an "invalid attribute".  That encapsulating Attribute might
   contain multiple TLVs, only one of which is an "invalid attribute".

   However, a TLV definition may require particular sub-TLVs to be
   present and/or to have specific values.  If a sub-TLV is missing or
   contains incorrect value(s), or if it is an "invalid attribute", then
   the encapsulating TLV SHOULD be treated as an "invalid attribute".
   This requirement ensures that strongly connected TLVs are either
   handled as a coherent whole or ignored entirely.

   It is RECOMMENDED that Attributes with unknown Type, Extended-Type,
   TLV-Type, or EVS-Type are treated as "invalid attributes".  This
   recommendation is compatible with the suggestion in [RFC2865]
   Section 5 that implementations "MAY ignore Attributes with an
   unknown Type".


(next page on part 2)

Next Section