draft-ietf-radext-extended-attributes-00.txt   draft-ietf-radext-extended-attributes-01.txt 
Network Working Group Y. Li Network Working Group Y. Li
Internet-Draft A. Lior Internet-Draft A. Lior
Intended status: Standards Track BWS Intended status: Standards Track BWS
Expires: May 13, 2008 G. Zorn Expires: August 24, 2008 G. Zorn
NetCube Aruba Networks
November 10, 2007 February 21, 2008
Extended Remote Authentication Dial In User Service (RADIUS) Attributes Extended Remote Authentication Dial In User Service (RADIUS) Attributes
draft-ietf-radext-extended-attributes-00.txt draft-ietf-radext-extended-attributes-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 May 13, 2008. This Internet-Draft will expire on August 24, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
In order for the Remote Authentication Dial In User Service (RADIUS) In order for the Remote Authentication Dial In User Service (RADIUS)
protocol to continue to support new applications the RADIUS attribute protocol to continue to support new applications the RADIUS attribute
type space must be extended beyond the current limit of 255 possible type space must be extended beyond the current limit of 255 possible
attribute types while maintaining backwards compatibility with attribute types while maintaining backwards compatibility with the
existing RADIUS implementations. This document defines a mechanism existing protocol. This document defines a mechanism to accomplish
to accomplish that task, along with standard methods to group related that task, along with standard methods to group together related
attributes together and to encode values that don't fit into 253 attributes and to encode values that don't fit into 253 octets.
octets.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4 4. RADIUS Type Extension . . . . . . . . . . . . . . . . . . . . 4
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 13
skipping to change at page 3, line 21 skipping to change at page 3, line 21
Vendor-specific Attributes (VSAs) allow vendors (including Standards Vendor-specific Attributes (VSAs) allow vendors (including Standards
Development Organizations (SDOs)) to define their own Attributes, Development Organizations (SDOs)) to define their own Attributes,
which may not be suitable for general usage; on the other hand, the which may not be suitable for general usage; on the other hand, the
attributes that belong to the standard RADIUS space are controlled by attributes that belong to the standard RADIUS space are controlled by
the IETF and are intended to be of general utility. These attributes the IETF and are intended to be of general utility. These attributes
are defined in RFCs and are assigned type codes by the Internet are defined in RFCs and are assigned type codes by the Internet
Assigned Number Authority (IANA)[IANA]. Assigned Number Authority (IANA)[IANA].
The standard RADIUS attribute type code is 8 bits in length; hence The standard RADIUS attribute type code is 8 bits in length; hence
RADIUS is limited to 255 attribute types. Of these 255 attribute RADIUS is limited to 255 attribute types. Of these 255 attribute
types, 101 or so have been assigned. Types 192-223 are reserved for types, 101 or so have been assigned. According to RFC 3575
experimental use; types 224-240 are reserved for implementation- [RFC3575], types 192-223 are reserved for experimental use; types
specific use; and values 241-255 are reserved and should not be used. 224-240 are reserved for implementation-specific use; and values 241-
Therefore, as of this writing there are approximately 90 type codes 255 are reserved and should not be used. Therefore, as of this
that can be allocated to new attributes. writing there are approximately 90 type codes that can be allocated
to new attributes.
RADIUS evolution must not be hindered by the inability to define new RADIUS evolution must not be hindered by the inability to define new
standard RADIUS attributes. This document defines a mechanism to standard RADIUS attributes. This document defines a mechanism to
extend the standard RADIUS Attribute space by defining a new scheme extend the standard RADIUS Attribute space by defining a new scheme
to allocate attribute type codes. In addition, mechanisms are to allocate attribute type codes. In addition, mechanisms are
defined to support both the grouping of related attributes and the defined to support both the grouping of related attributes and the
encoding of attribute values the length of which exceed the current encoding of attribute values the length of which exceed the current
limit of 253 octets. limit of 253 octets.
2. Terminology 2. Terminology
skipping to change at page 4, line 46 skipping to change at page 4, line 46
253 octets. Fragmentation of RADIUS attributes has always been 253 octets. Fragmentation of RADIUS attributes has always been
possible by extending the value into another attribute of the same possible by extending the value into another attribute of the same
type; however, this approach does not always work (for example, if type; however, this approach does not always work (for example, if
more than one instance of an attribute occurs in the same RADIUS more than one instance of an attribute occurs in the same RADIUS
packet). The proposed scheme SHOULD enable the transmission of packet). The proposed scheme SHOULD enable the transmission of
attributes longer than 253 octets. attributes longer than 253 octets.
4. RADIUS Type Extension 4. RADIUS Type Extension
The solution described in this document takes the recommended VSA The solution described in this document takes the recommended VSA
format [RFC2865] as a model for the RADIUS Extended Attributes. format [RFC2865] as a basis for the RADIUS Extended Attributes.
We allocate RADIUS the Vendor-Id of zero (0). In essence we are We allocate RADIUS the Vendor-Id of zero (0). In essence we are
assigning the IETF a Vendor-Id which is what other SDOs have done in assigning the IETF a Vendor-Id which is what other SDOs have done in
registering their own Vendor-Id. registering their own Vendor-Id.
Extended Attributes consist of an attribute header similar to that Extended Attributes consist of an attribute header similar to that
recommended by RFC 2865 [RFC2865] for Vendor Specific Attributes recommended by RFC 2865 [RFC2865] for Vendor Specific Attributes
followed by a non-empty sequence of Type-Length-Value (TLV) triples followed by a non-empty sequence of Type-Length-Value (TLV) triples
(see below). If an Extended Attribute contains more than one TLV (see below). If an Extended Attribute contains more than one TLV
then all of the encapsulated TLVs MUST fit completely within the then all of the encapsulated TLVs MUST fit completely within the
skipping to change at page 5, line 35 skipping to change at page 5, line 35
field. If the one bit More flag is set (1) this indicates that field. If the one bit More flag is set (1) this indicates that
the encapsulated TLV is continued in the following Extended the encapsulated TLV is continued in the following Extended
Attribute; if the More flag is clear (0) then all of the Attribute; if the More flag is clear (0) then all of the
encapsulated TLVs fit into the current Extended Attribute. The encapsulated TLVs fit into the current Extended Attribute. The
More flag MUST NOT be set if the Extended Attribute contains more More flag MUST NOT be set if the Extended Attribute contains more
than one TLV. The Tag field is used to combine sets of related than one TLV. The Tag field is used to combine sets of related
Extended Attributes into simple groups. Extended Attributes into simple groups.
TLVs are encoded as follows: TLVs are encoded as follows:
o The first octet is the Ext-Type field o The first bit is the Standard or 'S' flag. The Standard flag is
set (1) if the TLV is a standard RADIUS attribute (as defined in
RFC 2865, for example), otherwise it is clear (0).
o The second octet is the Ext-Length field, representing of the o The next 2 octets are the Ext-Type field
entire TLV, including the length of the Ext-Type field (1 octet),
the length of the Ext-Length field itself (1 octet) and the length o The next octet is the Ext-Length field, representing of the entire
of the Value field (1 or more octets) TLV, including the length of the Ext-Type field (2 octets), the
length of the Ext-Length field itself (1 octet) and the length of
the Value field (1 or more octets)
o The Value field consists of one or more octets comprising the
actual data.
5. Formal Syntax 5. Formal Syntax
This section describes the encoding scheme used for RADIUS Extended This section describes the encoding scheme used for RADIUS Extended
Attributes. The basis of this encoding is the format recommended for Attributes. The basis of this encoding is the format recommended for
Vendor Specific Attributes in RFC 2865 [RFC2865]. Vendor Specific Attributes in RFC 2865 [RFC2865].
1 2 3 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 (26) | Length | Vendor-Id (0) | | Type (26) | Length | Vendor-Id (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id (0) |M| Tag | Ext-Type | | Vendor-Id (0) |M| Tag | Ext-Type
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ext-Type | Ext-Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type Type
26 for Vendor-Specific 26 for Vendor-Specific
Length Length
>=10 >=10
Vendor ID Vendor ID
skipping to change at page 6, line 49 skipping to change at page 7, line 7
Tag Tag
The Tag field is 7 bits long and MUST be present. It is used to The Tag field is 7 bits long and MUST be present. It is used to
group Extended Attributes. Extended Attributes with the same non- group Extended Attributes. Extended Attributes with the same non-
zero value in the Tag field belong to the same group. A Tag value zero value in the Tag field belong to the same group. A Tag value
of zero (0) indicates that the attribute is not grouped. A Tag of zero (0) indicates that the attribute is not grouped. A Tag
value of all ones (0x7F) is reserved. value of all ones (0x7F) is reserved.
Ext-Type Ext-Type
One (1) octet. Up-to-date values of the Ext-Type field are Two (2) octets. Up-to-date values of the Ext-Type field are
specified in the most recent "Assigned Numbers" [IANA]. Values specified in the most recent "Assigned Numbers" [IANA]. Values
XXXX-YYYY are reserved. XXXX-YYYY are reserved.
Ext-Length Ext-Length
>= 4. The length of the Extended Attribute, including the Ext- >= 4. The length of the Extended Attribute, including the Ext-
Type, Ext-Length and Value fields. Type, Ext-Length and Value fields.
Value Value
skipping to change at page 7, line 23 skipping to change at page 7, line 29
6. Examples 6. Examples
Consider an attribute called Foo of type String. Foo is allocated an Consider an attribute called Foo of type String. Foo is allocated an
Extended-Type by IANA of 10. The following figure shows the encoding Extended-Type by IANA of 10. The following figure shows the encoding
of Foo(0,4) = "Hello": of Foo(0,4) = "Hello":
1 2 3 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 (26) | Length | Vendor-Id | | Type (26) | Length | Vendor-Id
| | (7 + 7 = 14) | (0) | | | (6 + 9 = 15) | (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |M| Tag | Ext-Type | Vendor-Id (cont) |M| Tag | Ext-Type
| (0) |0| (0) | (10) | |0| (0) | (257)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value | | | Ext-Type (cont)| Ext-Length | Value | |
| (2 + 5 = 7) | (H) | (e) | (l) | | (4 + 5 = 9) | (H) | (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | |
| (l) | (o) | | (l) | (l) | (o) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Figure 1
Now consider another instantiation of the Foo Extended Attribute, Now consider another instantiation of the Foo Extended Attribute,
this one with a length of 251 octets. In this case the value is this one with a length of 251 octets. In this case the value is
fragmented over two Extended Attributes. The first 246 octets are fragmented over two Extended Attributes. The first 245 octets are
included in the first fragment which has the More bit set and the included in the first fragment which has the More bit set and the
remaining 5 octets appear in the second attribute. Figure 2 below remaining 6 octets appear in the second attribute. Figure 2 below
illustrates the encoding of the first 7 octets of the first Extended illustrates the encoding of the first 7 octets of the first Extended
Attribute (Foo(0,6) = "Hello W"), while Figure 3 shows how the second Attribute (Foo(0,6) = "Hello W"), while Figure 3 shows how the second
attribute (Foo(246,250) = " end.") is encoded. attribute (Foo(245,250) = "e end.") is encoded.
1 2 3 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 (26) | Length | Vendor-Id | | Type (26) | Length | Vendor-Id
| |(7 + 248 = 255)| (0) | | |(7 + 248 = 255)| (0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |M| Tag | Ext-Type | Vendor-Id (cont) |M| Tag | Ext-Type
| (0) |1| (0) | (10) | |1| (0) | (256)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value | | | Ext-Type (cont)| Ext-Length | Value | |
|(2 + 246 = 248)| (H) | (e) | (l) | |(3 + 245 = 248)| (H) | (e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | |
| (l) | (o) | ( ) | (W) | | (l) | (l) | (o) | ( ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| (W) |
+-+-+-+-+-+-+-+-+
... ...
Figure 2 Figure 2
1 2 3 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 (26) | Length | Vendor-Id | | Type (26) | Length | Vendor-Id |
| | (7 + 7 = 14) | (0) | | | (7 + 9 = 16) | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor-Id |M| Tag | Ext-Type | Vendor-Id |M| Tag | Ext-Type
| (0) |0| (0) | (10) | (0) |0| (0) | (256)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ext-Length | Value | | | Ext-Type (cont)| Ext-Length | Value | |
| (2 + 5 = 7) | ( ) | (e) | (n) | | (3 + 6 = 9) | (e) | ( ) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | |
| (e) | (n) | (d) | (.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
| (d) | (.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Figure 3
The next example illustrates several of the features of Extended The next example illustrates several of the features of Extended
Attributes: Attributes:
o encapsulation of values greater than 253 octets in length o encapsulation of values greater than 253 octets in length
o grouping of related Extended Attributes using tags o grouping of related Extended Attributes using tags
o encapsulation of more than one TLV in a single Extended Attribute o encapsulation of more than one TLV in a single Extended Attribute
Consider the following structure: Consider the following structure:
struct struct
Integer a; Integer a;
String b; String b;
Integer c; Integer c;
endStruct endStruct
skipping to change at page 11, line 41 skipping to change at page 11, line 41
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000. RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
10.2. Informative References 10.2. Informative References
[IANA] Internet Assigned Number Authority, "RADIUS TYPES", [IANA] Internet Assigned Number Authority, "RADIUS TYPES",
August 2007, August 2007,
<http://www.iana.org/assignments/radius-types>. <http://www.iana.org/assignments/radius-types>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote
Authentication Dial In User Service)", RFC 3575,
July 2003.
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
"Diameter Network Access Server Application", RFC 4005, "Diameter Network Access Server Application", RFC 4005,
August 2005. August 2005.
Authors' Addresses Authors' Addresses
Yong Li Yong Li
Bridgewater Systems Corporation Bridgewater Systems Corporation
303 Terry Fox Drive 303 Terry Fox Drive
Suite 100 Suite 100
skipping to change at page 12, line 34 skipping to change at page 12, line 38
303 Terry Fox Drive 303 Terry Fox Drive
Suite 100 Suite 100
Ottawa, Ontario K2K 3J1 Ottawa, Ontario K2K 3J1
Canada Canada
Phone: +1 (613) 591-6655 Phone: +1 (613) 591-6655
Email: avi@bridgewatersystems.com Email: avi@bridgewatersystems.com
URI: http://www.bridgewatersystems.com/ URI: http://www.bridgewatersystems.com/
Glen Zorn Glen Zorn
NetCube Aruba Networks
1310 East Thomas Street 1322 Crossman Avenue
#306 Sunnyvale, CA 94089-1113
Seattle, WA 98102 USA
United States of America
Phone: +1 (206) 377-9035 Email: gwz@arubanetworks.com
Email: glenzorn@comcast.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 35 change blocks. 
65 lines changed or deleted 76 lines changed or added

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