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@switch.ch wrote:
Hi Harshit,
On 19.11.20, 11:17, "Harshit Jain" hjain@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 theroadmap 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@lists.nordu.net To unsubscribe send an email to radsecproxy-leave@lists.nordu.net