What if a client falsely links two paths using CIDs associated with the same path ID

[yfmascgy]

Stable path ID is helpful to link two paths when CID rotation and NAT rebinding happen at the same time. However, this could also have a downside. There's a chance that a client might falsely apply a CID from an old path to a new one. If this happens, the server may incorrectly treat both paths as identical, despite changes in the CID and the 4-tuple. Should the server opt to retain the congestion window under this assumption, it could inadvertently trigger network congestion, affecting other clients on the new path. Moreover, this vulnerability could be exploited by attackers to deliberately disrupt service for others.

[gloinul]

I don't understand how this happens I think you may have to make event diagram to explain how one would draw the wrong conlcusion. To my understanding you are talking about this case:

So for path 1 the server has announced DCIDs X, Y, Z to the client

A (Client) -> NAT -> B (server): IP_A:port_A ->IP_B:Port_B: DCID:X -> arrive as IP_N:Port_N1 -> IP_B:Port_B DCID:X Then the client decides to cycle DCID IP_A:port_A ->IP_B:Port_B: DCID:Y -> arrive as IP_N:Port_N2 -> IP_B:Port_B DCID:Y This triggers a path challenge by the server on the related reverse path. So if the client correctly associates the reverse path the path challenge is what should indicate to the client that something have occurred that require client to reset its path state. But, as the client's forward path will continue to be correctly acked by server I don't see this is case which likely have significant transport impact. A port rebinding would not affect the client to NAT path conditions. It could possibly affect ECMP etc betwen NAT and server. The server will clearly know that the path changed and if it is larger than just a port change or not.

[yfmascgy]

I don't understand how this happens I think you may have to make event diagram to explain how one would draw the wrong conlcusion. To my understanding you are talking about this case:

So for path 1 the server has announced DCIDs X, Y, Z to the client

A (Client) -> NAT -> B (server): IP_A:port_A ->IP_B:Port_B: DCID:X -> arrive as IP_N:Port_N1 -> IP_B:Port_B DCID:X Then the client decides to cycle DCID IP_A:port_A ->IP_B:Port_B: DCID:Y -> arrive as IP_N:Port_N2 -> IP_B:Port_B DCID:Y This triggers a path challenge by the server on the related reverse path. So if the client correctly associates the reverse path the path challenge is what should indicate to the client that something have occurred that require client to reset its path state. But, as the client's forward path will continue to be correctly acked by server I don't see this is case which likely have significant transport impact. A port rebinding would not affect the client to NAT path conditions. It could possibly affect ECMP etc betwen NAT and server. The server will clearly know that the path changed and if it is larger than just a port change or not.

One possibility is a "bad" client behavior, either intentionally or unintentionally. For example, a client simply opens a new UDP socket on a different interface and uses DCID Y.

I think we should say something like "An endpoint MUST NOT reuse a path ID when sending from more than one local address".

[huitema]

The issue is NAT. Suppose the client has path[1] from address 10.0.0.1:1234, and path[2] from address 10.0.0.2:4567. Suppose that the NAT intercepts a packet send on path[1] and re-sends it from address 10.0.0.2:4567. The CID will still say "path[1]", but the IP addresses will end up being exactly the same.

[mirjak]

The issue is NAT. Suppose the client has path[1] from address 10.0.0.1:1234, and path[2] from address 10.0.0.2:4567. Suppose that the NAT intercepts a packet send on path[1] and re-sends it from address 10.0.0.2:4567. The CID will still say "path[1]", but the IP addresses will end up being exactly the same.

Is that a real problem we have to worry about? Otherwise we could just close the path?

[gloinul]

I think we should say something like "An endpoint MUST NOT reuse a path ID when sending from more than one local address".

Maybe saying this is part of the clarification of what is path. To my understanding if one changes anything in the 5-tuple one is forced to use a new path and a CID that indicates this path.

The issue is NAT. Suppose the client has path[1] from address 10.0.0.1:1234, and path[2] from address 10.0.0.2:4567. Suppose that the NAT intercepts a packet send on path[1] and re-sends it from address 10.0.0.2:4567. The CID will still say "path[1]", but the IP addresses will end up being exactly the same.

So, the NAT would be totally broken if it collapse both these UDP flows to one external port on the same IP address, Thus, I would suggest two flows through one NAT would still get differnet ports, and thus be the receiver be handled as two different paths. Also for the client as they have different destination ports for incoming packet flows they will be treated differently.

[huitema]

I believe these scenarios cannot normally happen. A NAT will normally not give the same mappings to two different paths. When that happens, it is probably some kind of attack: either the client is deliberately trying to pile up multiple paths through the same bottleneck, or an observer on path is re-injecting packets trying to do some damage. In the latter case, the defense would be to remain with the old path and not execute the NAT rebinding.

[kazuho]

Consider the case of a NAT handling only a handful of ports (e.g., MAP-E providing 240 ports to the NAT).

When two paths (A and B) are established through that NAT and the NAT reboots, the server could notice the migration of path A to path B, before noticing that path B has also migrated.

I think what endpoints should do is just ignore overlaps of 4 tuples. The problem would be fixed in a moment, as the purpose of NATs are to provide unique mappings.

[mirjak]

With an explicit path ID this cannot happen, as the same path ID is used after migration. This is exactly the problem that the explicit path ID solves. Closing this issue now. Please reopen or open a new issue if there is still a remaining problem.