Re: Back to work

[Martin Thomson <[e-mail]>]

Hi Eric,

I don't know what you mean by: "How worried are we about the 3x limit?".

I got the impression that Christian's request was that we avoid padding where it is unnecessary.

The two things we need to balance here are:
* Amplification (the reason we have a 3x limit)
* Odd failures when things only work sometimes (the reason we require padding of probes)

My belief is that the proposed PR #4264 achieves this balance in a minimal fashion.

Yes, there are two things you need to verify for a new path, but for the most part, probes can be padded and so will verify both.  Both that the address is live and that the path supports a reasonable MTU.  These are separated into two separate checks if checking the latter would violate the amplification limit.

Padding packets sent on either path is sub-optimal if you already know that the MTU is OK, so I'd be happy to create a carve-out for that.  It seems like a fine optimization, but the space can be used for things other than PADDING frames, so I don't see it as critical.  My migration implementation (almost finished, thanks) will include other frames in these packets where possible.

Cheers,
Martin

On Thu, Oct 29, 2020, at 13:13, Eric Kinnear wrote:
> 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
> > 
> > 
>