From nobody Mon Sep 1 10:27:45 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 616B11A0552 for ; Mon, 1 Sep 2014 10:27:43 -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 Uc7WGmdQtE0q for ; Mon, 1 Sep 2014 10:27:42 -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 554A71A04BC for ; Mon, 1 Sep 2014 10:27:41 -0700 (PDT) Received: (qmail 10440 invoked from network); 1 Sep 2014 10:27:36 -0700 Received: from shell4.bayarea.net (209.128.82.1) by shell4.bayarea.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 1 Sep 2014 10:27:36 -0700 Date: Mon, 1 Sep 2014 10:27:36 -0700 (PDT) From: "C. M. Heard" X-X-Sender: heard@shell4.bayarea.net To: OPSEC In-Reply-To: <53FCA7B1.9000006@si6networks.com> Message-ID: References: <20140826152114.26964.93347.idtracker@ietfa.amsl.com> <53FCA7B1.9000006@si6networks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/8Za37xztfDfISo0kd8ItzrlKq5o Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-02.txt 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, 01 Sep 2014 17:27:43 -0000 Greetings, I'm pretty happy with what I see in the new revision. It now treats extension headers and options on an equal footing, leaving the specification of protocol requirements (including configuration defaults) to standards-track documents and concentrating on advice for what configuration options operators should choose. The standards-track document for extension headers is RFC 7045, and the authors have submitted a draft to 6man to cover IPv6 options: http://tools.ietf.org/html/draft-gont-6man-ipv6-opt-transmit Folks who are interested in draft-gont-opsec-ipv6-eh-filtering will doubtless want to look at that draft too. As far as I can see, the major substantive things that need to be done before draft-gont-opsec-ipv6-eh-filtering is ready for prime time are to fill in the TBDs. These mainly deal with specific security implications, but in the case of three hop-by-hop options (SMF_DPD, MPL, IP_DFF) there are some additional gaps. Here is the full list of gaps: EH: Mobility, HIP, Shim6 HbH (a): Jumbo Payload, RPL HbH (b) SMF_DPD, MPL, IP_DFF [also needs impact if blocked and advice] Dest: Tunnel Encapsulation Limit, Home Address, EID, ILNP Nonce, Line ID The three EHs mentioned above are basically upper-layer protocols with the ability to tunnel another ULP (though in the cases of Mobility and HIP this capability is for further study -- the specs require that they contain a Next Header type of No Next Header). The security considerations of the respective specs (RFCs 5201, 6275, and 5553) seem to provide the necessary information to craft specific security implication text. If I have time in the next couple of weeks I'll see if I can propose something, assuming that the authors (or other interested parties) do not beat me to it. I also noticed one nit: 3.3.2.4. Operational and Interoperability Impact if Blocked Blocking packets containing a RHT0 or RTH1 has no operational s/RTH1/RHT1/ //cmh On Tue, 26 Aug 2014, Fernando Gont wrote: > Folks, > > We have posted a revision > (http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-02.txt) > of the aforementioned document, that addresses all the comments we have > received so far. > > Any further comments will be highly appreciated. > > Thanks! > > Best regards, > Fernando (and co-authors) > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-opsec-ipv6-eh-filtering-02.txt > Date: Tue, 26 Aug 2014 08:21:14 -0700 > From: internet-drafts@ietf.org > To: Will(Shucheng) Liu , Shucheng LIU (Will) > , Fernando Gont , Ron > Bonica , Fernando Gont , > Ronald P. Bonica > > > A new version of I-D, draft-gont-opsec-ipv6-eh-filtering-02.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-opsec-ipv6-eh-filtering > Revision: 02 > Title: Recommendations on Filtering of IPv6 Packets Containing IPv6 > Extension Headers > Document date: 2014-08-26 > Group: Individual Submission > Pages: 30 > URL: > http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-02.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-eh-filtering/ > Htmlized: > http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-eh-filtering-02 > > Abstract: > This document provides advice on the filtering of IPv6 packets based > on the IPv6 Extension Headers and the IPv6 options they contain. > Additionally, it discusses the operational and interoperability > implications of discarding packets based on the IPv6 Extension > Headers and IPv6 options they contain. > > > > > > 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 > > > > > From nobody Mon Sep 8 08:42: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 0EA9E1A8880; Mon, 8 Sep 2014 08:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-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 UWVSr6eI40Qk; Mon, 8 Sep 2014 08:42:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1921A8873; Mon, 8 Sep 2014 08:42:19 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140908154219.1497.84073.idtracker@ietfa.amsl.com> Date: Mon, 08 Sep 2014 08:42:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/7JlOb7q4y9B56v8-wIWdePXMpGs Cc: opsec@ietf.org Subject: [OPSEC] Last Call: (BGP operations and security) to Best Current Practice X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 15:42:21 -0000 The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'BGP operations and security' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-09-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsec-bgp-security/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Sep 8 14:38:06 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 E120E1A03BE; Mon, 8 Sep 2014 14:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, 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 EsbV5m4H5MjM; Mon, 8 Sep 2014 14:38:03 -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 EED471A03AA; Mon, 8 Sep 2014 14:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3411; q=dns/txt; s=iport; t=1410212283; x=1411421883; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SvlrlVMUhUOPRrPVKQeNBd/SqjEzFR8soKSpaFCUeIo=; b=eRzPJZkK37JHzSuF1U4xzGAmwCshBjktZ+yC97rk32T6KbjahGkhAJ37 Y6lbluH0dbzrkU3Doi3QDx8V0uLHU5s2oqhJFZ/Cn265V/bwR2e2CHOuP G7NQYpoGCcNU1Nib40yXPI37+4hwvq8Dos0NCpw+iD+YeYBJ4fxf8M2n7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAEohDlStJA2F/2dsb2JhbABZgw1TVwTJeYdQAYEZFniEBAEBAwF5BQsCAQg7CzIlAgQOBYg6CA29KQEXjxozB4MvgR0FjyuCFYQwhwKBX5NNghuBRmyBCCQcgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,488,1406592000"; d="scan'208";a="76069556" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP; 08 Sep 2014 21:38:01 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s88Lc141025178 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Sep 2014 21:38:01 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.236]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Mon, 8 Sep 2014 16:38:01 -0500 From: "Jerome Durand (jerduran)" To: "John G. Scudder" Thread-Topic: Last Call: (BGP operations and security) to Best Current Practice Thread-Index: AQHPy6jHnPt+KxTd20eej+9ncMinpZv4FtGA Date: Mon, 8 Sep 2014 21:38:00 +0000 Message-ID: <674B7643-20E2-4BC5-A506-980F34CAEBAE@cisco.com> References: <20140908154219.1497.84073.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.99.213] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3FAAC69173A7A9418AB1D5550106CF60@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/UeM0WOx3yvimoRjjP7djL4EvtPI Cc: "randy@psg.com" , " draft-ietf-opsec-bgp-security@tools.ietf.org" , mailing list wg opsec , ietf Subject: Re: [OPSEC] Last Call: (BGP operations and security) to Best Current Practice 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, 08 Sep 2014 21:38:05 -0000 > o If an ROA is not found then the prefix SHOULD be accepted but > corresponding route SHOULD be given a low preference. >=20 > The draft isn't precise about what's meant by "ROA is not found", but pro= bably it's the same as NotFound in RFC 7115 and 6811. That=92s indeed right. First publication of the draft is quite old now and = we might have not adjusted vocabulary from what was happening in other docs= that got published quicker. > Assuming that's right, I'm curious what the rationale is for giving not-f= ound routes a low preference? I=92ll start quoting section 5 of RFC7115: As origin validation will be rolled out incrementally, coverage will be incomplete for a long time. Therefore, routing on NotFound validity state SHOULD be done for a long time. As the transition moves forward, the number of BGP announcements with validation state NotFound should decrease. Hence, an operator=92s policy should not be overly strict and should prefer Valid announcements; it should attach a lower preference to, but still use, NotFound announcements, and drop or give a very low preference to Invalid announcements. Merely de-preferencing Invalid announcements is ill-advised; see previous paragraph. > By definition, they don't compete with a route that is in any other state= -- NotFound basically means there is no ROA that has anything to say about= this prefix at all, so all routes for this prefix will be NotFound.=20 What you say is intersting and I will cc Randy :-) Actually I think the "lower preference" thing still makes some sense. I sti= ll see the case where you receive the routes from different peerings, for w= hich you either check or do not check the received prefix against the ROA. = I can give the below example: - An ISP would check all routes received from an IXP - This ISP would have a loose policy on its transit (with no verification= because he trusts the transit provider) The basic ISP policy would be to prefer the routes received through the IXP= . But with the policy described in RFC7115 and repeated in the bgp-opsec dr= aft the internet route would be prefered. I think this makes some sense and= I=92ve seen some similar things some years ago when we were doing route va= lidation against the RADB. > The net result is according to the draft's recommendation all routes for = the prefix in question will be "accepted but ... given a low preference". T= he recommendation ends up being mostly harmless, but also not useful.=20 >=20 > (I say only *mostly* harmless since I guess some operator could be confus= ed into thinking they're more secure than they actually are.) >=20 > Sorry for the late comment. No problem, it=92s an interesting point. I=92d personally keep it as-is (except =AB NotFound =BB) given the above ex= ample but I=92m interested by what others think. Thanks! Jerome >=20 > Regards, >=20 > --John >=20 > P.S.: This shouldn't be construed as a full review of the document, which= I haven't done. -- Jerome Durand Consulting Systems Engineer - Routing & Switching jerduran@cisco.com - +33 6 35 11 60 50 blogs: http://reseauxblog.cisco.fr - http://ipv6blog.cisco.fr twitter: @JeromeDurand linkedin: http://fr.linkedin.com/in/jeromedurand CISCO France 11, rue Camille Desmoulins 92782 Issy les Moulineaux CEDEX 9 FRANCE From nobody Mon Sep 8 19:15:33 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 662641A0415; Mon, 8 Sep 2014 19:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 wzzARQfDdjHg; Mon, 8 Sep 2014 19:14:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA111A03E2; Mon, 8 Sep 2014 19:14:58 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XRAxE-0001FM-Ql; Tue, 09 Sep 2014 02:14:49 +0000 Date: Tue, 09 Sep 2014 11:14:47 +0900 Message-ID: From: Randy Bush To: Jerome Durand In-Reply-To: <674B7643-20E2-4BC5-A506-980F34CAEBAE@cisco.com> References: <20140908154219.1497.84073.idtracker@ietfa.amsl.com> <674B7643-20E2-4BC5-A506-980F34CAEBAE@cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/jzOhQkyNJ8C8CpBUczptjBRm0Ug Cc: "John G. Scudder" , opsec , ietf , draft-ietf-opsec-bgp-security@tools.ietf.org Subject: Re: [OPSEC] Last Call: (BGP operations and security) to Best Current Practice 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, 09 Sep 2014 02:15:02 -0000 >> Assuming that's right, I'm curious what the rationale is for giving >> not-found routes a low preference? it was intended more as prefer valid. but i take your point. do remind me when we have gained enough experience to rev 7115 >> By definition, they don't compete with a route that is in any other >> state -- NotFound basically means there is no ROA that has anything >> to say about this prefix at all, so all routes for this prefix will >> be NotFound. true, if they are notfound, then they can not be either valid or invalid as there is no covering roa. > Actually I think the "lower preference" thing still makes some > sense. I still see the case where you receive the routes from > different peerings, for which you either check or do not check the > received prefix against the ROA. I can give the below example: you have a sick mind.:) yes, this is possible. so perhaps qualify the recommendation. in a configuration when some announcements may be checked and others not, it is possible that a prefix may be marked both notfound, because of not being checked, and [in]valid, because it is checked. in this configuration, we recommend that the operator prefer valid over notfound. randy From nobody Mon Sep 8 23:28: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 B73711A02A6; Mon, 8 Sep 2014 14:06:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VPWQHzouY0X5; Mon, 8 Sep 2014 14:06:07 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9230E1A02BA; Mon, 8 Sep 2014 14:06:07 -0700 (PDT) Received: from scardali-sslvpn-nc.jnpr.net (66.129.241.14) by BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Mon, 8 Sep 2014 21:06:03 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "John G. Scudder" In-Reply-To: <20140908154219.1497.84073.idtracker@ietfa.amsl.com> Date: Mon, 8 Sep 2014 17:05:53 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140908154219.1497.84073.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [66.129.241.14] X-ClientProxiedBy: BY1PR0201CA0001.namprd02.prod.outlook.com (25.160.191.139) To BLUPR05MB724.namprd05.prod.outlook.com (10.141.207.154) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-Forefront-PRVS: 03283976A6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019018)(6009001)(51704005)(377454003)(24454002)(199003)(189002)(83716003)(86362001)(85852003)(83072002)(42186005)(23726002)(92566001)(88136002)(92726001)(89996001)(87286001)(230783001)(82746002)(62966002)(77982001)(57306001)(46102001)(77156001)(76482001)(102836001)(104166001)(97736003)(33656002)(87976001)(79102001)(31966008)(74502001)(50226001)(20776003)(97756001)(36756003)(74662001)(95666004)(19580405001)(83322001)(19580395003)(66066001)(69596002)(21056001)(46406003)(81342001)(80022001)(50466002)(81542001)(106356001)(81156004)(107046002)(110136001)(90102001)(85306004)(64706001)(101416001)(4396001)(50986999)(76176999)(77096002)(99396002)(53416004)(105586002)(104396001)(42262002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB724; H:scardali-sslvpn-nc.jnpr.net; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Nu60c4JMdbYLq56dME8-vS8s3Wk X-Mailman-Approved-At: Mon, 08 Sep 2014 23:28:31 -0700 Cc: opsec@ietf.org, ietf Subject: Re: [OPSEC] Last Call: (BGP operations and security) to Best Current Practice 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, 08 Sep 2014 21:06:10 -0000 On Sep 8, 2014, at 11:42 AM, The IESG wrote: >=20 > The IESG has received a request from the Operational Security > Capabilities for IP Network Infrastructure WG (opsec) to consider the > following document: > - 'BGP operations and security' > as Best Current Practice >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2014-09-22.=20 ... I happened to notice, in S. 6.1.2.4 (SIDR): o If an ROA is not found then the prefix SHOULD be accepted but corresponding route SHOULD be given a low preference. The draft isn't precise about what's meant by "ROA is not found", but = probably it's the same as NotFound in RFC 7115 and 6811. Assuming that's = right, I'm curious what the rationale is for giving not-found routes a = low preference? By definition, they don't compete with a route that is = in any other state -- NotFound basically means there is no ROA that has = anything to say about this prefix at all, so all routes for this prefix = will be NotFound.=20 The net result is according to the draft's recommendation all routes for = the prefix in question will be "accepted but ... given a low = preference". The recommendation ends up being mostly harmless, but also = not useful.=20 (I say only *mostly* harmless since I guess some operator could be = confused into thinking they're more secure than they actually are.) Sorry for the late comment. Regards, --John P.S.: This shouldn't be construed as a full review of the document, = which I haven't done.=20= From nobody Tue Sep 9 06:56:27 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 68F0C1A6F9D for ; Tue, 9 Sep 2014 06:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 uoErOAJUuubB for ; Tue, 9 Sep 2014 06:55:14 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C9F1A6FAB for ; Tue, 9 Sep 2014 06:55:08 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0275.namprd09.prod.outlook.com (25.160.80.24) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Tue, 9 Sep 2014 13:55:07 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.1024.012; Tue, 9 Sep 2014 13:55:06 +0000 From: "Sriram, Kotikalapudi" To: "opsec@ietf.org" Thread-Topic: [OPSEC] Last Call: (BGP operations and security) to Best Current Practice Thread-Index: Ac/MMNJXRz3hlm1YQ/mpDwi5pA0rrg== Date: Tue, 9 Sep 2014 13:55:06 +0000 Message-ID: <9a5bd319b65c4a64ba312a8b0c463e20@BN1PR09MB0274.namprd09.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.6.222.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0329B15C8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019018)(6009001)(189002)(199003)(50986999)(230783001)(108616004)(2501002)(74662001)(21056001)(74502001)(74316001)(97736003)(76482001)(99286002)(95666004)(101416001)(110136001)(85306004)(15975445006)(106356001)(2656002)(4396001)(80022001)(81342001)(54356999)(66066001)(64706001)(77096002)(81542001)(86362001)(77982001)(107046002)(76576001)(46102001)(2351001)(90102001)(33646002)(87936001)(83072002)(19580395003)(31966008)(85852003)(83322001)(20776003)(79102001)(105586002)(99396002)(92566001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0275; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/bUWYJCXF9ShDWNe2yK3YSLEpAEE X-Mailman-Approved-At: Tue, 09 Sep 2014 06:56:20 -0700 Cc: "Randy Bush \(randy@psg.com\)" , "John G. Scudder \(jgs@bgp.nu\)" Subject: Re: [OPSEC] Last Call: (BGP operations and security) to Best Current Practice 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, 09 Sep 2014 13:55:16 -0000 >> Actually I think the "lower preference" thing still makes some sense.=20 >> I still see the case where you receive the routes from different=20 >> peerings, for which you either check or do not check the received=20 >> prefix against the ROA. I can give the below example: > you have a sick mind.:) yes, this is possible. so perhaps qualify the r= ecommendation. > in a configuration when some announcements may be checked and others > not, it is possible that a prefix may be marked both notfound, > because of not being checked, and [in]valid, because it is checked. > in this configuration, we recommend that the operator prefer valid > over notfound. The situation of having in(valid) and notfound routes simultaneous for a p= refix also arises when a router is not doing its own origin-AS check but is relying on neighboring IBGP speakers (all within the same AS):=20 https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-04= =20 One IBGP peer may signal "Valid" (or "Invalid") and=20 another may signal "NotFound" for the same prefix.=20 Also, it is possible one IBGP peer may signal "Valid" and another may sign= al "Invalid" even when the origin AS is the same in the two updates. Two IBGP peers apparently not in sync w.r.t. their RPKI state. =20 The sidr-origin-validation-signaling I-D and RFC 7115 have not gone into discussing these situations. There are some subtleties involved.=20 For example, it is possible the IBGP peer signaling "Invalid" is actually = correct=20 and another IBGP peer signaling "NotFound" is actually wrong (relative to true global RPKI state). Sriram =20 =20 From nobody Tue Sep 9 06:56: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 05EDF1A6FA9 for ; Tue, 9 Sep 2014 06:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 toqWwUsi_H5w for ; Tue, 9 Sep 2014 06:56:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FC21A0410 for ; Tue, 9 Sep 2014 06:56:21 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1XRLu6-00035g-74; Tue, 09 Sep 2014 13:56:18 +0000 Date: Tue, 09 Sep 2014 22:56:16 +0900 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" In-Reply-To: <9a5bd319b65c4a64ba312a8b0c463e20@BN1PR09MB0274.namprd09.prod.outlook.com> References: <9a5bd319b65c4a64ba312a8b0c463e20@BN1PR09MB0274.namprd09.prod.outlook.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/xTG-3KjD6jYXc3gh6ccGa55SAJw Cc: "opsec@ietf.org" , "John G. Scudder \(jgs@bgp.nu\)" Subject: Re: [OPSEC] Last Call: (BGP operations and security) to Best Current Practice 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, 09 Sep 2014 13:56:24 -0000 > The situation of having in(valid) and notfound routes simultaneous for a prefix > also arises when a router is not doing its own origin-AS check but is > relying on neighboring IBGP speakers (all within the same AS): don't do that From nobody Tue Sep 9 08:12:59 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 B6EAD1A034D for ; Tue, 9 Sep 2014 08:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 fbQ8D6HVr_0e for ; Tue, 9 Sep 2014 08:12:47 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699AD1A6FB0 for ; Tue, 9 Sep 2014 08:12:44 -0700 (PDT) Received: from BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) by BN1PR09MB0274.namprd09.prod.outlook.com (25.160.80.23) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Tue, 9 Sep 2014 15:12:43 +0000 Received: from BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) by BN1PR09MB0274.namprd09.prod.outlook.com ([25.160.80.23]) with mapi id 15.00.1024.012; Tue, 9 Sep 2014 15:12:43 +0000 From: "Sriram, Kotikalapudi" To: Randy Bush Thread-Topic: [OPSEC] Last Call: (BGP operations and security) to Best Current Practice Thread-Index: Ac/MMNJXRz3hlm1YQ/mpDwi5pA0rrgABQCEAAAGx9YA= Date: Tue, 9 Sep 2014 15:12:43 +0000 Message-ID: <19cfbf3b7fc14567ab57e2952cf63cdb@BN1PR09MB0274.namprd09.prod.outlook.com> References: <9a5bd319b65c4a64ba312a8b0c463e20@BN1PR09MB0274.namprd09.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.6.222.19] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0329B15C8A x-forefront-antispam-report: SFV:NSPM; SFS:(10019018)(6009001)(189002)(199003)(76176999)(83322001)(74316001)(110136001)(64706001)(87936001)(21056001)(20776003)(92566001)(97736003)(85306004)(80022001)(54356999)(50986999)(105586002)(66066001)(81342001)(86362001)(108616004)(107046002)(76576001)(81542001)(31966008)(46102001)(106356001)(90102001)(95666004)(77982001)(99286002)(99396002)(76482001)(83072002)(101416001)(33646002)(74502001)(85852003)(74662001)(77096002)(230783001)(79102001)(2656002)(4396001)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB0274; H:BN1PR09MB0274.namprd09.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/daiyo5qPREDz6crNafhQRnh-yUY Cc: "opsec@ietf.org" , "John G. Scudder \(jgs@bgp.nu\)" Subject: Re: [OPSEC] Last Call: (BGP operations and security) to Best Current Practice 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, 09 Sep 2014 15:12:50 -0000 >> The situation of having in(valid) and notfound routes simultaneous=20 >> for a prefix also arises when a router is not doing its own origin-AS=20 >> check but is relying on neighboring IBGP speakers (all within the same = AS): >don't do that I was not proposing it. I was merely referring to the following from draft-ietf-sidr-origin-validation-signaling-04: =20 If the router is configured to support the extensions defined in this draft, it SHOULD attach the origin validation state extended community to BGP UPDATE messages sent to IBGP peers by mapping the computed validation state in the last octet of the extended community. Similarly on the receiving IBGP speakers, the validation state of an IBGP route SHOULD be derived directly from the last octet of the extended community, if present. It appears the origin-validation-signaling draft expired as of August 18. I am not aware if it is being pursued still or put aside. Sriram From nobody Wed Sep 10 20:14:51 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 F27C71A03AB for ; Wed, 10 Sep 2014 20:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-1.652, 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 qwfFApHda6fU for ; Wed, 10 Sep 2014 20:14:47 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with SMTP id A21561A0218 for ; Wed, 10 Sep 2014 20:14:46 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea5411139f75a-11911; Thu, 11 Sep 2014 11:14:39 +0800 (CST) X-RM-TRANSID: 2eea5411139f75a-11911 X-RM-SPAM-FLAG: 00000000 Received: from vicwork (unknown[10.1.228.212]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee55411139fd92-70610; Thu, 11 Sep 2014 11:14:39 +0800 (CST) X-RM-TRANSID: 2ee55411139fd92-70610 From: "Vic Liu" To: Date: Thu, 11 Sep 2014 11:15:21 +0800 Message-ID: <003601cfcd6e$9f4af4a0$dde0dde0$@chinamobile.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01CFCDB1.AD6FE250" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac/NbkzNIJ/acHsLT+aiFBQdMrjhPA== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/4S990svh3KRS6hIOXXnrtGduKgU Subject: Re: [OPSEC] ICMP/ICMPv6 network ingress filtering (Fwd: New Version Notification for draft-gont-opsec-icmp-ingress-filtering-00.txt) 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, 11 Sep 2014 03:14:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0037_01CFCDB1.AD6FE250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Fernando I read the document and think it is important work. In particular, I would be very glad to see this type of filtering implemented in CPE devices. Are you aware if Linux implements this? Section 4 should clarify that this filtering must be performed on icmp error messages. Document says 'SHOULD perform ingress filtering on the Destination Address of the IP packet embedded in the ICMP payload', but this does not apply to other icmp messages like icmp echo request and reply. Vic Liu Chinamobile Liuzhiheng@chinamobile.com -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Fernando Gont Sent: Friday, August 29, 2014 1:44 AM To: 'opsec@ietf.org'; IPv6 Operations Subject: [OPSEC] ICMP/ICMPv6 network ingress filtering (Fwd: New Version Notification for draft-gont-opsec-icmp-ingress-filtering-00.txt) Folks, Based on the recent discussion we have had about ICMP-based DoS attacks, we have posted an I-D which describes and suggests that network ingress filtering be applied on ICMPv4 and ICMPv6 error messages (based on the addresses of the embedded payload). The I-D is available at: Any feedback will be very appreciated. Thanks! Best regards, Fernando -------- Forwarded Message -------- Subject: New Version Notification for draft-gont-opsec-icmp-ingress-filtering-00.txt Date: Thu, 28 Aug 2014 10:37:47 -0700 From: internet-drafts@ietf.org To: Will(Shucheng) Liu >, Jeroen Massar >, Ray Hunter >, Fernando Gont >, Ray Hunter >, Jeroen Massar >, Fernando Gont >, Shucheng LIU (Will) > A new version of I-D, draft-gont-opsec-icmp-ingress-filtering-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Name: draft-gont-opsec-icmp-ingress-filtering Revision: 00 Title: Network Ingress Filtering: Defeating Attacks which employ Forged ICMP/ ICMPv6 Error Messages Document date: 2014-08-28 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-gont-opsec-icmp-ingress-filtering- 00.txt Status: https://datatracker.ietf.org/doc/draft-gont-opsec-icmp-ingress-filtering/ Htmlized: http://tools.ietf.org/html/draft-gont-opsec-icmp-ingress-filtering-00 Abstract: Over the years, a number of attack vectors that employ forged ICMP/ ICMPv6 error messages have been disclosed and exploited in the wild. The aforementioned attack vectors do not require that the source address of the packets be forged, but do require that the addresses of the IP/IPv6 packet embedded in the ICMP/ICMPv6 payload be forged. This document discusses a simple, effective, and straightforward method for using ingress traffic filtering to mitigate attacks that use forged addresses in the IP/IPv6 packet embedded in an ICMP/ICMPv6 payload. This advice is in line with the recommendations in BCP38. 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 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec ------=_NextPart_000_0037_01CFCDB1.AD6FE250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, = Fernando

 

