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

[Stefan Winter <[e-mail]>]

Hi,

>   The PMTU / 4096 octet problem is one which I think should be supported
> by the draft.  Telling operators to "fix their equipment" works in some
> cases.  In others, it's useful to be able to fragment at sizes which are
> *known* to work.

I don't have particularly hard feelings about this; so if there's use
for it, the text can also stay as it is.

>   Fragmentation in this draft is only for authorization (Access-Request
> / Access-Accept).  CoA can be done via sending a CoA with "Service-Type
> = Additional-Authorization".  The client should then do fragmentation as
> per the draft.  It's just too much to add fragmentation in multiple
> places in the protocol.

That's how I understood the first two paras in the document. The third
one seemed to deal with the CoA-ACK/NAK replies, but there I got lost
why these would need to be fragmented.

>   Additional fragmentation in proxies can be done.  But it likely
> involves re-assembly and subsequent re-sending / re-fragmentation of the
> entire data.  Doing "on the fly" additional fragmentation is just too
> hard (IMHO).

So it would suffice to state that chunks are not supposed to be
fragmented as-is; they need to be re-assembled into the long packet, and
then that needs to be chunked again.

>   We need a new flag for extended-type attributes.  Each Access-Request
>  / Access-Accept packet MUST be a perfect RADIUS packet in and of
> itself.  Some proxies MAY support RFC 6929, and will toss the packet if
> it isn't formatted correctly.  i.e. if the attribute fragments "fall
> off" the end of a packet.

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.

>   Fragmentation doesn't work with Access-Challenge.  There was a lot of
> discussion between the draft authors about this.  The fragmentation is
> *only* for authorization.  And it carries *only* authorization data, not
> authentication data.  Think of it as pausing an existing RADIUS
> conversation, and inserting a "fragmented data" exchange.

That's understood; I didn't want Access-Challenge packets to be
fragmented. My concern was that an initial (long) Access-Request needs
to be fragmented, but that upon completing its reassembly, the server
side finds that it is in the middle of an exchange which requires
Access-Challenge as a subsequent packet. It must be possible to finalise
the fragmented packet reassambly not just with an Accept or Reject; it
may need to be a Challenge to complete the subsequent authentication
that is done after the pre-authz.

>   We're assuming that proxy decisions are made via User-Name.  If it's
> done via anything else... well... sorry, but it won't work.  There are
> trade-offs which have to be made.
> 
>   And eduroam proxying via SSID is just weird.  Isn't the SSID for
> eduroam just "EDUROAM"?

Sure it is. But you may be participating in more than one consortium
with your hotspot.

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.

That's real life (but not on very many sites, as far as I can see).

"Sorry" may well be the appropriate answer. But that answer should be
written explicitly into the draft.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]