Hi Fabian,

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. Currently, radsecproxy simply discards the request because it is not a reply for any outstanding request. I was planning to add support in radsecproxy for receiving CoA requests on an existing TLS connection made to a server.

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.

Any thoughts or feedback will be really helpful.

Thanks and regards,

Harshit

On Mon, Jan 25, 2021 at 12:39 PM Fabian Mauchle <fabian.mauchle@switch.ch> wrote:

Hi Harshit,

On 20.01.21, 08:14, "Harshit Jain" <hjain@arista.com> wrote:

Hi Fabian,

> 1. Would it break the radius protocol?
Regarding your question, I started looking at RFC6614 [https://tools.ietf.org/html/rfc6614] - TLS for Radius (Radsec). It states that -
Due to the use of one single TCP port for all packet types, it is
required that a RADIUS/TLS server signal which types of packets are
supported on a server to a connecting peer. When an unwanted packet of type 'CoA-Request' or 'Disconnect-
Request' is received, a RADIUS/TLS server needs to respond with a
'CoA-NAK' or 'Disconnect-NAK', respectively.
It got me confused. Does this mean that the radius server should use the same TLS connection as auth/acct to send CoA requests instead of creating a new one? Since there is one single port, does this mean there should be a single TCP connection between client and server for all packet types?

Indeed a bit confusing, and I think these RFCs aren't fully aligned. The primary topic here is how to know which messages a server (or proxy) understands. It refers to the UDP case where you can use ICMP port unreachable responses to figure out, if a port (and thus a specific message type) is not supported - which frankly, does not work in real life anyway since almost everybody blocks ICMP on firewalls.

Basically, you can always use multiple TCP connections (as you can always use multiple source ports for UDP, there is no restrictions on that), however the RFC implies that you might send a disconnect-request on the same connection as the original access-request, with reveres client/server roles. Even in a pure client/server setup (without proxy), by the time the radius server wants to send a disconnect-request, the TCP connection might be long gone and it needs to setup a new one (in reverse direction).

Tot that end, I might at least consider the possibility a that CoA requests can arrive on an existing (outgoing) connection.

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