Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Ok take eduroam for example. A change in user authorisation at their home site may result in the generation of a CoA request for the user to be disconnected at the remote site, this would be proxied by the remote sites RADIUS server. That same server may also wish to generate it's own CoA request for the same user, because a local IDS system / traffic analysis probe has detected a bot net etc.. running on their equipment.
Not at the same time. The packets will be ordered. e.g CoA by local server because of botnet, to put them into a quarantine VLAN. Then, a CoA from the remote server, saying that they've just been fired, and they should be disconnected.
If it's the other way around, the local system proxies the disconnect request. There's no need to put them into a quarantine vlan, because they've been disconnected.
The requests *may* rarely happen at about the same time. But that's for the NAS to figure out. It's possible for the NAS to disconnect the user, ACK that, and then send a NAK to the CoA request, because the user has been disconnected.
New identifiers are assigned when forwarding RADIUS packets anyway (i'm guessing), so there's no problem with conflicts between remotely generated and locally generated CoA messages.
You might need logic on the server to handle these corner cases, but it's really not much different than out of order accounting packets, for example.
Quite. So in your implementation, we'll be able to fork off a CoA request on reciept of new accounting data. Or if we need to tie it in with a monitoring server, we can just use the RADIUS client and send a CoA request to the server which will then proxy it on to the correct NAS. I guess proxying behavior is arbitrary and decided on by local configuration. Routing CoA request through proxy chains is pretty much identical as routing standard requests. Arran
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html