Re: [tcpm] rfc5961 and suggested updates.

Joe Touch <touch@strayalpha.com> Thu, 04 October 2018 15:04 UTC

Return-Path: <touch@strayalpha.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 1320612958B for <tcpm@ietfa.amsl.com>; Thu, 4 Oct 2018 08:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Level:
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 jShW7khz2pWB for <tcpm@ietfa.amsl.com>; Thu, 4 Oct 2018 08:04:20 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65644130E3C for <tcpm@ietf.org>; Thu, 4 Oct 2018 08:04:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ah0+cvbNZuJ+zeOvK8/UNmhqmlMcgjZiy2H9YRqtiNg=; b=yEbwJANQgG2sPeJzTh5+HF2wK vNgzNk/mAUJ2bERKbr03va5P4bhfWrFPWrQr61i0E4J2IHKsIGAf4VWJ9SJEMLuVONiz6x6GFBLJI irRhQ/R/l8OhJct5i/y3s8fZygVIyIrivknLDIb1nhLjNd1aVzshyo4y/TvJIDqqdlpdQFZIYKSF0 kNqPfYEsaFSgCqjqWc0uNkRvdPRAyIG6+i0Mfn3N9zdUAjqkt21K0iQBotOPVyGAEZErfmmr86W+9 UAuOm2FWapsfcos332SVHqJ+2B+eLEA5eLMs+o1z/09CckbISNjenrI0y/QrnaAneQtzrciIUd4Fd giNw/adcA==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:52808 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1g85An-004KSC-1O; Thu, 04 Oct 2018 11:04:17 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <CAOp4FwRWmuh=RtHA9mULOt3XBGN_thK3FiTVRkBLK1XWKH4N+g@mail.gmail.com>
Date: Thu, 4 Oct 2018 08:04:16 -0700
Cc: zhiyunq@cs.ucr.edu, "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <15EA46D7-D00F-4E3B-B891-B169B12149E9@strayalpha.com>
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>
To: Loganaden Velvindron <loganaden@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/guTIw-hLMieRWgWqO-Qzd1119Ik>
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 15:04:23 -0000


> On Oct 3, 2018, at 11:10 PM, 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?

To clarify, are you talking about a per “socket pair” (i.e., per connection) limit? For TCP, the term should be “socket pair” or “connection”. A socket could include one local side of IP/port and many remote IP/ports, and I don’t think that’s what you intend.

(if you mean “unix socket” then  you’re writing recommendations for unix implementers, which is much less useful as an Internet doc).
…

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

FWIW, all of this basically highlights the issue that simply receiving these messages is not an “attack”; the attack is inferred from some threshold of activity. It’s difficult to understand how to usefully set that threshold in any way that isn’t trivial or arbitrarily heuristic (and I haven’t found the draft you’re referring to).

It seems like you’re arguing largely that this threshold should be per connection rather than per IP address. If so, that’s such a minimal issue it’s hard to understand this as more than an errata to RFC5961.

Joe