Hi Fabian,

In our use case, we will be running radsecproxy on the same hardware as the client so we will essentially only have a single client to proxy the requests to. But we were thinking that if we are gonna implement it anyway, we might as well do it in a way that is flexible and extensible and it would just be super if our implementation is eventually merged in the official radsecproxy repository.

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?

Thanks and regards, Harshit Jain

On Fri, Nov 20, 2020 at 6:34 PM Fabian Mauchle fabian.mauchle@switch.ch wrote:

Hi Harshit,

On 19.11.20, 11:17, "Harshit Jain" hjain@arista.com wrote: I was looking to add support for Dynamic Authorization Messages - Change of Authority (CoA) and Disconnect messages - to radsecproxy. RFC for this can be found here - https://tools.ietf.org/html/rfc5176 .

Before diving headfirst, I wanted to ask if it is already on the

roadmap or if there has been a design discussion that I can read up on.

There was a brief discussion of this on this list, but quite some time ago. I think the conclusion was that although the RFC permits proxying of these messages, there was no concise method to find out where to proxy those messages, as this is the reverse direction from typical username based realm routing.

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

---

radsecproxy mailing list -- radsecproxy@lists.nordu.net To unsubscribe send an email to radsecproxy-leave@lists.nordu.net

Hi Fabian,

I looked at RFC8559 [https://tools.ietf.org/html/rfc8559] and have done a basic implementation following it. Before proceeding further, I wanted to run my design and thoughts with you.

Here is a quick rundown of the RFC. RFC8559 specifies 2 additional radius attributes - Operator-Name and Operator-NAS-Identifier. Operator-Name contains the realm which is used by intermediate proxies to determine where to forward the received CoA request. It works the same way as the User-Name attribute does for authentication and accounting requests, just in reverse. Proxies that receive CoA requests look up the realm in the Operator-Name attribute in a logical "realm routing table" and then the packet is sent to the next-hop server configured for that realm. Operator-NAS-Identifier is used by the end CoA server and the proxy must pass it unchanged.

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.

Please let me know if there's something I missed or if any changes are necessary. If everything seems good, I'll do some finishing touches to the code and create a pull request on github.

Thanks, Harshit

On Fri, Nov 27, 2020 at 1:40 PM Fabian Mauchle fabian.mauchle@switch.ch wrote:

Hi Harshit,

On 23.11.20, 08:03, "Harshit Jain" hjain@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 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

Hi Fabian,

*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.

I have created a pull request on github for the changes - https://github.com/radsecproxy/radsecproxy/pull/77

Regards,

Harshit

On Tue, Jan 12, 2021 at 1:13 PM Fabian Mauchle fabian.mauchle@switch.ch wrote:

Hi Harshit,

On 08.01.21, 14:37, "Harshit Jain" hjain@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 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

Hi Fabian,

1. Would it break the radius protocol?

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?

Thanks,

Harshit

On Tue, Jan 19, 2021 at 4:04 PM Fabian Mauchle fabian.mauchle@switch.ch wrote:

Hi Harshit,

On 19.01.21, 09:18, "Harshit Jain" hjain@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

---

radsecproxy mailing list -- radsecproxy@lists.nordu.net To unsubscribe send an email to radsecproxy-leave@lists.nordu.net

Hi Fabian,

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. Currently, radsecproxy simply discards the request because it is *not a reply* for any outstanding request. I was planning to add support in radsecproxy for receiving CoA requests on an existing TLS connection made to a server.

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.

Any thoughts or feedback will be really helpful.

Thanks and regards, Harshit

On Mon, Jan 25, 2021 at 12:39 PM Fabian Mauchle fabian.mauchle@switch.ch wrote:

Hi Harshit,

On 20.01.21, 08:14, "Harshit Jain" hjain@arista.com wrote:

Hi Fabian,


> 1. Would it break the radius protocol?
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 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@switch.ch wrote:

Hi Harshit,

On 08.02.21, 08:03, "Harshit Jain" hjain@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 Harshit,

Apologies for the delay.

On 01.04.21, 09:19, "Harshit Jain" hjain@arista.com wrote:

Hi Fabian,

> - Regardless of how we get the CoA requests, there should always be a 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.

I don’t see this as an issue. There is anyway only one socket in the listening state (per port), not for every defined client. That’s the same as for regular clients: you can define as many as you want, there will only be config objects. New sockets with associated threads are only started when there is an actual incoming connection. Small detail: UDP clients really only have one single thread reading all incoming UDP packets.

> - In case of connection resets, I would not try to reuse the existing 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?

Yes. This is what already happens for regular incoming TLS connections.

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