Re: Alternative ways to keeps ODCID on the server

[Kazuho Oku <[e-mail]>]

2020年1月28日(火) 15:45 Christian Huitema <[e-mail]>:

> But then, the client that responded to a retry will fail the connection if
> the ODCID parameter is not there. There are two alternative in the bad
> token scenario: good faith client with an obsolete new token, or client
> that received a bad faith retry. In the first case, there is no harm
> completing the connection. In the second case, the client will drop it so
> there is only a modest issue of temporary resource allocation.
>

While I agree that the two scenarios being described here are the
possibilities, I now tend to agree that the MAY can be dropped. Previously,
I missed the fact that ODCID has to be carried as a TP (as correctly
pointed out by Marten and Dmitri).

Regarding attack scenarios, I'd argue that it would be awkward for an
attacker to only send a spoofed packet to the server-side, when a malicious
middlebox can also send a packet to the client. I'd also argue that there
are many other ways of spoofing a client-sent Initial packet, and that
having a defense just for retry tokens does not change the picture.

Therefore, I think dropping the MAY is fine. I think a server can continue
to ignore the retry token when it assumes that it was spoofed, but my take
is that it's not worth writing it down.

> On 1/27/2020 8:35 PM, Marten Seemann wrote:
>
> The client knows if it used a NEW_TOKEN token. More specifically, the
> client knows if it received and responded to a Retry packet.
>
> On Tue, Jan 28, 2020 at 11:21 AM Christian Huitema <[e-mail]>
> wrote:
>
>>
>> On 1/27/2020 7:11 PM, Marten Seemann wrote:
>>
>> > That's actually what I implemented. If the token can be verified, accept
>> > the connection, treat it as validated. If it cannot be verified, check
>> > whether the token is necessary, e.g., would any incoming connection
>> > trigger retry. If it is necessary, drop the connection; if not
>> > necessary, continue as if no token was there.
>>
>> Doesn't that defeat the purpose of the original_connection_id transport
>> parameter? We introduced it to prevent middleboxes from performing a Retry.
>> With this logic, a middlebox could perform a Retry, and then corrupt the
>> token on the second Initial to trick the server into accepting the
>> connection.
>> Furthermore, client implementation will check for the
>> original_connection_id TP, and fail the connection if this TP is missing.
>>
>> The spec also has language that I'd interpret as forbidding this:
>> If the server sends a Retry packet, it MUST include the Destination
>> Connection ID field from the client's first Initial packet in the transport
>> parameter.
>>
>> How do you reconcile that requirement with the "NEW TOKEN" mechanism? If
>> the Initial packet carries a NEW TOKEN, it will be accepted and there won't
>> be any ODCID transport parameter.
>>
>> -- Christian Huitema
>>
>

-- 
Kazuho Oku