Hi Fabian,

I looked at RFC8559 [https://tools.ietf.org/html/rfc8559] and have done a basic implementation following it. Before proceeding further, I wanted to run my design and thoughts with you.

Here is a quick rundown of the RFC.
RFC8559 specifies 2 additional radius attributes - Operator-Name and Operator-NAS-Identifier. Operator-Name contains the realm which is used by intermediate proxies to determine where to forward the received CoA request. It works the same way as the User-Name attribute does for authentication and accounting requests, just in reverse. Proxies that receive CoA requests look up the realm in the Operator-Name attribute in a logical "realm routing table" and then the packet is sent to the next-hop server configured for that realm.
Operator-NAS-Identifier is used by the end CoA server and the proxy must pass it unchanged.

Here is an overview of my proposed design -
  1. Add an attribute dynAuthServer to the realm config block. This attribute specifies the next-hop server to forward the CoA request to corresponding to a realm, just like server and accountingServer specify the next-hop server to use for authentication and accounting requests respectively.
  2. Any device which sends a CoA/Disconnect request must be configured as a client in the config file. Similarly, any device to which CoA requests are to be proxied to must be configured as a server in the config file.
  3. Add a function radsrvcoa which will be called from radsrv to specifically handle CoA/Disconnect requests. radsrvcoa will fetch the realm object corresponding to the realm extracted from Operator-Name attribute present in the packet and then proceed to check whether the realm object has a dynAuthServer configured or not. If it is, then the request is forwarded to it otherwise the request is discarded.
  4. There are no interesting changes to be made to the reply flow.
Please let me know if there's something I missed or if any changes are necessary. If everything seems good, I'll do some finishing touches to the code and create a pull request on github.

Thanks,
Harshit

On Fri, Nov 27, 2020 at 1:40 PM Fabian Mauchle <fabian.mauchle@switch.ch> wrote:
Hi Harshit,

On 23.11.20, 08:03, "Harshit Jain" <hjain@arista.com> wrote:
    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?

Yes exactly. I mostly have the use-case for federated WPA-enterprise wifi access in mind (as that's what radsecproxy was designed for). There, the presence of NAS-IP-Address attribute is not guaranteed, and even if it is present, you might often see some local (RFC1918) IP address in there.

However, I noticed that the RFC5176 got an update with RFC 8559 [https://tools.ietf.org/html/rfc5176] which tackles exactly this issue. Haven't looked at it in detail thought.

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