Re: Back to work

[Martin Duke <[e-mail]>]

PATH_CHALLENGE MUST be padded as well, so I don't see that as an
amplification vector. It might be useful to add language to allow
PATH_CHALLENGE to be ignored if not padded (SHOULD ignore?)

In migration, the path usually should have already been pre-validated so
there is no attack vector once that happens.

But Ian's proposal to use the 3x limit is not so great in the NAT rebinding
case. If a small packet causes this, data transfer is going to plummet, and
we can't simultaneously verify the path and the MTU.

On Tue, Oct 27, 2020 at 10:04 AM Magnus Westerlund <magnus.westerlund=
[e-mail]> wrote:

> On Tue, 2020-10-27 at 09:12 -0400, Ian Swett wrote:
> > Thanks for summarizing this issue. I think the above discussion is about
> > immediate migration and repeated immediate migrations, but I also wonder
> if
> > we've introduced a single packet amplification attack by requiring
> > PATH_RESPONSEs be padded on new paths without a requirement on the size
> of
> > PATH_CHALLENGE(see first item)?
> >
> > Validating a new path
> > If one receives only a PATH_CHALLENGE on a new path, then the server
> > responds with a full-sized PATH_RESPONSE.  This seems safe.  If a
> non-padded
> > PATH_CHALLENGE is received on a new path, then the peer is supposed to
> send a
> > fully padded PATH_RESPONSE on the path, which could be >20x larger.  I'm
> not
> > sure if we care about this, but I wanted to point it out.
> >
> > Immediately migrating to a new path
> > I think we should remove the text about allowing kMinimumWindow each
> > kInitialRtt after migration and change it to the 3x limit.  I'm actually
> > surprised the text about 2*kInitialWindow still exists, since recovery
> says
> > "Until the server has validated the client's address on the path, the
> amount
> > of data it can send is limited to three times the amount of data
> received, as
> > specified in Section 8.1 of {{QUIC-TRANSPORT}}.".
> >
> > In order to not get deadlocked by the 3x factor, I think we should
> change the
> > newly added MUSTs to only apply to path validation prior to migration,
> not the
> > peer responding to migration.
> >
> > My reasoning is that if a peer migrates prior to validating the path, it
> means
> > it's either unintentional or they have no other choice, so the migrating
> peer
> > has implicitly decided that validating PathMTU is not a prerequisite to
> > migrating.
>
> So some quesitons and ideas as I think it is relevant to resolve this as
> best as
> possible.
>
> So isn't this recreating the issue that if the client initiates a
> migration to a
> new path that is not QUIC compatible, by responding with a minimal size
> packet
> and completing the migration and then if the server performs the path
> verification with 1200 bytes UDP payload it fails. Thus maintaining a
> broken
> path.
>
> So is there need for the non pre-validated path migration case that one
> need
> need to do a two step process where one will ACK with minimal packet while
> initiating path validation. If path validatation fails then maybe one need
> to
> close down the connection as the migration ended up on a path that was
> unable to
> support QUIC. The question here is how to avoid the DoS attack this may
> open up
> if an attack rewrites source address of packets.
>
> So Maybe the path validation needs to be a two step process. First a return
> routability over the new path to verify that it is bi-directional. When
> that has
> been verified one does a test with minimal MTU to prove it to be QUIC
> compatible. This might even be done with application data if there is some
> that
> are available to send.
>
> But, I think that one needs to work through the criterias for when the QUIC
> connection is shut down under the conditions that the path available is not
> supporting 1200 bytes. Also do we end up in a situation where the client
> needs
> to do the second step itself towards the server to verify the path so that
> it
> can determine if it needs to try another path if this one doesn't work?
>
> Cheers
>
> Magnus
>
>