Re: Back to work

[Christian Huitema <[e-mail]>]

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