Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06

[Alan DeKok <[e-mail]>]

Stefan Winter wrote:
> That doesn't seem right. If a proxy supports RFC6929, but not the
> fragmentation draft, it will not know that the T flag exists and can't
> react accordingly. It will see an M flag and some gibberish in the
> Reserved field (which RFC6929 says should simply be ignored). It will
> observe that the M flag requirements are violated and has every right to
> drop the packet.

  Yes.  That presumes (a) everyone implements RFC 6929, and (b) those
implementations get deployed to proxies.

  I don't think either will happen for a while.  That limits the
problems with this approach.

> Imagine a single access point which is part of "eduroam" and "S-Mobile";
> and emits both SSIDs. Both consortia use RADIUS auth; the access point
> is dumb and only knows "its" authentication server.
> 
> At that point, the RADIUS server which gets the AP's packet needs to
> realise: if a user tried to log into the eduroam SSID, I'll proxy the
> packet to eduroam infrastructure; if the user tried S-Mobile, I'll proxy
> to their infrastructure.

  I think initially the idea is to have fragmentation from server to
server.  i.e. few (if any) APs will be implementing it.  So the issue
becomes less relevant.

  A server local to the AP can track a users session, including SSID.
And then make proxy decisions based on that.  The proxies in the wider
network will *not* know about the site's SSID, and will *not* be basing
proxy decisions on it.

  Alan DeKok.