8:02 a.m.
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(a)switch.ch>
wrote:
Hi Harshit,
On 20.01.21, 08:14, "Harshit Jain" <hjain(a)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