Re: [tcpm] rfc5961 and suggested updates.

[Yoshifumi Nishida <[e-mail]>]

Hi Zhiyun,

OK. So, in my understanding, this attack infers the lower bound at first,
then repeating the process to expect eventually the target selects the
lower bound value again everytime they narrow down to identify the proper
seqno or ackno.
I also think this could be a potential risk, but we can easily increase the
difficulties by using wide random range or probability-based response
without increasing the complexity of the implementations much.
Anyway, if many implementors think having per-connection/address limit is
easier and inexpensive, I don't have any more opinions on it.
Thanks for the info!
--
Yoshi


On Thu, Oct 4, 2018 at 11:07 PM Zhiyun Qian <[e-mail]> wrote:

> Yoshifumi,
>
> Linux did implement the fix to randomize the global limit for each
> 1-second interval (I think Eric made the patch if I am not mistaken).
> However, such randomization can be tricky to analyze and is not fool-proof.
> In fact, there is still information leakage in the current Linux
> implementation (albeit much more difficult to exploit). Hence I'd still
> vote for the per-connection rate limit.
>
> Let us imagine the random range of the limit to be 100 to 200 (Linux uses
> a larger range but let us use it just for the sake of discussion). To infer
> whether a spoofed packet triggers a challenge ACK, the attacker can do the
> following: it sends 1 spoofed packet and 100 non-spoofed packets (the sum
> of which would be 101, just slightly over the lower bound of the limit).
> Whenever the spoofed packet triggers a challenge ACK from the victim
> server, and the server happens to choose 100 as the limit of the current
> interval, the attacker will see exactly 99 challenge ACKs back to itself
> --- this is the only time the attacker should see 99 (all other times the
> attacker will see 100, which doesn't leak anything because it could either
> be the case that spoofed packet does not triggger a challenge ACK, or
> perhaps it did but the server's limit at the moment is higher than 100).
> This still allows the attacker to infer whether a spoofed packet does
> trigger a challenge ACK. It just needs to guess 50X more times (on average)
> compared to the original attack. Obviously here this is just an example.
> The larger the random range, the longer it will take the server to pick the
> lower bound as its limit by chance.
>
> In terms of how expensive it is to implement this, Linux seems to have the
> per-connection rate limit even before the challenge ACK was introduced. So
> it doesn't seem to be a lot of overhead?
>
> Best,
> -Zhiyun
>
>
> On Thu, Oct 4, 2018 at 10:13 AM Yoshifumi Nishida <[e-mail]>
> wrote:
>
>> Hi, I am personally wondering if per-connection or per-address based
>> limit is the best way for this.
>> In my reading of the usenix paper, it says using fixed value for global
>> limit would be vulnerable. So, it seems to me that it would be ok if the
>> value is not fixed,
>> I think there're several ways to do this such as 1) keep changing global
>> limit at certain interval. 2) after exceeding a certain threshold, send
>> challenge ACKs with a certain probability. I am thinking this might be
>> relatively inexpensive rather than having per-connection/address limit.
>>
>> Thanks,
>> --
>> Yoshi
>>
>> On Thu, Oct 4, 2018 at 9:42 AM Neal Cardwell <ncardwell=
>> [e-mail] <[e-mail]>> wrote:
>>
>>> On Thu, Oct 4, 2018 at 2:11 AM Loganaden Velvindron <[e-mail]>
>>> wrote:
>>> >
>>> > On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian <[e-mail]> wrote:
>>> > >
>>> > > Loganaden and Mirja,
>>> > >
>>> > > Not sure if my previous email went through. I'm copying it here:
>>> > >
>>> > > Chiming in here. My name is Zhiyun Qian. We are the group of
>>> researchers from UC Riverside who invented the original side channel attack
>>> in 2016. Thanks Loganaden for initiating the changes to the specification
>>> and thanks Mirja for putting me in the loop. I've done much research in TCP
>>> security that I felt like this is home :)
>>> > >
>>> > > My 2 cents:
>>> > >
>>> > > - I fully support we make it explicit that per-socket rate limit
>>> (instead of global limit) should be implemented either in a separate draft
>>> or maybe RFC5961itself. I am not sure how people will come across a
>>> separate draft like this. Will there be a link from RFC5961?
>>> > >
>>> >
>>> > That's a possibility if there is enough interest. Right now, I've
>>> > received feedback only from you and Mirja. I was hoping to get
>>> > feedback from more people.
>>> > The draft is pretty small, and I've removed the "controversial" parts
>>> > that some people disagreed with.
>>> >
>>> > > - BTW, to this day, Linux still has the global rate limit together
>>> with the per-socket limit (the latter will apply first), which still leaves
>>> some possibility for attacks (although very slim). I understand the global
>>> rate limit is to prevent the whole system from sending too many challenge
>>> ACKs. However, to be honest, I am not sure why this is considered harmful..
>>> Why don't we do something simple instead such as no limit at all or apply
>>> only the per-socket limit? I infer two reasons  (1) reflection attacks ---
>>> but the amplification ratio is only 1:1. (2) ACK loops --- but this can be
>>> mitigated by the per-socket limit already. Why do we need a global rate
>>> limit? The benefit seems very incremental to me. The only benefit is that
>>> when thousands of connections (perhaps on a server) all enter the "ACK loop
>>> state" and started flooding the network but this seems extremely unlikely?
>>> > >
>>>
>>> Re:
>>>   https://tools.ietf.org/html/draft-lvelvindron-ack-throttling-03
>>>
>>> I would support the suggestion to publish these recommendations (for
>>> per-connection rather than per-IP-address rate limiting) as an errata
>>> to RFC5961.
>>>
>>> neal
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>