8:14 a.m.
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(a)switch.ch>
wrote:
> Hi Harshit,
>
> On 19.01.21, 09:18, "Harshit Jain" <hjain(a)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(a)lists.nordu.net
> To unsubscribe send an email to radsecproxy-leave(a)lists.nordu.net
>