I read the document and think it is important work.  = In particular, I would be very glad to see this type of filtering = implemented in CPE devices.  Are you aware if Linux implements = this?

 

Section 4 should clarify that this filtering must be = performed on icmp error messages.  Document says 'SHOULD perform = ingress filtering on the Destination Address of the IP packet embedded = in the ICMP payload', but this does not apply to other icmp messages = like icmp echo request and reply.

 

 

Vic Liu

Chinamobile

Liuzhiheng@chinamobile.com

 

 

-----Original = Message-----

From: OPSEC [mailto:opsec-bounces@ietf.org]= On Behalf Of Fernando Gont

Sent: Friday, August 29, 2014 = 1:44 AM

To: 'opsec@ietf.org'; IPv6 = Operations

Subject: [OPSEC] ICMP/ICMPv6 network ingress filtering = (Fwd: New Version Notification for = draft-gont-opsec-icmp-ingress-filtering-00.txt)

 

Folks,

 

Based on the recent discussion = we have had about ICMP-based DoS attacks, we have posted an I-D which = describes and suggests that network ingress filtering be applied on = ICMPv4 and ICMPv6 error messages (based on the addresses of the embedded = payload).

 

The I-D is available at:

<http://www.ietf.org/internet-drafts/draft-gont-opsec-i= cmp-ingress-filtering-00.txt>

 

