Re: [EToSat] BDP parameters draft: security aspects

 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, emile.stephan@orange.com wrote:
>
> Hi Christian,
>
> Thanks for your analysis of the draft. See inline
>
> -----Original Message-----
> From: Christian Huitema [mailto:huitema@huitema.net]
> Sent: mercredi 18 décembre 2019 03:03
> To: Kuhn Nicolas
> Cc: 'Gorry (erg)'; 'etosat@ietf.org'; 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
> EToSat@ietf.org
> https://www.ietf.org/mailman/listinfo/etosat