Re: [radext] Meeting laundry list

[Stefan Winter <[e-mail]>]

Hi,

>> I don't know that "overload" is applicable in this context or why it
>> couldn't be used for multiple purposes concurrently.
> 
>   Yeah.  Fill it with whatever makes you happy.
> 
>> We don't really know generally what constitutes a "loop" or granularity
>> of the system box (Parts of one server or entire groups of servers).
>> Messages may be able to loop back for another round of processing after
>> being sent outside the admin domain.
> 
>   I agree.  I think using an opaque token is a good idea.  Using an IP
> address is more fragile, and prone to disclosing private information.

Sure; my use of "(or other halfways unique ID)" is basically about cases
where one needs to control granularity.

E.g. I have two redundant servers in failover: tld1.eduroam.lu and
tld2.eduroam.lu - the ID could then be "tld.eduroam.lu" to indicate that
the packet went through either of the two already and shouldn't come
back later.

Of course even loops that ping-pong between multiple hops would
eventually be detected, as soon as the packet comes back to one of the
servers which used his own mark. So in effect any random value is good
enough, doesn't have to be an IP address. It has to be random enough
though, so that no two hops accidently use the same ID.

>> Perhaps some general guidance or blunt tools like TTLs on stack of
>> proxy-states.
> 
>   FreeRADIUS just has a config option which says "too many".  It's good
> for blunt checks.
> 
>   Having some guidance for detecting proxy loops would be good.

Yes! It's good to hear that Peter's implementation does some magic with
Proxy-State - but it would be even better to write down something like
that for every implementation's benefit. E.g. in FreeRADIUS Proxy-State
is not under config control and it doesn't do such clever comparisons
yet. With a good spec, this could become a config switch
"do_loop_checks" which would do all that Proxy-State magic
automatically, without any fiddling with VSAs and such.

I wonder if Peter feels like putting this into an I-D...?

Greetings,

Stefan Winter


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