Re: [radext] Server identity and RFC7585bis (was: Review of draft-ietf-radext-radiusdtls)

[Alexander Clouter <[e-mail]>]

Hello,

On Wed, 10 Apr 2024, at 08:34, Jan-Frederik Rieckers wrote:
> On 20.03.24 03:55, Jan-Frederik Rieckers wrote:
>>>     ... If a RADIUS/(D)TLS client has multiple connection to a server, 
>>> it MUST NOT decide to mark the whole server as DOWN until all 
>>> connections to it have been marked DOWN.
>>>
>>>    Maybe add a discussion of what, exactly, is a "server". Destination 
>>> IP?  How is this affected by RFC 7585 dynamic DNS lookups?
>> 
>> I've added a TODO for after the IETF.
>
> I've started to write a section to explain how a server is uniquely 
> identified, but I am failing to come up with anything other than 
> destination IP address and destination port.
> Is there some better qualifier?

This makes me twitchy, especially when things are multi-homed...dual stack of course can be seen as a type of multi-homing.

I think it is important that no one knows the relationship between N connections and the final destination.

It may actually be harmful to think like this.

The connection (stream, datagram, carrier pigeon, ...) is to an endpoint that pinky promises to handle a set of requests (eg. for a given realm).  It is an implementation detail of the endpoint on if a given connection maps back to a particular physical bit of tin, a load balancer, an anycast service...or a flock of pigeons.

I would recommend each connection is just treated (and described) as a *route* to the service endpoint.

It seems easier to read if you replace 'connection' with 'route' when reading it out loud. Connections provide *routes* to a server. When there are no routes, the 'server' (ie. 'service endpoint') is then DOWN.

Alternatively, redefine 'RADIUS/(D)TLS server' as the definition at the moment is 'port' orientated so you cannot use destination IP as an anchor.

Personally, I think it is clearer to describe connections using routing characteristics...but that maybe is just me :)

Cheers