Subject: [radext] Fragmentation in RADIUS

From: Alan DeKok <[email-masked]>
Date: Sat, 31 Mar 2012 10:48:24 +0200

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.