Any feedback will be very = appreciated.

 

Thanks!

 

Best regards,

Fernando

 

 

 

 

-------- Forwarded Message = --------

Subject: New Version Notification = for

draft-gont-opsec-icmp-ingress-filtering-00.txt

Date: Thu, 28 Aug = 2014 10:37:47 -0700

From: internet-drafts@ietf.org

To: = Will(Shucheng) Liu <liushucheng@huawei.com>, = Jeroen Massar <jeroen@massar.ch>, Ray Hunter = <v6ops@globis.net>, = Fernando Gont <fgont@si6networks.com>, Ray = Hunter <v6ops@globis.net>, = Jeroen Massar <jeroen@massar.ch>, Fernando Gont = <fgont@si6networks.com>, = Shucheng LIU

(Will) <liushucheng@huawei.com>

 

 

A new version of I-D, = draft-gont-opsec-icmp-ingress-filtering-00.txt

has been successfully submitted = by Fernando Gont and posted to the IETF = repository.

 

Name:         &= nbsp;     = draft-gont-opsec-icmp-ingress-filtering

Revision:  = 00

Title:         =          Network Ingress = Filtering: Defeating Attacks which employ Forged

ICMP/ ICMPv6 Error = Messages

Document date:       = 2014-08-28

Group:         =       Individual = Submission

Pages:         =       9

URL:

http://www.ietf.org/internet-drafts/draft-gont-opsec-i= cmp-ingress-filtering-00.txt

Status:

https://datatracker.ietf.org/doc/draft-gont-opsec-icmp-ingress-= filtering/

Htmlized:

http://tools.ietf.org/html/draft-gont-opsec-icmp-ingress-filtering-= 00

 

 

Abstract:

   Over the years, a = number of attack vectors that employ forged = ICMP/

   ICMPv6 error messages have been disclosed and = exploited in the wild.

   The aforementioned = attack vectors do not require that the source

   address of the = packets be forged, but do require that the = addresses

   of the IP/IPv6 packet embedded in the = ICMP/ICMPv6 payload be forged.

   This document = discusses a simple, effective, and = straightforward

   method for using ingress traffic filtering to = mitigate attacks that

   use forged addresses in the IP/IPv6 packet = embedded in an ICMP/ICMPv6

   payload.  This = advice is in line with the recommendations in = BCP38.

 

 

 

 

 

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

 

 

 

 

_______________________________________________

OPSEC mailing = list

OPSEC@ietf.org

https://www.ietf.org= /mailman/listinfo/opsec

 

