Re: [radext] configuration auto-discovery [was: draft-cullen-radextra-status-realm-00]

[Alan DeKok <[e-mail]>]

On Aug 14, 2023, at 11:34 AM, Alexander Clouter <[e-mail]> wrote:
> Say we invent a new type of RADIUS reject...call it 'Access-Unreachable'.

  We already have Protocol-Error.  But the way it works is a bit ugly.

  What would likely be better is a new packet type "unroutable", that could be a reply to any request.  For simplicity, it might be best to require that this is sent only over RADIUS/1.1

  The use of RADIUS/1.1 makes it trivial to tie a response packet to any request packet.  It may also help with per-hop signalling, so that servers know clients are capable of understanding this packet.

> Not important here and now, as it is detail, but this packet could have a 'scope' to communicate if this is just the realm the Access-Request was for or "all realms" or something in between.

  The response packet would need an Error-Cause attribute with new values.  Perhaps:

* temporary proxy failure for this destination (don't use "realm", as people proxy on different things)

* permanent proxy failure for this destination

> The tricky part would be figuring out when to unblock traffic to the upstream by realm. This probably would be a good fit for regularly polling Status-Realm with the TTL set to one.

  Do what we do now:  leave all of that to the client.  :)

  The client can at some later time send a probe, or it can simply start retrying packets after a period of time.

> This would be an optimisation effort. The system would have to discover unreachable before it can start reporting unreachable downstream.

  Yes.

  The "request unroutable" reply would essentially be treated the same way as packets which were sent on a TCP connection that was closed.  The packets would get redirected to another destination.

  The only difference is that the "request unroutable" reply is not a failure of the connection, it is a failure of the destination.  So the client wouldn't retry another connection to that server.  Instead, it would retry to a different server.  I suspect that there isn't a large difference in logic.

  Alan DeKok.