--- 1/draft-ietf-radext-radius-fragmentation-07.txt 2014-10-03 01:14:38.899450853 -0700 +++ 2/draft-ietf-radext-radius-fragmentation-08.txt 2014-10-03 01:14:38.963452458 -0700 @@ -1,24 +1,24 @@ RADIUS EXTensions Working Group A. Perez-Mendez Internet-Draft R. Marin-Lopez Updates: RFC6929 (if approved) F. Pereniguez-Garcia Intended status: Experimental G. Lopez-Millan -Expires: January 5, 2015 University of Murcia +Expires: April 6, 2015 University of Murcia D. Lopez Telefonica I+D A. DeKok Network RADIUS - July 4, 2014 + October 3, 2014 Support of fragmentation of RADIUS packets - draft-ietf-radext-radius-fragmentation-07 + draft-ietf-radext-radius-fragmentation-08 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 January 5, 2015. + This Internet-Draft will expire on April 6, 2015. Copyright Notice Copyright (c) 2014 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 @@ -127,25 +127,27 @@ [RFC6158] recommends three approaches for the transmission of large amount of data within RADIUS. However, they are not applicable to the problem statement of this document for the following reasons: o The first approach does not talk about large amounts of data sent from the NAS to a server. Leveraging EAP (request/challenge) to send the data is not feasible, as EAP already fills packet to PMTU, and not all authentications use EAP. Moreover, as noted for NAS-Filter-Rule ([RFC4849]), this approach does entirely solve the - problem of sending large amounts of data from a server to a NAS. + problem of sending large amounts of data from a server to a NAS, + as many current RADIUS attributes are not permitted in an Access- + Challenge packets. o The second approach is not usable either, as using names rather than values is difficult when the nature of the data to be sent is - highly dynamic (e.g. SAML sentences or NAS-Filter-Rule + highly dynamic (e.g. SAML statement or NAS-Filter-Rule attributes). URLs could be used as a pointer to the location of the actual data, but their use would require them to be (a) dynamically created and modified, (b) securely accessed and (c) accessible from remote systems. Satisfying these constraints would require the modification of several networking systems (e.g. firewalls and web servers). Furthermore, the set up of an additional trust infrastructure (e.g. PKI) would be required to allow secure retrieving of the information from the web server. o PMTU discovery does not solve the problem, as it does not allow to @@ -404,29 +405,32 @@ 4. Fragmentation of packets When the NAS or the AS desires to send a packet that exceeds the size limit, it is split into chunks and sent via multiple client/server exchanges. The exchange is indicated via the Frag-Status attribute, which has value More-Data-Pending for all but the last chunk of the series. The chunks are tied together via the State attribute. The delivery of a large fragmented RADIUS packet with authorization data can happen before or after the end user has been authenticated - by the AS. We can distinguish two phases: + by the AS. We can distinguish two phases, which can be omitted if + there is no authorization data to be sent: - 1. Pre-authorization. In this phase, the NAS can send a large + 1. Pre-authorization. In this phase, the NAS MAY send a large packet with authorization information to the AS before the end - user is authenticated. + user is authenticated. Only the NAS is allowed to send + authorization data during this phase. - 2. Post-authorization. In this phase, the AS can send a large + 2. Post-authorization. In this phase, the AS MAY send a large packet with authorization data to the NAS after the end user has - been authenticated. + been authenticated. Only the AS is allowed to send authorization + data during this phase. The following subsections describe how to perform fragmentation for packets for these two phases, pre-authorization and post- authorization. We give the packet type, along with a RADIUS Identifier, to indicate that requests and responses are connected. We then give a list of attributes. We do not give values for most attributes, as we wish to concentrate on the fragmentation behaviour, rather than packet contents. Attribute values are given for attributes relevant to the fragmentation process. Where "long extended" attributes are used, we indicate the M (More) and T @@ -853,21 +857,21 @@ According to [RFC6929], a Long-Extended-Type provides a payload of 251 octets. Therefore, the SAML assertion described above would result into 60 attributes, requiring of 4 round-trips to be completely transmitted. 7. Handling special attributes 7.1. Proxy-State attribute RADIUS proxies may introduce Proxy-State attributes into any Access- - Request packet they forward. Should they are unable to add this + Request packet they forward. If they are unable to add this information to the packet, they may silently discard forwarding it to its destination, leading to DoS situations. Moreover, any Proxy- State attribute received by a RADIUS server in an Access-Request packet MUST be copied into the reply packet to it. For these reasons, Proxy-State attributes require a special treatment within the packet fragmentation mechanism. When the RADIUS server replies to an Access-Request packet as part of a conversation involving a fragmentation (either a chunk or a request for chunks), it MUST include every Proxy-State attribute received @@ -1289,21 +1293,21 @@ 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 - [RFC2865]: + [RFC6929]: Tag Name Length Meaning ---- ---- ------ ------- TBD1 Frag-Status 7 Signals fragmentation TBD2 Proxy-State-Len 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