Hi Harshit, On 23.11.20, 08:03, "Harshit Jain" <hjain(a)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

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

Hi Harshit, On 08.01.21, 14:37, "Harshit Jain" <hjain(a)arista.com> wrote: 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. This sounds good as a description, but It's hard to do a detailed review without actually seeing the code. 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. 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. BR, 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

Hi Harshit, On 13.01.21, 06:24, "Harshit Jain" <hjain(a)arista.com> wrote: 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

Hi Harshit, On 19.01.21, 09:18, "Harshit Jain" <hjain(a)arista.com> wrote: 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. I have come across a similar idea, accepting auth/acct requests on an outgoing TCP/TLS connection, but I haven't looked any deeper into this. To main questions arise: 1. Would it break the radius protocol? 2. If not, it still might be hard to do it in radsecproxy as the request and response data flow is completely different. This would require very careful design to make it thread safe. 3. If it works, between two radsecproxy is one thing, but what standardization would be required for other software to implement it too. All in all, it's hard to justify the effort (except for just 'I want to know if it's possible'); having a few more TCP connections doesn't really cost much. BR, 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

Hi Harshit, On 20.01.21, 08:14, "Harshit Jain" <hjain(a)arista.com> wrote: Hi Fabian, Regarding your question, I started looking at RFC6614 [https://tools.ietf.org/html/rfc6614] - TLS for Radius (Radsec). It states that - Due to the use of one single TCP port for all packet types, it is required that a RADIUS/TLS server signal which types of packets are supported on a server to a connecting peer. When an unwanted packet of type 'CoA-Request' or 'Disconnect- Request' is received, a RADIUS/TLS server needs to respond with a 'CoA-NAK' or 'Disconnect-NAK', respectively. It got me confused. Does this mean that the radius server should use the same TLS connection as auth/acct to send CoA requests instead of creating a new one? Since there is one single port, does this mean there should be a single TCP connection between client and server for all packet types? Indeed a bit confusing, and I think these RFCs aren't fully aligned. The primary topic here is how to know which messages a server (or proxy) understands. It refers to the UDP case where you can use ICMP port unreachable responses to figure out, if a port (and thus a specific message type) is not supported - which frankly, does not work in real life anyway since almost everybody blocks ICMP on firewalls. Basically, you can always use multiple TCP connections (as you can always use multiple source ports for UDP, there is no restrictions on that), however the RFC implies that you might send a disconnect-request on the same connection as the original access-request, with reveres client/server roles. Even in a pure client/server setup (without proxy), by the time the radius server wants to send a disconnect-request, the TCP connection might be long gone and it needs to setup a new one (in reverse direction). Tot that end, I might at least consider the possibility a that CoA requests can arrive on an existing (outgoing) connection. 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

Hi Harshit, On 08.02.21, 08:03, "Harshit Jain" <hjain(a)arista.com> wrote: I was trying out interoperability testing with Aruba Networks Clearpass which is Aruba's implementation of a RADIUS/Radsec server. I found out that Clearpass sends a CoA request on the same TLS connection which was opened by the client for auth/acct. Ok, so we definitely have to allow for CoA requests to arrive on server connections. Here's what I am thinking - Create a dummy client for a server which can send CoA requests on an existing TLS connection. The dummy client will have the same socket/ssl context as well as the resolved IP address as the server. Create a new tlsserverwr thread in tlsclientrd function for listening on replyq of the created dummy client. When reading a reply from the server, if it is a CoA request, then radsrv is called with the new request created with the dummy client otherwise replyh is called. If the connection to the server is reset, then the socket/ssl context and IP address are updated for the dummy client with the new values. Interestingly, freeradius, an open source implementation of RADIUS/Radsec server creates a new TLS connection for sending CoA requests (I guess the ambiguity in RFC has spurred these different implementation choices). So, the above functionality will be guarded behind a config in the server config block. It can be something like DynAuthClient which if set to ON, will enable the above feature otherwise not. I have to look into this more deeply, but my first thoughts: - Regardless of how we get the CoA requests, there should always be a client definition in the config. - With that, we could refer to a client config in a server config (and with this, enable reception of CoA requests). Dynamically association clients and servers by their name or address might be possible, but for now, I would rather do this explicitly. - The good thing is that the client code already handles multiple connections per client, so for the most part I think we can consider this as just another connection from that client - to do that, the protocol code will need to call `addclient` at some point and then handle the replyqueue (for tls, it will need to create a tlsserverwr thread. - I would put as few knowledge about radius packets in the protocol code as possible. I would do the call to radsrv at the beginning of replyh. - In case of connection resets, I would not try to reuse the existing client but rather close it normally and create a new client. 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

Hi Fabian, client definition in the config. One thing that came to mind is with there being a client config regardless of where we get the CoA request, we will end up listening for requests from that client on a new socket even if we only want to receive CoA requests over the same TLS connection from the server. I am not sure if this is really an issue but I wanted to hear your thoughts on this. client but rather close it normally and create a new client. This will mean also closing the thread writing replies to this client (tlsserverwr for example) along with the cleanup and creating that thread again with the new client passed as an argument. Do we want to do this for every connection reset? Regards, Harshit On Thu, Feb 11, 2021 at 3:16 PM Harshit Jain <hjain(a)arista.com> wrote: > Hi Fabian, > > > - With that, we could refer to a client config in a server config (and > with this, enable reception of CoA requests). Dynamically association > clients and servers by their name or address might be possible, but for > now, I would rather do this explicitly. > > What I understand is, the client config referenced in the server config to > enable reception of CoA requests should have the same protocol type as the > server. Also, the created client (using addclient on referenced client > config) must have its socket, SSL object and address set to the same values > as that of the server because ultimately when radsecproxy will receive a > CoA response, it will have to send it out on the same TCP/TLS connection on > which it received the CoA request. > So, the referenced client config will be used to create the client and > store the created client in it's client_list but the created client's > network IO attributes will be copied over from the server. But with this, > we might have inconsistent logging if, say, the CoA request's source IP is > different from the referenced client config's host IP. What I was thinking > is that we can get the server's IP from the connected socket and use that > to find a client config. Any thoughts on this? > > Thanks and regards, > Harshit > > On Thu, Feb 11, 2021 at 1:06 PM Fabian Mauchle <fabian.mauchle(a)switch.ch> > wrote: > >> Hi Harshit, >> >> On 08.02.21, 08:03, "Harshit Jain" <hjain(a)arista.com> wrote: >> I was trying out interoperability testing with Aruba Networks >> Clearpass which is Aruba's implementation of a RADIUS/Radsec server. I >> found out that Clearpass sends a CoA request on the same TLS connection >> which was opened by the client for auth/acct. >> >> Ok, so we definitely have to allow for CoA requests to arrive on server >> connections. >> >> Here's what I am thinking - >> Create a dummy client for a server which can send CoA requests on an >> existing TLS connection. The dummy client will have the >> same socket/ssl context as well as the resolved IP address as the >> server. Create a new >> tlsserverwr thread in tlsclientrd function for listening on replyq of >> the created dummy client. When reading a reply from the server, if it is a >> CoA request, then >> radsrv is called with the new request created with the dummy client >> otherwise >> replyh is called. If the connection to the server is reset, then the >> socket/ssl context and IP address are updated for the dummy client with the >> new values. >> Interestingly, freeradius, an open source implementation of >> RADIUS/Radsec server >> creates a new TLS connection for sending CoA requests (I guess the >> ambiguity in RFC has spurred these different implementation choices). So, >> the above functionality will be guarded behind a >> config in the server config block. It can be something like >> DynAuthClient which if set to ON, will enable the above feature >> otherwise not. >> >> I have to look into this more deeply, but my first thoughts: >>> client definition in the config. >> - With that, we could refer to a client config in a server config (and >> with this, enable reception of CoA requests). Dynamically association >> clients and servers by their name or address might be possible, but for >> now, I would rather do this explicitly. >> - The good thing is that the client code already handles multiple >> connections per client, so for the most part I think we can consider this >> as just another connection from that client >> - to do that, the protocol code will need to call `addclient` at some >> point and then handle the replyqueue (for tls, it will need to create a >> tlsserverwr thread. >> - I would put as few knowledge about radius packets in the protocol code >> as possible. I would do the call to radsrv at the beginning of replyh. >>> client but rather close it normally and create a new client. >> >> 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 >> >> >> >>