Re: [radext] draft-cullen-radextra-status-realm-00

[Alan DeKok <[e-mail]>]

On Mar 28, 2023, at 6:34 AM, Terry Burton <tez=[e-mail]> wrote:
> Regarding draft-cullen-radextra-status-realm-00.
> 
> 
> Section 4.2: "When a RADIUS Proxy receives a RADIUS Request packet, it
> checks to see if the Request contains a Server-Identifier attribute
> indicating that it has already processed this packet. If so, it
> discards the packet. If not, it adds its own Server Identifier to the
> packet before forwarding it."
> 
> Should consideration be given to MTU constraints that may be
> encountered by increasing the hop-by-hop packet size?

  It's worth mentioning.  But at 4K max packet sizes and maybe 64 bytes for Server-Identifier, we'll go through a large number of proxies before we run out of packet.

> Section 6: "If the Max-Hop-Count attribute is present and the value is
> zero, the Request MUST NOT be forwarded and an error response SHOULD
> be returned, as appropriate to the request type."
> 
> May be beneficial to define the appropriate behaviour for each request type:

  I'd suggest that Max-Hop-Count MUST NOT appear in any packet other that Status-Realm-Request.  We haven't needed it so far for Access-Request etc.  So I think it's worth leaving those alone.
> Section 7:
> 
> Status-Realm-Response-Code table needs work:
> 
>  - 256 is missing.
>  - Is there an intended difference between 3 and 259?
>  - 260 has multiple definitions.
> 
> Assuming that 5-255 means temporary reachability issue and 260-511
> means "internal error" (may or may not be reachable), i.e. differing
> semantics rather than extension of the same range.

  OK.

> Is the intent to allow automation on the basis of the Status-Realm, or
> only to support administration?

  Ideally both?  But it's difficult to define automation.  i.e. current systems handle fail-over, etc. somewhat automatically.  How would a system leverage Status-Realm in order to improve those decisions?

  Note that Status-Realm is "end to end", while proxy fail-over, etc. is "hop by hop".  So there's a natural boundary here.

> If the former, to avoid ossification it may be worth splitting the
> values into ranges against which one might associate differing
> behaviours, e.g. Temporary path faults (e.g. "definately
> unreachable"), temporary configuration faults (e.g. "unable to
> dynamically look up a realm"), permanent configuration "faults"
> (invalid realm / prohibited realm), unexpected errors. New definitions
> can be added to the appropriate range.

  Sure.  Error-Cause does something similar.

> Are there recommended policy behaviours for "realm unreachable",
> "status unknown" and "reserved"?

  It's worth mentioning.

  Alan DeKok.