From nobody Tue Aug 4 11:37:08 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9561A8A58 for ; Tue, 4 Aug 2015 11:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.926 X-Spam-Level: ** X-Spam-Status: No, score=2.926 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 uHYg6fuaaBWV for ; Tue, 4 Aug 2015 11:37:04 -0700 (PDT) Received: from cdcipgw01.twcable.com (cdcipgw01.twcable.com [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA411A887F for ; Tue, 4 Aug 2015 11:37:04 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.15,610,1432612800"; d="scan'208,217";a="342027090" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 04 Aug 2015 14:33:24 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 4 Aug 2015 14:37:03 -0400 From: "George, Wes" To: Ca By , "opsec@ietf.org" Date: Tue, 4 Aug 2015 14:37:05 -0400 Thread-Topic: [OPSEC] draft-byrne-opsec-udp-advisory Thread-Index: AdDO5I5BLNRv0k9tTli64HEtjY1Eyw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1E67E3A60D7Awesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" , "draft-ietf-tsvwg-rfc5405bis@tools.ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 18:37:06 -0000 --_000_D1E67E3A60D7Awesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSdtIHdvbmRlcmluZyBpZiBwZXJoYXBzIHNvbWUgcGFydHMgb2YgdGhpcyB1ZHAtYWR2aXNvcnkg ZG9jdW1lbnQgd291bGQgYmUgYmV0dGVyIHNlcnZlZCBpbnRlZ3JhdGVkIGludG8gdGhpcyBkb2N1 bWVudDogaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10c3Z3Zy1yZmM1NDA1 YmlzLTA1DQoNClRoYW5rcywNCg0KV2VzDQoNCg0KRnJvbTogT1BTRUMgPG9wc2VjLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgQ2Eg QnkgPGNiLmxpc3Q2QGdtYWlsLmNvbTxtYWlsdG86Y2IubGlzdDZAZ21haWwuY29tPj4NCkRhdGU6 IE1vbmRheSwgSnVseSAyMCwgMjAxNSBhdCA4OjQ2IFBNDQpUbzogIm9wc2VjQGlldGYub3JnPG1h aWx0bzpvcHNlY0BpZXRmLm9yZz4iIDxvcHNlY0BpZXRmLm9yZzxtYWlsdG86b3BzZWNAaWV0Zi5v cmc+Pg0KQ2M6ICJkcmFmdC1ieXJuZS1vcHNlYy11ZHAtYWR2aXNvcnlAdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWJ5cm5lLW9wc2VjLXVkcC1hZHZpc29yeUB0b29scy5pZXRmLm9yZz4iIDxk cmFmdC1ieXJuZS1vcHNlYy11ZHAtYWR2aXNvcnlAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0 LWJ5cm5lLW9wc2VjLXVkcC1hZHZpc29yeUB0b29scy5pZXRmLm9yZz4+DQpTdWJqZWN0OiBbT1BT RUNdIGRyYWZ0LWJ5cm5lLW9wc2VjLXVkcC1hZHZpc29yeQ0KDQpPcCBzZWMsDQoNCkdpdmVuIHRo ZSBudW1iZXIgb2YgdWRwIHJlbGF0ZWQgZGV2ZWxvcG1lbnRzLCBJIGNyZWF0ZWQgdGhpcyBJLWQg dG8gZXhwcmVzcyBjb25jZXJuICBhYm91dCBmdXJ0aGVyIHVkcCB3b3JrIGFuZCBleHBvdW5kIG9u IHNvbWUgb3BlcmF0aW9uYWwgcHJhY3RpY2VzIHRoYXQgY29uZmxpY3Qgd2l0aCB1ZHAgZ3Jvd3Ro Lg0KDQpZb3VyIGZlZWRiYWNrIGlzIHdlbGNvbWUuDQoNCj09PT09PT09PQ0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtYnlybmUtb3BzZWMtdWRwLWFkdmlzb3J5LTAwLnR4dA0KaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDYW1lcm9uIEJ5cm5lIGFuZCBwb3N0ZWQgdG8g dGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICBkcmFmdC1ieXJuZS1vcHNlYy11 ZHAtYWR2aXNvcnkNClJldmlzaW9uOiAgICAwMA0KVGl0bGU6ICAgICAgICBBZHZpc29yeSBHdWlk ZWxpbmVzIGZvciBVRFAgRGVwbG95bWVudA0KRG9jdW1lbnQgZGF0ZTogICAgMjAxNS0wNy0yMA0K R3JvdXA6ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgNQ0KVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1i eXJuZS1vcHNlYy11ZHAtYWR2aXNvcnktMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYnlybmUtb3BzZWMtdWRwLWFkdmlzb3J5Lw0K SHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ieXJuZS1v cHNlYy11ZHAtYWR2aXNvcnktMDANCg0KDQpBYnN0cmFjdDoNCiAgVXNlciBEYXRhZ3JhbSBQcm90 b2NvbCAoVURQKSBpcyBjb21tb25seSB1c2VkIGFzIGEgdm9sdW1ldHJpYyBhdHRhY2sNCiAgdHJh bnNwb3J0IG9uIHRoZSBpbnRlcm5ldC4gIFNvbWUgbmV0d29yayBvcGVyYXRvcnMgZXhwZXJpZW5j ZSBzdXJnZXMNCiAgb2YgVURQIGF0dGFjayB0cmFmZmljIHRoYXQgYXJlIG11bHRpcGxlIG9yZGVy cyBvZiBtYWduaXR1ZGUgYWJvdmUgdGhlDQogIGJhc2VsaW5lIHRyYWZmaWMgcmF0ZSBmb3IgVURQ LiAgQXBwbGljYXRpb24gZGV2ZWxvcGVycyBzaG91bGQgYmUNCiAgYWR2aXNlZCB0aGF0IFVEUCBp cyBiZWluZyByYXRlLWxpbWl0ZWQgb24gYSBiaXRzLXBlci1zZWNvbmQgYW5kDQogIHBhY2tldC1w ZXItc2Vjb25kIGJhc2lzIGJ5IG5ldHdvcmsgb3BlcmF0b3JzIHRvIGVuZm9yY2Uga25vd24gZ29v ZA0KICBiYXNlbGluZSB0cmFmZmljIGxldmVscyBmb3IgVURQLiBVRFAgaGFzIGJlZW4gYWJ1c2Vk IHRvIHN1Y2ggYW4NCiAgZXh0ZW50IHRoYXQgbGVnaXRpbWF0ZSB1c2UgbWF5IGJlY29tZSBjb2xs YXRlcmFsIGRhbWFnZSBhbmQNCiAgYXBwbGljYXRpb24gYW5kIHByb3RvY29sIGRldmVsb3BlcnMg c2hvdWxkIGF2b2lkIHVzaW5nIFVEUCBhcyBhDQogIHRyYW5zcG9ydCB3aGVuIHBvc3NpYmxlLg0K DQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmc8aHR0cDovL3Rvb2xzLmll dGYub3JnLz4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUg Y29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC4NCg== --_000_D1E67E3A60D7Awesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkknbSB3b25kZXJpbmcgaWYgcGVyaGFwcyBzb21lIHBhcnRzIG9mIHRoaXMgdWRwLWFkdmlz b3J5IGRvY3VtZW50IHdvdWxkIGJlIGJldHRlciBzZXJ2ZWQgaW50ZWdyYXRlZCBpbnRvIHRoaXMg ZG9jdW1lbnQ6Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10c3Z3Zy1yZmM1NDA1YmlzLTA1Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXRzdndnLXJmYzU0MDViaXMtMDU8L2E+PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFw dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+V2VzPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0 OyBmb250LXNpemU6IDExcHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsi Pjxicj4NCjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JP RFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6 MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVt IG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFE RElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAx cHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5PUFNFQyAmbHQ7PGEg aHJlZj0ibWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmciPm9wc2VjLWJvdW5jZXNAaWV0Zi5v cmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgQ2EgQnkgJmx0OzxhIGhyZWY9Im1haWx0bzpjYi5saXN0 NkBnbWFpbC5jb20iPmNiLmxpc3Q2QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5Nb25kYXksIEp1bHkgMjAsIDIwMTUgYXQg ODo0NiBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZx dW90OzxhIGhyZWY9Im1haWx0bzpvcHNlY0BpZXRmLm9yZyI+b3BzZWNAaWV0Zi5vcmc8L2E+JnF1 b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b3BzZWNAaWV0Zi5vcmciPm9wc2VjQGlldGYub3JnPC9h PiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVv dDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtYnlybmUtb3BzZWMtdWRwLWFkdmlzb3J5QHRvb2xzLmll dGYub3JnIj5kcmFmdC1ieXJuZS1vcHNlYy11ZHAtYWR2aXNvcnlAdG9vbHMuaWV0Zi5vcmc8L2E+ JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtYnlybmUtb3BzZWMtdWRwLWFkdmlzb3J5 QHRvb2xzLmlldGYub3JnIj5kcmFmdC1ieXJuZS1vcHNlYy11ZHAtYWR2aXNvcnlAdG9vbHMuaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0 OiA8L3NwYW4+W09QU0VDXSBkcmFmdC1ieXJuZS1vcHNlYy11ZHAtYWR2aXNvcnk8YnI+DQo8L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iLXdlYmtp dC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMzAxOTYxKTsiPk9wIHNl Yyw8L3NwYW4+PC9mb250Pg0KPGRpdj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iLXdlYmtp dC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMzAxOTYxKTsiPjxicj4N Cjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIyIiBzdHlsZT0i YmFja2dyb3VuZC1jb2xvcjpyZ2JhKDI1NSwyNTUsMjU1LDApIj5HaXZlbiB0aGUgbnVtYmVyIG9m IHVkcCByZWxhdGVkIGRldmVsb3BtZW50cywgSSBjcmVhdGVkIHRoaXMgSS1kIHRvIGV4cHJlc3Mg Y29uY2VybiZuYnNwOyZuYnNwO2Fib3V0IGZ1cnRoZXIgdWRwIHdvcmsgYW5kIGV4cG91bmQgb24g c29tZSBvcGVyYXRpb25hbCBwcmFjdGljZXMgdGhhdCBjb25mbGljdCB3aXRoIHVkcCBncm93dGgu Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjpyZ2JhKDI1NSwyNTUsMjU1LDApIj48YnI+DQo8L3NwYW4+PC9mb250Pjwv ZGl2Pg0KPGRpdj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjpy Z2JhKDI1NSwyNTUsMjU1LDApIj5Zb3VyIGZlZWRiYWNrIGlzIHdlbGNvbWUuJm5ic3A7PC9zcGFu PjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQtY29sb3I6cmdiYSgyNTUsMjU1LDI1NSwwKSI+PGJyPg0KPC9zcGFuPjwvZm9udD48L2Rpdj4N Cjxmb250IHNpemU9IjIiIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOnJnYmEoMjU1LDI1NSwyNTUs MCkiPg0KPGRpdj49PT09PT09PT08L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtYnlybmUtb3BzZWMtdWRwLWFkdmlzb3J5LTAwLnR4dDxicj4NCmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ2FtZXJvbiBCeXJuZSBhbmQgcG9zdGVk IHRvIHRoZTxicj4NCklFVEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpOYW1lOiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1ieXJuZS1vcHNlYy11ZHAtYWR2aXNvcnk8YnI+DQpSZXZp c2lvbjogJm5ic3A7ICZuYnNwOzAwPGJyPg0KVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO0Fkdmlzb3J5IEd1aWRlbGluZXMgZm9yIFVEUCBEZXBsb3ltZW50PGJyPg0KRG9jdW1lbnQg ZGF0ZTogJm5ic3A7ICZuYnNwOzIwMTUtMDctMjA8YnI+DQpHcm91cDogJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KUGFnZXM6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzU8YnI+DQpVUkw6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1ieXJuZS1vcHNlYy11ZHAtYWR2aXNvcnkt MDAudHh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYnlybmUt b3BzZWMtdWRwLWFkdmlzb3J5LTAwLnR4dDwvYT48YnI+DQpTdGF0dXM6ICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJ5cm5lLW9wc2VjLXVkcC1hZHZpc29yeS8iPmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJ5cm5lLW9wc2VjLXVkcC1hZHZpc29y eS88L2E+PGJyPg0KSHRtbGl6ZWQ6ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ieXJuZS1vcHNlYy11 ZHAtYWR2aXNvcnktMDAiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ieXJuZS1v cHNlYy11ZHAtYWR2aXNvcnktMDA8L2E+PGJyPg0KPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0K Jm5ic3A7Jm5ic3A7VXNlciBEYXRhZ3JhbSBQcm90b2NvbCAoVURQKSBpcyBjb21tb25seSB1c2Vk IGFzIGEgdm9sdW1ldHJpYyBhdHRhY2s8YnI+DQombmJzcDsmbmJzcDt0cmFuc3BvcnQgb24gdGhl IGludGVybmV0LiZuYnNwOyBTb21lIG5ldHdvcmsgb3BlcmF0b3JzIGV4cGVyaWVuY2Ugc3VyZ2Vz PGJyPg0KJm5ic3A7Jm5ic3A7b2YgVURQIGF0dGFjayB0cmFmZmljIHRoYXQgYXJlIG11bHRpcGxl IG9yZGVycyBvZiBtYWduaXR1ZGUgYWJvdmUgdGhlPGJyPg0KJm5ic3A7Jm5ic3A7YmFzZWxpbmUg dHJhZmZpYyByYXRlIGZvciBVRFAuJm5ic3A7IEFwcGxpY2F0aW9uIGRldmVsb3BlcnMgc2hvdWxk IGJlPGJyPg0KJm5ic3A7Jm5ic3A7YWR2aXNlZCB0aGF0IFVEUCBpcyBiZWluZyByYXRlLWxpbWl0 ZWQgb24gYSBiaXRzLXBlci1zZWNvbmQgYW5kPGJyPg0KJm5ic3A7Jm5ic3A7cGFja2V0LXBlci1z ZWNvbmQgYmFzaXMgYnkgbmV0d29yayBvcGVyYXRvcnMgdG8gZW5mb3JjZSBrbm93biBnb29kPGJy Pg0KJm5ic3A7Jm5ic3A7YmFzZWxpbmUgdHJhZmZpYyBsZXZlbHMgZm9yIFVEUC4gVURQIGhhcyBi ZWVuIGFidXNlZCB0byBzdWNoIGFuPGJyPg0KJm5ic3A7Jm5ic3A7ZXh0ZW50IHRoYXQgbGVnaXRp bWF0ZSB1c2UgbWF5IGJlY29tZSBjb2xsYXRlcmFsIGRhbWFnZSBhbmQ8YnI+DQombmJzcDsmbmJz cDthcHBsaWNhdGlvbiBhbmQgcHJvdG9jb2wgZGV2ZWxvcGVycyBzaG91bGQgYXZvaWQgdXNpbmcg VURQIGFzIGE8YnI+DQombmJzcDsmbmJzcDt0cmFuc3BvcnQgd2hlbiBwb3NzaWJsZS48YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCZuYnNwOzxh IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy8iPnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8 YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdDwvZm9udD48Zm9udCBzaXplPSIyIj48c3BhbiBzdHls ZT0iLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMzAxOTYx KTsiPjxicj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L3NwYW4+PGJyPg0KPGhyPg0KPGZvbnQg ZmFjZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9m IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFy eSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJq ZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1t YWlsIGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRh a2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0 aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwg YW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D1E67E3A60D7Awesleygeorgetwcablecom_-- From nobody Tue Aug 4 12:17:44 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755841A1A98 for ; Tue, 4 Aug 2015 12:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.912 X-Spam-Level: X-Spam-Status: No, score=-0.912 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 QqFAYxcp9XO6 for ; Tue, 4 Aug 2015 12:17:37 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 6257C1A1A8A for ; Tue, 4 Aug 2015 12:17:37 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id 17A4A54076C; Tue, 4 Aug 2015 15:17:36 -0400 (EDT) Date: Tue, 4 Aug 2015 15:17:36 -0400 From: Jared Mauch To: "George, Wes" Message-ID: <20150804191736.GD25530@puck.nether.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 19:17:42 -0000 On Sat, Jul 25, 2015 at 09:21:02PM -0400, George, Wes wrote: > Last – I had a conversation with someone (whose name is unfortunately escaping me) in Prague regarding this, and he mentioned one point to potentially highlight is that UDP attacks that are abusing open reflectors (NTP, Chargen, etc) can be distinguished from legitimate traffic if there is something in the header of most legitimate UDP traffic (especially that which is congestion-aware at the app level, or otherwise well-behaved) because while an app could generate packets with the right flag, traffic coming in from a reflector is unlikely to have that information on the header since the attacker does not have any actual control over the reflector. It wouldn't fix raw UDP floods (non-reflected DDoS) where the attacker generates packets with that bit set but it would at least give you another piece of data when establishing your baseline. I hate to say it, but it's almost like the opposite of the "evil bit". > Wes, This is sadly not the case as some of the operational attacks observed have ephemeral ports for both numbers so it is harder to mitigate as vendors quickly run out of TCAM when implementing these features in hardware. It's not easy to compile a filter that matches all the traffic and just QoS against the bad as it's been NTP, DNS, CHARGEN, SSDP and with full UPnP/SSDP enumeration of hosts within the home occuring, traffic from those inside hosts mean the call^Wattack is "coming from inside the house". With attacks using UDP/80,443 as common destination ports it's not easy to discern these from actual NAT'ed traffic egressing a home or otherwise. We sadly had to deploy some UDP limits at $dayjob due to attack sizes. Once we did this the daily triage went away. We were not happy about the E2E aspect of this but the damage is now limited and people can literaly sleep better at night with fewer pages and escalations. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Tue Aug 4 19:17:41 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585011B2B3A for ; Tue, 4 Aug 2015 19:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.611 X-Spam-Level: X-Spam-Status: No, score=-13.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_47=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 1AHwXRYUfSNb for ; Tue, 4 Aug 2015 19:17:38 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7EDD1B2B31 for ; Tue, 4 Aug 2015 19:17:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2589; q=dns/txt; s=iport; t=1438741058; x=1439950658; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=qT6AND+KDs9K2dZqL1MiMEZdtHdnIe9fdTQfoB265fA=; b=WjkjpaZ+n1cyfF93EO9EqzxdIs0qH80U6jX2mh8irhiWvMdMCHbmO7c+ AaJt017tnLui4JFTFffjEfgOi1j7S/x8HqQEw6OLsnXaRKPKyxAWZBn4O dHli/4WyTZBNGGfY1qXE/i9XcxIREOoZPtNP7wwOTUbnyogm2w1HiTNLR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BQAwByccFV/5tdJa1bFoMFVGmDI7lUCYF6CoV5AoE/OBQBAQEBAQEBgQqEJAEBBAEBASBLCxALGAICJgICJzAGE4guDbNqljgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKKLYQvJjMHgmkvgRQFjEx0hzqEfYdTgUdGhk6JVINCg2Qmgg4cgXMeMYEFgUcBAQE X-IronPort-AV: E=Sophos;i="5.15,613,1432598400"; d="scan'208";a="175567810" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 05 Aug 2015 02:17:37 +0000 Received: from [10.24.89.103] ([10.24.89.103]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t752HXO2032469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Aug 2015 02:17:37 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: <20150804191736.GD25530@puck.nether.net> Date: Tue, 4 Aug 2015 17:57:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150804191736.GD25530@puck.nether.net> To: Jared Mauch X-Mailer: Apple Mail (2.2102) Archived-At: Cc: "opsec@ietf.org" , "draft-byrne-opsec-udp-advisory@tools.ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 02:17:40 -0000 On 04-Aug-2015 12:17 pm, Jared Mauch wrote: >=20 > On Sat, Jul 25, 2015 at 09:21:02PM -0400, George, Wes wrote: >> Last =E2=80=93 I had a conversation with someone (whose name is = unfortunately escaping me) in Prague regarding this, and he mentioned = one point to potentially highlight is that UDP attacks that are abusing = open reflectors (NTP, Chargen, etc) can be distinguished from legitimate = traffic if there is something in the header of most legitimate UDP = traffic (especially that which is congestion-aware at the app level, or = otherwise well-behaved) because while an app could generate packets with = the right flag, traffic coming in from a reflector is unlikely to have = that information on the header since the attacker does not have any = actual control over the reflector. It wouldn't fix raw UDP floods = (non-reflected DDoS) where the attacker generates packets with that bit = set but it would at least give you another piece of data when = establishing your baseline. I hate to say it, but it's almost like the = opposite of the "evil bit". >>=20 >=20 > Wes, >=20 > This is sadly not the case as some of the operational > attacks observed have ephemeral ports for both numbers so it > is harder to mitigate as vendors quickly run out of TCAM when=20 > implementing these features in hardware. It's not easy to compile > a filter that matches all the traffic and just QoS against the bad > as it's been NTP, DNS, CHARGEN, SSDP and with full UPnP/SSDP = enumeration > of hosts within the home occuring, traffic from those inside > hosts mean the call^Wattack is "coming from inside the house". With > attacks using UDP/80,443 as common destination ports it's not easy to=20= > discern these from actual NAT'ed traffic egressing a home or = otherwise. >=20 > We sadly had to deploy some UDP limits at $dayjob due to > attack sizes. Once we did this the daily triage went away. We were = not > happy about the E2E aspect of this but the damage is now limited and > people can literaly sleep better at night with fewer pages and = escalations. Which does not bode well for WebRTC (which uses UDP for its SRTP and its = data channel) or QUIC. -d >=20 > - Jared >=20 > --=20 > Jared Mauch | pgp key available via finger from jared@puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only = mine. >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From nobody Tue Aug 4 22:26:14 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B774A1B2BD2 for ; Tue, 4 Aug 2015 22:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 9gR7-57AeLhh for ; Tue, 4 Aug 2015 22:26:10 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (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 4B48A1B2BC0 for ; Tue, 4 Aug 2015 22:26:10 -0700 (PDT) Received: by wijp15 with SMTP id p15so32569834wij.0 for ; Tue, 04 Aug 2015 22:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JOt5tj1FVVt37BMcsij2yBvg6Ue1OSahZQt2EFgxSpA=; b=vKK9PLkBzuWARo9aPXXCsVPIhIIRVvbahZRYdZhiAHMh48W8h5CFTJt25ZAKKKJOqZ bCH2Qhj7QFAlIL1XDgYeveiK92/Ie3CDkSEAErXyQA65Ll5Dt4EJjraylzgRjQ40vjml pgRxhd9Q/sVKPlBJegwe+DQwZ37C0TXi4pYM6AVpEUL4q+DgLcTlTI9II4UGYM/D8ds/ w1/964RJQXEctAw6oDV+6njKFe98rNuBhMvTwVEkdm3xeWhivkL6d8MeH5hufJVlcZaC TdtY7Ls0Z+ZaD2APRfg5N07Kgd4n3BO9TjrlZuaCCHVZByAzfKj7YUCcqcLFICqkZnzb Y9fw== MIME-Version: 1.0 X-Received: by 10.180.21.169 with SMTP id w9mr6432807wie.73.1438752368973; Tue, 04 Aug 2015 22:26:08 -0700 (PDT) Received: by 10.194.191.232 with HTTP; Tue, 4 Aug 2015 22:26:08 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Aug 2015 22:26:08 -0700 Message-ID: From: Ca By To: "George, Wes" Content-Type: multipart/alternative; boundary=047d7bae48f4df5c51051c89a3da Archived-At: Cc: "opsec@ietf.org" , "draft-byrne-opsec-udp-advisory@tools.ietf.org" , "draft-ietf-tsvwg-rfc5405bis@tools.ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 05:26:12 -0000 --047d7bae48f4df5c51051c89a3da Content-Type: text/plain; charset=UTF-8 On Tuesday, August 4, 2015, George, Wes wrote: > I'm wondering if perhaps some parts of this udp-advisory document would be > better served integrated into this document: > http://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-05 > > Thanks, > > > > Wes > > > I believe that has already taken place in the recent revisions of said I-d's security section. This is both important and good. To that end, I would like to see opsec take on draft-byrne-opsec-udp-advisory to publish the full threat and known remediation and related impacts that are within the opsec charter. . CB > > From: OPSEC > on behalf of Ca > By > > Date: Monday, July 20, 2015 at 8:46 PM > To: "opsec@ietf.org " < > opsec@ietf.org > > Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org > " > > > > Subject: [OPSEC] draft-byrne-opsec-udp-advisory > > Op sec, > > Given the number of udp related developments, I created this I-d to > express concern about further udp work and expound on some operational > practices that conflict with udp growth. > > Your feedback is welcome. > > ========= > > A new version of I-D, draft-byrne-opsec-udp-advisory-00.txt > has been successfully submitted by Cameron Byrne and posted to the > IETF repository. > > Name: draft-byrne-opsec-udp-advisory > Revision: 00 > Title: Advisory Guidelines for UDP Deployment > Document date: 2015-07-20 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/internet-drafts/draft-byrne-opsec-udp-advisory-00.txt > Status: > https://datatracker.ietf.org/doc/draft-byrne-opsec-udp-advisory/ > Htmlized: > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > > Abstract: > User Datagram Protocol (UDP) is commonly used as a volumetric attack > transport on the internet. Some network operators experience surges > of UDP attack traffic that are multiple orders of magnitude above the > baseline traffic rate for UDP. Application developers should be > advised that UDP is being rate-limited on a bits-per-second and > packet-per-second basis by network operators to enforce known good > baseline traffic levels for UDP. UDP has been abused to such an > extent that legitimate use may become collateral damage and > application and protocol developers should avoid using UDP as a > transport when possible. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > ------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > --047d7bae48f4df5c51051c89a3da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, August 4, 2015, George, Wes <wesley.george@twcable.com> wrote:
I'm wondering if perhaps some parts of this udp-advisory document = would be better served integrated into this document:=C2=A0htt= p://tools.ietf.org/html/draft-ietf-tsvwg-rfc5405bis-05

Tha= nks,

= =C2=A0

Wes=

= =C2=A0


I believe that has already taken place in the recent revisions of said I= -d's security section.

This is both important = and good.=C2=A0=C2=A0

To that end, I would lik= e to see opsec take on=C2=A0draft-byrne-opsec-udp-advisory to publish the full t= hreat and known remediation and related impacts that are within the opsec c= harter.=C2=A0.=C2=A0

CB=

From: OPSEC <opsec-bounces@ietf.org> on behalf of Ca By <cb.list6@gmail.com>
Date: Monday, July 20, 2015 at 8:46= PM
To: "opsec@i= etf.org" <opsec@ietf.org>
Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org&q= uot; <draft-byrne-opsec= -udp-advisory@tools.ietf.org>
Subject: [OPSEC] draft-byrne-opsec-= udp-advisory

Op sec,

Given = the number of udp related developments, I created this I-d to express conce= rn=C2=A0=C2=A0about further udp work and expound on some operational practi= ces that conflict with udp growth.=C2=A0
=
= Your feedback is welcome.=C2=A0
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D

A new version of I-D, draft-byrne-opsec-udp-advisory-00.txt
has been successfully submitted by Cameron Byrne and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-byrne-opsec-udp-advisory
Revision: =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0Advisory Guidelines for UDP Deployment Document date: =C2=A0 =C2=A02015-07-20
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A05
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-byrne-= opsec-udp-advisory-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-byrne-opsec-udp-advisory/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tool= s.ietf.org/html/draft-byrne-opsec-udp-advisory-00


Abstract:
=C2=A0=C2=A0User Datagram Protocol (UDP) is commonly used as a volumetric a= ttack
=C2=A0=C2=A0transport on the internet.=C2=A0 Some network operators experie= nce surges
=C2=A0=C2=A0of UDP attack traffic that are multiple orders of magnitude abo= ve the
=C2=A0=C2=A0baseline traffic rate for UDP.=C2=A0 Application developers sho= uld be
=C2=A0=C2=A0advised that UDP is being rate-limited on a bits-per-second and=
=C2=A0=C2=A0packet-per-second basis by network operators to enforce known g= ood
=C2=A0=C2=A0baseline traffic levels for UDP. UDP has been abused to such an=
=C2=A0=C2=A0extent that legitimate use may become collateral damage and
=C2=A0=C2=A0application and protocol developers should avoid using UDP as a=
=C2=A0=C2=A0transport when possible.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at=C2=A0tools.ietf.org.

The IETF Secretariat

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
--047d7bae48f4df5c51051c89a3da-- From nobody Tue Aug 4 22:37:30 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58FE1B2BFA for ; Tue, 4 Aug 2015 22:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 gE7-EezS8GS6 for ; Tue, 4 Aug 2015 22:37:27 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (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 D77F91B2BF8 for ; Tue, 4 Aug 2015 22:37:26 -0700 (PDT) Received: by wijp15 with SMTP id p15so32817893wij.0 for ; Tue, 04 Aug 2015 22:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UBKBljNgVPPWMCC9L0htXO9vSIfz7myHUDZm//3Ooyg=; b=n2xMpt45HljvEQvTUSU38JP+xYDz9lWAKq3Fh6nX94SUUEU2ZLU2DOP4lzxBQVaB+c UtvSpuuwmW0byUt2N4qFa8eJ2n4PmxlTuaLsVPNLhRKDas6yx50gRMM8R94YH7Lp16Jl 6kiXOI6vzZh4zaMr06jULQvZ3yDlHkC1Hvo9996dN+8cp1O+xuHRZh7mNQtKCmb8EG+G +4gJ8b0r9XRjyfIbdOuM0UtAHLZJnlVwsBui0AvgY9UVBXLboI6W9lN8Np0EVPTUUp6g VhnpkN6c3n+BwFDcm1zj1QEEPUcwImXGdx7HpNENvey3wzgZn12KCgf8yvBAMhq21m2p C7uA== MIME-Version: 1.0 X-Received: by 10.180.85.231 with SMTP id k7mr7285424wiz.73.1438753045635; Tue, 04 Aug 2015 22:37:25 -0700 (PDT) Received: by 10.194.191.232 with HTTP; Tue, 4 Aug 2015 22:37:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 4 Aug 2015 22:37:25 -0700 Message-ID: From: Ca By To: "George, Wes" Content-Type: multipart/alternative; boundary=f46d0444ef41346782051c89cc67 Archived-At: Cc: "opsec@ietf.org" , "draft-byrne-opsec-udp-advisory@tools.ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 05:37:29 -0000 --f46d0444ef41346782051c89cc67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wes On Saturday, July 25, 2015, George, Wes wrote: > Cameron - > > Thank you for writing this. I think it's useful guidance, but I have some > specific suggestions: > > First of all, you need to be clearer what you mean by baseline in your > recommendations that operators should do it. I know from other > conversations that what you mean is that the rate-limit is not set and > forget, but something that is constantly re-evaluated to determine the > Ehh. Constantly re-evaluated is not scalable. Today, udp traffic levels in aggregate are small. So it is easy to set a threshold at 5x, 10x or even 20x busy hour and be capable of absorbing the blow before policing kicks in. If legit udp traffic rates rise, this is no longer possible, and hence the I-d > baseline, i.e. As a percentage of overall traffic, and this is intended t= o > be a circuit-breaker of sorts that protects against sudden spikes of UDP > traffic with the least possible impact to legitimate traffic, knowing ful= l > well that legitimate traffic continues to increase, or may follow a diurn= al > pattern, flash mob, etc. If there is information available about how this > is accomplished on some types of hardware (i.e. The way that you're doing > it isn't proprietary) it might be useful to discuss this, because that > makes people more likely to implement it. > > Ok. > Second, I would remove the recommendation against using UDP. Your > discussion of the practice of doing this sort of rate limiting and an > explanation of the risk to UDP traffic should be enough to make people > consider their use of UDP for their applications more carefully. Doing th= at > makes this document more likely to achieve consensus and less likely to b= e > misinterpreted as the IETF saying "UDP considered harmful" or similar. > > I am open to more discussion here. I do not want to be ambiguous > Last =E2=80=93 I had a conversation with someone (whose name is unfortuna= tely > escaping me) in Prague regarding this, and he mentioned one point to > potentially highlight is that UDP attacks that are abusing open reflector= s > (NTP, Chargen, etc) can be distinguished from legitimate traffic if there > is something in the header of most legitimate UDP traffic (especially tha= t > which is congestion-aware at the app level, or otherwise well-behaved) > because while an app could generate packets with the right flag, traffic > coming in from a reflector is unlikely to have that information on the > header since the attacker does not have any actual control over the > reflector. It wouldn't fix raw UDP floods (non-reflected DDoS) where the > attacker generates packets with that bit set but it would at least give y= ou > another piece of data when establishing your baseline. I hate to say it, > but it's almost like the opposite of the "evil bit". > I think you mean draft-herbert-udp-magic-numbers That's not a knob on a router I have. And, dipping into the transport frame for explicit middlebox signaling gives me indigestion. CB > Thanks, > > > > Wes > > > > > From: OPSEC > on behalf of Ca > By > > Date: Monday, July 20, 2015 at 8:46 PM > To: "opsec@ietf.org " < > opsec@ietf.org > > Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org > " > > > > Subject: [OPSEC] draft-byrne-opsec-udp-advisory > > Op sec, > > Given the number of udp related developments, I created this I-d to > express concern about further udp work and expound on some operational > practices that conflict with udp growth. > > Your feedback is welcome. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > A new version of I-D, draft-byrne-opsec-udp-advisory-00.txt > has been successfully submitted by Cameron Byrne and posted to the > IETF repository. > > Name: draft-byrne-opsec-udp-advisory > Revision: 00 > Title: Advisory Guidelines for UDP Deployment > Document date: 2015-07-20 > Group: Individual Submission > Pages: 5 > URL: > https://www.ietf.org/internet-drafts/draft-byrne-opsec-udp-advisory-00.tx= t > Status: > https://datatracker.ietf.org/doc/draft-byrne-opsec-udp-advisory/ > Htmlized: > https://tools.ietf.org/html/draft-byrne-opsec-udp-advisory-00 > > > Abstract: > User Datagram Protocol (UDP) is commonly used as a volumetric attack > transport on the internet. Some network operators experience surges > of UDP attack traffic that are multiple orders of magnitude above the > baseline traffic rate for UDP. Application developers should be > advised that UDP is being rate-limited on a bits-per-second and > packet-per-second basis by network operators to enforce known good > baseline traffic levels for UDP. UDP has been abused to such an > extent that legitimate use may become collateral damage and > application and protocol developers should avoid using UDP as a > transport when possible. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > ------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified th= at > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy o= f > this E-mail and any printout. > --f46d0444ef41346782051c89cc67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Wes

On Saturday, July 25, 2015, George, Wes <wesley.george@twcable.com> wrote:
Cameron -=C2=A0

Thank you for writing this. I think it's useful guidance, but I ha= ve some specific suggestions:

First of all, you need to be clearer what you mean by baseline in your= recommendations that operators should do it. I know from other conversatio= ns that what you mean is that the rate-limit is not set and forget, but som= ething that is constantly re-evaluated to determine the=C2=A0

Ehh. Constantly re-evaluated is not scalable. Today, udp tr= affic levels in aggregate are small. So it is easy to set a threshold at 5x= , 10x or even 20x busy hour and be capable of absorbing the blow before pol= icing kicks in.=C2=A0 If legit udp traffic rates=C2=A0rise, this is no long= er possible, and hence the I-d=C2=A0
=C2=A0
baseline, i.e. As a p= ercentage of overall traffic, and this is intended to be a circuit-breaker = of sorts that protects against sudden spikes of UDP traffic with the least = possible impact to legitimate traffic, knowing full well that legitimate traffic continues to increase, or may follow a diurnal pattern, flash mob,= etc. If there is information available about how this is accomplished on s= ome types of hardware (i.e. The way that you're doing it isn't prop= rietary) it might be useful to discuss this, because that makes people more likely to implement it.=C2=A0


Ok.=C2=A0
=C2=A0
<= div>
Second, I would remove the recommendation against using UDP. Your disc= ussion of the practice of doing this sort of rate limiting and an explanati= on of the risk to UDP traffic should be enough to make people consider thei= r use of UDP for their applications more carefully. Doing that makes this document more likely to achieve cons= ensus and less likely to be misinterpreted as the IETF saying "UDP con= sidered harmful" or similar.=C2=A0


I am open to more = discussion here. I do not want to be ambiguous =C2=A0
=C2=A0
Last =E2=80=93 I had a conversation with someone (whose name is unfort= unately escaping me) in Prague regarding this, and he mentioned one point t= o potentially highlight is that UDP attacks that are abusing open reflector= s (NTP, Chargen, etc) can be distinguished from legitimate traffic if there is something in the header of most legiti= mate UDP traffic (especially that which is congestion-aware at the app leve= l, or otherwise well-behaved) because while an app could generate packets w= ith the right flag, traffic coming in from a reflector is unlikely to have that information on the header sin= ce the attacker does not have any actual control over the reflector.=C2=A0 = It wouldn't fix raw UDP floods (non-reflected DDoS) where the attacker = generates packets with that bit set but it would at least give you another piece of data when establishing your basel= ine. I hate to say it, but it's almost like the opposite of the "e= vil bit".=C2=A0

I think you mean=C2=A0=C2=A0draft-herbert-udp-magic-numbers

That's not a=C2=A0knob on a route= r I have. And, dipping into the transport frame for explicit middlebox sign= aling gives me indigestion.=C2=A0

CB
=C2= =A0

Tha= nks,

= =C2=A0

Wes=

= =C2=A0

From: OPSEC <opsec-bounces@ietf.org> on behalf of Ca By <cb.list6@gmail.com>
Date: Monday, July 20, 2015 at 8:46= PM
To: "opsec@i= etf.org" <opsec@ietf.org>
Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org&q= uot; <draft-byrne-opsec= -udp-advisory@tools.ietf.org>
Subject: [OPSEC] draft-byrne-opsec-= udp-advisory

Op sec,

Given = the number of udp related developments, I created this I-d to express conce= rn=C2=A0=C2=A0about further udp work and expound on some operational practi= ces that conflict with udp growth.=C2=A0
=
= Your feedback is welcome.=C2=A0
=
=3D=3D=3D=3D=3D=3D=3D=3D=3D

A new version of I-D, draft-byrne-opsec-udp-advisory-00.txt
has been successfully submitted by Cameron Byrne and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-byrne-opsec-udp-advisory
Revision: =C2=A0 =C2=A000
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0Advisory Guidelines for UDP Deployment Document date: =C2=A0 =C2=A02015-07-20
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A05
URL: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-byrne-= opsec-udp-advisory-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/draft-byrne-opsec-udp-advisory/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tool= s.ietf.org/html/draft-byrne-opsec-udp-advisory-00


Abstract:
=C2=A0=C2=A0User Datagram Protocol (UDP) is commonly used as a volumetric a= ttack
=C2=A0=C2=A0transport on the internet.=C2=A0 Some network operators experie= nce surges
=C2=A0=C2=A0of UDP attack traffic that are multiple orders of magnitude abo= ve the
=C2=A0=C2=A0baseline traffic rate for UDP.=C2=A0 Application developers sho= uld be
=C2=A0=C2=A0advised that UDP is being rate-limited on a bits-per-second and=
=C2=A0=C2=A0packet-per-second basis by network operators to enforce known g= ood
=C2=A0=C2=A0baseline traffic levels for UDP. UDP has been abused to such an=
=C2=A0=C2=A0extent that legitimate use may become collateral damage and
=C2=A0=C2=A0application and protocol developers should avoid using UDP as a=
=C2=A0=C2=A0transport when possible.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at=C2=A0tools.ietf.org.

The IETF Secretariat

This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
--f46d0444ef41346782051c89cc67-- From nobody Wed Aug 5 00:06:20 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9108F1ACE12 for ; Wed, 5 Aug 2015 00:06:18 -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] autolearn=ham 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 R8jF4hSqv8ER for ; Wed, 5 Aug 2015 00:06:17 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) (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 6471D1B2CA8 for ; Wed, 5 Aug 2015 00:06:17 -0700 (PDT) Received: by pdco4 with SMTP id o4so14755952pdc.3 for ; Wed, 05 Aug 2015 00:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type; bh=LS0mvc4HWoOijBB83SsRiU2juyp90JLagNbR3ow6cWw=; b=ch17ehBnRf37rt52lXZfCHPkQpon9t0qu7Bz7dsD4kB4qatL0MUeDMafZ6CLp3Vmld GbH44+aSIEyyLC8MEVzPyQiB61m7p3/iicJ7TKA2E9Zy3gjDm3N57BH18U9XfFbzlmlk brOs7f+rGT7BiGDr+UgV5DD4vTwAkLxHV3yB0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-type; bh=LS0mvc4HWoOijBB83SsRiU2juyp90JLagNbR3ow6cWw=; b=e8OvX5/yMNcspiZ0xobRwxgqfMjHAZEuvdNTCjl8p8WOAgpvoPSo/fXPDpMfX5UlPm WcQUKjnmMXUsbyoHMxglt6YvmPYU1sLnc+F2egt9PCfOPdO/UDLS7tkp2Lv1BIFSeRsZ Cw1Hb5agO7XRQ2bjgEOnsPL+bvLjVUkp3SbELi4+csd2cqRAM+YOIFUmVVbJEl1jJlXa 2JrOQ50ZVBX3u/8anP6BgpyA4nrQpSv+QrrUl1muqzMq8UwG2icmwB/TJJx63Aqre0NL dT7VB3lPJFz4xdRSZ61uLSbMPF68cKtI83aLOG9Rh3emt0TbUpUC/Hbkg7EKyZdZDBbi WouQ== X-Gm-Message-State: ALoCoQl1jGvkNJLwuUo1SU9YGg6zhw+737S49XPHNLchoGBu0lqIdPk3MEV87vn34eb7pD/CoXOn X-Received: by 10.70.43.15 with SMTP id s15mr9561953pdl.14.1438758377044; Wed, 05 Aug 2015 00:06:17 -0700 (PDT) Received: from [172.19.254.129] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id nu6sm1603639pbb.64.2015.08.05.00.06.14 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Aug 2015 00:06:16 -0700 (PDT) From: "Roland Dobbins" To: opsec@ietf.org Date: Wed, 05 Aug 2015 14:06:12 +0700 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-byrne-opsec-udp-advisory@tools.ietf.org Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 07:06:18 -0000 On 5 Aug 2015, at 12:37, Ca By wrote: > Constantly re-evaluated is not scalable. It is in fact scalable, given network infrastructure with sufficient instrumentation capabilities/capacity and sufficient telemetry collection/analysis. Many organizations do this today. Not everyone has those things, however. They should, and eventually most will, but it takes time. The other factor is the reliable automation of policy construction and deployment based on said analysis. Besides the usual gaps and hurdles (standardization of mechanisms still in its relative infancy, lack of skills/resources in many organizations to perform systems integration, et. al.), there is a potential for cascading, feedback loops, and other undesirable forms of oscillation. > I am open to more discussion here. I do not want to be ambiguous Many folks here might generally agree that we don't want to see tons more UDP dumped into the cesspit (QUIC and WebRTC come to mind, as Dan Wing notes) in the current situation, but flatly stating 'no more new UDP, ever' may have difficulty n the necessary consensus in the broader arena. That being said, QUIC and WebRTC in particular are significantly problematic on the operational side of things due to many aspects of this general problem-set. Some middle ground between 'no new UDP, ever' and 'let's switch all Web traffic over to UDP, because it'd be cool' ought to be possible, no? ----------------------------------- Roland Dobbins From nobody Wed Aug 5 05:24:40 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB9A1A0636 for ; Wed, 5 Aug 2015 05:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 loHp_W8yx0v9 for ; Wed, 5 Aug 2015 05:24:36 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 DB28A1A03E1 for ; Wed, 5 Aug 2015 05:24:35 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so206150027wib.0 for ; Wed, 05 Aug 2015 05:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Lyu2p5H4joat57uir8D/mvWMWWLRmDWETkaTtk+TOVQ=; b=SNX14x4EsJJpEzVPKafIAG7yo7Jne6F7W7A185sQaZ/QTp6HZuaU7Jb9caM3YEXMmD jmq7i3z2YjY2NCwsSQyQvVsBeCVZMQ0LUuYQfN3TB8yahN2kbB3vB+HKnqIioPcQVo/R Afq3E7j/vQeItiBFXWbOAsVf0KQt/mDjFGmvAx4CjllByv0Haik6Q20/g0n3Q1Bh07Ry Jq31Gry0cE1bpOpCvpSDjzhJVcP4AFvfaK3csRTyTrTqGEkuJQWH2mfMvlle0Zp3Ro2x Mz1vCBMGAGZNLsa1ktND93UwvxPeMN437ruabizOPgQkDlnCSLacsgfnd6qKCi+gGaHd jg+A== MIME-Version: 1.0 X-Received: by 10.194.10.165 with SMTP id j5mr20547830wjb.147.1438777474534; Wed, 05 Aug 2015 05:24:34 -0700 (PDT) Received: by 10.194.191.232 with HTTP; Wed, 5 Aug 2015 05:24:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Aug 2015 05:24:34 -0700 Message-ID: From: Ca By To: Roland Dobbins Content-Type: multipart/alternative; boundary=e89a8f642b0647d76e051c8f7c5c Archived-At: Cc: "opsec@ietf.org" , "draft-byrne-opsec-udp-advisory@tools.ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 12:24:38 -0000 --e89a8f642b0647d76e051c8f7c5c Content-Type: text/plain; charset=UTF-8 On Wednesday, August 5, 2015, Roland Dobbins wrote: > On 5 Aug 2015, at 12:37, Ca By wrote: > > Constantly re-evaluated is not scalable. >> > > It is in fact scalable, given network infrastructure with sufficient > instrumentation capabilities/capacity and sufficient telemetry > collection/analysis. Many organizations do this today. > > Not everyone has those things, however. They should, and eventually most > will, but it takes time. > > The other factor is the reliable automation of policy construction and > deployment based on said analysis. Besides the usual gaps and hurdles > (standardization of mechanisms still in its relative infancy, lack of > skills/resources in many organizations to perform systems integration, et. > al.), there is a potential for cascading, feedback loops, and other > undesirable forms of oscillation. > > I am open to more discussion here. I do not want to be ambiguous >> > > Many folks here might generally agree that we don't want to see tons more > UDP dumped into the cesspit (QUIC and WebRTC come to mind, as Dan Wing > notes) in the current situation, but flatly stating 'no more new UDP, ever' > may have difficulty n the necessary consensus in the broader arena. > > That being said, QUIC and WebRTC in particular are significantly > problematic on the operational side of things due to many aspects of this > general problem-set. Some middle ground between 'no new UDP, ever' and > 'let's switch all Web traffic over to UDP, because it'd be cool' ought to > be possible, no? > > Yes. Can you please suggest text? CB > ----------------------------------- > Roland Dobbins > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > --e89a8f642b0647d76e051c8f7c5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, August 5, 2015, Roland Dobbins <rdobbins@arbor.net> wrote:
On 5 Aug 2015, at 12:37, Ca By wrote:

Constantly re-evaluated is not scalable.

It is in fact scalable, given network infrastructure with sufficient instru= mentation capabilities/capacity and sufficient telemetry collection/analysi= s.=C2=A0 Many organizations do this today.

Not everyone has those things, however.=C2=A0 They should, and eventually m= ost will, but it takes time.

The other factor is the reliable automation of policy construction and depl= oyment based on said analysis.=C2=A0 Besides the usual gaps and hurdles (st= andardization of mechanisms still in its relative infancy, lack of skills/r= esources in many organizations to perform systems integration, et. al.), th= ere is a potential for cascading, feedback loops, and other undesirable for= ms of oscillation.

I am open to more discussion here. I do not want to be ambiguous

Many folks here might generally agree that we don't want to see tons mo= re UDP dumped into the cesspit (QUIC and WebRTC come to mind, as Dan Wing n= otes) in the current situation, but flatly stating 'no more new UDP, ev= er' may have difficulty n the necessary consensus in the broader arena.=

That being said, QUIC and WebRTC in particular are significantly problemati= c on the operational side of things due to many aspects of this general pro= blem-set.=C2=A0 Some middle ground between 'no new UDP, ever' and &= #39;let's switch all Web traffic over to UDP, because it'd be cool&= #39; ought to be possible, no?


Yes. Can=C2=A0you please=C2=A0suggest = text?

CB
=C2=A0
-----------------------------------
Roland Dobbins <rdobbins@arbor.net>

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec
--e89a8f642b0647d76e051c8f7c5c-- From nobody Wed Aug 5 05:31:54 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBF011B2B5B for ; Wed, 5 Aug 2015 05:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham 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 j2PKxkUgMUIf for ; Wed, 5 Aug 2015 05:31:51 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (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 CAE9F1B2A0B for ; Wed, 5 Aug 2015 05:31:51 -0700 (PDT) Received: by pdrg1 with SMTP id g1so18335857pdr.2 for ; Wed, 05 Aug 2015 05:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arbor.net; s=m0; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=7Pql1r7QBEt491WWK0ki8gDIfJScZpCseyUWpt8E+xE=; b=PA/SNoTtBGIb6EFmJT6hdSAU1E1qG0Sx33V7hr3J2kVsloGEchVrE2fOkKFjxBPv7C eNF/4v4nJMZ45jLkuZZk6QL6+owCBrQEFLZlf/O7mz3g0xPllvnHnD2PfmNgKTA8pQ/o gMNXEVHfpSbS/MBYWLl9MNB1MWrciJsZOIXrs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=7Pql1r7QBEt491WWK0ki8gDIfJScZpCseyUWpt8E+xE=; b=P5odDl+TDCNm5VXgwLNPka8XAyyYcIbMQAgQe99KaDY9FA0FhBnPGSnW684YmACtzn ZcEiS4foFgC792asjA4IFtazjzEoAfJW/oKUhYHOr35GFKv79/fACjO7Xq1nMYRSA+3V icOPbXXmNUUPaVHpLlvNTqZcFg+JrgTV5m5Kpg3c3iFROfZ7RCIqeuVWjj+SNop6z0L/ LGjrFQcPMFostEcyj76OM9+L96t4UJr/kD5FEm6yIFqNWzkNt4xZkqJxyQc33XXCFDkm Ii+PveAgG6yt34yt+8qxoqOSktxB0Ap+Qtl5sghfgZTVHnk6HrGQ6d7dza73XAzXkGCC BVUQ== X-Gm-Message-State: ALoCoQkGMCI/yIhM94c1nG20/HcI04tZUEiPGhCTmpBsWa/SBkKHjcjc4wwjSWJkvi/XDK2I8mjb X-Received: by 10.70.91.14 with SMTP id ca14mr19283805pdb.150.1438777911430; Wed, 05 Aug 2015 05:31:51 -0700 (PDT) Received: from [172.19.254.129] (202-176-81-112.static.asianet.co.th. [202.176.81.112]) by smtp.gmail.com with ESMTPSA id wv4sm2825300pac.2.2015.08.05.05.31.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 05 Aug 2015 05:31:41 -0700 (PDT) From: "Roland Dobbins" To: opsec@ietf.org Date: Wed, 05 Aug 2015 19:31:36 +0700 Message-ID: <56261AA2-F76A-49AA-B7F1-AD8D52E75AED@arbor.net> In-Reply-To: References: MIME-Version: 1.0 X-Mailer: MailMate (1.9.2r5107) Archived-At: Cc: draft-byrne-opsec-udp-advisory@tools.ietf.org Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 12:31:53 -0000 On 5 Aug 2015, at 19:24, Ca By wrote: > Can you please suggest text? Yes, let me think on it. ----------------------------------- Roland Dobbins From nobody Fri Aug 14 05:59:25 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63001A19F8 for ; Fri, 14 Aug 2015 05:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.212 X-Spam-Level: X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 7wD7bYfaf_nf for ; Fri, 14 Aug 2015 05:59:22 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 093E01A0470 for ; Fri, 14 Aug 2015 05:59:22 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 162) id 5B0BB540AB5; Fri, 14 Aug 2015 08:59:21 -0400 (EDT) Date: Fri, 14 Aug 2015 08:59:21 -0400 From: Jared Mauch To: =?utf-8?B?8J+Uk0Rhbg==?= Wing Message-ID: <20150814125921.GA7152@puck.nether.net> References: <20150804191736.GD25530@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Cc: "opsec@ietf.org" , "draft-byrne-opsec-udp-advisory@tools.ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 12:59:23 -0000 On Tue, Aug 04, 2015 at 05:57:47PM -0700, 🔓Dan Wing wrote: > On 04-Aug-2015 12:17 pm, Jared Mauch wrote: > > > > We sadly had to deploy some UDP limits at $dayjob due to > > attack sizes. Once we did this the daily triage went away. We were not > > happy about the E2E aspect of this but the damage is now limited and > > people can literaly sleep better at night with fewer pages and escalations. > > Which does not bode well for WebRTC (which uses UDP for its SRTP and its data channel) or QUIC. Yes, I think this is why the draft is important to discuss at least so protocol people understand the operator challenges faced. Most people don't realize that TCP performance is many times UDP performance in hosts as well. [jared@npd ~]$ iperf -c localhost ------------------------------------------------------------ Client connecting to localhost, TCP port 5001 TCP window size: 2.50 MByte (default) ------------------------------------------------------------ [ 3] local 127.0.0.1 port 55428 connected with 127.0.0.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 20.5 GBytes 17.6 Gbits/sec [jared@npd ~]$ iperf -u -b 99999m -c localhost ------------------------------------------------------------ Client connecting to localhost, UDP port 5001 Sending 1470 byte datagrams, IPG target: 0.12 us (kalman adjust) UDP buffer size: 208 KByte (default) ------------------------------------------------------------ [ 3] local 127.0.0.1 port 33166 connected with 127.0.0.1 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 1.59 GBytes 1.37 Gbits/sec [ 3] Sent 1163581 datagrams [ 3] Server Report: [ 3] 0.0-10.0 sec 1.59 GBytes 1.36 Gbits/sec 0.000 ms 5416/1163581 (0.47%) This means you're not getting the UDP performance advantage you think you are. The challenge here appears to be part of assumptions which are clearly untrue. Looking at my IPv4 stats: 89.4% TCP 10.5% UDP 0.15% ICMP .. other Doing a rate-limit like this: ipv4 access-list ntp-limit permit udp any eq 123 any permit udp any eq 1900 any permit udp any eq 19 any Seems perfectly reasonable and has reduced the impact of attacks seen by our customers. - Jared > > -d > > > > > > - Jared > > > > -- > > Jared Mauch | pgp key available via finger from jared@puck.nether.net > > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From nobody Fri Aug 14 10:14:30 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E8B1B2A81; Fri, 14 Aug 2015 10:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 7Chyh7WXqabe; Fri, 14 Aug 2015 10:14:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1F41A0194; Fri, 14 Aug 2015 10:14:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150814171428.15851.33656.idtracker@ietfa.amsl.com> Date: Fri, 14 Aug 2015 10:14:28 -0700 Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org Subject: [OPSEC] Barry Leiba's No Objection on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 17:14:30 -0000 Barry Leiba has entered the following ballot position for draft-ietf-opsec-ipv6-host-scanning-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Nice document you have here. Just two really small comments, neither of which needs any response, and both of which you can ignore if you prefer. An observation: Three times, you say that something is "obvious", and this can come across as condescending -- and can be frustrating to a reader for whom it isn't obvious. I suggest omitting that, so - In Section 3.1.1.1, change "Firstly, as it should be obvious from the algorithm described above" to "Firstly, as shown by the algorithm described above". - In Section 3.1.3.2, change "For obvious reasons, the search space for addresses following" to "The search space for addresses following". - In Section 3.3, change "Obviously, a number of other network reconnaissance vectors" to "A number of other network reconnaissance vectors". -- Section 3.1.1.1 -- An observation, for which the response is probably "everyone knows this, so no change is needed," but please think about it for a fleeting moment: 1. The "Universal" bit (bit 6, from left to right) of the address is set to 1 Bit 6, starting from 0, or from 1? The answer (which I can see from the example) is "starting from 0." Firstly, as it should be obvious from the algorithm described above, two bytes (bytes 4-5) of the resulting address always have a fixed value (0xff, 0xfe) Bytes 4-5, starting from 0 or from 1? The answer (which I can see from the example) is "starting from 1." The fact that the origins differ makes me think that it'd be nice if that were made clear. Please give it a thought, to say that bits are numbered from left to right starting at 0, and bytes are numbered from left to right starting at 1. From nobody Sun Aug 16 20:26:58 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EB91B2AD8; Sun, 16 Aug 2015 20:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham 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 XTfBjIPeX2yG; Sun, 16 Aug 2015 20:26:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE8E1B2AD6; Sun, 16 Aug 2015 20:26:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150817032655.16360.38365.idtracker@ietfa.amsl.com> Date: Sun, 16 Aug 2015 20:26:55 -0700 Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org Subject: [OPSEC] Spencer Dawkins' No Objection on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 03:26:56 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-opsec-ipv6-host-scanning-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I echo Barry's "nice document", and would support the changes he suggested. I did notice what I believe is a repeated "not" in "it is not not only the lowest-order byte". In this text: 3.4.1. Remote IPv6 Network Scanners Many address scanning tools such as nmap [nmap2012] do not even support sweeping an IPv6 address range. ^ does this mean "sweeping an IPv6 address range in a remote IPv6 network"? I think that's implicit from the section title, but what nmap supports is clearer in the corresponding text in the next section: 3.4.2. Local IPv6 Network Scanners There are a variety of publicly-available local IPv6 network scanners: o Current versions of nmap [nmap2012] implement this functionality. From nobody Tue Aug 18 18:40:34 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC02A1A7035; Tue, 18 Aug 2015 18:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 difJeGAN7pKz; Tue, 18 Aug 2015 18:40:28 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 E16161A8872; Tue, 18 Aug 2015 18:40:27 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZRsLZ-0005zH-AE; Wed, 19 Aug 2015 03:39:21 +0200 Message-ID: <55D3CC08.3040202@si6networks.com> Date: Wed, 19 Aug 2015 02:21:28 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Spencer Dawkins , The IESG References: <20150817032655.16360.38365.idtracker@ietfa.amsl.com> In-Reply-To: <20150817032655.16360.38365.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org Subject: Re: [OPSEC] Spencer Dawkins' No Objection on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 01:40:32 -0000 Hi, Spencer, Thanks so much for your feedback! Please find my comments in-line.... On 08/17/2015 05:26 AM, Spencer Dawkins wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I echo Barry's "nice document", and would support the changes he > suggested. > > I did notice what I believe is a repeated "not" in "it is not not only > the lowest-order byte". Yep. Will fix this. > In this text: > > 3.4.1. Remote IPv6 Network Scanners > > Many address scanning tools such as nmap [nmap2012] do not even > support sweeping an IPv6 address range. > ^ > does this mean "sweeping an IPv6 address range in a remote IPv6 network"? Yes. > I think that's implicit from the section title, but what nmap supports is > clearer in the corresponding text in the next section: > > 3.4.2. Local IPv6 Network Scanners > > There are a variety of publicly-available local IPv6 network > scanners: > > o Current versions of nmap [nmap2012] implement this functionality. This is a different feature: for local scans, you can just "ping" the all-nodes link-local multicast address. But when scanning a remote network, you can only target unicast addresses. And for remote address scans, nmap does not support targeting specific IPv6 address ranges. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 18 18:40:44 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419301A7035; Tue, 18 Aug 2015 18:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 nKqGD7G8TWGs; Tue, 18 Aug 2015 18:40:31 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 E28A81A884D; Tue, 18 Aug 2015 18:40:19 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZRsLP-0005yy-VP; Wed, 19 Aug 2015 03:39:12 +0200 Message-ID: <55D3C85A.604@si6networks.com> Date: Wed, 19 Aug 2015 02:05:46 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Barry Leiba , The IESG References: <20150814171428.15851.33656.idtracker@ietfa.amsl.com> In-Reply-To: <20150814171428.15851.33656.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org Subject: Re: [OPSEC] Barry Leiba's No Objection on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 01:40:33 -0000 Hi, Barry, Thanks so much for your feedback! Please find my comment in-line... On 08/14/2015 07:14 PM, Barry Leiba wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Nice document you have here. Just two really small comments, neither of > which needs any response, and both of which you can ignore if you > prefer. > > An observation: Three times, you say that something is "obvious", and > this can come across as condescending -- and can be frustrating to a > reader for whom it isn't obvious. I suggest omitting that, so > > - In Section 3.1.1.1, change "Firstly, as it should be obvious from the > algorithm described above" to "Firstly, as shown by the algorithm > described above". > > - In Section 3.1.3.2, change "For obvious reasons, the search space for > addresses following" to "The search space for addresses following". > > - In Section 3.3, change "Obviously, a number of other network > reconnaissance vectors" to "A number of other network reconnaissance > vectors". Will update. Thanks! > -- Section 3.1.1.1 -- > > An observation, for which the response is probably "everyone knows this, > so no change is needed," but please think about it for a fleeting > moment: > > 1. The "Universal" bit (bit 6, from left to right) of the address is > set to 1 > > Bit 6, starting from 0, or from 1? The answer (which I can see from the > example) is "starting from 0." Yes, we assume this to be known. > Firstly, as it should be obvious from the algorithm described above, > two bytes (bytes 4-5) of the resulting address always have a fixed > value (0xff, 0xfe) > > Bytes 4-5, starting from 0 or from 1? The answer (which I can see from > the example) is "starting from 1." Good grief! mm.. how about changing this to "bytes 3-4" -- and also adding a note regarding how the bytes are numbered? Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Aug 18 18:43:39 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0091A88F1; Tue, 18 Aug 2015 18:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 G20GaqzL0KCm; Tue, 18 Aug 2015 18:43:36 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 92BDC1A88CF; Tue, 18 Aug 2015 18:43:36 -0700 (PDT) Received: by vkm66 with SMTP id 66so17139656vkm.1; Tue, 18 Aug 2015 18:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4oVvRKJpvMSPZgvzDo3gd3SeTwsA+HEBtC1BRpvL5/U=; b=0K8PL1FcrQyOPMgVRYBedZ+H3htWEwtMfBWs+22Ks8xhS3CDUVCVKPZ9zLRkdcSM+X tdjWy0XMbhTffvQbuoyQuFSHl3QxHXn4RvNOG2gOhmRtxPkfp3gWjzgN7OEwpjTXJUNc fL+dDEklcrrn/ERa5JNEObrFp3Rhao2nFpHG6LJ7jeX2YEsQDYS+c5dexecybFmDtTUF NDIOFaBza8BrTrzwX9YWujEbBhzaS+CQxpI3XEtGEVPHXHKbxN8nyD3Y+kaSondsuKBq ZB7E6CEag7vNqn3LVwgR3SmAczcMaEIPWiRRDlnWSA3mXJ5K2v6dzsFL+6BW22eKfObl thgg== MIME-Version: 1.0 X-Received: by 10.52.15.72 with SMTP id v8mr13415725vdc.94.1439948615782; Tue, 18 Aug 2015 18:43:35 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Tue, 18 Aug 2015 18:43:35 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Tue, 18 Aug 2015 18:43:35 -0700 (PDT) In-Reply-To: <55D3CC08.3040202@si6networks.com> References: <20150817032655.16360.38365.idtracker@ietfa.amsl.com> <55D3CC08.3040202@si6networks.com> Date: Tue, 18 Aug 2015 20:43:35 -0500 Message-ID: From: Spencer Dawkins at IETF To: Fernando Gont Content-Type: multipart/alternative; boundary=20cf30334e75bd1733051da02929 Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org, iesg@ietf.org Subject: Re: [OPSEC] Spencer Dawkins' No Objection on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 01:43:38 -0000 --20cf30334e75bd1733051da02929 Content-Type: text/plain; charset=UTF-8 Hi, Fernando, On Aug 18, 2015 20:39, "Fernando Gont" wrote: > > Hi, Spencer, > > Thanks so much for your feedback! Please find my comments in-line.... > > On 08/17/2015 05:26 AM, Spencer Dawkins wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I echo Barry's "nice document", and would support the changes he > > suggested. > > > > I did notice what I believe is a repeated "not" in "it is not not only > > the lowest-order byte". > > Yep. Will fix this. > > > > > In this text: > > > > 3.4.1. Remote IPv6 Network Scanners > > > > Many address scanning tools such as nmap [nmap2012] do not even > > support sweeping an IPv6 address range. > > ^ > > does this mean "sweeping an IPv6 address range in a remote IPv6 network"? > > Yes. > > > > I think that's implicit from the section title, but what nmap supports is > > clearer in the corresponding text in the next section: > > > > 3.4.2. Local IPv6 Network Scanners > > > > There are a variety of publicly-available local IPv6 network > > scanners: > > > > o Current versions of nmap [nmap2012] implement this functionality. > > This is a different feature: for local scans, you can just "ping" the > all-nodes link-local multicast address. But when scanning a remote > network, you can only target unicast addresses. And for remote address > scans, nmap does not support targeting specific IPv6 address ranges. Right. That's what I wasn't getting from the text. Thanks, Spencer > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > --20cf30334e75bd1733051da02929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi, Fernando,

On Aug 18, 2015 20:39, "Fernando Gont" <fgont@si6networks.com> wrote:
>
> Hi, Spencer,
>
> Thanks so much for your feedback! Please find my comments in-line....<= br> >
> On 08/17/2015 05:26 AM, Spencer Dawkins wrote:
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > I echo Barry's "nice document", and would support t= he changes he
> > suggested.
> >
> > I did notice what I believe is a repeated "not" in &quo= t;it is not not only
> > the lowest-order byte".
>
> Yep. Will fix this.
>
>
>
> > In this text:
> >
> > 3.4.1.=C2=A0 Remote IPv6 Network Scanners
> >
> >=C2=A0 =C2=A0 Many address scanning tools such as nmap [nmap2012] = do not even
> >=C2=A0 =C2=A0 support sweeping an IPv6 address range.
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ^
> > does this mean "sweeping an IPv6 address range in a remote I= Pv6 network"?
>
> Yes.
>
>
> > I think that's implicit from the section title, but what nmap= supports is
> > clearer in the corresponding text in the next section:
> >
> > 3.4.2.=C2=A0 Local IPv6 Network Scanners
> >
> >=C2=A0 =C2=A0 There are a variety of publicly-available local IPv6= network
> >=C2=A0 =C2=A0 scanners:
> >
> >=C2=A0 =C2=A0 o=C2=A0 Current versions of nmap [nmap2012] implemen= t this functionality.
>
> This is a different feature: for local scans, you can just "ping&= quot; the
> all-nodes link-local multicast address. But when scanning a remote
> network, you can only target unicast addresses. And for remote address=
> scans, nmap does not support targeting specific IPv6 address ranges.

Right. That's what I wasn't getting from the text. <= /p>

Thanks,

Spencer

> Thanks!
>
> Best regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com=
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>

--20cf30334e75bd1733051da02929-- From nobody Wed Aug 19 12:06:39 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4C91A891A for ; Wed, 19 Aug 2015 12:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 Q-l2LKFpGJJG for ; Wed, 19 Aug 2015 12:06:35 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22551A7022 for ; Wed, 19 Aug 2015 12:06:35 -0700 (PDT) Received: from lxomavmpc030.qintra.com (lxomavmpc030.qintra.com [151.117.207.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id t7JJ6Wom026245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2015 13:06:32 -0600 (MDT) Received: from lxomavmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id C05B01E0093; Wed, 19 Aug 2015 14:06:26 -0500 (CDT) Received: from lxomp06u.corp.intranet (unknown [10.6.10.61]) by lxomavmpc030.qintra.com (Postfix) with ESMTP id 852951E0088; Wed, 19 Aug 2015 14:06:26 -0500 (CDT) Received: from lxomp06u.corp.intranet (localhost [127.0.0.1]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id t7JJ6QZ7049841; Wed, 19 Aug 2015 14:06:26 -0500 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id t7JJ6QUZ049833 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Aug 2015 14:06:26 -0500 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0195.001; Wed, 19 Aug 2015 13:06:25 -0600 From: "Smith, Donald" To: "George, Wes" , Ca By , "opsec@ietf.org" Thread-Topic: [OPSEC] draft-byrne-opsec-udp-advisory Thread-Index: AQHQw07DSCNgsRs7E0ybKNITpVbCVZ3tYKMAgCZLzaw= Date: Wed, 19 Aug 2015 19:06:25 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 19:06:38 -0000 H8Hz Donald.Smith@centurylink.com > From: OPSEC [opsec-bounces@ietf.org] on behalf of George, Wes [wesl= ey.george@twcable.com] > Sent: Saturday, July 25, 2015 7:21 PM > To: Ca By; opsec@ietf.org > Cc: draft-byrne-opsec-udp-advisory@tools.ietf.org > Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory > > > Cameron - > > > Thank you for writing this. I think it's useful guidance, but I hav= e some specific suggestions: > > > First of all, you need to be clearer what you mean by baseline in y= our recommendations that operators should do it. Base lining is important. If you have netfow or something like it and the a= bility to due reports based on months/years of it, you can see what the tr= affic was like before it started being commonly used for attacks. You should even be able to do some predictive modeling. >I know from other conversations that what you mean is that the rate-limit = is not set and forget, but something that is constantly re-evaluated I would say frequently. I suspect you could safely review it annually or mo= nthly? As long as you set your rate limit Nx higher than the normal rate fo= r that upd protocol/service where 1 to determine the baseline, i.e. As a percentage of overall traffic, and t= his is intended to be a circuit-breaker of sorts that protects against sudd= en spikes of UDP traffic with the least >possible impact to legitimate traf= fic, knowing full well that legitimate >traffic continues to increase, or may follow a diurnal pattern, flash mob,= etc. If there is information available about how this is accomplished on s= ome types of hardware (i.e. The way >that you're doing it isn't proprietary= ) it might be useful to discuss this, because >that makes people more likely to implement it. If you have Arbor's peakflow this is not hard to do since they keep metadat= a around much of the traffic they see. But anything that tracks the flow of packets including the standard 5 tuple= could be used. > > > Second, I would remove the recommendation against using UDP. Your d= iscussion of the practice of doing this sort of rate limiting and an explan= ation of the risk to UDP traffic >should be enough to make people consider = their use of UDP for their applications >more carefully. Doing that makes this document more likely to achieve cons= ensus and less likely to be misinterpreted as the IETF saying "UDP consider= ed harmful" or similar. Agree. Is this true? Application developers should be advised that UDP is being rate-limited on a bits-per-second and packet-per-second basis by network operators to enforce known good baseline traffic levels for UDP. I am not aware of anyone rate-limiting UDP itself. Specific ports using UDP= yes but not UDP as a protocol. Also when we rate limit it is nearly always done on bps because many router= s won't let you do pps. This UDP has been abused to such an extent that legitimate use may become collateral damage and application and protocol developers should avoid using UDP as a transport when possible. Should probably be this. UDP has been abused to such an extent that legitimate use may suffer collateral damage and application and protocol developers may want to avoid using UDP as a transport when possible. Also was the should meant to be an RFC2119 should? It probably should be an= d you should reference that rfc. This TCP has a three- way handshake and SCTP has a four-way handshake, Should probably be this: TCP has a three- way session setup handshake and SCTP has a four-way session setup handsh= ake , Should this be UDP or IP? In the case of SNMP, NTP, CHARGEN, and DNS, a single spoofed IP packet can generate a much larger response to an attack target in many deployments It is true it is a single IP packet, it is slightly more correct to say UDP= . I hate the use of DRDOS. Please use amplified reflective attacks instead. Y= ou can say amplified reflective DDOS attacks if you like :) That's as far as I got so far. > > > Last =96 I had a conversation with someone (whose name is unfortuna= tely escaping me) in Prague regarding this, and he mentioned one point to p= otentially highlight is that UDP >attacks that are abusing open reflectors = (NTP, Chargen, etc) can be distinguished > from legitimate traffic if there= is something in the header of most legitimate UDP traffic (especially >tha= t which is congestion-aware at the app level, or otherwise well-behaved) be= cause while an app could generate packets with the right flag, traffic comi= ng in >from a reflector is >unlikely to have that information on the header= since the attacker does not have any actual control over the reflector. I= t wouldn't fix raw UDP floods (non-reflected DDoS) where the >attacker gene= rates packets with that bit set but it would at >least give you another pie= ce of data when establishing your baseline. I hate to say it, but it's almo= st like the opposite of >the "evil bit". > > > Thanks, > > Wes > > > > From: OPSEC on behalf of Ca By > Date: Monday, July 20, 2015 at 8:46 PM > To: "opsec@ietf.org" > Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" > Subject: [OPSEC] draft-byrne-opsec-udp-advisory > > > > Op sec, > > > Given the number of udp related developments, I created this I-d to= express concern about further udp work and expound on some operational pr= actices that conflict with udp growth. > > > Your feedback is welcome. > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > > A new version of I-D, draft-byrne-opsec-udp-advisory-00.txt > has been successfully submitted by Cameron Byrne and posted to the > IETF repository. > > Name: draft-byrne-opsec-udp-advisory > Revision: 00 > Title: Advisory Guidelines for UDP Deployment > Document date: 2015-07-20 > Group: Individual Submission > Pages: 5 > URL: https://www.ietf.org/internet-drafts/draft-byrne-op= sec-udp-advisory-00.txt > Status: https://datatracker.ietf.org/doc/draft-byrne-opsec-= udp-advisory/ > Htmlized: https://tools.ietf.org/html/draft-byrne-opsec-udp-a= dvisory-00 > > > Abstract: > User Datagram Protocol (UDP) is commonly used as a volumetric att= ack > transport on the internet. Some network operators experience sur= ges > of UDP attack traffic that are multiple orders of magnitude above= the > baseline traffic rate for UDP. Application developers should be > advised that UDP is being rate-limited on a bits-per-second and > packet-per-second basis by network operators to enforce known goo= d > baseline traffic levels for UDP. UDP has been abused to such an > extent that legitimate use may become collateral damage and > application and protocol developers should avoid using UDP as a > transport when possible. > > > > > > Please note that it may take a couple of minutes from the time of s= ubmission > until the htmlized version and diff are available at tools.ietf.org= . > > The IETF Secretariat > > > > > This E-mail and any of its attachments may contain Time Warner Cabl= e proprietary information, which is privileged, confidential, or subject to= copyright belonging to Time Warner Cable. This E-mail is intended solely f= or the use of the individual or entity to which it is addressed. If you are= not the intended recipient of this E-mail, you are hereby notified that an= y dissemination, distribution, copying, or action taken in relation to the = contents of and attachments to this E-mail is strictly prohibited and may b= e unlawful. If you have received this E-mail in error, please notify the se= nder immediately and permanently delete the original and any copy of this E= -mail and any printout. > This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Wed Aug 19 12:30:53 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DA31A6F3A for ; Wed, 19 Aug 2015 12:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 os8tD4z9mihb for ; Wed, 19 Aug 2015 12:30:49 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 022EF1A6EE8 for ; Wed, 19 Aug 2015 12:30:49 -0700 (PDT) Received: by qkch123 with SMTP id h123so380875qkc.0 for ; Wed, 19 Aug 2015 12:30:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0IoSCiMvtzFJr+E8y92BfrvGhTIHq7qwBSOEFWPQCm4=; b=Lqkqnra7zw79oJKBNpkBY8QzK2cdf7+HNYxaCsGR12GytqKxSbSUXWyfBTRQszrg9D ne75pKqFZzw2MuRofE62Pdxq3heLu9064D9DOX1autQ67jsk/qnyzQVAVboHFt6ti2uy N+IVfosH0P+o3c+hZn7AIz1/RVCIG/hdgbjxD002MsVeY/bm5CyB2j+IJVwnTFtXC29r H8lJ2XhhCIHYhyAPGT1x77qBdr+JmBXyeMsTKI+BivAcZe5X7S5d5Of1zl9nvmNoAco2 Leuvkj8fuvbRKT7/frifxFE32Gh2myMi2JmOy5OaxRlvr2LbxwGcxBrXU92Uq0d/RsW9 R6WQ== MIME-Version: 1.0 X-Received: by 10.55.16.3 with SMTP id a3mr26176280qkh.65.1440012648283; Wed, 19 Aug 2015 12:30:48 -0700 (PDT) Received: by 10.55.214.85 with HTTP; Wed, 19 Aug 2015 12:30:48 -0700 (PDT) In-Reply-To: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> References: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> Date: Wed, 19 Aug 2015 12:30:48 -0700 Message-ID: From: Ca By To: "Smith, Donald" Content-Type: multipart/alternative; boundary=001a1146f2c65f8d83051daf129f Archived-At: Cc: "opsec@ietf.org" , "draft-byrne-opsec-udp-advisory@tools.ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 19:30:51 -0000 --001a1146f2c65f8d83051daf129f Content-Type: text/plain; charset=UTF-8 On Wed, Aug 19, 2015 at 12:06 PM, Smith, Donald < Donald.Smith@centurylink.com> wrote: > > > H8Hz > Donald.Smith@centurylink.com > > > > > From: OPSEC [opsec-bounces@ietf.org] on behalf of George, Wes [ > wesley.george@twcable.com] > > Sent: Saturday, July 25, 2015 7:21 PM > > To: Ca By; opsec@ietf.org > > Cc: draft-byrne-opsec-udp-advisory@tools.ietf.org > > Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory > > > > > > Cameron - > > > > > > Thank you for writing this. I think it's useful guidance, but I > have some specific suggestions: > > > > > > First of all, you need to be clearer what you mean by baseline in > your recommendations that operators should do it. > Base lining is important. If you have netfow or something like it and the > ability to due reports based on months/years of it, you can see what the > traffic was like before it started being commonly used for attacks. > You should even be able to do some predictive modeling. > > Yes, agreed. The challenge is that if YouTube switches to QUIC overnight, then your baseline is not very effective > >I know from other conversations that what you mean is that the rate-limit > is not set and forget, but something that is constantly re-evaluated > I would say frequently. I suspect you could safely review it annually or > monthly? As long as you set your rate limit Nx higher than the normal rate > for that upd protocol/service where 1 > > to determine the baseline, i.e. As a percentage of overall traffic, and > this is intended to be a circuit-breaker of sorts that protects against > sudden spikes of UDP traffic with the least >possible impact to legitimate > traffic, knowing full well that legitimate > >traffic continues to increase, or may follow a diurnal pattern, flash > mob, etc. If there is information available about how this is accomplished > on some types of hardware (i.e. The way >that you're doing it isn't > proprietary) it might be useful to discuss this, because > >that makes people more likely to implement it. > > If you have Arbor's peakflow this is not hard to do since they keep > metadata around much of the traffic they see. > But anything that tracks the flow of packets including the standard 5 > tuple could be used. > > > > > > > > Second, I would remove the recommendation against using UDP. Your > discussion of the practice of doing this sort of rate limiting and an > explanation of the risk to UDP traffic >should be enough to make people > consider their use of UDP for their applications > >more carefully. Doing that makes this document more likely to achieve > consensus and less likely to be misinterpreted as the IETF saying "UDP > considered harmful" or similar. > Agree. > Is this true? > > Application developers should be > advised that UDP is being rate-limited on a bits-per-second and > packet-per-second basis by network operators to enforce known good > baseline traffic levels for UDP. > > I am not aware of anyone rate-limiting UDP itself. Specific ports using > UDP yes but not UDP as a protocol. > Also when we rate limit it is nearly always done on bps because many > routers won't let you do pps. > > Cisco IOS-XR allows PPS rate-limit, this is specifically relevant in when a stateful device such as a CGN is part of the deployed network > > This > UDP has been abused to such an > extent that legitimate use may become collateral damage and > application and protocol developers should avoid using UDP as a > transport when possible. > > Should probably be this. > > UDP has been abused to such an > extent that legitimate use may suffer collateral damage and > application and protocol developers may want to avoid using UDP as a > transport when possible. > > ok > Also was the should meant to be an RFC2119 should? It probably should be > and you should reference that rfc. > > Those keywords are are allowed for informational documents AFAIK > This > TCP has a three- > way handshake and SCTP has a four-way handshake, > > Should probably be this: > TCP has a three- > way session setup handshake and SCTP has a four-way session setup > handshake , > > Should this be UDP or IP? > In the case of SNMP, NTP, CHARGEN, and > DNS, a single spoofed IP packet can generate a much larger response > to an attack target in many deployments > It is true it is a single IP packet, it is slightly more correct to say UDP. > > I hate the use of DRDOS. Please use amplified reflective attacks instead. > You can say amplified reflective DDOS attacks if you like :) > > Yeah, i don't like DRDOS either but i used it for consistency with the cited work. Thanks for taking the time to send feedback. CB --001a1146f2c65f8d83051daf129f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 19, 2015 at 12:06 PM, Smith, Donald <<= a href=3D"mailto:Donald.Smith@centurylink.com" target=3D"_blank">Donald.Smi= th@centurylink.com> wrote:
=

H8Hz
Donald.Smith@centurylink.co= m



>=C2=A0 =C2=A0 =C2=A0 =C2=A0From: OPSEC [opsec-bounces@ietf.org] on behalf of George, Wes [wesley.george@twcable.com]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Sent: Saturday, July 25, 2015 7:21 PM
>=C2=A0 =C2=A0 =C2=A0 =C2=A0To: Ca By; opsec@ietf.org
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Cc: draft-byrne-opsec-udp-advisory@tools.ietf.org<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Subject: Re: [OPSEC] draft-byrne-opsec-udp-a= dvisory
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Cameron -
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thank you for writing this. I think it's= useful guidance, but I have some specific suggestions:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0First of all, you need to be clearer what yo= u mean by baseline in your recommendations that operators should do it.
Base lining is important. If you have netfow or something like it an= d the ability to due reports based on months/years of it,=C2=A0 you can see= what the traffic was like before it started being commonly used for attack= s.
You should even be able to do some predictive modeling.


Yes, agreed.= =C2=A0 The challenge is that if YouTube switches to QUIC overnight, then yo= ur baseline is not very effective
=C2=A0
>I know from other conversations that what you mean is that the rate-lim= it is not set and forget, but something that is constantly re-evaluated
I would say frequently. I suspect you could safely review it annuall= y or monthly? As long as you set your rate limit Nx higher than the normal = rate for that upd protocol/service where 1<N<???

> to determine the baseline, i.e. As a percentage of overall traffic, an= d this is intended to be a circuit-breaker of sorts that protects against s= udden spikes of UDP traffic with the least >possible impact to legitimat= e traffic, knowing full well that legitimate
>traffic continues to increase, or may follow a diurnal pattern, flash m= ob, etc. If there is information available about how this is accomplished o= n some types of hardware (i.e. The way >that you're doing it isn'= ;t proprietary) it might be useful to discuss this, because
=C2=A0>that makes people more likely to implement it.

If you have Arbor's peakflow this is not hard to do since they k= eep metadata around much of the traffic they see.
But anything that tracks the flow of packets including the standard 5 tuple= could be used.


>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Second, I would remove the recommendation ag= ainst using UDP. Your discussion of the practice of doing this sort of rate= limiting and an explanation of the risk to UDP traffic >should be enoug= h to make people consider their use of UDP for their applications
>more carefully. Doing that makes this document more likely to achieve c= onsensus and less likely to be misinterpreted as the IETF saying "UDP = considered harmful" or similar.
Agree.
Is this true?

Application developers should be
=C2=A0 =C2=A0advised that UDP is being rate-limited on a bits-per-second an= d
=C2=A0 =C2=A0packet-per-second basis by network operators to enforce known = good
=C2=A0 =C2=A0baseline traffic levels for UDP.

I am not aware of anyone rate-limiting UDP itself. Specific ports us= ing UDP yes but not UDP as a protocol.
Also when we rate limit it is nearly always done on bps because many router= s won't let you do pps.


Cisco IOS-XR allows PPS rate-limit, th= is is specifically relevant in when a stateful device such as a CGN is part= of the deployed network


=C2=A0

This
UDP has been abused to such an
=C2=A0 =C2=A0extent that legitimate use may become collateral damage and =C2=A0 =C2=A0application and protocol developers should avoid using UDP as = a
=C2=A0 =C2=A0transport when possible.

Should probably be this.

UDP has been abused to such an
=C2=A0 =C2=A0extent that legitimate use may suffer collateral damage= and
=C2=A0 =C2=A0application and protocol developers may want to avoid using UD= P as a
=C2=A0 =C2=A0transport when possible.


ok
=C2=A0
Also was the should meant to be an RFC2119 should? It probably should be an= d you should reference that rfc.


Those keywords are are allowed for inf= ormational documents AFAIK
=C2=A0
This
TCP has a three-
=C2=A0 =C2=A0way handshake and SCTP has a four-way handshake,

Should probably be this:
TCP has a three-
=C2=A0 =C2=A0way session setup handshake and SCTP has a four-way session se= tup handshake ,

Should this be UDP or IP?
In the case of=C2=A0 SNMP, NTP, CHARGEN, and
=C2=A0 =C2=A0DNS, a single spoofed IP packet can generate a much larger res= ponse
=C2=A0 =C2=A0to an attack target in many deployments
It is true it is a single IP packet, it is slightly more correct to say UDP= .

I hate the use of DRDOS. Please use amplified reflective attacks instead. Y= ou can say amplified reflective DDOS attacks if you like :)


Yeah, i don't like DRDOS either bu= t i used it for consistency with the cited work.

= =C2=A0Thanks for taking the time to send feedback.

CB
--001a1146f2c65f8d83051daf129f-- From nobody Wed Aug 19 12:38:36 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8DF1A8A4F for ; Wed, 19 Aug 2015 12:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nxCp_VnPQENG for ; Wed, 19 Aug 2015 12:38:27 -0700 (PDT) Received: from mailout.cymru.com (mailout.cymru.com [38.229.36.8]) by ietfa.amsl.com (Postfix) with ESMTP id EE5051A8A55 for ; Wed, 19 Aug 2015 12:38:26 -0700 (PDT) Received: from localhost (vpn-72-33.svcs.ord07.cymru.com [172.16.72.33]) by mailout.cymru.com (Postfix) with ESMTP id 9717846EF6E; Wed, 19 Aug 2015 19:38:27 +0000 (GMT) Date: Wed, 19 Aug 2015 14:38:24 -0500 From: John Kristoff To: "Smith, Donald" Message-ID: <20150819143824.73ece3cf@localhost> In-Reply-To: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> References: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> User-Agent: Claws Mail MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 19:38:28 -0000 Hi Don, On Wed, 19 Aug 2015 19:06:25 +0000 "Smith, Donald" wrote: > I am not aware of anyone rate-limiting UDP itself. Specific ports > using UDP yes but not UDP as a protocol. As a specific IP protocol, it happens and it has happened. And not just with UDP. If you're not on NANOG, I described what was done in a university environment I was at years ago: While perhaps not on transit networks, some networks have UDP dropped by their upstream(s) or at their own "border", primarily as a means to mitigate all the UDP-based amplified reflection traffic they might otherwise have to carry. Its not very elegant perhaps, but it does happen and seemingly the trade-off some find to be worth it. John From nobody Wed Aug 19 12:54:04 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8EE1A8A16 for ; Wed, 19 Aug 2015 12:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 x0-0GBQdhVgI for ; Wed, 19 Aug 2015 12:54:00 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB97E1A8860 for ; Wed, 19 Aug 2015 12:54:00 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (emailout.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id t7JJrtqK009222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Aug 2015 13:53:55 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 35A631E007F; Wed, 19 Aug 2015 13:53:50 -0600 (MDT) Received: from lxomp07u.corp.intranet (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id ECDA41E006B; Wed, 19 Aug 2015 13:53:49 -0600 (MDT) Received: from lxomp07u.corp.intranet (localhost [127.0.0.1]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id t7JJrnSL014521; Wed, 19 Aug 2015 14:53:49 -0500 Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.ctl.intranet [151.119.128.28]) by lxomp07u.corp.intranet (8.14.8/8.14.8) with ESMTP id t7JJrnLl014518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Aug 2015 14:53:49 -0500 Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.03.0195.001; Wed, 19 Aug 2015 13:53:49 -0600 From: "Smith, Donald" To: John Kristoff Thread-Topic: [OPSEC] draft-byrne-opsec-udp-advisory Thread-Index: AQHQw07DSCNgsRs7E0ybKNITpVbCVZ3tYKMAgCZLzayAAJ7AAP//nARo Date: Wed, 19 Aug 2015 19:53:48 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> References: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet>, <20150819143824.73ece3cf@localhost> In-Reply-To: <20150819143824.73ece3cf@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.131] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-CFilter-Loop: Reflected Archived-At: Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 19:54:02 -0000 Thanks John, and universities are their own ISP sort of so I see how you re= late this. But I am not sure that supports their original statement about ISPs limitin= g udp. I have discussed this with several large ISPs. So far I haven't heard anyon= e advocating rate limiting UDP as a protocol. Now udp:123 upd:1900 yes, many of us are or will be rate limiting those. Things like udp:1900, a lan protocol, could even in theory even be dropped.= I know of no valid use of it over the Internet. RIPv1 same it is depreciated. However if they just said some networks may rate limit udp ... it would sti= ll cover the basic concept without making any false claims. If our enterprise started seeing a lot of udp reflective attacks I would re= commend this approach if we could limit it to a specific set of ports. H8Hz Donald.Smith@centurylink.com From: John Kristoff [jtk@cymru.com] Sent: Wednesday, August 19, 2015 1:38 PM To: Smith, Donald Cc: George, Wes; Ca By; opsec@ietf.org; draft-byrne-opsec-udp-advisory@tool= s.ietf.org Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory Hi Don, On Wed, 19 Aug 2015 19:06:25 +0000 "Smith, Donald" wrote: > I am not aware of anyone rate-limiting UDP itself. Specific ports > using UDP yes but not UDP as a protocol. As a specific IP protocol, it happens and it has happened. And not just with UDP. If you're not on NANOG, I described what was done in a university environment I was at years ago: While perhaps not on transit networks, some networks have UDP dropped by their upstream(s) or at their own "border", primarily as a means to mitigate all the UDP-based amplified reflection traffic they might otherwise have to carry. Its not very elegant perhaps, but it does happen and seemingly the trade-off some find to be worth it. John This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communicat= ion in error, please immediately notify the sender by reply e-mail and dest= roy all copies of the communication and any attachments. From nobody Wed Aug 19 13:05:14 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804E71A8F39 for ; Wed, 19 Aug 2015 13:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.212 X-Spam-Level: X-Spam-Status: No, score=-4.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 wHpV_Rue1csT for ; Wed, 19 Aug 2015 13:05:11 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 72AD61A1EF5 for ; Wed, 19 Aug 2015 13:05:11 -0700 (PDT) Received: from [10.0.0.137] (173-167-0-106-michigan.hfc.comcastbusiness.net [173.167.0.106]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 07760540935; Wed, 19 Aug 2015 16:05:09 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=utf-8 From: Jared Mauch In-Reply-To: <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> Date: Wed, 19 Aug 2015 16:05:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <408C7740-D9C3-47C0-984A-9AA30054DD4C@puck.nether.net> References: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> <20150819143824.73ece3cf@localhost> <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> To: Donald Smith X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 20:05:12 -0000 > On Aug 19, 2015, at 3:53 PM, Smith, Donald = wrote: >=20 > However if they just said some networks may rate limit udp ... it = would still cover the basic concept without making any false claims. > If our enterprise started seeing a lot of udp reflective attacks I = would recommend this approach if we could limit it to a specific set of = ports. We had to do these to mitigate issues and have some fairly generous = rate-limits compared to the observed traffic rates. While we don=E2=80=99t do UDP across the board, some of the attacks have = been creeping to make it more likely. - Jared= From nobody Wed Aug 19 13:08:14 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0C91AC3A2 for ; Wed, 19 Aug 2015 13:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 SITd7WbAtuUq for ; Wed, 19 Aug 2015 13:08:07 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 77AC31ABD3C for ; Wed, 19 Aug 2015 13:08:07 -0700 (PDT) Received: by qged69 with SMTP id d69so13333993qge.0 for ; Wed, 19 Aug 2015 13:08:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uGWVS07NEew8Ap1as4YTljXqkuXqdoAnUP+BHWCBHWg=; b=lf3EeAUZ5L7kWW1uILz+jOqyHwTpx7XYwOxPmBAILMlKoC+5whOtDVFHf68b/LQwPD fWvwcfK3GI04CTpMCZdR6whBFAx4eewq6MGlOWb+SOCWGyXqPBk5voILuEhGJ/oxATie NeP33lDZlG+MM0uwmxMjCfWtMZj4sDSOWTYxjcBgDJHblIafvuw7+DzBK1GPxNlwUcb1 jEv3rF6cXGprqbxjjnH0xpR7X3/hQJNHAqjZBiomPqvjhQyG7VI+EQ88xq7WmHArQeBH fDaFHxlZR+LDuTjhQTNF5DOBCLN6cUWU2I1dqLNBVWbMikHVkN/aEf2NpvEBs9Stpd5v TCUA== MIME-Version: 1.0 X-Received: by 10.140.130.196 with SMTP id 187mr28050953qhc.58.1440014886518; Wed, 19 Aug 2015 13:08:06 -0700 (PDT) Received: by 10.55.214.85 with HTTP; Wed, 19 Aug 2015 13:08:06 -0700 (PDT) In-Reply-To: <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> References: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> <20150819143824.73ece3cf@localhost> <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> Date: Wed, 19 Aug 2015 13:08:06 -0700 Message-ID: From: Ca By To: "Smith, Donald" Content-Type: multipart/alternative; boundary=001a1134f126c84743051daf977b Archived-At: Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 20:08:09 -0000 --001a1134f126c84743051daf977b Content-Type: text/plain; charset=UTF-8 On Wed, Aug 19, 2015 at 12:53 PM, Smith, Donald < Donald.Smith@centurylink.com> wrote: > Thanks John, and universities are their own ISP sort of so I see how you > relate this. > > But I am not sure that supports their original statement about ISPs > limiting udp. > I have discussed this with several large ISPs. So far I haven't heard > anyone advocating rate limiting UDP as a protocol. > Now udp:123 upd:1900 yes, many of us are or will be rate limiting those. > > As an edge network provider, i rely on my upstream backbone provide to stop my attachment circuit from getting saturated with UDP junk. Unfortunately, my upstream also sells a DDoS protection service and network based firewall service which cost north of 10x what i normally pay per meg. When i provide them with a list of ports, and then add some ports later, they refer me to said expensive products. If i give them a one-liner policer for UDP, then there is nothing much for me or them to manage. We have not discussed in 2 years in fact. > Things like udp:1900, a lan protocol, could even in theory even be > dropped. I know of no valid use of it over the Internet. > RIPv1 same it is depreciated. > > And Chargen, and SNMP, and ... > However if they just said some networks may rate limit udp ... it would > still cover the basic concept without making any false claims. > If our enterprise started seeing a lot of udp reflective attacks I would > recommend this approach if we could limit it to a specific set of ports. > > H8Hz > Donald.Smith@centurylink.com > > > > From: John Kristoff [jtk@cymru.com] > Sent: Wednesday, August 19, 2015 1:38 PM > To: Smith, Donald > Cc: George, Wes; Ca By; opsec@ietf.org; > draft-byrne-opsec-udp-advisory@tools.ietf.org > Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory > > > Hi Don, > > On Wed, 19 Aug 2015 19:06:25 +0000 > "Smith, Donald" wrote: > > > I am not aware of anyone rate-limiting UDP itself. Specific ports > > using UDP yes but not UDP as a protocol. > > As a specific IP protocol, it happens and it has happened. And not > just with UDP. If you're not on NANOG, I described what was done in > a university environment I was at years ago: > > > > While perhaps not on transit networks, some networks have UDP dropped > by their upstream(s) or at their own "border", primarily as a means to > mitigate all the UDP-based amplified reflection traffic they might > otherwise have to carry. > > Its not very elegant perhaps, but it does happen and seemingly the > trade-off some find to be worth it. > > John > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. > --001a1134f126c84743051daf977b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 19, 2015 at 12:53 PM, Smith, Donald <<= a href=3D"mailto:Donald.Smith@centurylink.com" target=3D"_blank">Donald.Smi= th@centurylink.com> wrote:
= Thanks John, and universities are their own ISP sort of so I see how you re= late this.

But I am not sure that supports their original statement about ISPs limitin= g udp.
I have discussed this with several large ISPs. So far I haven't heard a= nyone advocating rate limiting UDP as a protocol.
Now udp:123 upd:1900 yes, many of us are or will be rate limiting those.

As an edge network provider, i rely on= my upstream backbone provide to stop my attachment circuit from getting sa= turated with UDP junk.=C2=A0 Unfortunately, my upstream also sells a DDoS p= rotection service and network based firewall service which cost north of 10= x what i normally pay per meg.=C2=A0 When i provide them with a list of por= ts, and then add some ports later, they refer me to said expensive products= .

If i give them a one-liner policer for UDP, then= there is nothing much for me or them to manage.=C2=A0 We have not discusse= d in 2 years in fact.
=C2=A0
Things like udp:1900, a lan protocol, could even in theory even be dropped.= I know of no valid use of it over the Internet.
RIPv1 same it is depreciated.


And Chargen, and SNMP, and ...

=C2=A0
However if they just said some networks may rate limit udp ... it would sti= ll cover the basic concept without making any false claims.
If our enterprise started seeing a lot of udp reflective attacks I would re= commend this approach if we could limit it to a specific set of ports.

H8Hz
Donald.Smith@centurylink.co= m



From: John Kristoff [jtk@cymru.com] Sent: Wednesday, August 19, 2015 1:38 PM
To: Smith, Donald
Cc: George, Wes; Ca By; opsec@ietf.org; draft-b= yrne-opsec-udp-advisory@tools.ietf.org
Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory


Hi Don,

On Wed, 19 Aug 2015 19:06:25 +0000
"Smith, Donald" <Donald.Smith@CenturyLink.com> wrote:

> I am not aware of anyone rate-limiting UDP itself. Specific ports
> using UDP yes but not UDP as a protocol.

As a specific IP protocol, it happens and it has happened.=C2=A0 And not just with UDP.=C2=A0 If you're not on NANOG, I described what was done = in
a university environment I was at years ago:

=C2=A0 <https://mailman.nanog.org/= pipermail/nanog/2015-July/078010.html>

While perhaps not on transit networks, some networks have UDP dropped
by their upstream(s) or at their own "border", primarily as a mea= ns to
mitigate all the UDP-based amplified reflection traffic they might
otherwise have to carry.

Its not very elegant perhaps, but it does happen and seemingly the
trade-off some find to be worth it.

John
This communication is t= he property of CenturyLink and may contain confidential or privileged infor= mation. Unauthorized use of this communication is strictly prohibited and m= ay be unlawful. If you have received this communication in error, please im= mediately notify the sender by reply e-mail and destroy all copies of the c= ommunication and any attachments.

--001a1134f126c84743051daf977b-- From nobody Wed Aug 19 13:30:11 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15DB61ACCF4 for ; Wed, 19 Aug 2015 13:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 Ruf-eljZh5Mv for ; Wed, 19 Aug 2015 13:30:08 -0700 (PDT) Received: from mailout.cymru.com (mailout.cymru.com [38.229.36.8]) by ietfa.amsl.com (Postfix) with ESMTP id D9EAA1A8BB1 for ; Wed, 19 Aug 2015 13:30:08 -0700 (PDT) Received: from localhost (vpn-72-33.svcs.ord07.cymru.com [172.16.72.33]) by mailout.cymru.com (Postfix) with ESMTP id A94EA46EF47; Wed, 19 Aug 2015 20:30:08 +0000 (GMT) Date: Wed, 19 Aug 2015 15:30:06 -0500 From: John Kristoff To: "Smith, Donald" Message-ID: <20150819153006.2ebe5ad6@localhost> In-Reply-To: <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> References: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> <20150819143824.73ece3cf@localhost> <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> User-Agent: Claws Mail MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 20:30:10 -0000 On Wed, 19 Aug 2015 19:53:48 +0000 "Smith, Donald" wrote: > But I am not sure that supports their original statement about ISPs > limiting udp. I took the context of the discussion at face value. Also, if I'm not mistaken,the draft refers more generally to "network operators", which may include a whole class of networks. I'm not supportive of the draft's recommendation on that more general basis and I'm not aware of so-called transit ISPs that do this already, but there are networks and network operators that have and do rate limit at borders and throughout their network. Semantics. :-) > However if they just said some networks may rate limit udp ... it > would still cover the basic concept without making any false claims. That would be better I agree and if their was some discussion about the trade-offs of doing these sorts of things, and perhaps some discussion about the effects of them depending on where they reside, that might be helpful too. > If our enterprise started seeing a lot of udp reflective attacks I > would recommend this approach if we could limit it to a specific set > of ports. There is likely going to be some number of benign packets that are going to be dropped. Clients that just happen to pick the unlucky ephemeral value of 1900 (or whatever other unlucky value is being filtered) plus the occasional port selection by NAPT devices will be caught up in the packet dropping dragnet. Some people clearly don't mind this collateral damage and no amount of e2e talk will convince everyone. This too should be clearly spelled out so the trade-offs, potential problems and *sob* loss of transparency are documented. John From nobody Wed Aug 19 13:58:04 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383D21B2AF0; Wed, 19 Aug 2015 13:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 BuHLh0qfCUg0; Wed, 19 Aug 2015 13:57:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 81B611B2AEA; Wed, 19 Aug 2015 13:57:56 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZSAPg-0003XH-Vb; Wed, 19 Aug 2015 22:56:49 +0200 Message-ID: <55D4ED65.7020108@si6networks.com> Date: Wed, 19 Aug 2015 22:56:05 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Alissa Cooper , The IESG References: <20150819194657.7337.46107.idtracker@ietfa.amsl.com> In-Reply-To: <20150819194657.7337.46107.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org Subject: Re: [OPSEC] Alissa Cooper's No Objection on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 20:58:02 -0000 Hi, Alissa, Thanks so much fr your feedback! -- Please find my comments in-line.... On 08/19/2015 09:46 PM, Alissa Cooper wrote: > On the VMWare ESX example given in Sec. 3.1.1.1, the OUI given for > automatically-generated MAC addresses (00:05:59) does not seem correct. > In the linked documentation, it is listed as 00:0C:29. In the IEEE OUI > list, 00:0C:29 is registered to VMWare but 00:05:59 is registered to some > other company. You seem to be absolutely right :-?. I'll double-check and update as warranted. > In Sec. 3.1.1.3 and 3.1.1.4, I wonder if you might want to re-use the > terminology from draft-ietf-6man-ipv6-address-generation-privacy in the > section headings, in particular to differentiate "Constant" IIDs from > "Stable" IIDs. I think this would be better than using "Privacy-Enhanced" > as the term "privacy" is now overloaded when it comes to different types > of v6 addresses. Fully agree. Will update accordingly. > I think the tables in 3.1.5 would be a lot more useful if the table > captions noted the total number of addresses investigated (N). Not sure what you mean. Isn't it more meaningful to talk about percentages rather than number of addresses? > In Section 3.5, wouldn't using RFC 4941 addresses count as a mitigation > as well (first bullet)? Not really: The problem is that RFC4941 (temporary) addresses are configured *in addition* to the stable addresses. SO no matter how random the RFC4941 addresses are, they will not mitigate address scanning if your stable addresses are predictable. > Sections 5-13 seem like they belong as subsections of an overarching > section about "Other Network Reconnaissance Techniques" or some such. They are kind of "top level".... but since many of such sections are really short, I understand they could be thought of as "Other Network Reconnaissance Techniques" -- I will leave this one up to Tim (co-author). > It > might also help to provide some indication of how resource-intensive > these techniques might be relative to each other. These are hard to compare with each other. For instance, many of the "gleand information from the..." are not expensive at all: the information is just out there (as long as you have the necessary credentials). > There are other > application-specific ways of gathering information about active IP > addresses that aren't listed here (the example that comes to mind is an > attacker standing up a TURN server) but are probably also more trouble > than they're worth for most attackers, which is presumably why they are > not included in the list. Agreed. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Aug 19 15:41:48 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B87C1A8A29; Wed, 19 Aug 2015 15:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 aFX9vbTAlY_a; Wed, 19 Aug 2015 15:41:42 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 985711A8A3B; Wed, 19 Aug 2015 15:41:42 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZSC37-000530-Pb; Thu, 20 Aug 2015 00:41:38 +0200 Message-ID: <55D50617.2090403@si6networks.com> Date: Thu, 20 Aug 2015 00:41:27 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Alissa Cooper References: <20150819194657.7337.46107.idtracker@ietfa.amsl.com> <55D4ED65.7020108@si6networks.com> <6034066F-FEBD-4647-97EC-1753523D9AE8@cooperw.in> In-Reply-To: <6034066F-FEBD-4647-97EC-1753523D9AE8@cooperw.in> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org, IESG Subject: Re: [OPSEC] Alissa Cooper's No Objection on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 22:41:44 -0000 Hi, Alissa, On 08/20/2015 12:21 AM, Alissa Cooper wrote: >>> I think the tables in 3.1.5 would be a lot more useful if the >>> table captions noted the total number of addresses investigated >>> (N). >> >> Not sure what you mean. Isn't it more meaningful to talk about >> percentages rather than number of addresses? >> > > I meant the total number of addresses. Like, 6% of 100 hosts > investigated doesn’t mean much but 6% of a million hosts might. I > assume these totals are in the papers but it would be easier to > include them directly in the document. Or maybe I misunderstood what > the table data represents? All percentages are statistically significative... the measurements were performed based on ALexa's top 1M sites.... Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Aug 19 15:57:49 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398781A86E2; Wed, 19 Aug 2015 15:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 3gylcbPuDkF0; Wed, 19 Aug 2015 15:57:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C293B1A802A; Wed, 19 Aug 2015 15:57:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150819225743.2648.39186.idtracker@ietfa.amsl.com> Date: Wed, 19 Aug 2015 15:57:43 -0700 Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org Subject: [OPSEC] Stephen Farrell's Yes on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 22:57:45 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-opsec-ipv6-host-scanning-07: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - general: @Fernando: thank you for writing a document that does not recommend turning off IPv6:-) - general: shouldn't you recommend a honeynet approach as another way of spotting scans when there ought be none? That might fit in 3.5 I guess. - intro: what evidence is there that the number of hosts per subnet is likely to stay the same? (And what do you consider an IPv4 subnet here? a /16 is it? Maybe worth saying.) The density point still applies though, but good to not assume things that aren't needed. - 3.1.1 - I would recommend you check with Christian Huitema about Windows10 which has some new features related to MAC addresses. I don't know if there is new IPv6 handling associated with those changes. - 3.4.1 s/patters/patterns/ From nobody Wed Aug 19 16:20:12 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0DF1A00DB; Wed, 19 Aug 2015 16:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 twebsGm9rH2m; Wed, 19 Aug 2015 16:20:08 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [37.72.100.182]) (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 8A3741A8754; Wed, 19 Aug 2015 16:20:08 -0700 (PDT) Received: from [186.137.82.224] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZSCeJ-0005Gt-7Z; Thu, 20 Aug 2015 01:20:03 +0200 Message-ID: <55D50EAC.1040306@si6networks.com> Date: Thu, 20 Aug 2015 01:18:04 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Stephen Farrell , The IESG References: <20150819225743.2648.39186.idtracker@ietfa.amsl.com> In-Reply-To: <20150819225743.2648.39186.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org Subject: Re: [OPSEC] Stephen Farrell's Yes on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 23:20:11 -0000 Hi, Stephen, Thanks so much for your feedback! Please find my comments in-line.... On 08/20/2015 12:57 AM, Stephen Farrell wrote: > > - general: @Fernando: thank you for writing a document that does > not recommend turning off IPv6:-) (a comment on this one at the end of this emai :-) ) (*) > - general: shouldn't you recommend a honeynet approach as another > way of spotting scans when there ought be none? That might fit in > 3.5 I guess. The goal here is not to detect host scanning, but to perform it or mitigate them -- rather than detecting the host scanning attacks. > - intro: what evidence is there that the number of hosts per > subnet is likely to stay the same? (And what do you consider an > IPv4 subnet here? a /16 is it? Maybe worth saying.) The density > point still applies though, but good to not assume things that > aren't needed. What evidence there is that this is going to change? > - 3.1.1 - I would recommend you check with Christian Huitema > about Windows10 which has some new features related to MAC > addresses. I don't know if there is new IPv6 handling associated > with those changes. I will. > - 3.4.1 s/patters/patterns/ Will fix. (*) P.S.: You keep repeating this one :-), but the only document in which I noted that the unfortunate only possible approach might be to disable v6 at the time was RFC7359 (and in RFC7123, as one possible approach). As unfortunate as it was, it was correct. And there was a recent wave of press on this topic: with kind of sad comments about IPv6. I think our advice was timely, and in line with a quote from Bertrand Russell I like: "The intellectual thing I should want to say is this: When you are studying any matter, or considering any philosophy, ask yourself only what are the facts and what is the truth that the facts bear out. Never let yourself be diverted either by what you wish to believe, or by what you think would have beneficent social effects if it were believed. But look only, and solely, at what are the facts." Everything else I've authored has been about improvements, not "turning it off"... and for instance, I've been IPv6 enabled for years... ;-) Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Aug 19 16:28:22 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC451A87AD; Wed, 19 Aug 2015 16:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 unwkjIbG20Bg; Wed, 19 Aug 2015 16:28:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F071A8771; Wed, 19 Aug 2015 16:28:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 021D0BE77; Thu, 20 Aug 2015 00:28:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNBwMKftg3wB; Thu, 20 Aug 2015 00:28:12 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.22.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 515D7BE5D; Thu, 20 Aug 2015 00:28:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1440026892; bh=LXRj5o5tkbOhbOIx4rEjs9UWWt4/I+7YB7vYly7SD0Y=; h=Date:From:To:CC:Subject:References:In-Reply-To:From; b=4aztQpdRiv4oxAUlXSnerpbR+zo3FD4nyc8vesU+J81++anfLQWRjfmEntIVMMqlF 8lCslsUqwJlh+9gkGQcbwfJryXcTeQZNnww2/Vu8M4XBTQgxhZ5pvohQTazb5PK67y wfyYMo8dwjL+S8Byiwz3ZNusR08h4Jxdf/zXP/PM= Message-ID: <55D5110C.2080400@cs.tcd.ie> Date: Thu, 20 Aug 2015 00:28:12 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Fernando Gont , The IESG References: <20150819225743.2648.39186.idtracker@ietfa.amsl.com> <55D50EAC.1040306@si6networks.com> In-Reply-To: <55D50EAC.1040306@si6networks.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-opsec-ipv6-host-scanning.shepherd@ietf.org, draft-ietf-opsec-ipv6-host-scanning@ietf.org, draft-ietf-opsec-ipv6-host-scanning.ad@ietf.org, opsec@ietf.org, gunter@vandevelde.cc, opsec-chairs@ietf.org Subject: Re: [OPSEC] Stephen Farrell's Yes on draft-ietf-opsec-ipv6-host-scanning-07: (with COMMENT) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2015 23:28:19 -0000 On 20/08/15 00:18, Fernando Gont wrote: > Hi, Stephen, > > Thanks so much for your feedback! Please find my comments in-line.... > > On 08/20/2015 12:57 AM, Stephen Farrell wrote: >> >> - general: @Fernando: thank you for writing a document that does >> not recommend turning off IPv6:-) > > (a comment on this one at the end of this emai :-) ) (*) Fair enough. We can delve into that one over a beer sometime:-) >> - general: shouldn't you recommend a honeynet approach as another >> way of spotting scans when there ought be none? That might fit in >> 3.5 I guess. > > The goal here is not to detect host scanning, but to perform it or > mitigate them -- rather than detecting the host scanning attacks. I'd argue that detecting scanning is an entirely relevant mitigation. >> - intro: what evidence is there that the number of hosts per >> subnet is likely to stay the same? (And what do you consider an >> IPv4 subnet here? a /16 is it? Maybe worth saying.) The density >> point still applies though, but good to not assume things that >> aren't needed. > > What evidence there is that this is going to change? That's backwards. The draft makes a positive claim that the number of hosts per subnet won't change but that's not currently well-founded. I'd say just removing the unfounded claim would be easiest. Cheers, S. > > > >> - 3.1.1 - I would recommend you check with Christian Huitema >> about Windows10 which has some new features related to MAC >> addresses. I don't know if there is new IPv6 handling associated >> with those changes. > > I will. > > > >> - 3.4.1 s/patters/patterns/ > > Will fix. > > > (*) > > P.S.: You keep repeating this one :-), but the only document in which I > noted that the unfortunate only possible approach might be to disable v6 > at the time was RFC7359 (and in RFC7123, as one possible approach). > > As unfortunate as it was, it was correct. And there was a recent wave of > press on this topic: > > with kind of sad comments about IPv6. > > I think our advice was timely, and in line with a quote from Bertrand > Russell I like: > > "The intellectual thing I should want to say is this: When you are > studying any matter, or considering any philosophy, ask yourself only > what are the facts and what is the truth that the facts bear out. Never > let yourself be diverted either by what you wish to believe, or by what > you think would have beneficent social effects if it were believed. But > look only, and solely, at what are the facts." > > Everything else I've authored has been about improvements, not "turning > it off"... and for instance, I've been IPv6 enabled for years... ;-) > > > Thanks! > > Best regards, > From nobody Wed Aug 19 19:03:51 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9671A8BB7 for ; Wed, 19 Aug 2015 19:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ej7PAmyVRnzr for ; Wed, 19 Aug 2015 19:03:48 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 814041A8AF0 for ; Wed, 19 Aug 2015 19:03:48 -0700 (PDT) Received: from [10.101.107.186] (mobile-166-172-191-090.mycingular.net [166.172.191.90]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id DB8B9540AB4; Wed, 19 Aug 2015 22:03:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jared Mauch X-Mailer: iPhone Mail (12H321) In-Reply-To: <20150819153006.2ebe5ad6@localhost> Date: Wed, 19 Aug 2015 22:03:43 -0400 Content-Transfer-Encoding: 7bit Message-Id: <349043B2-F3DE-45D4-AEB2-D139E1C58C89@puck.nether.net> References: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> <20150819143824.73ece3cf@localhost> <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> <20150819153006.2ebe5ad6@localhost> To: John Kristoff Archived-At: Cc: "opsec@ietf.org" , "draft-byrne-opsec-udp-advisory@tools.ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 02:03:49 -0000 I can name two that do this in some part at least. Jared Mauch > On Aug 19, 2015, at 4:30 PM, John Kristoff wrote: > > I'm not aware of > so-called transit ISPs that do this already, From nobody Thu Aug 20 15:23:10 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316031B2C57 for ; Thu, 20 Aug 2015 15:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 kX9gpOA3N3fj for ; Thu, 20 Aug 2015 15:23:07 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 E12D11B2C55 for ; Thu, 20 Aug 2015 15:23:06 -0700 (PDT) Received: by qkbm65 with SMTP id m65so23174836qkb.2 for ; Thu, 20 Aug 2015 15:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=okm17kt0AhA/sdy8LqyJfkIiCtbfoNJi4ic5T6vHICM=; b=TWPPsEoxdd6vn1Uuv1/X0yrI4m2ufabxabT9BFCcEHU1eckXeS10lNdv4PMsJORAAx cL2bLu2pWzzb+DzMrS1kV0M/Vw4oISlQRzXYa2XxGDn94+0Zu+iYhoZJwpwAM1DFK4yk bo6qbbSq6PIgnu7B14i0kuFDBWnApPiasbsl5H0O57+Ws89VaINiJY/QpdormRozBA4J WyssoxQwjRwffyJnuSOgopGjDhwxLpAo7ML5wSBgj9dsHLQgoQ5DDIdZ55XVCs4jMwhq pDyUxF0LhHvm4g+i0cCxuZpTLUt4zPKn9o8BI5RJcCFRNNCnPobOFgD82s6SRdFULNNc f0gA== MIME-Version: 1.0 X-Received: by 10.55.212.13 with SMTP id l13mr10058601qki.29.1440109386047; Thu, 20 Aug 2015 15:23:06 -0700 (PDT) Received: by 10.55.214.85 with HTTP; Thu, 20 Aug 2015 15:23:05 -0700 (PDT) In-Reply-To: <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> References: <68EFACB32CF4464298EA2779B058889D3B25F38A@PDDCWMBXEX503.ctl.intranet> <20150819143824.73ece3cf@localhost> <68EFACB32CF4464298EA2779B058889D3B25F44F@PDDCWMBXEX503.ctl.intranet> Date: Thu, 20 Aug 2015 15:23:05 -0700 Message-ID: From: Ca By To: "Smith, Donald" Content-Type: multipart/alternative; boundary=001a1147a52064b2e8051dc598aa Archived-At: Cc: "draft-byrne-opsec-udp-advisory@tools.ietf.org" , "opsec@ietf.org" Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 22:23:09 -0000 --001a1147a52064b2e8051dc598aa Content-Type: text/plain; charset=UTF-8 On Wed, Aug 19, 2015 at 12:53 PM, Smith, Donald < Donald.Smith@centurylink.com> wrote: > Thanks John, and universities are their own ISP sort of so I see how you > relate this. > > But I am not sure that supports their original statement about ISPs > limiting udp. > I have discussed this with several large ISPs. So far I haven't heard > anyone advocating rate limiting UDP as a protocol. > Now udp:123 upd:1900 yes, many of us are or will be rate limiting those. > > Things like udp:1900, a lan protocol, could even in theory even be > dropped. I know of no valid use of it over the Internet. > RIPv1 same it is depreciated. > > However if they just said some networks may rate limit udp ... it would > still cover the basic concept without making any false claims. > If our enterprise started seeing a lot of udp reflective attacks I would > recommend this approach if we could limit it to a specific set of ports. > US CERT via a reference to Level3 has suggested that you may want to add UDP 111 to your list. https://www.us-cert.gov/ncas/alerts/TA14-017A http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-early-warning-to-the-industry/ The larger point being, you can have an ever growing constantly maintained list of after-the-fact ports that cause problems. Or, you can come to the conclusion that UDP is broadly abused >From the Level3 blog: "Global portmap traffic grew by a factor of 22x when comparing the last 7 days of June with the 7 days, ending August 12. Clearly the success of using this method for attacks is growing aggressively. " This fits in-line with what the I-D says: have a baseline for UDP and enforce it (providing a healthy margin of growth, which is well below 22x.) CB > H8Hz > Donald.Smith@centurylink.com > > > > From: John Kristoff [jtk@cymru.com] > Sent: Wednesday, August 19, 2015 1:38 PM > To: Smith, Donald > Cc: George, Wes; Ca By; opsec@ietf.org; > draft-byrne-opsec-udp-advisory@tools.ietf.org > Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory > > > Hi Don, > > On Wed, 19 Aug 2015 19:06:25 +0000 > "Smith, Donald" wrote: > > > I am not aware of anyone rate-limiting UDP itself. Specific ports > > using UDP yes but not UDP as a protocol. > > As a specific IP protocol, it happens and it has happened. And not > just with UDP. If you're not on NANOG, I described what was done in > a university environment I was at years ago: > > > > While perhaps not on transit networks, some networks have UDP dropped > by their upstream(s) or at their own "border", primarily as a means to > mitigate all the UDP-based amplified reflection traffic they might > otherwise have to carry. > > Its not very elegant perhaps, but it does happen and seemingly the > trade-off some find to be worth it. > > John > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender > by reply e-mail and destroy all copies of the communication and any > attachments. > --001a1147a52064b2e8051dc598aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 19, 2015 at 12:53 PM, Smith, Donald <<= a href=3D"mailto:Donald.Smith@centurylink.com" target=3D"_blank">Donald.Smi= th@centurylink.com> wrote:
= Thanks John, and universities are their own ISP sort of so I see how you re= late this.

But I am not sure that supports their original statement about ISPs limitin= g udp.
I have discussed this with several large ISPs. So far I haven't heard a= nyone advocating rate limiting UDP as a protocol.
Now udp:123 upd:1900 yes, many of us are or will be rate limiting those.
Things like udp:1900, a lan protocol, could even in theory even be dropped.= I know of no valid use of it over the Internet.
RIPv1 same it is depreciated.

However if they just said some networks may rate limit udp ... it would sti= ll cover the basic concept without making any false claims.
If our enterprise started seeing a lot of udp reflective attacks I would re= commend this approach if we could limit it to a specific set of ports.
<= /blockquote>

US CERT via a reference to Level3 has sugge= sted that you may want to add UDP 111 to your list.

https://www.us-= cert.gov/ncas/alerts/TA14-017A

http://blog.level3.com/security/a-new-ddos-= reflection-attack-portmapper-an-early-warning-to-the-industry/

The larger point being, you can have an ever growing c= onstantly maintained list of after-the-fact ports that cause problems.

Or, you can come to the conclusion that UDP is broadly= abused

From the Level3 blog:

=
"Global = portmap traffic grew by a factor of 22x when comparing the last 7 days of J= une with the 7 days, ending August 12.=C2=A0 Clearly the success of using t= his method for attacks is growing aggressively.=C2=A0"

This fits in-line with = what the I-D says: have a baseline for UDP and enforce it (providing a heal= thy margin of growth, which is well below 22x.)

CB

=

H8Hz
Donald.Smith@centurylink.co= m



From: John Kristoff [jtk@cymru.com] Sent: Wednesday, August 19, 2015 1:38 PM
To: Smith, Donald
Cc: George, Wes; Ca By; opsec@ietf.org; draft-b= yrne-opsec-udp-advisory@tools.ietf.org
Subject: Re: [OPSEC] draft-byrne-opsec-udp-advisory


Hi Don,

On Wed, 19 Aug 2015 19:06:25 +0000
"Smith, Donald" <Donald.Smith@CenturyLink.com> wrote:

> I am not aware of anyone rate-limiting UDP itself. Specific ports
> using UDP yes but not UDP as a protocol.

As a specific IP protocol, it happens and it has happened.=C2=A0 And not just with UDP.=C2=A0 If you're not on NANOG, I described what was done = in
a university environment I was at years ago:

=C2=A0 <https://mailman.nanog.org/= pipermail/nanog/2015-July/078010.html>

While perhaps not on transit networks, some networks have UDP dropped
by their upstream(s) or at their own "border", primarily as a mea= ns to
mitigate all the UDP-based amplified reflection traffic they might
otherwise have to carry.

Its not very elegant perhaps, but it does happen and seemingly the
trade-off some find to be worth it.

John
This communication is t= he property of CenturyLink and may contain confidential or privileged infor= mation. Unauthorized use of this communication is strictly prohibited and m= ay be unlawful. If you have received this communication in error, please im= mediately notify the sender by reply e-mail and destroy all copies of the c= ommunication and any attachments.

--001a1147a52064b2e8051dc598aa-- From nobody Thu Aug 20 15:34:54 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99C11B2C7C; Thu, 20 Aug 2015 15:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham 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 rM2hAeS8qgqs; Thu, 20 Aug 2015 15:34:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id CC53C1B2C97; Thu, 20 Aug 2015 15:34:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id AC6CA180207; Thu, 20 Aug 2015 15:34:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150820223420.AC6CA180207@rfc-editor.org> Date: Thu, 20 Aug 2015 15:34:20 -0700 (PDT) Archived-At: Cc: opsec@ietf.org, rfc-editor@rfc-editor.org Subject: [OPSEC] BCP 199, RFC 7610 on DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2015 22:34:52 -0000 A new Request for Comments is now available in online RFC libraries. BCP 199 RFC 7610 Title: DHCPv6-Shield: Protecting against Rogue DHCPv6 Servers Author: F. Gont, W. Liu, G. Van de Velde Status: Best Current Practice Stream: IETF Date: August 2015 Mailbox: fgont@si6networks.com, liushucheng@huawei.com, gunter.van_de_velde@alcatel-lucent.com Pages: 12 Characters: 26119 See Also: BCP 199 I-D Tag: draft-ietf-opsec-dhcpv6-shield-08.txt URL: https://www.rfc-editor.org/info/rfc7610 DOI: http://dx.doi.org/10.17487/RFC7610 This document specifies a mechanism for protecting hosts connected to a switched network against rogue DHCPv6 servers. It is based on DHCPv6 packet filtering at the layer 2 device at which the packets are received. A similar mechanism has been widely deployed in IPv4 networks ('DHCP snooping'); hence, it is desirable that similar functionality be provided for IPv6 networks. This document specifies a Best Current Practice for the implementation of DHCPv6-Shield. This document is a product of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Mon Aug 24 07:55:16 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1CC11A1B34 for ; Mon, 24 Aug 2015 07:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 syBtgHXXQ4cE for ; Mon, 24 Aug 2015 07:55:14 -0700 (PDT) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 AB30A1A1B2E for ; Mon, 24 Aug 2015 07:55:14 -0700 (PDT) Received: by igcse8 with SMTP id se8so49075766igc.1 for ; Mon, 24 Aug 2015 07:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=90T5ddTxCZWkDWEf+Pe7d7uIUcYbblSKKt16gsDpTCI=; b=m+y8djuwvF6pG6wXiC7gCq+R7a9IgdDDAUWIJQFjseGuPlyM16ICNG+sOTP0R4xiIE g3ByN/0A+U+XkGkla4q2z4Jbtx8Bgdw/TnPJWAF/Ygfbx4ql9AA5VaUezQYOTnnLT9pq KlEVgMzvNDUgW9DoWnsAcmq2gmFFJ9KjCCXM+SsWBA4LpzLnfD+7vMozWIz0EzOspDyk DgNsWH2BXWG2mmnoWcCecsObz97pi7JJ19xQVBarAoT17Z4QqMu2MksRgpTEvfehhnlE z5UK9fOMshY64Sj6B8HZsB+5FbRNcSw9uJb2MXqnf8EBHVDwcDyy8BgU+0rk7DCytQFY 7NcQ== X-Received: by 10.50.117.8 with SMTP id ka8mr3451727igb.68.1440428114100; Mon, 24 Aug 2015 07:55:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.34.196 with HTTP; Mon, 24 Aug 2015 07:54:54 -0700 (PDT) From: KK Chittimaneni Date: Mon, 24 Aug 2015 07:54:54 -0700 Message-ID: To: opsec@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [OPSEC] Stepping down as OPSEC co-chair X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 14:55:15 -0000 Hi All, Due to some personal reasons, I will be stepping down as OPSEC co-chair. I=E2=80=99d like to thank everyone for the opportunity to have served as on= e of your co-chairs. I have had a great time doing this, and think that we've made some good progress. I leave the WG in the capable hands of Gunter. Once again, thank you all for making this a fun and interesting working gro= up. Regards, KK From nobody Fri Aug 28 05:31:10 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3BF1B2D1C; Fri, 28 Aug 2015 05:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 54qdx0AYoLRd; Fri, 28 Aug 2015 05:31:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A85A71B2EC4; Fri, 28 Aug 2015 05:30:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150828123057.2873.98321.idtracker@ietfa.amsl.com> Date: Fri, 28 Aug 2015 05:30:57 -0700 Archived-At: Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-host-scanning-08.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2015 12:31:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Network Reconnaissance in IPv6 Networks Authors : Fernando Gont Tim Chown Filename : draft-ietf-opsec-ipv6-host-scanning-08.txt Pages : 35 Date : 2015-08-28 Abstract: IPv6 offers a much larger address space than that of its IPv4 counterpart. An IPv6 subnet of size /64 can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than is typical in IPv4 networks, where a site typically has 65,000 or less unique addresses. As a result, it is widely assumed that it would take a tremendous effort to perform address scanning attacks against IPv6 networks, and therefore brute-force IPv6 address scanning attacks have been considered unfeasible. This document formally obsoletes RFC 5157, which first discussed this assumption, by providing further analysis on how traditional address scanning techniques apply to IPv6 networks, and exploring some additional techniques that can be employed for IPv6 network reconnaissance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-host-scanning/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-opsec-ipv6-host-scanning-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-ipv6-host-scanning-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 28 19:39:08 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A101B32E0 for ; Fri, 28 Aug 2015 19:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1a7UWLY9p1MK for ; Fri, 28 Aug 2015 19:39:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B081B325D for ; Fri, 28 Aug 2015 19:39:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAN94139; Sat, 29 Aug 2015 02:39:04 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.235.1; Sat, 29 Aug 2015 03:39:03 +0100 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.156]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Sat, 29 Aug 2015 10:38:59 +0800 From: "Liushucheng (Will)" To: KK Chittimaneni , "opsec@ietf.org" Thread-Topic: [OPSEC] Stepping down as OPSEC co-chair Thread-Index: AQHQ3nzoQ4bqlCDjr0OQxqyV60ZikJ4iSLvw Date: Sat, 29 Aug 2015 02:38:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.84] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [OPSEC] Stepping down as OPSEC co-chair X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 02:39:07 -0000 VGhhbmsgeW91IEtLIGZvciB5b3VyIGVmZm9ydHMgYW5kIGd1aWRhbmNlLCBhcyB3ZWxsIGFzIHRo ZSB3b25kZXJmdWwgcHJvZ3Jlc3MgdGhhdCB5b3UgYW5kIEd1bnRlciBtYWRlIGhhcHBlbiENCg0K UmVnYXJkcywNCldpbGwgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog T1BTRUMgW21haWx0bzpvcHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS0sgQ2hp dHRpbWFuZW5pDQo+IFNlbnQ6IE1vbmRheSwgQXVndXN0IDI0LCAyMDE1IDEwOjU1IFBNDQo+IFRv OiBvcHNlY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbT1BTRUNdIFN0ZXBwaW5nIGRvd24gYXMgT1BT RUMgY28tY2hhaXINCj4gDQo+IEhpIEFsbCwNCj4gDQo+IER1ZSB0byBzb21lIHBlcnNvbmFsIHJl YXNvbnMsIEkgd2lsbCBiZSBzdGVwcGluZyBkb3duIGFzIE9QU0VDIGNvLWNoYWlyLg0KPiANCj4g SeKAmWQgbGlrZSB0byB0aGFuayBldmVyeW9uZSBmb3IgdGhlIG9wcG9ydHVuaXR5IHRvIGhhdmUg c2VydmVkIGFzIG9uZSBvZiB5b3VyDQo+IGNvLWNoYWlycy4gSSBoYXZlIGhhZCBhIGdyZWF0IHRp bWUgZG9pbmcgdGhpcywgYW5kIHRoaW5rIHRoYXQgd2UndmUgbWFkZSBzb21lDQo+IGdvb2QgcHJv Z3Jlc3MuIEkgbGVhdmUgdGhlIFdHIGluIHRoZSBjYXBhYmxlIGhhbmRzIG9mIEd1bnRlci4NCj4g DQo+IE9uY2UgYWdhaW4sIHRoYW5rIHlvdSBhbGwgZm9yIG1ha2luZyB0aGlzIGEgZnVuIGFuZCBp bnRlcmVzdGluZyB3b3JraW5nIGdyb3VwLg0KPiANCj4gUmVnYXJkcywNCj4gS0sNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE9QU0VDIG1h aWxpbmcgbGlzdA0KPiBPUFNFQ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL29wc2VjDQo= From nobody Sat Aug 29 14:04:37 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 131EE1A3BA1 for ; Sat, 29 Aug 2015 14:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1uGKvv953L_U for ; Sat, 29 Aug 2015 14:04:34 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 D53F91A0370 for ; Sat, 29 Aug 2015 14:04:34 -0700 (PDT) Received: from mb.local ([IPv6:2601:647:4200:7a31:143b:716:a08f:81ad]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t7TL4Xd8046033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 29 Aug 2015 21:04:33 GMT (envelope-from joelja@bogus.com) To: KK Chittimaneni , opsec@ietf.org References: From: joel jaeggli Message-ID: <55E21E61.3070405@bogus.com> Date: Sat, 29 Aug 2015 14:04:33 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="50k6gKgo68LApejTmAc8B0jROgtoL5mJH" Archived-At: Subject: Re: [OPSEC] Stepping down as OPSEC co-chair X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Aug 2015 21:04:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --50k6gKgo68LApejTmAc8B0jROgtoL5mJH Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the steady hand in OPSEC. you contribution and judgement especially when it comes to shepherding documents has been greatly appreciated. joel On 8/24/15 7:54 AM, KK Chittimaneni wrote: > Hi All, >=20 > Due to some personal reasons, I will be stepping down as OPSEC co-chair= =2E >=20 > I=E2=80=99d like to thank everyone for the opportunity to have served a= s one > of your co-chairs. I have had a great time doing this, and think that > we've made some good progress. I leave the WG in the capable hands > of Gunter. >=20 > Once again, thank you all for making this a fun and interesting working= group. >=20 > Regards, > KK >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --50k6gKgo68LApejTmAc8B0jROgtoL5mJH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXiHmEACgkQ8AA1q7Z/VrLZgACeMt3irFQS2HDzqWBn/3Xbca2o pjYAnjlfncCQpf2nrnlIrEz4JYUMqMCh =uLBA -----END PGP SIGNATURE----- --50k6gKgo68LApejTmAc8B0jROgtoL5mJH-- From nobody Mon Aug 31 08:37:39 2015 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345141A8726 for ; Mon, 31 Aug 2015 08:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 1NJBVCGBkR8J for ; Mon, 31 Aug 2015 08:37:33 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 015121B3301 for ; Mon, 31 Aug 2015 08:33:40 -0700 (PDT) Received: from mb.local ([IPv6:2601:647:4200:7a31:24:ae63:c13d:4dfb]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id t7VFXdcP097067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 31 Aug 2015 15:33:40 GMT (envelope-from joelja@bogus.com) To: "opsec@ietf.org" , opsec chairs From: joel jaeggli X-Enigmail-Draft-Status: N1110 Message-ID: <55E473D2.6050503@bogus.com> Date: Mon, 31 Aug 2015 08:33:38 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Thunderbird/40.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WrlFV6xaScRABrBP3kOl6SgrL0igkJl1q" Archived-At: Subject: [OPSEC] Seeking volunteers - opsec w.g. co-chair. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2015 15:37:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WrlFV6xaScRABrBP3kOl6SgrL0igkJl1q Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Folks, We have have a vacancy for the role of opsec co-chair serving alongside gunter. Opsec interest and involvement has varried by interest and intensity over time. In the interest of finding someone currently interested in the topic I figured I would solicit volunteers. If you're interested and have the time (opsec is a fairly low intensity wg) please contact me offlist and we'll amke a decision in a couple of weeks.= thanks joel --WrlFV6xaScRABrBP3kOl6SgrL0igkJl1q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlXkc9MACgkQ8AA1q7Z/VrIppQCdGfgwAh8QhJ2cf0rKQc8lOGQJ PNYAnjhVky+vGIeVnoIYjYtY2zFKA1D9 =CXcB -----END PGP SIGNATURE----- --WrlFV6xaScRABrBP3kOl6SgrL0igkJl1q--