> On Oct 27, 2020, at 4:49 PM, Kazuho Oku <[email protected]> wrote:
>
>
>
> 2020年10月28日(水) 8:23 Martin Duke <[email protected]
> <mailto:[email protected]>>:
> Again the spec says PATH_CHALLENGE MUST be padded to 1200
>
> The specification says that. At the same time the receiver is *not* required
> to enforce that.
>
> To be specific, the receiver is not allowed to error-close the connection,
> because the size of datagrams are never authenticated. See #4253. At the
> moment, section 14[1] permits *either* of the following two behaviors when
> receiving a small-sized datagram containing PATH_CHALLENGE: a) respond with a
> full-sized PATH_RESPONSE, b) discard that packet.
>
> But as stated, we need a MUST that somehow prohibits the endpoint from
> sending PATH_RESPONSE, if we want the rule to be stringent.
>
> That might sound like we will be enforcing b. But that's going to be
> problematic, due to the approach requiring implementations to do frame
> processing then discard the packet. That's going to be complicated for some
> QUIC stacks, because they make changes to the connection state (e.g., adding
> the packet number to ack queue) before processing the frames.
>
> Fortunately, we have another option, and that is to state that endpoints MUST
> not respond with PATH_RESPONSEs under these conditions. By stating as such,
> the receiver can either discard the packet, or process the packet as usual
> but refrain from sending PATH_RESPONSE.
>
That seems like a not-unreasonable option, Kazuho. It certainly seems like it
might close some loopholes that haven’t yet been fully explored around sizing
of PATH_CHALLENGE and PATH_RESPONSE.
I’d also note that at one point we lost the 3x limit for path validation. We
used to match the handshake, and when the pacing discussion came in we wound up
with the X bytes / initial RTT duration.
It is important to be able to migrate immediately without validating, not just
because an endpoint might be discovering/bringing up a new path at the same
time as the old one is bad, but due to NAT or other routing changes — we can’t
attempt to guarantee that the 4-tuple will stay the same and also expect to
survive NAT rebinding.
One of the situations that we’ve been using as an example attack is someone who
is able to cause you to toggle between arbitrary ports on a NAT for each packet
(if you go back and forth between two, ideally you’d just end up validating
both and then be cheerfully willing to alternate the data between the two of
them on a sub-RTT basis, probably with somewhat restricted flight sizes, but
let’s not get back into multipath here).
Had a few more thoughts after reading through this thread and re-reading the
relevant sections of the document, but will split those out into a separate
message as they got rather long.
Thanks,
Eric
> [1]
> https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-14-8
> <https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-14-8>
>
>
> On Tue, Oct 27, 2020 at 4:17 PM Kazuho Oku <[email protected]
> <mailto:[email protected]>> wrote:
>
>
> 2020年10月28日(水) 5:13 Martin Duke <[email protected]
> <mailto:[email protected]>>:
> 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?)
>
> The problem here is that an attacker might establish a connection, then send
> small-sized datagrams containing PATH_CHALLENGE frames. Therefore, if we are
> to have a stringent amplification limit for path migration (BTW, I like Ian's
> proposal), we should better block this attack vector too.
>
> So maybe something like "MUST NOT send PATH_RESPONSE frames in response to
> PATH_CHALLENGE frame carried by a datagram that is less than 1200 bytes."
>
>
> 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
> <[email protected]
> <mailto:[email protected]>> 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
>
>
>
> --
> Kazuho Oku
>
>
> --
> Kazuho Oku
