--- 1/draft-ietf-radext-datatypes-07.txt 2016-10-18 14:15:55.696460556 -0700 +++ 2/draft-ietf-radext-datatypes-08.txt 2016-10-18 14:15:55.760462135 -0700 @@ -1,17 +1,17 @@ Network Working Group DeKok, Alan INTERNET-DRAFT FreeRADIUS Updates: 2865,3162,6158,6572 Category: Standards Track - -24 August 2016 + +18 October 2016 Data Types in the Remote Authentication Dial-In User Service Protocol (RADIUS) Abstract RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types, and have used them in attribute definitions. This document updates the specifications to @@ -38,21 +38,21 @@ 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 April 24, 2017. + This Internet-Draft will expire on May 18, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info/) in effect on the date of publication of this document. Please review these documents @@ -86,29 +86,29 @@ 3.7. ifid ................................................ 16 3.8. ipv4addr ............................................ 17 3.9. ipv6addr ............................................ 18 3.10. ipv6prefix ......................................... 18 3.11. ipv4prefix ......................................... 20 3.12. integer64 .......................................... 21 3.13. tlv ................................................ 22 3.14. vsa ................................................ 23 3.15. extended ........................................... 24 3.16. long-extended ...................................... 26 - 3.17. evs ................................................ 28 -4. Updated Registries ....................................... 29 - 4.1. Create a Data Type Registry ......................... 29 - 4.2. Updates to the Attribute Type Registry .............. 30 -5. Security Considerations .................................. 35 -6. IANA Considerations ...................................... 36 -7. References ............................................... 36 - 7.1. Normative References ................................ 36 - 7.2. Informative References .............................. 37 + 3.17. evs ................................................ 29 +4. Updated Registries ....................................... 30 + 4.1. Create a Data Type Registry ......................... 30 + 4.2. Updates to the Attribute Type Registry .............. 31 +5. Security Considerations .................................. 36 +6. IANA Considerations ...................................... 37 +7. References ............................................... 37 + 7.1. Normative References ................................ 37 + 7.2. Informative References .............................. 38 1. Introduction RADIUS specifications have historically defined attributes in terms of name, value, and data type. Of these three pieces of information, the name is recorded by IANA in the RADIUS Attribute Type registry, but not otherwise managed or restricted, as discussed in [RFC6929] Section 2.7.1. The value is managed by IANA, and recorded in that registry. The data type is not managed or recorded in the RADIUS Attribute Type registry. Experience has shown that there is a need @@ -254,23 +254,23 @@ These terms are used in preference to the term "String", which was previously used in ambiguous ways. It is RECOMMENDED that future specifications use type-specific names, and the same naming scheme for new types. This use will maintain consistent definitions, and help to avoid ambiguities. 2.1.2. Attribute Definitions using Data Types New RADIUS specifications MUST define attributes using data types from the RADIUS Data Type registry. The specification may, of - course, define a new data type and use it in the same document. The - guidelines given in [RFC6929] MUST be followed when defining a new - data type. + course, define a new data type update the "Data Types" registry, and + use the new data type, all in the same document. The guidelines + given in [RFC6929] MUST be followed when defining a new data type. Attributes can usually be completely described via the Attribute Type value, name, and data type. The use of "ASCII art" is then limited only to the definition of new data types, and for complex data types. Use of the new extended attributes [RFC6929] makes ASCII art even more problematic. An attribute can be allocated from any of the extended spaces, with more than one option for attribute header format. This allocation decision is made after the specification has been accepted for publication. As the allocation affects the format @@ -801,26 +801,26 @@ ... Prefix ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Reserved This field, which is reserved and MUST be present, is always - set to zero. + set to zero. This field is one octet in length. Prefix-Length The length of the prefix, in bits. At least 0 and no larger - than 128. + than 128. This field is one octet in length. Prefix The Prefix field is up to 16 octets in length. Bits outside of the Prefix-Length, if included, MUST be zero. The Prefix field SHOULD NOT contain more octets than necessary to encode the Prefix. 3.11. ipv4prefix @@ -1131,21 +1131,21 @@ Length Three or more octets Format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Extended-Type |M| Reserved | Ext-Data ... + | Extended-Type |M|T| Reserved | Ext-Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Subfields Extended-Type This field is identical to the Extended-Type field defined above in Section 3.15. M (More) @@ -1171,56 +1171,98 @@ contain all fragments of the attribute, and those fragments need to be contiguous in the packet. RADIUS does not support inter-packet fragmentation, which means that fragmenting an attribute across multiple packets is impossible. If a client or server receives an attribute fragment with the "More" field set (1), but for which no subsequent fragment can be found, then the fragmented attribute is considered to be an "invalid attribute", and handled as per [RFC6929] Section 2.8. + T (Truncation) + + This field is one bit in size and is + called "T" for Truncation. It + indicates that the attribute is + intentionally truncated in this + chunk and is to be continued in the + next chunk of the sequence. The + combination of the M flag and the T + flag indicates that the attribute is + fragmented (M flag) but that all the + fragments are not available in this + chunk (T flag). Proxies + implementing [RFC6929] will see + these attributes as invalid (they + will not be able to reconstruct + them), but they will still forward + them, as Section 5.2 of [RFC6929] + indicates that they SHOULD forward + unknown attributes anyway. + + Please see [RFC7499] for further + discussion of the uses of this flag. + Reserved - This field is 7 bits long, and is reserved for future use. - Implementations MUST set it to zero (0) when encoding an - attribute for sending in a packet. The contents SHOULD be - ignored on reception. + This field is 6 bits long, and is + reserved for future use. + Implementations MUST set it to zero + (0) when encoding an attribute for + sending in a packet. The contents + SHOULD be ignored on reception. - Future specifications may define additional meaning for this - field. Implementations therefore MUST NOT treat this field as - invalid if it is non-zero. + Future specifications may define + additional meaning for this field. + Implementations therefore MUST NOT + treat this field as invalid if it is + non-zero. Ext-Data - The contents of this field MUST be a valid data type as defined - in the RADIUS Data Type registry. The Ext-Data field MUST NOT - contain any of the following data types: "concat", "vsa", - "extended", "long-extended", or "evs". + The contents of this field MUST be a + valid data type as defined in the + RADIUS Data Type registry. The Ext- + Data field MUST NOT contain any of + the following data types: "concat", + "vsa", "extended", "long-extended", + or "evs". - The Ext-Data field is one or more octets. + The Ext-Data field is one or more + octets. - Implementations supporting this specification MUST use the - Identifier of "Type.Extended-Type" to determine the - interpretation of the Ext-Data field. + Implementations supporting this + specification MUST use the + Identifier of "Type.Extended-Type" + to determine the interpretation of + the Ext-Data field. - The length of the data MUST be taken as the sum of the lengths - of the fragments (i.e. Ext-Data fields) from which it is - constructed. Any interpretation of the resulting data MUST - occur after the fragments have been reassembled. If the - reassembled data does not match the expected format, each - fragment MUST be treated as an "invalid attribute", and the - reassembled data MUST be discarded. + The length of the data MUST be taken + as the sum of the lengths of the + fragments (i.e. Ext-Data fields) + from which it is constructed. Any + interpretation of the resulting data + MUST occur after the fragments have + been reassembled. If the + reassembled data does not match the + expected format, each fragment MUST + be treated as an "invalid + attribute", and the reassembled data + MUST be discarded. - We note that the maximum size of a fragmented attribute is - limited only by the RADIUS packet length limitation. - Implementations MUST be able to handle the case where one - fragmented attribute completely fills the packet. + We note that the maximum size of a + fragmented attribute is limited only + by the RADIUS packet length + limitation. Implementations MUST be + able to handle the case where one + fragmented attribute completely + fills the packet. 3.17. evs The "evs" data type encodes an "Extended Vendor-Specific" attribute, as given in [RFC6929] Section 2.4. The "evs" data type is used solely to extend the Vendor Specific space. It MAY appear inside of an "extended" or a "long-extended" data type. It MUST NOT appear in the contents of any other data type. Where an implementation determines that an attribute of data type @@ -1281,32 +1322,31 @@ 4. Updated Registries This section defines a new IANA registry for RADIUS data types, and then updates the existing RADIUS Attribute Type registry to use the data types from the new registry. 4.1. Create a Data Type Registry This section defines a new registry located under "RADIUS Types", - called "Data Type". Allocation in this registry requires IETF - Review. The "Registration Procedures" for the Data Type registry are - "Standards Action". + called "Data Type". The "Registration Procedures" for the Data Type + registry are "Standards Action". The Data Type registry contains three columns of data, as follows. Value The number of the data type. The value field is an artifact of the registry, and has no on-the-wire meaning. - Description + Name The name of the data type. The name field is used only for the registry, and has no on-the-wire meaning. Reference The specification where the data type was defined. The initial contents of the registry are as follows. @@ -1537,21 +1577,23 @@ 187,WLAN-Group-Cipher,integer,[RFC7268] 188,WLAN-AKM-Suite,integer,[RFC7268] 189,WLAN-Group-Mgmt-Cipher,integer,[RFC7268] 190,WLAN-RF-Band,integer,[RFC7268] 191,Unassigned,, 192-223,Experimental Use,,[RFC3575] 224-240,Implementation Specific,,[RFC3575] 241,Extended-Attribute-1,extended,[RFC6929] 241.1,Frag-Status,integer,[RFC7499] 241.2,Proxy-State-Length,integer,[RFC7499] - 241.{3-25},Unassigned,, + 241.3,Response-Length,integer,[RFC7930] + 241.4,Original-Packet-Code,integer,[RFC7930] + 241.{5-25},Unassigned,, 241.26,Extended-Vendor-Specific-1,evs,[RFC6929] 241.{27-240},Unassigned,, 241.{241-255},Reserved,,[RFC6929] 242,Extended-Attribute-2,extended,[RFC6929] 242.{1-25},Unassigned,, 242.26,Extended-Vendor-Specific-2,evs,[RFC6929] 242.{27-240},Unassigned,, 242.{241-255},Reserved,,[RFC6929] 243,Extended-Attribute-3,extended,[RFC6929] 243.{1-25},Unassigned,, @@ -1645,20 +1687,24 @@ (EAP) Application", RFC 4072, February 2013. [RFC6158] DeKok, A., and Weber, G., "RADIUS Design Guidelines", RFC 6158, March 2011. [RFC6572] Xia, F., et al, "RADIUS Support for Proxy Mobile IPv6", RFC 6572, June 2012. +[RFC7499] + Perez-Mendez, A. Ed., et al, "Support of Fragmentation of RADIUS + Packets", RFC 7499, April 2015. + 7.2. Informative References [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., et al, "RADIUS Extensions", RFC 2869, June 2000.