Re: [EToSat] BDP parameters draft: security aspects

[Christian Huitema <[e-mail]>]

Gorry,

Yes, if the server adopts a conservative IW based on RTT min and does
appropriate pacing, then the risk of a flooding attacks is greatly
diminished. But there are two problems. First, the draft does not
mention your suggestion in its security section. It probably should.
Second, the algorithm that you propose uses more information than the
BDP and IW values carried in the transport parameters.

You write that the server can check whether the client returns encrypted
information from the same IP address over which the parameters were
initially provided. But the transport parameters are just two integers,
without any mention of previous IP address or a cryptographic proof. In
QUIC v1, the proof of origin is obtained with the "NEW TOKEN" frame. If
you want to restrict the mechanism to situations where the IP address is
verified using the token in the Initial packet, the draft should say that.

But then, if the mechanism is restricted to repeated calls from the same
address verified using the NEW TOKEN/Initial token mechanism, one wonder
whether the required information should also be carried in the NEW TOKEN
itself, rather than carried in both in clear text in  the transport
parameters and also in encrypted form in the token.

-- Christian Huitema

On 12/18/2019 1:46 AM, Gorry Fairhurst wrote:
> From the congestion control point of view, this attack does not seem
> to exist in the way you suggest:
>
> Suppose a path is declared as having a large RTT and large BDP.
>
> If the client returns ecnrypted info form it's IP address, the server
> can verify the client is indeed at the same IP address. So it seems
> hard to force this behaviour as an attack.
>
> If the server then "believes" the congestion control info that it has
> been passed, it will anticipate a large delay. An increased window of
> data would be pacing over the anticpated RRT, say 1 sec. The method
> needs to choose an increased IW that is conservative (say ... for
> example, this was only enabled when RTT>200mS? and then only scaled by
> allowing an increas from the normal that is IW * cached_min_RTT/0.2).
>
> If the RTT is correct, the client responds 1 RTT later all is well.
>
> If it happens that the client's RTT is smaller (for whatever reason),
> the rate of transmission is still not likely higher than the client
> would normally experience (because it is paced to a rate based on a
> higher RTT). The first ACK will be received before the entire IW has
> been paced-out and the server realises the shorter RTT.
>
> If it happens the client's RTT is larger (for whatever reason), the
> rate of tranbsmission remains the same, but paced-sending ceases
> before the RTT. This is better than not trying to adjust the paced-IW
> to the RTT, but less than could have been achieved.
>
> Does that appear unsafe?
>
> Gorry
>
> On 18/12/2019, 10:14, [e-mail] wrote:
>>
>> Hi Christian,
>>
>> Thanks for your analysis of the draft. See inline
>>
>> -----Original Message-----
>> From: Christian Huitema [mailto:[e-mail]]
>> Sent: mercredi 18 décembre 2019 03:03
>> To: Kuhn Nicolas
>> Cc: 'Gorry (erg)'; '[e-mail]'; STEPHAN Emile TGI/OLN
>> Subject: Re: BDP parameters draft (was: [EToSat] Re-chartering for
>> extension work)
>>
>> ...
>>
>> There is also a security aspect there. The server that blindly trusts
>>
>> the BDP option will blast a large number of packets. What if the client
>>
>> is trying to sabotage the local network? Why should the server trust the
>>
>> client? The security section does not cover that...
>>
>> [Emile]
>>
>> The draft supposes that the BDP parameters are protected using the
>> same mechanism that protect initial_max_data TP: the server has a
>> mean to check that the parameters proposed by the client are those it
>> sent to the client during the previous connexion. We will reword that
>> in the security section but it is not an easy part as the usage of
>> TLS1.3 newSessionTicket by QUIC is hard to summarize.
>>
>> Cdt
>>
>> Emile
>>
>> On 12/17/2019 7:27 AM, Kuhn Nicolas wrote:
>>
>> > Hi Mark, Lars,
>>
>> >
>>
>> > Many meetings discussed the impacts of QUIC encryption on satellite
>> Performance-enhancing proxy (PEP) and the benefit of exchanging
>> additional transport parameters.
>>
>> > draft-kuhn-quic-0rtt-bdp was mentioned as a possible extension
>> during « Quick QUIC Update » presentation.
>>
>> >
>>
>> > We have updated draft-kuhn-quic-0rtt-bdp-05 as an extension of QUIC.
>>
>> > We propose to include it in the re-chartering discussion.
>>
>> >
>>
>> > Regards,
>>
>> > Nicolas, Emile and Gorry
>>
>> >
>>
>> >
>> https://datatracker.ietf.org/meeting/106/materials/slides-106-tsvarea-quick-quic-update-mark-nottingham-00.pdf
>>
>> > https://tools.ietf.org/html/draft-kuhn-quic-0rtt-bdp-05
>>
>> >
>>
>> _________________________________________________________________________________________________________________________
>>
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous
>> avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere,
>> deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender
>> and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have
>> been modified, changed or falsified.
>> Thank you.
>>
>>
>> _______________________________________________
>> EToSat mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/etosat
>
> _______________________________________________
> EToSat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/etosat