Re: [tcpm] rfc5961 and suggested updates.

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Fri, 05 October 2018 23:50 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16302130EF7 for <tcpm@ietfa.amsl.com>; Fri, 5 Oct 2018 16:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.101
X-Spam-Level: ***
X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F607g-zoDl-j for <tcpm@ietfa.amsl.com>; Fri, 5 Oct 2018 16:50:21 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [203.178.142.146]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9EE6130ED3 for <tcpm@ietf.org>; Fri, 5 Oct 2018 16:50:20 -0700 (PDT)
Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id A19A5278460 for <tcpm@ietf.org>; Sat, 6 Oct 2018 08:50:18 +0900 (JST)
Received: by mail-io1-f50.google.com with SMTP id x26-v6so11931433iog.11 for <tcpm@ietf.org>; Fri, 05 Oct 2018 16:50:18 -0700 (PDT)
X-Gm-Message-State: ABuFfogE1ntLyekAUtLjUzJt652mjpebi67mQb37Xk4vfw2mB6MJmUx9 opnPm3WDY6hUNDfmIeFRnH+onebu7N5C8U6XhiE=
X-Google-Smtp-Source: ACcGV61n1Whst5HfCbBpfjInH0DN8MI16LnqBOsAxsGnTTM919HCBgqTtMWtwGLQe5BiRICwDcZDQg6fJgakHodrXxg=
X-Received: by 2002:a6b:b558:: with SMTP id e85-v6mr9552986iof.6.1538783416692; Fri, 05 Oct 2018 16:50:16 -0700 (PDT)
MIME-Version: 1.0
References: <CAOp4FwQqfJh6QiNbtcaH83gbZm+iPK5zpTCvje0W+Tpz+fjNng@mail.gmail.com> <DDE6A9C1-3FED-4F0A-84F1-355FA2EBFCF1@tik.ee.ethz.ch> <CAOp4FwQ26SChQtPZ84aGZSYx6kfBChHkff54sqWNy4iMbeHg-Q@mail.gmail.com> <CALvgte-JDaKczpa_WYHNxzDJ7m2Yz3KRGxBgEuj2k0x76p2XTw@mail.gmail.com> <CAOp4FwRWmuh=RtHA9mULOt3XBGN_thK3FiTVRkBLK1XWKH4N+g@mail.gmail.com> <CADVnQymo0GD-K9QdOcTHZ2X6D-JozXV4_sX06U1Q=UjCoaSuWg@mail.gmail.com> <CAO249yecx55CFP-kGu7zoK6iaJ1j=53FNRNJ-10b30jPEhnFxw@mail.gmail.com> <CALvgte8HiS1aAGWMedNhEKJS60aGKgsSur4R515Vp1TvGu8nrQ@mail.gmail.com>
In-Reply-To: <CALvgte8HiS1aAGWMedNhEKJS60aGKgsSur4R515Vp1TvGu8nrQ@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Fri, 5 Oct 2018 16:50:04 -0700
X-Gmail-Original-Message-ID: <CAO249yeq1nvQXpp3SoRkyTQPVEhTNN957-3tWbNzgV48a65MLQ@mail.gmail.com>
Message-ID: <CAO249yeq1nvQXpp3SoRkyTQPVEhTNN957-3tWbNzgV48a65MLQ@mail.gmail.com>
To: zhiyunq@cs.ucr.edu
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, "tcpm@ietf.org" <tcpm@ietf.org>, edumazet@google.com, ncardwell=40google.com@dmarc.ietf.org
Content-Type: multipart/alternative; boundary="000000000000f043bb057783ee37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/V2TVI0O25IBhdFGNhVeCq0M4usU>
Subject: Re: [tcpm] rfc5961 and suggested updates.
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Oct 2018 23:50:33 -0000

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 <zhiyunq@cs.ucr.edu> 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 <nishida@sfc.wide.ad.jp>
> 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=
>> 40google..com@dmarc.ietf.org <40google.com@dmarc.ietf.org>> wrote:
>>
>>> On Thu, Oct 4, 2018 at 2:11 AM Loganaden Velvindron <loganaden@gmail.com>
>>> wrote:
>>> >
>>> > On Tue, Oct 2, 2018 at 7:38 PM Zhiyun Qian <zhiyunq@cs.ucr.edu> 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
>>> tcpm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>