Network Working Group G. Weber Internet-Draft Cisco Systems Expires: September 6, 2006 March 5, 2006 Design Guidelines for RADIUS Attributes draft-weber-radius-attr-guidelines-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This memo explores various issues related to the data model used by the Remote Authentication Dial In User Service (RADIUS) protocol. Recommendations are made to facilitate internal alignment and uniformity. Attribute design guidelines are also provided. Weber Expires September 6, 2006 [Page 1] Internet-Draft RADIUS Attribute Guidelines March 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Divergent Data Models . . . . . . . . . . . . . . . . . . 4 3.2. Attribute Space Exhaustion . . . . . . . . . . . . . . . . 5 3.3. Diameter Alignment . . . . . . . . . . . . . . . . . . . . 5 4. Current Data Model . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. General Attribute Format . . . . . . . . . . . . . . . . . 6 4.3. Tagging Mechanism . . . . . . . . . . . . . . . . . . . . 6 4.4. Vendor-Specific Attribute Format . . . . . . . . . . . . . 7 4.5. Value Packing . . . . . . . . . . . . . . . . . . . . . . 7 5. Data Model Features in the Vendor Space . . . . . . . . . . . 8 5.1. Grouping . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Attribute Encryption . . . . . . . . . . . . . . . . . . . 8 5.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 6. Scope and Solution Characteristics . . . . . . . . . . . . . . 9 6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 9 6.1.1. Intermediate Nodes . . . . . . . . . . . . . . . . . . 9 6.1.2. Dictionary-based Implementations . . . . . . . . . . . 9 6.1.3. Unaware Endpoints . . . . . . . . . . . . . . . . . . 9 6.2. Existing Vendor-Specific Attribute Usage . . . . . . . . . 9 6.3. Transport Impact . . . . . . . . . . . . . . . . . . . . . 10 6.4. Non-AAA Applications . . . . . . . . . . . . . . . . . . . 10 6.5. Diameter Compatibility . . . . . . . . . . . . . . . . . . 10 6.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Diameter Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Weber Expires September 6, 2006 [Page 2] Internet-Draft RADIUS Attribute Guidelines March 2006 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction The Remote Authentication Dial In User Service (RADIUS) protocol [RFC2865] [RFC2866] uses an attribute paradigm as the basis for representing authentication, authorization and accounting (AAA) data. RADIUS messages exchanged between client and server contain lists of similarly formatted attributes. Unlike SNMP [RFC1157] [RFC1155], RADIUS does not use a formal data definition language to describe its attributes or attribute formats. A handful of basic data types are provided, and a data type is associated with a particular attribute when that attribute is defined. Two distinct attribute spaces are defined: the standard space, and a vendor specific space. Attributes in the standard space generally are composed of a type, length, value (TLV) triplet. The vendor specific space is encapsulated within a single attribute type (Vendor-Specific Attribute or VSA). The format of this space is defined by individual vendors, but the same TLV encoding used by the standard space is recommended. The similarity between attribute formats has enabled implementations to leverage a common parsing functionality, though attributes in the vendor specific space have begun to diverge in some cases from use of the common formatting. In addition, many new attributes in the vendor specific space are actually not intended to be vendor specific at all, such as those attributes defined by Standards Development Organizations (SDOs) outside the IETF, e.g. the 3rd Generation Partnership Project (3GPP). Perhaps a contributing factor in the SDOs' decision to use the vendor specific space, is that the standard attribute space is limited to approximately 250 unique attributes; of these, only about half remain available for allocation. In the vendor specific space, the number of attributes available is a function of the format of the attribute (the size of the type field). This document analyzes some of the issues around rationalizing the RADIUS attribute data model and recommends extending the model to allow more alignment between the standard and vendor attribute spaces. The extension mechanism, defined in [EXTATTR], is in the form of a new RADIUS attribute which accommodates some of the Weber Expires September 6, 2006 [Page 3] Internet-Draft RADIUS Attribute Guidelines March 2006 features that have evolved over time in the vendor space including attribute grouping and an expanded attribute number space. This document also analyzes the usage of the basic data types defined in [RFC2865] and [RFC2866], together with the ad-hoc extensions to that data model that have been used in VSAs. A proposal is included for additional base data types, as well as the formation of complex or structured data types, in a standard way. This recommendation leads to a more regular, if not formal, data model for all RADIUS attributes. These recommendations are made for both the traditional and the extended RADIUS attribute formats. 3. Motivation Since the closure of the IETF's RADIUS Working Group, the popularity and prevalence of RADIUS usage has continued to grow and is now commonly applied to various access media in addition to dial in access. The large number of vendors and SDOs developing and providing RADIUS-based solutions has led to some technical splintering in the approach to RADIUS attribute design. 3.1. Divergent Data Models In particular, the data model covering the standard RADIUS attributes is much more constrained than the data model for vendor space attributes. Vendors have evolved the data model they use to support new functions like attribute grouping and attribute fragmentation. Multiple methods have been developed to achieve these desirable features. There is no motivation for vendors or SDOs to move generally useful attributes from the vendor space to the more stringent standard space, so the data models continue to diverge. One of RADIUS's design goals was that new attributes should be able to be added without modifying the client or server core protocol parsing code. As attributes continue to take on new formats, this advantage will fade. Many implementations of RADIUS servers use a data dictionary driven parser implementation. Attribute formats that do not follow established conventions often break the ability to add new attributes to servers by adding their definitions to the data dictionary. In addition, more attribute-specific parsing means more complex software to develop and maintain, and more complexity may lead to more error prone implementations. Weber Expires September 6, 2006 [Page 4] Internet-Draft RADIUS Attribute Guidelines March 2006 3.2. Attribute Space Exhaustion Another impending problem is that eventually the standard attribute space may become depleted over time. The type code field for standard attributes is one octet, so a maximum of 255 attributes may be defined; approximately half of which are currently unallocated. 3.3. Diameter Alignment Section 9 of [RFC4005] describes RADIUS/Diameter interactions. While Diameter [RFC3588] has much more functionality than RADIUS [RFC2865], it may facilitate interoperation to align the RADIUS and Diameter data models at least at some basic level. 4. Current Data Model The following subsections describe how RADIUS data are typed and formatted according to the current specification set. Some exceptions to the rules are identified. 4.1. Data Types RADIUS attributes are typed by reference. In other words, the data type of a particular attribute is fixed when that attribute is defined. The data type information is not transported on the wire. The reference to the attribute type allows RADIUS entities to know the data type because typically, each RADIUS entity has access to a dictionary or some other mechanism describing all defined attributes. The RADIUS specifications define these data types: text 1-253 octets containing UTF-8 encoded 10646 [RFC2279] 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 -- 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 The current specifications do not always adhere to specifying a data type from this set. Weber Expires September 6, 2006 [Page 5] Internet-Draft RADIUS Attribute Guidelines March 2006 For example, in the attribute definition for Framed-Interface-Id (from [RFC3162]), the data type is not given; the value is simply defined as an 8 octet value. Likewise in the definition of CHAP-Password (from [RFC2865]), the data type of the CHAP Identifier is not given, only the one octet length. As you can see, in some cases the data are described textually. This is possible because the data types are not sent inside the attributes. They are largely a matter for endpoint interpretation. In fact, an implementation could define additional data types, say for example, for IPv6 address, and use these data types today by matching them to the attribute's textual description. In fact, some RADIUS implementations treat tagged attributes (see section 4.3) as an additional data type. 4.2. General Attribute Format The attribute TLV encoding is summarized in [RFC2865] as: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- However, some standard attributes do not follow this format. The definition of CHAP-Password above demonstrates this inconsistency. Similarly, the ARAP-Password attribute definition (from [RFC2869]), instead of having a single Value field, contains four 4-octet values. In general, these types of multi-valued attributes may treat the concatenation of all the values as a String data type field. However, separating these values into different attributes, each with its own type and length, would enable additional error checking and would simplify implementations by eliminating special case, attribute specific parsing. 4.3. Tagging Mechanism [RFC2868] defines an attribute grouping mechanism based on the use of a one octet tag value. Tunnel attributes that refer to the same tunnel are grouped together by virtue of using the same tag value. This tagging mechanism has some drawbacks. There are a limited number of unique tags (31). The tags are not well suited for use Weber Expires September 6, 2006 [Page 6] Internet-Draft RADIUS Attribute Guidelines March 2006 with arbitrary binary data values because it is not always possible to tell if the first byte after the Length is the tag or the first byte of the untagged value (assuming the tag is optional). When integer values are tagged, the value portion is reduced to three bytes meaning only 24-bit numbers can be represented. The tagging mechanism does not offer an ability to create nested groups of attributes. 4.4. Vendor-Specific Attribute Format [RFC2865] allows each vendor to define its own attribute space under the Vendor-Specific attribute. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- The format of data in the String field of Vendor-Specific attributes is under each vendor's control, but the specification advises that this field SHOULD be encoded as show below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | Vendor type | Vendor length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Multiple sub-attributes MAY be encoded within a single Vendor- Specific attribute, although they do not have to be. Allowing multiple sub-attributes does provide a form of grouping. 4.5. Value Packing Some attributes pack multiple data items into a single attribute value field. For example, the Connect-Info attribute defined in [RFC2869] may contain values like "28800 V42BIS/LAPM" or "52000/31200 V90". Weber Expires September 6, 2006 [Page 7] Internet-Draft RADIUS Attribute Guidelines March 2006 Encoding multiple values within a Text attribute reduces the amount of data validation that can be performed when the attribute is first encountered. This particular attribute is used in Access-Request messages. If authorization decisions are based on connection speed information, it would perhaps be better to validate it separately from the remainder of the Text attribute. 5. Data Model Features in the Vendor Space Vendors, of course, are under no obligation to publish their proprietary usages of RADIUS. Through SDOs, however, we can see some of the RADIUS usages that have developed in the vendor space. 5.1. Grouping Various strategies and justifications for organizing attribute data into groups have proven popular. The most common of these is probably the sub-attribute scheme introduced in the Vendor-Specific format recommendation. Another method is to concatenate multiple values into a single String or Text attribute. Here are some of the reasons given for grouping attributes: o Compactness - As with bit flags or multiply valued attributes, e.g. a list of IP addresses. o Logical Relationship - For attributes which describe multiple aspects of a single entity or which have interdependencies. o Shared Information - As with a group of attributes related to a single timestamp or remote IP address. 5.2. Attribute Encryption Some legal environments restrict particular types of data from being transmitted in clear text. Some vendors have developed means of encrypting particular RADIUS attributes within messages for use in deployments where the operators want to avoid various deployment issues related to IPsec. 5.3. Fragmentation Several different methods are in use to handle attributes which exceed the 253 octet length limit. One vendor has specified use of multiple attributes with an embedded sequence number to transfer MS- CHAP-LM-Enc-PW (as described in [RFC2548]). One SDO uses multiple attributes, requiring them to be consecutive but without embedded sequence info (see Section 13.1.5.2 in [PKT-SP-EM1.5]) to transfer several large attributes. Weber Expires September 6, 2006 [Page 8] Internet-Draft RADIUS Attribute Guidelines March 2006 6. Scope and Solution Characteristics These subsections describe the desirable scope of any recommended changes to make the RADIUS data model more uniform. 6.1. Backwards Compatibility It is imperative that any changes to the data model do not impact functioning deployments. 6.1.1. Intermediate Nodes RADIUS deployments can include complex proxy architectures. Intermediate nodes may be under separate administrative or operational control from the endpoint client and server. In these scenarios it would not be likely that intermediate nodes would make software or configuration changes to support new functionality at the endpoints. Any data model changes should be transparent to intermediate nodes. This means no changes in wire formats outside the value portion of attributes. 6.1.2. Dictionary-based Implementations Support for structured data or attribute groupings would likely impact dictionary-based implementations. Typically, such an implementation would use the attribute type as an index into a single description of the attribute. There is some precedent for requiring software changes to deploy new RADIUS functionality. This happened with the addition of tagged attribute support and the dynamic authorization extensions [RFC3576]. 6.1.3. Unaware Endpoints Any changes must recognize the fact that any combination of client or server might not understand the new functionality. That said, this document will not address the idea of capability negotiation or advertisement. This would seem to be a problem common to other features and should be addressed separately. 6.2. Existing Vendor-Specific Attribute Usage No new, retroactive requirements should be placed on vendors with regard to existing use of Vendor-Specific attributes. However, recommendations may be made for SDOs specifying attributes intended for use by multiple vendors. Weber Expires September 6, 2006 [Page 9] Internet-Draft RADIUS Attribute Guidelines March 2006 6.3. Transport Impact No changes will be made to the RADIUS transport or (related) maximum packet sizes. 6.4. Non-AAA Applications This document is not targeted at non-AAA applications which use RADIUS as a transport such as the Extensible Authentication Protocol (EAP) [RFC3748] [RFC3579]. These applications do not need to conform to the RADIUS data model as the RADIUS client and server are not the real endpoints of such conversations. For AAA applications, however, the RADIUS data model should not be circumvented; RADIUS is not intended as a generalized "carrier protocol". 6.5. Diameter Compatibility Changes to the RADIUS data model should be Diameter-friendly. It is not the intent to reproduce all or even significant Diameter functionality, or to support all Diameter applications via RADIUS. Ensuring that the data models are somewhat aligned, however, will facilitate the work of Translation Agents for common applications (see section 2.8.4 of [RFC3588]). 6.6. Security No new security mechanisms will be provided to protect RADIUS attribute content. Providing such would interfere with backwards compatibility and interoperability with deployed RADIUS implementations and with Diameter interoperability. 7. Guidelines These guidelines apply to all future RADIUS work, including both traditional standard space attributes and attributes which make use of the extension mechanism specified in [EXTATTR]. In general, new attributes SHOULD comply with the attribute design guidelines given in [RFC2865] unless one or more of the following applies: o The standard attribute space for new attributes has been exhausted. o The proposed maximum attribute length exceeds that available for attributes specified by [RFC2865]. o The native data type of the data element is defined by [EXTATTR] but not [RFC2865]. Weber Expires September 6, 2006 [Page 10] Internet-Draft RADIUS Attribute Guidelines March 2006 o Logical grouping is required (as discussed in Section 5.1). In the cases above, it is RECOMMENDED that the extended attribute encoding specified by [EXTATTR] be used. Additionally, it is RECOMMENDED that: 1. The Vendor-Specific Enumeration (VSE) encoding mechanism as proposed by Section 2.2.1 of [RFC2882] SHOULD NOT be used. Instead, vendors should comply with the recommendations of [RFC3575] 2. Per-attribute encryption mechanisms other than specified by RADIUS standards SHOULD NOT be used. 3. The message lengths specified by RADIUS standards MUST NOT be exceeded. 4. Variable attribute content SHOULD NOT be specified. Separate attributes SHOULD be defined instead. 5. SDOs are RECOMMENDED to use the standard attribute space for attributes that are intended to be supported by multiple vendors. 8. Diameter Considerations This document defines guidelines for RADIUS attribute design, but does not specify any new attributes. As such, there are no Diameter considerations other than those already specified by section section 9 of [RFC4005]. See section 3 of [EXTATTR] for the Diameter considerations related to using the extended RADIUS attribute space. 9. IANA Considerations This document does not allocate any new values from IANA registries. 10. Security Considerations This document does not specify any new functionality. The security considerations related to using RADIUS are discussed in [RFC2865] and section 4.2 of [RFC3579]. 11. References Weber Expires September 6, 2006 [Page 11] Internet-Draft RADIUS Attribute Guidelines March 2006 11.1. Normative References [EXTATTR] Wolff, B. and G. Weber, "Extended RADIUS Attributes", draft-wolff-radext-ext-attribute-00 (work in progress), March 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000. [RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000. [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003. [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005. Weber Expires September 6, 2006 [Page 12] Internet-Draft RADIUS Attribute Guidelines March 2006 11.2. Informative References [PKT-SP-EM1.5] CableLabs PacketCable Project, "Event Messages", PacketCable Specifications 1.5, January 2005. [RFC1155] Rose, M. and K. McCloghrie, "Structure and identification of management information for TCP/IP-based internets", STD 16, RFC 1155, May 1990. [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. Appendix A. Acknowledgments Many of the issues discussed in this document are a distillation of email threads on the RADEXT WG list which is archived here: http://ops.ietf.org/lists/radiusext/ Informal discussions with Barney Wolff, Alan DeKok, Dave Nelson, and Emile van Bergen aided immensely in formulating and refining the ideas in this document. Weber Expires September 6, 2006 [Page 13] Internet-Draft RADIUS Attribute Guidelines March 2006 Author's Address Greg Weber Cisco Systems 10850 Murdock Road Knoxville, TN 37932 USA Email: gdweber@cisco.com Weber Expires September 6, 2006 [Page 14] Internet-Draft RADIUS Attribute Guidelines March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Weber Expires September 6, 2006 [Page 15]