RFC 3576 support

[Alan DeKok]

Arran Cudbard-Bell wrote:
> 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.

  Yes.

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

  That's the theory.  We'll have to see if it works out in practice.

  But yes, the intent is too allow generation AND proxying of CoA.  The
server doesn't currently support generation of authentication or
accountng packets, but CoA is different.

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

  No.  It's horrible and evil.  Hence the refusal to consider it until
now.  NAS vendors have recently started putting support for it into
their products, so it's best to keep up with them.

  i.e. there's a "reverse proxy" check for security:  If you receive a
CoA, then it MAY be forged from someone who wasn't supposed to do it.
So... pretend that it's an Access-Request, look up where you would have
proxied it, and if that destination does not matche the source of the
CoA, then send a CoA-NAK.  Otherwise, process the CoA packet, and
(perhaps) continue proxying it.

  Ugh.

  Alan DeKok.