IETF Logo Mail Archive

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

Christian Huitema <huitema@microsoft.com> Tue, 14 June 2016 19:47 UTC

Return-Path: <huitema@microsoft.com>
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 9FE1312D187 for <spud@ietfa.amsl.com>; Tue, 14 Jun 2016 12:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 sLuSP9DTxHrp for <spud@ietfa.amsl.com>; Tue, 14 Jun 2016 12:47:08 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0140.outbound.protection.outlook.com [65.55.169.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C93A812B01B for <spud@ietf.org>; Tue, 14 Jun 2016 12:47:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z44iG5b34/4lCbOCoqPY5ogRsUr/q6qBmZOaXZ86unY=; b=cRL8pli+TbJpbo84F0ksY/9C7I0jH7MNIbuC76n5hg2Ms0fsyPr0pbL5386OSI2XxuoVFyLTIHnbh8bcRkYfAZEFbde6Omaryz3oT9MGN62zZ6XbSkjQ/NAilyKwE6gjItfeabluF2R5MqJleiJBs6oJlOs3LQuMTxMI8F8KnP4=
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0656.namprd03.prod.outlook.com (10.160.96.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Tue, 14 Jun 2016 19:47:04 +0000
Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0517.011; Tue, 14 Jun 2016 19:47:04 +0000
From: Christian Huitema <huitema@microsoft.com>
To: Ca By <cb.list6@gmail.com>, Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>
Thread-Topic: [Spud] updated draft PLUS charter, rev. 1 June
Thread-Index: AQHRu/KkknslUV6vnUS4tzs14whv9J/eT28AgAABG4CAAB43AIAABfgAgAADLQCAABjYgIAABqUAgAACJQCAAAEtgIAAAqWAgAAEkgCAAGJBAIAAZ68AgADDP4CAAK+3gIAGt8qAgAFmxwCAAHIJoA==
Date: Tue, 14 Jun 2016 19:47:04 +0000
Message-ID: <DM2PR0301MB0655C4B5A3A7E4102D16DBC6A8540@DM2PR0301MB0655.namprd03.prod.outlook.com>
References: <85E24D9D-F666-49C3-A022-2F207227A153@trammell.ch> <CAD62q9UiLi1ffGPm=xEXOSH=sqZPv7hYiNBTGvAX52a9dhV8yg@mail.gmail.com> <CAD62q9U7XL8hDqY1VdzuvUvoz0Ec5DDLAS6=kaLxRExu7FY0Kg@mail.gmail.com> <86027402-2F05-4E3B-B9CD-26517A4F007C@tik.ee.ethz.ch> <A4C63A75-9D7E-430E-B986-9981FB929D46@gmail.com> <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> <57589967.9090004@isi.edu> <37A6D94A-639C-4B9C-B44E-3FD3B5B59071@trammell.ch> <EA4C43BE752A194597B002779DF69BAE24100840@ESESSMB303.ericsson.se> <CAD6AjGTiSu7Lcfq_fdfva1Z5xM0ReQL+tk4UabE7=g7yjGG4CQ@mail.gmail.com>
In-Reply-To: <CAD6AjGTiSu7Lcfq_fdfva1Z5xM0ReQL+tk4UabE7=g7yjGG4CQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com;
x-originating-ip: [2001:4898:80e8:2::14d]
x-ms-office365-filtering-correlation-id: 52eaa50d-727b-474f-bc44-08d3948ca981
x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0656; 6:W5OErRKpVg5bGah9FWdxXvAapNd2iytgjgfmb+sAPtFZwvcsxzCM9IRUbID0Tvh2kRCihZhA+l9WKdHEma28FMQyCob9Z3NyPkZqlPm1zmptpIJUuOBWKA8tgWNy1lKhU9AsDblxRIJsxkaeajk6rTpHxEgg7siLlT5SgAwJMNsq0nxHOZDwTNCO+uAouI4OcIPmUXAwnmGmknLMoWZlfa+bXlhwBwljNSkcZ0YKZblJI8vuKT+e1O3Kfh2V/7cwJlV6HY0EX0fHG677HVHZqg0PuoZzPOb4kasE+JykpfCnFKGkD5LWtqzT+DNSLLtrItN+cR3TFlEue8qrgdPF3w==; 5:QZwzriLQDUjmzqRwANI9sMaBEoKHLeuBw22w8HQiFu4Gd1ZJQXbSiJWqbEg9XASOWaDjEVutBrAzkEjlDBSbWOpVtSlbtc5o5n8ufh6DR4tFims3ygWuq+4w9peFmsorWj/pUvUI/Nwgq7byOD5MdQ==; 24:pP7TmtwwpkbexCHX76zAzG3j6xahDbPrlJNfWhhfxdzK5YnuBQeAOWahFPKrmDU4GYIJY96Pw0J5cxBTaLsoRBV+sO8Z1jUagQORJsbcMyk=; 7:cKDSTP943p3A+a4xeMTIbtT7I/EJao/fO9WvoQRxF7w/1FsNuOe7HlBmVi4JZv1ly/j+XB6Aev/kzjl6m+ryYnMkyZdnCAtkcnq5LMYpkAVedKc0Qawo++hIa6F8R6Zc0iDRESqXjaWLGFKI3yOd3rKSCz1v6KxrUWsQAjJzrPeN+Xsp0T1M7Y6YEKcY7oc/b31fsjRJv03SqvwtKOEPBCtju4EXScWTnnZFhiLZNgEJJAvaJZrYo9qDmQZti8yX
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0656;
x-microsoft-antispam-prvs: <DM2PR0301MB06567013A152EC7BB002FE41A8540@DM2PR0301MB0656.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0656; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0656;
x-forefront-prvs: 09730BD177
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(377454003)(199003)(8936002)(9686002)(50986999)(10090500001)(189998001)(68736007)(10400500002)(81156014)(86612001)(8990500004)(5005710100001)(92566002)(76176999)(105586002)(54356999)(11100500001)(5004730100002)(10290500002)(8676002)(6116002)(102836003)(81166006)(97736004)(87936001)(586003)(5008740100001)(5001770100001)(77096005)(2950100001)(2900100001)(2906002)(4326007)(3280700002)(3660700001)(93886004)(5003600100002)(122556002)(99286002)(86362001)(101416001)(106356001)(106116001)(33656002)(74316001)(76576001)(5002640100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0656; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 19:47:04.8254 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0656
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/kY0MKujMGmRKoHZFHMR6nG40sXY>
Cc: Brian Trammell <ietf@trammell.ch>, Joe Touch <touch@isi.edu>, 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: Tue, 14 Jun 2016 19:47:10 -0000

On Tuesday, June 14, 2016 5:46 AM, Ca By wrote:

>
> All my concerns with spud and quic would be solved by using a 
> new protocol number since it would allow for the network to, 
> at scale, identify good spud/quic traffic from the known bad  udp ddos mess

I think we need to dig a bit further there. Botnets could issue spud/quic traffic just fine. Granted, it will take them some time to adapt, but history shows that they will adapt. So, I don't see how painting a fixed set of bits in the packets would help in the long run. Botnets engaged in DOS will just set the same bits, be it a protocol number or a header field.

There may be something specific to do about differentiation from UDP reflection attacks. I am aware that a lot of these are DNS packets. There may be some other UDP services as well. But the general characteristic is that such attacks reuse a deployed infrastructure to their benefits, and thus have specific markers. The infrastructure is not going to change, so the markers will stay. The new protocols should certainly try to differentiate from these existing attacks. 

> This network operator concern has been repeatedly ignored since
> it is easier to access udp in userspace. 

As many said, user space is just one of the problems. The other is the installed base of NATs that won't pass anything else than TCP and UDP. Do we have studies indicating whether that changes with IPv6?

-- Christian Huitema

v2.23.0 | Report a Bug | By Email