Security Consideration: Network Address Translation

[ethan-thompson]

Added subsection on Network Address Translation (from RFC 7360 Section 10.5)

[alandekok]

Looks good to me.

[Janfred]

I'm not sure exactly what the problem here is and if the proposed solution is correct.

I'll try to put it the way I understand the problem:

A 10.0.0.1 (RADIUS/DTLS) --> NAT (translated to source 192.0.2.1:12345) --> RADIUS server 203.0.113.1:2083
B 10.0.0.2 (RADIUS/UDP) --> NAT (translated to source 192.0.2.1:12345) --> RADIUS server 203.0.113.1:1812

So now the RADIUS server has two UDP connections to 192.0.2.1:12345, but since the port on the RADIUS server side is different, the NAT can translate the UDP packets from source port 2083 to A and the ones from 1812 to B.

In my view, the problem here is that, if the server mixes those up, the server is at fault for allowing the client list for RADIUS/UDP to merge with the client list for RADIUS/DTLS.
Those two client lists should be separate (at least in terms of IP-Addr/Port).

We cannot force every client behind a NAT to behave this way, because the NAT may be responsible for a huge variety of customer nets, and we can't mandate them to speak to each other.

Example: Carrier-Grade NAT (CGN), Company A has a Dual-Stack internet connection with CGN for v4 and uses legacy-RADIUS, Company B has the same, but uses RADIUS/(D)TLS for their connection. We can't define a standard where Company A would now be forced to migrate to RADIUS/(D)TLS. They have no way of knowing that Company B is using DTLS with the same server. And we shouldn't mandate that the CGN keeps track of all possible connections and makes sure that no source port gets re-used if RADIUS/(D)TLS and RAIDUS/UDP are used with the same server.

[jimdigriz]

Fortunately any kind of NAT is not going to blend this to the same source IP and port (to the same destination IP and port) as it would have no way to figure out what to do with the responses from the server (ie. which client gets them); ignoring the case of the idle timeout ending a flow and starting the new one.

Otherwise I can only see this attack working if a server ignored the destination IP/port. Maybe I am missing something...

[alandekok]

On Oct 4, 2024, at 9:19 AM, Jan-Frederik Rieckers ***@***.***> wrote: +## Network Address Translation + +Network Address Translation (NAT) is fundamentally incompatible with RADIUS/UDP. RADIUS/UDP uses the source IP address to determine the shared secret for the client, and NAT hides many clients behind one source IP address. As a result, RADIUS/UDP clients cannot be located behind a NAT gateway. + +In addition, port reuse on a NAT gateway means that packets from different clients may appear to come from the same source port on the NAT. That is, a RADIUS server may receive a RADIUS/DTLS packet from one source IP/port combination, followed by the reception of a RADIUS/UDP packet from that same source IP/port combination. If this behavior is allowed, then the server would have an inconsistent view of the client’s security profile, allowing an attacker to choose the most insecure method. I'm not sure exactly what the problem here is and if the proposed solution is correct. I'll try to put it the way I understand the problem: A 10.0.0.1 (RADIUS/DTLS) --> NAT (translated to source 192.0.2.1:12345) --> RADIUS server 203.0.113.1:2083 B 10.0.0.2 (RADIUS/UDP) --> NAT (translated to source 192.0.2.1:12345) --> RADIUS server 203.0.113.1:1812 So now the RADIUS server has two UDP connections to 192.0.2.1:12345, but since the port on the RADIUS server side is different, the NAT can translate the UDP packets from source port 2083 to A and the ones from 1812 to B.

Yes. The issue is the network security model.

In my view, the problem here is that, if the server mixes those up, the server is at fault for allowing the client list for RADIUS/UDP to merge with the client list for RADIUS/DTLS. Those two client lists should be separate (at least in terms of IP-Addr/Port).

We don't know what source port will be used by the client. So we can't rely on that. All we know is that one IP is sending us RADIUS/UDP, and RADIUS/TLS. The question is not just what to do, but what we _can_ do in that situation.

We cannot force every client behind a NAT to behave this way, because the NAT may be responsible for a huge variety of customer nets, and we can't mandate them to speak to each other. Example: Carrier-Grade NAT (CGN), Company A has a Dual-Stack internet connection with CGN for v4 and uses legacy-RADIUS, Company B has the same, but uses RADIUS/(D)TLS for their connection. We can't define a standard where Company A would now be forced to migrate to RADIUS/(D)TLS. They have no way of knowing that Company B is using DTLS with the same server. And we shouldn't mandate that the CGN keeps track of all possible connections and makes sure that no source port gets re-used if RADIUS/(D)TLS and RAIDUS/UDP are used with the same server.

Agreed. To a certain extent, there is no technical reason why a server can't accept both RADIUS/UDP and RADIUS/TLS from the same source IP. The packets are clearly distinguishable. The problem we're trying to solve is to stop down-bidding attacks. The simplest approach then is to say that both UDP and TLS may be allowed for compatibility, but that this configuration is NOT RECOMMENDED.