--- 1/draft-ietf-radext-radius-fragmentation-04.txt 2014-03-07 00:14:35.608014406 -0800 +++ 2/draft-ietf-radext-radius-fragmentation-05.txt 2014-03-07 00:14:35.668015901 -0800 @@ -1,24 +1,24 @@ RADIUS EXTensions Working Group A. Perez-Mendez Internet-Draft R. Marin-Lopez Updates: RFC6929 (if approved) F. Pereniguez-Garcia Intended status: Experimental G. Lopez-Millan -Expires: September 2, 2014 University of Murcia +Expires: September 8, 2014 University of Murcia D. Lopez Telefonica I+D A. DeKok Network RADIUS - March 2014 + March 7, 2014 Support of fragmentation of RADIUS packets - draft-ietf-radext-radius-fragmentation-04 + draft-ietf-radext-radius-fragmentation-05 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 September 2, 2014. + This Internet-Draft will expire on September 8, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -443,21 +443,25 @@ Figure 2: Access-Request (chunk 1) Compliant servers (i.e. servers implementing fragmentation) receiving this packet will see the Frag-Status attribute, and postpone all authorization and authentication handling until all of 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 not contain any of them. + rebuilt, as some of the chunks may not contain any of them. The + authors acknowledge this is formally violating [RFC2865], but there + are no known operational issues with it. Once this document goes + beyond being considered as experimental, it will state it updates + [RFC2865]. Non-compliant 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 servers may return an Access-Reject, Access-Challenge, or an Access- Accept with a particular Service-Type other then Additional- Authorization. Compliant NAS implementations MUST treat these responses as if they had received Access-Reject instead. Compliant servers who wish to receive all of the chunks will respond