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

Joe Touch <touch@isi.edu> Mon, 13 June 2016 15:47 UTC

Return-Path: <touch@isi.edu>
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 EECE212D549 for <spud@ietfa.amsl.com>; Mon, 13 Jun 2016 08:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 q7vzLLviJBXs for <spud@ietfa.amsl.com>; Mon, 13 Jun 2016 08:47:35 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 40C4612D193 for <spud@ietf.org>; Mon, 13 Jun 2016 08:47:35 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5DFkoJI013747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Jun 2016 08:46:51 -0700 (PDT)
To: Brian Trammell <ietf@trammell.ch>, Christian Huitema <huitema@microsoft.com>
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>
From: Joe Touch <touch@isi.edu>
Message-ID: <575ED56A.1000009@isi.edu>
Date: Mon, 13 Jun 2016 08:46:50 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <0216496B-9083-49B1-8778-AA150DEE8392@trammell.ch>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/5gfwEPxbLReAnZCshQsBnx5jQlI>
Cc: Tom Herbert <tom@herbertland.com>, spud <spud@ietf.org>
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: Mon, 13 Jun 2016 15:47:36 -0000


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").

Joe