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

[Alexander Clouter <[e-mail]>]

On Tue, 25 Oct 2022, at 01:18, Margaret Cullen wrote:
> We have submitted a draft that defines a Status-Realm mechanism, offering  “ping-like” and “traceroute-like” functionality for multi-hop RADIUS proxy fabrics.  It also contains mechanism for the mitigation and prevention of proxy forwarding loops.  The draft can be found here:
> 
> https://datatracker.ietf.org/doc/draft-cullen-radextra-status-realm/

Section 4.2:

"The value is *deprecated* each time a RADIUS message...", did you mean 'decremented'?

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.

Section 7:

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

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.

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.

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

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

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?

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.

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.

Thanks