Subject: Re: [EToSat] BDP parameters draft: security aspects

From: <[email-masked]>
Date: Wed, 18 Dec 2019 10:14:09 +0000

Hi Christian,

Thanks for your analysis of the draft. See inline

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: mercredi 18 décembre 2019 03:03
To: Kuhn Nicolas
Cc: 'Gorry (erg)'; [email-masked]'; 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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 18 Dec 2019 11:46:18 +0000

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, [email-masked] wrote:
> 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
>
> > 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.
>
> >
>
> _______________________________________________
> EToSat mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/etosat

---

From: Christian Huitema <[email-masked]>
Date: Wed, 18 Dec 2019 10:12:56 -1000

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:
>
> can verify the client is indeed at the same IP address. So it seems
> hard to force this behaviour as an attack.
>
> 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
>
>> 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
>>
>> 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,
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law;
>> If you have received this email in error, please notify the sender
>> and delete this message and its attachments.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 19 Dec 2019 09:55:10 +0000

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