Re: RFC 3576 support



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





This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.