Re: Back to work

[Eric Kinnear <[e-mail]>]

I was originally shying a bit away from that option, Christian, but the more I think about it the less painful it seems: back out the padding requirement, add in a note that “after a new path has been validated, endpoints can/should/must do PMTUD to validate the MTU on that path”. 

The natural responses that an endpoint goes through during path validation (or abrupt migration) leave it with either a working or failing path when trying to migrate; this was always the case and is no more or less the case due to MTU concerns. 

Alternately, you also note that we might want to avoid forcing the server specifically to send large packets — in my opinion, that would be another equally valid way to tackle this: require the padding only for PATH_CHALLENGES sent from the client and any PATH_RESPONSE to a padded challenge.
That’s really nice in a number of ways, especially for the MOTS cases where I can make the server think that every new packet is on a new path, etc.

So… lots of words to say: I very much agree with what you’re saying. :) 

It seems like these would be good options to use if we think that there’s something we don’t like about the 3x limit (perhaps how it interacts with NAT rebinding). Otherwise, the 3x limit is nice and general.

How worried are we about the 3x limit?

Thanks,
Eric


> On Oct 28, 2020, at 5:41 PM, Christian Huitema <[e-mail]> wrote:
> 
> 
> On 10/28/2020 5:17 PM, Jana Iyengar wrote:
>> I like the universality of the 3x limit. The reasoning applies broadly
>> and there's no reason to separately reason about how a server responds
>> to new addresses, be it at the start of a connection or
>> mid-connection. Overall, I have a few minor suggestions to make, but
>> I'm happy with the way the PR is headed.
> 
> 
> I think that we can devise proper solutions for "organized migrations",
> such as requiring both receipt and acknowledgement of a long enough
> packet before validating a path. I am not going to belabor that. But NAT
> traversal is a can of worms, and some of the norms are going to bite us.
> 
> I order to support NAT traversal, we request servers to take action if
> they see a packet arriving from a new address of the client. This opens
> a huge hole through which enterprising MOTS or "specially crafted
> clients" can harass servers. We have an OK defense: send a challenge to
> both old and new IP to force "proof of address ownership". That defense
> is OK because it uses minimal length packets, and thus does not cause
> too much amplification. I think we should leave it at that, and not
> force the server to send large packets. There is a need to then validate
> that the path can carry traffic, which will happen naturally when the
> server tries to send a large packet. But if the server only sends these
> large packets after address ownership has been verified, things ought to
> be quite good.
> 
> -- Christian Huitema
> 
>