draft-ietf-radext-radius-extensions-09.txt   draft-ietf-radext-radius-extensions-10.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
<draft-ietf-radext-radius-extensions-09.txt> <draft-ietf-radext-radius-extensions-10.txt>
Expires: July 28, 2013 Expires: August 1, 2013
28 January 2013 1 February 2013
Remote Authentication Dial In User Service (RADIUS) Protocol Remote Authentication Dial In User Service (RADIUS) Protocol
Extensions Extensions
draft-ietf-radext-radius-extensions-09.txt draft-ietf-radext-radius-extensions-10.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 3, line 16 skipping to change at page 3, line 16
1. Introduction ............................................. 5 1. Introduction ............................................. 5
1.1. Caveats and Limitations ............................. 6 1.1. Caveats and Limitations ............................. 6
1.1.1. Failure to Meet Certain Goals .................. 6 1.1.1. Failure to Meet Certain Goals .................. 6
1.1.2. Implementation Recommendations ................. 6 1.1.2. Implementation Recommendations ................. 6
1.2. Terminology ......................................... 7 1.2. Terminology ......................................... 7
1.3. Requirements Language ............................... 8 1.3. Requirements Language ............................... 8
2. Extensions to RADIUS ..................................... 9 2. Extensions to RADIUS ..................................... 9
2.1. Extended Type ....................................... 10 2.1. Extended Type ....................................... 10
2.2. Long Extended Type .................................. 11 2.2. Long Extended Type .................................. 11
2.3. TLV Data Type ....................................... 13 2.3. TLV Data Type ....................................... 14
2.3.1. TLV Nesting .................................... 15 2.3.1. TLV Nesting .................................... 16
2.4. EVS Data Type ....................................... 16 2.4. EVS Data Type ....................................... 16
2.5. Integer64 Data Type ................................. 17 2.5. Integer64 Data Type ................................. 18
2.6. Vendor-ID Field ..................................... 18 2.6. Vendor-ID Field ..................................... 18
2.7. Attribute Naming and Type Identifiers ............... 18 2.7. Attribute Naming and Type Identifiers ............... 19
2.7.1. Attribute and TLV Naming ....................... 18 2.7.1. Attribute and TLV Naming ....................... 19
2.7.2. Attribute Type Identifiers ..................... 19 2.7.2. Attribute Type Identifiers ..................... 19
2.7.3. TLV Identifiers ................................ 19 2.7.3. TLV Identifiers ................................ 20
2.7.4. VSA Identifiers ................................ 20 2.7.4. VSA Identifiers ................................ 20
2.8. Invalid Attributes .................................. 21 2.8. Invalid Attributes .................................. 21
3. Attribute Definitions .................................... 21 3. Attribute Definitions .................................... 22
3.1. Extended-Type-1 ..................................... 22 3.1. Extended-Type-1 ..................................... 22
3.2. Extended-Type-2 ..................................... 23 3.2. Extended-Type-2 ..................................... 23
3.3. Extended-Type-3 ..................................... 24 3.3. Extended-Type-3 ..................................... 24
3.4. Extended-Type-4 ..................................... 25 3.4. Extended-Type-4 ..................................... 25
3.5. Long-Extended-Type-1 ................................ 25 3.5. Long-Extended-Type-1 ................................ 26
3.6. Long-Extended-Type-2 ................................ 27 3.6. Long-Extended-Type-2 ................................ 27
4. Vendor Specific Attributes ............................... 28 4. Vendor Specific Attributes ............................... 28
4.1. Extended-Vendor-Specific-1 .......................... 28 4.1. Extended-Vendor-Specific-1 .......................... 29
4.2. Extended-Vendor-Specific-2 .......................... 29 4.2. Extended-Vendor-Specific-2 .......................... 30
4.3. Extended-Vendor-Specific-3 .......................... 31 4.3. Extended-Vendor-Specific-3 .......................... 31
4.4. Extended-Vendor-Specific-4 .......................... 32 4.4. Extended-Vendor-Specific-4 .......................... 32
4.5. Extended-Vendor-Specific-5 .......................... 33 4.5. Extended-Vendor-Specific-5 .......................... 33
4.6. Extended-Vendor-Specific-6 .......................... 34 4.6. Extended-Vendor-Specific-6 .......................... 35
5. Compatibility with traditional RADIUS .................... 36 5. Compatibility with traditional RADIUS .................... 36
5.1. Attribute Allocation ................................ 36 5.1. Attribute Allocation ................................ 36
5.2. Proxy Servers ....................................... 37 5.2. Proxy Servers ....................................... 37
6. Guidelines ............................................... 38 6. Guidelines ............................................... 38
6.1. Updates to RFC 6158 ................................. 38 6.1. Updates to RFC 6158 ................................. 38
6.2. Guidelines for Simple Data Types .................... 38 6.2. Guidelines for Simple Data Types .................... 38
6.3. Guidelines for Complex Data Types ................... 39 6.3. Guidelines for Complex Data Types ................... 39
6.4. Design Guidelines For the New Types ................. 40 6.4. Design Guidelines For the New Types ................. 40
6.5. TLV Guidelines ...................................... 40 6.5. TLV Guidelines ...................................... 40
6.6. Allocation Request Guidelines ....................... 41 6.6. Allocation Request Guidelines ....................... 41
6.7. Allocation Requests Guidelines for TLVs ............. 42 6.7. Allocation Requests Guidelines for TLVs ............. 42
6.8. Implementation Guidelines ........................... 42 6.8. Implementation Guidelines ........................... 43
6.9. Vendor Guidelines ................................... 43 6.9. Vendor Guidelines ................................... 43
7. Rationale for This Design ................................ 43 7. Rationale for This Design ................................ 43
7.1. Attribute Audit ..................................... 43 7.1. Attribute Audit ..................................... 43
8. Diameter Considerations .................................. 44 8. Diameter Considerations .................................. 44
9. Examples ................................................. 44 9. Examples ................................................. 45
9.1. Extended Type ....................................... 46 9.1. Extended Type ....................................... 46
9.2. Long Extended Type .................................. 47 9.2. Long Extended Type .................................. 47
10. IANA Considerations ..................................... 49 10. IANA Considerations ..................................... 50
10.1. Attribute Allocations .............................. 50 10.1. Attribute Allocations .............................. 50
10.2. RADIUS Attribute Type Tree ......................... 50 10.2. RADIUS Attribute Type Tree ......................... 50
10.3. Allocation Instructions ............................ 51 10.3. Allocation Instructions ............................ 51
10.3.1. Requested Allocation from the Standard Space .. 51 10.3.1. Requested Allocation from the Standard Space .. 52
10.3.2. Requested Allocation from the short extended sp 51 10.3.2. Requested Allocation from the short extended sp 52
10.3.3. Requested Allocation from the long extended spa 52 10.3.3. Requested Allocation from the long extended spa 52
10.3.4. Allocation Preferences ........................ 52 10.3.4. Allocation Preferences ........................ 52
10.3.5. Extending the Type Space via TLV Data Type .... 52 10.3.5. Extending the Type Space via TLV Data Type .... 53
10.3.6. Allocation within a TLV ....................... 53 10.3.6. Allocation within a TLV ....................... 53
10.3.7. Allocation of Other Data Types ................ 53 10.3.7. Allocation of Other Data Types ................ 54
11. Security Considerations ................................. 53 11. Security Considerations ................................. 54
12. References .............................................. 54 12. References .............................................. 54
12.1. Normative references ............................... 54 12.1. Normative references ............................... 54
12.2. Informative references ............................. 54 12.2. Informative references ............................. 55
Appendix A - Extended Attribute Generator Program ............ 56 Appendix A - Extended Attribute Generator Program ............ 56
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
skipping to change at page 6, line 40 skipping to change at page 6, line 40
deployments, and implementation difficulty. deployments, and implementation difficulty.
1.1. Caveats and Limitations 1.1. Caveats and Limitations
This section describes some caveats and limitations with the This section describes some caveats and limitations with the
proposal. proposal.
1.1.1. Failure to Meet Certain Goals 1.1.1. Failure to Meet Certain Goals
One goal which was not met by the above modifications is to have an One goal which was not met by the above modifications is to have an
incentive for standards to use the new space. We would ideally like incentive for standards to use the new space. That incenctive is
to deprecate the "Unassigned" attributes in the standard space, which being provided by the exhaustion of the standard space.
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 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
skipping to change at page 7, line 23 skipping to change at page 7, line 20
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), but the contents of the
the attribute does not follow the format required by the data type Attribute do not follow the correct format. For example, an
defined for that Attribute. e.g. an Attribute of type "address" Attribute of type "address" which encapsulates more than four, or
which encapsulates more than four, or less than four, octets of less than four, octets of data. See Section 2.8 for a more
data. See Section 2.8 for a more complete definition. 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 [RFC2865]. and that follow the format defined in Section 5 of [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.
skipping to change at page 10, line 37 skipping to change at page 10, line 37
server receives an Extended Attribute with a Length of 2 or 3, server receives an Extended Attribute with a Length of 2 or 3,
then that Attribute MUST be considered to be an "invalid then that Attribute MUST be considered to be an "invalid
attribute", and handled as per Section 2.8, 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 MUST 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
the Type field. That is, this field may be thought of as defining 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 a new type space of the form "Type.Extended-Type". See Section
2.5, below, for additional discussion. 2.5, below, for additional discussion.
A RADIUS server MAY ignore Attributes with an unknown A RADIUS server MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
A RADIUS client MAY ignore Attributes with an unknown A RADIUS client MAY ignore Attributes with an unknown
"Type.Extended-Type". "Type.Extended-Type".
Value Value
This field is similar to the Value field of the Attribute format This field is similar to the Value field of the Attribute format
defined in [RFC2865] Section 5. The format of the data SHOULD be defined in [RFC2865] Section 5. The format of the data SHOULD be
a valid RADIUS data type. a valid RADIUS data type.
The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as
undistinguished 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 The addition of the Extended-Type field decreases the maximum
length for attributes of type "text" or "string" from 253 to 252 length for attributes of type "text" or "string" from 253 to 252
octets. Where an Attribute needs to carry more than 252 octets of octets. Where an Attribute needs to carry more than 252 octets of
data, the "Long Extended Type" format SHOULD be used. data, the "Long Extended Type" format SHOULD be used.
Experience has shown that the "experimental" and "implementation Experience has shown that the "experimental" and "implementation
specific" attributes defined in [RFC2865] Section 5 have had little specific" attributes defined in [RFC2865] Section 5 have had little
practical value. We therefore do not continue that practice here practical value. We therefore do not continue that practice here
with the Extended-Type field. with the Extended-Type field.
skipping to change at page 12, line 17 skipping to change at page 12, line 26
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.
If the More field is set (1), it indicates that the Value field If the More field is set (1), it indicates that the Value field
has been fragmented across multiple RADIUS attributes. When the has been fragmented across multiple RADIUS attributes. When the
More field is set (1), the attribute SHOULD have a Length field of More field is set (1), the attribute MUST have a Length field of
value 255; it MUST NOT have a length Field of value 4; there MUST value 255; there MUST be an attribute following this one; and the
be an attribute following this one; and the next attribute MUST next attribute MUST have both the same Type and Extended Type.
have both the same Type and Extended Type. That is, multiple That is, multiple fragments of the same value MUST be in order and
fragments of the same value MUST be in order and MUST be MUST be consecutive attributes in the packet, and the last
consecutive attributes in the packet, and the last attribute in a 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 That is, a packet containing a fragmented attribute needs to
More field SHOULD be clear (0). 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 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.8, 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
skipping to change at page 12, line 49 skipping to change at page 13, line 12
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
invalid if it is non-zero. invalid if it is non-zero.
Value Value
This field is similar to the Value field of the Attribute format This field is similar to the Value field of the Attribute format
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.
The Value field is one or more octets. Implementations not
supporting this specification SHOULD support the field as
undistinguished 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 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. 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 We note that the maximum size of a fragmented attribute is limited
only by the RADIUS packet length limitation (i.e. 4096 octets, not only by the RADIUS packet length limitation (i.e. 4096 octets, not
counting various headers and overhead). Implementations SHOULD be counting various headers and overhead). Implementations MUST be
able to handle fragmented attributes of 4096 octets. able to handle the case where one fragmented attribute completely
fill the packet.
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: Note that [RFC2865] Section 5 says:
If multiple Attributes with the same Type are present, the order If multiple Attributes with the same Type are present, the order
of Attributes with the same Type MUST be preserved by any proxies. of Attributes with the same Type MUST be preserved by any proxies.
The order of Attributes of different Types is not required to be The order of Attributes of different Types is not required to be
preserved. A RADIUS server or client MUST NOT have any preserved. A RADIUS server or client MUST NOT have any
dependencies on the order of attributes of different types. A dependencies on the order of attributes of different types. A
RADIUS server or client MUST NOT require attributes of the same RADIUS server or client MUST NOT require attributes of the same
type to be contiguous. type to be contiguous.
These requirements also apply to the "Long Extended Type" attribute, These requirements also apply to the "Long Extended Type" attribute,
including fragments. Implementations MUST be able to process non- including fragments. Implementations SHOULD be able to process non-
contiguous fragments. That is, fragments which are mixed together contiguous fragments. That is, fragments which are mixed together
with other attributes of a different Type. 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.
skipping to change at page 14, line 30 skipping to change at page 15, line 4
A RADIUS client 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- 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.8, 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 TLV-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. Use of non-standard data types SHOULD NOT be done. 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
skipping to change at page 17, line 5 skipping to change at page 17, line 23
Vendor-Id Vendor-Id
The 4 octets are the Network Management Private Enterprise Code The 4 octets are the Network Management Private Enterprise Code
[PEN] of the Vendor in network byte order. [PEN] 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 String
The Value field is one or more octets. It SHOULD encapsulate a The String 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
types is NOT RECOMMENDED. We note that the Value field may be of types is NOT RECOMMENDED. We note that the Value field may be of
data type "tlv". However, it MUST NOT be of data type "evs", as data type "tlv". However, it MUST NOT be of data type "evs", as
the use cases are unclear for one vendor delegating Attribute Type the use cases are unclear for one vendor delegating Attribute Type
space to another vendor. space to another vendor.
The actual format of the information is site or application The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field as specific, and a robust implementation SHOULD support the field as
undistinguished octets. We recognise that Vendors have complete undistinguished octets. We recognise that Vendors have complete
control over the contents and format of the Value field, while at control over the contents and format of the Value field, while at
skipping to change at page 19, line 41 skipping to change at page 20, line 14
possible type code values, with values 1 through 240 available for possible type code values, with values 1 through 240 available for
allocation. We define here an identification method that uses a allocation. We define here an identification method that uses a
"dotted number" notation similar to that used for Object Identifiers "dotted number" notation similar to that used for Object Identifiers
(OIDs), formatted as "Type.Extended-Type". (OIDs), formatted as "Type.Extended-Type".
For example, an attribute within the Type space of 241, having For example, an attribute within the Type space of 241, having
Extended-Type of one (1), is uniquely identified as "241.1". Extended-Type of one (1), is uniquely identified as "241.1".
Similarly, an attribute within the Type space of 246, having Similarly, an attribute within the Type space of 246, having
Extended-Type of ten (10), is uniquely identified as "246.10". Extended-Type of ten (10), is uniquely identified as "246.10".
The algorithm used to create the Attribute Identifier is simply to
concatenate all of the various identification fields (e.g. Type,
Extended-Type, etc.), starting from the encapsulating attribute, down
to the final encapsulated TLV, separated by a '.' character.
2.7.3. TLV Identifiers 2.7.3. TLV Identifiers
We can extend the Attribute reference scheme defined above for TLVs. We can extend the Attribute reference scheme defined above for TLVs.
This is done by leveraging the "dotted number" notation. As above, This is done by leveraging the "dotted number" notation. As above,
we define an additional TLV type space, within the "Extended Type" we define an additional TLV type space, within the "Extended Type"
space, by appending another "dotted number" in order to identify the space, by appending another "dotted number" in order to identify the
TLV. This method can be replied in sequence for nested TLVs. TLV. This method can be repeated in sequence for nested TLVs.
For example, let us say that "245.1" identifies RADIUS Attribute Type For example, let us say that "245.1" identifies RADIUS Attribute Type
245, containing an "Extended Type" of one (1), which is of type 245, containing an "Extended Type" of one (1), which is of type
"tlv". That attribute will contain 256 possible TLVs, one for each "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 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 then be identified by appending a ".1" to the number of the
encapsulating attribute ("241.1"), to yield "241.1.1". Similarly, encapsulating attribute ("241.1"), to yield "241.1.1". Similarly,
the sequence "245.2.3.4" identifies RADIUS attribute 245, containing 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 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 contains a TLV with TLV-Type number three (3), which in turn contains
skipping to change at page 21, line 26 skipping to change at page 21, line 41
While the content of these attributes is malformed, we emphasize that While the content of these attributes is malformed, we emphasize that
the encapsulating RADIUS packet, or attribute, or TLV, is well the encapsulating RADIUS packet, or attribute, or TLV, is well
formed, and can be correctly decoded. The existence of an "invalid formed, and can be correctly decoded. The existence of an "invalid
attribute" in a packet MUST NOT result in the implementation attribute" in a packet MUST NOT result in the implementation
discarding the entire packet, or treating the packet as a negative discarding the entire packet, or treating the packet as a negative
acknowledgement. Instead, only the "invalid attribute" is treated acknowledgement. Instead, only the "invalid attribute" is treated
differently. differently.
When an implementation receives an "invalid attribute", it SHOULD be When an implementation receives an "invalid attribute", it SHOULD be
silently discarded. If it is not discarded, it MUST NOT be handled silently discarded, except when the implementation is acting as a
in the same manner as a well-formed attribute. For example, proxy (see Section 5.2 for discussion of proxy servers). If it is
receiving an Attribute of data type "address" containing less than not discarded, it MUST NOT be handled in the same manner as a well-
four octets, or more than four octets of data means that the formed attribute. For example, receiving an Attribute of data type
Attribute MUST NOT be treated as being of data type "address". The "address" containing less than four octets, or more than four octets
reason here is that if the attribute does not carry an IPv4 address, of data means that the Attribute MUST NOT be treated as being of data
the receiver has no idea what format the data is in, and it is type "address". The reason here is that if the attribute does not
therefore not an IPv4 address. 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 For Attributes of type "Long Extended Type", an Attribute is
considered to be an "invalid attribute" when does not match the considered to be an "invalid attribute" when it does not match the
criteria set out in Section 2.2, above. criteria set out in Section 2.2, above.
For Attributes of type "TLV", an Attribute is considered to be an For Attributes of type "TLV", an Attribute is considered to be an
"invalid attribute" when the TLV-Length field allows the "invalid attribute" when the TLV-Length field allows the
encapsulating Attribute to be parsed, but the TLV-Value field does encapsulating Attribute to be parsed, but the TLV-Value field does
not match the criteria for that TLV. Implementations SHOULD NOT not match the criteria for that TLV. Implementations SHOULD NOT
treat the "invalid attribute" property as being transitive. That is, treat the "invalid attribute" property as being transitive. That is,
the Attribute encapsulating the "invalid attribute" SHOULD NOT be the Attribute encapsulating the "invalid attribute" SHOULD NOT be
treated as an "invalid attribute". That encapsulating Attribute treated as an "invalid attribute". That encapsulating Attribute
might contain multiple TLVs, only one of which is an "invalid might contain multiple TLVs, only one of which is an "invalid
skipping to change at page 39, line 31 skipping to change at page 39, line 45
complexity in non-RADIUS systems or where using the basic data complexity in non-RADIUS systems or where using the basic data
types types
would be awkward (such as where grouping would be required in would be awkward (such as where grouping would be required in
order order
to link related attributes). to link related attributes).
Since the extended attribute format allows for grouping of complex Since the extended attribute format allows for grouping of complex
types via TLVs, the guidelines for complex data types need to be types via TLVs, the guidelines for complex data types need to be
updated as follows: updated as follows:
Complex data types MAY be used where they reduce complexity in [RFC6158], Section 3.2.4, describes situations in which complex
non-RADIUS systems, though this practice is NOT RECOMMENDED. The data types might be appropriate. They SHOULD NOT be used even in
complex data type exceptions of [RFC6158] Section 3.2.4 still those situations, without careful consideration of the described
apply. In all other situations, complex data types MUST NOT be limitations. In all other cases not covered by the complex data
used. Instead, complex data types MUST be decomposed into TLVs. type exceptions, complex data types MUST NOT be used. Instead,
complex data types MUST be decomposed into TLVs.
The checklist in Appendix A.2.2 is similarly updated to add a new The checklist in Appendix A.2.2 is similarly updated to add a new
requirement at the top of that section, requirement at the top of that section,
Does the attribute: Does the attribute:
* define a complex type which can be represented via TLVs? * define a complex type which can be represented via TLVs?
If so, this data type MUST be represented via TLVs. If so, this data type MUST be represented via TLVs.
skipping to change at page 40, line 16 skipping to change at page 40, line 29
This section gives design guidelines for specifications defining This section gives design guidelines for specifications defining
attributes using the new format. The items listed below are not attributes using the new format. The items listed below are not
exhaustive. As experience is gained with the new formats, later exhaustive. As experience is gained with the new formats, later
specifications may define additional guidelines. specifications may define additional guidelines.
* The data type "evs" MUST NOT be used for standard RADIUS * The data type "evs" MUST NOT be used for standard RADIUS
Attributes, or for TLVs, or for VSAs. Attributes, or for TLVs, or for VSAs.
* The data type "tlv" SHOULD NOT be used for standard RADIUS * The data type "tlv" SHOULD NOT be used for standard RADIUS
attributes. This format was NOT RECOMMENDED by [RFC6158], attributes.
but their utility is now evident.
* [RFC2866] "tagged" attributes MUST NOT be defined in the * [RFC2866] "tagged" attributes MUST NOT be defined in the
Extended-Type space. The "tlv" data type should be used instead Extended-Type space. The "tlv" data type should be used instead
to group attributes. to group attributes.
* The "integer64" data type MAY be used in any RADIUS attribute. * The "integer64" data type MAY be used in any RADIUS attribute.
The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but The use of 64-bit integers is NOT RECOMMENDED by [RFC6158], but
their utility is now evident. their utility is now evident.
* Any attribute which is allocated from the "long extended space" of * Any attribute which is allocated from the "long extended space" of
skipping to change at page 41, line 45 skipping to change at page 42, line 9
* Specifications of an attribute which always encode less than 253 * Specifications of an attribute which always encode less than 253
octets of data MUST NOT request allocation from the long extended octets of data MUST NOT request allocation from the long extended
space. The standard space, or the short extended space MUST be space. The standard space, or the short extended space 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 will have to be written which requests allocation of one or more
Attributes from the "Reserved" portion of the standard space, RADIUS Attributes from the "Reserved" portion of the standard space,
values 247-255, using an appropriate format ("Short Extended Type", values 247-255, using an appropriate format ("Short Extended Type",
or "Long Extended Type") or "Long Extended Type")
An allocation request made in a specification SHOULD use one of the An allocation request made in a specification SHOULD use one of the
following formats when allocating an attribute type code: following formats when allocating an attribute type code:
* TBDn - request allocation of an attribute from the "standard * TBDn - request allocation of an attribute from the "standard
space". The value "n" should be "1" or more, to track individual space". The value "n" should be "1" or more, to track individual
attributes which are to be allocated. attributes which are to be allocated.
skipping to change at page 45, line 18 skipping to change at page 45, line 31
by the program given in Appendix A. The language is line oriented, by the program given in Appendix A. The language is line oriented,
and composed of a sequence of lines matching the grammar ([RFC5234]) and composed of a sequence of lines matching the grammar ([RFC5234])
given below: given below:
Identifier = 1*DIGIT *( "." 1*DIGIT ) Identifier = 1*DIGIT *( "." 1*DIGIT )
HEXCHAR = HEXDIG HEXDIG HEXCHAR = HEXDIG HEXDIG
STRING = DQUOTE 1*CHAR DQUOTE STRING = DQUOTE 1*CHAR DQUOTE
TLV = "{" 1*DIGIT DATA "}" TLV = "{" SP 1*DIGIT SP DATA SP "}"
DATA = 1*HEXCHAR / 1*TLV / STRING DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING
LINE = Identifier DATA LINE = Identifier SP DATA
The program has additional restrictions on its input that are not The program has additional restrictions on its input that are not
reflected in the above grammar. For example, the portions of the reflected in the above grammar. For example, the portions of the
Identifier which refer to Type and Extended-Type are limited to Identifier which refer to Type and Extended-Type are limited to
values between 1 and 255. We trust that the source code in Appendix values between 1 and 255. We trust that the source code in Appendix
A is clear, and that these restrictions do not negatively affect the A is clear, and that these restrictions do not negatively affect the
comprehensibility of the examples. comprehensibility of the examples.
The program reads the input text, and interprets it as a set of The program reads the input text, and interprets it as a set of
instructions to create RADIUS Attributes. It then prints the hex instructions to create RADIUS Attributes. It then prints the hex
skipping to change at page 48, line 23 skipping to change at page 48, line 35
with Vendor-Id of 1, and Vendor-Type of 5, which in turn with Vendor-Id of 1, and Vendor-Type of 5, which in turn
encapsulates a TLV with TLV-Type of 3, which encapsulates encapsulates a TLV with TLV-Type of 3, which encapsulates
textual data. textual data.
245.26.1.5 { 3 "test" } 245.26.1.5 { 3 "test" }
-> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74 -> f5 0f 1a 00 00 00 00 01 05 03 06 74 65 73 74
Attribute encapsulating more than 251 octets of data. The "Data" Attribute encapsulating more than 251 octets of data. The "Data"
portions are indented for readability. portions are indented for readability.
245.4 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 245.4 "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb aaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbcccccccccccccccccccc
cccccccccc ccccccccccc"
-> f5 ff 04 80 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa -> f5 ff 04 80 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 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 bb bb bb bb bb 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
skipping to change at page 49, line 12 skipping to change at page 49, line 24
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 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 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
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 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
skipping to change at page 52, line 25 skipping to change at page 52, line 38
Type Space should have Attributes allocated using the following Type Space should have Attributes allocated using the following
criteria: criteria:
* when the standard space has no more Unassigned attributes, * when the standard space has no more Unassigned attributes,
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 would allocate a large percentage of the * specifications which would allocate a more than twenty percent
remaining standard space attributes should have all allocations of
made from the extended space. the remaining standard space attributes should have all
allocations made from the 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.
skipping to change at page 67, line 32 skipping to change at page 67, line 32
if (fp != stdin) fclose(fp); if (fp != stdin) fclose(fp);
return 0; return 0;
} }
------------------------------------------------------------ ------------------------------------------------------------
Author's Address Author's Address
Alan DeKok Alan DeKok
Network RADIUS SARL Network RADIUS SARL
15 av du Granier 57bis blvd des Alpes
38240 Meylan 38240 Meylan
France France
Email: aland@networkradius.com Email: aland@networkradius.com
URI: http://networkradius.com URI: http://networkradius.com
Avi Lior Avi Lior
Bridgewater Systems Corporation Email: avi.ietf@lior.org
303 Terry Fox Drive
Suite 100
Ottawa, Ontario K2K 3J1
Canada
Phone: +1 (613) 591-6655
Email: avi@bridgewatersystems.com
URI: http://www.bridgewatersystems.com/
 End of changes. 49 change blocks. 
89 lines changed or deleted 105 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/