From nobody Wed Oct 8 03:20:46 2014 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 22CB11A017C for ; Wed, 8 Oct 2014 03:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, 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 TSWpo0df-TJs for ; Wed, 8 Oct 2014 03:20:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8F31A016A for ; Wed, 8 Oct 2014 03:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=940; q=dns/txt; s=iport; t=1412763639; x=1413973239; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=XPfai/r2q6a9bcfexVNhGhPkmmh9uXc4+GVt+xkJXJA=; b=cHaJZ9m+JgoDx4h6TZ/z1gFDigGFN4nZI/T8rMcwj9qQr0zZIsr4pq8V E60kQKC2j2xWBpUC2o0xxfKBzCi03hc9BtjrsM4rUVmZ0E+++tPVuoCYt luPq/UdekQ0fK/upHW7FN9VLGONzLaYSiRWXK5yYqbH5KlMZ6NNp/0gqV I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcGALQONVStJA2H/2dsb2JhbABfgw5TWATLHYdNAoEKFgFyCYQDAQEBBB1cDAYBCBEEAQELGT0dCQEEDgUIiDYNwg4BF5ATMQ2DJ4EeBYsehlmEPog8PIMIjRqDf4IggUNsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,676,1406592000"; d="scan'208";a="361552863" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 08 Oct 2014 10:20:38 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s98AKcn5024500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 10:20:38 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.120]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 05:20:38 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers Thread-Index: Ac/X2IHCixEQiP9WSwO6zL/lhjHmPQLB7Pww Date: Wed, 8 Oct 2014 10:20:38 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2411C57127@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.199.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/W2pjCeX4VdtVJaZB4AyNIlz8POs Cc: "v6ops-chairs@tools.ietf.org" Subject: Re: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 08 Oct 2014 10:20:41 -0000 Dear all, Many thanks for your input on this request. OPSEC chairs will look at the received input and see together with the v6op= s chairs how the IPv6 EH work could progress. =20 Kind Regards, G/ -----Original Message----- From: Gunter Van de Velde (gvandeve)=20 Sent: 24 September 2014 11:28 To: opsec@ietf.org Subject: Call for WG adoption - Recommendations on Filtering of IPv6 Packet= s Containing IPv6 Extension Headers Dear, =A0 Please find this request for WG adoption for "Recommendations on Filtering = of IPv6 Packets Containing IPv6 Extension Headers" The authors of the work explicitly asked for "Call for WG adoption" in its = current state.=20 =A0 Latest draft can be found at: http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02=A0 (1) Do you support for adopting the draft as OPSEC WG item? This call for WG adoption will end 8 October 2014. Kind Regards, OPSEC chairs From nobody Wed Oct 8 16:41:13 2014 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 6D8AA1A8721 for ; Wed, 8 Oct 2014 16:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 HgGXvhLs2vx6 for ; Wed, 8 Oct 2014 16:41:04 -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 92A271A8702 for ; Wed, 8 Oct 2014 16:41:03 -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 BNL20711; Wed, 08 Oct 2014 23:41:01 +0000 (GMT) Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 9 Oct 2014 00:41:00 +0100 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.57]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 07:40:56 +0800 From: Tina TSOU To: "Gunter Van de Velde (gvandeve)" Thread-Topic: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers Thread-Index: AQHP41FO/867e3ppREu02VlapYCY8g== Date: Wed, 8 Oct 2014 23:40:57 +0000 Message-ID: References: <67832B1175062E48926BF3CB27C49B2411C57127@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2411C57127@xmb-aln-x12.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AC7C8DF650EB45E6AD616ADDCAD6249Fhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Icfbq2loVUx6c-PIHNNO5PrEUlM Cc: "opsec@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 08 Oct 2014 23:41:11 -0000 --_000_AC7C8DF650EB45E6AD616ADDCAD6249Fhuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I support adoption of this document as an opsec item. It seems like sensibl= e follow-up to the work done in RFC7126 for IPv4. Thank you, Tina On Oct 8, 2014, at 6:20 PM, Gunter Van de Velde (gvandeve) > wrote: Dear all, Many thanks for your input on this request. OPSEC chairs will look at the received input and see together with the v6op= s chairs how the IPv6 EH work could progress. Kind Regards, G/ -----Original Message----- From: Gunter Van de Velde (gvandeve) Sent: 24 September 2014 11:28 To: opsec@ietf.org Subject: Call for WG adoption - Recommendations on Filtering of IPv6 Packet= s Containing IPv6 Extension Headers Dear, Please find this request for WG adoption for "Recommendations on Filtering = of IPv6 Packets Containing IPv6 Extension Headers" The authors of the work explicitly asked for "Call for WG adoption" in its = current state. Latest draft can be found at: http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02 (1) Do you support for adopting the draft as OPSEC WG item? This call for WG adoption will end 8 October 2014. Kind Regards, OPSEC chairs _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --_000_AC7C8DF650EB45E6AD616ADDCAD6249Fhuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear all,

I support ad= option of this document as an opsec item. It seems like sensible follo= w-up to the work done in RFC7126 for IPv4.


Thank you,
Tina

On Oct 8, 2014, at 6:20 PM, Gunter Van de Velde (gvandeve) <gvandeve@cisco.com> wrote:

Dear all,

Many thanks for your input on this request.
OPSEC chairs will look at the received input and see together with th= e v6ops chairs how the IPv6 EH work could progress.

Kind Regards,
G/


-----Original Message-----
From: Gunter Van de Velde (gvandeve)
Sent: 24 September 2014 11:28
To: opsec@ietf.org
Subject: Call for WG adoption - Recommendations on Filtering of IPv6 = Packets Containing IPv6 Extension Headers

Dear,
 
Please find this request for WG adoption for "Recommendations on= Filtering of IPv6 Packets Containing IPv6 Extension Headers" The authors of the work explicitly asked for "Call for WG adopti= on" in its current state.
 
Latest draft can be found at:
http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02 

(1) Do you support for adopting the draft as OPSEC WG item?
This call for WG adoption will end 8 October 2014.

