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

[Stefan Winter <[e-mail]>]

Hi,

>> 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.

Most RADIUS servers are versaitle enough to act as server and proxy;
Radiator has hinted towards 6929 support soon, and I believe your
FreeRADIUS is a reference implementation of it since a long time. Both
can proxy, and both are in wide-spread use.

I think the issue is not artificial; it may well bite a deployment in
its backside.

That's not the end of the world though; simply adding a sentence in the
draft such a case exists and that deployments need to take care that
their deployed implementation(s) don't stumble over this.

>   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.

Aha! I had the impression that authz exchanges in the ABFAB world go all
the way from/to the RADIUS client that does the whole GSS EAP magic. And
that this is the equivalent of an "AP" in the non-network-access use case.

>   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.

That's something I can live with. Again, documenting in the draft that
User-Name is the only proxying criterion would be enough for me then.
Maybe a second one explaining that client to first-server is not in
scope/has complexities that can make the use of this draft hard/unsuitable.

Greetings,

Stefan

> 
>   Alan DeKok.
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext
> 


-- 
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]