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

[Alan DeKok <[e-mail]>]

On Jan 1, 2023, at 12:53 PM, Alexander Clouter <[e-mail]> wrote:
> Section 4.2:
> 
> "The value is *deprecated* each time a RADIUS message...", did you mean 'decremented'?

  Yes.

> Is it useful to add to this section that by originating requests with 'Max-Hop-Count = 1' you can hint that you wish to prevent proxying upstream? Similarly the reverse in the IGP/EGP routing protocols world the TTL of the IP packet is set to 255 so the next hop router knows the request came from it's immediate neighbor.

  I think so, yes.

> Section 7:
> 
> "Hop-Count is of type 'integer'. Valid values are 0=255...", should this be '0-255'?

  Yes.

> Also, what are the consequences of a originating system sending out a request with 'Max-Hop-Count = 0'? Should the next hop just reject the request immediately? Asking as this is the sort of thing we are going to see during the excitement of interop.

  I think that the receiving system should send a reply.  Perhaps the rest of the text can be updated to say that "0" means "don't proxy", and "1..N" means "proxy across 1..N intermediate proxies between visited and home server".

> Section 8:
> 
> "RADIUS Servers SHOULD NOT add Server-Information attributes to Response messages when processing Responses.", it is unclear why you would not want to have Server-Information attributes added to the responses on the way back? The routing may be asymmetrical (https://paris-traceroute.net/) and would be useful to see this.

  The routing can't be asymmetrical.  Each reply *must* go back down the exact inverse path of the request.

  If a client retransmits a request, perhaps it could be useful to add that information?  i.e. "tried server A, it failed, tried server B, it failed".  etc.

> "This attribute is also included as a sub-attribute within the Status-Realm-Response-Code attribute...", okay, my brain just exploded with the TLVs within TLVs within TLVs...and it is unclear if Server-Information must only now be inside a Status-Realm-Response-Code at all times? I am probably being stupid, but I cannot piece together how Server-Information is added *inside* of Status-Realm-Response-Code unless some constraints are highlighted guarding that the attribute ID for Server-Information is nothing like the sub-attribute IDs of Status-Realm-Response-Code. This section is screaming out for some ASCIIart.

  That makes sense.  Even a simple hierarchical list would be useful.

> 'Proxy-{Information,Identifier}' appears from nowhere. Did you mean 'Server-{Information,Identifier}'? I am guessing this terminology was used in an earlier revision?

  Yes.

> I have no idea where 'Server-Operator' comes from? I know it is a 'string' and works like 'Operator-Name', but I have no idea how it should be packaged into the 'Server-Information' TLV? Should this be a 'Type = 4' or something?

  Not sure.  We'll take a look.

> It takes some mental gymnastics to understand and see the purpose of 'Hop-Count'. There is a hint tucked away into Section 6 of 'traceroute-like', so it might be worth showing an example of after a full proxied authentication round trip the contents of those Server-Information attributes that have been added and how that information is extractable to build a map of the RADIUS Proxy Fabric involved.

  Yes.

> Finally I would love to see a timestamp (at least millisecond resolution) sub-attribute be packed into 'Server-Information' so we can find the slow hops and an optional 'retry' sub-attribute counter so we can discover the lossy hops.

  I agree.

  Alan DeKok.