Hi Fabian,

I think you are right. Sending NAK for some realms and not others does sound a bit confusing. I found this in the RFC

If the proxy cannot find a destination for the request or if no
Operator-Name attribute exists in the request, the proxy will return
a CoA-NAK with Error-Cause 502 ("Request Not Routable").

which I think means we should be sending a NAK even if we can't find a dynAuthServer for a realm since we were not able to find a destination for the request. I'll remove the DynAuthResponse config altogether.

Also, I was testing out CoA over TLS and it got me thinking. Can we use the same TCP/TLS session as auth/acct requests to receive CoA requests as well since dynamic authorization only works for authenticated clients? Currently, a server sending CoA request initiates a new TCP/TLS connection but while sending an auth/acct request to the same server, we would have already created a TLS connection so I was thinking can't we just reuse that (This assumes that the server is sending CoA requests on the same TLS connection instead of initiating a new one)? I haven't looked in detail at the changes required (I think it will require adding/modifying protocol specific code for TCP/TLS) but it just got me curious and I wanted to hear your thoughts.

Regards,
Harshit

On Mon, Jan 18, 2021 at 9:41 PM Fabian Mauchle <fabian.mauchle@switch.ch> wrote:
Hi Harshit,

On 13.01.21, 06:24, "Harshit Jain" <hjain@arista.com> wrote:
    > This makes me wonder how CoA Servers will behave if they receive ACK/NAK for some realms they send requests to, but not others (having DynAuthResponse On for some realms, but not others). Haven't looked at the details if the RFC has considered this.
    I went through the RFC but I don't think the RFC has considered this. I couldn't find any mention of how CoA Servers should behave on receiving a NAK.

Indeed. However, the way I read RFC 8559 a proxy must always respond with a NAK if it can't proxy. Doing this for some realms but not others might confuse a home server. So a per realm DynAuthResponse doesn't make sense to me. If any, this might be a global config.

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