Re: [tcpm] rfc5961 and suggested updates.

Loganaden Velvindron <loganaden@gmail.com> Thu, 04 October 2018 06:11 UTC

Return-Path: <loganaden@gmail.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 DC500130DE6 for <tcpm@ietfa.amsl.com>; Wed, 3 Oct 2018 23:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KmYiNZfeNEHj for <tcpm@ietfa.amsl.com>; Wed, 3 Oct 2018 23:11:17 -0700 (PDT)
Received: from mail-it1-x134.google.com (mail-it1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 210A9130DDF for <tcpm@ietf.org>; Wed, 3 Oct 2018 23:11:17 -0700 (PDT)
Received: by mail-it1-x134.google.com with SMTP id 134-v6so11624059itz.2 for <tcpm@ietf.org>; Wed, 03 Oct 2018 23:11:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3m8UbRYVfVajrJIfxXmqJnuKQVql8ytCNmG01t0pdZc=; b=l7yvxjelkGGvg4c02Lrru9ljsvd137ZsIboHlUUVMy9kTs+vwxgy9/EdaVHppx6GBm RTNuMDIPG1HraPtfCwnLPhrRNcxYLR+zmK05dadYgbuCtfLt5wvwNWXFdI3HE1RtF7xf HvSbcmTcbmoU9puLR8fkLSR7hEAos87Ohpc6YEdkvsJor4TEAmyVU9cBAPW9TnUxn/3P 5C2oUdNcVDkwRR7vXax3KNxE85ZuGYZnKORWlfOCLWoB+0zaf8j7roRdguw9ivswS3ig bon/xNTweTcnTFJAmha4q9PTCwukS4pIwSZMDEWBUlEScxkSkmFc+KFE82AHctyCrdA4 cJRA==
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=3m8UbRYVfVajrJIfxXmqJnuKQVql8ytCNmG01t0pdZc=; b=spqc03W2tAKoVBrBWQitSp5Q7cWSKkuzm+NL1lKSumi7kCNDLKVSQabFvNs0GlVnAD ETPlC8kAcLGBoofAo3keafWFdmtwjXa07uea3qnxDAoBl61saHjYe49xaRViOnsanAMc eEbS79bJy8CjCCTfJSfDKmMUytJC9YiVHj2z0q01BgvtrbRFMn5UteQPn8IDbPJVLopG D/dHjbWuYF5lvxQRwX+guNqXWjPr7ip1geMhR10P2o0i9+PY/DUTYAKse/iGqYNkkJv5 BhiZn/QkiwivZLrXIN8bvDSYTVIWSPT/+853hAcshx068HYvOW48Xe26yJiRTgT7fxJ3 umiw==
X-Gm-Message-State: ABuFfoiu2WKbA/1lMRHI3qmhZIvaO95oXyDGaAsid5MOcr8pdtayXEN2 NuDYKIJhGuL7h6TMyXJCJuO99Gl6e6QP3iCu6AQ=
X-Google-Smtp-Source: ACcGV63lLlY6l019/KZEOwB0tlzERE5YKtbACAY/i+C8q5R45de3yOawSG+AnF2QT7rlWcDZCo9/5tbmFceqkb7ofeU=
X-Received: by 2002:a02:940a:: with SMTP id a10-v6mr3743169jai.94.1538633476375; Wed, 03 Oct 2018 23:11: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>
In-Reply-To: <CALvgte-JDaKczpa_WYHNxzDJ7m2Yz3KRGxBgEuj2k0x76p2XTw@mail.gmail.com>
From: Loganaden Velvindron <loganaden@gmail.com>
Date: Thu, 04 Oct 2018 10:10:49 +0400
Message-ID: <CAOp4FwRWmuh=RtHA9mULOt3XBGN_thK3FiTVRkBLK1XWKH4N+g@mail.gmail.com>
To: zhiyunq@cs.ucr.edu
Cc: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/uh85egYowg_8nAKeIMwh_PRpBVU>
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 06:11:20 -0000

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?
>
Understood.

> Best,
> -Zhiyun
>
>
> On Tue, Oct 2, 2018 at 3:23 AM Loganaden Velvindron <loganaden@gmail.com> wrote:
>>
>> On Fri, Aug 24, 2018 at 6:07 PM Mirja Kühlewind
>> <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
>> >
>> > Hi,
>> >
>> > my personal opinion:
>> >
>> > I agree that documenting the problem and recommending the implementation of per-socket limits would be a useful thing to do.
>> >
>> > I don’t think it is appropriated or needed to update or even deprecate RFC5961, therefore I would strongly support the changes to this draft as you described below.
>> >
>> > Mirja
>> >
>>
>> Gentle reminder.
>>
>> _______________________________________________
>> tcpm mailing list
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm