Hi Harshit,
On 08.02.21, 08:03, "Harshit Jain" hjain@arista.com wrote: I was trying out interoperability testing with Aruba Networks Clearpass which is Aruba's implementation of a RADIUS/Radsec server. I found out that Clearpass sends a CoA request on the same TLS connection which was opened by the client for auth/acct.
Ok, so we definitely have to allow for CoA requests to arrive on server connections.
Here's what I am thinking - Create a dummy client for a server which can send CoA requests on an existing TLS connection. The dummy client will have the same socket/ssl context as well as the resolved IP address as the server. Create a new tlsserverwr thread in tlsclientrd function for listening on replyq of the created dummy client. When reading a reply from the server, if it is a CoA request, then radsrv is called with the new request created with the dummy client otherwise replyh is called. If the connection to the server is reset, then the socket/ssl context and IP address are updated for the dummy client with the new values. Interestingly, freeradius, an open source implementation of RADIUS/Radsec server creates a new TLS connection for sending CoA requests (I guess the ambiguity in RFC has spurred these different implementation choices). So, the above functionality will be guarded behind a config in the server config block. It can be something like DynAuthClient which if set to ON, will enable the above feature otherwise not.
I have to look into this more deeply, but my first thoughts: - Regardless of how we get the CoA requests, there should always be a client definition in the config. - With that, we could refer to a client config in a server config (and with this, enable reception of CoA requests). Dynamically association clients and servers by their name or address might be possible, but for now, I would rather do this explicitly. - The good thing is that the client code already handles multiple connections per client, so for the most part I think we can consider this as just another connection from that client - to do that, the protocol code will need to call `addclient` at some point and then handle the replyqueue (for tls, it will need to create a tlsserverwr thread. - I would put as few knowledge about radius packets in the protocol code as possible. I would do the call to radsrv at the beginning of replyh. - In case of connection resets, I would not try to reuse the existing client but rather close it normally and create a new client.
Best regards, Fabian
-- SWITCH Fabian Mauchle, Network Engineer Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland Phone +41 44 268 15 30, direct +41 44 268 15 39