--- 1/draft-ietf-radext-radius-fragmentation-11.txt 2015-01-27 03:14:53.385956176 -0800 +++ 2/draft-ietf-radext-radius-fragmentation-12.txt 2015-01-27 03:14:53.453957837 -0800 @@ -1,24 +1,24 @@ RADIUS EXTensions Working Group A. Perez-Mendez Internet-Draft R. Marin-Lopez -Updates: 2865, 6158, 6929 F. Pereniguez-Garcia -(if approved) G. Lopez-Millan -Intended status: Experimental University of Murcia -Expires: July 24, 2015 D. Lopez +Intended status: Experimental F. Pereniguez-Garcia +Expires: July 30, 2015 G. Lopez-Millan + University of Murcia + D. Lopez Telefonica I+D A. DeKok Network RADIUS - January 20, 2015 + January 26, 2015 Support of fragmentation of RADIUS packets - draft-ietf-radext-radius-fragmentation-11 + draft-ietf-radext-radius-fragmentation-12 Abstract The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on July 24, 2015. + This Internet-Draft will expire on July 30, 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 @@ -58,51 +58,51 @@ described in the Simplified BSD License. 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 . . . . . . . . . . . . . . . . . . . 12 - 5.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 12 + 5.1. Pre-authorization . . . . . . . . . . . . . . . . . . . . 13 5.2. Post-authorization . . . . . . . . . . . . . . . . . . . . 17 6. Chunk size . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Allowed large packet size . . . . . . . . . . . . . . . . . . 21 8. Handling special attributes . . . . . . . . . . . . . . . . . 22 8.1. Proxy-State attribute . . . . . . . . . . . . . . . . . . 22 8.2. State attribute . . . . . . . . . . . . . . . . . . . . . 23 8.3. Service-Type attribute . . . . . . . . . . . . . . . . . . 24 8.4. Rebuilding the original large packet . . . . . . . . . . . 24 9. New flag T field for the Long Extended Type attribute definition . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. New attribute definition . . . . . . . . . . . . . . . . . . . 25 10.1. Frag-Status attribute . . . . . . . . . . . . . . . . . . 25 10.2. Proxy-State-Length attribute . . . . . . . . . . . . . . . 26 10.3. Table of attributes . . . . . . . . . . . . . . . . . . . 27 11. Operation with proxies . . . . . . . . . . . . . . . . . . . . 27 - 11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 27 + 11.1. Legacy proxies . . . . . . . . . . . . . . . . . . . . . . 28 11.2. Updated proxies . . . . . . . . . . . . . . . . . . . . . 28 - 12. General considerations . . . . . . . . . . . . . . . . . . . . 29 - 12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 30 - 12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 30 - 12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 30 - 13. Security Considerations . . . . . . . . . . . . . . . . . . . 31 - 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 - 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 16.1. Normative References . . . . . . . . . . . . . . . . . . . 32 - 16.2. Informative References . . . . . . . . . . . . . . . . . . 33 + 12. General considerations . . . . . . . . . . . . . . . . . . . . 30 + 12.1. Flag T . . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 12.2. Violation of RFC2865 . . . . . . . . . . . . . . . . . . . 31 + 12.3. Proxying based on User-Name . . . . . . . . . . . . . . . 31 + 12.4. Transport behaviour . . . . . . . . . . . . . . . . . . . 31 + 13. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 + 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 16.1. Normative References . . . . . . . . . . . . . . . . . . . 34 + 16.2. Informative References . . . . . . . . . . . . . . . . . . 34 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction The RADIUS [RFC2865] protocol carries authentication, authorization, and accounting information between a RADIUS Client and an RADIUS Server. Information is exchanged between them through RADIUS packets. Each RADIUS packet is composed of a header, and zero or more attributes, up to a maximum packet size of 4096 octets. The protocol is a request/response protocol, as described in the operational model ([RFC6158], Section 3.1). @@ -240,20 +240,24 @@ although some proxies might drop packets that does 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 octets", 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 re-issued + 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 octet limit imposed by one packet. However, the mechanism described in this specification SHOULD NOT be used to exchange more than 100 kilo-octets of data. Any more than this may turn RADIUS into a generic transport protocol, such as TCP or SCTP, which is undesired. Experience shows that attempts to transport bulk data across the Internet with UDP will inevitably fail, unless they re-implement all of the behavior of TCP. @@ -440,20 +444,27 @@ signals the fragmentation status. 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 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 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 flag "T" 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 @@ -1169,21 +1180,23 @@ 7 Extended-Type TBD2 Value 4 octets. Total length (in octets) of received Proxy-State - attributes (including headers). + attributes (including headers). As the RADIUS "length" field + cannot take values over 4096 octets, 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. 10.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. @@ -1297,24 +1310,24 @@ 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 the "Reserved" field. However, the working group thinks that would be overkill, as not such a great number of specifications extending that field are expected. - Hence, we have decided to include the "Updates" clause in the - document so far. Note that if this experiment does not succeed, the - "T" flag allocation would not persist, as it is tightly associated to - this document. + 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 WG to recall that this T flag is used. When/if the experiment + will be successful, the T flag will be properly assigned. 12.2. Violation of RFC2865 Section 5.1 indicates that all authorization and authentication handling will be postponed until all the chunks have been received. This postponement also affects 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 @@ -1342,20 +1355,27 @@ attribute. 12.4. Transport behaviour This proposal does not modify the way RADIUS interacts with the underlying transport (UDP). That is, RADIUS keeps following a lock- step behaviour, that requires receiving an explicit acknowledge for each chunk sent. Hence, bursts of traffic which 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.