Support of Fragmentation of RADIUS Packets
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, radext mailing list <email@example.com>, radext chair <firstname.lastname@example.org> Subject: Document Action: 'Support of fragmentation of RADIUS packets' to Experimental RFC (draft-ietf-radext-radius-fragmentation-12.txt) The IESG has approved the following document: - 'Support of fragmentation of RADIUS packets' (draft-ietf-radext-radius-fragmentation-12.txt) as Experimental RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/
Technical Summary 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 existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy clients and servers. Working Group Summary The content of this document was discussed at length in the working group, and there are multiple other approaches to the same problem. The document thus got significant exposure at the experts of the working group. The document has a few rough edges which were the cause of discussions. Considering the target status of Experimental, they appear minor enough to carry on with the experiment. The authors have documented the friction points in their section 11 "Operational Considerations". 11.1 in particular shows a process question: is it appropriate for an Experimental RFC to update a Standards-track RFC? The document attempts to follow that course; if this is ultimately agreed after IESG review, the text in that section will be changed accordingly. Document Quality At least one implementation is known which implements this specification: FreeRADIUS. The sheperd has no information about plans of other vendors. There were no particular expert reviews outside the working group process; i.e. no MIB doctor review nor Media Type review (and no need for those two as the document contains neither MIBs nor requests a Media Type). Since the document adds new transport capabilities, a thorough review by transport experts (e.g. TSVDIR) during IETF Last Call would be appreciated. Personnel The Document Shepherd is Stefan Winter <email@example.com>. The responsible Area Directors are Benoit Claise <firstname.lastname@example.org>.