Re: [radext] Server identity and RFC7585bis

[Fabian Mauchle <[e-mail]>]

On 12.04.2024 10:35, Jan-Frederik Rieckers wrote:> We should make sure 
why we need to identify a client and a server.

Reading the many comments, I think this is the most important question 
to answer first.

>  From my perspective, identifying a server has two reasons:
> 1. Make sure that redundancy mechanisms work (as described above)

In my view, this part is really easy, as it is local to the client. A 
client might open multiple connections to (what it considers) A server 
(e.g. to mitigate the id-space limitation pre-RADIUS/1.1), and would 
only start sending requests to another server if all connections to the 
active one are dead.
But in that case, the client has perfect knowledge which connections 
represent a single server in its view.

> 2. Prevent opening unnecessarily many open connections to a server with 
> dynamic discovery, just because the client is not sure if it's the same, 
> while keeping deployment options open (i.e. different policies hidden 
> behind different Server Names, but with the same certificate)

I think this would be the main use-case - if done at all. As Alex 
pointed out, TCP connections aren't that expensive (not computationally 
at least, but they occupy file descriptors, and I have seen servers 
running out of those).
But if it is done, a client needs to figure out if a new connection 
should be opened, or if it can reuse an existing one (or an existing set 
of connections, see above) - meaning that to routes (to different NAI 
realms) use the same connection.

I can think of two scenarios:
1. Configuration by an admin. Then again it's no issue: two connections 
are the same because the admin said so.
2. Dynamic discovery: which parts of the discovery process needs to 
match for the result to be considered the 'same' server such that it can 
share a (set of) connection(s).
At first glance, this could be the DNS name and port in the SRV record, 
plus maybe the IP address the DNS name resolves to (i.e. reuse an 
existing connection only if its IP address is in the set the DNS name 
resolves to).

All of this is not to be confused with multiple routes to different NAI 
realms - a single route can use multiple connections, and many routes 
can share a single connection (or any combination of the above)

> I'm not entirely sure, why we need to identify a specific client in the 
> way the specification in RFC6614 was written
> (i.e. "What is the problem we solve by having a way to identify a 
> client" or more specifically "what are the consequences of identifying 
> that two connections come from the same client")

TLS-PSK might be a good starting point: identify a client to provide 
peer authorisation and different policies.
- with UDP and TCP it was the IP address (and maybe port)
- with TLS-PSK it's the PSK Identity
- with TLS Certificates, it could be any identifying element in the 
certificate. Maybe the CN or some subjectAltName - there's virtually no 
limit.

But in the end, its only to apply the desired policy (and maybe 
logging). Any incoming connection needs to be treated separately anyway 
(to send responses, handle duplicates etc.), and it's perfectly fine for 
two separate clients having the same identity (thought it's probably 
still advisable to provide distinguishable identities, if only for 
logging/auditing purposes).


-- 
Fabian Mauchle
Network
NOC:   [phone]
Direct:[phone]

Switch
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland