Re: loop detection, current state

[Stig Venaas <stig.venaas@xxxxxxxxxx>]

Stefan Winter wrote:
> Hello,
>
> some time has passed after the last TF-Mobility meeting. Meanwhile, I've 
> been negotiating what can be done and would like to present the options 
> so far.

I'll comment from radsecproxy perspective.

> - check incoming IP != outgoing IP. This is similar to what we do in 
> RADIUS right now. It only detects a loop if a tight sub-loop (direct 
> bounces) is present within the loop. Can not distinguish between 
> multiple instances on one IP address. This is not doable in a completely 
> dynamic setup right now - there were some suggestions from OSC how to do 
> it in AuthBy DNSROAM or ServerRADSEC clauses, but only if one end of the 
> connection has a list of IPs - which is not the case in a dynamic setup. 
> Implementing this should be rather easy though.
>
> - check cert of incoming != cert of outgoing. Same restriction to tight 
> loops. Can distinguish between multiple instances, assuming that 
> different instances use different certificates. Is not implemented yet, 
> but might be easy to do.

Can be configured to do the two above.

> - introduce attribute with a TTL and count down, if 0 discard. Can 
> detect all kinds of loops. Attribute definition is easy, we have a 
> eduroam-Loop-TTL attribute assigned (within the Dante PEN). Requires 
> arithmetics in proxy hops to decrement attribute. That may be a bit 
> clumsy to implement, and I'm not sure if we get support in mainstream 
> servers.

I like this one and it's easy to implement. It needs additional code but
nothing complicated. It will help solve the problem if at least one
proxy in the loop supports it.

> - count number of Proxy-State attributes, if too high, discard. Proposed 
> by Alan DeKok. Can detect all kinds of loops. Doesn't need any new 
> attribute. Still needs arithmetics in servers. Is not quaranteed to work 
> in all environments. That is because: 1) a proxy may choose not to add 
> its own Proxy-State (thereby not incrementing the count); 2) a proxy may 
> take all Proxy-State attributes out of the packet, store them statefully 
> and re-inject them when the packet comes back. According to Alan these 2 
> things are not as discouraging as they sound: *most* servers add 
> Proxy-State, and *most* leave them untouched.

radsecproxy does not add them, but does leave them untouched. So far
there has been no good reason (AFAICT) for radsecproxy to add any. The
main problem with adding them is increased message size (MTU). This also
is more complex to implement than the TTL. I think this is a bad idea.

Stig

> As you can see from above, none of the options is all-roses. We might go 
> for a combination of them. Let's see.
>
> Greetings,
>
> Stefan Winter