draft-ietf-radext-radius-extensions-06.txt   draft-ietf-radext-radius-extensions-07.txt 
Network Working Group Alan DeKok Network Working Group Alan DeKok
INTERNET-DRAFT Network RADIUS INTERNET-DRAFT Network RADIUS
Category: Proposed Standard Avi Lior Category: Proposed Standard Avi Lior
Updates: 2865, 2866, 3575, 5176, 6158 BWS Updates: 2865, 2866, 3575, 5176, 6158 BWS
<draft-ietf-radext-radius-extensions-06.txt> <draft-ietf-radext-radius-extensions-07.txt>
Expires: January 27, 2013 Expires: June 26, 2013
27 June 2012 26 December 2012
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-06.txt draft-ietf-radext-radius-extensions-07.txt
Abstract Abstract
The Remote Authentication Dial In User Service (RADIUS) protocol is The Remote Authentication Dial In User Service (RADIUS) protocol is
nearing exhaustion of its current 8-bit Attribute Type space. In nearing exhaustion of its current 8-bit Attribute Type space. In
addition, experience shows a growing need for complex grouping, along addition, experience shows a growing need for complex grouping, along
with attributes which can carry more than 253 octets of data. This with attributes which can carry more than 253 octets of data. This
document defines changes to RADIUS which address all of the above document defines changes to RADIUS which address all of the above
problems. problems.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 27, 2013. This Internet-Draft will expire on June 26, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info/) in effect on the date of (http://trustee.ietf.org/license-info/) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ............................................. 5 1. Introduction ............................................. 5
1.1. Unmet Requirements .................................. 6 1.1. Caveats and Limitations ............................. 6
1.2. Terminology ......................................... 6 1.1.1. Failure to Meet Certain Goals .................. 6
1.3. Requirements Language ............................... 7 1.1.2. Implementation Recommendations ................. 6
2. Extensions to RADIUS ..................................... 8 1.2. Terminology ......................................... 7
2.1. Extended Type ....................................... 8 1.3. Requirements Language ............................... 8
2.2. Long Extended Type .................................. 9 2. Extensions to RADIUS ..................................... 9
2.3. TLV Data Type ....................................... 11 2.1. Extended Type ....................................... 10
2.3.1. TLV Nesting .................................... 13 2.2. Long Extended Type .................................. 11
2.4. EVS Data Type ....................................... 13 2.3. TLV Data Type ....................................... 13
2.5. Integer64 Data Type ................................. 15 2.3.1. TLV Nesting .................................... 15
2.6. Vendor-ID Field ..................................... 15 2.4. EVS Data Type ....................................... 16
2.7. Attribute Naming and Type Identifiers ............... 16 2.5. Integer64 Data Type ................................. 17
2.7.1. Attribute and TLV Naming ....................... 16 2.6. Vendor-ID Field ..................................... 18
2.7.2. Attribute Type Identifiers ..................... 16 2.7. Attribute Naming and Type Identifiers ............... 18
2.7.3. TLV Identifiers ................................ 17 2.7.1. Attribute and TLV Naming ....................... 18
2.7.4. VSA Identifiers ................................ 17 2.7.2. Attribute Type Identifiers ..................... 19
2.8. Invalid Attributes .................................. 18 2.7.3. TLV Identifiers ................................ 19
3. Attribute Definitions .................................... 19 2.7.4. VSA Identifiers ................................ 20
3.1. Extended-Type-1 ..................................... 19 2.8. Invalid Attributes .................................. 20
3.2. Extended-Type-2 ..................................... 20 3. Attribute Definitions .................................... 21
3.3. Extended-Type-3 ..................................... 21 3.1. Extended-Type-1 ..................................... 22
3.4. Extended-Type-4 ..................................... 22 3.2. Extended-Type-2 ..................................... 23
3.5. Long-Extended-Type-1 ................................ 23 3.3. Extended-Type-3 ..................................... 23
3.6. Long-Extended-Type-2 ................................ 24 3.4. Extended-Type-4 ..................................... 24
4. Vendor Specific Attributes ............................... 25 3.5. Long-Extended-Type-1 ................................ 25
4.1. Extended-Vendor-Specific-1 .......................... 25 3.6. Long-Extended-Type-2 ................................ 26
4.2. Extended-Vendor-Specific-2 .......................... 26 4. Vendor Specific Attributes ............................... 28
4.3. Extended-Vendor-Specific-3 .......................... 28 4.1. Extended-Vendor-Specific-1 .......................... 28
4.4. Extended-Vendor-Specific-4 .......................... 29 4.2. Extended-Vendor-Specific-2 .......................... 29
4.5. Extended-Vendor-Specific-5 .......................... 30 4.3. Extended-Vendor-Specific-3 .......................... 30
4.6. Extended-Vendor-Specific-6 .......................... 31 4.4. Extended-Vendor-Specific-4 .......................... 31
5. Compatibility with traditional RADIUS .................... 33 4.5. Extended-Vendor-Specific-5 .......................... 33
5.1. Attribute Allocation ................................ 33 4.6. Extended-Vendor-Specific-6 .......................... 34
5.2. Proxy Servers ....................................... 34 5. Compatibility with traditional RADIUS .................... 35
6. Guidelines ............................................... 35 5.1. Attribute Allocation ................................ 36
6.1. Updates to RFC 6158 ................................. 35 5.2. Proxy Servers ....................................... 37
6.2. Guidelines for Simple Data Types .................... 35 6. Guidelines ............................................... 38
6.3. Guidelines for Complex Data Types ................... 36 6.1. Updates to RFC 6158 ................................. 38
6.4. Guidelines For the New Types ........................ 36 6.2. Guidelines for Simple Data Types .................... 38
6.5. Allocation Request Guidelines ....................... 37 6.3. Guidelines for Complex Data Types ................... 39
6.6. TLV Guidelines ...................................... 38 6.4. Guidelines For the New Types ........................ 39
6.7. Implementation Guidelines ........................... 38 6.5. Allocation Request Guidelines ....................... 40
6.8. Vendor Guidelines ................................... 39 6.6. TLV Guidelines ...................................... 41
7. Rationale ................................................ 39 6.7. Implementation Guidelines ........................... 41
7.1. Attribute Audit ..................................... 39 6.8. Vendor Guidelines ................................... 42
8. Diameter Considerations .................................. 40 7. Rationale for This Design ................................ 42
9. Examples ................................................. 41 7.1. Attribute Audit ..................................... 42
9.1. Extended Type ....................................... 42 8. Diameter Considerations .................................. 43
9.2. Long Extended Type .................................. 43 9. Examples ................................................. 43
10. IANA Considerations ..................................... 46 9.1. Extended Type ....................................... 45
10.1. Attribute Allocations .............................. 46 9.2. Long Extended Type .................................. 46
10.2. RADIUS Attribute Type Tree ......................... 46 10. IANA Considerations ..................................... 48
10.3. Allocation Instructions ............................ 47 10.1. Attribute Allocations .............................. 49
10.3.1. Requested Allocation from the Standard Space .. 48 10.2. RADIUS Attribute Type Tree ......................... 49
10.3.2. Requested Allocation from the short extended sp 48 10.3. Allocation Instructions ............................ 50
10.3.3. Requested Allocation from the long extended spa 48 10.3.1. Requested Allocation from the Standard Space .. 50
10.3.4. Allocation Preferences ........................ 48 10.3.2. Requested Allocation from the short extended sp 50
10.3.5. Extending the Type Space via TLV Data Type .... 49 10.3.3. Requested Allocation from the long extended spa 51
10.3.6. Allocation within a TLV ....................... 49 10.3.4. Allocation Preferences ........................ 51
10.3.7. Allocation of Other Data Types ................ 50 10.3.5. Extending the Type Space via TLV Data Type .... 51
11. Security Considerations ................................. 50 10.3.6. Allocation within a TLV ....................... 52
12. References .............................................. 50 10.3.7. Allocation of Other Data Types ................ 52
12.1. Normative references ............................... 50 11. Security Considerations ................................. 52
12.2. Informative references ............................. 50 12. References .............................................. 53
Appendix A - Extended Attribute Generator Program ............ 52 12.1. Normative references ............................... 53
12.2. Informative references ............................. 53
Appendix A - Extended Attribute Generator Program ............ 55
1. Introduction 1. Introduction
Under current allocation pressure, we expect that the RADIUS Under current allocation pressure, we expect that the RADIUS
Attribute Type space will be exhausted by 2014 or 2015. We therefore 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 need a way to extend the type space, so that new specifications may
continue to be developed. Other issues have also been shown with continue to be developed. Other issues have also been shown with
RADIUS. The attribute grouping method defined in [RFC2868] has been RADIUS. The attribute grouping method defined in [RFC2868] has been
shown to be impractical, and a more powerful mechanism is needed. shown to be impractical, and a more powerful mechanism is needed.
Multiple attributes have been defined which transport more than the Multiple attributes have been defined which transport more than the
253 octets of data originally envisioned with the protocol. Each of 253 octets of data originally envisioned with the protocol. Each of
these attributes is handled as a "special case" inside of RADIUS these attributes is handled as a "special case" inside of RADIUS
implementations, instead of as a general method. We therefore also implementations, instead of as a general method. We therefore also
need a standardized method of transporting large quantities of data. need a standardized method of transporting large quantities of data.
Finally, some vendors are close to allocating all of the Attributes Finally, some vendors are close to allocating all of the Attributes
within their Vendor-Specific Attribute space. It would be useful to within their Vendor-Specific Attribute space. It would be useful to
leverage changes to the base protocol for extending the Vendor- leverage changes to the base protocol for extending the Vendor-
Specific Attribute space. Specific Attribute space.
We satisfy all of these requirements through the following We satisfy all of these requirements through the following changes
modifications to RADIUS: given in this document:
* defining an "Extended Type" format, which adds 8 bits of "Extended * defining an "Extended Type" format, which adds 8 bits of "Extended
Type" to the RADIUS Attribute Type space, by using one octet of the Type" to the RADIUS Attribute Type space, by using one octet of the
"Value" field. This method gives us a general way of extending "Value" field. This method gives us a general way of extending
the Attribute Type Space. the Attribute Type Space. (Section 2.1)
* allocating 4 attributes as using the format of "Extended Type". * allocating 4 attributes as using the format of "Extended Type".
This allocation extends the RADIUS Attribute Type Space by This allocation extends the RADIUS Attribute Type Space by
approximately 1000 values. approximately 1000 values. (Sections 3.1, 3.2, 3.3, and 3.4)
* defining a "Long Extended Type" format, which inserts * defining a "Long Extended Type" format, which inserts an additional
an additional octet between the "Extended Type" octet, octet between the "Extended Type" octet, and the "Value" field.
and the "Value" field. This method gives us a general way of This method gives us a general way of adding additional
adding additional functionality to the protocol. functionality to the protocol. (Section 2.2)
* defining a method which uses the additional octet to indicate data * defining a method which uses the additional octet in the "Long
fragmentation across multiple Attributes. This method provides a Extended Type" to indicate data fragmentation across multiple
standard way for an Attribute to carry more than 253 octets of Attributes. This method provides a standard way for an Attribute
data. to carry more than 253 octets of data. (Section 2.2)
* allocating 2 attributes as using the format "Long Extended Type". * allocating 2 attributes as using the format "Long Extended Type".
This allocation extends the RADIUS Attribute Type Space This allocation extends the RADIUS Attribute Type Space
by an additional 500 values. by an additional 500 values. (Sections 3.5 and 3.6)
* defining a new "Type Length Value" (TLV) data type. The data type * defining a new "Type Length Value" (TLV) data type. The data type
allows an attribute to carry TLVs as "sub-attributes", which can in allows an attribute to carry TLVs as "sub-attributes", which can in
turn encapsulate other TLVs as "sub-sub-attributes." This change turn encapsulate other TLVs as "sub-sub-attributes." This change
creates a standard way to group a set of Attributes. creates a standard way to group a set of Attributes. (Section 2.3)
* defining a new "extended Vendor-Specific" (EVS) data type. The * defining a new "extended Vendor-Specific" (EVS) data type. The
data type allows an attribute to carry Vendor-Specific Attributes data type allows an attribute to carry Vendor-Specific Attributes
(VSAs) inside of the new attribute formats. (VSAs) inside of the new attribute formats. (Section 2.4)
* defining a new "integer64" data type. The data type allows * defining a new "integer64" data type. The data type allows
counters which track more than 2^32 octets of data. counters which track more than 2^32 octets of data. (Section 2.5)
* allocating 6 attributes using the new EVS data type. This * allocating 6 attributes using the new EVS data type. This
allocation extends the Vendor-Specific Attribute Type space by allocation extends the Vendor-Specific Attribute Type space by
over 1500 values. over 1500 values. (Sections 4.1 through 4.6)
* Define the "Vendor-ID" for Vendor-Specific attributes to * Define the "Vendor-ID" for Vendor-Specific attributes to encompass
encompass the entire 4 octets of the Vendor field. [RFC2865] the entire 4 octets of the Vendor field. [RFC2865] Section 5.26
Section 5.26 defined it to be 3 octets, with the high octet defined it to be 3 octets, with the high octet being zero.
being zero. (Section 2.5)
* 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 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 of a series of compromises. We have tried to find a balance between
flexibility, space in the RADIUS message, compatibility with existing flexibility, space in the RADIUS message, compatibility with existing
deployments, and implementation difficulty. deployments, and implementation difficulty.
1.1. Unmet Requirements 1.1. Caveats and Limitations
One requirement which was not met by the above modifications is to This section describes some caveats and limitations with the
have an incentive for standards to use the new space. We would proposal.
ideally like to deprecate the "Unassigned" attributes in the standard
space, which would permit allocation, but under more stringent 1.1.1. Failure to Meet Certain Goals
guidelines. However, [RFC5226] has no provisions for a "Deprecated"
entry in an IANA managed registry. One gaol which was not met by the above modifications is to have an
incentive for standards to use the new space. We would ideally like
to deprecate the "Unassigned" attributes in the standard space, which
would permit allocation, but under more stringent guidelines.
However, [RFC5226] has no provisions for a "Deprecated" entry in an
IANA managed registry.
1.1.2. Implementation Recommendations
It is RECOMMENDED that implementations support this specification. It is RECOMMENDED that implementations support this specification.
It is RECOMMENDED that new specifications use the formats defined in It is RECOMMENDED that new specifications use the formats defined in
this specification. this specification.
The alternative to the above recommendations is a circular argument The alternative to the above recommendations is a circular argument
of not implementing this specification because no other standards of not implementing this specification because no other standards
reference it, and also not defining new standards referencing this reference it, and also not defining new standards referencing this
specification because no implementations exist. specification because no implementations exist.
As noted earlier, the "standard space" is almost entirely allocated.
Ignoring the looming crisis benefits no one.
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
silently discard silently discard
This means the implementation discards the packet without further This means the implementation discards the packet without further
processing. The implementation MAY provide the capability of processing. The implementation MAY provide the capability of
logging the error, including the contents of the silently discarded logging the error, including the contents of the silently discarded
packet, and SHOULD record the event in a statistics counter. packet, and SHOULD record the event in a statistics counter.
invalid attribute invalid attribute
This means that the Length field of an Attribute is valid (as per This means that the Length field of an Attribute is valid (as per
[RFC2865], Section 5, top of page 25). However, the Value field of [RFC2865], Section 5, top of page 25). However, the Value field of
the attribute does not follow the format required by the data type the attribute does not follow the format required by the data type
defined for that Attribute. e.g. an Attribute of type "address" defined for that Attribute. e.g. an Attribute of type "address"
which encapsulates more than four, or less than four, octets of which encapsulates more than four, or less than four, octets of
data. See Section 2.7 for a more complete definition. data. See Section 2.8 for a more complete definition.
Standard space Standard space
Codes in the RADIUS Attribute Type Space that are allocated by IANA Codes in the RADIUS Attribute Type Space that are allocated by IANA
and that follow the format defined in Section 5 of RFC 2865 and that follow the format defined in Section 5 of [RFC2865].
[RFC2865].
Extended space Extended space
Codes in the RADIUS Attribute Type Space that require the Codes in the RADIUS Attribute Type Space that require the
extensions defined in this document, and are an extension of the extensions defined in this document, and are an extension of the
standard space, but which cannot be represented within the standard standard space, but which cannot be represented within the standard
space. space.
Short extended space Short extended space
Codes in the extended space which use the "Extended Type" format. Codes in the extended space which use the "Extended Type" format.
skipping to change at page 8, line 15 skipping to change at page 9, line 15
2. Extensions to RADIUS 2. Extensions to RADIUS
This section defines two new attribute formats; "Extended Type"; and This section defines two new attribute formats; "Extended Type"; and
"Long Extended Type". It defines a new Type-Length-Value (TLV) data "Long Extended Type". It defines a new Type-Length-Value (TLV) data
type, an Extended-Vendor-Specific (EVS) data type, and an Integer64 type, an Extended-Vendor-Specific (EVS) data type, and an Integer64
data type. It defines a new method for naming attributes and data type. It defines a new method for naming attributes and
identifying Attributes using the new attribute formats. It finally identifying Attributes using the new attribute formats. It finally
defines the new term "invalid attribute", and describes how it defines the new term "invalid attribute", and describes how it
affects implementations. 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 is unchanged from that
specification. This reuse allows the new formats to be compatible
RADIUS implementations which 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
Values 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
RADIUS implementations which 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
Values 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.
2.1. Extended Type 2.1. Extended Type
This section defines a new attribute format, called "Extended Type". This section defines a new attribute format, called "Extended Type".
A summary of the Attribute format is shown below. The fields are A summary of the Attribute format is shown below. The fields are
transmitted from left to right. transmitted from left to right.
0 1 2 3 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 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 | Length | Extended-Type | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
This field is identical to the Type field of the Attribute format This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5. defined in [RFC2865] Section 5.
Length Length
This field is identical to the Length field of the Attribute The Length field is one octet, and indicates the length of this
format defined in [RFC2865] Section 5. Permitted values are Attribute including the Type, Length, Extended-Type, and Value
between 4 and 255. If a client or server receives an Extended fields. Permitted values are between 4 and 255. If a client or
Attribute with a Length of 2 or 3, then that Attribute MUST be server receives an Extended Attribute with a Length of 2 or 3,
considered to be an "invalid attribute", and handled as per then that Attribute MUST be considered to be an "invalid
Section 2.7, below. attribute", and handled as per Section 2.8, below.
Extended-Type Extended-Type
The Extended-Type field is one octet. Up-to-date values of this The Extended-Type field is one octet. Up-to-date values of this
field are specified according to the policies and rules described field are specified according to the policies and rules described
in Section 10. Unlike the Type field defined in [RFC2865] Section in Section 10. Unlike the Type field defined in [RFC2865] Section
5, no values are allocated for experimental or implementation- 5, no values are allocated for experimental or implementation-
specific use. Values 241-255 are reserved and SHOULD NOT be used. specific use. Values 241-255 are reserved and SHOULD NOT be used.
The Extended-Type is meaningful only within a context defined by The Extended-Type is meaningful only within a context defined by
skipping to change at page 9, line 50 skipping to change at page 11, line 40
| Value ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
This field is identical to the Type field of the Attribute format This field is identical to the Type field of the Attribute format
defined in [RFC2865] Section 5. defined in [RFC2865] Section 5.
Length Length
This field is identical to the Length field of the Attribute The Length field is one octet, and indicates the length of this
format defined in [RFC2865] Section 5. Permitted values are Attribute including the Type, Length, Extended-Type, and Value
between 5 and 255. If a client or server receives a "Long fields. Permitted values are between 5 and 255. If a client or
Extended Attribute" with a Length of 2, 3, or 4, then that server receives a "Long Extended Type" with a Length of 2, 3, or
Attribute MUST be considered to be an "invalid attribute", and be 4, then that Attribute MUST be considered to be an "invalid
handled as per Section 2.7, below. attribute", and be handled as per Section 2.8, below.
Extended-Type Note that this Length is limited to the length of this fragment.
There is no field which 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 This field is identical to the Extended-Type field defined above
in Section 2.1. in Section 2.1.
M (More) M (More)
The More field is one (1) bit in length, and indicates whether or The More field is one (1) bit in length, and indicates whether or
not the current attribute contains "more" than 251 octets of data. not the current attribute contains "more" than 251 octets of data.
The More field MUST be clear (0) if the Length field has value The More field MUST be clear (0) if the Length field has value
less than 255. The More field MAY be set (1) if the Length field less than 255. The More field MAY be set (1) if the Length field
has value of 255. has value of 255.
skipping to change at page 10, line 37 skipping to change at page 12, line 31
fragments of the same value MUST be in order and MUST be fragments of the same value MUST be in order and MUST be
consecutive attributes in the packet, and the last attribute in a consecutive attributes in the packet, and the last attribute in a
packet MUST NOT have the More field set (1). packet MUST NOT have the More field set (1).
When the Length field of an attribute has value less than 255, the When the Length field of an attribute has value less than 255, the
More field SHOULD be clear (0). More field SHOULD be clear (0).
If a client or server receives an attribute fragment with the If a client or server receives an attribute fragment with the
"More" field set (1), but for which no subsequent fragment can be "More" field set (1), but for which no subsequent fragment can be
found, then the fragmented attribute is considered to be an found, then the fragmented attribute is considered to be an
"invalid attribute", and handled as per Section 2.7, below. "invalid attribute", and handled as per Section 2.8, below.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Future specifications may define additional meaning for this Future specifications may define additional meaning for this
field. Implementations therefore MUST NOT treat this field as field. Implementations therefore MUST NOT treat this field as
skipping to change at page 11, line 15 skipping to change at page 13, line 9
defined in [RFC2865] Section 5. It may contain a complete set of defined in [RFC2865] Section 5. It may contain a complete set of
data (when the Length field has value less than 255), or it may data (when the Length field has value less than 255), or it may
contain a fragment of data (when the More field is set). contain a fragment of data (when the More field is set).
Any interpretation of the resulting data MUST occur after the Any interpretation of the resulting data MUST occur after the
fragments have been reassembled. The length of the data MUST be fragments have been reassembled. The length of the data MUST be
taken as the sum of the lengths of the fragments (i.e. Value taken as the sum of the lengths of the fragments (i.e. Value
fields) from which it is constructed. The format of the data fields) from which it is constructed. The format of the data
SHOULD be a valid RADIUS data type. SHOULD be a valid RADIUS data type.
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 SHOULD be
able to handle fragmented attributes of 4096 octets.
This definition increases the RADIUS Attribute Type space as above, This definition increases the RADIUS Attribute Type space as above,
but also provides for transport of Attributes which could contain but also provides for transport of Attributes which could contain
more than 253 octets of data. 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 which are mixed together
with other attributes of a different Type.
2.3. TLV Data Type 2.3. TLV Data Type
We define a new data type in RADIUS, called "tlv". The "tlv" data We define a new data type in RADIUS, called "tlv". The "tlv" data
type is an encapsulation layer which permits the "Value" field of an type is an encapsulation layer which permits the "Value" field of an
Attribute to contain new sub-Attributes. These sub-Attributes can in Attribute to contain new sub-Attributes. These sub-Attributes can in
turn contain "Value"s of data type TLV. This capability both extends turn contain "Value"s of data type TLV. This capability both extends
the attribute space, and permits "nested" attributes to be used. the attribute space, and permits "nested" attributes to be used.
This nesting can be used to encapsulate or group data into one or This nesting can be used to encapsulate or group data into one or
more logical containers. more logical containers.
skipping to change at page 12, line 20 skipping to change at page 14, line 37
A RADIUS proxy SHOULD forward Attributes with an unknown "TLV- A RADIUS proxy SHOULD forward Attributes with an unknown "TLV-
Type" verbatim. Type" verbatim.
TLV-Length TLV-Length
The TLV-Length field is one octet, and indicates the length of The TLV-Length field is one octet, and indicates the length of
this TLV including the TLV-Type, TLV-Length and TLV-Value fields. 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 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 receives a TLV with an invalid TLV-Length, then the attribute
which encapsulates that TLV MUST be considered to be an "invalid which encapsulates that TLV MUST be considered to be an "invalid
attribute", and handled as per Section 2.7, below. attribute", and handled as per Section 2.8, below.
TLV-Value TLV-Value
The Value field is one or more octets and contains information The Value field is one or more octets and contains information
specific to the Attribute. The format and length of the TLV-Value specific to the Attribute. The format and length of the TLV-Value
field is determined by the TLV-Type and TLV-Length fields. field is determined by the TLV-Type and TLV-Length fields.
The TLV-Value field SHOULD encapsulate a previously defined RADIUS The TLV-Value field SHOULD encapsulate a previously defined RADIUS
data type. Using non-standard data types is NOT RECOMMENDED. We data type. Use of non-standard data types SHOULD NOT be done. We
note that the TLV-Value field MAY also contain one or more note that the TLV-Value field MAY also contain one or more
attributes of data type "tlv", which allows for simple grouping attributes of data type "tlv", which allows for simple grouping
and multiple layers of nesting. and multiple layers of nesting.
The TLV-Value field is limited to containing 253 or fewer octets The TLV-Value field is limited to containing 253 or fewer octets
of data. Specifications which require a TLV to contain more than of data. Specifications which require a TLV to contain more than
253 octets of data are incompatible with RADIUS, and need to be 253 octets of data are incompatible with RADIUS, and need to be
redesigned. Specifications which require the transport of empty redesigned. Specifications which require the transport of empty
Values (i.e. Length = 2) are incompatible with RADIUS, and need to Values (i.e. Length = 2) are incompatible with RADIUS, and need to
be redesigned. be redesigned.
skipping to change at page 13, line 4 skipping to change at page 15, line 21
Type" formats defined in this document. The base Extended Type" formats defined in this document. The base Extended
Attributes format allows for sufficient flexibility that nesting Attributes format allows for sufficient flexibility that nesting
them inside of a TLV offers little additional value. them inside of a TLV offers little additional value.
This TLV definition is compatible with the suggested format of the This TLV definition is compatible with the suggested format of the
"String" field of the Vendor-Specific attribute, as defined in "String" field of the Vendor-Specific attribute, as defined in
[RFC2865] Section 5.26, though that specification does not discuss [RFC2865] Section 5.26, though that specification does not discuss
nesting. nesting.
Vendors MAY use attributes of type "tlv" in any Vendor Specific Vendors MAY use attributes of type "tlv" in any Vendor Specific
Attribute. We RECOMMEND using type "tlv" for VSAs, in preference to Attribute. It is RECOMMENDED to use type "tlv" for VSAs, in
any other format. 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.
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 a set or a list 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 2.3.1. TLV Nesting
TLVs may contain other TLVs. When this occurs, the "container" TLV TLVs may contain other TLVs. When this occurs, the "container" TLV
MUST be completely filled by the "contained" TLVs. That is, the MUST be completely filled by the "contained" TLVs. That is, the
"container" TLV-Length field MUST be exactly two (2) more than the "container" TLV-Length field MUST be exactly two (2) more than the
sum of the "contained" TLV-Length fields. If the "contained" TLVs sum of the "contained" TLV-Length fields. If the "contained" TLVs
over-fill the "container" TLV, the "container" TLV MUST be considered over-fill the "container" TLV, the "container" TLV MUST be considered
to be an "invalid attribute", and handled as described in Section to be an "invalid attribute", and handled as described in Section
2.7, below. 2.8, below.
The depth of TLV nesting is limited only by the restrictions on the 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 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 of 126 levels of nesting. However, nesting depths of more than 4 are
NOT RECOMMENDED. NOT RECOMMENDED.
2.4. EVS Data Type 2.4. EVS Data Type
We define a new data type in RADIUS, called "evs", for "Extended We define a new data type in RADIUS, called "evs", for "Extended
Vendor-Specific". The "evs" data type is an encapsulation layer Vendor-Specific". The "evs" data type is an encapsulation layer
skipping to change at page 14, line 16 skipping to change at page 16, line 46
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 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 | | Vendor-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Type | String .... | Vendor-Type | String ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the SMI Network Management Private Enterprise
Code of the Vendor in network byte order. Code [SMI] of the Vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. It SHOULD encapsulate a The Value field is one or more octets. It SHOULD encapsulate a
previously defined RADIUS data type. Using non-standard data previously defined RADIUS data type. Using non-standard data
skipping to change at page 15, line 16 skipping to change at page 17, line 45
We define a new data type in RADIUS, called "integer64", which We define a new data type in RADIUS, called "integer64", which
carries a 64-bit unsigned integer in network byte order. carries a 64-bit unsigned integer in network byte order.
This data type is intended to be used in any situation where there is This data type is intended to be used in any situation where there is
a need to have counters which can count past 2^32. The expected use a need to have counters which can count past 2^32. The expected use
of this data type is within Accounting-Request packets, but this data 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 type SHOULD be used in any packet where 32-bit integers are expected
to be insufficient. to be insufficient.
The "integer64" data type MAY be used in Attributes of any format, The "integer64" data type can be used in Attributes of any format,
standard space, extended attributes, TLVs, and VSAs. standard space, extended attributes, TLVs, and VSAs.
A summary of the "integer64" data type format is shown below. The A summary of the "integer64" data type format is shown below. The
fields are transmitted from left to right. fields are transmitted from left to right.
0 1 2 3 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 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 ... | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Attributes having data type "integer64" MUST have the relevant Length Attributes having data type "integer64" MUST have the relevant Length
field set to eight more than the length of the Attribute header. For field set to eight more than the length of the Attribute header. For
standard space Attributes and TLVs, this means that the Length field standard space Attributes and TLVs, this means that the Length field
MUST be set to ten (10). For "Extended Type" Attributes, the Length MUST be set to ten (10). For "Extended Type" Attributes, the Length
skipping to change at page 16, line 34 skipping to change at page 19, line 12
names are not allocated from a registry, and there is no restriction names are not allocated from a registry, and there is no restriction
other than convention on their global uniqueness. other than convention on their global uniqueness.
Similarly, vendors have often used their company name as the prefix Similarly, vendors have often used their company name as the prefix
for VSA names, though this practice is not universal. For example, for VSA names, though this practice is not universal. For example,
for a vendor named "Example", the name "Example-Attribute-Name" for a vendor named "Example", the name "Example-Attribute-Name"
SHOULD be used instead of "Attribute-Name". The second form can SHOULD be used instead of "Attribute-Name". The second form can
conflict with attributes from other vendors, whereas the first form conflict with attributes from other vendors, whereas the first form
cannot. cannot.
We therefore RECOMMEND that specifications give names to Attributes It is therefore RECOMMENDED that specifications give names to
which attempt to be globally unique across all RADIUS Attributes. We Attributes which attempt to be globally unique across all RADIUS
RECOMMEND that vendors use their name as a unique prefix for Attributes. It is RECOMMENDED that vendors use their name as a
attribute names. We recognise that these suggestion may sometimes be unique prefix for attribute names, e.g. Livingston-IP-Pool instead of
difficult to implement in practice. IP-Pool. It is RECOMMENDED that implementations enforce uniqueness
on names, which would otherwise lead to ambiguity and problems.
We recognise that these suggestion may sometimes be difficult to
implement in practice.
TLVs SHOULD be named with a unique prefix that is shared among TLVs SHOULD be named with a unique prefix that is shared among
related attributes. For example, a specification that defines a set related attributes. For example, a specification that defines a set
of TLVs related to time could create attributes named "Time-Zone", of TLVs related to time could create attributes named "Time-Zone",
"Time-Day", "Time-Hour", "Time-Minute", etc. "Time-Day", "Time-Hour", "Time-Minute", etc.
2.7.2. Attribute Type Identifiers 2.7.2. Attribute Type Identifiers
The RADIUS Attribute Type space defines a context for a particular The RADIUS Attribute Type space defines a context for a particular
"Extended-Type" field. The "Extended-Type" field allows for 256 "Extended-Type" field. The "Extended-Type" field allows for 256
skipping to change at page 17, line 50 skipping to change at page 20, line 32
provides a suggested practice, but does not define a standard of any provides a suggested practice, but does not define a standard of any
kind. kind.
The Vendor-Specific Attribute has been assigned the Attribute number The Vendor-Specific Attribute has been assigned the Attribute number
26. It in turn carries a 24-bit Vendor-Id, and possibly additional 26. It in turn carries a 24-bit Vendor-Id, and possibly additional
VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended VSAs. Where the VSAs follow the [RFC2865] Section 5.26 recommended
format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type". format, a VSA can be identified as "26.Vendor-Id"."Vendor-Type".
For example, Livingston has Vendor-Id 307, and has defined an For example, Livingston has Vendor-Id 307, and has defined an
attribute "IP-Pool" as number 6. This VSA can be uniquely identified attribute "IP-Pool" as number 6. This VSA can be uniquely identified
as 26.307.6. as 26.307.6, but it cannot be uniquely identified by name.
Note that there is no restriction on the size of the numerical values Note that there is no restriction on the size of the numerical values
in this notation. The Vendor-Id is a 24-bit number, and the VSA may in this notation. The Vendor-Id is a 24-bit number, and the VSA may
have been assigned from a 16-bit vendor-specific Attribute Type have been assigned from a 16-bit vendor-specific Attribute Type
space. space.
For example, the company USR has been allocated Vendor-Id 429, and For example, the company USR has been allocated Vendor-Id 429, and
has defined a "Version-Id" attribute as number 32768. This VSA can has defined a "Version-Id" attribute as number 32768. This VSA can
be uniquely identified as 26.429.32768. be uniquely identified as 26.429.32768, and again cannot be uniquely
identified by name.
Where a VSA is a TLV, the "dotted number" notation can be used as Where a VSA is a TLV, the "dotted number" notation can be used as
above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical above: 26.VID.VSA.TLV1.TLV2.TLV3 where "TLVn" are the numerical
values assigned by the vendor to the different nested TLVs. values assigned by the vendor to the different nested TLVs.
2.8. Invalid Attributes 2.8. Invalid Attributes
The term "invalid attribute" is new to this specification. It is The term "invalid attribute" is new to this specification. It is
defined to mean that the Length field of an Attribute is valid (as defined to mean that the Length field of an Attribute is valid (as
per [RFC2865], Section 5, top of page 25). However, the Value field per [RFC2865], Section 5, top of page 25). However, the Value field
skipping to change at page 26, line 20 skipping to change at page 29, line 4
... Vendor-Id (cont) | Vendor-Type | ... Vendor-Id (cont) | Vendor-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value .... | Value ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type.Extended-Type Type.Extended-Type
241.26 for Extended-Vendor-Specific-1 241.26 for Extended-Vendor-Specific-1
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the SMI Network Management Private Enterprise
Code of the Vendor in network byte order. Code [SMI] of the Vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 27, line 31 skipping to change at page 30, line 15
242.26 for Extended-Vendor-Specific-2 242.26 for Extended-Vendor-Specific-2
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the SMI Network Management Private Enterprise
Code of the Vendor in network byte order. Code [SMI] of the Vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 28, line 37 skipping to change at page 31, line 22
243.26 for Extended-Vendor-Specific-3 243.26 for Extended-Vendor-Specific-3
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the SMI Network Management Private Enterprise
Code of the Vendor in network byte order. Code [SMI] of the Vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 29, line 43 skipping to change at page 32, line 27
244.26 for Extended-Vendor-Specific-4 244.26 for Extended-Vendor-Specific-4
Length Length
>= 9 >= 9
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the SMI Network Management Private Enterprise
Code of the Vendor in network byte order. Code [SMI] of the Vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 31, line 16 skipping to change at page 34, line 4
Further definition of this field is given in Section 2.2, above. Further definition of this field is given in Section 2.2, above.
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the SMI Network Management Private Enterprise
Code of the Vendor in network byte order. Code [SMI] of the Vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 32, line 39 skipping to change at page 35, line 26
Reserved Reserved
This field is 7 bits long, and is reserved for future use. This field is 7 bits long, and is reserved for future use.
Implementations MUST set it to zero (0) when encoding an attribute Implementations MUST set it to zero (0) when encoding an attribute
for sending in a packet. The contents SHOULD be ignored on for sending in a packet. The contents SHOULD be ignored on
reception. reception.
Vendor-Id Vendor-Id
The 4 octets are the SMI Network Management Private Enterprise The 4 octets are the SMI Network Management Private Enterprise
Code of the Vendor in network byte order. Code [SMI] of the Vendor in network byte order.
Vendor-Type Vendor-Type
The Vendor-Type field is one octet. Values are assigned at the The Vendor-Type field is one octet. Values are assigned at the
sole discretion of the Vendor. sole discretion of the Vendor.
Value Value
The Value field is one or more octets. The actual format of the The Value field is one or more octets. The actual format of the
information is site or application specific, and a robust information is site or application specific, and a robust
skipping to change at page 34, line 35 skipping to change at page 37, line 25
This requirement solves some of the issues related to proxying of the This requirement solves some of the issues related to proxying of the
new format, but not all. The reason is that proxy servers are new format, but not all. The reason is that proxy servers are
permitted to examine the contents of the packets that they forward. permitted to examine the contents of the packets that they forward.
Many proxy implementations not only examine the attributes, but they Many proxy implementations not only examine the attributes, but they
refuse to forward attributes which they do not understand (i.e. refuse to forward attributes which they do not understand (i.e.
attributes for which they have no local dictionary definitions). attributes for which they have no local dictionary definitions).
This practice is NOT RECOMMENDED. Proxy servers SHOULD forward This practice is NOT RECOMMENDED. Proxy servers SHOULD forward
attributes, even ones which they do not understand, or which are not attributes, even ones which they do not understand, or which are not
in a local dictionary. When forwarded, these attributes SHOULD be in a local dictionary. When forwarded, these attributes SHOULD be
sent verbatim, with no modifications or changes. The only exception sent verbatim, with no modifications or changes. This requirement
to this recommendation is when local site policy dictates that includes "invalid attributes", as there may be some other system in
filtering of attributes has to occur. For example, a filter at a the network which understands them.
visited network may require removal of certain authorization rules
which apply to the home network, but not to the visited network. The only exception to this recommendation is when local site policy
This filtering can sometimes be done even when the contents of the dictates that filtering of attributes has to occur. For example, a
attributes are unknown, such as when all Vendor-Specific Attributes filter at a visited network may require removal of certain
are designated for removal. authorization rules which apply to the home network, but not to the
visited network. This filtering can sometimes be done even when the
contents of the attributes are unknown, such as when all Vendor-
Specific Attributes are designated for removal.
As seen in [EDUROAM] many proxies do not follow these practices for As seen in [EDUROAM] many proxies do not follow these practices for
unknown Attributes. Some proxies filter out unknown attributes or unknown Attributes. Some proxies filter out unknown attributes or
attributes which have unexpected lengths (24%, 17/70), some truncate attributes which have unexpected lengths (24%, 17/70), some truncate
the attributes to the "expected" length (11%, 8/70), some discard the the attributes to the "expected" length (11%, 8/70), some discard the
request entirely (1%, 1/70), with the rest (63%, 44/70) following the request entirely (1%, 1/70), with the rest (63%, 44/70) following the
recommended practice of passing the attributes verbatim. It will be recommended practice of passing the attributes verbatim. It will be
difficult to widely use the Extended Attributes format until all non- difficult to widely use the Extended Attributes format until all non-
conformant proxies are fixed. We therefore RECOMMEND that all conformant proxies are fixed. We therefore RECOMMEND that all
proxies which do not support the Extended Attributes (241 through proxies which do not support the Extended Attributes (241 through
skipping to change at page 37, line 37 skipping to change at page 40, line 32
6.5. Allocation Request Guidelines 6.5. Allocation Request Guidelines
The following items give guidelines for allocation requests made in a The following items give guidelines for allocation requests made in a
RADIUS specification. RADIUS specification.
* Discretion is RECOMMENDED when requesting allocation of attributes. * Discretion is RECOMMENDED when requesting allocation of attributes.
The new space is much larger than the old one, but it is not The new space is much larger than the old one, but it is not
infinite. infinite.
* Specifications which request ten (10) or more attributes MUST * Specifications which allocate many attributes MUST NOT request that
NOT request that all be allocated from the standard space. allocation be made from from the standard space. That space is
That space is under allocation pressure, and the extended space under allocation pressure, and the extended space is more suitable
is more suitable for large allocations. for large allocations.
* Specifications which allocate many related attributes SHOULD define
one or more TLVs to contain related attributes.
* New specifications SHOULD NOT request allocation from the standard * New specifications SHOULD NOT request allocation from the standard
Attribute Type Space (i.e. Attributes 1 through 255). That space Attribute Type Space (i.e. Attributes 1 through 255). That space
is deprecated. is deprecated.
* It is RECOMMENDED that specifications do not request allocation * It is RECOMMENDED that specifications do not request allocation
from a specific space. The IANA considerations given in from a specific space. The IANA considerations given in
Section 9, below, should be sufficient for attribute allocation. Section 9, below, should be sufficient for attribute allocation.
* Specifications of an ttribute which encodes 252 octets or less * Specifications of an attribute which encodes 252 octets or less
of data MAY request allocation from the exended space, using of data MAY request allocation from the exended space, using
format "Extended Type" format "Extended Type"
* Specifications of an attribute which can always encode less than * Specifications of an attribute which always encode less than 253
253 octets of data MUST NOT request allocation from the long octets of data MUST NOT request allocation from the long extended
extended space. The standard space, or the short extended space space. The standard space, or the short extended space MUST be
MUST be used instead. used instead.
* Specifications of an attribute which encodes 253 octets or more of * Specifications of an attribute which encodes 253 octets or more of
data MUST request allocation from the long extended space. data MUST request allocation from the long extended space.
* When the extended space is nearing exhaustion, a new specification * When the extended space is nearing exhaustion, a new specification
SHOULD be written which requests allocation of one or more RADIUS SHOULD be written which requests allocation of one or more RADIUS
Attributes from the "Reserved" portion of the standard space, Attributes from the "Reserved" portion of the standard space,
values 247-255, using an appropriate format ("Extended Type", or values 247-255, using an appropriate format ("Extended Type", or
"Long Extended Type") "Long Extended Type")
skipping to change at page 39, line 6 skipping to change at page 41, line 52
6.7. Implementation Guidelines 6.7. Implementation Guidelines
* RADIUS client implementations SHOULD support this specification, * RADIUS client implementations SHOULD support this specification,
in order to permit the easy deployment of specifications using in order to permit the easy deployment of specifications using
the changes defined herein. the changes defined herein.
* RADIUS server implementations SHOULD support this specification, * RADIUS server implementations SHOULD support this specification,
in order to permit the easy deployment of specifications using in order to permit the easy deployment of specifications using
the changes defined herein. the changes defined herein.
* RADIUS proxy servers SHOULD forward all attributes, even ones * RADIUS proxy servers MUST follow the specifications in section 5.2
which they do not understand, or which are not in a local
dictionary. These attributes SHOULD be forwarded verbatim, with
no modifications or changes.
* When forwarding attributes, RADIUS proxy servers SHOULD forward
the "Reserved" field unchanged. That is, they SHOULD NOT assume
that the "Reserved" field can always be set to zero.
6.8. Vendor Guidelines 6.8. Vendor Guidelines
* Vendors SHOULD use the existing Vendor-Specific Attribute Type * Vendors SHOULD use the existing Vendor-Specific Attribute Type
space in preference to the new Extended-Vendor-Specific space in preference to the new Extended-Vendor-Specific
attributes, as this specification may take time to become widely attributes, as this specification may take time to become widely
deployed. deployed.
* Vendors SHOULD implement this specification. The changes to * Vendors SHOULD implement this specification. The changes to
RADIUS are relatively small, and are likely to quickly be used RADIUS are relatively small, and are likely to quickly be used
in new specifications. in new specifications.
7. Rationale 7. Rationale for This Design
The path to extending the RADIUS protocol has been long and arduous. The path to extending the RADIUS protocol has been long and arduous.
A number of proposals have been made and discarded by the RADEXT A number of proposals have been made and discarded by the RADEXT
working group. These proposals have been judged to be either too working group. These proposals have been judged to be either too
bulky, too complex, too simple, or to be unworkable in practice. We bulky, too complex, too simple, or to be unworkable in practice. We
do not otherwise explain here why earlier proposals did not obtain do not otherwise explain here why earlier proposals did not obtain
working group consensus. working group consensus.
The changes outlined here have the benefit of being simple, as the The changes outlined here have the benefit of being simple, as the
"Extended Type" format requires only a one octet change to the "Extended Type" format requires only a one octet change to the
skipping to change at page 45, line 23 skipping to change at page 48, line 12
As the VSA encapsulates more than 251 octets of data, it is As the VSA encapsulates more than 251 octets of data, it is
split into two RADIUS attributes. The first attribute has the split into two RADIUS attributes. The first attribute has the
More field set, and carries the Vendor-Id and Vendor-Type. More field set, and carries the Vendor-Id and Vendor-Type.
The second attribute has the More field clear, and carries The second attribute has the More field clear, and carries
the rest of the data portion of the VSA. Note that the second the rest of the data portion of the VSA. Note that the second
attribute does not include the Vendor-Id ad Vendor-Type fields. attribute does not include the Vendor-Id ad Vendor-Type fields.
The "Data" portions are indented for readability. The "Data" portions are indented for readability.
245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 245.26.1.6 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb aaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbccccccccccccc
ccccccccccccccccc ccccccccccccccccc
-> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa -> f5 ff 1a 80 00 00 00 01 06 aa aa aa aa aa aa aa aa aa aa aa
skipping to change at page 45, line 45 skipping to change at page 48, line 34
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb aa aa aa aa aa aa aa aa aa aa aa aa aa aa ab bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 17 1a 00 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb f5 18 1a 00 bb
bb bb bb bb cc cc cc cc cc cc cc cc cc cc 13 45 67 89 bb bb bb bb cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
10. IANA Considerations 10. IANA Considerations
This document updates [RFC3575] in that it adds new IANA This document updates [RFC3575] in that it adds new IANA
considerations for RADIUS Attributes. These considerations modify considerations for RADIUS Attributes. These considerations modify
and extend the IANA considerations for RADIUS, rather than replacing and extend the IANA considerations for RADIUS, rather than replacing
them. them.
The IANA considerations of this document are limited to the "RADIUS The IANA considerations of this document are limited to the "RADIUS
Attribute Types" registry. Some Attribute Type values which were Attribute Types" registry. Some Attribute Type values which were
skipping to change at page 48, line 42 skipping to change at page 51, line 29
all allocations should be performed from the extended space. all allocations should be performed from the extended space.
* specifications which allocate a small number of attributes * specifications which allocate a small number of attributes
(i.e. less than ten) should have all allocations made from (i.e. less than ten) should have all allocations made from
the standard space. the standard space.
* specifications which allocate a large number of attributes * specifications which allocate a large number of attributes
(i.e. ten or more) should have all allocations made from the (i.e. ten or more) should have all allocations made from the
extended space. extended space.
* specifications which request allocation of an Attribute of * specifications which request allocation of an attribute of
data type TLV should have that attribute allocated from the data type TLV should have that attribute allocated from the
extended space. extended space.
* specifications which request allocation of an attribute * specifications which request allocation of an attribute
which can transport 253 or more octets of data should have which can transport 253 or more octets of data should have
that attribute allocated from within the long extended space, that attribute allocated from within the long extended space,
We note that Section 6.5, above requires specifications to We note that Section 6.5, above requires specifications to
request this allocation. request this allocation.
There is otherwise no requirement that all attributes within a There is otherwise no requirement that all attributes within a
skipping to change at page 50, line 45 skipping to change at page 53, line 28
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March, 1997. Requirement Levels", RFC 2119, March, 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 2000.
[RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA [RFC5226] Narten, T. and Alvestrand, H, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008. Considerations Section in RFCs", RFC 5226, May 2008.
[SMI] http://www.iana.org/assignments/enterprise-numbers
12.2. Informative references 12.2. Informative references
[RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R. "The MD5 Message-Digest Algorithm", RFC 1321,
April, 1992 April, 1992
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol [RFC2868] Zorn, G., et al, " RADIUS Attributes for Tunnel Protocol
Support", RFC 2868, June 2000. Support", RFC 2868, June 2000.
 End of changes. 57 change blocks. 
167 lines changed or deleted 268 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/