2:37 p.m.
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(a)switch.ch>
wrote:
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