Re: Spin bit discussion - where we're at

[Roland Zink <[e-mail]>]

Taking the spin bit and LTE as an example does it help? Assuming you 
placed an app on my phone and you activate it to do a DoS attack to 
bloat my own last mile access link. Then the RTT should go up for all 
the connections of my phone and the spin bit would allow to measure the 
RTT giving a hint what is going on. It's only a small piece of 
information but it may help.

Even worse would be if the LTE scheduler use a single queue for all 
phones of the cell and you fill the queue with useless packets doing a 
DoS attack to all users of a LTE cell. Here most implementations already 
seem to act fair against users resource block allocation and give them 
equal shares but your mileage may vary.

Of cause you can do the same attack today when you root / jailbreak my 
phone. Similar you can just use the amount of packets send/received but 
in LTE you don't know from this value if the link is saturated or not.

Regards,
Roland


Am 28.11.2017 um 08:01 schrieb Ingemar Johansson S:
> Hi
>
> I really don't see that QUIC is able to solve this (congestion) issue.
> I pointed out ConEx (see eg. RFC6789) as one solution. And as Christian pointed out, operators already use rate shaping or policing or limit the amount of data.
>
> Finally, even though there can be reasons to hack a congestion control algorithm that will help your QUIC connection to outcompete other flows, it also comes with the risk that said connection bloats its own last mile access link. So in the end you create most of the problems for yourself. For instance your LTE connection will only reward you with either high RTT or high loss or both if your congestion control is not enough responsive to congestion signals.
>
> /Ingemar
>
>> -----Original Message-----
>> From: Roland Zink [mailto:[e-mail]]
>> Sent: den 27 november 2017 20:46
>> To: Christian Huitema <[e-mail]>
>> Cc: Ingemar Johansson S <[e-mail]>; Gorry (erg)
>> <[e-mail]>; [e-mail]
>> Subject: Re: Spin bit discussion - where we're at
>>
>> I agree it is not only QUIC. I also don't think it is necessary to panic now. We
>> have issue #740
>> (https://github.com/quicwg/base-drafts/issues/740) about adding a security
>> issues section were existing means could be added. When QUIC can help to
>> address such issues it can become more reliable so I wouldn't say this is out
>> of scope just because other protocols have similar issues. If it really turns out
>> that the current mitigations are not sufficient then work on better queue
>> management algorithm will probably come too late.
>>
>>
>> Roland
>>
>>
>>
>> Am 27.11.2017 um 19:02 schrieb Christian Huitema:
>>> On 11/27/2017 9:36 AM, Roland Zink wrote:
>>>
>>>> If QUIC makes the problem crystal clear then now seems to be a good
>>>> time to solve or mitigate it before risking it becomes a real world
>>>> problem.
>>> First, let's start by agreeing that this is not a problem specific QUIC.
>>> You could say the same about Bit Torrent, any protocol that sends
>>> video over UDP, or any application that opens multiple TCP connection.
>>> So, yes, there may well be a problem, but since it is not specific to
>>> QUIC the mitigation does not have to be specific to QUIC either.
>>>
>>> But let's not panic. Practical mitigation has started long ago, with
>>> ISPs effectively controlling how much data can be sent through a
>>> customer's up-link. Maybe these current mitigations are not
>>> sufficient, but if that is the case I would expect more work on better
>>> queue management algorithm.
>>>
>>> -- Christian Huitema
>>>