--- 1/draft-ietf-radext-radius-fragmentation-09.txt 2015-01-09 01:14:52.166337700 -0800 +++ 2/draft-ietf-radext-radius-fragmentation-10.txt 2015-01-09 01:14:52.238339455 -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: June 13, 2015 D. Lopez +Expires: July 13, 2015 D. Lopez Telefonica I+D A. DeKok Network RADIUS - December 10, 2014 + January 9, 2015 Support of fragmentation of RADIUS packets - draft-ietf-radext-radius-fragmentation-09 + draft-ietf-radext-radius-fragmentation-10 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,152 +33,171 @@ 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 June 13, 2015. + This Internet-Draft will expire on July 13, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 - 2. Status of this document . . . . . . . . . . . . . . . . . . . 5 - 3. Scope of this document . . . . . . . . . . . . . . . . . . . . 6 - 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 - 5. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 11 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 + 2. Status of this document . . . . . . . . . . . . . . . . . . . 6 + 3. Scope of this document . . . . . . . . . . . . . . . . . . . . 7 + 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 12 5.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 12 5.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 17 - 6. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 7. Allowed large packet size . . . . . . . . . . . . . . . . . . 20 - 8. Handling special attributes . . . . . . . . . . . . . . . . . 21 - 8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 21 + 6. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 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 . . . . . . . . . . . . . . . . . . 23 - 8.4. Rebuilding the original large packet . . . . . . . . . . . 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.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27 11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27 11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 27 - 11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 27 - 12. Operational considerations . . . . . . . . . . . . . . . . . . 29 + 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 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 16.2. Informative References . . . . . . . . . . . . . . . . . . 33 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction The RADIUS [RFC2865] protocol carries authentication, authorization, and accounting information between a RADIUS Client and an RADIUS Server. Information is exchanged between them through RADIUS packets. Each RADIUS packet is composed of a header, and zero or more attributes, up to a maximum packet size of 4096 octets. The protocol is a request/response protocol, as described in the operational model ([RFC6158], Section 3.1). - The above packet size limitation mean that peers desiring to send - large amounts of data must fragment it across multiple packets. For - example, RADIUS-EAP [RFC3579] defines how an EAP exchange occurs - across multiple Access-Request / Access-Challenge sequences. No such - exchange is possible for accounting or authorization data. [RFC6158] - Section 3.1 suggests that exchanging large amounts authorization data - is unnecessary in RADIUS. Instead, the data should be referenced by - name. This requirement allows large policies to be pre-provisioned, - and then referenced in an Access-Accept. In some cases, however, the - authorization data sent by the RADIUS Server is large and highly - dynamic. In other cases, the RADIUS Client needs to send large - amounts of authorization data to the RADIUS Server. Both of these - cases are un-met by the requirements in [RFC6158]. As noted in that - document, the practical limit on RADIUS packet sizes is governed by - the Path MTU (PMTU), which may be significantly smaller than 4096 - octets. The combination of the two limitations means that there is a - pressing need for a method to send large amounts of authorization - data between RADIUS Client and Server, with no accompanying solution. + The intention of the above packet size limitation was to avoid as + much as possible UDP fragmentation. Back then, 4096 seemed large + enough for any purpose. Now, new scenarios are emerging that require + the exchange of authorization information exceeding this 4096 limit. + For instance, the Application Bridging for Federated Access Beyond + web (ABFAB) IETF WG defines the transport of Security Assertion + Markup Language (SAML) sentences from the RADIUS server to the RADIUS + client [I-D.ietf-abfab-aaa-saml]. This assertion is likely to be + larger than 4096 octets. + + This means that peers desiring to send large amounts of data must + fragment it across multiple packets. For example, RADIUS-EAP + [RFC3579] defines how an Extensible Authentication Protocol (EAP) + exchange occurs across multiple Access-Request / Access-Challenge + sequences. No such exchange is possible for accounting or + authorization data. [RFC6158] Section 3.1 suggests that exchanging + large amounts authorization data is unnecessary in RADIUS. Instead, + the data should be referenced by name. This requirement allows large + policies to be pre-provisioned, and then referenced in an Access- + Accept. In some cases, however, the authorization data sent by the + RADIUS Server is large and highly dynamic. In other cases, the + RADIUS Client needs to send large amounts of authorization data to + the RADIUS Server. Both of these cases are un-met by the + requirements in [RFC6158]. As noted in that document, the practical + limit on RADIUS packet sizes is governed by the Path MTU (PMTU), + which may be significantly smaller than 4096 octets. The combination + of the two limitations means that there is a pressing need for a + method to send large amounts of authorization data between RADIUS + Client and Server, with no accompanying solution. [RFC6158] section 3.1 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 (utilization of a sequence of packets) does not talk about large amounts of data sent from the RADIUS Client to a RADIUS 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 RADIUS Server to a RADIUS - Client, as many current RADIUS attributes are not permitted in an - Access-Challenge packets. + Rule ([RFC4849]), this approach does not entirely solve the + problem of sending large amounts of data from a RADIUS Server to a + RADIUS Client, as many current RADIUS attributes are not permitted + in an Access-Challenge packets. o The second approach (utilization of names rather than values) 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 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. + Furthermore, the setup of an additional trust infrastructure (e.g. + Public Key Infrastructure - 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 send data larger than the minimum of (PMTU or 4096) octets. This document provides a mechanism to allow RADIUS peers to exchange large amounts of authorization data exceeding the 4096 octet limit, by fragmenting it across several exchanges. The proposed solution does not impose any additional requirements to the RADIUS system administrators (e.g. need to modify firewall rules, set up web servers, configure routers, or modify any application server). It maintains compatibility with intra-packet fragmentation mechanisms (like those defined in [RFC3579] or in [RFC6929]). It is also transparent to existing RADIUS proxies, which do not implement this - specification. The only systems needing to implement the draft are + specification. The only systems needing to implement this RFC are the ones which either generate, or consume the fragmented data being transmitted. Intermediate proxies just pass the packets without changes. Nevertheless, if a proxy supports this specification, it may re-assemble the data in order to either examine and/or modify it. + A different approach to deal with RADIUS packets above the 4096 octet + limit is described in [I-D.ietf-radext-bigger-packets], which + proposes to extend RADIUS over TCP by allowing the length field in + the RADIUS header to take values up to 65535 octets. This provides a + simpler operation, but it has the drawback of requiring every RADIUS + proxy in the path between the RADIUS client and the RADIUS server to + implement the extension as well. + 1.1. Requirements Language 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]. When these words appear in lower case, they have their natural language meaning. 2. Status of this document @@ -225,28 +244,29 @@ The other Standards Track document that requires a minor update is [RFC6158]. It states that "attribute designers SHOULD NOT assume that a RADIUS implementation can successfully process RADIUS packets larger than 4096 octets", something no longer true if this document advances. 3. Scope of this document This specification describes how a RADIUS Client and a RADIUS Server can exchange data exceeding the 4096 octet limit imposed by one - packet. However, the mechanism described in this specification MUST - NOT be used to exchange more than 100K of data. It has not been - designed to substitute for stream-oriented transport protocols, such - as TCP or SCTP. Experience shows that attempts to transport bulk - data across the Internet with UDP will inevitably fail, unless they - re-implement all of the behavior of TCP. The underlying design of - RADIUS lacks the proper retransmission policies or congestion control - mechanisms which would make it a competitor to TCP. + packet. However, the mechanism described in this specification + SHOULD NOT be used to exchange more than 100 kilo-octets of data. + Any more than this may turn RADIUS into a generic transport protocol, + such as TCP or SCTP, which is undesired. Experience shows that + attempts to transport bulk data across the Internet with UDP will + inevitably fail, unless they re-implement all of the behavior of TCP. + The underlying design of RADIUS lacks the proper retransmission + policies or congestion control mechanisms which would make it a + competitor to TCP. Therefore, RADIUS/UDP transport is by design unable to transport bulk data. It is both undesired and impossible to change the protocol at this point in time. This specification is intended to allow the transport of more than 4096 octets of data through existing RADIUS/ UDP proxies. Other solutions such as RADIUS/TCP MUST be used when a "green field" deployment requires the transport of bulk data. Section 7, below, describes with further details the reasoning for this limitation, and recommends administrators to adjust it according @@ -257,27 +277,27 @@ as other exchanges do not require of such a mechanism. In particular, authentication exchanges have already been defined to overcome this limitation (e.g. RADIUS-EAP). Moreover, as they represent the most critical part of a RADIUS conversation, it is preferable to not introduce any modification to their operation that may affect existing equipment. There is no need to fragment accounting packets either. While the accounting process can send large amounts of data, that data is typically composed of many small updates. That is, there is no - demonstrated need to send indivisible blocks of more than 4K 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. + 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. 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 @@ -338,21 +358,21 @@ | Proxy Proxy | +---------------------+ | ^ Access-Request | | CoA-Request v | +---------------------+ | RADIUS CoA client | | Server | +---------------------+ - That is, the RADIUS and COA subsystems at each hop are strongly + 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 of large data is preferred to unspecified communication methods and multiple ways of achieving the same result. If we were to allow @@ -563,21 +582,21 @@ verification that the Access-Request packet contains some kind of authentication attribute (e.g. User-Password, CHAP-Password, State or other future attribute), as required by [RFC2865] (see Section 12.2 for more information on this). Non-compliant RADIUS Servers (i.e. servers not implementing fragmentation) should also see the Service-Type requesting provisioning for an unknown service, and return Access-Reject. Other non-compliant RADIUS Servers may return an Access-Reject, Access- Challenge, or an Access-Accept with a particular Service-Type other - then Additional-Authorization. Compliant RADIUS Client + than Additional-Authorization. Compliant RADIUS Client implementations MUST treat these responses as if they had received Access-Reject instead. Compliant RADIUS Servers who wish to receive all of the chunks will respond with the following packet. The value of the State here is arbitrary, and serves only as a unique token for example purposes. We only note that it MUST be temporally unique to the RADIUS Server. Access-Accept (ID = 23) Frag-Status = More-Data-Request @@ -887,23 +907,23 @@ RADIUS Server, having the potential to allow Denial of Service (DoS) attacks. An attacker could initiate a large number of connections, each of which requests the RADIUS Server to store a large amount of data. This data could cause memory exhaustion on the RADIUS Server, and result in authentic users being denied access. It is worth noting that authentication mechanisms are already designed to avoid exceeding the size limit. Hence, implementations of this specification MUST limit the total amount of data they send and/or receive via this specification. Its - default value SHOULD be 100K. Any more than this may turn RADIUS into - a generic transport protocol, which is undesired. This limit SHOULD - be configurable, so that it can be changed if necessary. + default value SHOULD be 100 kilo-octets. Any more than this may turn + RADIUS into a generic transport protocol, which is undesired. This + limit SHOULD be configurable, so that it can be changed if necessary. Implementations of this specification MUST limit the total number of round trips used during the fragmentation process. Its default value SHOULD be to 25. Any more than this may indicate an implementation error, misconfiguration, or a denial of service (DoS) attack. This limit SHOULD be configurable, so that it can be changed if necessary. For instance, let's imagine the RADIUS Server wants to transport an SAML assertion which is 15000 octets long, to the RADIUS Client. In this hypothetical scenario, we assume there are 3 intermediate @@ -1199,21 +1219,21 @@ Updated proxies can interact with RADIUS Clients and Servers in order to obtain the complete large packet before starting forwarding it. In this way, proxies can manipulate (modify and/or remove) any attribute of the packet, or introduce new attributes, without worrying about crossing the boundaries of the chunk size. Once the manipulated packet is ready, it is sent to the original destination using the fragmentation mechanism (if required). The following example shows how an updated proxy interacts with the RADIUS Client to obtain a large Access-Request packet, modify an attribute - resulting into a even more large packet, and interacts with the + resulting into an even more large packet, and interacts with the RADIUS Server to complete the transmission of the modified packet. +-+-+-+-+-+ +-+-+-+-+-+ | RADIUS | | RADIUS | | Client | | Proxy | +-+-+-+-+-+ +-+-+-+-+-+ | | | Access-Request(1){User-Name,Calling-Station-Id, | | Example-Long-1[M],Example-Long-1[M], | | Example-Long-1[M],Example-Long-1[M], | @@ -1257,34 +1277,34 @@ | | | Access-Challenge(1){User-Name, | | Frag-Status(MDR),State3} | |<---------------------------------------------------| | | | Access-Request(5){User-Name,State3,Example-Long-1} | |--------------------------------------------------->| Figure 16: Updated proxy interacts with RADIUS Server -12. Operational considerations +12. General considerations 12.1. Flag T As described in Section 9, this document modifies the definition of the "Reserved" field of the "Long Extended Type" attribute [RFC6929], by allocating an additional flag "T". The meaning and position of this flag is defined in this document, and nowhere else. This might generate an issue if subsequent specifications want to allocate a new flag as well, as there would be no direct way for them to know which parts of the "Reserved" field have already been defined. An immediate and reasonable solution for this issue would be - declaring that this draft updates [RFC6929]. In this way, [RFC6929] + declaring that this RFC updates [RFC6929]. In this way, [RFC6929] would include an "Updated by" clause that will point readers to this document. Another alternative would be creating an IANA registry for the "Reserved" field. However, the working group thinks that would be overkill, as not such a great number of specifications extending that field are expected. Hence, we have decided to include the "Updates" clause in the document so far. Note that if this experiment does not succeed, the "T" flag allocation would not persist, as it is tightly associated to this document. @@ -1396,24 +1416,24 @@ Value Service Type Value Definition ---- ------------------------ ---------- TBA Additional-Authorization See section 4.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 draft. + sending comments about our RFC. The authors also thank David Cuenca (University of Murcia) for - implementing a proof of concept implementation of this draft that has + implementing a proof of concept implementation of this RFC that has been useful to improve the quality of the specification. This work has been partly funded by the GEANT GN3+ SA5 and CLASSe (http://sec.cs.kent.ac.uk/CLASSe/) projects. 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -1433,26 +1453,37 @@ [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011. [RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013. 16.2. Informative References + [I-D.ietf-abfab-aaa-saml] + Howlett, J. and S. Hartman, "A RADIUS Attribute, Binding, + Profiles, Name Identifier Format, and Confirmation Methods + for SAML", draft-ietf-abfab-aaa-saml-09 (work in + progress), February 2014. + [I-D.ietf-abfab-arch] Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. Schaad, "Application Bridging for Federated Access Beyond Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work in progress), July 2014. + [I-D.ietf-radext-bigger-packets] + Hartman, S., "Larger Packets for RADIUS over TCP", + draft-ietf-radext-bigger-packets-01 (work in progress), + July 2014. + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC4849] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007. [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication