draft-ietf-radext-design-15.txt   draft-ietf-radext-design-16.txt 
Network Working Group Alan DeKok (ed.) Network Working Group Alan DeKok (ed.)
INTERNET-DRAFT FreeRADIUS INTERNET-DRAFT FreeRADIUS
Category: Best Current Practice G. Weber Category: Best Current Practice G. Weber
<draft-ietf-radext-design-15.txt> Individual Contributor <draft-ietf-radext-design-16.txt> Individual Contributor
Expires: January 21, 2011 Expires: February 9, 2011
21 June 2010 9 July 2010
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-15 draft-ietf-radext-design-16
Abstract Abstract
This document provides guidelines for the design of attributes used This document provides guidelines for the design of attributes used
by the Remote Authentication Dial In User Service (RADIUS) protocol. by the Remote Authentication Dial In User Service (RADIUS) protocol.
It is expected that these guidelines will prove useful to authors and It is expected that these guidelines will prove useful to authors and
reviewers of future RADIUS attribute specifications, both within the reviewers of future RADIUS attribute specifications, both within the
IETF as well as other Standards Development Organizations (SDOs). IETF as well as other Standards Development Organizations (SDOs).
Status of this Memo Status of this Memo
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 21, 2011. This Internet-Draft will expire on February 9, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction ............................................. 5 1. Introduction ............................................. 5
1.1. Terminology ......................................... 5 1.1. Terminology ......................................... 5
1.2. Requirements Language ............................... 6 1.2. Requirements Language ............................... 6
1.3. Applicability ....................................... 6 1.3. Applicability ....................................... 6
1.3.1. Reviews ........................................ 7 1.3.1. Reviews ........................................ 7
2. Guidelines ............................................... 8 2. Guidelines ............................................... 8
2.1. Data Types .......................................... 9 2.1. Data Types .......................................... 9
2.2. Vendor-Specific Attribute Space ..................... 10 2.2. Vendor-Specific Attribute Space ..................... 10
2.3. Service definitions and RADIUS ...................... 11 2.3. Service definitions and RADIUS ...................... 10
2.4. Translation of Vendor Specifications ................ 11 2.4. Translation of Vendor Specifications ................ 11
3. Rationale ................................................ 12 3. Rationale ................................................ 12
3.1. RADIUS Operational Model ............................ 12 3.1. RADIUS Operational Model ............................ 12
3.2. Data Model Issues ................................... 15 3.2. Data Model Issues ................................... 15
3.2.1. Basic Data Types ............................... 16 3.2.1. Issues with Definitions of Types ............... 15
3.2.2. Tagging Mechanism .............................. 17 3.2.2. Tagging Mechanism .............................. 16
3.2.3. Complex Data Types ............................. 18 3.2.3. Complex Data Types ............................. 17
3.3. Vendor Space ........................................ 20 3.3. Vendor Space ........................................ 20
3.3.1. Interoperability Considerations ................ 21 3.3.1. Interoperability Considerations ................ 21
3.3.2. Vendor Allocations ............................. 22 3.3.2. Vendor Allocations ............................. 21
3.3.3. SDO Allocations ................................ 22 3.3.3. SDO Allocations ................................ 21
3.4. Polymorphic Attributes .............................. 23 3.4. Polymorphic Attributes .............................. 22
4. IANA Considerations ...................................... 23 4. IANA Considerations ...................................... 23
5. Security Considerations .................................. 24 5. Security Considerations .................................. 23
5.1. New Data Types and Complex Attributes ............... 24 5.1. New Data Types and Complex Attributes ............... 24
6. References ............................................... 25 6. References ............................................... 24
6.1. Normative References ................................ 25 6.1. Normative References ................................ 24
6.2. Informative References .............................. 26 6.2. Informative References .............................. 25
Appendix A - Design Guidelines ............................... 28 Appendix A - Design Guidelines ............................... 28
A.1. Types matching the RADIUS data model ................. 28 A.1. Types matching the RADIUS data model ................. 28
A.1.1. Transport of basic data types ................... 28 A.1.1. Transport of basic data types ................... 28
A.1.2. Transport of Authentication and Security Data ... 29 A.1.2. Transport of Authentication and Security Data ... 28
A.1.3. Opaque data types ............................... 29 A.1.3. Opaque data types ............................... 28
A.1.4. Pre-existing data types ......................... 29 A.1.4. Pre-existing data types ......................... 28
A.2. Improper Data Types .................................. 30 A.2. Improper Data Types .................................. 29
A.2.1. Basic Data Types ................................ 30 A.2.1. Basic Data Types ................................ 29
A.2.2. Complex Data Types .............................. 30 A.2.2. Complex Data Types .............................. 30
A.3. Vendor-Specific formats .............................. 31 A.3. Vendor-Specific formats .............................. 30
A.4. Changes to the RADIUS Operational Model .............. 31 A.4. Changes to the RADIUS Operational Model .............. 31
A.5. Allocation of attributes ............................. 33 A.5. Allocation of attributes ............................. 32
Appendix B - Complex Attributes .............................. 34 Appendix B - Complex Attributes .............................. 33
B.1. CHAP-Password ........................................ 34 B.1. CHAP-Password ........................................ 33
B.2. CHAP-Challenge ....................................... 34 B.2. CHAP-Challenge ....................................... 33
B.3. Tunnel-Password ...................................... 34 B.3. Tunnel-Password ...................................... 33
B.4. ARAP-Password ........................................ 35 B.4. ARAP-Password ........................................ 34
B.5. ARAP-Features ........................................ 35 B.5. ARAP-Features ........................................ 34
B.6. Connect-Info ......................................... 36 B.6. Connect-Info ......................................... 35
B.7. Framed-IPv6-Prefix ................................... 37 B.7. Framed-IPv6-Prefix ................................... 36
B.8. Egress-VLANID ........................................ 37 B.8. Egress-VLANID ........................................ 36
B.9. Egress-VLAN-Name ..................................... 38 B.9. Egress-VLAN-Name ..................................... 37
B.9. Digest-* ............................................. 38 B.10. Digest-* ............................................ 37
1. Introduction 1. Introduction
This document provides guidelines for the design of RADIUS attributes This document provides guidelines for the design of RADIUS attributes
both within the IETF as well as within other SDOs. By articulating both within the IETF as well as within other SDOs. By articulating
RADIUS design guidelines, it is hoped that this document will RADIUS design guidelines, it is hoped that this document will
encourage the development and publication of high quality RADIUS encourage the development and publication of high quality RADIUS
attribute specifications. attribute specifications.
However, the advice in this document will not be helpful unless it is However, the advice in this document will not be helpful unless it is
skipping to change at page 8, line 21 skipping to change at page 8, line 21
Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does
not define a formal data definition language. The data type of not define a formal data definition language. The data type of
RADIUS attributes is not transported on the wire. Rather, the data RADIUS attributes is not transported on the wire. Rather, the data
type of a RADIUS attribute is fixed when an attribute is defined. type of a RADIUS attribute is fixed when an attribute is defined.
Based on the RADIUS attribute type code, RADIUS clients and servers Based on the RADIUS attribute type code, RADIUS clients and servers
can determine the data type based on preconfigured entries within a can determine the data type based on preconfigured entries within a
data dictionary. data dictionary.
To explain the implications of this early RADIUS design decision we To explain the implications of this early RADIUS design decision we
distinguish two types of data types, namely "basic" and "complex". distinguish two types of data types, namely "basic" and "complex".
Basic data types use one of the existing RADIUS data types as defined Basic data types use one of the existing RADIUS data types defined in
below, encapsulated in a [RFC2865] RADIUS attribute, or in a Section 2.1, encapsulated in a [RFC2865] RADIUS attribute, or in a
[RFC2865] RADIUS VSA. All other data formats are "complex types". [RFC2865] RADIUS VSA. All other data formats are "complex types".
RADIUS attributes can be classified into one of three broad RADIUS attributes can be classified into one of three broad
categories: categories:
* Attributes that are of interest to a single vendor, e.g., for a * Attributes that are of interest to a single vendor, e.g., for a
product or product line. Minimal cross-vendor interoperability product or product line. Minimal cross-vendor interoperability
is needed. is needed.
Vendor-Specific Attributes (VSAs) are appropriate for use in Vendor-Specific Attributes (VSAs) are appropriate for use in
skipping to change at page 9, line 34 skipping to change at page 9, line 34
* Interface-Id (8 octet string in network byte order) * Interface-Id (8 octet string in network byte order)
* IPv6 prefix. * IPv6 prefix.
* string (i.e., binary data), totalling 253 octets or less in * string (i.e., binary data), totalling 253 octets or less in
length. This includes the opaque encapsulation of data length. This includes the opaque encapsulation of data
structures defined outside of RADIUS. See also Appendix A.1.3, structures defined outside of RADIUS. See also Appendix A.1.3,
below, for additional discussion. below, for additional discussion.
* UTF-8 text, totalling 253 octets or less in length. * UTF-8 text [RFC3629], totalling 253 octets or less in length.
Note that the length limitations for VSAs of type String and Text are Note that the length limitations for VSAs of type String and Text are
less than 253 octets, due to the additional overhead of the Vendor- less than 253 octets, due to the additional overhead of the Vendor-
Specific encoding. Specific encoding.
The following data also qualifies as "basic data types": The following data also qualifies as "basic data types":
* Attributes grouped into a logical container, using the * Attributes grouped into a logical container, using the
[RFC2868] tagging mechanism. This approach is NOT RECOMMENDED, [RFC2868] tagging mechanism. This approach is NOT RECOMMENDED
but is permissible where the alternatives are worse. (see Section 3.2.2), but is permissible where the alternatives
are worse.
* Attributes requiring the transport of more than 253 octets of * Attributes requiring the transport of more than 253 octets of
Text or String data. This includes the opaque encapsulation Text or String data. This includes the opaque encapsulation
of data structures defined outside of RADIUS. of data structures defined outside of RADIUS.
(e.g. EAP-Message) (e.g. EAP-Message)
All other data formats (including nested attributes) are defined to All other data formats (including nested attributes) are defined to
be "complex data types", and are NOT RECOMMENDED for normal use. be "complex data types", and are NOT RECOMMENDED for normal use.
Complex data types MAY be used in situations where they reduce Complex data types MAY be used in situations where they reduce
complexity in non-RADIUS systems, or where using the basic data types complexity in non-RADIUS systems, or where using the basic data types
would be awkward (such as where grouping would be required in order would be awkward (such as where grouping would be required in order
to link related attributes). Since there are no "hard and fast" to link related attributes). Since there are no "hard and fast"
rules for where complexity is best located, each situation has to be rules for where complexity is best located, each situation has to be
decided on a case-by-case basis. Examples of this tradeoff are decided on a case-by-case basis. Examples of this tradeoff are
discussed in Appendix B. Where a complex data type is selected, an discussed in Appendix B. Where a complex data type is selected, an
explanation SHOULD be offered as to why this was necessary. explanation SHOULD be offered as to why this was necessary.
There may be situations where complex attributes are acceptable
because they reduce complexity in non-RADIUS systems, or because
leveraging the basic data types would be awkward. Unfortunately,
there are no "hard and fast" rules for where the complexity would
best be located. Each situation has to be decided on a case-by-case
basis. The cost-benefit trade-off may result in a "complex data
type" being defined in RADIUS, as discussed in Appendix B. When this
is done, an explanation SHOULD be offered as to why the complex data
type was used.
2.2. Vendor-Specific Attribute Space 2.2. Vendor-Specific Attribute Space
The Vendor-Specific Attribute space is defined to be the contents of The Vendor-Specific Attribute space is defined to be the contents of
the "String" field of the Vendor-Specific Attribute ([RFC2865] the "String" field of the Vendor-Specific Attribute ([RFC2865]
Section 5.26). As discussed there, it is intended for vendors and Section 5.26). As discussed there, it is intended for vendors and
SDOs to support their own Attributes not suitable for general use. SDOs to support their own Attributes not suitable for general use.
While the encoding of attributes within the vendor space is under the While the encoding of attributes within the vendor space is under the
control of vendors and SDOs, following the guidelines described here control of vendors and SDOs, following the guidelines described here
is advantageous since it enables maximum interoperability with is advantageous since it enables maximum interoperability with
skipping to change at page 16, line 5 skipping to change at page 15, line 42
For example, vendors and SDOs have evolved the data model to support For example, vendors and SDOs have evolved the data model to support
functions such as new data types, along with attribute grouping and functions such as new data types, along with attribute grouping and
attribute fragmentation, with different groups taking different attribute fragmentation, with different groups taking different
approaches. These approaches are often incompatible, leading to approaches. These approaches are often incompatible, leading to
additional complexity in RADIUS implementations. additional complexity in RADIUS implementations.
In order to avoid repeating old mistakes, this section describes the In order to avoid repeating old mistakes, this section describes the
history of the RADIUS data model, and attempts to codify existing history of the RADIUS data model, and attempts to codify existing
practices. practices.
3.2.1. Basic Data Types 3.2.1. Issues with Definitions of Types
[RFC2865] and [RFC2866] utilize data types defined in [RFC2865]
Section 5, which states the following:
The format of the value field is one of five data types. Note
that type "text" is a subset of type "string".
text 1-253 octets containing UTF-8 encoded 10646 [RFC3629]
characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead.
string 1-253 octets containing binary data (values 0 through
255 decimal, inclusive). Strings of length zero (0)
MUST NOT be sent; omit the entire attribute instead.
address 32 bit value, most significant octet first.
integer 32 bit unsigned value, most significant octet first.
time 32 bit unsigned value, most significant octet first -- [RFC2865] Section 5 explicitly defines five data types: text, string,
seconds since 00:00:00 UTC, January 1, 1970. The address, integer and time. Both the names and interpretations of the
standard Attributes do not use this data type but it is types are given.
presented here for possible use in future attributes.
Subsequent RADIUS specifications also defined attributes using new Subsequent RADIUS specifications defined attributes by using type
data types. These specifications did not explicitly define those names not defined in [RFC2865], without defining the new names as was
data types as was done in [RFC2865]. They did not consistently done in [RFC2865]. They did not consistently indicate the format of
indicate the format of the value field using the same conventions as the value field using the same conventions as [RFC2865]. As a
[RFC2865]. As a result, the data type is ambiguous in some cases, result, the data type is ambiguous in some cases, and may not be
and may not be consistent among different implementations. consistent among different implementations.
It is out of the scope of this document to resolve all potential It is out of the scope of this document to resolve all potential
ambiguities within existing RADIUS specifications. However in order ambiguities within existing RADIUS specifications. However in order
to prevent future ambiguities, it is recommended that future RADIUS to prevent future ambiguities, it is recommended that future RADIUS
attribute specifications explicitly define newly created data types attribute specifications explicitly define newly created data types
at the beginning of the document, and indicate clearly the data type at the beginning of the document, and indicate clearly the data type
to be used for each attribute. to be used for each attribute.
For example, [RFC3162] utilizes but does not explicitly define the For example, [RFC3162] utilizes but does not explicitly define a type
following data types: which encapsulates an IPv6 address (Section 2.1 and 2.4), and another
type which encapsulates an IPv6 prefix (Section 2.3). The IPv6
IPv6 address 128 bit value, in network byte order. address attributes confusingly are referenced as type "Address" in
the document. This is a similar name as the "address" type defined
IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to in [RFC2865], which was defined to refer solely to IPv4 addresses.
128 bits of value, in network byte order.
The IPv6 address type is used for the NAS-IPv6-Address defined in
[RFC3162] Section 2.1 and the Login-IPv6-Host defined in [RFC3162]
Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3,
and in [RFC4818] Section 3.
While the Framed-Interface-Id attribute defined in [RFC3162] Section While the Framed-Interface-Id attribute defined in [RFC3162] Section
2.2 included a value field of 8 octets, the data type was not 2.2 included a value field of 8 octets, the data type was not
explicitly indicated, and therefore there is controversy over whether explicitly indicated, and therefore there is controversy over whether
the format of the data was intended to be an 8 octet String or the format of the data was intended to be an 8 octet String or
whether a special Interface-Id type was intended. whether a special Interface-Id type was intended.
Given that attributes of type "IPv6 address" and "IPv6 prefix" are Given that attributes encapsulating an IPv6 address and an IPv6
already in use, it is RECOMMENDED that RADIUS server implementations prefix are already in use, it is RECOMMENDED that RADIUS server
include support for these additional basic types, in addition to the implementations include support for these as basic types, in addition
types defined in [RFC2865]. Where the intent is to represent a to the types defined in [RFC2865]. Where the intent is to represent
specific IPv6 address, the "IPv6 address" type SHOULD be used. a specific IPv6 address, an "IPv6 address" type SHOULD be used.
Although it is possible to use the "IPv6 Prefix" type with a prefix Although it is possible to use an "IPv6 Prefix" type with a prefix
length of 128 to represent an IPv6 address, this usage is NOT length of 128 to represent an IPv6 address, this usage is NOT
RECOMMENDED. Implementations supporting the Framed-Interface-Id RECOMMENDED. Implementations supporting the Framed-Interface-Id
attribute may select a data type of their choosing (most likely an 8 attribute may select a data type of their choosing (most likely an 8
octet String or a special Interface-Id data type). octet String or a special "Interface Id" data type).
It is worth noting that since RADIUS only supports unsigned integers It is worth noting that since RADIUS only supports unsigned integers
of 32 bits, attributes using signed integer data types or unsigned of 32 bits, attributes using signed integer data types or unsigned
integer types of other sizes will require code changes, and SHOULD be integer types of other sizes will require code changes, and SHOULD be
avoided. avoided.
For [RFC2865] RADIUS VSAs, the length limitation of the String and For [RFC2865] RADIUS VSAs, the length limitation of the String and
Text types is 247 octets instead of 253 octets, due to the additional Text types is 247 octets instead of 253 octets, due to the additional
overhead of the Vendor-Specific Attribute. overhead of the Vendor-Specific Attribute.
skipping to change at page 18, line 34 skipping to change at page 17, line 47
below in this section, the creation of complex types can lead to below in this section, the creation of complex types can lead to
interoperability and deployment issues, so they need to be introduced interoperability and deployment issues, so they need to be introduced
with care. with care.
In general, complex types containing multiple sub-fields can be In general, complex types containing multiple sub-fields can be
supported by concatenating the sub-fields into a String data type supported by concatenating the sub-fields into a String data type
field. However, separating these sub-fields into different field. However, separating these sub-fields into different
attributes, each with its own type and length, would have the attributes, each with its own type and length, would have the
following benefits: following benefits:
* it is easier for the user to enter the data as well-known * it is easier for an administator to enter the data as well-known
types, rather than complex structures; types, rather than complex structures;
* it enables additional error checking by leveraging the * it enables additional error checking by leveraging the
parsing and validation routines for well-known types; parsing and validation routines for well-known types;
* it simplifies implementations by eliminating special-case * it simplifies implementations by eliminating special-case
attribute-specific parsing. attribute-specific parsing.
One of the fundamental goals of the RADIUS protocol design was to One of the fundamental goals of the RADIUS protocol design was to
allow RADIUS servers to be configured to support new attributes allow RADIUS servers to be configured to support new attributes
skipping to change at page 28, line 17 skipping to change at page 28, line 17
The following text provides guidelines for the design of attributes The following text provides guidelines for the design of attributes
used by the RADIUS protocol. Specifications that follow these used by the RADIUS protocol. Specifications that follow these
guidelines are expected to achieve maximum interoperability with guidelines are expected to achieve maximum interoperability with
minimal changes to existing systems. minimal changes to existing systems.
A.1. Types matching the RADIUS data model A.1. Types matching the RADIUS data model
A.1.1. Transport of basic data types A.1.1. Transport of basic data types
Does the data fit within the basic data types described in Section Does the data fit within the basic data types described in Section
2.1, as outlined below? If so, it SHOULD be encapsulated in a 2.1? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
[RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS VSA that uses one of the
VSA that uses one of the existing RADIUS data types: existing RADIUS data types.
* 32-bit unsigned integer, in network byte order.
* Enumerated data types, represented as a 32-bit unsigned integer
with a list of name to value mappings. (e.g. Service-Type)
* IPv4 address in network byte order.
* time as 32 bit unsigned value, in network byte order, and in
seconds since 00:00:00 UTC, January 1, 1970.
* IPv6 address in network byte order.
* Interface-Id (8 octet string in network byte order)
* IPv6 prefix.
* string (i.e., binary data), totalling 253 octets or less in
length. This includes the opaque encapsulation of data
structures defined outside of RADIUS. See also Appendix A.1.3,
below.
* UTF-8 text, totalling 253 octets or less in length.
Note that the length limitations for VSAs of type String and Text are
less than 253 octets, due to the additional overhead of the Vendor-
Specific format.
The following data also qualifies as "basic data types":
* Attributes grouped into a logical container, using the
[RFC2868] tagging mechanism. This approach is NOT
RECOMMENDED (see Section 3.2.2), but is permissible where
the alternatives are worse.
* Attributes requiring the transport of more than 247 octets of
Text or String data. This includes the opaque encapsulation
of data structures defined outside of RADIUS. See also Section
A.1.3, below.
Nested groups or attributes do not qualify as "basic data types", and
SHOULD NOT be used.
A.1.2. Transport of Authentication and Security Data A.1.2. Transport of Authentication and Security Data
Does the data provide authentication and/or security capabilities for Does the data provide authentication and/or security capabilities for
the RADIUS protocol, as outlined below? If so, use of a complex data the RADIUS protocol, as outlined below? If so, use of a complex data
type is acceptable, under the following circumstances: type is acceptable, under the following circumstances:
* Complex data types that carry authentication methods which * Complex data types that carry authentication methods which
RADIUS servers are expected to parse and verify as part of RADIUS servers are expected to parse and verify as part of
an authentication process. an authentication process.
skipping to change at page 32, line 45 skipping to change at page 32, line 4
to be provided, then an Access-Accept with appropriate to be provided, then an Access-Accept with appropriate
authorizations can be used instead. authorizations can be used instead.
* Lack of user authentication or authorization restrictions. * Lack of user authentication or authorization restrictions.
In an authorization check, where there is no demonstration of a In an authorization check, where there is no demonstration of a
live user, confidential data cannot be returned. Where there live user, confidential data cannot be returned. Where there
is a link to a previous user authentication, the State attribute is a link to a previous user authentication, the State attribute
SHOULD be present. SHOULD be present.
* Lack of per-packet integrity and authentication. * Lack of per-packet integrity and authentication.
It is expected that documents will support per-packet It is expected that documents will support per-packet
integrity and authentication. integrity and authentication.
* Modification of RADIUS packet sequences. * Modification of RADIUS packet sequences.
In RADIUS, each request is encapsulated in its own packet, and In RADIUS, each request is encapsulated in its own packet, and
elicits a single response that is sent to the requester. Since elicits a single response that is sent to the requester. Since
changes to this paradigm are likely to require major changes to this paradigm are likely to require major
modifications to RADIUS client and server implementations, they modifications to RADIUS client and server implementations, they
SHOULD be avoided if possible. SHOULD be avoided if possible.
For further details, see Section 3.3. For further details, see Section 3.1.
A.5. Allocation of attributes A.5. Allocation of attributes
Does the attribute have a limited scope of applicability, as outlined Does the attribute have a limited scope of applicability, as outlined
below? If so, then the attributes SHOULD be allocated from the below? If so, then the attributes SHOULD be allocated from the
vendor space, rather than requesting allocation from the standard vendor space, rather than requesting allocation from the standard
space. space.
* attributes intended for a vendor to support their own systems, * attributes intended for a vendor to support their own systems,
and not suitable for general usage and not suitable for general usage
skipping to change at page 37, line 16 skipping to change at page 36, line 16
More than one Connect-Info attribute may be present in an More than one Connect-Info attribute may be present in an
Accounting-Request packet to accommodate expected efforts by ITU Accounting-Request packet to accommodate expected efforts by ITU
to have modems report more connection information in a standard to have modems report more connection information in a standard
format that might exceed 252 octets. format that might exceed 252 octets.
This attribute contains no encrypted component, and is it not This attribute contains no encrypted component, and is it not
directly involved in authentication. The individual sub-fields could directly involved in authentication. The individual sub-fields could
therefore have been encapsulated in separate attributes. therefore have been encapsulated in separate attributes.
Since the form of the text string is well defined, there is no However, since the definition refers to potential standardization
benefit in using a text string. Instead, an integer attribute should activity within ITU, the Connect-Info attribute can also be thought
have been assigned for each of the transmit speed and the receive of opaque data whose definition is provided elsewhere. The Connect-
speed. A separate enumerated integer should have been assigned for Info attribute could therefore qualify for an exception as described
the additional information, as was done with the NAS-Port-Type in Section 3.2.3.
attribute.
B.7. Framed-IPv6-Prefix B.7. Framed-IPv6-Prefix
[RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and [RFC3162] Section 2.3 defines the Framed-IPv6-Prefix Attribute and
[RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix [RFC4818] Section 3 reuses this format for the Delegated-IPv6-Prefix
Attribute; these attributes are sent from the RADIUS server to the Attribute; these attributes are sent from the RADIUS server to the
client in an Access-Accept. client in an Access-Accept.
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
skipping to change at page 38, line 50 skipping to change at page 37, line 49
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 | Tag Indic. | String... | Type | Length | Tag Indic. | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Tag Indicator is either the character '1' or '2', which in ASCII The Tag Indicator is either the character '1' or '2', which in ASCII
map to the identical values for Tag Indicator in Egress-VLANID, map to the identical values for Tag Indicator in Egress-VLANID,
above. The complex structure of this attribute is acceptable for above. The complex structure of this attribute is acceptable for
reasons identical to those given for Egress-VLANID. reasons identical to those given for Egress-VLANID.
B.9. Digest-* B.10. Digest-*
[RFC5090] attempts to standardize the functionality provided by an [RFC5090] attempts to standardize the functionality provided by an
expired internet-draft [AAA-SIP] which improperly used two attributes expired internet-draft [AAA-SIP] which improperly used two attributes
from the standard space without being assigned them by IANA. This from the standard space without being assigned them by IANA. This
self-allocation is forbidden, as described above in Section 1.3 and self-allocation is forbidden, as described above in Section 2. In
in Section 2. In addition, the draft uses nested attributes, which addition, the draft uses nested attributes, which are discouraged in
are discouraged in Section 2.1. The updated document uses basic data Section 2.1. The updated document uses basic data types, and
types, and allocates nearly 20 attributes in the process. allocates nearly 20 attributes in the process.
However, the draft has seen wide-spread implementation, where However, the draft has seen wide-spread implementation, where
[RFC5090] has not. While there are a number of factors involved, one [RFC5090] has not. One explanation may be that implementors
factor may be that implementors disagreed with the trade-offs made in disagreed with the trade-offs made in the updated specification. It
the updated specification. It may have been better to simply may have been better to simply document the existing format, and
document the existing format, and request IANA allocation of two request IANA allocation of two attributes. The resulting design
attributes. The resulting design would have used nested attributes, would have used nested attributes, but may have gained more wide-
but may have gained more wide-spread implementation. spread implementation.
It is difficult to know which choice is optimal. Given the
complexity of the protocols and implementations, it is impossible to
define "hard and fast" rules for RADIUS design guidelines.
Acknowledgments Acknowledgments
We would like to acknowledge David Nelson, Bernard Aboba, Emile van We would like to acknowledge David Nelson, Bernard Aboba, Emile van
Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for Bergen, Barney Wolff, Glen Zorn, Avi Lior, and Hannes Tschofenig for
contributions to this document. contributions to this document.
Authors' Addresses Authors' Addresses
Greg Weber Greg Weber
 End of changes. 29 change blocks. 
166 lines changed or deleted 85 lines changed or added

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