Alejandro presented the fragmentation draft in RADEXT. There was a long discussion around it.
One suggestion was to just use Diameter for transporting large amounts of authorization data. That won't work, for the simple reason that the people involved don't run Diameter, have no plans to run Diameter, and have no budget to get Diameter. The consensus was that the document presents 3 related problems and solutions: 1) using Authorize-Only with Access-Accept It's currently specified for CoA (RFC 5176, Section 3.2). In this use-case, a CoA packet contains a State and Service-Type = Authorize-Only. The NAS then sends an Access-Request, with the same State and Authorize-Only. The RADIUS server responds with new authorization data. The same method could be used by sending Service-Type = Authorize-Only in an Access-Accept. This would need standardization. 2) Sending large amounts of authorization data The limit on RADIUS packet size is 4K. These limits have been run into in real-world deployments. e.g. sending large amounts of filter rules to a NAS. It would be useful to extend method (1) above to allow for more than 4K of authorization data to be sent. The draft proposes using Authorize-Only, and a sequence of Access-Request / Access-Challenge packets. Since challenges are widely implemented in servers and clients, this is an appealing approach. The major change to RADIUS here is to update RFC 2865 Section 5.44, to allow authorization attributes inside of Access-Challenge packets. This permission should be limited to Access-Requests having Service-Type = Authorize-Only. The result is a way to send arbitrary amounts of authorization data to a NAS. The extensions to RADIUS are hopefully minor, and not contentious. 3) Proxying large packets The solution to (2) above aggravates an existing problem in RADIUS. The specs are silent on what to do when a Proxy receives a large packet (<4K), and wants to add data to make the packet >4K. The problem is made worse by UDP fragmentation. Fragmented UDP packets can be dropped by intermediate routers, making the practical limit for RADIUS packets to be much smaller. The result is that it's difficult to send large amounts of authorization data from a server to a client, through intermediate proxies. The solution to (2) above helps by fragmenting the packets. However, we still don't know how large to make those fragments. And we don't know how to allow the proxies to re-write attributes when the authorization data is fragmented across multiple packets. The goal is to allow proxies to know how large to make the fragments, and also to allow them to re-write the authorization data. The draft proposes a number of work-arounds. One would be to have a new attribute like Framed-MTU, but instead "RADIUS MTU". It would signify the maximum size for RADIUS packets. This would allow home servers to know how large to make the fragments. The difficulty there is that the proxies still see fragments, and they want to re-write all of the authorization data. So they need to see *all* of the data. Re-writing each packet on the fly is likely unworkable. The draft proposes that the proxies obtain *all* of the data before re-writing it. This involves no changes to RADIUS. It does, however, require changes to implementations. These changes are documented, so that everyone is aware of the costs and benefits of the solution. And, so that the implementations are guided to a method that works. This message is long, but I hope it clarifies issues around the fragmentation draft. Alan DeKok. _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
