Re: Back to work

[Martin Duke <[e-mail]>]

Again the spec says PATH_CHALLENGE MUST be padded to 1200

On Tue, Oct 27, 2020 at 4:17 PM Kazuho Oku <[e-mail]> wrote:

>
>
> 2020年10月28日(水) 5:13 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?)
>>
>
> 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 <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
>>>
>>>
>
> --
> Kazuho Oku
>