Kind Regards,
OPSEC chairs

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.i= etf.org/mailman/listinfo/opsec
--_000_AC7C8DF650EB45E6AD616ADDCAD6249Fhuaweicom_-- From nobody Thu Oct 9 06:24:17 2014 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 E8F781ACF73 for ; Thu, 9 Oct 2014 06:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 r10y-Vz0EpbZ for ; Thu, 9 Oct 2014 06:24:00 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 097621ACF86 for ; Thu, 9 Oct 2014 06:18:46 -0700 (PDT) Received: (qmail 22257 invoked from network); 9 Oct 2014 06:18:44 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Oct 2014 06:18:44 -0700 Date: Thu, 9 Oct 2014 06:18:44 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: OPSEC In-Reply-To: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> Message-ID: References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-2133786286-1261731555-1412860724=:20912" Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/QfT5nzpY0RTf4qZZFLxhyXulZfY Subject: Re: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 09 Oct 2014 13:24:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---2133786286-1261731555-1412860724=:20912 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT On Wed, 24 Sep 2014, Gunter Van de Velde (gvandeve) wrote: > Please find this request for WG adoption for "Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers" > The authors of the work explicitly asked for "Call for WG adoption" in its current state. > > Latest draft can be found at: > http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02  > > (1) Do you support for adopting the draft as OPSEC WG item? > > This call for WG adoption will end 8 October 2014. I support adoption, and I apologise for sending this message after the deadline. //cmh ---2133786286-1261731555-1412860724=:20912-- From nobody Thu Oct 9 21:59:23 2014 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 30F6C1A0146; Thu, 9 Oct 2014 21:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 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, MIME_BASE64_TEXT=1.741, 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 rz5R8YnnAzvh; Thu, 9 Oct 2014 21:59:20 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0351A0103; Thu, 9 Oct 2014 21:59:20 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id lf10so1015201pab.30 for ; Thu, 09 Oct 2014 21:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:mime-version:message-id :content-type:content-transfer-encoding; bh=TrjpQfp2up6VfYBCTzDScd3g7Gkzsv43hlZ0lHxNzvU=; b=PCQ2RaOL2j6lF+fSeoOPzaf7XahLiF2PCcFjkZCpN8W4ln08/FsTqSDL67YWipS/Yx icZGDZgtoFDufROIFCBiXIt08rShIEbXGhKXiTtwL32kq7hV+jWhLPXhxjkcXihC32hf UH7ZXgtAp8SKu2FHfMrny4XUBJMGRLKlUyDyvW2PJsGTPQtKKqQ8Gfzo4ulZd2eNRTKW aw2CmOmehVIU7kro861opDJU0Wuv1kM4gWm91LwGaz+tuMl7KsYdL/tGFgedFHJAI3r/ 8oJHRw1tY6PGXg6wUUXfpJYqRxqzpUBbUnlLAWFpfEjuFrFJsV99SIfsrc2cTxX3Ea/z g54g== X-Received: by 10.69.17.234 with SMTP id gh10mr2780718pbd.0.1412917160470; Thu, 09 Oct 2014 21:59:20 -0700 (PDT) Received: from netlab-PC ([166.111.68.231]) by mx.google.com with ESMTPSA id rj8sm2076070pdb.55.2014.10.09.21.59.16 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 09 Oct 2014 21:59:19 -0700 (PDT) Date: Fri, 10 Oct 2014 12:59:17 +0800 From: "Yuchi Chen" To: gvandeve X-Priority: 3 X-GUID: 5CDC0BB9-3AAF-4FB9-A566-40DFC379B51B X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201410101259128179113@gmail.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/1zuSVCGMr1JAdYTnj3kICqbVDus Cc: v6ops , opsec Subject: Re: [OPSEC] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chenycmx List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 04:59:22 -0000 SGkgYWxsLA0KIA0KSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBmb3IgdGhpcyBkcmFmdC4gSU1PLCB0 aGlzIHNlZW1zIGxpa2UgdGltZWx5IGFkdmljZSBjb25jZXJuaW5nIHRoZSByZWNlbnQgZGF0YSBv biBmaWx0ZXJpbmcgb2YgcGFja2V0cyB3aXRoIGV4dGVuc2lvbiBoZWFkZXJzLg0KDQpCZXN0IHJl Z2FyZHMhDQotLS0tLS0tLS0tLS0tLQ0KWXVjaGkgQ2hlbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBPUFNFQyBbbWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBHdW50ZXIgVmFuIGRlIFZlbGRlIChndmFuZGV2ZSkNClNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciAwOCwgMjAxNCA2OjIxIFBNDQpUbzogb3BzZWNAaWV0Zi5vcmcNCkNjOiB2Nm9w cy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbT1BTRUNdIENhbGwgZm9yIFdH IGFkb3B0aW9uIC0gUmVjb21tZW5kYXRpb25zIG9uIEZpbHRlcmluZyBvZiBJUHY2IFBhY2tldHMg Q29udGFpbmluZyBJUHY2IEV4dGVuc2lvbiBIZWFkZXJzDQogDQpEZWFyIGFsbCwNCiANCk1hbnkg dGhhbmtzIGZvciB5b3VyIGlucHV0IG9uIHRoaXMgcmVxdWVzdC4NCk9QU0VDIGNoYWlycyB3aWxs IGxvb2sgYXQgdGhlIHJlY2VpdmVkIGlucHV0IGFuZCBzZWUgdG9nZXRoZXIgd2l0aCB0aGUgdjZv cHMgY2hhaXJzIGhvdyB0aGUgSVB2NiBFSCB3b3JrIGNvdWxkIHByb2dyZXNzLg0KIA0KS2luZCBS ZWdhcmRzLA0KRy8NCiANCiANCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBHdW50 ZXIgVmFuIGRlIFZlbGRlIChndmFuZGV2ZSkgDQpTZW50OiAyNCBTZXB0ZW1iZXIgMjAxNCAxMToy OA0KVG86IG9wc2VjQGlldGYub3JnDQpTdWJqZWN0OiBDYWxsIGZvciBXRyBhZG9wdGlvbiAtIFJl Y29tbWVuZGF0aW9ucyBvbiBGaWx0ZXJpbmcgb2YgSVB2NiBQYWNrZXRzIENvbnRhaW5pbmcgSVB2 NiBFeHRlbnNpb24gSGVhZGVycw0KIA0KRGVhciwNCiANClBsZWFzZSBmaW5kIHRoaXMgcmVxdWVz dCBmb3IgV0cgYWRvcHRpb24gZm9yICJSZWNvbW1lbmRhdGlvbnMgb24gRmlsdGVyaW5nIG9mIElQ djYgUGFja2V0cyBDb250YWluaW5nIElQdjYgRXh0ZW5zaW9uIEhlYWRlcnMiDQpUaGUgYXV0aG9y cyBvZiB0aGUgd29yayBleHBsaWNpdGx5IGFza2VkIGZvciAiQ2FsbCBmb3IgV0cgYWRvcHRpb24i IGluIGl0cyBjdXJyZW50IHN0YXRlLiANCiANCkxhdGVzdCBkcmFmdCBjYW4gYmUgZm91bmQgYXQ6 DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nb250LW9wc2VjLWlwdjYtZWgtZmls dGVyaW5nLTAyIA0KIA0KKDEpIERvIHlvdSBzdXBwb3J0IGZvciBhZG9wdGluZyB0aGUgZHJhZnQg YXMgT1BTRUMgV0cgaXRlbT8NCiANClRoaXMgY2FsbCBmb3IgV0cgYWRvcHRpb24gd2lsbCBlbmQg OCBPY3RvYmVyIDIwMTQuDQogDQpLaW5kIFJlZ2FyZHMsDQpPUFNFQyBjaGFpcnMNCiANCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpPUFNFQyBtYWlsaW5n IGxpc3QNCk9QU0VDQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2VjDQo= From nobody Mon Oct 13 00:09:47 2014 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 0F07A1A88B8; Mon, 13 Oct 2014 00:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 GVPYXJOdvZkW; Mon, 13 Oct 2014 00:09:43 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C174E1A88B7; Mon, 13 Oct 2014 00:09:43 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 5480FA2; Mon, 13 Oct 2014 09:09:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413184182; bh=Zi+2HUs7osJLXnyvwxcUB0fhNs/A0NdHtZDNT2y8G18=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=QTQ8vLSOkxK7ZPCiSkmqpoxC0hOLGt31dYko7l1YpwRF7npkXaSdg5B5ZMGP84HFo dvLrepntDjGMtCnuAplWUHulYxfLe45PskhhgMQiZlNyJKnnLPJ7DXIA3NTkaKTNcw Jq6mTevTUvF089XqXIbpEK3XMXgIFtMKp4DFetVk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 4A242A1; Mon, 13 Oct 2014 09:09:42 +0200 (CEST) Date: Mon, 13 Oct 2014 09:09:42 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan In-Reply-To: <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/3jvighlo7UKgP7XH0ktrfex6kvk Cc: opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 13 Oct 2014 07:09:45 -0000 On Mon, 13 Oct 2014, Ole Troan wrote: > shouldn't this be a draft authored by operators? giving operational > recommendations coming out of... well, actual operations? Well, another way of looking at this is that operators just want things to work as well as they can, so they need guidance from vendors and protocol designers. Isn't this a BCOP style document? I believe at least one of the authors is active in one or more BCOP group. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 13 00:32:00 2014 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 8A4C81A88B9; Mon, 13 Oct 2014 00:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.223 X-Spam-Level: X-Spam-Status: No, score=-3.223 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 geltaRjASGVL; Mon, 13 Oct 2014 00:31:56 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12511A88B7; Mon, 13 Oct 2014 00:31:56 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1FD46A2; Mon, 13 Oct 2014 09:31:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1413185515; bh=C93cgaL71FWfshnw2cV7UkBeS+OK7DzylvzHdzVUUv8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WOQjD+g8DhFCu7GWEtIfiR25PtwdhFD1voTmzW4zrn+6SGTWSMuGt469xSaeDbZP4 pUmyScwRbWyk5nSHyPWitAA4P3V9D8AwaHPebyqc+rcm6jwyWe2mEZMe4zsBNIbYhr K4UhPAIaA4xcvrjDtSvBkIrtlU33n+S136VYaOEE= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 15056A1; Mon, 13 Oct 2014 09:31:55 +0200 (CEST) Date: Mon, 13 Oct 2014 09:31:55 +0200 (CEST) From: Mikael Abrahamsson To: Ole Troan In-Reply-To: Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/KgfNHdbQbmCXtW4keANj5qRLKXc Cc: opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 13 Oct 2014 07:31:58 -0000 On Mon, 13 Oct 2014, Ole Troan wrote: >>> shouldn't this be a draft authored by operators? giving operational recommendations coming out of... well, actual operations? >> >> Well, another way of looking at this is that operators just want things to work as well as they can, so they need guidance from vendors and protocol designers. >> >> Isn't this a BCOP style document? I believe at least one of the authors is active in one or more BCOP group. > > the protocol designer's recommendation does appear pretty clear, RFC2460: > > "With one exception, extension headers are not examined or processed > by any node along a packet's delivery path, until the packet reaches > the node (or each of the set of nodes, in the case of multicast) > identified in the Destination Address field of the IPv6 header." > > my point is that I don't think the IETF should be making recommendations about how they should run their network, and certainly not make recommendations that are at odds with the functioning of the protocol. You mean you don't want non-operators in the IETF to make recommendations? The way I see it is that vendors are making equipment based on customer requirements. Since a lot of vendor equipment obviously inspect packets, including those with extension headers along the way (probably to do ACLs), then this equipment is already violating the functioning of the protocol (which of course is nothing new). My opinion is that it's better to look at common implementation and document and give recommendations where this differs from the blueprints. What I don't like is that if we follow along this path we're basically saying "extension headers don't work on the Internet" which has the implication that fewer will use them, meaning the vendors that don't follow the protocol designer intention has little downside, and thus perpetuating the problem. I don't know how to make it right though. I would like to see extension headers working well, but I also understand that people want to be able to do filtering. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Oct 13 07:38:11 2014 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 E416C1A010A for ; Mon, 13 Oct 2014 07:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 gSxvpAx_S81P for ; Mon, 13 Oct 2014 07:38:05 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120DD1A0107 for ; Mon, 13 Oct 2014 07:38:05 -0700 (PDT) Received: (qmail 1234 invoked from network); 13 Oct 2014 07:38:02 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Oct 2014 07:38:02 -0700 Date: Mon, 13 Oct 2014 07:38:02 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Mikael Abrahamsson In-Reply-To: Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/VeOrgK5QCOUo5-DYhaxvf028JlY Cc: Ole Troan , opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 13 Oct 2014 14:38:06 -0000 On Mon, 13 Oct 2014, Mikael Abrahamsson wrote: > On Mon, 13 Oct 2014, Ole Troan wrote: > > > > shouldn't this be a draft authored by operators? giving operational > > > > recommendations coming out of... well, actual operations? > > > > > > Well, another way of looking at this is that operators just want things to > > > work as well as they can, so they need guidance from vendors and protocol > > > designers. > > > > > > Isn't this a BCOP style document? I believe at least one of the authors is > > > active in one or more BCOP group. > > > > the protocol designer's recommendation does appear pretty clear, RFC2460: > > > > "With one exception, extension headers are not examined or processed > > by any node along a packet's delivery path, until the packet reaches > > the node (or each of the set of nodes, in the case of multicast) > > identified in the Destination Address field of the IPv6 header." RFC 7045, a standards-track document, explicitly changes that. The subject draft does not make any recommendations that contradict RC 7045. It supplements RFC 7045 where the latter does not fully nail down the behaviour. There is also draft-gont-6man-ipv6-opt-transmit, which (if approved) will do the same for options that RFC 7045 does for extension headers. Same commens wrt that. > You mean you don't want non-operators in the IETF to make recommendations? > > The way I see it is that vendors are making equipment based on customer > requirements. Since a lot of vendor equipment obviously inspect packets, > including those with extension headers along the way (probably to do ACLs), > then this equipment is already violating the functioning of the protocol > (which of course is nothing new). > > My opinion is that it's better to look at common implementation and document > and give recommendations where this differs from the blueprints. > > What I don't like is that if we follow along this path we're basically saying > "extension headers don't work on the Internet" which has the implication that > fewer will use them, meaning the vendors that don't follow the protocol > designer intention has little downside, and thus perpetuating the problem. > > I don't know how to make it right though. I would like to see extension > headers working well, but I also understand that people want to be able to do > filtering. RFC 7045 revises IPv6 to acknowledge the reality of packet inspection by forwarding devices, but lit levies requirements that, if followed, should make the behaviour far less destructive. The sibject draft complements it with operational advice that is much in the same spirit. //cmh From nobody Mon Oct 13 12:25:16 2014 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 5119B1A8BB5; Mon, 13 Oct 2014 12:25:03 -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, 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 W6pKTYckgEgF; Mon, 13 Oct 2014 12:24:53 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 704291A8BBE; Mon, 13 Oct 2014 12:24:53 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id y13so6095955pdi.33 for ; Mon, 13 Oct 2014 12:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uANDhjnajAxB+G0iTTKDjFc/2UwgJbv+WiZfnXBIz6o=; b=VGGnGi2bp6AAmBpZ39vhDtNcir5uY9vlFW/UFiwQGVQqceVwKMK8JSGBH6E0n1/LFm wMCA7nDbDBgEEM25zzff8SY6N9LWtknRXdJfw7Yz4RJKAxTICMOSvil10FRQnh1lq5Vc A31k1DnAH5FRFf+YAW+/p7KAtG1J2NBmL9Oi55BvLN4RH1PHjeGZjkPe8znOezwEtx6W fMR2rD4fea3/Gzg/e2qrp77J9CacJVQ+/aFHeGOT4kBE/2b1uIY4rsKNaApD9sERcOe4 czs1gMwuOdPzzCW5+6EUYFHE4osZOCs4cB7BGKsbc5oHY6Dn35LQals3awdDO5i71bZa hA/w== X-Received: by 10.70.5.164 with SMTP id t4mr587173pdt.48.1413228293094; Mon, 13 Oct 2014 12:24:53 -0700 (PDT) Received: from [192.168.178.23] (75.196.69.111.dynamic.snap.net.nz. [111.69.196.75]) by mx.google.com with ESMTPSA id n2sm11980158pdh.30.2014.10.13.12.24.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 Oct 2014 12:24:51 -0700 (PDT) Message-ID: <543C2700.3060404@gmail.com> Date: Tue, 14 Oct 2014 08:24:48 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/PKcKySWT6z0qo_FPZYR8kotQ8xU Cc: opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 13 Oct 2014 19:25:03 -0000 On 14/10/2014 03:38, C. M. Heard wrote: > On Mon, 13 Oct 2014, Mikael Abrahamsson wrote: >> On Mon, 13 Oct 2014, Ole Troan wrote: >>>>> shouldn't this be a draft authored by operators? giving operational >>>>> recommendations coming out of... well, actual operations? >>>> Well, another way of looking at this is that operators just want things to >>>> work as well as they can, so they need guidance from vendors and protocol >>>> designers. >>>> >>>> Isn't this a BCOP style document? I believe at least one of the authors is >>>> active in one or more BCOP group. >>> the protocol designer's recommendation does appear pretty clear, RFC2460: >>> >>> "With one exception, extension headers are not examined or processed >>> by any node along a packet's delivery path, until the packet reaches >>> the node (or each of the set of nodes, in the case of multicast) >>> identified in the Destination Address field of the IPv6 header." > > RFC 7045, a standards-track document, explicitly changes that. The > subject draft does not make any recommendations that contradict > RC 7045. It supplements RFC 7045 where the latter does not fully > nail down the behaviour. > > There is also draft-gont-6man-ipv6-opt-transmit, which (if > approved) will do the same for options that RFC 7045 does for > extension headers. Same commens wrt that. > >> You mean you don't want non-operators in the IETF to make recommendations? >> >> The way I see it is that vendors are making equipment based on customer >> requirements. Since a lot of vendor equipment obviously inspect packets, >> including those with extension headers along the way (probably to do ACLs), >> then this equipment is already violating the functioning of the protocol >> (which of course is nothing new). >> >> My opinion is that it's better to look at common implementation and document >> and give recommendations where this differs from the blueprints. >> >> What I don't like is that if we follow along this path we're basically saying >> "extension headers don't work on the Internet" which has the implication that >> fewer will use them, meaning the vendors that don't follow the protocol >> designer intention has little downside, and thus perpetuating the problem. >> >> I don't know how to make it right though. I would like to see extension >> headers working well, but I also understand that people want to be able to do >> filtering. > > RFC 7045 revises IPv6 to acknowledge the reality of packet > inspection by forwarding devices, but lit levies requirements that, > if followed, should make the behaviour far less destructive. The > sibject draft complements it with operational advice that is much in > the same spirit. Exactly. I believe this draft, and the options draft, are *exactly* what the IETF should do (and why we have an E in our name instead of an S; we are not the Internet Standards Task Force). If our standards are unrealistic, we should be the ones to do something about it... Brian From nobody Mon Oct 13 13:04:58 2014 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 886891A001D; Mon, 13 Oct 2014 13:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 fJKn3Gbo8AQS; Mon, 13 Oct 2014 13:04:53 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73ED01A000E; Mon, 13 Oct 2014 13:04:51 -0700 (PDT) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9DK3JTU013429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 13:03:20 -0700 (PDT) Message-ID: <543C3008.80506@isi.edu> Date: Mon, 13 Oct 2014 13:03:20 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian E Carpenter , "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> In-Reply-To: <543C2700.3060404@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/F5ey_i4z5YXNqCAEvB_5hMeFbXw Cc: opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 13 Oct 2014 20:04:54 -0000 On 10/13/2014 12:24 PM, Brian E Carpenter wrote: ... > Exactly. I believe this draft, and the options draft, are *exactly* what > the IETF should do (and why we have an E in our name instead of an S; > we are not the Internet Standards Task Force). If our standards are > unrealistic, we should be the ones to do something about it... If it's that our standards are unrealistic, it would be useful to address this as changes to the standards. Joe From nobody Mon Oct 13 13:47:32 2014 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 6E6AA1A0095 for ; Mon, 13 Oct 2014 13:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 oA1hrlOlMF3g for ; Mon, 13 Oct 2014 13:47:26 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B467C1A0092 for ; Mon, 13 Oct 2014 13:47:26 -0700 (PDT) Received: (qmail 18264 invoked from network); 13 Oct 2014 13:47:19 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Oct 2014 13:47:19 -0700 Date: Mon, 13 Oct 2014 13:47:19 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Joe Touch In-Reply-To: <543C3008.80506@isi.edu> Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/5OFveZcEQTv5tWWA7pz2tslJiGA Cc: opsec , Brian E Carpenter , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 13 Oct 2014 20:47:29 -0000 On Mon, 13 Oct 2014, Joe Touch wrote: > On 10/13/2014 12:24 PM, Brian E Carpenter wrote: > ... > > Exactly. I believe this draft, and the options draft, are *exactly* what > > the IETF should do (and why we have an E in our name instead of an S; > > we are not the Internet Standards Task Force). If our standards are > > unrealistic, we should be the ones to do something about it... > > If it's that our standards are unrealistic, it would be useful to > address this as changes to the standards. That's what RFC 7045 does; it has "Updates: 2460, 2780" on its front page. Similarly, draft-gont-6man-ipv6-opt-transmit (the options draft referred to above) has "Updates: 2460 (if approved)" in its front page. //cmh From nobody Mon Oct 13 13:57:34 2014 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 75F941A0072; Mon, 13 Oct 2014 13:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 qmLvetGoN83h; Mon, 13 Oct 2014 13:57:29 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAAB1A000E; Mon, 13 Oct 2014 13:57:29 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9DKukUE022063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 13:56:46 -0700 (PDT) Message-ID: <543C3C8E.3010405@isi.edu> Date: Mon, 13 Oct 2014 13:56:46 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/MZDou5hCCp9FKW6B54vnDjVPU9A Cc: opsec , Brian E Carpenter , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 13 Oct 2014 20:57:30 -0000 On 10/13/2014 1:47 PM, C. M. Heard wrote: > On Mon, 13 Oct 2014, Joe Touch wrote: >> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: >> ... >>> Exactly. I believe this draft, and the options draft, are *exactly* what >>> the IETF should do (and why we have an E in our name instead of an S; >>> we are not the Internet Standards Task Force). If our standards are >>> unrealistic, we should be the ones to do something about it... >> >> If it's that our standards are unrealistic, it would be useful to >> address this as changes to the standards. > > That's what RFC 7045 does; it has "Updates: 2460, 2780" on its front > page. Similarly, draft-gont-6man-ipv6-opt-transmit (the options > draft referred to above) has "Updates: 2460 (if approved)" in its > front page. Right, but it's not what either this doc (draft-gont-opsec-ipv6-eh-filtering) or draft-gont-v6ops-ipv6-ehs-in-real-world does. I've raised this issue before. Joe From nobody Mon Oct 13 22:33:49 2014 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 CEDB71A6F99; Mon, 13 Oct 2014 22:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] 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 YIKYGZ1E1VWa; Mon, 13 Oct 2014 22:33:45 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6DF1A6F97; Mon, 13 Oct 2014 22:33:45 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s9E5XMA8098544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2014 05:33:22 GMT (envelope-from joelja@bogus.com) Message-ID: <543CB5B4.9030203@bogus.com> Date: Mon, 13 Oct 2014 22:33:40 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Joe Touch , Brian E Carpenter , "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> In-Reply-To: <543C3008.80506@isi.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CJJEbVfmJbLNENIu50sJsWUrsbJ2xakcI" Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/_t42w-Xg_yypePUfVUpCQppLSK8 Cc: opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 14 Oct 2014 05:33:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CJJEbVfmJbLNENIu50sJsWUrsbJ2xakcI Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/13/14 1:03 PM, Joe Touch wrote: >=20 >=20 > On 10/13/2014 12:24 PM, Brian E Carpenter wrote: > ... >> Exactly. I believe this draft, and the options draft, are *exactly* wh= at >> the IETF should do (and why we have an E in our name instead of an S; >> we are not the Internet Standards Task Force). If our standards are >> unrealistic, we should be the ones to do something about it... >=20 > If it's that our standards are unrealistic, it would be useful to > address this as changes to the standards. It's not entirely unrealistic to expect a consensus about observed reality to emerge from ops before it evolves into protocol maintenance. The working groups remit doesn't involve changing standards so frankly that's right out. joel > Joe >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --CJJEbVfmJbLNENIu50sJsWUrsbJ2xakcI 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQ8tbQACgkQ8AA1q7Z/VrLLugCbB17qU13wwbj71vgebYV1bPdD 9OAAnjpSBWlsmwCct6RwsH72uUMxFRp/ =DtgR -----END PGP SIGNATURE----- --CJJEbVfmJbLNENIu50sJsWUrsbJ2xakcI-- From nobody Mon Oct 13 23:51:52 2014 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 2290F1A6FC0; Mon, 13 Oct 2014 23:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786] 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 XLaUUehOLmTl; Mon, 13 Oct 2014 23:51:49 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8471A6FBB; Mon, 13 Oct 2014 23:51:49 -0700 (PDT) Received: from [192.168.1.8] (pool-71-103-148-50.lsanca.dsl-w.verizon.net [71.103.148.50]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s9E6otns011920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 23:51:04 -0700 (PDT) Message-ID: <543CC7D1.7080602@isi.edu> Date: Mon, 13 Oct 2014 23:50:57 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: joel jaeggli , Brian E Carpenter , "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> <543CB5B4.9030203@bogus.com> In-Reply-To: <543CB5B4.9030203@bogus.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/M9Jda6YWpr2FHzRhwJgIRy5_GZI Cc: opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 14 Oct 2014 06:51:50 -0000 On 10/13/2014 10:33 PM, joel jaeggli wrote: > On 10/13/14 1:03 PM, Joe Touch wrote: >> >> >> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: >> ... >>> Exactly. I believe this draft, and the options draft, are *exactly* what >>> the IETF should do (and why we have an E in our name instead of an S; >>> we are not the Internet Standards Task Force). If our standards are >>> unrealistic, we should be the ones to do something about it... >> >> If it's that our standards are unrealistic, it would be useful to >> address this as changes to the standards. > > It's not entirely unrealistic to expect a consensus about observed > reality to emerge from ops before it evolves into protocol maintenance. Observed reality doesn't include recommendations. And if observed reality requires consensus, I doubt you're describing anything that involves either observation or reality. Joe From nobody Tue Oct 14 00:02:29 2014 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 0835B1A6FC0; Tue, 14 Oct 2014 00:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RDNS_DYNAMIC=0.982] 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 uvXhGMTLoQwP; Tue, 14 Oct 2014 00:02:25 -0700 (PDT) Received: from minorthreat.org (ec2-54-68-221-247.us-west-2.compute.amazonaws.com [54.68.221.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9B91A6FBE; Tue, 14 Oct 2014 00:02:25 -0700 (PDT) Received: from mb-aye.local (c-67-188-0-113.hsd1.ca.comcast.net [67.188.0.113]) (authenticated bits=0) by minorthreat.org (8.14.9/8.14.9) with ESMTP id s9E722xB098881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 14 Oct 2014 07:02:03 GMT (envelope-from joelja@bogus.com) Message-ID: <543CCA7D.6060900@bogus.com> Date: Tue, 14 Oct 2014 00:02:21 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Thunderbird/33.0 MIME-Version: 1.0 To: Joe Touch , Brian E Carpenter , "C. M. Heard" References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> <543CB5B4.9030203@bogus.com> <543CC7D1.7080602@isi.edu> In-Reply-To: <543CC7D1.7080602@isi.edu> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wAc2j9lGx1esRGuGT9jaH5GnmdoVAKNCo" Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/KqR570Yi6Ef9Ryxj1sz3h-QEgyI Cc: opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 14 Oct 2014 07:02:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wAc2j9lGx1esRGuGT9jaH5GnmdoVAKNCo Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/13/14 11:50 PM, Joe Touch wrote: >=20 >=20 > On 10/13/2014 10:33 PM, joel jaeggli wrote: >> On 10/13/14 1:03 PM, Joe Touch wrote: >>> >>> >>> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: >>> ... >>>> Exactly. I believe this draft, and the options draft, are *exactly* = what >>>> the IETF should do (and why we have an E in our name instead of an S= ; >>>> we are not the Internet Standards Task Force). If our standards are >>>> unrealistic, we should be the ones to do something about it... >>> >>> If it's that our standards are unrealistic, it would be useful to >>> address this as changes to the standards. >> >> It's not entirely unrealistic to expect a consensus about observed >> reality to emerge from ops before it evolves into protocol maintenance= =2E >=20 > Observed reality doesn't include recommendations. >=20 > And if observed reality requires consensus, I doubt you're describing > anything that involves either observation or reality. =2E.. The goals of the v6ops working group are: 1. Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues. These issues will be documented in Informational or BCP RFCs, or in Internet-Drafts. This work should primarily be conducted by those areas and WGs which are responsible and best fit to analyze these problems, but v6ops may also cooperate in focusing such work. 2. Publish Informational or BCP RFCs that identify potential security risks in the operation of shared IPv4/IPv6 networks, and document operational practices to eliminate or mitigate those risks. This work will be done in cooperation with the Security area and other relevant areas or working groups. 3. As a particular instance of (1) and (2), provide feedback to the IPv6 WG regarding portions of the IPv6 specifications that cause, or are likely to cause, operational or security concerns, and work with the IPv6 WG to resolve those concerns. This feedback will be published in Internet-Drafts or RFCs. =2E.. > Joe >=20 --wAc2j9lGx1esRGuGT9jaH5GnmdoVAKNCo 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.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlQ8yn4ACgkQ8AA1q7Z/VrIYkACfZtjcSsgg6KWosvVxWmCZftrh Hl0An1d7UFi1HIEF2NEQ5nsJp1eP9OTu =bibc -----END PGP SIGNATURE----- --wAc2j9lGx1esRGuGT9jaH5GnmdoVAKNCo-- From nobody Tue Oct 14 08:23:25 2014 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 326F31A88F2 for ; Tue, 14 Oct 2014 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 0WR3wREPNkGF for ; Tue, 14 Oct 2014 08:23:21 -0700 (PDT) Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 911CA1A88D0 for ; Tue, 14 Oct 2014 08:23:21 -0700 (PDT) Received: (qmail 31413 invoked from network); 14 Oct 2014 08:23:17 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 14 Oct 2014 08:23:17 -0700 Date: Tue, 14 Oct 2014 08:23:17 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: Joe Touch In-Reply-To: <543C3C8E.3010405@isi.edu> Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> <543C3C8E.3010405@isi.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/-KXKZDna_q75oce_QBC6BLQeDTQ Cc: opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 14 Oct 2014 15:23:22 -0000 On Mon, 13 Oct 2014, Joe Touch wrote: > On 10/13/2014 1:47 PM, C. M. Heard wrote: > > On Mon, 13 Oct 2014, Joe Touch wrote: > >> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: > >> ... > >>> Exactly. I believe this draft, and the options draft, are *exactly* what > >>> the IETF should do (and why we have an E in our name instead of an S; > >>> we are not the Internet Standards Task Force). If our standards are > >>> unrealistic, we should be the ones to do something about it... > >> > >> If it's that our standards are unrealistic, it would be useful to > >> address this as changes to the standards. > > > > That's what RFC 7045 does; it has "Updates: 2460, 2780" on its front > > page. Similarly, draft-gont-6man-ipv6-opt-transmit (the options > > draft referred to above) has "Updates: 2460 (if approved)" in its > > front page. > > Right, but it's not what either this doc > (draft-gont-opsec-ipv6-eh-filtering) or > draft-gont-v6ops-ipv6-ehs-in-real-world does. > > I've raised this issue before. If I correctly understand the intent, draft-gont-opsec-ipv6-eh-filtering is not supposed to make any recommendations that contravene RFC 2460 as updated by RFC 7045 and draft-gont-6man-ipv6-opt-transmit. If you see something specific where it does so please point it out. I didn't find anything like that when I reviewed the document. //cmh From nobody Tue Oct 14 15:47:10 2014 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 08E421A000C; Tue, 14 Oct 2014 15:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.786, SPF_NEUTRAL=0.779] 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 lGtUEq9zhuVT; Tue, 14 Oct 2014 15:47:06 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCE71A0019; Tue, 14 Oct 2014 15:47:05 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9EMkqxb009604; Tue, 14 Oct 2014 23:46:52 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s9EMkqxb009604 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1413326815; bh=aN4Dx8qZz9jTsemKEUGKeTA/79Y=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=UQ8vJp4yDSnajAQUddYmZKm/EhXSOqxINEP40UO3Xhcn81kno+YHtGPcQe3SGCBEM GldF75Fi8U0uhhdKVz/HuDdCaYxqG61rUatZMqFxup57vce7U9IfLB0njc7dFr+ure UHgmXK+9PfvYyCSghmhpkOq2N6BRTZ4dsky8Td5s= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id q9DNkq17613133797Z ret-id none; Tue, 14 Oct 2014 23:46:54 +0100 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s9EMkdQ6018707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 14 Oct 2014 23:46:40 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <543CCA7D.6060900@bogus.com> Date: Tue, 14 Oct 2014 23:46:39 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> <543C2700.3060404@gmail.com> <543C3008.80506@isi.edu> <543CB5B4.9030203@bogus.com> <543CC7D1.7080602@isi.edu> <543CCA7D.6060900@bogus.com> <9FAF4D5B-217D-40E8-997A-924B05CF045D@ecs.soton.ac.uk> To: joel jaeggli X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q9DNkq176131337900; tid=q9DNkq17613133797Z; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s9EMkqxb009604 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/WNerQKaGNztc5QdM_I2pBdzuRb8 Cc: "C. M. Heard" , opsec , Brian E Carpenter , v6ops , Joe Touch Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 14 Oct 2014 22:47:09 -0000 On 14 Oct 2014, at 08:02, joel jaeggli wrote: > On 10/13/14 11:50 PM, Joe Touch wrote: >>=20 >>=20 >> On 10/13/2014 10:33 PM, joel jaeggli wrote: >>> On 10/13/14 1:03 PM, Joe Touch wrote: >>>>=20 >>>>=20 >>>> On 10/13/2014 12:24 PM, Brian E Carpenter wrote: >>>> ... >>>>> Exactly. I believe this draft, and the options draft, are = *exactly* what >>>>> the IETF should do (and why we have an E in our name instead of an = S; >>>>> we are not the Internet Standards Task Force). If our standards = are >>>>> unrealistic, we should be the ones to do something about it... >>>>=20 >>>> If it's that our standards are unrealistic, it would be useful to >>>> address this as changes to the standards. >>>=20 >>> It's not entirely unrealistic to expect a consensus about observed >>> reality to emerge from ops before it evolves into protocol = maintenance. >>=20 >> Observed reality doesn't include recommendations. >>=20 >> And if observed reality requires consensus, I doubt you're describing >> anything that involves either observation or reality. >=20 > ... >=20 > The goals of the v6ops working group are: >=20 > 1. Solicit input from network operators and users to identify > operational issues with the IPv4/IPv6 Internet, and > determine solutions or workarounds to those issues. These issues > will be documented in Informational or BCP RFCs, or in > Internet-Drafts. >=20 > This work should primarily be conducted by those areas and WGs > which are responsible and best fit to analyze these problems, but > v6ops may also cooperate in focusing such work. >=20 > 2. Publish Informational or BCP RFCs that identify potential security > risks in the operation of shared IPv4/IPv6 networks, and document > operational practices to eliminate or mitigate those risks. >=20 > This work will be done in cooperation with the Security area and > other relevant areas or working groups. >=20 > 3. As a particular instance of (1) and (2), provide feedback to > the IPv6 WG regarding portions of the IPv6 specifications that > cause, or are likely to cause, operational or security concerns, > and work with the IPv6 WG to resolve those concerns. This feedback > will be published in Internet-Drafts or RFCs. > ... =85 which suggests publishing the observations / problem statement in = one draft in v6ops, and then progressing recommendations in a separate = document in conjuction with opsec seems perfectly reasonable? I=92m puzzled by the length of this conversation / debate=85 Tim= From nobody Thu Oct 16 01:22:02 2014 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 E7A721A88A5; Sun, 12 Oct 2014 23:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 lKDlKDwsqVYI; Sun, 12 Oct 2014 23:57:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204081A88A4; Sun, 12 Oct 2014 23:57:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,708,1406592000"; d="scan'208";a="204593986" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 13 Oct 2014 06:57:30 +0000 Received: from dhcp-10-61-101-249.cisco.com (dhcp-10-61-101-249.cisco.com [10.61.101.249]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9D6vSOh015552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 06:57:30 GMT Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-Type: text/plain; charset=us-ascii From: Ole Troan X-Priority: 3 In-Reply-To: <201410101259128179113@gmail.com> Date: Mon, 13 Oct 2014 08:57:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> References: <201410101259128179113@gmail.com> To: opsec , v6ops X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/q4B7buA3xsfzr6P4jTs7YRPIG4Y X-Mailman-Approved-At: Thu, 16 Oct 2014 01:21:58 -0700 Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 13 Oct 2014 06:57:34 -0000 shouldn't this be a draft authored by operators? giving operational = recommendations coming out of... well, actual operations? cheers, Ole > On 10 Oct 2014, at 6:59 , Yuchi Chen wrote: >=20 > Hi all, >=20 > I support the adoption for this draft. IMO, this seems like timely = advice concerning the recent data on filtering of packets with extension = headers. >=20 > Best regards! > -------------- > Yuchi Chen >=20 >=20 > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de = Velde (gvandeve) > Sent: Wednesday, October 08, 2014 6:21 PM > To: opsec@ietf.org > Cc: v6ops-chairs@tools.ietf.org > Subject: Re: [OPSEC] Call for WG adoption - Recommendations on = Filtering of IPv6 Packets Containing IPv6 Extension Headers >=20 > Dear all, >=20 > Many thanks for your input on this request. > OPSEC chairs will look at the received input and see together with the = v6ops chairs how the IPv6 EH work could progress. >=20 > Kind Regards, > G/ >=20 >=20 > -----Original Message----- > From: Gunter Van de Velde (gvandeve)=20 > Sent: 24 September 2014 11:28 > To: opsec@ietf.org > Subject: Call for WG adoption - Recommendations on Filtering of IPv6 = Packets Containing IPv6 Extension Headers >=20 > Dear, >=20 > Please find this request for WG adoption for "Recommendations on = Filtering of IPv6 Packets Containing IPv6 Extension Headers" > The authors of the work explicitly asked for "Call for WG adoption" in = its current state.=20 >=20 > Latest draft can be found at: > http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02=20 >=20 > (1) Do you support for adopting the draft as OPSEC WG item? >=20 > This call for WG adoption will end 8 October 2014. >=20 > Kind Regards, > OPSEC chairs >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From nobody Thu Oct 16 01:22:04 2014 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 29B3B1A88B4; Mon, 13 Oct 2014 00:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 8qOcfZzA5CmF; Mon, 13 Oct 2014 00:15:08 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 417191A1AC2; Mon, 13 Oct 2014 00:15:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEANF6O1StJssW/2dsb2JhbABb1xQCgSsBfYQDAQEDAR0dPxALDi0LVwaISQjDagEBAQEBAQEBAQEBAQEBAQEBAQEBAReQEjMHgy2BHgEEs1yCNIFFO4J5AQEB X-IronPort-AV: E=Sophos;i="5.04,708,1406592000"; d="scan'208";a="204609670" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 13 Oct 2014 07:15:05 +0000 Received: from dhcp-10-61-101-249.cisco.com (dhcp-10-61-101-249.cisco.com [10.61.101.249]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s9D7F1WO028207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Oct 2014 07:15:05 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Ole Troan In-Reply-To: Date: Mon, 13 Oct 2014 09:15:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201410101259128179113@gmail.com> <279945F5-9A00-41AB-903E-FF4F858CB387@employees.org> To: Mikael Abrahamsson X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/qfCGslZjBgLQSMEZHa3OkOb7JNc X-Mailman-Approved-At: Thu, 16 Oct 2014 01:21:58 -0700 Cc: opsec , v6ops Subject: Re: [OPSEC] [v6ops] Call for WG adoption - Recommendations on Filtering of IPv6 Packets Containing IPv6 Extension Headers 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, 13 Oct 2014 07:15:09 -0000 >> shouldn't this be a draft authored by operators? giving operational = recommendations coming out of... well, actual operations? >=20 > Well, another way of looking at this is that operators just want = things to work as well as they can, so they need guidance from vendors = and protocol designers. >=20 > Isn't this a BCOP style document? I believe at least one of the = authors is active in one or more BCOP group. the protocol designer's recommendation does appear pretty clear, = RFC2460: "With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header." my point is that I don't think the IETF should be making recommendations = about how they should run their network, and certainly not make = recommendations that are at odds with the functioning of the protocol. cheers, Ole From nobody Mon Oct 27 12:38:55 2014 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 A0C481ACFF2; Mon, 27 Oct 2014 12:38:35 -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 xJdgdokKBLRm; Mon, 27 Oct 2014 12:38:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D761AD379; Mon, 27 Oct 2014 12:38:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027193826.3673.92600.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 12:38:26 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/UM2qGNvVMv2bb5sErIWrsp8T2eQ Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-05.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: Mon, 27 Oct 2014 19:38:35 -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 : Operational Security Considerations for IPv6 Networks Authors : Kiran K. Chittimaneni Merike Kaeo Eric Vyncke Filename : draft-ietf-opsec-v6-05.txt Pages : 41 Date : 2014-10-27 Abstract: Knowledge and experience on how to operate IPv4 securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues in all places of a network (service providers, enterprises and residential users) and proposes technical and procedural mitigations techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-v6-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-05 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 Mon Oct 27 16:46:14 2014 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 AFD2E1A878E; Mon, 27 Oct 2014 16:46:09 -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 gM0wd5FJUjNM; Mon, 27 Oct 2014 16:46:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1F41A8795; Mon, 27 Oct 2014 16:45:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141027234543.7223.3645.idtracker@ietfa.amsl.com> Date: Mon, 27 Oct 2014 16:45:43 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/weZ9UnSsUHB0VHOv7vpbImRCQmE Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-bgp-security-06.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: Mon, 27 Oct 2014 23:46:09 -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 : BGP operations and security Authors : Jerome Durand Ivan Pepelnjak Gert Doering Filename : draft-ietf-opsec-bgp-security-06.txt Pages : 30 Date : 2014-10-27 Abstract: BGP (Border Gateway Protocol) is the protocol almost exclusively used in the Internet to exchange routing information between network domains. Due to this central nature, it is important to understand the security measures that can and should be deployed to prevent accidental or intentional routing disturbances. This document describes measures to protect the BGP sessions itself (like TTL, TCP-AO, control plane filtering) and to better control the flow of routing information, using prefix filtering and automatization of prefix filters, max-prefix filtering, AS path filtering, route flap dampening and BGP community scrubbing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-bgp-security-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-bgp-security-06 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/