Hi Fabian,

Thanks for the review. It seems there was some duplicate code in the new function, specifically relating to rewriteIn/rewriteOut and ttl checks. I have moved CoA processing to the radsrv function itself.
Here is the updated proposed design and a couple of questions - 
  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 an attribute useDynAuthPort of type Boolean to the server config block. If this is set to ON and no port is specified for the server, then default CoA port is used. This is 3799 for UDP/TCP and 2083 for TLS/DTLS. If this is set to OFF, then default authentication port is used i.e 1812 for UDP/TCP and 2083 for TLS/DTLS.
  4. Update radsrv function to enable it to handle CoA/Disconnect requests as well.
    • If no Operator-Name attribute is present in the packet, then the request is ignored. (Should we send a NAK containing Error-Cause attribute having value 402 "Missing Attribute" instead?).
    • If the value of Operator-Name attribute is not valid i.e the first character is not an ascii "1", then the request is ignored. (Should we send a NAK containing Error-Cause attribute having value 407 "Invalid Attribute Value" instead?).
    • If the realm is unknown by the proxy, then a NAK packet containing Error-Cause attribute 502 "Request not Routable" is sent back.
  5. Add an attribute DynAuthResponse of type Boolean to the realm config block. If this is set to ON and no dynAuthServer is configured for the realm, then a NAK will be sent for requests matching the realm. If this is set to OFF, then the request will be silently ignored. This is similar to AccountingResponse attribute.
Please let me know if any changes are required.

Regards,
Harshit

On Thu, Jan 7, 2021 at 1:02 PM Fabian Mauchle <fabian.mauchle@switch.ch> wrote:
Hi Harshit,

On 05.01.21, 13:26, "Harshit Jain" <hjain@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