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?

Thanks,
Harshit

On Tue, Jan 19, 2021 at 4:04 PM Fabian Mauchle <fabian.mauchle@switch.ch> wrote:
Hi Harshit,

On 19.01.21, 09:18, "Harshit Jain" <hjain@arista.com> wrote:
    Also, I was testing out CoA over TLS and it got me thinking. Can we use the same TCP/TLS session as auth/acct requests to receive CoA requests as well since dynamic authorization only works for authenticated clients? Currently, a server sending CoA request initiates a new TCP/TLS connection but while sending an auth/acct request to the same server, we would have already created a TLS connection so I was thinking can't we just reuse that (This assumes that the server is sending CoA requests on the same TLS connection instead of initiating a new one)? I haven't looked in detail at the changes required (I think it will require adding/modifying protocol specific code for TCP/TLS) but it just got me curious and I wanted to hear your thoughts.

I have come across a similar idea, accepting auth/acct requests on an outgoing TCP/TLS connection, but I haven't looked any deeper into this. To main questions arise:
1. Would it break the radius protocol?
2. If not, it still might be hard to do it in radsecproxy as the request and response data flow is completely different. This would require very careful design to make it thread safe.
3. If it works, between two radsecproxy is one thing, but what standardization would be required for other software to implement it too.

All in all, it's hard to justify the effort (except for just 'I want to know if it's possible'); having a few more TCP connections doesn't really cost much.

BR,
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



_______________________________________________
radsecproxy mailing list -- radsecproxy@lists.nordu.net
To unsubscribe send an email to radsecproxy-leave@lists.nordu.net