draft-ietf-radext-design-09.txt   draft-ietf-radext-design-10.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-09.txt> Individual Contributor <draft-ietf-radext-design-10.txt> Individual Contributor
Expires: April 12, 2010 Expires: April 32, 2010
12 October 2009 4 December 2009
RADIUS Design Guidelines RADIUS Design Guidelines
draft-ietf-radext-design-09 draft-ietf-radext-design-10
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and document may not be modified outside the IETF Standards Process, and
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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).
Table of Contents Table of Contents
1. Introduction ............................................. 4 1. Introduction ............................................. 4
1.1. Terminology ......................................... 4 1.1. Terminology ......................................... 4
1.2. Requirements Language ............................... 4 1.2. Requirements Language ............................... 4
1.3. Applicability ....................................... 5 1.3. Applicability ....................................... 5
2. RADIUS Data Model ........................................ 6 2. RADIUS Data Model ........................................ 6
2.1. Standard Space ...................................... 6 2.1. Standard Space ...................................... 7
2.1.1. Basic Data Types ............................... 6 2.1.1. Basic Data Types Defined in RFC 2865 ........... 7
2.1.2. Tagging Mechanism .............................. 8 2.1.2. Tagging Mechanism .............................. 8
2.1.3. Complex Attribute Usage ........................ 8 2.1.3. Complex Attribute Usage ........................ 9
2.1.4. Complex Attributes and Security ................ 11 2.1.4. Complex Attributes and Security ................ 11
2.1.5. Service definitions and RADIUS ................. 11 2.1.5. Service definitions and RADIUS ................. 12
2.2. Vendor Space ........................................ 12 2.2. Vendor Space ........................................ 13
3. Data Model Issues ........................................ 14 3. Data Model Issues ........................................ 14
3.1. Vendor Space ........................................ 14 3.1. Vendor Space ........................................ 15
3.1.1. Interoperability Considerations ................ 16 3.1.1. Interoperability Considerations ................ 17
3.1.2. Vendor Allocations ............................. 17 3.1.2. Vendor Allocations ............................. 17
3.1.3. SDO Allocations ................................ 17 3.1.3. SDO Allocations ................................ 18
3.1.4. Publication of specifications .................. 18 3.1.4. Publication of specifications .................. 18
3.2. Polymorphic Attributes .............................. 18 3.2. Polymorphic Attributes .............................. 19
3.3. RADIUS Operational Model ............................ 19 3.3. RADIUS Operational Model ............................ 20
4. IANA Considerations ...................................... 22 4. IANA Considerations ...................................... 23
5. Security Considerations .................................. 22 5. Security Considerations .................................. 23
6. References ............................................... 23 6. References ............................................... 24
6.1. Normative References ................................ 23 6.1. Normative References ................................ 24
6.2. Informative References .............................. 23 6.2. Informative References .............................. 24
Appendix A - Design Guidelines ............................... 26 Appendix A - Design Guidelines ............................... 27
A.1. Types matching the RADIUS data model ................. 26 A.1. Types matching the RADIUS data model ................. 27
A.1.1. Transport of simple data ........................ 26 A.1.1. Transport of simple data ........................ 27
A.1.2. Transport of Authentication and Security Data ... 27 A.1.2. Transport of Authentication and Security Data ... 28
A.1.3. Opaque data types ............................... 27 A.1.3. Opaque data types ............................... 28
A.2. Improper Data Types .................................. 27 A.2. Improper Data Types .................................. 28
A.2.1. Simple Data Types ............................... 28 A.2.1. Simple Data Types ............................... 29
A.2.2. Complex Data Types .............................. 29 A.2.2. Complex Data Types .............................. 29
A.3. Vendor-Specific formats .............................. 29 A.3. Vendor-Specific formats .............................. 30
A.4. Changes to the RADIUS Operational Model .............. 29 A.4. Changes to the RADIUS Operational Model .............. 30
A.5. Allocation of attributes ............................. 31 A.5. Allocation of attributes ............................. 32
Appendix B - Complex Attributes .............................. 32 Appendix B - Complex Attributes .............................. 33
B.1. CHAP-Password ........................................ 32 B.1. CHAP-Password ........................................ 33
B.2. CHAP-Challenge ....................................... 32 B.2. CHAP-Challenge ....................................... 33
B.3. Tunnel-Password ...................................... 32 B.3. Tunnel-Password ...................................... 33
B.4. ARAP-Password ........................................ 33 B.4. ARAP-Password ........................................ 34
B.5. ARAP-Features ........................................ 33 B.5. ARAP-Features ........................................ 34
B.6. Connect-Info ......................................... 34 B.6. Connect-Info ......................................... 35
B.7. Framed-IPv6-Prefix ................................... 35 B.7. Framed-IPv6-Prefix ................................... 36
B.8. Egress-VLANID ........................................ 35 B.8. Egress-VLANID ........................................ 36
B.9. Egress-VLAN-Name ..................................... 36 B.9. Egress-VLAN-Name ..................................... 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
put to use. As with "Guidelines for Authors and Reviewers of MIB put to use. As with "Guidelines for Authors and Reviewers of MIB
Documents" [RFC4181], it is expected that this document will be used Documents" [RFC4181], it is expected that this document will be used
by authors to check their document against the guidelines prior to by authors to check their document against the guidelines prior to
requesting review (such as an "Expert Review" described in requesting review (such as an "Expert Review" described in
[RFC3575]). Similarly, it is expected that this document will used [RFC3575]). Similarly, it is expected that this document will used
by reviewers (such as WG participants or the AAA Doctors [DOCTORS]), by reviewers (such as WG participants or the AAA Doctors [DOCTORS]),
resulting in an improvement in the consistency of reviews. resulting in an improvement in the consistency of reviews.
In order to meet these objectives, this document needs to cover not In order to meet these objectives, this document needs to cover not
only the science of attribute design, but also the art. As a result, only the science of attribute design, but also the art. Therefore,
in addition to covering the most frequently encountered issues, this in addition to covering the most frequently encountered issues, this
document attempts to provide some of the considerations motivating document attempts to provide some of the considerations motivating
the guidelines. the guidelines.
In order to characterize current attribute usage, both the basic and In order to characterize current attribute usage, both the basic and
complex data types defined in the existing RADIUS RFCs are reviewed. complex data types defined in the existing RADIUS RFCs are reviewed.
1.1. Terminology 1.1. Terminology
This document uses the following terms: This document uses the following terms:
skipping to change at page 5, line 5 skipping to change at page 5, line 5
RADIUS proxy RADIUS proxy
A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS A RADIUS proxy acts as a RADIUS server to the NAS, and a RADIUS
client to the RADIUS server. client to the RADIUS server.
1.2. Requirements Language 1.2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The uses of "MUST" and "MUST NOT" in this document are limited to (a)
requirements to follow the IETF process for IETF standards, and (b)
quotes from other documents. As a result, the uses of "MUST" and
"MUST NOT" in this document do not prescribe new mandatory behavior
within implementations.
1.3. Applicability 1.3. Applicability
As RADIUS has become more widely accepted as a management protocol, As RADIUS has become more widely accepted as a management protocol,
its usage has become more prevalent, both within the IETF as well as its usage has become more prevalent, both within the IETF as well as
within other SDOs. Given the expanded utilization of RADIUS, it has within other SDOs. Given the expanded utilization of RADIUS, it has
become apparent that requiring SDOs to accomplish all their RADIUS become apparent that requiring SDOs to accomplish all their RADIUS
work within the IETF is inherently inefficient and unscalable. By work within the IETF is inherently inefficient and unscalable. By
articulating guidelines for RADIUS attribute design, this document articulating guidelines for RADIUS attribute design, this document
enables SDOs out of the IETF to design their own RADIUS attributes enables SDOs out of the IETF to design their own RADIUS attributes
within the Vendor-Specific Attribute (VSA) space. within the Vendor-Specific Attribute (VSA) space.
skipping to change at page 6, line 25 skipping to change at page 6, line 31
IETF require "IETF Consensus" for adoption, as noted in [RFC3575] IETF require "IETF Consensus" for adoption, as noted in [RFC3575]
Section 2.1. Section 2.1.
2. RADIUS Data Model 2. RADIUS Data Model
The Remote Authentication Dial In User Service (RADIUS) defined in The Remote Authentication Dial In User Service (RADIUS) defined in
[RFC2865] and [RFC2866] uses elements known as attributes in order to [RFC2865] and [RFC2866] uses elements known as attributes in order to
represent authentication, authorization and accounting data. represent authentication, authorization and accounting data.
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. A handful of basic not define a formal data definition language. The data type of
data types are in common use, and a data type is associated with an RADIUS attributes is not transported on the wire. Rather, the data
attribute when the 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
can determine the data type based on preconfigured entries within a
data dictionary.
Two distinct attribute spaces are defined: the standard space, and a Two distinct attribute spaces are defined: the standard space, and a
Vendor-Specific space. Attributes in the standard space generally Vendor-Specific space. Attributes in the standard space generally
are composed of a type, length, value (TLV) triplet, although complex are composed of a type, length, value (TLV) triplet, although complex
attributes have also been defined. The Vendor-Specific space is attributes have also been defined. The Vendor-Specific space is
encapsulated within a single attribute type (Vendor-Specific encapsulated within a single attribute type (Vendor-Specific
Attribute). The format of this space is defined by individual Attribute). The format of this space is defined by individual
vendors, but the same TLV encoding used by the standard space is vendors, but the same TLV encoding used by the standard space is
recommended in [RFC2865] Section 5.26. The similarity between recommended in [RFC2865] Section 5.26. The similarity between
attribute formats has enabled implementations to leverage common attribute formats has enabled implementations to leverage common
parsing functionality, although in some cases the attributes in the parsing functionality, although in some cases the attributes in the
Vendor-Specific space have begun to diverge from the common format.
2.1. Standard Space 2.1. Standard Space
The following subsections describe common data types and formats The following subsections describe common data types and formats
within the RADIUS standard attribute space. Common exceptions are within the RADIUS standard attribute space. Common exceptions are
identified. identified.
2.1.1. Basic Data Types 2.1.1. Basic Data Types Defined in RFC 2865
The data type of RADIUS attributes is not transported on the wire. [RFC2865] and [RFC2866] utilize data types defined in [RFC2865]
Rather, the data type of a RADIUS attribute is fixed when that Section 5, which states the following:
attribute is defined. Based on the RADIUS attribute type code,
RADIUS clients and servers can determine the data type based on pre-
configured entries within a data dictionary.
[RFC2865] defines the following data types: 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] text 1-253 octets containing UTF-8 encoded 10646 [RFC3629]
characters. Text of length zero (0) MUST NOT be sent; characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead. 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.
IPv4 address 32 bit value, in network byte order.
integer 32 bit unsigned value, in network byte order.
time 32 bit unsigned value, in network byte order.
-- seconds since 00:00:00 UTC, January 1, 1970.
In addition to these data types, follow-on RADIUS specifications string 1-253 octets containing binary data (values 0 through
define attributes using the following additional types: 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 --
seconds since 00:00:00 UTC, January 1, 1970. The
standard Attributes do not use this data type but it is
presented here for possible use in future attributes.
In addition to the data types defined in [RFC2865], subsequent RADIUS
specifications defined attributes using additional basic data types.
These specifications did not explicitly define new data types as was
done in [RFC2865]. They did not consistently indicate the format of
the value field using the same conventions as [RFC2865]. As a
result, the data type is ambiguous in some cases, and may not be
consistent among different implementations.
It is out of the scope of this document to resolve all potential
ambiguities within existing RADIUS specifications. However in order
to prevent future ambiguities, it is recommended that future RADIUS
attribute specifications explicitly define newly created data types
at the beginning of the document, and indicate clearly the data type
to be used for each attribute.
[RFC3162] utilizes but does not explicitly define the following data
types:
IPv6 address 128 bit value, in network byte order. IPv6 address 128 bit value, in network byte order.
IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to IPv6 prefix 8 bits of reserved, 8 bits of prefix length, up to
128 bits of value, in network byte order. 128 bits of value, in network byte order.
integer64 64 bit unsigned value, in network byte order
This type has also been used to represent an IPv6
interface identifier.
Examples of the IPv6 address type include NAS-IPv6-Address defined in Examples of the IPv6 address type include NAS-IPv6-Address defined in
[RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162] [RFC3162] Section 2.1 and Login-IPv6-Host defined in [RFC3162]
Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3, Section 2.4. The IPv6 prefix type is used in [RFC3162] Section 2.3,
and in [RFC4818] Section 3. The integer64 type is used for the ARAP- and in [RFC4818] Section 3.
Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
[RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
length, but denotes it as type String.
Given that attributes of type IPv6 address, IPv6 prefix, and While the Framed-Interface-Id attribute defined in [RFC3162] Section
integer64 are already in use, it is RECOMMENDED that RADIUS server 2.2 included a value field of 8 octets, the data type was not
implementations include support for these additional basic types, in explicitly indicated, and therefore there is controversy over whether
addition to the types defined in [RFC2865]. the format of this attribute was intended to be an 8 octet String or
whether a special Interface-Id type was intended.
Where the intent is to represent a specific IPv6 address, the IPv6 Given that attributes of type "IPv6 address" and "IPv6 prefix" are
address type SHOULD be used. Although it is possible to use the IPv6 already in use, it is RECOMMENDED that RADIUS server implementations
IPv6 Prefix type with a prefix length of 128 to represent an IPv6 include support for these additional basic types, in addition to the
address, this usage is NOT RECOMMENDED. types defined in [RFC2865]. Where the intent is to represent a
specific IPv6 address, the "IPv6 address" type SHOULD be used.
Although it is possible to use the "IPv6 Prefix" type with a prefix
length of 128 to represent an IPv6 address, this usage is NOT
RECOMMENDED. Implementations supporting the Framed-Interface-Id
attribute may select a data type of their choosing (most likely an 8
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 or 64 bits, attributes using signed integer data types or of 32 bits, attributes using signed integer data types or unsigned
unsigned integer types of other sizes will require code changes, and integer types of other sizes will require code changes, and SHOULD be
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.
2.1.2. Tagging Mechanism 2.1.2. Tagging Mechanism
[RFC2868] defines an attribute grouping mechanism based on the use of [RFC2868] defines an attribute grouping mechanism based on the use of
a one octet tag value. Tunnel attributes that refer to the same a one octet tag value. Tunnel attributes that refer to the same
tunnel are grouped together by virtue of using the same tag value. tunnel are grouped together by virtue of using the same tag value.
skipping to change at page 10, line 13 skipping to change at page 10, line 42
typically are not capable of parsing sub-elements, or providing typically are not capable of parsing sub-elements, or providing
sophisticated matching functionality. sophisticated matching functionality.
Given these limitations, the introduction of complex attributes can Given these limitations, the introduction of complex attributes can
require code changes on the RADIUS server which would be unnecessary require code changes on the RADIUS server which would be unnecessary
if basic data types had been used instead. In addition, attribute- if basic data types had been used instead. In addition, attribute-
specific parsing means more complex software to develop and maintain. specific parsing means more complex software to develop and maintain.
More complexity can lead to more error prone implementations, More complexity can lead to more error prone implementations,
interoperability problems, and even security vulnerabilities. These interoperability problems, and even security vulnerabilities. These
issues can increase costs to network administrators as well as issues can increase costs to network administrators as well as
reducing reliability and introducing deployment barriers. As a reducing reliability and introducing deployment barriers. We
result, the introduction of new complex data types within RADIUS therefore RECOMMEND thathte introduction of new complex data types
attribute specifications SHOULD be avoided, except in the case of within RADIUS attribute specifications be avoided. A potential
complex attributes involving authentication or security exception to this recommendation occurs for attributes that
functionality. inherently require code changes on both the client and server. For
example, as described in Appendix B, complex attributes have been
used in situations involving authentication and security attributes
that need to be dynamically computed and verified.
As can be seen in Appendix B, most of the existing complex attributes As can be seen in Appendix B, most of the existing complex attributes
involve authentication or security functionality. Supporting this involve authentication or security functionality. Supporting this
functionality requires code changes on both the RADIUS client and functionality requires code changes on both the RADIUS client and
server, regardless of the attribute format. As a result, in most server, regardless of the attribute format. As a result, in most
cases, the use of complex attributes to represent these methods is cases, the use of complex attributes to represent these methods is
acceptable, and does not create additional interoperability or acceptable, and does not create additional interoperability or
deployment issues. deployment issues.
The only other exception to the recommendation against complex types The only other exception to the recommendation against complex types
skipping to change at page 26, line 16 skipping to change at page 27, line 16
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 simple data A.1.1. Transport of simple data
Does the data fit within the existing RADIUS data model, as outlined Does the data fit within the basic data types described in Section
below? If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS 2.1.1, as outlined below? If so, it SHOULD be encapsulated in a
attribute, or in a [RFC2865] format RADIUS VSA that uses one of the [RFC2865] format RADIUS attribute, or in a [RFC2865] format RADIUS
existing RADIUS data types. VSA that uses one of the existing RADIUS data types.
* 32-bit unsigned integer, in network byte order. * 32-bit unsigned integer, in network byte order.
* Enumerated data types, represented as a 32-bit unsigned integer * Enumerated data types, represented as a 32-bit unsigned integer
with a list of name to value mappings. (e.g., Service-Type) with a list of name to value mappings. (e.g., Service-Type)
* 64-bit unsigned integer, in network byte order. * Interface-Id (8 octet string in network byte order)
* IPv4 address in network byte order. * IPv4 address in network byte order.
* IPv6 address in network byte order. * IPv6 address in network byte order.
* IPv6 prefix. * IPv6 prefix.
* time as 32 bit unsigned value, in network byte order, and in * time as 32 bit unsigned value, in network byte order, and in
seconds since 00:00:00 UTC, January 1, 1970. seconds since 00:00:00 UTC, January 1, 1970.
skipping to change at page 27, line 16 skipping to change at page 28, line 16
* Attributes requiring the transport of more than 247 octets of * Attributes requiring the transport of more than 247 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. See also Section of data structures defined outside of RADIUS. See also Section
A.1.3, below. A.1.3, below.
Nested groups or attributes do not qualify as "simple data types", Nested groups or attributes do not qualify as "simple data types",
and SHOULD NOT be used. 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, as Does the data provide authentication and/or security capabilities for
outlined below? If so, it SHOULD be encapsulated in a [RFC2865] the RADIUS protocol, as outlined below? If so, it SHOULD be
format RADIUS attribute. It SHOULD NOT be encapsulated in a encapsulated in a [RFC2865] format RADIUS attribute. It SHOULD NOT
[RFC2865] format RADIUS VSA. be encapsulated in a [RFC2865] format RADIUS VSA.
* 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.
* Complex data types that carry security information intended * Complex data types that carry security information intended
to increase the security of the RADIUS protocol itself. to increase the security of the RADIUS protocol itself.
Any data type carrying authentication and/or security data that is Any data type carrying authentication and/or security data that is
not meant to be parsed by a RADIUS server is an "opaque data type", not meant to be parsed by a RADIUS server is an "opaque data type",
skipping to change at page 27, line 49 skipping to change at page 28, line 49
The specification of the attribute SHOULD define the encapsulating The specification of the attribute SHOULD define the encapsulating
attribute to be of type String. The specification SHOULD refer to an attribute to be of type String. The specification SHOULD refer to an
external document defining the structure. The specification SHOULD external document defining the structure. The specification SHOULD
NOT define or describe the structure, as discussed above in Section NOT define or describe the structure, as discussed above in Section
2.1.3. 2.1.3.
A.2. Improper Data Types A.2. Improper Data Types
All data types other than the ones described above in Appendix A.1 All data types other than the ones described above in Appendix A.1
SHOULD NOT be used. This section describes in detail a number of and Appendix B SHOULD NOT be used. This section describes in detail
data types that are NOT RECOMMENDED in new RADIUS specifications. a number of data types that are NOT RECOMMENDED in new RADIUS
Where possible, replacement data types are suggested. specifications. Where possible, replacement data types are
suggested.
A.2.1. Simple Data Types A.2.1. Simple Data Types
Does the attribute use any of the following data types? If so, the Does the attribute use any of the following data types? If so, the
data type SHOULD be replaced with the suggested alternatives, or it data type SHOULD be replaced with the suggested alternatives, or it
SHOULD NOT be used at all. SHOULD NOT be used at all.
* Signed integers of any size. * Signed integers of any size.
SHOULD NOT be used. SHOULD be replaced with one or more SHOULD NOT be used. SHOULD be replaced with one or more
unsigned integer attributes. The definition of the attribute unsigned integer attributes. The definition of the attribute
skipping to change at page 28, line 25 skipping to change at page 29, line 26
value of the integer. value of the integer.
* 8 bit unsigned integers. * 8 bit unsigned integers.
SHOULD be replaced with 32-bit unsigned integer. There is SHOULD be replaced with 32-bit unsigned integer. There is
insufficient justification to save three bytes. insufficient justification to save three bytes.
* 16 bit unsigned integers. * 16 bit unsigned integers.
SHOULD be replaced with 32-bit unsigned integer. There is SHOULD be replaced with 32-bit unsigned integer. There is
insufficient justification to save two bytes. insufficient justification to save two bytes.
* Unsigned integers of size other than 32 or 64. * Unsigned integers of size other than 32
SHOULD be replaced by an unsigned integer of 32 or 64 bits. SHOULD be replaced by an unsigned integer of 32 bits.
There is insufficient justification to define a new size of There is insufficient justification to define a new size of
integer. integer.
* Integers of any size in non-network byte order * Integers of any size in non-network byte order
SHOULD be replaced by unsigned integer of 32 or 64 bits, SHOULD be replaced by unsigned integer of 32 bits in network
in network byte order. There is no reason to transport integers There is no reason to transport integers in any format other
in any format other than network byte order. than network byte order.
* Tagged data types as described in [RFC2868].
These data types SHOULD NOT be used in new specifications.
* Complex data structures defined only within RADIUS.
SHOULD NOT be used. This recommendation does not apply to new
attributes for authentication or security, as described below
in Section A.2.2.
* Multi-field text strings. * Multi-field text strings.
Each field SHOULD be encapsulated in a separate attribute. Each field SHOULD be encapsulated in a separate attribute.
* Polymorphic attributes. * Polymorphic attributes.
Multiple attributes, each with a static data type SHOULD be Multiple attributes, each with a static data type SHOULD be
defined instead. defined instead.
* Nested AVPs. * Nested AVPs.
Attributes should be defined in a flat typespace, possibly using Attributes should be defined in a flat typespace.
a 16-bit Vendor type field (see Section 2.3).
A.2.2. Complex Data Types A.2.2. Complex Data Types
Does the attribute: Does the attribute:
* define a complex data type * define a complex data type not described in Appendix B,
* that a RADIUS server and/or client is expected to parse,
* That a RADIUS server and/or client is expected to parse? validate, or create the contents of via a dynamic computation?
i.e. A type that cannot be treated as opaque data (Section A.1.3) i.e. A type that cannot be treated as opaque data (Section A.1.3)
* for purposes other than authentication or security? * involve functionality that could be implemented without code
changes on both the client and server? (i.e. a type that doesn't
require dynamic computation and verification, such as those
performed for authentication or security attributes)
If so, this data type SHOULD be replaced with simpler types, as If so, this data type SHOULD be replaced with simpler types, as
discussed above in Appendix A.2.1. Also see Section 2.1.3 for a discussed above in Appendix A.2.1. Also see Section 2.1.3 for a
discussion of why complex types are problematic. discussion of why complex types are problematic.
A.3. Vendor-Specific formats A.3. Vendor-Specific formats
Does the specification contain Vendor-Specific attributes that match Does the specification contain Vendor-Specific attributes that match
any of the following criteria? If so, the data type should be any of the following criteria? If so, the data type should be
replaced with the suggested alternatives, or should not be used at replaced with the suggested alternatives, or should not be used at
 End of changes. 33 change blocks. 
118 lines changed or deleted 143 lines changed or added

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