Re: [EToSat] BDP parameters draft: security aspects

[Gorry Fairhurst <[e-mail]>]

Thanks Christian,

So I see this as in three parts:
1) How to get parameters to the client from a server who knows
things about the path that has been used.
2) How to safely return the params to the server to initialise a 
connection's CC functions.
3) How to do the adjustment with "CC safety" considering the possibility 
that actual path could/will change.

For me the focus owas on the last item and the text we proposed
was I think our attempt to find a way that could complement QUIC -
I actually do think I do not yet know for certain how best to signal the
params or what security functions to use. I am aware of others
probably having more intuition here, and I would be very open to good
suggestions. I think this is where the WG expertise would help, and
your suggetsions are apprecaited.
  

Gorry



On 18/12/2019, 20:12, Christian Huitema wrote:
> 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
> _______________________________________________
> EToSat mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/etosat