Re: [tcpm] rfc5961 and suggested updates.

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Thu, 04 October 2018 17:13 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 30841130E7A for <tcpm@ietfa.amsl.com>; Thu, 4 Oct 2018 10:13:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 HCG5FNejY3q9 for <tcpm@ietfa.amsl.com>; Thu, 4 Oct 2018 10:13:39 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (mail.sfc.wide.ad.jp [IPv6:2001:200:0:8803: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 7091C130DD3 for <tcpm@ietf.org>; Thu, 4 Oct 2018 10:13:39 -0700 (PDT)
Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 422DA278355 for <tcpm@ietf.org>; Fri, 5 Oct 2018 02:13:37 +0900 (JST)
Received: by mail-io1-f46.google.com with SMTP id p4-v6so8524763iom.3 for <tcpm@ietf.org>; Thu, 04 Oct 2018 10:13:37 -0700 (PDT)
X-Gm-Message-State: ABuFfojcis6TskrfBuwhtnLIvGlXj88ipVP+ADlUzrQ9Z4K/bl4qIfTO HxjyTCQATGpy9jMYeGlAvMaotHe6CIqCdAEFnCs=
X-Google-Smtp-Source: ACcGV60NkngVDb6gcbQlzYVktB7Mf4IoCrfv2MA7j0meCTRNLqBDkzupu2UB6wMh36xuJZrWqcqyHWjhwMXI9USuBTA=
X-Received: by 2002:a6b:c586:: with SMTP id v128-v6mr5229498iof.7.1538673215876; Thu, 04 Oct 2018 10:13:35 -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>
In-Reply-To: <CADVnQymo0GD-K9QdOcTHZ2X6D-JozXV4_sX06U1Q=UjCoaSuWg@mail.gmail.com>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Thu, 4 Oct 2018 10:13:24 -0700
X-Gmail-Original-Message-ID: <CAO249yecx55CFP-kGu7zoK6iaJ1j=53FNRNJ-10b30jPEhnFxw@mail.gmail.com>
Message-ID: <CAO249yecx55CFP-kGu7zoK6iaJ1j=53FNRNJ-10b30jPEhnFxw@mail.gmail.com>
To: "tcpm@ietf.org" <tcpm@ietf.org>
Cc: loganaden@gmail.com, edumazet@google.com, ncardwell=40google.com@dmarc.ietf.org
Content-Type: multipart/alternative; boundary="0000000000007537e705776a46b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/EFL_2qi5NBsntQoFplslKQqVo4A>
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: Thu, 04 Oct 2018 17:13:42 -0000

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> 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
>