Re: [tcpm] rfc5961 and suggested updates.

Neal Cardwell <ncardwell@google.com> Thu, 04 October 2018 16:43 UTC

Return-Path: <ncardwell@google.com>
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 12630130E82 for <tcpm@ietfa.amsl.com>; Thu, 4 Oct 2018 09:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.502
X-Spam-Level:
X-Spam-Status: No, score=-17.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 rMRHE68WUjy7 for <tcpm@ietfa.amsl.com>; Thu, 4 Oct 2018 09:43:16 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1926130DE4 for <tcpm@ietf.org>; Thu, 4 Oct 2018 09:43:15 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id z8-v6so10576762qto.9 for <tcpm@ietf.org>; Thu, 04 Oct 2018 09:43:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HgkWVVdO+mlMLnbAVCMY0C0MB8n8QtGC6sgfYIfRpfU=; b=h7CfqoIbnlvZbqjaMfwPWeWslitljNTGJydJroov9fMsxDtq4VofE7Q9H8C+inAVgA kQ1twnUopzp1TYG5dDOENIN9Jk0Nxr0Pa6OS4NBAod+/HKq3YnCfwhNG9K7sQz+mk/A2 jUOsmoo8FTO5x7sHCV0hwg/VgPRvyder28mq/pgTU+IoHFyP6fo6evGigDLVmt1qLnvK lsR9kwrZQFGK73laiKa6S+mmeGpypQA2ILt32yfQXQJEbzf3/Y2tHbekC3bDnhJBy4C1 lg+nB/CLHZI7uRDf3ywR/rJi011lZGb7jUh8dYD+1pcYFKe9HQBffUdxHshRexU9MAMw VuTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HgkWVVdO+mlMLnbAVCMY0C0MB8n8QtGC6sgfYIfRpfU=; b=IXkn09I9JarsDpdXUmrDWpHNCnTNiHdtvMkPD5qUkWlN1giJ02eU/2VUk2pbwsOtan ilqlzStvvN8ZYgxGnP+VIy56NX2wZALoJM/p5dNHVXtdDD/LvgV1rQcUKp6Doz0QbeQB mVXto1VmsAC7DJXL07liSm0kWZrFfM0LZJ5+wAOBOLyrEWutx0+ovw8RnQlYsscxao5g mKt6SSTq+ysUTRc/LkhAblw/rbAB/kXctIJltgkYqOlw7H9TLPc8b/QR1l8b9qMwNZSY FohFXQ0kJsVIlb0UtL/SF/AbCjuXwhrnWJNzlkP2tT3fYKjuXAUW1/MWToe+wbVG8bJ5 4ktw==
X-Gm-Message-State: ABuFfoiUhxyayf/rbFnOoRcMBO9kaMVW13ZFpoHRd9VS2uHDHNKN6937 b6cOC3ueSl01iHWvV99tdoARzCOyk7cmO8IZCBJWRw==
X-Google-Smtp-Source: ACcGV63aE8kR6q9X5nREO90sNNNKUoKRoy9/AqZlG8kFRmp+P5VsxbCrCJlFhj6ZFWbK4InFhmC+MAb1he6kQcDuaj8=
X-Received: by 2002:ad4:5108:: with SMTP id g8-v6mr289442qvp.238.1538671394779; Thu, 04 Oct 2018 09:43:14 -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>
In-Reply-To: <CAOp4FwRWmuh=RtHA9mULOt3XBGN_thK3FiTVRkBLK1XWKH4N+g@mail.gmail.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Thu, 4 Oct 2018 12:42:58 -0400
Message-ID: <CADVnQymo0GD-K9QdOcTHZ2X6D-JozXV4_sX06U1Q=UjCoaSuWg@mail.gmail.com>
To: Loganaden Velvindron <loganaden@gmail.com>
Cc: Zhiyun Qian <zhiyunq@cs.ucr.edu>, "tcpm@ietf.org" <tcpm@ietf.org>, Eric Dumazet <edumazet@google.com>, Yuchung Cheng <ycheng@google.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/JGKXvjhU2u_aMFLQ0NOVSdKLIFM>
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 16:43:18 -0000

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