------=_NextPart_000_0037_01CFCDB1.AD6FE250-- From nobody Thu Sep 11 03:34:22 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 D97D21A06D3 for ; Thu, 11 Sep 2014 03:34:17 -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 Yq8b5SJc-rXr for ; Thu, 11 Sep 2014 03:34:15 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 4B7D51A06C7 for ; Thu, 11 Sep 2014 03:34:14 -0700 (PDT) Received: from [2001:5c0:1000:a::1447] by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XS1hV-0002NB-Vd; Thu, 11 Sep 2014 12:34:06 +0200 Message-ID: <54117073.9050206@si6networks.com> Date: Thu, 11 Sep 2014 06:50:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Vic Liu , opsec@ietf.org References: <003601cfcd6e$9f4af4a0$dde0dde0$@chinamobile.com> In-Reply-To: <003601cfcd6e$9f4af4a0$dde0dde0$@chinamobile.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/T6rZkC27m__d4EwN4_Cj4sWQR-g Subject: Re: [OPSEC] ICMP/ICMPv6 network ingress filtering (Fwd: New Version Notification for draft-gont-opsec-icmp-ingress-filtering-00.txt) 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, 11 Sep 2014 10:34:18 -0000 Hi, Vic, Thanks so much for your feedback! -- Please find my comments in-line... On 09/11/2014 12:15 AM, Vic Liu wrote: > > I read the document and think it is important work. In particular, I > would be very glad to see this type of filtering implemented in CPE > devices. Are you aware if Linux implements this? Don't recall if I ever checked. But I will, and will come back to you. > Section 4 should clarify that this filtering must be performed on icmp > error messages. Document says 'SHOULD perform ingress filtering on the > Destination Address of the IP packet embedded in the ICMP payload', but > this does not apply to other icmp messages like icmp echo request and reply. You're right. We will update the text to: IP nodes enforcing IP ingress filtering SHOULD perform ingress filtering on the Destination Address of the IP packets embedded in the payload of ICMP error messages. 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 Sep 24 02:27: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 5AC851A6F67 for ; Wed, 24 Sep 2014 02:27:46 -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 CzG-oE09rRSt for ; Wed, 24 Sep 2014 02:27:45 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC99B1A0041 for ; Wed, 24 Sep 2014 02:27:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=492; q=dns/txt; s=iport; t=1411550865; x=1412760465; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=T8C288/e2LnT9Q3+JgcI5pPdD71d0E9tdwEyh5eJm34=; b=VA7oFAlgCMPoYQ/fagq5Mzd6AitXGtJ9W/hZNWsTtImDruHQ1TjJ0i5A /0RMuM4ogrJsbdv1UhdVFzs12DvdfW9NQc8leHhnF9nYUV0Tbz+qG1GQ1 +J5amBpmCtzwTwueTFNTGbSmhslP0bdDPZWEi7u5sETD9Y02BukYXj7xw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAG6NIlStJV2Z/2dsb2JhbABfgw5TWAPKPYdNAYEIFgF6hAUBBB1uASoZPSYBBBuINg2cdKVlj22DZoEdBYsMhk+EOohpk3OCH4FDgjSBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,587,1406592000"; d="scan'208";a="80749555" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 24 Sep 2014 09:27:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8O9RfJK027685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Sep 2014 09:27:41 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.120]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 24 Sep 2014 04:27:41 -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/lhjHmPQ== Date: Wed, 24 Sep 2014 09:27:40 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2411C4DD6F@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.55.175.22] 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/sY6DeRpxoB0JERs8k9cpz8Q3HOg Subject: [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, 24 Sep 2014 09:27:46 -0000 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 Sep 24 18:55:33 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 321061A6F04 for ; Wed, 24 Sep 2014 18:55:28 -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 MACICPR5Cajk for ; Wed, 24 Sep 2014 18:55:26 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5591A6EFE for ; Wed, 24 Sep 2014 18:55:26 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id v10so8550633pde.6 for ; Wed, 24 Sep 2014 18:55:25 -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=ITLJtFqFCiTDU2aT3YRbbhzhh3Vv+usehdMJhBDNpRY=; b=lTX22srdrB2LURRS0FFqc7FotLkSGzydiwh/fv7AlnbIbGNSlW4SvaxaeruV+eMZmY /Hedc5SbwYCm+hcgTkPqnUx2P7WYSvxfnzyc6Zlts6rxMY2S6dXG6RSe8AWfVopbpex0 d2GtlXE7dGYIQEqwgJDNMRIXPzRVNm0QQFBEyvKZFtEzRI+anG7h9qyxmeT0GErgLtof MY2ZpFwCoh3rQd+UsfOm47lLKNIFGXN6Vp7nBefPt4VDIJt1PLD+cRZFSdrfAVwjnZx2 oX3ooaTzKj46Yq1LgrF8p1NbilQtjCekZQH7oPQc4ChpQRtHjHhuppa7X2m9qKCWCNNH UgpA== X-Received: by 10.66.144.195 with SMTP id so3mr594993pab.156.1411610124523; Wed, 24 Sep 2014 18:55:24 -0700 (PDT) Received: from [192.168.178.23] (163.199.69.111.dynamic.snap.net.nz. [111.69.199.163]) by mx.google.com with ESMTPSA id j13sm516785pbq.42.2014.09.24.18.55.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Sep 2014 18:55:23 -0700 (PDT) Message-ID: <5423760D.9060107@gmail.com> Date: Thu, 25 Sep 2014 13:55:25 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> In-Reply-To: <54231DD7.9040005@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/rDdN8_ru6uwCExFRNcPL-ogZgyc Cc: opsec@ietf.org Subject: Re: [OPSEC] [v6ops] FW: 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, 25 Sep 2014 01:55:28 -0000 I'm responding to the relevant WG as requested. I think the document is useful and realistic, given the real world in which firewalls live. I think OPSEC is the appropriate WG to adopt it. I am not convinced it should be a BCP; partly for the reason Joe gives, and partly because the advice may evolve in the light of experience. Making the document Informational softens that difficulty. Brian On 25/09/2014 07:39, Joe Touch wrote: > I am concerned about V6OPS advice that effectively deprecates IPv6 > capabilities in a BCP. IMO, if these are significant security or > performance issues, they should be reviewed within INTAREA as updates to > the IPv6 spec. > > To do this in a BCP undermines the spec without updating it. > > Some other comments: > > The advice sections in this doc fail to use RFC2119-style > recommendations. In some cases, lower-case is used, and in other cases > odd phrasing is used that avoids RFC2119 keywords. > > If this is indeed advice in the form of a BCP, the actual advice should > be provided in RFC2119-style format. > > Also, the term "intermediate systems" is used in a NOTE and is not > defined; this doc should clearly identify the type of systems that it is > intended for (e.g., routers). > > Joe > > On 9/24/2014 2:32 AM, Gunter Van de Velde (gvandeve) wrote: >> Dear, >> >> OPSEC Chairs requested "Call for WG adoption" on draft-gont-opsec-ipv6-eh-filtering. >> >> Please voice your reflexions in OPSEC WG >> >> G/ >> >> -----Original Message----- >> From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Velde (gvandeve) >> Sent: 24 September 2014 11:28 >> To: opsec@ietf.org >> Subject: [OPSEC] 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 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 >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From nobody Thu Sep 25 06:56:54 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 F07E21A00AF; Thu, 25 Sep 2014 06:56:47 -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 wrBbrfRrZQiI; Thu, 25 Sep 2014 06:56:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A99CB1A00D4; Thu, 25 Sep 2014 06:56:45 -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.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140925135645.5366.38630.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 06:56:45 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/p6g-wtZ5BxzXH9uHw4KVJbPXhaA Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-11.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: Thu, 25 Sep 2014 13:56:48 -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 : Using Only Link-Local Addressing Inside an IPv6 Network Authors : Michael Behringer Eric Vyncke Filename : draft-ietf-opsec-lla-only-11.txt Pages : 10 Date : 2014-09-25 Abstract: In an IPv6 network it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to help the decision process for a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-lla-only-11 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 Thu Sep 25 07:14:50 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 F26E61A00F9 for ; Thu, 25 Sep 2014 07:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, 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 53IwpNlSEBFL for ; Thu, 25 Sep 2014 07:14:47 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DAA71A00D8 for ; Thu, 25 Sep 2014 07:14:47 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id w61so6078694wes.26 for ; Thu, 25 Sep 2014 07:14:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=D6JzzXN4kM8pRos1EgRjjY9QZTSMn8umMpnr3P+qS+Q=; b=abiSnAIzSs2sWZfiAL3Qj3wQ18krCJfKoKijej3w2Hll6Jdd1SZl60CXnQvOf/UdaP HVf98muw6DRxXSDaRDjqOtiSp/z/QsfenhzF70I0/i2jDAfWFJFzHRBSN9bXG1B0JOiM +1iKUsEWBRg7lDPClRm+M3NrLQFD4D8+fuiepTy+geR+hxrQGpY5NH0C4Oe1INfAjkV9 UViIb9EZ51fkfoqKLyZgtmqQaEg9sdo+FEE/HrGAdCNVOKfZSlMEiSaglOFPk8MDmmYz VBj4xuyLQuk1UWJkUq7B/ndeTvc37ZrCpuxVuEk2cdrvNMWjcYQBIHUhrFCVfh7G+qib zuqA== X-Gm-Message-State: ALoCoQlE7Au9yYoDUBuzTS1+6eqtvjFwp8pbXqCa7SwwstKw7dZ/FEB6UTR2AMm2E91VhI1XguVt MIME-Version: 1.0 X-Received: by 10.194.86.34 with SMTP id m2mr16209763wjz.23.1411654485689; Thu, 25 Sep 2014 07:14:45 -0700 (PDT) Received: by 10.194.119.233 with HTTP; Thu, 25 Sep 2014 07:14:45 -0700 (PDT) In-Reply-To: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> Date: Thu, 25 Sep 2014 10:14:45 -0400 Message-ID: From: Warren Kumari To: "Gunter Van de Velde (gvandeve)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/d0CPgOg2JvYxZnd-nrM64c54JfU Cc: "opsec@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: Thu, 25 Sep 2014 14:14:49 -0000 On Wed, Sep 24, 2014 at 5:27 AM, Gunter Van de Velde (gvandeve) wrote: > 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? I do. I'm sad, but I do.... W > > 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Sep 25 07:33:41 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 EC3A21A7004; Thu, 25 Sep 2014 07:33:38 -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 gt7-zQ5CR6l0; Thu, 25 Sep 2014 07:33:37 -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 589891A7003; Thu, 25 Sep 2014 07:33:37 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8PEWHLU013647 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 07:32:27 -0700 (PDT) Message-ID: <54242773.9040005@isi.edu> Date: Thu, 25 Sep 2014 07:32:19 -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: "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> In-Reply-To: <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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/Rqr_Wra34rzBP6-ldYHhFO-KUHA Cc: "'opsec@ietf.org'" , "v6ops@ietf.org" 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: Thu, 25 Sep 2014 14:33:39 -0000 Hi, all, On 9/24/2014 11:56 PM, Fred Baker (fred) wrote: > For the record, Opsec is considering adopting the draft, not v6ops; I'm including both groups in this response. > Gunter asked v6ops to chime in on the discussion in opsec. The author > has been asking both sets of chairs, and I haven’t seen the > groundswell of support, or even comment, that would lead in the > direction of v6ops adoption. When a doc is "shopped around", that tells me it's not ready for anything. The ADs should determine where a doc belongs and should alert related WGs at that time - and during WGLC. > I personally share your concerns; if we > want to deprecate parts of RFC 2460, I think we need to do that in > 6man. I disagree. This is a significant change to the IPv6 spec; the 6man charter excludes those: --- The 6man working group is responsible for the maintenance, upkeep, and advancement of the IPv6 protocol specifications and addressing architecture. It is not chartered to develop major changes or additions to the IPv6 specifications.... > What v6ops or opsec would be chartered to do is give advice. Agreed. IMO, advice should be limited to explaining cases that fall under MAY or SHOULD in other documents. Anything that overrides a MUST or MUST NOT needs to happen in the WG chartered to update the original doc; AFAICT, that's only INTAREA in this case (if not, it's certainly not *OPS or *MAN). Joe From nobody Thu Sep 25 08:39:48 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 338221A7022; Thu, 25 Sep 2014 08:39:45 -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 sN89EBFtrWYE; Thu, 25 Sep 2014 08:39:44 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D2A1A010C; Thu, 25 Sep 2014 08:39:44 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s8PFcnLP024876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 08:39:03 -0700 (PDT) Message-ID: <5424370B.8080900@isi.edu> Date: Thu, 25 Sep 2014 08:38:51 -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: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> In-Reply-To: <54242DAA.8000404@si6networks.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/C0CLJFOnessbiVU3KVBeVPUMr3k Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Thu, 25 Sep 2014 15:39:45 -0000 On 9/25/2014 7:58 AM, Fernando Gont wrote: ... > May I ask where does draft-gont-opsec-ipv6-eh-filtering try to deprecate > anything? In every statement where an existing IPv6 required capability is changed. E.g.: - demotes requirements to "SHOULDS" (most x.x.x.5 sections). - deprecates the flags in HBH options intended to declare how an option is handled when not known by providing advice specific to each option type that does not consider the flag setting Joe From nobody Thu Sep 25 08:46: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 139BF1A7006; Thu, 25 Sep 2014 08:46: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 dS0PXezegrAP; Thu, 25 Sep 2014 08:45:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 BB1D11A0174; Thu, 25 Sep 2014 08:45:59 -0700 (PDT) Received: from [186.137.80.27] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XXBEv-000320-MX; Thu, 25 Sep 2014 17:45:53 +0200 Message-ID: <542438A8.60801@si6networks.com> Date: Thu, 25 Sep 2014 12:45:44 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Joe Touch , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242773.9040005@isi.edu> In-Reply-To: <54242773.9040005@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/fO57a5Oe3F74xlk36EvU1yxQN1g Cc: "'opsec@ietf.org'" , "v6ops@ietf.org" 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: Thu, 25 Sep 2014 15:46:02 -0000 On 09/25/2014 11:32 AM, Joe Touch wrote: > On 9/24/2014 11:56 PM, Fred Baker (fred) wrote: >> For the record, Opsec is considering adopting the draft, not v6ops; > > I'm including both groups in this response. > >> Gunter asked v6ops to chime in on the discussion in opsec. The author >> has been asking both sets of chairs, and I haven’t seen the >> groundswell of support, or even comment, that would lead in the >> direction of v6ops adoption. > > When a doc is "shopped around", that tells me it's not ready for > anything. The ADs should determine where a doc belongs and should alert > related WGs at that time - and during WGLC. The document has never been "shopped around". Please see my response to Fred. >> What v6ops or opsec would be chartered to do is give advice. > > Agreed. IMO, advice should be limited to explaining cases that fall > under MAY or SHOULD in other documents. > > Anything that overrides a MUST or MUST NOT needs to happen in the WG > chartered to update the original doc; AFAICT, that's only INTAREA in > this case (if not, it's certainly not *OPS or *MAN). Could you please point out which part of this I-D overrides a MUST or SHOULD? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 25 08:53: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 8FA311A8033; Thu, 25 Sep 2014 08:52:57 -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 nC_cwdGF9Khy; Thu, 25 Sep 2014 08:52:56 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 F1EEB1A802D; Thu, 25 Sep 2014 08:52:55 -0700 (PDT) Received: from [186.137.80.27] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XXBLf-000348-54; Thu, 25 Sep 2014 17:52:51 +0200 Message-ID: <54243A4B.9010704@si6networks.com> Date: Thu, 25 Sep 2014 12:52:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Joe Touch , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> In-Reply-To: <5424370B.8080900@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/6VwqiDZIUIi56bUathPZAmaMF1o Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Thu, 25 Sep 2014 15:52:57 -0000 On 09/25/2014 12:38 PM, Joe Touch wrote: > On 9/25/2014 7:58 AM, Fernando Gont wrote: > ... >> May I ask where does draft-gont-opsec-ipv6-eh-filtering try to deprecate >> anything? > > In every statement where an existing IPv6 required capability is changed. > > E.g.: > - demotes requirements to "SHOULDS" (most x.x.x.5 sections). They are lowercase shoulds. And not protocol changes, but operational advice. > - deprecates the flags in HBH options intended to declare how an option > is handled when not known by providing advice specific to each option > type that does not consider the flag setting The advice in this I-D essentially mimics RFC7045 for options. That was the intent. Am I missing something? Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 25 09:13:36 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 A7D5E1A0174; Thu, 25 Sep 2014 09:13:33 -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 SreNxZY2wGLL; Thu, 25 Sep 2014 09:13:31 -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 88D711A00CF; Thu, 25 Sep 2014 09:13:31 -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 s8PGDDTl018905; Thu, 25 Sep 2014 17:13:13 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk s8PGDDTl018905 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1411661594; bh=FEx6rIWAov1cZxOVmqa+Tq4hh3s=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=z6XYsnKueO9f+kp4FG7YFmzUe2FJsSmL46xjh1ZjafhNegrdcpPLYsgbC60UkBuzJ IsiMfG+xuX41K/U3m8Va/vAylaznPSSwI4VGa0jbNwU/lrFNEA6Ws91jEBEN4k13f0 q5V4iLmS6XzntThxlIZyUUfbkN5erOOaT49QE54s= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id q8OHDD0935009884b2 ret-id none; Thu, 25 Sep 2014 17:13:14 +0100 Received: from [IPv6:2001:630:d0:ed04:4dbb:aa55:d289:997b] ([IPv6:2001:630:d0:ed04:4dbb:aa55:d289:997b]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id s8PGDBlB002853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 25 Sep 2014 17:13:11 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Tim Chown In-Reply-To: <54243A4B.9010704@si6networks.com> Date: Thu, 25 Sep 2014 17:13:10 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <285EA688-C29C-475F-9CA0-D0BAB1678A2F@ecs.soton.ac.uk> To: Fernando Gont X-Mailer: Apple Mail (2.1878.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=q8OHDD093500988400; tid=q8OHDD0935009884b2; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: s8PGDDTl018905 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/dfutopz-c7YyiYqxRNi9F24UjeY Cc: "v6ops@ietf.org" , "opsec@ietf.org" , 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: Thu, 25 Sep 2014 16:13:33 -0000 On 25 Sep 2014, at 16:52, Fernando Gont wrote: > On 09/25/2014 12:38 PM, Joe Touch wrote: >>=20 >>=20 >> In every statement where an existing IPv6 required capability is = changed. >>=20 >> E.g.: >> - demotes requirements to "SHOULDS" (most x.x.x.5 sections). >=20 > They are lowercase shoulds. And not protocol changes, but operational > advice. >=20 >> - deprecates the flags in HBH options intended to declare how an = option >> is handled when not known by providing advice specific to each option >> type that does not consider the flag setting >=20 > The advice in this I-D essentially mimics RFC7045 for options. That = was > the intent. Am I missing something? Hi, I would say that putting forward operational recommendations in a style = similar to RFC4890, which does not use RFC2119 language, is both = appropriate and useful. I agree that were there specific protocol changes then of course these = should be run through 6man (most likely) to update existing RFCs. There are many drafts that fall between v6ops and opsec, where the scope = is IPv6 operational security practices. Tim= From nobody Thu Sep 25 09:40:38 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 AC59C1A870C; Thu, 25 Sep 2014 09:40:36 -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 egp2VRayAcN1; Thu, 25 Sep 2014 09:40:35 -0700 (PDT) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B4A1A8708; Thu, 25 Sep 2014 09:40:35 -0700 (PDT) Received: from [192.168.1.10] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s8PGdqVA016992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 09:40:02 -0700 (PDT) Message-ID: <5424455A.7040501@isi.edu> Date: Thu, 25 Sep 2014 09:39:54 -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: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> In-Reply-To: <54243A4B.9010704@si6networks.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/CUHt28_vCZVEC0yLx_TfhGxYOP4 Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Thu, 25 Sep 2014 16:40:36 -0000 On 9/25/2014 8:52 AM, Fernando Gont wrote: > On 09/25/2014 12:38 PM, Joe Touch wrote: >> On 9/25/2014 7:58 AM, Fernando Gont wrote: >> ... >>> May I ask where does draft-gont-opsec-ipv6-eh-filtering try to deprecate >>> anything? >> >> In every statement where an existing IPv6 required capability is changed. >> >> E.g.: >> - demotes requirements to "SHOULDS" (most x.x.x.5 sections). > > They are lowercase shoulds. And not protocol changes, but operational > advice. I see no utility to a BCP that makes operational recommendations without qualifying them in RFC2119 language. Further, this doc does not explicitly indicate the distinction between upper and lowercase of the RFC2119 terms. IMO, except for use in discussion prose, those terms need to be avoided at all cost except where used in their RFC2119 sense. >> - deprecates the flags in HBH options intended to declare how an option >> is handled when not known by providing advice specific to each option >> type that does not consider the flag setting > > The advice in this I-D essentially mimics RFC7045 for options. That was > the intent. Am I missing something? The places where you provide contradictory advice, notably (from 7045): RFC 2460 requires destination hosts to discard packets containing unrecognised extension headers. However, intermediate forwarding nodes SHOULD NOT do this, since that might cause them to inadvertently discard traffic using a recently standardised extension header not yet recognised by the intermediate node. The exceptions to this rule are discussed next. Joe From nobody Thu Sep 25 11:58: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 85E861A0315; Thu, 25 Sep 2014 11:58:27 -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 kGwGJ6d3yVQg; Thu, 25 Sep 2014 11:58:25 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 F13781A02D6; Thu, 25 Sep 2014 11:58:24 -0700 (PDT) Received: from [186.137.80.27] (helo=[192.168.3.107]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XXEF8-0003sk-DQ; Thu, 25 Sep 2014 20:58:18 +0200 Message-ID: <542465BB.7050404@si6networks.com> Date: Thu, 25 Sep 2014 15:58:03 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Joe Touch , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> In-Reply-To: <5424455A.7040501@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/J6jNDisrBJeCTve6J08TBaTJIug Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Thu, 25 Sep 2014 18:58:27 -0000 On 09/25/2014 01:39 PM, Joe Touch wrote: >>> In every statement where an existing IPv6 required capability is changed. >>> >>> E.g.: >>> - demotes requirements to "SHOULDS" (most x.x.x.5 sections). >> >> They are lowercase shoulds. And not protocol changes, but operational >> advice. > > I see no utility to a BCP that makes operational recommendations without > qualifying them in RFC2119 language. Yes, the document track should be changed to Informational, as suggested by Brian. > Further, this doc does not explicitly indicate the distinction between > upper and lowercase of the RFC2119 terms. It's the uppercase that are special, not the lowercase. There's a single bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. >>> - deprecates the flags in HBH options intended to declare how an option >>> is handled when not known by providing advice specific to each option >>> type that does not consider the flag setting >> >> The advice in this I-D essentially mimics RFC7045 for options. That was >> the intent. Am I missing something? > > The places where you provide contradictory advice, notably (from 7045): > > RFC 2460 requires destination hosts to discard packets containing > unrecognised extension headers. However, intermediate forwarding > nodes SHOULD NOT do this, since that might cause them to > inadvertently discard traffic using a recently standardised extension > header not yet recognised by the intermediate node. The exceptions > to this rule are discussed next. Looks like you've decided to ignore the next paragraph, which says: If a forwarding node discards a packet containing a standard IPv6 extension header, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. This means that the discard policy for each standard type of extension header MUST be individually configurable. The default configuration SHOULD allow all standard extension headers. and also ignore the Security Considerations, which says: These changes do not affect a firewall's ability to filter out traffic containing unwanted or suspect extension headers, if configured to do so. However, the changes do require firewalls to be capable of permitting any or all extension headers, if configured to do so. The default configurations are intended to allow normal use of any standard extension header, avoiding the connectivity issues described in Sections 1 and 2.1. draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* a default policy or the like (and this is pretty clear in the Intro). So it doesn't go against RFC7045. For instance, that was the main/sole goal of the latest rev of the I-D Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Thu Sep 25 13:24: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 75D6E1A0350; Thu, 25 Sep 2014 13:24:51 -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 XFthsqOhqc-Q; Thu, 25 Sep 2014 13:24:50 -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 023E81A0337; Thu, 25 Sep 2014 13:24:49 -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 s8PKOBh8026649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 13:24:11 -0700 (PDT) Message-ID: <542479EB.1010406@isi.edu> Date: Thu, 25 Sep 2014 13:24:11 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <542465BB.7050404@si6networks.com> In-Reply-To: <542465BB.7050404@si6networks.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/eLLiU9Bk-IQWm3Qsc-8rhSeSwQ0 Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Thu, 25 Sep 2014 20:24:51 -0000 On 9/25/2014 11:58 AM, Fernando Gont wrote: > On 09/25/2014 01:39 PM, Joe Touch wrote: ... >> Further, this doc does not explicitly indicate the distinction between >> upper and lowercase of the RFC2119 terms. > > It's the uppercase that are special, not the lowercase. There's a single > bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. The doc needs to remove the definition of 2119 language, and IMO also needs to add a statement that no use of those terms is intended in the 2119 sense. When both are used (both 2119-sense and not), I use the following text to make the distinction explicit: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. >>>> - deprecates the flags in HBH options intended to declare how an option >>>> is handled when not known by providing advice specific to each option >>>> type that does not consider the flag setting >>> >>> The advice in this I-D essentially mimics RFC7045 for options. That was >>> the intent. Am I missing something? >> >> The places where you provide contradictory advice, notably (from 7045): >> >> RFC 2460 requires destination hosts to discard packets containing >> unrecognised extension headers. However, intermediate forwarding >> nodes SHOULD NOT do this, since that might cause them to >> inadvertently discard traffic using a recently standardised extension >> header not yet recognised by the intermediate node. The exceptions >> to this rule are discussed next. > > Looks like you've decided to ignore the next paragraph, which says: > > If a forwarding node discards a packet containing a standard IPv6 > extension header, it MUST be the result of a configurable policy and > not just the result of a failure to recognise such a header. This > means that the discard policy for each standard type of extension > header MUST be individually configurable. The default configuration > SHOULD allow all standard extension headers. The term "standard" in that paragraph refers to a specific set of extensions defined in RFC2460 - i.e., those that are deemed mandatory to support. Your doc refers to other extensions that were not defined in RFC2460, and for which that paragraph does not apply. > and also ignore the Security Considerations, which says: > > These changes do not affect a firewall's ability to filter out > traffic containing unwanted or suspect extension headers, if > configured to do so. However, the changes do require firewalls to be > capable of permitting any or all extension headers, if configured to > do so. The default configurations are intended to allow normal use > of any standard extension header, avoiding the connectivity issues > described in Sections 1 and 2.1. The recommendations in your document are to have a default that overrides the security considerations in RFC2460. Your doc would have to say something like "when the following attack is noticed,..." or "in the following specific use case...". > draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* > a default policy or the like (and this is pretty clear in the Intro). So > it doesn't go against RFC7045. For instance, that was the main/sole goal > of the latest rev of the I-D Advice that doesn't give a specific context is advice to override a default, IMO. You need a lot more context to explain when and/or where such overrides are relevant. Joe From nobody Thu Sep 25 13:26: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 834E41A0350; Thu, 25 Sep 2014 13:26: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 K9FppEeAaSLc; Thu, 25 Sep 2014 13:26: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 186CA1A01D6; Thu, 25 Sep 2014 13:26: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 s8PKPcBU026789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 13:25:38 -0700 (PDT) Message-ID: <54247A42.4040400@isi.edu> Date: Thu, 25 Sep 2014 13:25:38 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <542465BB.7050404@si6networks.com> <542479EB.1010406@isi.edu> In-Reply-To: <542479EB.1010406@isi.edu> 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/lUfPP2K7VDd4V-8-6X8SxNyH8oI Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Thu, 25 Sep 2014 20:26:30 -0000 PS - I have a day job, and this isn't it. If others care about this doc, I encourage them to speak up. In its current form, I don't support its adoption by any WG. Joe On 9/25/2014 1:24 PM, Joe Touch wrote: > > > On 9/25/2014 11:58 AM, Fernando Gont wrote: >> On 09/25/2014 01:39 PM, Joe Touch wrote: > ... >>> Further, this doc does not explicitly indicate the distinction between >>> upper and lowercase of the RFC2119 terms. >> >> It's the uppercase that are special, not the lowercase. There's a single >> bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. > > The doc needs to remove the definition of 2119 language, and IMO also > needs to add a statement that no use of those terms is intended in the > 2119 sense. > > When both are used (both 2119-sense and not), I use the following text > to make the distinction explicit: > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in RFC-2119 [RFC2119]. > > In this document, these words will appear with that interpretation > only when in ALL CAPS. Lower case uses of these words are not to be > interpreted as carrying RFC-2119 significance. > >>>>> - deprecates the flags in HBH options intended to declare how an option >>>>> is handled when not known by providing advice specific to each option >>>>> type that does not consider the flag setting >>>> >>>> The advice in this I-D essentially mimics RFC7045 for options. That was >>>> the intent. Am I missing something? >>> >>> The places where you provide contradictory advice, notably (from 7045): >>> >>> RFC 2460 requires destination hosts to discard packets containing >>> unrecognised extension headers. However, intermediate forwarding >>> nodes SHOULD NOT do this, since that might cause them to >>> inadvertently discard traffic using a recently standardised extension >>> header not yet recognised by the intermediate node. The exceptions >>> to this rule are discussed next. >> >> Looks like you've decided to ignore the next paragraph, which says: >> >> If a forwarding node discards a packet containing a standard IPv6 >> extension header, it MUST be the result of a configurable policy and >> not just the result of a failure to recognise such a header. This >> means that the discard policy for each standard type of extension >> header MUST be individually configurable. The default configuration >> SHOULD allow all standard extension headers. > > The term "standard" in that paragraph refers to a specific set of > extensions defined in RFC2460 - i.e., those that are deemed mandatory to > support. > > Your doc refers to other extensions that were not defined in RFC2460, > and for which that paragraph does not apply. > >> and also ignore the Security Considerations, which says: >> >> These changes do not affect a firewall's ability to filter out >> traffic containing unwanted or suspect extension headers, if >> configured to do so. However, the changes do require firewalls to be >> capable of permitting any or all extension headers, if configured to >> do so. The default configurations are intended to allow normal use >> of any standard extension header, avoiding the connectivity issues >> described in Sections 1 and 2.1. > > The recommendations in your document are to have a default that > overrides the security considerations in RFC2460. Your doc would have to > say something like "when the following attack is noticed,..." or "in the > following specific use case...". > >> draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* >> a default policy or the like (and this is pretty clear in the Intro). So >> it doesn't go against RFC7045. For instance, that was the main/sole goal >> of the latest rev of the I-D > > Advice that doesn't give a specific context is advice to override a > default, IMO. You need a lot more context to explain when and/or where > such overrides are relevant. > > Joe > From nobody Thu Sep 25 13:30:44 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 CE4A41A0365; Thu, 25 Sep 2014 13:30:40 -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 QAWmym-9DkIx; Thu, 25 Sep 2014 13:30:39 -0700 (PDT) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3DB1A035B; Thu, 25 Sep 2014 13:30:38 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id lf10so11552993pab.8 for ; Thu, 25 Sep 2014 13:30:38 -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=IcMzd9CfzD+QoDE599L+WSH5wrWeVw5wtVHduifKYd8=; b=GBceejyYB39Am54sUkPU0K0lO8YeoZ92mg6Hg4uDpZTuIuWlVYDomV+OISxKV0SS2x jemxM4Y/GLh57F4m9pBRYWJvUxq9SwV6WDbnuIaQ7DfoZjiB5BwNShV9X3948HEIAtAv f/AML6gP1F90b8SUaJfY61L8oU/v6x2kpAh3OyUDoS6nSF4mehUbgYQ/72t6k6U4bLLU QAe65ZXr7FXpvtFNDhcdLC7R52YJQzx3N4D4koggzPdYEk4Mx8HOc6OdDzPKHzv4SYoU LxI8NdUjAXnr0gMW8tG0rzZfgl+ga84XxsziR7k9zU1vKIVvXKx/c77QnmxgNnuyoBAe 4UWQ== X-Received: by 10.68.76.35 with SMTP id h3mr23636665pbw.66.1411677038728; Thu, 25 Sep 2014 13:30:38 -0700 (PDT) Received: from [192.168.178.23] (99.201.69.111.dynamic.snap.net.nz. [111.69.201.99]) by mx.google.com with ESMTPSA id ah7sm2966739pbd.52.2014.09.25.13.30.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 13:30:37 -0700 (PDT) Message-ID: <54247B72.7040700@gmail.com> Date: Fri, 26 Sep 2014 08:30:42 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> In-Reply-To: <5424455A.7040501@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/uDTZlQp5V2as_bi-xW9FQKu0tPY Cc: Fernando Gont , "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Thu, 25 Sep 2014 20:30:41 -0000 I've given my views of this draft on the appropriate list, but... On 26/09/2014 04:39, Joe Touch wrote: ... > I see no utility to a BCP that makes operational recommendations without > qualifying them in RFC2119 language. Why? The word "should" is a perfectly clear word in the English language. RFC 2119 qualifies its meaning in a particular way, but there's nothing in the IETF process that requires us to use that qualification. > Further, this doc does not explicitly indicate the distinction between > upper and lowercase of the RFC2119 terms. Huh? It cites RFC 2119 in the prescribed words, which make it clear that "SHOULD" is a qualified version of "should". It's quite common for RFCs to use both. (The only word that can be problematic in that way is "may" - I have take to using "might" to avoid the ambiguity in "may".) > IMO, except for use in > discussion prose, those terms need to be avoided at all cost except > where used in their RFC2119 sense. Why? RFC 2119 is perfectly clear about how it qualifies normal usage. Brian From nobody Thu Sep 25 14:18: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 A970E1A19E8; Thu, 25 Sep 2014 14:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JpM5zO7Iu1lq; Thu, 25 Sep 2014 14:18:19 -0700 (PDT) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2AB1A19E5; Thu, 25 Sep 2014 14:18:19 -0700 (PDT) Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s8PLHpL8012170 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 Sep 2014 14:17:51 -0700 (PDT) Message-ID: <5424867F.6060201@isi.edu> Date: Thu, 25 Sep 2014 14:17:51 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Brian E Carpenter References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <54247B72.7040700@gmail.com> In-Reply-To: <54247B72.7040700@gmail.com> Content-Type: text/plain; charset=utf-8 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/J9vrcrDwRb8JIIV2o5vyVG2I0iA Cc: Fernando Gont , "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Thu, 25 Sep 2014 21:18:20 -0000 On 9/25/2014 1:30 PM, Brian E Carpenter wrote: > I've given my views of this draft on the appropriate list, but... > > On 26/09/2014 04:39, Joe Touch wrote: > ... >> I see no utility to a BCP that makes operational recommendations without >> qualifying them in RFC2119 language. > > Why? The word "should" is a perfectly clear word in the English language. > RFC 2119 qualifies its meaning in a particular way, but there's nothing > in the IETF process that requires us to use that qualification. If this issued as a BCP, there should be recommendations in RFC2119 language. A BCP with no such recommendations doesn't explain current practice sufficiently, IMO. >> Further, this doc does not explicitly indicate the distinction between >> upper and lowercase of the RFC2119 terms. > > Huh? It cites RFC 2119 in the prescribed words, which make it clear > that "SHOULD" is a qualified version of "should". It's quite common for > RFCs to use both. (The only word that can be problematic in that way > is "may" - I have take to using "might" to avoid the ambiguity in > "may".) Once you cite RFC2119, you're saying that the key words used have special meaning. There's nothing in RFC2119 that requires them to be capitalized; the use of capitals is mentioned only in the abstract: These words are often capitalized. Often. Not exclusively. IMO, if you want to mix 2119 and non-2119 it is necessary to be explicit in how to tell the difference. >> IMO, except for use in >> discussion prose, those terms need to be avoided at all cost except >> where used in their RFC2119 sense. > > Why? RFC 2119 is perfectly clear about how it qualifies normal usage. I found only text that defines their use as exclusively having special meaning: This document defines these words as they should be interpreted in IETF documents. Can you point to where you found the doc to say otherwise? Joe From nobody Thu Sep 25 15:56:36 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 9C4461A0041; Thu, 25 Sep 2014 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 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, GB_I_LETTER=-2, 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 4Rx2Gcy_qJub; Thu, 25 Sep 2014 15:56:30 -0700 (PDT) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 306E51A00B9; Thu, 25 Sep 2014 15:56:29 -0700 (PDT) Received: by mail-pd0-f170.google.com with SMTP id y13so11538734pdi.1 for ; Thu, 25 Sep 2014 15:56:29 -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=YQb27irJwK+WFDWj+to3rmgEh0PXGRZoUphi2jA1Y0A=; b=b33vEARn4gAC3QR8Ra+VY07s38w4k1F27N5Ht+Ph5AAXIOLzSDjOJmNXB7z/CU5CFF tOodVHOgRXGRkbWI6LINPjpU907GAEz7f6bTMFr2qTwyDnTR2ubRXbPzXBz47vQ5y0zm 8SL7E6BkuWmTwMmaNaCHa2OAg14a3CBafTXwmceNDJbu6YoRhvgQHcZIq3v4+IwkbheT fGprYLWBFTycuDA6HtONwsliqHobPlj+wXhFi0xbEgmu/BBApF1pS3stFu6z+CqjacpH wuKkqEXoS0VqAvZsM9Jt39g51tM2YAR9tiksIhS2GyVvEpKtRFWidB/V4gniyzUOk1Xw PPyQ== X-Received: by 10.68.183.68 with SMTP id ek4mr24746659pbc.54.1411685789658; Thu, 25 Sep 2014 15:56:29 -0700 (PDT) Received: from [130.216.38.108] (sc-cs-567-laptop.cs.auckland.ac.nz. [130.216.38.108]) by mx.google.com with ESMTPSA id ds14sm3155815pdb.20.2014.09.25.15.56.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Sep 2014 15:56:28 -0700 (PDT) Message-ID: <54249DA2.8050509@gmail.com> Date: Fri, 26 Sep 2014 10:56:34 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joe Touch References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <54247B72.7040700@gmail.com> <5424867F.6060201@isi.edu> In-Reply-To: <5424867F.6060201@isi.edu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/a_bBUZLV2k8mOJN3f-BgOXJvHXk Cc: Fernando Gont , "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Thu, 25 Sep 2014 22:56:31 -0000 I agree it would have been better if RFC 2119 had specified upper case letters. Apart from that, I have said all I plan to say on this topic. Brian On 26/09/2014 09:17, Joe Touch wrote: > > On 9/25/2014 1:30 PM, Brian E Carpenter wrote: >> I've given my views of this draft on the appropriate list, but... >> >> On 26/09/2014 04:39, Joe Touch wrote: >> ... >>> I see no utility to a BCP that makes operational recommendations without >>> qualifying them in RFC2119 language. >> Why? The word "should" is a perfectly clear word in the English language. >> RFC 2119 qualifies its meaning in a particular way, but there's nothing >> in the IETF process that requires us to use that qualification. > > If this issued as a BCP, there should be recommendations in RFC2119 > language. A BCP with no such recommendations doesn't explain current > practice sufficiently, IMO. > >>> Further, this doc does not explicitly indicate the distinction between >>> upper and lowercase of the RFC2119 terms. >> Huh? It cites RFC 2119 in the prescribed words, which make it clear >> that "SHOULD" is a qualified version of "should". It's quite common for >> RFCs to use both. (The only word that can be problematic in that way >> is "may" - I have take to using "might" to avoid the ambiguity in >> "may".) > > Once you cite RFC2119, you're saying that the key words used have > special meaning. There's nothing in RFC2119 that requires them to be > capitalized; the use of capitals is mentioned only in the abstract: > > These words are often capitalized. > > Often. Not exclusively. IMO, if you want to mix 2119 and non-2119 it is > necessary to be explicit in how to tell the difference. > >>> IMO, except for use in >>> discussion prose, those terms need to be avoided at all cost except >>> where used in their RFC2119 sense. >> Why? RFC 2119 is perfectly clear about how it qualifies normal usage. > > I found only text that defines their use as exclusively having special > meaning: > > This document defines these words as they should be > interpreted in IETF documents. > > Can you point to where you found the doc to say otherwise? > > Joe > From nobody Sun Sep 28 05:02: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 BBA281A1A6B; Sun, 28 Sep 2014 05:02:52 -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 tzm_j746FYGq; Sun, 28 Sep 2014 05:02:50 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 560891A1A52; Sun, 28 Sep 2014 05:02:49 -0700 (PDT) Received: from [201.221.226.50] (helo=[192.168.102.57]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XYDBV-0007ld-HP; Sun, 28 Sep 2014 14:02:39 +0200 Message-ID: <5424A425.7060407@si6networks.com> Date: Thu, 25 Sep 2014 20:24:21 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Joe Touch , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <542465BB.7050404@si6networks.com> <542479EB.1010406@isi.edu> In-Reply-To: <542479EB.1010406@isi.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/vz4Jm_5hIQZ4by9vnNMEv1UER9U Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" 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: Sun, 28 Sep 2014 12:02:53 -0000 Hi, Joe, On 09/25/2014 05:24 PM, Joe Touch wrote: > On 9/25/2014 11:58 AM, Fernando Gont wrote: >> On 09/25/2014 01:39 PM, Joe Touch wrote: > ... >>> Further, this doc does not explicitly indicate the distinction between >>> upper and lowercase of the RFC2119 terms. >> >> It's the uppercase that are special, not the lowercase. There's a single >> bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. > > The doc needs to remove the definition of 2119 language, and IMO also > needs to add a statement that no use of those terms is intended in the > 2119 sense. [...] FWIW, I have no issues adding such a description if deemed necessary. However, if anything, this is easily fixable, and certainly not a show-stopper. >>> The places where you provide contradictory advice, notably (from 7045): >>> >>> RFC 2460 requires destination hosts to discard packets containing >>> unrecognised extension headers. However, intermediate forwarding >>> nodes SHOULD NOT do this, since that might cause them to >>> inadvertently discard traffic using a recently standardised extension >>> header not yet recognised by the intermediate node. The exceptions >>> to this rule are discussed next. >> >> Looks like you've decided to ignore the next paragraph, which says: >> >> If a forwarding node discards a packet containing a standard IPv6 >> extension header, it MUST be the result of a configurable policy and >> not just the result of a failure to recognise such a header. This >> means that the discard policy for each standard type of extension >> header MUST be individually configurable. The default configuration >> SHOULD allow all standard extension headers. > > The term "standard" in that paragraph refers to a specific set of > extensions defined in RFC2460 - i.e., those that are deemed mandatory to > support. > > Your doc refers to other extensions that were not defined in RFC2460, > and for which that paragraph does not apply. That's not correct. NPlease see Section 1.1 of RFC7045, which says: In this document, "standard" IPv6 extension headers are those specified in detail by IETF Standards Actions [RFC5226]. "Experimental" extension headers include those defined by any Experimental RFC and the header values 253 and 254 defined by [RFC3692] and [RFC4727] when used as experimental extension headers. "Defined" extension headers are the "standard" extension headers plus the "experimental" ones. >> and also ignore the Security Considerations, which says: >> >> These changes do not affect a firewall's ability to filter out >> traffic containing unwanted or suspect extension headers, if >> configured to do so. However, the changes do require firewalls to be >> capable of permitting any or all extension headers, if configured to >> do so. The default configurations are intended to allow normal use >> of any standard extension header, avoiding the connectivity issues >> described in Sections 1 and 2.1. > > The recommendations in your document are to have a default that > overrides the security considerations in RFC2460. Nope. Please check Section 2.2 of our I-D, which says: The advice provided in this document is only meant to guide an operator in configuring forwarding devices, and is *not* to be interpreted as advice regarding default configuration settings for network devices. That is, this document provides advice with respect to operational configurations, but does not change the implementation defaults required by [RFC7045] and [draft-gont-6man-ipv6-opt-transmit]. i.e., our recommendations shouldn't be used as "default configurations" of any devices. >> draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* >> a default policy or the like (and this is pretty clear in the Intro). So >> it doesn't go against RFC7045. For instance, that was the main/sole goal >> of the latest rev of the I-D > > Advice that doesn't give a specific context is advice to override a > default, IMO. You need a lot more context to explain when and/or where > such overrides are relevant. If you look closely at the I-D, it is essentially a "default allow", modulo HBH, in which case we provide recommendations 8a few options) well within RFC7045. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Sep 28 22:57:28 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 7FB101A02DF; Sun, 28 Sep 2014 22:57:26 -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 TqALdSIbFukM; Sun, 28 Sep 2014 22:57:25 -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 6FE051A029E; Sun, 28 Sep 2014 22:57:25 -0700 (PDT) Received: from [192.168.1.2] (pool-71-103-148-36.lsanca.dsl-w.verizon.net [71.103.148.36]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id s8T5v2NC022054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 28 Sep 2014 22:57:11 -0700 (PDT) Message-ID: <5428F4AF.3090405@isi.edu> Date: Sun, 28 Sep 2014 22:57:03 -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: Fernando Gont , "Fred Baker (fred)" References: <67832B1175062E48926BF3CB27C49B2411C4DD6F@xmb-aln-x12.cisco.com> <67832B1175062E48926BF3CB27C49B2411C4DD81@xmb-aln-x12.cisco.com> <54231DD7.9040005@isi.edu> <5A984BFE-2A52-4B5F-BF1A-2825F0A146F2@cisco.com> <54242DAA.8000404@si6networks.com> <5424370B.8080900@isi.edu> <54243A4B.9010704@si6networks.com> <5424455A.7040501@isi.edu> <542465BB.7050404@si6networks.com> <542479EB.1010406@isi.edu> <5424A425.7060407@si6networks.com> In-Reply-To: <5424A425.7060407@si6networks.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/-yMW-bYf2wKD_9hxvJYog7GdARk Cc: "v6ops@ietf.org" , "'opsec@ietf.org'" 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, 29 Sep 2014 05:57:26 -0000 On 9/25/2014 4:24 PM, Fernando Gont wrote: ... > Nope. Please check Section 2.2 of our I-D, which says: > > The advice provided in this document is only meant to guide an > operator in configuring forwarding devices, and is *not* to be > interpreted as advice regarding default configuration settings for > network devices. ... > i.e., our recommendations shouldn't be used as "default configurations" > of any devices. So these are not defaults... ... > If you look closely at the I-D, it is essentially a "default allow", except that they are. Esp. two of the specific recommendations. Perhaps this most clearly highlights the reason I don't see the utility or purpose in this doc. Operational recommendations should be explained in the context of existing standards, and only where they deviate from them in a specific operational context. Joe From nobody Mon Sep 29 05:03:08 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 0AFC81A1A2C; Mon, 29 Sep 2014 05:03: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 4QYh7p_G4s1g; Mon, 29 Sep 2014 05:03:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3811F1A8745; Mon, 29 Sep 2014 05:03:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140929120303.5001.7140.idtracker@ietfa.amsl.com> Date: Mon, 29 Sep 2014 05:03:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Ud56qtLMeArefrOMtFuNvw3YxQA Cc: opsec mailing list , opsec chair , RFC Editor Subject: [OPSEC] Document Action: 'Using Only Link-Local Addressing Inside an IPv6 Network' to Informational RFC (draft-ietf-opsec-lla-only-11.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, 29 Sep 2014 12:03:06 -0000 The IESG has approved the following document: - 'Using Only Link-Local Addressing Inside an IPv6 Network' (draft-ietf-opsec-lla-only-11.txt) as Informational RFC This document is the product of the Operational Security Capabilities for IP Network Infrastructure Working Group. The IESG contact persons are Joel Jaeggli and Benoit Claise. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/ Technical Summary In an IPv6 network it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to help the decision process for a given network. Working Group Summary This document had a bumpy ride within the working group. There is rough consensus that the document provides valuable insight into advantages and disadvantages of the network Link-Local approach and that the content it includes is technically correct. The bumps for this document have been driven by the believe that running a network based upon this approach is in general a bad idea, and that even existence of this document provides perception it is an IETF supported approach. IETF last call reflects similar concerns, e.g. even the most vehement detractors agree that this works, the extent to which it is recomended is another matter. Document Quality The document is technically correct as seen by many reviews on the WG email list. The document does not discuss a new protocol or implementation of a new protocol. The document provides advantages and disadvantages of using IPv6 Link-Local Addresses within an IPv6 Network. It has had thorough review by WG reviewers, with discussions inside the WG email list Personnel Area Director: Joel Jaeggli Shepherd: Gunter Van de Velde From nobody Mon Sep 29 21:25:03 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 720501A013B for ; Mon, 29 Sep 2014 21:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.55 X-Spam-Level: X-Spam-Status: No, score=0.55 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, MANGLED_EMAIL=2.3, 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 TUG8JidP_M42 for ; Mon, 29 Sep 2014 21:24:57 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F2F1A0125 for ; Mon, 29 Sep 2014 21:24:57 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id la4so1877509vcb.27 for ; Mon, 29 Sep 2014 21:24:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mjCG+e6MqeBdoG5FKtGmqfe48ZxTZ6HWbmcnAM+Iipk=; b=SvbCJ93VZL9yC3IgbghtlRl0nVFqQR09P/Caqs4llNDOUUIpIzRP6Pgg+pH0YUldXZ XQyhifQVOmnpmwXge50jCsYZfxTXjrBYBRnxrS++QA1Ki5xx8GyysvYonyfOkkahB2RC K12FPsdQiQ24fy6JjvAzOm+ALPc/lTUtB3lZAHZp5hvkK3iUmooO9n3RBFUCEVanhiS+ PCnnYNJBwwgfdlY3+fdg1MfacyKlvnUbKwmH3ryX5j/yA4FZycV8w81DR9/GBVT5IdWN kv2gHXLoAGqhCsHFZFNLuAtWjUZZewCSpCE5atpiNe3Qt080vV7ZTEP6WSjkN0NwPQaZ eQWA== X-Received: by 10.52.245.66 with SMTP id xm2mr7877663vdc.36.1412051096722; Mon, 29 Sep 2014 21:24:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.173.2 with HTTP; Mon, 29 Sep 2014 21:24:36 -0700 (PDT) In-Reply-To: <53FCA7B1.9000006@si6networks.com> References: <20140826152114.26964.93347.idtracker@ietfa.amsl.com> <53FCA7B1.9000006@si6networks.com> From: Jen Linkova Date: Tue, 30 Sep 2014 06:24:36 +0200 Message-ID: To: Fernando Gont Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/YzvVXUoMuEthGURtHQPVkXbhVnk Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-02.txt 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, 30 Sep 2014 04:24:59 -0000 Hi Fernando, Some comments: 1) Section 2.2 " - Permit this IPv6 Extension Header or IPv6 Option type; - Ignore this IPv6 Extension Header or option type (forwarding packets that contain them)" What the difference? 2) Section 3.4 discussed the unknown EHs and it says: - impossible to determine specific security implications - filtering might break new protocols and makes the deployment harder and then you make a conclusion 'it's recommended to filter' - does not look too logical to me ;) 3) Section 4.3.6. Router Alert (Type=0x05): - you suggest to permit 'only in specific environments where support for RSVP or similar protocols is desired', while mentioning MLD earlier. IMHO you might want to mention multicast here as well. 4) NOTE: [RFC7112] specifies that non-fragmented IPv6 datagrams and IPv6 First-Fragments MUST contain the entire IPv6 header chain [RFC7112]. Therefore, intermediate systems can always enforce the filtering policies discussed in this document, or resort to simply discarding the offending packets when they fail to comply with the requirements in [RFC7112]. I'd not say ' intermediate systems can always enforce the policy'. To be always able to do it the system must be able to inspect the *whole* packet - it is not the case for various hardware. 5) 3.3.2. Routing Header for IPv6 (Protocol Number=43) You suggest to 'discard packets containing a RHT0 or RHT1. As required by [RFC7045], packets containing standardised and undeprecated Routing Headers should be permitted.'. Should it say 'permit all other types', otherwise you do not specify what to do with new/unknown types. 6)" 4.3.5.5. Advice Intermediate systems should not discard packets based on the presence of this option." The rest of the document says 'should permit' or 'should discard', so could you change it to 'should permit'? 7) Section 4 IPv6 Options As you already discussed HbH and Destination options - so why do you have a separate section? Unless I'm really missing smth here, we have only HbH and Destination ;) IMHO it would be more logical to have a section about 'IPv6 Options Headers and two sub-sections for HbH and Destination. BTW in many places in the document you say 'IPv6 Extension Headers and/or Ipv6 Options' which I read like 'there are such things as IPv6 EH and smth different called IPv6 Options'. IMHO it should be smth like 'Ipv6 extension headers (incl. individual option type)'. In general I'm a bit concern about the message of this document as it is quite long and I'm afraid that people might read it as 'filter 'em all, let God sort 'em out' which would make the current situation even worse. Is it what you trying to say? If not - would it help to have a short summary saying 'filter this, rate limit thas, permit everything else' or 'permit this, rate-limit that, block everything else' and then provide with all details you currently have in the document? On Tue, Aug 26, 2014 at 5:28 PM, Fernando Gont wrote: > Folks, > > We have posted a revision > (http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-02.txt) > of the aforementioned document, that addresses all the comments we have > received so far. > > Any further comments will be highly appreciated. > > Thanks! > > Best regards, > Fernando (and co-authors) > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-opsec-ipv6-eh-filtering-02.txt > Date: Tue, 26 Aug 2014 08:21:14 -0700 > From: internet-drafts@ietf.org > To: Will(Shucheng) Liu , Shucheng LIU (Will) > , Fernando Gont , Ron > Bonica , Fernando Gont , > Ronald P. Bonica > > > A new version of I-D, draft-gont-opsec-ipv6-eh-filtering-02.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-opsec-ipv6-eh-filtering > Revision: 02 > Title: Recommendations on Filtering of IPv6 Packets Containing IPv6 > Extension Headers > Document date: 2014-08-26 > Group: Individual Submission > Pages: 30 > URL: > http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-02.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-eh-filtering/ > Htmlized: > http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-eh-filtering-02 > > Abstract: > This document provides advice on the filtering of IPv6 packets based > on the IPv6 Extension Headers and the IPv6 options they contain. > Additionally, it discusses the operational and interoperability > implications of discarding packets based on the IPv6 Extension > Headers and IPv6 options they contain. > > > > > > 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 > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec -- SY, Jen Linkova aka Furry From nobody Tue Sep 30 01:51: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 219F01A02EA for ; Tue, 30 Sep 2014 01:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_EMAIL=2.3, SPF_HELO_PASS=-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 lGlMDmgpfubh for ; Tue, 30 Sep 2014 01:51:10 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) (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 BE4D81A02E6 for ; Tue, 30 Sep 2014 01:51:09 -0700 (PDT) Received: from [186.134.2.155] (helo=[192.168.1.6]) by web01.jbserver.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1XYt9C-0007si-QI; Tue, 30 Sep 2014 10:51:03 +0200 Message-ID: <542A5770.7080200@si6networks.com> Date: Tue, 30 Sep 2014 04:10:40 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Jen Linkova References: <20140826152114.26964.93347.idtracker@ietfa.amsl.com> <53FCA7B1.9000006@si6networks.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/UksPG9xiHv0FCDnAUyVwiJvSPHA Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ipv6-eh-filtering-02.txt 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, 30 Sep 2014 08:51:12 -0000 Hi, Jen, Thanks so much for your feedback! Please find my comments in-line... On 09/30/2014 01:24 AM, Jen Linkova wrote: > Hi Fernando, > > Some comments: > > 1) Section 2.2 > " - Permit this IPv6 Extension Header or IPv6 Option type; > - Ignore this IPv6 Extension Header or option type (forwarding > packets that contain them)" > > What the difference? With "permit", you honor the IP option (act on it) and forward the packet. With "ignore", you do not act on the option, but still forward the packet. Please let us know if you think this should be made more clear in the I-D. > 2) Section 3.4 discussed the unknown EHs and it says: > - impossible to determine specific security implications > - filtering might break new protocols and makes the deployment harder > > and then you make a conclusion 'it's recommended to filter' - does not > look too logical to me ;) The thing here is that a standardized IPv6 EH is not "unknown" anymore. [I've suppressed those comments that we will apply as suggested] > 7) Section 4 IPv6 Options > > As you already discussed HbH and Destination options - so why do you > have a separate section? Unless I'm really missing smth here, we have > only HbH and Destination ;) IMHO it would be more logical to have a > section about 'IPv6 Options Headers and two sub-sections for HbH and > Destination. The reason was to discuss filtering on both per-EH-type (Section 3) and per-option-type (Section 4) granularities. How renaming the section (somehow) make things more clear? > In general I'm a bit concern about the message of this document as it > is quite long and I'm afraid that people might read it as 'filter 'em > all, let God sort 'em out' which would make the current situation even > worse. Is it what you trying to say? Certainly not -- actually, kind of quite the opposite. :-) > If not - would it help to have a > short summary saying 'filter this, rate limit thas, permit everything > else' or 'permit this, rate-limit that, block everything else' and > then provide with all details you currently have in the document? Yes. This is what we did in RFC7126. We should definitely do it for this document, too. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492