RADIUS EXTensions Working Group A. Perez-Mendez Internet-Draft R. Marin-Lopez Intended status: Experimental F. Pereniguez-Garcia Expires: August 5, 2013 G. Lopez-Millan University of Murcia D. Lopez Telefonica I+D A. DeKok Network RADIUS Feb 2013 Support of fragmentation of RADIUS packets draft-perez-radext-radius-fragmentation-05 Abstract This document describes a mechanism providing fragmentation support of RADIUS packets that exceed the 4096 bytes limit. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 August 5, 2013. Copyright Notice Copyright (c) 2013 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 Perez-Mendez, et al. Expires August 5, 2013 [Page 1] Internet-Draft Fragmentation of RADIUS packets Feb 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Fragmentation of packets . . . . . . . . . . . . . . . . . . . 5 3.1. Access-Request . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Access-Accept . . . . . . . . . . . . . . . . . . . . . . 9 3.3. Combined use of both fragmented packets . . . . . . . . . 12 3.4. Unsupported packet types . . . . . . . . . . . . . . . . . 15 3.4.1. Accounting . . . . . . . . . . . . . . . . . . . . . . 15 3.4.2. CoA . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Allowed large packet size . . . . . . . . . . . . . . . . . . 16 6. Handling special attributes . . . . . . . . . . . . . . . . . 17 6.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 17 6.2. State attribute . . . . . . . . . . . . . . . . . . . . . 18 6.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 18 6.4. Rebuilding the original large packet . . . . . . . . . . . 19 7. New attribute definition . . . . . . . . . . . . . . . . . . . 19 7.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 19 7.2. Proxy-State-Len attribute . . . . . . . . . . . . . . . . 20 7.3. Table of attributes . . . . . . . . . . . . . . . . . . . 21 8. Operation with proxies . . . . . . . . . . . . . . . . . . . . 22 8.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 22 8.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 11. Normative References . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Perez-Mendez, et al. Expires August 5, 2013 [Page 2] Internet-Draft Fragmentation of RADIUS packets Feb 2013 1. Introduction RADIUS [RFC2865] is a protocol for carrying authentication, authorization, and configuration information between a Network Access Server (NAS) which desires to authenticate its links and a shared Authentication Server (AS). Information is exchanged between the NAS and the AS through RADIUS packets. Each RADIUS packet can transport several RADIUS attributes, to convey the necessary information to the other peer, up to a maximum size of 4096 bytes of total data (including RADIUS packet headers). RADIUS attributes have a maximum payload size of 253 bytes. RADIUS has been extensively used for the years. Along this time, the need of sending RADIUS attributes larger than 253 bytes has become a reality. An immediate alternative to overcome this issue consists in truncating the data into a group of RADIUS attributes of the same type, and then insert them ordered into the RADIUS packet. At the destination, the content of these attributes is extracted and joined to rebuild the original data. This scheme is followed, for example, by RADIUS-EAP [RFC3579]. A more advanced solution is given in [I-D.ietf-radext-radius-extensions], where extended attributes can be marked with a flag to indicate fragmentation. A reference-based mechanism, where the value of the attributes can be obtained by other protocol instead of RADIUS, is also proposed in [RFC6158]. However, there are no proposals to fragment a large-sized RADIUS packet into multiple small-sized RADIUS packets, where the length of the original (unfragmented) RADIUS packet exceeds the 4096-octet limit imposed by the RADIUS specification. When RADIUS is considered in more complex AAA scenarios, including the exchange of bigger amount of data, like SAML assertions or JSON Web tokens, exceeding this limit becomes more likely, thus making necessary the availability of mechanisms for dealing with this situation. This document defines a mechanism to allow RADIUS peers to exchange packets exceeding the 4096 bytes limit, by fragmenting them across several exchanges. This proposal tries to maintain compatibility with intra-packet fragmentation mechanisms (like those defined in [RFC3579] or in [I-D.ietf-radext-radius-extensions]) and with the existing RADIUS deployments. 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]. Perez-Mendez, et al. Expires August 5, 2013 [Page 3] Internet-Draft Fragmentation of RADIUS packets Feb 2013 2. Overview When a RADIUS client or server need to send a packet that exceeds the 4096 bytes limit, the mechanism proposed in this document is used. First, the large packet is truncated into several smaller RADIUS packets (i.e. chunks) of the same type (i.e. Access-Request or Access-Accept). Each small RADIUS packet is so-called "chunk" in this specification. The first chunk contains "n" RADIUS attributes of the original packet, where the order of the attributes of the same type is respected, until a limit below 4096 bytes. The actual amount of data from the original packet included into each chunk will depend on the specific length of the attributes, the amount of proxies between both ends, and the number of signalling attributes (more details in Section 4). Signalling to indicate whether there are fragmented data to be sent is performed by means of a new attribute called Frag-Status. Section 7.1 defines this attribute and its possible values. The first chunk is sent to the other party, which identifies the packet as a chunk (based on the information contained in the Frag- Status attribute), and requests for the next chunk. The RADIUS State attribute and the RADIUS Identifier field are used to tie the conversation together. This process is repeated until all the RADIUS attributes from the original packet have been sent by means of several chunks. Once all the chunks have been received by the peer, the original packet is reconstructed and processed as if received in one piece. When a packet is truncated into chunks, a special situation may occur when it is combined with Extended Type attributes as defined in [I-D.ietf-radext-radius-extensions]. If the truncation splits an existing fragmented attribute along two or more chunks, the last fragment of that attribute for the first chunk will have the flag M enabled (indicating the attribute is not completed). This situation is specifically forbidden in [I-D.ietf-radext-radius-extensions]. To indicate that this situation is provoked by a truncation and hence MUST be allowed, a new flag "T" (indicating truncation) MUST be set into that Extended-Type-Flag attribute. The combination of the flags "M" and "T" indicates that the attribute is fragmented (flag M), but that all the fragments are not available in this chunk (flag T). Indeed, this last situation will be the most usual. Typically, packet fragmentation will occur as a consequence of including one or more large (and fragmented) attributes into a RADIUS packet. Hence, the truncation will probably split the large attribute into two (or more) pieces. The rest of possibilities, where the truncation point does not split a fragmented attribute, do not require any special Perez-Mendez, et al. Expires August 5, 2013 [Page 4] Internet-Draft Fragmentation of RADIUS packets Feb 2013 treatment. The packet fragmentation mechanism described in this draft can only be used once the authentication process has been completed. The reason behind this decision is based on security. If unauthenticated clients were permitted to ask the server to store bulk data, then a Denial of Service (DoS) attack becomes possible. An attacker could initiate a large number of connections, each of which requests the server to store a large amount of data. This data could cause memory exhaustion on the server, and result in authentic users being denied access. It is worth noting that authentication mechanisms are already designed to avoid exceeding the 4096 bytes limit. 3. Fragmentation of packets When the NAS or the AS desires to send a RADIUS packet that exceeds the 4096 bytes limit, the packet can be split into smaller packets (chunks) and sent over different exchanges. This fact is indicated by including a Frag-Status = More-Data-Pending (except the last one of the series). All the packets belonging to the same fragmentation exchange are tied together by making use of the standard RADIUS mechanisms, that is, by using the Identifier field of the RADIUS packet by the Client and by using the RADIUS State attribute by the Server. The following sections describe how to perform fragmentation for each RADIUS packet type. In order to make these examples simpler, it is assumed that each RADIUS packet can include up to 8 RADIUS attributes, instead of using bytes. The used notation is the following: Packet-Type(Identifier){attributes} where Packet-Type can be Access-Request, Access-Challenge, Access- Accept or Access-Reject, and Identifier is the value of the Identifier field of the RADIUS packet header. Each attribute is denoted by Attr[Flags], where Attr is the name of the attribute type, and flags represents the active flags as described in [I-D.ietf-radext-radius-extensions]. Frag-Status(X) indicates a Frag-Status attribute with value X, where X can be FS for Fragmentation-Supported, AA for Additional-Authorization, MDP for More-Data-Pending and MDR for More-Data-Request. Service-Type(X) indicates a Service-Type attribute with value X, where AA indicates the value Additional-Authorization. Perez-Mendez, et al. Expires August 5, 2013 [Page 5] Internet-Draft Fragmentation of RADIUS packets Feb 2013 3.1. Access-Request When the client needs to send a large amount of data to the server, it MUST signal this by including a Frag-Status = Additional- Authorization in the initial Access-Request. This packet will likely be small (e.g. contain EAP-Identity), and there will be room for the attribute. The client MUST NOT send the Frag-Status attribute in later packets (e.g. responses to any Access-Challenge) until an Access-Accept packet is received. It has already signalled that there is data to be sent, and there is no need to do so again. Servers implementing this specification MUST flag the session as requiring more data. They MAY respond with Access-Challenge, where the authentication method requires that. When the authentication is complete, either an Access-Reject or Access-Accept is returned. If the client has signalled that there is more data pending for this session, the server MUST respond with Service-Type = Additional- Authorization in any Access-Accept. The client is then expected to initiate the fragmentation procedure as defined here. If a client sends the Frag-Status = Additional-Authorization attribute, and receives an Access-Accept without Service-Type = Additional-Authorization, or with any other value for Service-Type, it will know the server does not implement this specification and will not allow the exchange of fragmented packets. Hence, it MAY behave as if it had received Access-Reject instead and close the authentication. If the server supports fragmentation, the data to be sent is then split into smaller packets (chunks) and sent over different exchanges to the server. This fact is indicated by including a Frag-Status = More-Data-Pending attribute on each chunk (except the last one of the series). All the packets belonging to the same fragmentation exchange are tied together by making use of the standard RADIUS mechanisms, that is, by using the Identifier field of the RADIUS packet by the Client and by using the RADIUS State attribute by the Server. o In this example, the client (NAS) is trying to send a large Access-Request packet to the server (AS). Attributes "Attr1" and "Attr2" are Extended-Type-Flags attributes, as defined in [I-D.ietf-radext-radius-extensions]. Attr1 is composed by 9 fragments, while Attr2 is composed by 3 of them. Access-Request() {User-Name, Calling-Station-Id, Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1, Attr2[M], Attr2[M], Attr2} Perez-Mendez, et al. Expires August 5, 2013 [Page 6] Internet-Draft Fragmentation of RADIUS packets Feb 2013 o As the RADIUS packet exceeds the maximum allowed length (8 attributes), the RADIUS client indicates the server its will of sending additional large data after authentication has been completed. This fact is indicated by including the Frag-Status = Additional-Authorization attribute into the first Access-Request sent from the NAS to the AS. Access-Request(1) {User-Name, ..., Frag-Status(AA)} o The RADIUS server flags the session as requiring more data, and both continue with the authentication process as usual (e.g. exchange of Access-Request/Access-Challenge). RADIUS Identifier is not increased in this example for sake of simplicity. o Within the final Access-Accept packet, the server includes a Service-Type = Additional-Authorization and a State attribute, indicating to the client that it is ready to receive the additional authorization information. If the server wanted to send a different Service-Type attribute, it would be sent in the last Access-Accept packet after receiving all the data from the client. Access-Accept(1) {User-Name, ..., State1, Service-Type(AA)} o The RADIUS client truncates the original packet to generate the first chunk, including the Frag-Status = More-Data-Pending attribute. As attribute "Attr1" does not completely fit into this chunk, the flag "T" is activated into the last fragment included into this chunk, to indicate that it is not the last fragment of the attribute. If the original Access-Request packet contained a User-Name attribute, it MUST be included on every chunk sent to the server. This is required because proxies may need this value to forward the chunk to its proper destination. Access-Request(2) {User-Name, Calling-Station-Id, Attr1[M], Attr1[M], Attr1[M], Attr1[M], State1, Frag-Status(MDP)} o When the server receives the RADIUS packet containing the Frag- Status = More-Data-Pending attribute, the processing of the packet is delayed until all the pending data is received. The pending data is requested by means of an Access-Challenge packet containing a Frag-Status = More-Data-Request, using the State attribute to tie together this response with the subsequent request from the client. Access-Challenge(2) {Frag-Status(MDR), State2} Perez-Mendez, et al. Expires August 5, 2013 [Page 7] Internet-Draft Fragmentation of RADIUS packets Feb 2013 o The client continues including attributes until another chunk is completed, including the Frag-Status = More-Data-Pending attribute, as Attr2 does not fit in this chunk. The State attribute received in the Access-Challenge (i.e. State2) is also included. Access-Request(3) {User-Name, Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1, State2, Frag-Status(MDP)} o As the received request contains the Frag-Status = More-Data- Pending attribute, the server stores the attributes into the state associated to State1 and replies with another Access-Challenge packet. The challenge contains a Frag-Status = More-Data-Request and a new State attribute (i.e. State3) that refers to this conversation. Access-Challenge(3) {Frag-Status(MDR), State3} o Finally, the client sends the last chunk of the original packet, including the received State attribute (i.e. State3). Access-Request(4) {User-Name, Attr2[M], Attr2[M], Attr2, State3} o On reception of this last chunk (no Frag-Status = More-Data- Pending present), the server can process the received attributes as if they all had been received into a single RADIUS packet larger than 4096 bytes. See Section 6.4 for further details. It generates the Access-Accept packet finalizing the exchange of data. This packet will contain the original Service-Type attribute (if any). Access-Accept(4) {User-Name, Service-Type(X)} The Figure 1 depicts this scenario. Perez-Mendez, et al. Expires August 5, 2013 [Page 8] Internet-Draft Fragmentation of RADIUS packets Feb 2013 +-+-+-+-+ +-+-+-+-+ | NAS | | AS | +-+-+-+-+ +-+-+-+-+ | | | Access-Request(1){User-Name,...,Frag-Status(AA)} | |-------------------------------------------------------->| | . | | . | | Authentication process | |<------------------------------------------------------->| | . | | . | | Access-Accept(1){User-Name,...,State1, | | Service-Type(AddAuth)} | |<--------------------------------------------------------| | | | Access-Request(2){User-Name,Calling-Station-Id, | | Attr1[M],Attr1[M],Attr1[M],Attr1[MT] | | State1,Frag-Status(MDP)} | |-------------------------------------------------------->| | | | Access-Challenge(2){Frag-Status(MDR),State2} | |<--------------------------------------------------------| | | | Access-Request(3){User-Name,State2,Attr1[M], | | Attr1[M],Attr1[M],Attr1[M],Attr1, | | Frag-Status(MDP)} | |-------------------------------------------------------->| | | | Access-Challenge(3){Frag-Status(MDR),State3} | |<--------------------------------------------------------| | | | Access-Request(4){User-Name,State3,Attr2[M], | | Attr2[M],Attr2} | |-------------------------------------------------------->| | | | Access-Accept(4){User-Name,Service-Type(X)} | |<--------------------------------------------------------| Figure 1: Fragmented Access-Request packet 3.2. Access-Accept If the AS wants to send an Access-Accept packet that exceeds the 4096 bytes limit (e.g. due to the inclusion of authorization-specific attributes), the operation is slightly different. In addition to the use of the Frag-Status = More-Data-Pending attribute for each chunk, the AS makes use of the Service-Type = Additional-Authorization Perez-Mendez, et al. Expires August 5, 2013 [Page 9] Internet-Draft Fragmentation of RADIUS packets Feb 2013 attribute. In this way, when a client receives an Access-Accept and it does not support Additional-Authorization, it MUST 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 signalling. Client supporting this specification and not wanting to send additional authorization information (see section above) MUST include a Frag-Status = Fragmentation-Supported attribute in the first Access-Request sent to the server, in order to indicate they would accept fragmented data from the sever. o The RADIUS client includes a Frag-Status = Fragmentation-Supported attribute into the first Access-Request packet sent to the server, indicating this specification is supported. Access-Request(1) {User-Name, ..., Frag-Status(FS)} o Once the user has been authenticated, the AS wants to send the following Access-Accept packet. Attr1 has 9 fragments, while Attr2 has 3 fragments: Access-Accept(1) {User-Name, Service-Type(X), Framed-IP- Address, Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1, Attr2[M], Attr2[M], Attr2[M]} o As the RADIUS packet exceeds the maximum allowed length (8 attributes), the AS truncates the packet to generate the first chunk. This chunk includes a Service-Type = Additional- Authorization, indicating that this Access-Accept MUST not be considered as a final packet, and a Frag-Status = More-Data- Pending attribute indicating that there are more chunks yet to be provided. Note that the Service-Type(X) is not included yet to avoid confusion. Besides, as attribute "Attr1" does not completely fit into this chunk, the flag "T" is activated into the last fragment included into this chunk. Finally, a new RADIUS State attribute is included to allow the AS to correlate the following Access-Request with this chunk. Access-Accept(1) {User-Name, Framed-IP-Address, Attr1[M], Attr1[M], Attr1[MT],Service-Type(AA), State1, Frag-Status(MDP)} o When the NAS receives the Access-Accept, it determines, based on the Frag-Status = More-Data-Pending attribute, that additional exchanges are required. Thus, it generates a new Access-Request Perez-Mendez, et al. Expires August 5, 2013 [Page 10] Internet-Draft Fragmentation of RADIUS packets Feb 2013 packet containing the User-Name attribute, a Frag-Status = More- Data-Request attribute and the State attribute received from the server. Access-Request(2) {User-Name, Frag-Status(MDR), State1} o The AS then generates a new chunk with part of the remaining attributes to be sent. As they does not fit into a single chunk, Frag-Status = More-Data-Pending and Service-Type = Additional- Authorization are included, along with a new State attribute. Access-Accept(2) {User-Name, Attr1[M], Attr1[M], Attr1[M], Attr1[MT], Service-Type(AA), State2, Frag-Status(MDP)} o The NAS determines there is more data pending, and generates a new Access-Request packet containing the User-Name attribute, a Frag- Status = More-Data-Request attribute and the State attribute received from the server. Access-Request(3) {User-Name, Frag-Status(MDR), State2} o Finally, the AS sends the last chunk as all the remaining data fits into a single packet. This is indicated by not including a Frag-Status = More-Data-Pending attribute. This last chunk includes the original Service-Type attribute. Access-Accept(3) {User-Name, Attr1[M], Attr1, Attr2[M], Attr2[M], Attr2, Service-Type(X)} o On reception of this last packet, the NAS can process the totality of the received attributes as if they were all received into a single RADIUS packet larger than 4096 bytes. See Section 6.4 for further details on this. The following figure depicts the exchange of chunks between the NAS and the AS. Perez-Mendez, et al. Expires August 5, 2013 [Page 11] Internet-Draft Fragmentation of RADIUS packets Feb 2013 +-+-+-+-+ +-+-+-+-+ | NAS | | AS | +-+-+-+-+ +-+-+-+-+ | | | Access-Request(1){User-Name,...,Frag-Status(FS)} | |-------------------------------------------------------->| | . | | . | | Authentication process | |<------------------------------------------------------->| | . | | . | | Access-Accept(1){User-Name,Framed-IP-Address, | | Attr1[M],Attr1[M],Attr1[MT],State1, | | Service-Type(AA),Frag-Status(MDP)} | |<--------------------------------------------------------| | | | Access-Request(2){User-Name,Frag-Status(MDR),State1} | |-------------------------------------------------------->| | | | Access-Accept(2){User-Name,Attr1[M],Attr1[M], | | Attr1[M],Attr1[M],Service-Type(AA), | | State2,Frag-Status(MDP)} | |<--------------------------------------------------------| | | | Access-Request(3){User-Name,Frag-Status(MDR),State2} | |-------------------------------------------------------->| | | | Access-Accept(3){User-Name,Attr1[M],Attr1, | | Attr2[M],Attr2[M],Attr2, | | Service-Type(X)} | |<--------------------------------------------------------| Figure 2: Fragmented Access-Accept packet 3.3. Combined use of both fragmented packets The use of both fragmented packets may occur simultaneously. In that case, the AS will be the first sending the fragmented data. In the last chunk from the AS to the NAS it is included a Service-Type = Additional-Authorization attribute, indicating the NAS that it can proceed sending its data. The original Service-Type (if any) will be included in the last Access-Accept from the AS to the NAS after having received all the chunks. Specifically, the NAS wants to send the following Access-Request packet (Attr1 has 9 fragments): Perez-Mendez, et al. Expires August 5, 2013 [Page 12] Internet-Draft Fragmentation of RADIUS packets Feb 2013 Access-Request(1) {User-Name, Calling-Station-Id, Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1[M], Attr1} While the AS wants to send the following Access-Accept packet (Attr2 has 8 fragments): Access-Accept(1) {User-Name, Service-Type(X), Framed-IP-Address, Attr2[M], Attr2[M], Attr2[M], Attr2[M], Attr2[M], Attr2[M], Attr2[M], Attr2} Perez-Mendez, et al. Expires August 5, 2013 [Page 13] Internet-Draft Fragmentation of RADIUS packets Feb 2013 +-+-+-+-+ +-+-+-+-+ | NAS | | AS | +-+-+-+-+ +-+-+-+-+ | | | Access-Request(1){User-Name,...,Frag-Status(AA)} | |-------------------------------------------------------->| | . | | . | | Authentication process | |<------------------------------------------------------->| | . | | . | | Access-Accept(1){User-Name,Framed-IP-Address, | | Attr2[M],Attr2[M],Attr2[MT],State1, | | Service-Type(AA),Frag-Status(MDP)} | |<--------------------------------------------------------| | | | Access-Request(2){User-Name,Frag-Status(MDR),State1} | |-------------------------------------------------------->| | | | Access-Accept(2){User-Name,Attr2[M],Attr2[M],| | Attr2[M],Attr2[M],Attr2, | | State2,Service-Type(AA)} | |<--------------------------------------------------------| | | | Access-Request(3){User-Name,Calling-Station-Id, | | Attr1[M],Attr1[M],Attr1[M],Attr1[MT], | | State1,Frag-Status(MDP)} | |-------------------------------------------------------->| | | | Access-Challenge(3){User-Name, | | Frag-Status(MDR),State3} | |<--------------------------------------------------------| | | | Access-Request(4){User-Name,State3,Attr1[M], | | Attr1[M],Attr1[M],Attr1[M],Attr1} | |-------------------------------------------------------->| | | | Access-Accept(4){User-Name,Service-Type(X)} | |<--------------------------------------------------------| Figure 3: Combined fragmentation of Access-Request and Access-Accept packets Perez-Mendez, et al. Expires August 5, 2013 [Page 14] Internet-Draft Fragmentation of RADIUS packets Feb 2013 3.4. Unsupported packet types We define fragmentation for authentication and authorization only. Fragmentation for other packet types is not supported. This section explains the rationale behind that decision 3.4.1. Accounting There is no need to fragment accounting packets. 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 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. 3.4.2. CoA There is no need to fragment CoA 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. Implementations supporting this specification may not be able to change authorization data for a particular session. In that case, they MUST respond with a CoA-NAK, as above. Otherwise, the implementation MUST start fragmentation via Access-Request, using the methods defined here. 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. When a sessions authorization is changed, the CoA server MUST continue the existing service until the new authorization parameters are applied. The change of service SHOULD be done atomically. If the CoA server is unable to apply the new authorization, it MUST terminate the user session. Perez-Mendez, et al. Expires August 5, 2013 [Page 15] Internet-Draft Fragmentation of RADIUS packets Feb 2013 4. Chunk size In an ideal scenario, chunks would be exactly 4096 bytes length, and they would contain exactly 4096-20=4076 bytes of attributes from the original large packet (where 20 is the size of the RADIUS header). 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 on every chunk. 2. RADIUS fragmentation requires the introduction of some extra attributes for signalling. Specifically, a Frag-Status attribute (7 bytes) is included on 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 server to bind an Access- Request with a previous Access-Challenge. User-Name attributes (from 3 to 255 bytes) are introduced on every chunk the 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 signalling data, reducing the amount of payload information that can be sent on each chunk. 3. RADIUS packets SHOULD be adjusted to avoid exceeding the network MTU. Otherwise, IP fragmentation may occur, having 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 into the chunk. This is described with further detail in Section 6.1. 5. Allowed large packet size There are no provisions for signalling 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, which includes RADIUS attribute header fields. Or it can be one or more "large" attributes (more than 256 octets 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 take on future packets. As a result, it is impossible Perez-Mendez, et al. Expires August 5, 2013 [Page 16] Internet-Draft Fragmentation of RADIUS packets Feb 2013 to signal any meaningful value for the total amount of additional data. Implementations of this specification MUST limit the total amount of data they send and/or receive via this specification. It is RECOMMENDED that the limits be set to a few tens of kilobytes. Any more than this may turn RADIUS into a generic transport protocol, which is undesired. It is RECOMMENDED that this limit be exposed to administrators, 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. It is RECOMMENDED that the number of round trips be limited to twenty (20). Any more than this may indicate an implementation error, misconfiguration, or a denial of service (DoS) attack. It is RECOMMENDED that this limit be exposed to administrators, so that it can be changed if necessary. 6. Handling special attributes 6.1. Proxy-State attribute RADIUS proxies may introduce Proxy-State attributes into any Access- Request packet they forward. Should they cannot add this information to the packet, they may silently discard forwarding it to its destination, leading to DoS situations. Moreover, any Proxy-State attribute received by a RADIUS server in an Access-Request packet MUST be copied into the reply packet to it. For these reasons, Proxy-State attributes require a special treatment within the packet fragmentation mechanism. When the RADIUS server replies to an Access-Request packet as part of a conversation involving a fragmentation (either a chunk or a request for chunks), it MUST include every Proxy-State attribute received into the reply packet. This means that the 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 many space MUST be left on 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, clients need a mechanism to discover the amount of space required by proxies to introduce their Proxy-State attributes. In the following we describe a new mechanism to perform such a discovery: Perez-Mendez, et al. Expires August 5, 2013 [Page 17] Internet-Draft Fragmentation of RADIUS packets Feb 2013 1. When a RADIUS client does not know how many 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 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 client in the next reply packet, encoded into a new attribute called Proxy-State-Len. 3. The RADIUS client reacts upon the reception of this attribute by adjusting the maximum size for the next chunk accordingly. 6.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 with the fragmentation. If the procedure described in Section 3 is followed, two different State attributes could be included into a single chunk, incurring into two problems. First, [RFC2865] explicitly forbids that more than one State attribute appears into a single packet. A straightforward solution consists on making the RADIUS server to send the original State attribute into the last chunk of the sequence (attributes can be re-ordered 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. Something similar happens when the RADIUS client has to send a fragmented packet that contains a State attribute on it. The client MUST assure that this original State is included into the first chunk sent to the server (as this one never contains any State attribute due to fragmentation). 6.3. Service-Type attribute This RADIUS fragmentation mechanism makes use of the Service-Type attribute to indicate an Access-Accept packet is not granting access to the service yet, since additional authorization exchange needs to be performed. Similarly to the State attribute, the RADIUS server has to send the original Service-Type attribute into the last Access- Accept of the RADIUS conversation to avoid ambiguity. Perez-Mendez, et al. Expires August 5, 2013 [Page 18] Internet-Draft Fragmentation of RADIUS packets Feb 2013 6.4. Rebuilding the original large packet The RADIUS client stores the RADIUS attributes received on each chunk 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 this list, as they have been introduced as part of the fragmentation signalling and hence, they are not part of the original packet. o State (except the one in the last chunk, if present) o Service-Type = Additional-Authorization o Frag-Status o Proxy-State-Len 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 Frag-Status o Proxy-State (except the ones in the last chunk) o User-Name (except the one in the first chunk) 7. New attribute definition This document proposes the definition of two new extended type attributes, called Frag-Status and Proxy-State-Len. The format of these attributes follows the indications for an Extended Type attribute defined in [I-D.ietf-radext-radius-extensions]. 7.1. Frag-Status attribute This attribute is used for fragmentation signalling, and its meaning depends on the code value transported within it. The following figure represents the format of the Frag-Status attribute. Perez-Mendez, et al. Expires August 5, 2013 [Page 19] Internet-Draft Fragmentation of RADIUS packets Feb 2013 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 4: Frag-Status format Type To be assigned (TBA) Length 7 Extended-Type To be assigned (TBA). Code 4 byte. Integer indicating the code. The values defined in this specifications are: 0 - Reserved 1 - Fragmentation-Supported 2 - Additional-Authorization 3 - More-Data-Pending 4 - 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. 7.2. Proxy-State-Len attribute This attribute indicates to the RADIUS client the length of the Proxy-State attributes received by the RADIUS server. This information is useful to adjust the length of the chunks sent by the RADIUS client. The format of this Proxy-State-Len attribute is the following: Perez-Mendez, et al. Expires August 5, 2013 [Page 20] Internet-Draft Fragmentation of RADIUS packets Feb 2013 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 5: Proxy-State-Len format Type To be assigned (TBA) Length 7 Extended-Type To be assigned (TBA). Value 4 bytes. Total length (in bytes) of received Proxy-State attributes (including headers). This attribute MAY be present in Access-Challenge and Access-Accept packets. It MUST not be included in Access-Request or Access-Reject packets. 7.3. Table of attributes The following table shows the different attributes defined in this document related with the kind of RADIUS packets where they can be present. | Kind of packet | +-----+-----+-----+-----+ Attribute Name | Req | Acc | Rej | Cha | ----------------------+-----+-----+-----+-----+ Frag-Status | 0-1 | 0-1 | 0 | 0-1 | ----------------------+-----+-----+-----+-----+ Proxy-State-Len | 0 | 0-1 | 0 | 0-1 | ----------------------+-----+-----+-----+-----+ Figure 6 Perez-Mendez, et al. Expires August 5, 2013 [Page 21] Internet-Draft Fragmentation of RADIUS packets Feb 2013 8. 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. 8.1. Legacy proxies As every chunk is indeed a RADIUS packet, legacy proxies treat them as the rest of packets, routing them to their destination. Proxies can introduce Proxy-State attributes to Access-Request packets, even if they are indeed chunks. This will not affect how fragmentation is managed. The server will include all the received Proxy-State attributes into the generated response, as described in [RFC2865]. Hence, proxies do not distinguish between a regular RADIUS packet and a chunk. 8.2. Updated proxies Updated proxies can interact with clients and servers in order to obtain the complete large packet before start 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 NAS to obtain a large Access- Request packet, modify an attribute resulting into a even more large packet, and interacts with the AS to complete the transmission of the modified packet. Perez-Mendez, et al. Expires August 5, 2013 [Page 22] Internet-Draft Fragmentation of RADIUS packets Feb 2013 +-+-+-+-+ +-+-+-+-+ | NAS | | Proxy | +-+-+-+-+ +-+-+-+-+ | | | Access-Request(1){User-Name,Calling-Station-Id, | | Attr1[M],Attr1[M],Attr1[M],Attr1[M], | | Attr1[MT],Frag-Status(MDP)} | |--------------------------------------------------->| | | | Access-Challenge(1){User-Name, | | Frag-Status(MDR),State1} | |<---------------------------------------------------| | | | Access-Request(2)(User-Name,State1,Attr1[M], | | Attr1[M],Attr1[M],Attr1} | |--------------------------------------------------->| PROXY MODIFIES ATTRIBUTE Data INCREASING ITS SIZE FROM 9 FRAGMENTS TO 11 FRAGMENTS Figure 7: Updated proxy interacts with NAS Perez-Mendez, et al. Expires August 5, 2013 [Page 23] Internet-Draft Fragmentation of RADIUS packets Feb 2013 +-+-+-+-+ +-+-+-+-+ | Proxy | | AS | +-+-+-+-+ +-+-+-+-+ | | | Access-Request(3){User-Name,Calling-Station-Id, | | Attr1[M],Attr1[M],Attr1[M],Attr1[M], | | Attr1[MT],Frag-Status(MDP)} | |--------------------------------------------------->| | | | Access-Challenge(1){User-Name, | | Frag-Status(MDR),State2} | |<---------------------------------------------------| | | | Access-Request(4){User-Name,State2,Attr1[M], | | Attr1[M],Attr1[M],Attr1[M], | | Attr1[MT],Frag-Status(MDP)} | |--------------------------------------------------->| | | | Access-Challenge(1){User-Name, | | Frag-Status(MDR),State3} | |<---------------------------------------------------| | | | Access-Request(5){User-Name,State3,Attr1} | |--------------------------------------------------->| Figure 8: Updated proxy interacts with AS 9. 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 signed 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. 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 5 gives some indications on what could be a 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 Perez-Mendez, et al. Expires August 5, 2013 [Page 24] Internet-Draft Fragmentation of RADIUS packets Feb 2013 stored in an external database, or in files. This approach mitigates the resource exhaustion issue, as servers today already store large amounts of accounting data. 10. IANA Considerations The authors request that Attribute Types and Attribute Values defined in this document be registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS namespaces as described in the "IANA Considerations" section of [RFC3575], in accordance with BCP 26 [RFC5226]. For RADIUS packets, attributes and registries created by this document IANA is requested to place them at http://www.iana.org/assignments/radius-types. This document defines the following RADIUS messages: o Frag-Status o Proxy-State-Len Additionally, allocation of a new Service-Type value for "Additional- Authorization" is requested. 11. Normative References [I-D.ietf-radext-radius-extensions] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", draft-ietf-radext-radius-extensions-11 (work in progress), February 2013. [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. [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Perez-Mendez, et al. Expires August 5, 2013 [Page 25] Internet-Draft Fragmentation of RADIUS packets Feb 2013 Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011. Authors' Addresses Alejandro Perez-Mendez (Ed.) 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. Expires August 5, 2013 [Page 26] Internet-Draft Fragmentation of RADIUS packets Feb 2013 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 15 av du Granier Meylan, 38240 France Phone: +34 913 129 041 Email: aland@networkradius.com URI: http://networkradius.com Perez-Mendez, et al. Expires August 5, 2013 [Page 27]