--- 1/draft-ietf-radext-radius-fragmentation-10.txt 2015-01-20 04:16:49.439413879 -0800 +++ 2/draft-ietf-radext-radius-fragmentation-11.txt 2015-01-20 04:16:49.531416122 -0800 @@ -1,24 +1,24 @@ RADIUS EXTensions Working Group A. Perez-Mendez Internet-Draft R. Marin-Lopez Updates: 2865, 6158, 6929 F. Pereniguez-Garcia (if approved) G. Lopez-Millan Intended status: Experimental University of Murcia -Expires: July 13, 2015 D. Lopez +Expires: July 24, 2015 D. Lopez Telefonica I+D A. DeKok Network RADIUS - January 9, 2015 + January 20, 2015 Support of fragmentation of RADIUS packets - draft-ietf-radext-radius-fragmentation-10 + draft-ietf-radext-radius-fragmentation-11 Abstract The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on July 13, 2015. + This Internet-Draft will expire on July 24, 2015. Copyright Notice Copyright (c) 2015 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 @@ -71,21 +71,21 @@ 7. Allowed large packet size . . . . . . . . . . . . . . . . . . 21 8. Handling special attributes . . . . . . . . . . . . . . . . . 22 8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 22 8.2. State attribute . . . . . . . . . . . . . . . . . . . . . 23 8.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 24 8.4. Rebuilding the original large packet . . . . . . . . . . . 24 9. New flag T field for the Long Extended Type attribute definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. New attribute definition . . . . . . . . . . . . . . . . . . . 25 10.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 25 - 10.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 26 + 10.2. Proxy-State-Length attribute . . . . . . . . . . . . . . . 26 10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27 11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27 11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 27 11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28 12. General considerations . . . . . . . . . . . . . . . . . . . . 29 12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30 12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30 12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 @@ -286,25 +286,25 @@ typically composed of many small updates. That is, there is no demonstrated need to send indivisible blocks of more than 4 kilo- octets of data. The need to send large amounts of data per user session often originates from the need for flow-based accounting. In this use-case, the RADIUS Client may send accounting data for many thousands of flows, where all those flows are tied to one user session. The existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section 5.11 has been proven to work here. Similarly, there is no need to fragment Change of Authorization (CoA) - [RFC5176] packets. Instead, the CoA client MUST send a CoA-Request - packet containing session identification attributes, along with - Service-Type = Additional-Authorization, and a State attribute. - Implementations not supporting fragmentation will respond with a CoA- - NAK, and an Error-Cause of Unsupported-Service. + [RFC5176] packets. Instead, according to [RFC5176] the CoA client + will send a CoA-Request packet containing session identification + attributes, along with Service-Type = Additional-Authorization, and a + State attribute. Implementations not supporting fragmentation will + respond with a CoA-NAK, and an Error-Cause of Unsupported-Service. The above requirement does not assume that the CoA client and the RADIUS Server are co-located. They may, in fact be run on separate parts of the infrastructure, or even by separate administrators. There is, however, a requirement that the two communicate. We can see that the CoA client needs to send session identification attributes in order to send CoA packets. These attributes cannot be known a priori by the CoA client, and can only come from the RADIUS Server. Therefore, even when the two systems are not co-located, they must be able to communicate in order to operate in unison. The @@ -312,65 +312,65 @@ users authorization parameters, which is a security disaster. This specification does not allow for fragmentation of CoA packets. Allowing for fragmented CoA packets would involve changing multiple parts of the RADIUS protocol, with the corresponding possibility for implementation issues, mistakes, etc. Where CoA clients (i.e. RADIUS Servers) need to send large amounts of authorization data to a CoA server (i.e. RADIUS Client), they need only send a minimal CoA-Request packet, containing Service-Type - of Authorize-Only, as per RFC 5176, along with session identification - attributes. This CoA packet serves as a signal to the RADIUS Client - that the users' session requires re-authorization. When the RADIUS - Client re-authorizes the user via Access-Request, the RADIUS Server - can perform fragmentation, and send large amounts of authorization - data to the RADIUS Client. + of Authorize-Only, as per [RFC5176], along with session + identification attributes. This CoA packet serves as a signal to the + RADIUS Client that the users' session requires re-authorization. + When the RADIUS Client re-authorizes the user via Access-Request, the + RADIUS Server can perform fragmentation, and send large amounts of + authorization data to the RADIUS Client. The assumption in the above scenario is that the CoA client and RADIUS Server are co-located, or at least strongly coupled. That is, the path from CoA client to CoA server SHOULD be the exact reverse of the path from RADIUS Client to RADIUS Server. The following diagram will hopefully clarify the roles: - +---------------------+ - | RADIUS | - | Client CoA Server | - +---------------------+ + +----------------+ + | RADIUS CoA | + | Client Server | + +----------------+ | ^ Access-Request | | CoA-Request v | - +---------------------+ - | RADIUS CoA client | - | Server | - +---------------------+ + +----------------+ + | RADIUS CoA | + | Server Client | + +----------------+ Where there is a proxy involved: - +---------------------+ - | RADIUS | - | Client CoA Server | - +---------------------+ + +----------------+ + | RADIUS CoA | + | Client Server | + +----------------+ | ^ Access-Request | | CoA-Request v | - +---------------------+ + +----------------+ | RADIUS CoA | | Proxy Proxy | - +---------------------+ + +----------------+ | ^ Access-Request | | CoA-Request v | - +---------------------+ - | RADIUS CoA client | - | Server | - +---------------------+ + +----------------+ + | RADIUS CoA | + | Server Client | + +----------------+ That is, the RADIUS and CoA subsystems at each hop are strongly connected. Where they are not strongly connected, it will be impossible to use CoA-Request packets to transport large amounts of authorization data. This design is more complicated than allowing for fragmented CoA packets. However, the CoA client and the RADIUS Server must communicate even when not using this specification. We believe that standardizing that communication, and using one method for exchange @@ -976,31 +976,31 @@ 1. When a RADIUS Client does not know how much space will be required by intermediate proxies for including their Proxy-State attributes, it SHOULD start using a conservative value (e.g. 1024 octets) as the chunk size. 2. When the RADIUS Server receives a chunk from the RADIUS Client, it can calculate the total size of the Proxy-State attributes that have been introduced by intermediary proxies along the path. This information MUST be returned to the RADIUS Client in the next reply packet, encoded into a new attribute called Proxy- - State-Len. The RADIUS Server MAY artificially increase this + State-Length. The RADIUS Server MAY artificially increase this quantity in order to handle with situations where proxies behave inconsistently (e.g. they generate Proxy-State attributes with a different size for each packet), or for situations where intermediary proxies remove Proxy-State attributes generated by other proxies. Increasing this value would make the RADIUS Client to leave some free space for these situations. 3. The RADIUS Client SHOULD react upon the reception of this attribute by adjusting the maximum size for the next chunk - accordingly. However, as the Proxy-State-Len offers just an + accordingly. However, as the Proxy-State-Length offers just an estimation of the space required by the proxies, the RADIUS Client MAY select a smaller amount in environments known to be problematic. 8.2. State attribute This RADIUS fragmentation mechanism makes use of the State attribute to link all the chunks belonging to the same fragmented packet. However, some considerations are required when the RADIUS Server is fragmenting a packet that already contains a State attribute for @@ -1040,21 +1040,21 @@ MUST NOT be stored in this list, as they have been introduced as part of the fragmentation signalling and hence, they are not part of the original packet. o State (except the one in the last chunk, if present) o Service-Type = Additional-Authorization o Frag-Status - o Proxy-State-Len + o Proxy-State-Length Similarly, the RADIUS Server MUST NOT store the following attributes as part of the original large packet: o State (except the one in the first chunk, if present) o Service-Type = Additional-Authorization o Frag-Status @@ -1085,50 +1085,50 @@ | Type | Length | Extended-Type |M|T| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Updated Long Extended Type attribute format 10. New attribute definition This document proposes the definition of two new extended type - attributes, called Frag-Status and Proxy-State-Len. The format of + attributes, called Frag-Status and Proxy-State-Length. The format of these attributes follows the indications for an Extended Type attribute defined in [RFC6929]. 10.1. Frag-Status attribute This attribute is used for fragmentation signalling, and its meaning depends on the code value transported within it. The following figure represents the format of the Frag-Status attribute. 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 | Extended-Type | Code +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Frag-Status format Type - To be assigned (TBA) + 241 (To be confirmed by IANA) Length 7 Extended-Type - To be assigned (TBA). + TBD1 Code 4 byte. Integer indicating the code. The values defined in this specifications are: 0 - Reserved 1 - Fragmentation-Supported @@ -1136,49 +1136,49 @@ 3 - More-Data-Request This attribute MAY be present in Access-Request, Access-Challenge and Access-Accept packets. It MUST NOT be included in Access-Reject packets. RADIUS Clients supporting this specification MUST include a Frag-Status = Fragmentation-Supported attribute in the first Access- Request sent to the RADIUS Server, in order to indicate they would accept fragmented data from the sever. -10.2. Proxy-State-Len attribute +10.2. Proxy-State-Length attribute This attribute indicates to the RADIUS Client the length of the Proxy-State attributes received by the RADIUS Server. This information is useful to adjust the length of the chunks sent by the - RADIUS Client. The format of this Proxy-State-Len attribute is the - following: + RADIUS Client. The format of this Proxy-State-Length attribute is + the following: 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 | Extended-Type | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Figure 14: Proxy-State-Len format + Figure 14: Proxy-State-Length format Type - To be assigned (TBA) + 241 (To be confirmed by IANA) Length 7 Extended-Type - To be assigned (TBA). + TBD2 Value 4 octets. Total length (in octets) of received Proxy-State attributes (including headers). This attribute MAY be present in Access-Challenge and Access-Accept packets. It MUST NOT be included in Access-Request or Access-Reject packets. @@ -1187,21 +1187,21 @@ The following table shows the different attributes defined in this document related with the kind of RADIUS packets where they can be present. | Kind of packet | +-----+-----+-----+-----+ Attribute Name | Req | Acc | Rej | Cha | ----------------------+-----+-----+-----+-----+ Frag-Status | 0-1 | 0-1 | 0 | 0-1 | ----------------------+-----+-----+-----+-----+ - Proxy-State-Len | 0 | 0-1 | 0 | 0-1 | + Proxy-State-Length | 0 | 0-1 | 0 | 0-1 | ----------------------+-----+-----+-----+-----+ 11. Operation with proxies The fragmentation mechanism defined above is designed to be transparent to legacy proxies, as long as they do not want to modify any fragmented attribute. Nevertheless, updated proxies supporting this specification can even modify fragmented attributes. 11.1. Legacy proxies @@ -1378,52 +1378,52 @@ The authors request that Attribute Types and Attribute Values defined in this document be registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS namespaces as described in the "IANA Considerations" section of [RFC3575], in accordance with BCP 26 [RFC5226]. For RADIUS packets, attributes and registries created by this document IANA is requested to place them at http://www.iana.org/assignments/radius-types. In particular, this document defines two new RADIUS attributes, - entitled "Frag-Status" and "Proxy-State-Len" (see section 9), - assigned values of TBD1 and TBD2 from the Long Extended Space of - [RFC6929]: + entitled "Frag-Status" and "Proxy-State-Length" (see Section 10), + with assigned values of 241.TBD1 and 241.TBD2 from the Short Extended + Space of [RFC6929]: - Tag Name Length Meaning + Type Name Length Meaning ---- ---- ------ ------- - TBD1 Frag-Status 7 Signals fragmentation - TBD2 Proxy-State-Len 7 Indicates the length of the + 241.TBD1 Frag-Status 7 Signals fragmentation + 241.TBD2 Proxy-State-Length 7 Indicates the length of the received Proxy-State attributes The Frag-Status attribute also defines a 8-bit "Code" field, for which the IANA is to create and maintain a new sub-registry entitled "Code values" under the RADIUS "Frag-Status" attribute. Initial values for the RADIUS Frag-Status "Code" registry are given below; future assignments are to be made through "RFC required" [RFC5226]. Assignments consist of a Frag-Status "Code" name and its associated value. Value Frag-Status Code Name Definition ---- ------------------------ ---------- - 0 Reserved See Section 9.1 - 1 Fragmentation-Supported See Section 9.1 - 2 More-Data-Pending See Section 9.1 - 3 More-Data-Request See Section 9.1 + 0 Reserved See Section 10.1 + 1 Fragmentation-Supported See Section 10.1 + 2 More-Data-Pending See Section 10.1 + 3 More-Data-Request See Section 10.1 4-255 Unassigned Additionally, allocation of a new Service-Type value for "Additional- Authorization" is requested. Value Service Type Value Definition ---- ------------------------ ---------- - TBA Additional-Authorization See section 4.1 + TBA Additional-Authorization See Section 5.1 15. Acknowledgements The authors would like to thank the members of the RADEXT working group who have contributed to the development of this specification, either by participating on the discussions on the mailing lists or by sending comments about our RFC. The authors also thank David Cuenca (University of Murcia) for implementing a proof of concept implementation of this RFC that has