On 10/29/2020 3:53 PM, Martin Thomson wrote: > Thanks for clarifying Eric, > > On Fri, Oct 30, 2020, at 09:07, Eric Kinnear wrote: >> Client is fetching a decently large web resource from a server over >> QUIC. NAT rebinds and so the server sees un-padded QUIC packets >> arriving on a different port. > Ah, so I had in my mind that the server would be able to treat the new > address as validated if only the port changed. Then it wouldn't be obligated > to perform address validation or limit its sending. > > This is not what the draft says. The same-port exception only applies to the > congestion controller. > (https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-9.4-2) > > I guess that my implementation will be off-spec in this regard. I have no > intention of splitting the logic so that a port rebinding retains congestion > control and RTT state, but not address validation state. > > The question then is whether this is worth permitting in the spec.
First, let's look at Eric's scenario, a client that is fetching a big load of data, and sending back a steady stream of ACKs. Under these circumstances, NAT rebinding ought to be fairly rare. NATs don't actually "rebind". They create state on first packet from client, and discard it according to some resource management algorithm. In the proposed scenario, the NAT sees that the port is in use and it will take some extra pressure or some software bugs to discard the NAT state. If that happen, incoming packets from the server will be lost until the client sends a packet, the NAT installs some new binding state, and the server decides to send on the new path. Bottom line, we are talking about an error scenario, which we should not try to optimize it too much. My concern is the opposite. Over-optimization of the NAT rebinding scenario creates a significant attack surface. If sending a tiny packet triggers a series of fully padded path challenges, attackers can use that creatively. I would rather **not* optimize the NAT rebinding scenario for performance, and look for robustness instead. On the server side, send short challenges without padding to assess address ownership without opening a DDOS avenue. Worry about path MTU later. That means doing thing differently for a regular migration and for a NAT rebinding. A regular migration happens starts the client sends a full size packet, with a not yet seen CID, and containing a path challenge. Responding to that with a full size response makes sense. But if the server receives a short packet, with an already used CID, and without a path challenge, that's probably a NAT rebinding. Responding with full size challenge packets is counter-productive. -- Christian Huitema
