Hi Fabian,
In our use case, we will be running radsecproxy on the same hardware as the
client so we will essentially only have a single client to proxy the
requests to. But we were thinking that if we are gonna implement it anyway,
we might as well do it in a way that is flexible and extensible and it
would just be super if our implementation is eventually merged in the
official radsecproxy repository.
Regarding proxying of CoA/Disconnect messages, I was thinking we could look
at NAS-IP-Address/NAS-IPv6-Address present in the CoA/Disconnect request to
determine where to proxy the request. I am not entirely sure if this will
work for clients/servers configured with a domain name (FQDN) though as it
might get resolved to multiple IP addresses. Were you referring to this
when you mentioned that there was no concise way to determine where to
proxy the requests? Can you elaborate a little on this?
Thanks and regards,
Harshit Jain
On Fri, Nov 20, 2020 at 6:34 PM Fabian Mauchle <fabian.mauchle(a)switch.ch>
wrote:
Hi Harshit,
On 19.11.20, 11:17, "Harshit Jain" <hjain(a)arista.com> wrote:
I was looking to add support for Dynamic Authorization Messages -
Change of Authority (CoA) and Disconnect messages - to radsecproxy. RFC for
this can be found here -
https://tools.ietf.org/html/rfc5176
.
Before diving headfirst, I wanted to ask if it is already on the
roadmap or if there has been a design discussion that I can read up on.
There was a brief discussion of this on this list, but quite some time ago.
I think the conclusion was that although the RFC permits proxying of these
messages, there was no concise method to find out where to proxy those
messages, as this is the reverse direction from typical username based
realm routing.
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
_______________________________________________
radsecproxy mailing list -- radsecproxy(a)lists.nordu.net
To unsubscribe send an email to radsecproxy-leave(a)lists.nordu.net