Re: [radext] Server identity and RFC7585bis

[Alan DeKok <[e-mail]>]

On Apr 12, 2024, at 4:35 AM, Jan-Frederik Rieckers <[e-mail]> wrote:
> The purpose of defining a way to check if it is the same server is to make sure that we mark broken servers as down and don't use them in our load-balancing any more.

  I think we have to more clearly separate the concepts of routing from identity.

  An admin running a RADIUS proxy typically can group multiple _routes_ into one _identity_.   That configuration is a statement that a set of destination IP/ports are all the "same" RADIUS server.

  Historically, there is some out of band process by which an admin determines that this set of destination IP/posts are all the "same" server.  That process is largely manual, and is done by having admins communicate with each other.

  RFC 7585 automated that process a little bit.  A particular realm can put a routing statement into DNS.  RADIUS clients or proxies can look up a DNS record for a particular realm, and find route(s) to the RADIUS server.

  We also have issues of what happens when the next hop is another proxy, and not a server which is authoritative for a realm.  Similarly, one system could perhaps be authoritative for multiple realms.  The issues are similar in both cases.

> Nowhere does it say "A server certificate MUST NOT be used in more than one single server"

  I agree that isn't a useful restriction.  It's certainly reasonable to have a "gold" VM, and clone it to multiple RADIUS servers.

  But it's also reasonable to issue multiple _different_ certs which have the same RFC 7585 NAIRealm field.  I interpret that statement as all of those servers are interchangeable.  That all (or any) of them can be used to reach that realm.

> And just because the server presented the same certificate (with maybe multiple SANs) it doesn't mean that all connections to the server are the same.

  I think that's where we disagree, perhaps just on terminology.

  For me, there can be multiple _routes_ to a realm.  The routes can go up or down dynamically.  The routes can use UDP, IPSec, or (D)TLS.  But those routes all terminate at the same _identity_: a server which is authoritative for a realm.

  Those routes are pretty much different by definition.  They can use different transports, IPs, or even just different TLS connections.  Each router or connection has to have its own handling for idle timeouts, lifetimes, etc.

  An administrator can put multiple routes into a "pool" of routes.  When the proxy sends a packet, it selects a particular route, and sends the packet over that route.

  Routes can be added and deleted dynamically.  If the route uses TCP or TLS, one configured route may end up using multiple connections.  And the connections can be added and deleted dynamically.

> If we go down the path with SNI, then I could have a connection that used eduroam-federation.example.com for one connection and openroaming-federation.example.com for another. The certificate may be valid for both DNS names, but the policy is different on the connections.

  I'm not clear what that means.

  I do agree that it's possible to send packets for multiple realms down one connection.  The question for me is how do we determine that this particular system accepts packets for multiple realms.  Historically, that has been done manually by the administrator.

> If we would say "Just compare the certificate" then the client would send OpenRoaming packets to the eduroam federation, or the other way round, depending on which connection was there first.

  I think 

> If we completely ignore the IP/port part, then a client would mark the whole redundancy cluster as down, just because they opened up a connection to one of them and they stopped answering.

  I don't think so.  Each route / connection has to operate independently.  There really isn't another choice.  I think such bad behaviour should be forbidden.

  i.e. when there is pool of routes / connections, the RADIUS client runs liveliness checks _independently_ for each one.  Only when all routes / connections are "down" is the destination realm declared "down".

> And, the other way round, if there were other connection open to other members of the cluster, it would keep trying the broken server in the cluster, because there are still open connections to "this server", so the software can't mark the server as down.

  It should try using the other connections.  They might work.  If they don't work, the proxy will gradually discover that all connections are broken.  And then mark the realm as down.

> We should make sure why we need to identify a client and a server.
> 
> From my perspective, identifying a server has two reasons:
> 1. Make sure that redundancy mechanisms work (as described above)

  RRC 2865 says:

	Retry and fallback algorithms are the topic of current
        research and are not specified in detail in this document.

  Perhaps we need to finally define that, along with load-balancing.

  I'm not sure that this document is the place to do that work.  I would just update this document to say that each connection has to be operated independently of other connections.

> 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)

  If the client is "not sure if it's the same", then we need to describe how the client makes that decision.

  As for the issue of different polices hidden behind different server names, I'm not overly worried about that.  We do this today with proxies in eduroam.  The eduroam proxies may present a certificate, but then forward the packets to different destination realms, each with different policies.  The client has no idea that this is happening.

  The problem for me is determining how to define the routes.  "realm A is at server B".  That mapping should ideally be M-N, not 1-1.

  i..e. one realm can have multiple servers.  One server can handle multiple realms, etc.

  Back to SNI, it's really only useful for RFC 7585: I asked example.com where the RADIUS server is, and it told me it's at this IP.  So when I connect to that IP, it better produce a certificate for example.com.

  I think it's fine for that server to support multiple realms.  It can then present different certs depending on the SNI presented by the client.

  RFC 7585 doesn't provide for that server to accept multiple realms on that connection.  We do need to address that issue.  But "manual admin configuration" has worked until now...

  Alan DeKok.