From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7499.txt | 2131 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2131 insertions(+) create mode 100644 doc/rfc/rfc7499.txt (limited to 'doc/rfc/rfc7499.txt') diff --git a/doc/rfc/rfc7499.txt b/doc/rfc/rfc7499.txt new file mode 100644 index 0000000..2c5c3ed --- /dev/null +++ b/doc/rfc/rfc7499.txt @@ -0,0 +1,2131 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Perez-Mendez, Ed. +Request for Comments: 7499 R. Marin-Lopez +Category: Experimental F. Pereniguez-Garcia +ISSN: 2070-1721 G. Lopez-Millan + University of Murcia + D. Lopez + Telefonica I+D + A. DeKok + Network RADIUS + April 2015 + + + Support of Fragmentation of RADIUS Packets + +Abstract + + The Remote Authentication Dial-In User Service (RADIUS) protocol is + limited to a total packet size of 4096 bytes. Provisions exist for + fragmenting large amounts of authentication data across multiple + packets, via Access-Challenge packets. 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 + existing implementations, and they are designed to be invisible to + proxies and "fail-safe" to legacy RADIUS Clients and Servers. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7499. + + + + + + + + +Perez-Mendez, et al. Experimental [Page 1] + +RFC 7499 Fragmentation of RADIUS Packets April 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 + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 2] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Requirements Language ......................................6 + 2. Status of This Document .........................................6 + 3. Scope of This Document ..........................................7 + 4. Overview .......................................................10 + 5. Fragmentation of Packets .......................................13 + 5.1. Pre-Authorization .........................................14 + 5.2. Post-Authorization ........................................18 + 6. Chunk Size .....................................................21 + 7. Allowed Large Packet Size ......................................22 + 8. Handling Special Attributes ....................................23 + 8.1. Proxy-State Attribute .....................................23 + 8.2. State Attribute ...........................................24 + 8.3. Service-Type Attribute ....................................25 + 8.4. Rebuilding the Original Large Packet ......................25 + 9. New T Flag for the Long Extended Type Attribute Definition .....26 + 10. New Attribute Definition ......................................26 + 10.1. Frag-Status Attribute ....................................27 + 10.2. Proxy-State-Length Attribute .............................28 + 10.3. Table of Attributes ......................................29 + 11. Operation with Proxies ........................................29 + 11.1. Legacy Proxies ...........................................29 + 11.2. Updated Proxies ..........................................29 + 12. General Considerations ........................................31 + 12.1. T Flag ...................................................31 + 12.2. Violation of RFC 2865 ....................................32 + 12.3. Proxying Based on User-Name ..............................32 + 12.4. Transport Behavior .......................................33 + 13. Security Considerations .......................................33 + 14. IANA Considerations ...........................................34 + 15. References ....................................................35 + 15.1. Normative References .....................................35 + 15.2. Informative References ...................................35 + Acknowledgements ..................................................37 + Authors' Addresses ................................................37 + + + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 3] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +1. Introduction + + The RADIUS [RFC2865] protocol carries authentication, authorization, + and accounting information between a RADIUS Client and a 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 bytes. The + protocol is a request/response protocol, as described in the + operational model ([RFC6158], Section 3.1). + + The intention of the above packet size limitation was to avoid UDP + fragmentation as much as possible. Back then, a size of 4096 bytes + seemed large enough for any purpose. Now, new scenarios are emerging + that require the exchange of authorization information exceeding this + 4096-byte limit. For instance, the Application Bridging for + Federated Access Beyond web (ABFAB) IETF working group defines the + transport of Security Assertion Markup Language (SAML) statements + from the RADIUS Server to the RADIUS Client [SAML-RADIUS]. This + assertion is likely to be larger than 4096 bytes. + + 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 of 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. Neither of these cases is 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 bytes. 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. + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 4] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + [RFC6158], Section 3.1 recommends three approaches for the + transmission of large amounts 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 packets to PMTU, and + not all authentications use EAP. Moreover, as noted for the + NAS-Filter-Rule attribute ([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 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., a + 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 setup of an additional trust infrastructure + (e.g., Public Key Infrastructure (PKI)) would be required to allow + secure retrieval of the information from the web server. + + o PMTU discovery does not solve the problem, as it does not allow + the sending of data larger than the minimum of (PMTU or 4096) + bytes. + + This document provides a mechanism to allow RADIUS peers to exchange + large amounts of authorization data exceeding the 4096-byte 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 [RFC6929]). It is also + transparent to existing RADIUS proxies, which do not implement this + specification. The only systems needing to implement this RFC are + the ones that 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 reassemble the data in order to examine and/or modify it. + + + + + +Perez-Mendez, et al. Experimental [Page 5] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + A different approach to deal with RADIUS packets above the 4096-byte + limit is described in [RADIUS-Larger-Pkts], which proposes to extend + RADIUS over TCP by allowing the Length field in the RADIUS header to + take values up to 65535 bytes. 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 + + This document is an Experimental RFC. It defines a proposal to allow + the sending and receiving of data exceeding the 4096-byte limit in + RADIUS packets imposed by [RFC2865], without requiring the + modification of intermediary proxies. + + The experiment consists of verifying whether the approach is usable + in a large-scale environment, by observing the uptake, usability, and + operational behavior it shows in large-scale, real-life deployments. + In that sense, so far the main use case for this specification is the + transportation of large SAML statements defined within the ABFAB + architecture [ABFAB-Arch]. Hence, it can be tested wherever an ABFAB + deployment is being piloted. + + Besides, this proposal defines some experimental features that will + need to be tested and verified before the document can be considered + for the Standards Track. The first one of them is the requirement of + updating [RFC2865] in order to relax the sentence defined in + Section 4.1 of that document that states that "An Access-Request MUST + contain either a User-Password or a CHAP-Password or a State." This + specification might generate Access-Request packets without any of + these attributes. Although all known implementations have chosen the + philosophy of "be liberal in what you accept," we need to gain more + operational experience to verify that unmodified proxies do not drop + these types of packets. More details on this aspect can be found in + Section 12.2. + + + + + + + + +Perez-Mendez, et al. Experimental [Page 6] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + Another experimental feature of this specification is that it + requires proxies to base their routing decisions on the value of the + RADIUS User-Name attribute. Our experience is that this is the + common behavior; thus, no issues are expected. However, it needs to + be confirmed after using different implementations of intermediate + proxies. More details on this aspect can be found in Section 12.3. + + Moreover, this document requires two minor updates to Standards Track + documents. First, it modifies the definition of the Reserved field + of the Long Extended Type attribute [RFC6929] by allocating an + additional flag called the T (Truncation) flag. No issues are + expected with this update, although some proxies might drop packets + that do not have the Reserved field set to 0. More details on this + aspect can be found in Section 12.1. + + 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 bytes," something no longer true if this document + advances. + + A proper "Updates" clause will be included for these modifications + when/if the experiment is successful and this document is reissued as + a Standards Track document. + +3. Scope of This Document + + This specification describes how a RADIUS Client and a RADIUS Server + can exchange data exceeding the 4096-byte limit imposed by one + packet. However, the mechanism described in this specification + SHOULD NOT be used to exchange more than 100 kilobytes of data. Any + more than this may turn RADIUS into a generic transport protocol, + such as TCP or the Stream Control Transmission Protocol (SCTP), which + is undesirable. Experience shows that attempts to transport bulk + data across the Internet with UDP will inevitably fail, unless these + transport attempts reimplement all of the behavior of TCP. The + underlying design of RADIUS lacks the proper retransmission policies + or congestion control mechanisms that would make it a competitor + of TCP. + + Therefore, RADIUS/UDP transport is by design unable to transport bulk + data. It is both undesirable and impossible to change the protocol + at this point in time. This specification is intended to allow the + transport of more than 4096 bytes 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. + + + + + +Perez-Mendez, et al. Experimental [Page 7] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + Section 7, below, describes in further detail what is considered to + be a reasonable amount of data and recommends that administrators + adjust limitations on data transfer according to the specific + capabilities of their existing systems in terms of memory and + processing power. + + Moreover, its scope is limited to the exchange of authorization data, + as other exchanges do not require 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 into their operation any modification 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 4 kilobytes + 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, 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 + alternative is for the two systems to have differing views of the + users' authorization parameters; such a scenario would be a security + disaster. + + + + + + + +Perez-Mendez, et al. Experimental [Page 8] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + This specification does not allow for fragmentation of CoA packets. + Allowing for fragmented CoA packets would involve changing multiple + parts of the RADIUS protocol; such changes introduce the risk of + 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 a Service-Type + 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 CoA | + | Client Server | + +----------------+ + | ^ + Access-Request | | CoA-Request + v | + +----------------+ + | RADIUS CoA | + | Server Client | + +----------------+ + + + + + + + + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 9] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + Where there is a proxy involved: + + +----------------+ + | RADIUS CoA | + | Client Server | + +----------------+ + | ^ + Access-Request | | CoA-Request + v | + +----------------+ + | RADIUS CoA | + | Proxy Proxy | + +----------------+ + | ^ + Access-Request | | CoA-Request + v | + +----------------+ + | 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 of + large data are preferred to unspecified communication methods and + multiple ways of achieving the same result. If we were to allow + fragmentation of data over CoA packets, the size and complexity of + this specification would increase significantly. + + The above requirement solves a number of issues. It clearly + separates session identification from authorization. Without this + separation, it is difficult to both identify a session and change its + authorization using the same attribute. It also ensures that the + authorization process is the same for initial authentication and + for CoA. + +4. Overview + + Authorization exchanges can occur either before or after end-user + authentication has been completed. An authorization exchange before + authentication allows a RADIUS Client to provide the RADIUS Server + with information that MAY modify how the authentication process will + + + +Perez-Mendez, et al. Experimental [Page 10] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + be performed (e.g., it may affect the selection of the EAP method). + An authorization exchange after authentication allows the RADIUS + Server to provide the RADIUS Client with information about the end + user, the results of the authentication process, and/or obligations + to be enforced. In this specification, we refer to + "pre-authorization" as the exchange of authorization information + before the end-user authentication has started (from the RADIUS + Client to the RADIUS Server), whereas the term "post-authorization" + is used to refer to an authorization exchange happening after this + authentication process (from the RADIUS Server to the RADIUS Client). + + In this specification, we refer to the "size limit" as the practical + limit on RADIUS packet sizes. This limit is the minimum between + 4096 bytes and the current PMTU. We define below a method that uses + Access-Request and Access-Accept in order to exchange fragmented + data. The RADIUS Client and Server exchange a series of + Access-Request / Access-Accept packets, until such time as all of the + fragmented data has been transported. Each packet contains a + Frag-Status attribute, which lets the other party know if + fragmentation is desired, ongoing, or finished. Each packet may also + contain the fragmented data or may instead be an "ACK" to a previous + fragment from the other party. Each Access-Request contains a + User-Name attribute, allowing the packet to be proxied if necessary + (see Section 11.1). Each Access-Request may also contain a State + attribute, which serves to tie it to a previous Access-Accept. Each + Access-Accept contains a State attribute, for use by the RADIUS + Client in a later Access-Request. Each Access-Accept contains a + Service-Type attribute with the "Additional-Authorization" value. + This indicates that the service being provided is part of a + fragmented exchange and that the Access-Accept should not be + interpreted as providing network access to the end user. + + When a RADIUS Client or RADIUS Server needs to send data that exceeds + the size limit, the mechanism proposed in this document is used. + Instead of encoding one large RADIUS packet, a series of smaller + RADIUS packets of the same type are encoded. Each smaller packet is + called a "chunk" in this specification, in order to distinguish it + from traditional RADIUS packets. The encoding process is a simple + linear walk over the attributes to be encoded. This walk preserves + the order of the attributes of the same type, as required by + [RFC2865]. The number of attributes encoded in a particular chunk + depends on the size limit, the size of each attribute, the number of + proxies between the RADIUS Client and RADIUS Server, and the overhead + for fragmentation-signaling attributes. Specific details are given + in Section 6. A new attribute called Frag-Status (Section 10.1) + signals the fragmentation status. + + + + + +Perez-Mendez, et al. Experimental [Page 11] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + After the first chunk is encoded, it is sent to the other party. The + packet is identified as a chunk via the Frag-Status attribute. The + other party then requests additional chunks, again using the + Frag-Status attribute. This process is repeated until all the + attributes have been sent from one party to the other. When all the + chunks have been received, the original list of attributes is + reconstructed and processed as if it had been received in one packet. + + The reconstruction process is performed by simply appending all of + the chunks together. Unlike IPv4 fragmentation, there is no Fragment + Offset field. The chunks in this specification are explicitly + ordered, as RADIUS is a lock-step protocol, as noted in Section 12.4. + That is, chunk N+1 cannot be sent until all of the chunks up to and + including N have been received and acknowledged. + + When multiple chunks are sent, a special situation may occur for Long + Extended Type attributes as defined in [RFC6929]. The fragmentation + process may split a fragmented attribute across two or more chunks, + which is not permitted by that specification. We address this issue + by using the newly defined T flag in the Reserved field of the Long + Extended Type attribute format (see Section 9 for further details on + this flag). + + This last situation is expected to be the most common occurrence in + chunks. Typically, packet fragmentation will occur as a consequence + of a desire to send one or more large (and therefore fragmented) + attributes. The large attribute will likely be split into two or + more pieces. Where chunking does not split a fragmented attribute, + no special treatment is necessary. + + The setting of the T flag is the only case where the chunking process + affects the content of an attribute. Even then, the Value fields of + all attributes remain unchanged. Any per-packet security attributes, + such as Message-Authenticator, are calculated for each chunk + independently. Neither integrity checks nor security checks are + performed on the "original" packet. + + Each RADIUS packet sent or received as part of the chunking process + MUST be a valid packet, subject to all format and security + requirements. This requirement ensures that a "transparent" proxy + not implementing this specification can receive and send compliant + packets. That is, a proxy that simply forwards packets without + detailed examination or any modification will be able to proxy + "chunks". + + + + + + + +Perez-Mendez, et al. Experimental [Page 12] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +5. Fragmentation of Packets + + When the RADIUS Client or the RADIUS Server 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 RADIUS Server. 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 RADIUS Client MAY send a + large packet with authorization information to the RADIUS Server + before the end user is authenticated. Only the RADIUS Client is + allowed to send authorization data during this phase. + + 2. Post-authorization. In this phase, the RADIUS Server MAY send a + large packet with authorization data to the RADIUS Client after + the end user has been authenticated. Only the RADIUS Server is + allowed to send authorization data during this phase. + + The following subsections describe how to perform fragmentation for + packets for these two phases. 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 + behavior 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 + (Truncation) flags as optional square brackets after the attribute + name. As no "long extended" attributes have yet been defined, we use + example attributes, named as "Example-Long-1", etc. For the sake of + simplicity, the maximum chunk size is established in terms of the + number of attributes (11). + + + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 13] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +5.1. Pre-Authorization + + When the RADIUS Client needs to send a large amount of data to the + RADIUS Server, the data to be sent is split into chunks and sent to + the RADIUS Server via multiple Access-Request / Access-Accept + exchanges. The example below shows this exchange. + + The following is an Access-Request that the RADIUS Client intends to + send to a RADIUS Server. However, due to a combination of issues + (PMTU, large attributes, etc.), the content does not fit into one + Access-Request packet. + + Access-Request + User-Name + NAS-Identifier + Calling-Station-Id + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 + Example-Long-2 [M] + Example-Long-2 [M] + Example-Long-2 + + Figure 1: Desired Access-Request + + The RADIUS Client therefore must send the attributes listed above in + a series of chunks. The first chunk contains eight (8) attributes + from the original Access-Request, and a Frag-Status attribute. Since + the last attribute is "Example-Long-1" with the M flag set, the + chunking process also sets the T flag in that attribute. The + Access-Request is sent with a RADIUS Identifier field having + value 23. The Frag-Status attribute has value More-Data-Pending, to + indicate that the RADIUS Client wishes to send more data in a + subsequent Access-Request. The RADIUS Client also adds a + Service-Type attribute, which indicates that it is part of the + chunking process. The packet is signed with the + Message-Authenticator attribute, completing the maximum number of + attributes (11). + + + + + + + +Perez-Mendez, et al. Experimental [Page 14] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + Access-Request (ID = 23) + User-Name + NAS-Identifier + Calling-Station-Id + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [MT] + Frag-Status = More-Data-Pending + Service-Type = Additional-Authorization + Message-Authenticator + + Figure 2: Access-Request (Chunk 1) + + Compliant RADIUS Servers (i.e., servers implementing fragmentation) + receiving this packet will see the Frag-Status attribute and will + postpone all authorization and authentication handling until all of + the chunks have been received. This postponement also applies to the + 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 or + Access-Challenge, or they may return an Access-Accept with a + particular Service-Type other 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 + Service-Type = Additional-Authorization + State = 0xabc00001 + Message-Authenticator + + Figure 3: Access-Accept (Chunk 1) + + + + + + +Perez-Mendez, et al. Experimental [Page 15] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + The RADIUS Client will see this response and use the RADIUS + Identifier field to associate it with an ongoing chunking session. + Compliant RADIUS Clients will then continue the chunking process. + Non-compliant RADIUS Clients will never see a response such as this, + as they will never send a Frag-Status attribute. The Service-Type + attribute is included in the Access-Accept in order to signal that + the response is part of the chunking process. This packet therefore + does not provision any network service for the end user. + + The RADIUS Client continues the process by sending the next chunk, + which includes an additional six (6) attributes from the original + packet. It again includes the User-Name attribute, so that + non-compliant proxies can process the packet (see Section 11.1). It + sets the Frag-Status attribute to More-Data-Pending, as more data is + pending. It includes a Service-Type, for the reasons described + above. It includes the State attribute from the previous + Access-Accept. It signs the packet with Message-Authenticator, as + there are no authentication attributes in the packet. It uses a new + RADIUS Identifier field. + + Access-Request (ID = 181) + User-Name + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 + Example-Long-2 [M] + Example-Long-2 [MT] + Frag-Status = More-Data-Pending + Service-Type = Additional-Authorization + State = 0xabc000001 + Message-Authenticator + + Figure 4: Access-Request (Chunk 2) + + Compliant RADIUS Servers receiving this packet will see the + Frag-Status attribute and look for a State attribute. Since one + exists and it matches a State sent in an Access-Accept, this packet + is part of a chunking process. The RADIUS Server will associate the + attributes with the previous chunk. Since the Frag-Status attribute + has value More-Data-Request, the RADIUS Server will respond with an + Access-Accept as before. It MUST include a State attribute, with a + value different from the previous Access-Accept. This State MUST + again be globally and temporally unique. + + + + + + + +Perez-Mendez, et al. Experimental [Page 16] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + Access-Accept (ID = 181) + Frag-Status = More-Data-Request + Service-Type = Additional-Authorization + State = 0xdef00002 + Message-Authenticator + + Figure 5: Access-Accept (Chunk 2) + + The RADIUS Client will see this response and use the RADIUS + Identifier field to associate it with an ongoing chunking session. + The RADIUS Client continues the chunking process by sending the next + chunk, with the final attribute(s) from the original packet, and + again includes the original User-Name attribute. The Frag-Status + attribute is not included in the next Access-Request, as no more + chunks are available for sending. The RADIUS Client includes the + State attribute from the previous Access-Accept. It signs the packet + with Message-Authenticator, as there are no authentication attributes + in the packet. It again uses a new RADIUS Identifier field. + + Access-Request (ID = 241) + User-Name + Example-Long-2 + State = 0xdef00002 + Message-Authenticator + + Figure 6: Access-Request (Chunk 3) + + On reception of this last chunk, the RADIUS Server matches it with an + ongoing session via the State attribute and sees that there is no + Frag-Status attribute present. It then processes the received + attributes as if they had been sent in one RADIUS packet. See + Section 8.4 for further details on this process. It generates the + appropriate response, which can be either Access-Accept or + Access-Reject. In this example, we show an Access-Accept. The + RADIUS Server MUST send a State attribute, which allows linking the + received data with the authentication process. + + Access-Accept (ID = 241) + State = 0x98700003 + Message-Authenticator + + Figure 7: Access-Accept (Chunk 3) + + The above example shows in practice how the chunking process works. + We reiterate the implementation and security requirements here. + + + + + + +Perez-Mendez, et al. Experimental [Page 17] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + Each chunk is a valid RADIUS packet (see Section 12.2 for some + considerations about this), and all RADIUS format and security + requirements MUST be followed before any chunking process is applied. + + Every chunk except for the last one from a RADIUS Client MUST include + a Frag-Status attribute, with value More-Data-Pending. The last + chunk MUST NOT contain a Frag-Status attribute. Each chunk except + for the last one from a RADIUS Client MUST include a Service-Type + attribute, with value Additional-Authorization. Each chunk MUST + include a User-Name attribute, which MUST be identical in all chunks. + Each chunk except for the first one from a RADIUS Client MUST include + a State attribute, which MUST be copied from a previous + Access-Accept. + + Each Access-Accept MUST include a State attribute. The value for + this attribute MUST change in every new Access-Accept and MUST be + globally and temporally unique. + +5.2. Post-Authorization + + When the RADIUS Server wants to send a large amount of authorization + data to the RADIUS Client after authentication, the operation is very + similar to the pre-authorization process. The presence of a + Service-Type = Additional-Authorization attribute ensures that a + RADIUS Client not supporting this specification will treat that + unrecognized Service-Type as though an Access-Reject had been + received instead ([RFC2865], Section 5.6). If the original large + Access-Accept packet contained a Service-Type attribute, it will be + included with its original value in the last transmitted chunk, to + avoid confusion with the one used for fragmentation signaling. It is + RECOMMENDED that RADIUS Servers include a State attribute in their + original Access-Accept packets, even if fragmentation is not taking + place, to allow the RADIUS Client to send additional authorization + data in subsequent exchanges. This State attribute would be included + in the last transmitted chunk, to avoid confusion with the ones used + for fragmentation signaling. + + 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 that they would accept + fragmented data from the server. This is not required if the + pre-authorization process was carried out, as it is implicit. + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 18] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + The following is an Access-Accept that the RADIUS Server intends to + send to a RADIUS Client. However, due to a combination of issues + (PMTU, large attributes, etc.), the content does not fit into one + Access-Accept packet. + + Access-Accept + User-Name + EAP-Message + Service-Type = Login + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 + Example-Long-2 [M] + Example-Long-2 [M] + Example-Long-2 + State = 0xcba00003 + + Figure 8: Desired Access-Accept + + The RADIUS Server therefore must send the attributes listed above in + a series of chunks. The first chunk contains seven (7) attributes + from the original Access-Accept, and a Frag-Status attribute. Since + the last attribute is "Example-Long-1" with the M flag set, the + chunking process also sets the T flag in that attribute. The + Access-Accept is sent with a RADIUS Identifier field having value 30, + corresponding to a previous Access-Request not depicted. The + Frag-Status attribute has value More-Data-Pending, to indicate that + the RADIUS Server wishes to send more data in a subsequent + Access-Accept. The RADIUS Server also adds a Service-Type attribute + with value Additional-Authorization, which indicates that it is part + of the chunking process. Note that the original Service-Type is not + included in this chunk. Finally, a State attribute is included to + allow matching subsequent requests with this conversation, and the + packet is signed with the Message-Authenticator attribute, completing + the maximum number of attributes (11). + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 19] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + Access-Accept (ID = 30) + User-Name + EAP-Message + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [MT] + Frag-Status = More-Data-Pending + Service-Type = Additional-Authorization + State = 0xcba00004 + Message-Authenticator + + Figure 9: Access-Accept (Chunk 1) + + Compliant RADIUS Clients receiving this packet will see the + Frag-Status attribute and suspend all authorization handling until + all of the chunks have been received. Non-compliant RADIUS Clients + should also see the Service-Type indicating the provisioning for an + unknown service and will treat it as an Access-Reject. + + RADIUS Clients who wish to receive all of the chunks will respond + with the following packet, where the value of the State attribute is + taken from the received Access-Accept. They will also include the + User-Name attribute so that non-compliant proxies can process the + packet (Section 11.1). + + Access-Request (ID = 131) + User-Name + Frag-Status = More-Data-Request + Service-Type = Additional-Authorization + State = 0xcba00004 + Message-Authenticator + + Figure 10: Access-Request (Chunk 1) + + The RADIUS Server receives this request and uses the State attribute + to associate it with an ongoing chunking session. Compliant RADIUS + Servers will then continue the chunking process. Non-compliant + RADIUS Servers will never see a response such as this, as they will + never send a Frag-Status attribute. + + The RADIUS Server continues the chunking process by sending the next + chunk, with the final attribute(s) from the original packet. The + value of the Identifier field is taken from the received + Access-Request. A Frag-Status attribute is not included in the next + Access-Accept, as no more chunks are available for sending. The + + + + +Perez-Mendez, et al. Experimental [Page 20] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + RADIUS Server includes the original State attribute to allow the + RADIUS Client to send additional authorization data. The original + Service-Type attribute is included as well. + + Access-Accept (ID = 131) + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 [M] + Example-Long-1 + Example-Long-2 [M] + Example-Long-2 [M] + Example-Long-2 + Service-Type = Login + State = 0xfda000003 + Message-Authenticator + + Figure 11: Access-Accept (Chunk 2) + + On reception of this last chunk, the RADIUS Client matches it with an + ongoing session via the Identifier field and sees that there is no + Frag-Status attribute present. It then processes the received + attributes as if they had been sent in one RADIUS packet. See + Section 8.4 for further details on this process. + +6. Chunk Size + + In an ideal scenario, each intermediate chunk would be exactly the + size limit in length. In this way, the number of round trips + required to send a large packet would be optimal. However, this is + not possible for several reasons. + + 1. RADIUS attributes have a variable length and must be included + completely in a chunk. Thus, it is possible that, even if there + is some free space in the chunk, it is not enough to include the + next attribute. This can generate up to 254 bytes of spare space + in every chunk. + + 2. RADIUS fragmentation requires the introduction of some extra + attributes for signaling. Specifically, a Frag-Status attribute + (7 bytes) is included in every chunk of a packet, except the last + one. A RADIUS State attribute (from 3 to 255 bytes) is also + included in most chunks, to allow the RADIUS Server to bind an + Access-Request with a previous Access-Challenge. User-Name + attributes (from 3 to 255 bytes) are included in every chunk the + RADIUS Client sends, as they are required by the proxies to route + the packet to its destination. Together, these attributes can + generate from up to 13 to 517 bytes of signaling data, reducing + the amount of payload information that can be sent in each chunk. + + + +Perez-Mendez, et al. Experimental [Page 21] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + 3. RADIUS packets SHOULD be adjusted to avoid exceeding the network + MTU. Otherwise, IP fragmentation may occur, with undesirable + consequences. Hence, maximum chunk size would be decreased from + 4096 to the actual MTU of the network. + + 4. The inclusion of Proxy-State attributes by intermediary proxies + can decrease the availability of usable space in the chunk. This + is described in further detail in Section 8.1. + +7. Allowed Large Packet Size + + There are no provisions for signaling how much data is to be sent via + the fragmentation process as a whole. It is difficult to define what + is meant by the "length" of any fragmented data. That data can be + multiple attributes and can include RADIUS attribute header fields, + or it can be one or more "large" attributes (more than 256 bytes in + length). Proxies can also filter these attributes, to modify, add, + or delete them and their contents. These proxies act on a "packet by + packet" basis and cannot know what kind of filtering actions they + will take on future packets. As a result, it is impossible to signal + any meaningful value for the total amount of additional data. + + Unauthenticated end users are permitted to trigger the exchange of + large amounts of fragmented data between the RADIUS Client and the + 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 100 kilobytes. Any more than this may turn + RADIUS into a generic transport protocol, which is undesirable. 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 25. Any more than this may indicate an implementation + error, misconfiguration, or DoS attack. This limit SHOULD be + configurable, so that it can be changed if necessary. + + + + + + + + +Perez-Mendez, et al. Experimental [Page 22] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + For instance, let's imagine that the RADIUS Server wants to transport + a SAML assertion that is 15000 bytes long to the RADIUS Client. In + this hypothetical scenario, we assume that there are three + intermediate proxies, each one inserting a Proxy-State attribute of + 20 bytes. Also, we assume that the State attributes generated by the + RADIUS Server have a size of 6 bytes and the User-Name attribute + takes 50 bytes. Therefore, the amount of free space in a chunk for + the transport of the SAML assertion attributes is as follows: + Total (4096 bytes) - RADIUS header (20 bytes) - User-Name (50 bytes) + - Frag-Status (7 bytes) - Service-Type (6 bytes) - State (6 bytes) - + Proxy-State (20 bytes) - Proxy-State (20 bytes) - Proxy-State + (20 bytes) - Message-Authenticator (18 bytes), resulting in a total + of 3929 bytes. This amount of free space allows the transmission of + up to 15 attributes of 255 bytes each. + + According to [RFC6929], a Long-Extended-Type provides a payload of + 251 bytes. Therefore, the SAML assertion described above would + result in 60 attributes, requiring four round trips to be completely + transmitted. + +8. Handling Special Attributes + +8.1. Proxy-State Attribute + + RADIUS proxies may introduce Proxy-State attributes into any + Access-Request packet they forward. If they are unable to add this + information to the packet, they may silently discard it rather than + forward it to its destination; this would lead to DoS situations. + Moreover, any Proxy-State attribute received by a RADIUS Server in an + Access-Request packet MUST be copied into the corresponding reply + packet. For these reasons, Proxy-State attributes require 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 in + the reply packet. This means that the RADIUS Server MUST take into + account the size of these Proxy-State attributes in order to + calculate the size of the next chunk to be sent. + + However, while a RADIUS Server will always know how much space MUST + be left in each reply packet for Proxy-State attributes (as they are + directly included by the RADIUS Server), a RADIUS Client cannot know + this information, as Proxy-State attributes are removed from the + reply packet by their respective proxies before forwarding them back. + Hence, RADIUS Clients need a mechanism to discover the amount of + + + + + +Perez-Mendez, et al. Experimental [Page 23] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + space required by proxies to introduce their Proxy-State attributes. + In the following paragraphs, we describe a new mechanism to perform + such a discovery: + + 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 bytes) 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-Length. The RADIUS Server MAY artificially increase + this quantity in order to handle situations where proxies behave + inconsistently (e.g., they generate Proxy-State attributes with a + different size for each packet) or where intermediary proxies + remove Proxy-State attributes generated by other proxies. + Increasing this value would make the RADIUS Client leave some + free space for these situations. + + 3. The RADIUS Client SHOULD respond to the reception of this + attribute by adjusting the maximum size for the next chunk + 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 + other purposes not related to the fragmentation. If the procedure + described in Section 5 is followed, two different State attributes + could be included in a single chunk. This is something explicitly + forbidden in [RFC2865]. + + A straightforward solution consists of making the RADIUS Server send + the original State attribute in the last chunk of the sequence + (attributes can be reordered as specified in [RFC2865]). As the last + chunk (when generated by the RADIUS Server) does not contain any + State attribute due to the fragmentation mechanism, both situations + described above are avoided. + + + + + +Perez-Mendez, et al. Experimental [Page 24] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + Something similar happens when the RADIUS Client has to send a + fragmented packet that contains a State attribute in it. The RADIUS + Client MUST ensure that this original State is included in the first + chunk sent to the RADIUS Server (as this one never contains any State + attribute due to fragmentation). + +8.3. Service-Type Attribute + + This RADIUS fragmentation mechanism makes use of the Service-Type + attribute to indicate that an Access-Accept packet is not granting + access to the service yet, since an additional authorization exchange + needs to be performed. Similarly to the State attribute, the RADIUS + Server has to send the original Service-Type attribute in the last + Access-Accept of the RADIUS conversation to avoid ambiguity. + +8.4. Rebuilding the Original Large Packet + + The RADIUS Client stores the RADIUS attributes received in each chunk + in a list, in order to be able to rebuild the original large packet + after receiving the last chunk. However, some of these received + attributes MUST NOT be stored in that list, as they have been + introduced as part of the fragmentation signaling and hence 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-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 + + o Proxy-State (except the ones in the last chunk) + + o User-Name (except the one in the first chunk) + + + + + + + +Perez-Mendez, et al. Experimental [Page 25] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +9. New T Flag for the Long Extended Type Attribute Definition + + This document defines a new field in the Long Extended Type attribute + format. 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. + + As a consequence of this addition, the Reserved field is now 6 bits + long (see Section 12.1 for some considerations). The following + figure represents the new attribute 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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-Length. The format of + these attributes follows the indications for an Extended Type + attribute defined in [RFC6929]. + + + + + + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 26] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +10.1. Frag-Status Attribute + + This attribute is used for fragmentation signaling, and its meaning + depends on the code value transported within it. The following + figure represents the format of the Frag-Status 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 | Extended-Type | Code + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Code (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 13: Frag-Status Format + + Type + + 241 + + Length + + 7 + + Extended-Type + + 1 + + Code + + 4 bytes. Integer indicating the code. The values defined in this + specification are: + + 0 - Reserved + + 1 - Fragmentation-Supported + + 2 - More-Data-Pending + + 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 that + they would accept fragmented data from the server. + + + + +Perez-Mendez, et al. Experimental [Page 27] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +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 for adjusting the length of the chunks sent by + the RADIUS Client. The format of this Proxy-State-Length attribute + is as follows: + + 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 | Extended-Type | Value + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Value (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 14: Proxy-State-Length Format + + Type + + 241 + + Length + + 7 + + Extended-Type + + 2 + + Value + + 4 bytes. Total length (in bytes) of received Proxy-State + attributes (including headers). As the RADIUS Length field cannot + take values over 4096 bytes, values of Proxy-State-Length MUST be + less than that maximum length. + + This attribute MAY be present in Access-Challenge and Access-Accept + packets. It MUST NOT be included in Access-Request or Access-Reject + packets. + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 28] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +10.3. Table of Attributes + + The following table shows the different attributes defined in this + document, along with the types of RADIUS packets in which they can be + present. + + | Type of Packet | + +-----+-----+-----+-----+ + Attribute Name | Req | Acc | Rej | Cha | + ----------------------+-----+-----+-----+-----+ + Frag-Status | 0-1 | 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 + + As every chunk is indeed a RADIUS packet, legacy proxies treat them + as they would the rest of the packets, routing them to their + destination. Proxies can introduce Proxy-State attributes into + Access-Request packets, even if they are indeed chunks. This will + not affect how fragmentation is managed. The RADIUS Server will + include all the received Proxy-State attributes in the generated + response, as described in [RFC2865]. Hence, proxies do not + distinguish between a regular RADIUS packet and a chunk. + +11.2. Updated Proxies + + Updated proxies can interact with RADIUS Clients and Servers in order + to obtain the complete large packet before starting to forward 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 example in + Figure 15 shows how an updated proxy interacts with the RADIUS Client + to (1) obtain a large Access-Request packet and (2) modify an + attribute, resulting in an even larger packet. The proxy then + interacts with the RADIUS Server to complete the transmission of the + modified packet, as shown in Figure 16. + + + + +Perez-Mendez, et al. Experimental [Page 29] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + +-+-+-+-+-+ +-+-+-+-+-+ + | 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], | + | Example-Long-1[MT],Frag-Status(MDP)} | + |--------------------------------------------------->| + | | + | Access-Challenge(1){User-Name, | + | Frag-Status(MDR),State1} | + |<---------------------------------------------------| + | | + | Access-Request(2){User-Name,State1, | + | Example-Long-1[M],Example-Long-1[M], | + | Example-Long-1[M],Example-Long-1} | + |--------------------------------------------------->| + + Proxy Modifies Attribute Data, Increasing Its + Size from 9 Fragments to 11 Fragments + + Figure 15: Updated Proxy Interacts with RADIUS Client + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 30] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + +-+-+-+-+-+ +-+-+-+-+-+ + | RADIUS | | RADIUS | + | Proxy | | Server | + +-+-+-+-+-+ +-+-+-+-+-+ + | | + | Access-Request(3){User-Name,Calling-Station-Id, | + | Example-Long-1[M],Example-Long-1[M], | + | Example-Long-1[M],Example-Long-1[M], | + | Example-Long-1[MT],Frag-Status(MDP)} | + |--------------------------------------------------->| + | | + | Access-Challenge(1){User-Name, | + | Frag-Status(MDR),State2} | + |<---------------------------------------------------| + | | + | Access-Request(4){User-Name,State2, | + | Example-Long-1[M],Example-Long-1[M], | + | Example-Long-1[M],Example-Long-1[M], | + | Example-Long-1[MT],Frag-Status(MDP)} | + |--------------------------------------------------->| + | | + | 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. General Considerations + +12.1. T Flag + + 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 called the T flag. The meaning and + position of this flag are defined in this document, and nowhere else. + This might cause 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 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 + + + + + +Perez-Mendez, et al. Experimental [Page 31] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + the Reserved field. However, the RADIUS Extensions (RADEXT) working + group thinks that would be overkill, as a large number of + specifications extending that field are not expected. + + In the end, the proposed solution is that this experimental RFC + should not update RFC 6929. Instead, we rely on the collective mind + of the working group to remember that this T flag is being used as + specified by this Experimental document. If the experiment is + successful, the T flag will be properly assigned. + +12.2. Violation of RFC 2865 + + Section 5.1 indicates that all authorization and authentication + handling will be postponed until all the chunks have been received. + This postponement also applies to the 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]. This checking will therefore + be delayed until the original large packet has been rebuilt, as some + of the chunks may not contain any of them. + + The authors acknowledge that this specification violates the "MUST" + requirement of [RFC2865], Section 4.1 that states that "An + Access-Request MUST contain either a User-Password or a CHAP-Password + or a State." We note that a proxy that enforces that requirement + would be unable to support future RADIUS authentication extensions. + Extensions to the protocol would therefore be impossible to deploy. + All known implementations have chosen the philosophy of "be liberal + in what you accept." That is, they accept traffic that violates the + requirement of [RFC2865], Section 4.1. We therefore expect to see no + operational issues with this specification. After we gain more + operational experience with this specification, it can be reissued as + a Standards Track document and can update [RFC2865]. + +12.3. Proxying Based on User-Name + + This proposal assumes that legacy proxies base their routing + decisions on the value of the User-Name attribute. For this reason, + every packet sent from the RADIUS Client to the RADIUS Server (either + chunks or requests for more chunks) MUST contain a User-Name + attribute. + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 32] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +12.4. Transport Behavior + + This proposal does not modify the way RADIUS interacts with the + underlying transport (UDP). That is, RADIUS keeps following a + lock-step behavior that requires receiving an explicit + acknowledgement for each chunk sent. Hence, bursts of traffic + that could congest links between peers are not an issue. + + Another benefit of the lock-step nature of RADIUS is that there are + no security issues with overlapping fragments. Each chunk simply has + a length, with no Fragment Offset field as with IPv4. The order of + the fragments is determined by the order in which they are received. + There is no ambiguity about the size or placement of each chunk, and + therefore no security issues associated with overlapping chunks. + +13. Security Considerations + + As noted in many earlier specifications ([RFC5080], [RFC6158], etc.), + RADIUS security is problematic. This specification changes nothing + related to the security of the RADIUS protocol. It requires that all + Access-Request packets associated with fragmentation are + authenticated using the existing Message-Authenticator attribute. + This signature prevents forging and replay, to the limits of the + existing security. + + The ability to send bulk data from one party to another creates new + security considerations. RADIUS Clients and Servers may have to + store large amounts of data per session. The amount of this data can + be significant, leading to the potential for resource exhaustion. We + therefore suggest that implementations limit the amount of bulk data + stored per session. The exact method for this limitation is + implementation-specific. Section 7 gives some indications of what + could be reasonable limits. + + The bulk data can often be pushed off to storage methods other than + the memory of the RADIUS implementation. For example, it can be + stored in an external database or in files. This approach mitigates + the resource exhaustion issue, as RADIUS Servers today already store + large amounts of accounting data. + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 33] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +14. IANA Considerations + + The Internet Assigned Numbers Authority (IANA) has registered the + Attribute Types and Attribute Values defined in this document in 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 + has updated + accordingly. + + In particular, this document defines two new RADIUS attributes, + entitled "Frag-Status" (value 241.1) and "Proxy-State-Length" + (value 241.2), which have been allocated from the short extended + space as described in [RFC6929]: + + Type Name Length Meaning + ---- ---- ------ ------- + 241.1 Frag-Status 7 Signals fragmentation + 241.2 Proxy-State-Length 7 Indicates the length of the + received Proxy-State attributes + + The Frag-Status attribute also defines an 8-bit "Code" field, for + which IANA has created and now maintains a new sub-registry entitled + "Code Values for RADIUS Attribute 241.1, Frag-Status". 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 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, IANA has allocated a new Service-Type value for + "Additional-Authorization". + + Value Service Type Value Definition + ---- ------------------------ ---------- + 19 Additional-Authorization See Section 5.1 + + + + + + + + +Perez-Mendez, et al. Experimental [Page 34] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +15. References + +15.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997, + . + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service (RADIUS)", + RFC 2865, June 2000, . + + [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote + Authentication Dial In User Service)", RFC 3575, + July 2003, . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008, . + + [RFC6158] DeKok, A., Ed., 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, . + +15.2. Informative References + + [ABFAB-Arch] + Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J. + Schaad, "Application Bridging for Federated Access Beyond + Web (ABFAB) Architecture", Work in Progress, + draft-ietf-abfab-arch-13, July 2014. + + [RADIUS-Larger-Pkts] + Hartman, S., "Larger Packets for RADIUS over TCP", Work in + Progress, draft-ietf-radext-bigger-packets-03, March 2015. + + [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, + . + + + +Perez-Mendez, et al. Experimental [Page 35] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + [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 + Dial In User Service (RADIUS) Implementation Issues and + Suggested Fixes", RFC 5080, December 2007, + . + + [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. + Aboba, "Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS)", RFC 5176, + January 2008, . + + [SAML-RADIUS] + Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A + RADIUS Attribute, Binding, Profiles, Name Identifier + Format, and Confirmation Methods for SAML", Work in + Progress, draft-ietf-abfab-aaa-saml-10, February 2015. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 36] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + +Acknowledgements + + The authors would like to thank the members of the RADEXT working + group who have contributed to the development of this specification + by either participating in the discussions on the mailing lists or + 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 + been useful to improve the quality of the specification. + + This work has been partly funded by the GEANT GN3+ SA5 and CLASSe + () projects. + +Authors' Addresses + + Alejandro Perez-Mendez (editor) + University of Murcia + Campus de Espinardo S/N, Faculty of Computer Science + Murcia 30100 + Spain + + Phone: +34 868 88 46 44 + EMail: alex@um.es + + + Rafa Marin-Lopez + University of Murcia + Campus de Espinardo S/N, Faculty of Computer Science + Murcia 30100 + Spain + + Phone: +34 868 88 85 01 + EMail: rafa@um.es + + + Fernando Pereniguez-Garcia + University of Murcia + Campus de Espinardo S/N, Faculty of Computer Science + Murcia 30100 + Spain + + Phone: +34 868 88 78 82 + EMail: pereniguez@um.es + + + + + + + +Perez-Mendez, et al. Experimental [Page 37] + +RFC 7499 Fragmentation of RADIUS Packets April 2015 + + + Gabriel Lopez-Millan + University of Murcia + Campus de Espinardo S/N, Faculty of Computer Science + Murcia 30100 + Spain + + Phone: +34 868 88 85 04 + EMail: gabilm@um.es + + + Diego R. Lopez + Telefonica I+D + Don Ramon de la Cruz, 84 + Madrid 28006 + Spain + + Phone: +34 913 129 041 + EMail: diego@tid.es + + + Alan DeKok + Network RADIUS SARL + 57bis Boulevard des Alpes + Meylan 38240 + France + + EMail: aland@networkradius.com + URI: http://networkradius.com + + + + + + + + + + + + + + + + + + + + + + + +Perez-Mendez, et al. Experimental [Page 38] + -- cgit v1.2.3