8:32 a.m.
Hi Harshit,
On 05.01.21, 13:26, "Harshit Jain" <hjain(a)arista.com> wrote:
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.
Points 1,2 and 4 I think are fine. That would have been my approach too.
As for 3. I'm not 100% sure. Please make sure you're not duplicating code from
radsrv (at first glance, most of the processing should be identical; save for the
attribute used for routing).
Also note that the RFC states that:
Where the realm is unknown, the proxy MUST return a NAK packet that
contains an Error-Cause Attribute having value 502 ("Request Not
Routable").
Best 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