Hi Fabian,

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

What I understand is, the client config referenced in the server config to enable reception of CoA requests should have the same protocol type as the server. Also, the created client (using addclient on referenced client config) must have its socket, SSL object and address set to the same values as that of the server because ultimately when radsecproxy will receive a CoA response, it will have to send it out on the same TCP/TLS connection on which it received the CoA request.

So, the referenced client config will be used to create the client and store the created client in it's client_list but the created client's network IO attributes will be copied over from the server. But with this, we might have inconsistent logging if, say, the CoA request's source IP is different from the referenced client config's host IP. What I was thinking is that we can get the server's IP from the connected socket and use that to find a client config. Any thoughts on this?

Thanks and regards,

Harshit

On Thu, Feb 11, 2021 at 1:06 PM Fabian Mauchle <fabian.mauchle@switch.ch> wrote:

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