Re: [Spud] updated draft PLUS charter, rev. 1 June

Brian Trammell <ietf@trammell.ch> Tue, 14 June 2016 14:57 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CC612D7BF for <spud@ietfa.amsl.com>; Tue, 14 Jun 2016 07:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.328
X-Spam-Level:
X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-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 R_RqfOojTh-g for <spud@ietfa.amsl.com>; Tue, 14 Jun 2016 07:57:57 -0700 (PDT)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 86F4B12D7AD for <spud@ietf.org>; Tue, 14 Jun 2016 07:57:57 -0700 (PDT)
Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id EA0B21A0F1F; Tue, 14 Jun 2016 16:57:56 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_F2016C4D-5464-4318-AA3F-110A6A735BA2"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.6b2
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <575ED56A.1000009@isi.edu>
Date: Tue, 14 Jun 2016 16:57:56 +0200
Message-Id: <248D5235-3D59-4071-9F81-A72C252AF6DB@trammell.ch>
References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <CA+9kkMBhJ2oCJ1avnGUY4NYTX0VWA_g=YoJSiLcy6u9hJnH-eA@mail.gmail.com> <57573DCF.1030402@isi.edu> <F6BE4EE1-D320-421E-9D86-2F30B2A88792@tik.ee.ethz.ch> <CALx6S35Z7iEp2F7+1PHzAe0qu9st_CNXB9GCzF278HehFiv0Qg@mail.gmail.com> <0f5628e2-a142-8d83-b427-d6b07183cb9e@isi.edu> <CALx6S35KXOioEK60p-m5tGE_H9MWbB=YhJ_sOcW0KP2vR80vvw@mail.gmail.com> <57574C38.6070402@isi.edu> <F44FFD3B-CE7E-45E8-9F04-233C56CA95A0@trammell.ch> <890FE014-D3F8-4D64-8BF8-95B3E4773075@trammell.ch> <CALx6S34jbmaV7vAxr1+-p2HW9i2oKv7Bb138MzsaP71zVh=PQw@mail.gmail.com> <76A9F36B-9C21-4268-8267-16D0D9A78834@trammell.ch> <CALx6S37uONysFMNJgUs430eFEUuNTMuhcYKtCPBPMs5W6godVQ@mail.gmail.com> <780953BA-CE7B-4B17-AB9A-27324246FB86@tra mmell.ch> <CALx6S374mn6pwrSMmEdE5p60zPOu+77+M6HkA8w43GBO1xLvFg@mail.gmail.com> <DM2PR0301MB06554C7A8277C06E0119AA7EA8500@DM2PR0301MB0655.namprd03.prod.outlook.com> <0216496B-9083-49B1-8778-AA150DEE8392@trammell.ch> <575ED56A.1000009@isi.edu >
To: Joe Touch <touch@isi.edu>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/6CbpWrDsGHDCBFbBYrl6981qv34>
Cc: Christian Huitema <huitema@microsoft.com>, spud <spud@ietf.org>, Tom Herbert <tom@herbertland.com>
Subject: Re: [Spud] updated draft PLUS charter, rev. 1 June
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2016 14:57:59 -0000

> On 13 Jun 2016, at 17:46, Joe Touch <touch@isi.edu> wrote:
> 
> 
> 
> On 6/11/2016 4:49 AM, Brian Trammell wrote:
>>> I think Tom has a good point here. PLUS does introduce new communication patterns, passing information to intermediate routers and expecting routers to act on the information. These communication patterns can very well introduce new attack vectors. We actually discussed a few of those on the list some time back. For example, an attacker could inject a packet that mimics the closure of a flow, and cause intermediate firewalls to close the holes open for that flow.
>> Except this isn't really a new attack vector;
> 
> Not a new type, but it would be a new instance.
> 
>> there's no real difference between this and a FIN/RST injection in TCP, except we get a chance to make the space the attacker has to successfully guess in larger.
> It would be very useful to be clear about your threat model before
> assuming a given solution.
> 
> E.g., no increase in number space will prevent middlebox FIN/RST
> manipulation of endpoint associations ("connections").

True, but defending against endpoint state manipulation by a box on path, in the present deployed Internet in which at least endpoint-to-endpoint flows are always identified by a five-tuple, wherein said box can always simply drop packets identified by said five-tuple, is not very useful. The best you can do is detect it happened. At least an RST-injecting on-path device is nice enough to tell you it's killing your flow.

In the case of a PLUS-encapsulated, encrypted transport, the flow state bits would presumably be integrity-protected against change, using a MAC that could only be generated by the sender, so a receiving endpoint could certainly detect that the flow state bits were manipulated, or that the packet was forged. But just as today, it couldn't detect that the middlebox decided simply to start dropping all the packets (or rather, differentiate that state from some other link failure).

You're correct that the number-space defense is primarily useful against off-path attacks, which are more useful to defend against than on-path ones; indeed, if [1] is to be believed (which I tend to think it is), this is still very much a problem in TCP as deployed.

Cheers,

Brian

[1] Luckie et al "Resilience of Deployed TCP to Blind Attacks" http://conferences.sigcomm.org/imc/2015/papers/p13.pdf

> Joe
> 
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud