Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03
Ron Bonica <rbonica@juniper.net> Thu, 05 October 2017 18:04 UTC
Return-Path: <rbonica@juniper.net>
X-Original-To: opsec@ietfa.amsl.com
Delivered-To: opsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A90134310 for <opsec@ietfa.amsl.com>; Thu, 5 Oct 2017 11:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.031
X-Spam-Level:
X-Spam-Status: No, score=-0.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 IeNf7hA1-Mia for <opsec@ietfa.amsl.com>; Thu, 5 Oct 2017 11:04:25 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0122.outbound.protection.outlook.com [104.47.41.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBF8134477 for <opsec@ietf.org>; Thu, 5 Oct 2017 11:04:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sT576XpfPWODYPvjo4lVfY+jNDpKNY+Re1TWNknfJ4w=; b=hNJXUzWWCbHSVPNmp5aC2ALF/d7Q6xwLAvtDneSGosLDqh2XTt8ECq096VRAZgYjLcsB8a5FBN6uWghztNcsuQDYxx/S7lnZ9rfp5jmxUuMh8ond7nHIYhwEdEq946TiJ9S5qOt4Fp6g9MV2U6a1yHgphgNAgKHnI9sjKOmiCv0=
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com (10.164.23.21) by BLUPR0501MB2050.namprd05.prod.outlook.com (10.164.23.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Thu, 5 Oct 2017 18:04:19 +0000
Received: from BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) by BLUPR0501MB2051.namprd05.prod.outlook.com ([10.164.23.21]) with mapi id 15.20.0077.018; Thu, 5 Oct 2017 18:04:19 +0000
From: Ron Bonica <rbonica@juniper.net>
To: "C. M. Heard" <heard@pobox.com>, OPSEC <opsec@ietf.org>, Joe Touch <touch@strayalpha.com>, Bob Hinden <bob.hinden@gmail.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Thread-Topic: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03
Thread-Index: AQHTPYcyy6w36+fdfkOchQ9lkNpRO6LVbANA
Date: Thu, 05 Oct 2017 18:04:19 +0000
Message-ID: <BLUPR0501MB2051A8FFB1DAFDCA9873B9E6AE700@BLUPR0501MB2051.namprd05.prod.outlook.com>
References: <CACL_3VExxwN6z-WHbp3dcdLNV1JMVf=sgMVzh-k0shNJFeADbQ@mail.gmail.com>
In-Reply-To: <CACL_3VExxwN6z-WHbp3dcdLNV1JMVf=sgMVzh-k0shNJFeADbQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rbonica@juniper.net;
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BLUPR0501MB2050; 6:/UefqBUNz5xf/s+FJD/4APZpSChp0woh54U+CNOySGuJlC7rL+kZHsYyNNSnDwjScdNE//aqeVEYZ9gTxpIEjBuwRHT1JOKaabbd/KOPZYeqTqwqIgWpgd1LakaP5vPkGPeh4D126ugsdnOL9c8FNhOYVxAQ/0EqPjBlubaIajp2u8zDGlQzFXwsIJAH9KB+ujnrLP7XeOrp/yDWAuqHDWy5pNaHPiorQved19/GIvr+96w9kGL5Djgk7AG9pJ91fEb/ZkMeIgIYu+LVngBcWyw8saIseWPGKTyRrV+2kekQU+bXBfTBL5lhvm8xZRTKdvL5540QKlgChs3Udjl/DQ==; 5:ZQoKJwoYBZ27EDQFgGVIITohzwdL910ig4qnBRG9bVcscY6VEw0iyCBUgNuPJl1espGo0FYTZeBrM+HH+Ru7g4C+Jb2gOlA/pe+Uy8UW8hR5IQS+wA0AEcaivVkSdDRXhKKkqJXQZ9bRejDXMfvouw==; 24:XsK8jp0bNq9+OdIzAIzMVedvNROWe2uQKiiT1R1yA48zaCZNZM4q+kcX5j9Zo0w4i2EQNYPrZsCblc8YwgCYP+gqxFzYNDiniQ71vdLcnzA=; 7:ngYR7jZtoXTMN93G6MVkDMP1bSRmum2/FEIV0Yfk8XD/Bajal8MbE7UuACv4t83lQk5Ce16SmaImsEMC8Zlr67dGGVWRnrQFABMBy5OyEMsyKpm823rHfQc6+TiRNYrqgUVqy/k6L08zjj7dVi9x2kNH8J1NpDlrzjhDzMsmBNFVVKVJSqsOzbMt/AigR2qdImVPliVLuptTE4UfoDouGmkb0Ea9oP1pmpFu/vyZtYo=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 3c79425b-6860-46ae-f9a2-08d50c1b8022
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR0501MB2050;
x-ms-traffictypediagnostic: BLUPR0501MB2050:
x-exchange-antispam-report-test: UriScan:(10436049006162)(21748063052155);
x-microsoft-antispam-prvs: <BLUPR0501MB2050C63875A5DB7EF2EC2F33AE700@BLUPR0501MB2050.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR0501MB2050; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR0501MB2050;
x-forefront-prvs: 04519BA941
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(24454002)(199003)(51444003)(377454003)(189002)(9686003)(66066001)(99286003)(8676002)(86362001)(230783001)(229853002)(3280700002)(2950100002)(6436002)(2900100001)(50986999)(5660300001)(3660700001)(2906002)(106356001)(105586002)(77096006)(6506006)(7696004)(33656002)(189998001)(76176999)(53946003)(6246003)(14454004)(25786009)(236005)(966005)(101416001)(39060400002)(81166006)(97736004)(54356999)(74316002)(55016002)(6306002)(7736002)(6116002)(53546010)(19609705001)(81156014)(110136005)(316002)(606006)(54896002)(8936002)(102836003)(53936002)(8656003)(68736007)(3846002)(478600001)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2050; H:BLUPR0501MB2051.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR0501MB2051A8FFB1DAFDCA9873B9E6AE700BLUPR0501MB2051_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2017 18:04:19.5281 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2050
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/qAm_8x3OuMLPQPcbU-mTjAqYXjE>
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Oct 2017 18:04:33 -0000
Mike, I think that you just struck the note that Fernando and I missed. Transit routers filter extension headers for one of the following reasons: - To protect themselves (as in RFC 6192) - To protect downstream devices Therefore, the document should contain two clearly marked sections, one regarding EH filtering policies that protect the transit router and one regarding EH filtering policies that protect downstream devices. The first section can: - Be very short (2 pages max) - Be guided largely by RFC 8200 - Speak with some degree of authority (while still INFORMATIONAL) The second section should begin with a discussion of the relationship between the transit router and the downstream devices. Let’s assume that the transit router belongs to an ISP, while downstream devices fall into the following three classes: 1) Belong to the ISP 2) Belong to parties who want to be protected by the ISP (e.g., its customers) 3) Belong to other parties Therefore, the transit router MAY discard packets that pose a threat to the first two classes of downstream device, but MUST NOT discard packets that are required by the third class of downstream device. From this point, we formulate a policy that *might* satisfy the above mentioned requirement. We mark this policy with the following caveats: - It is a best guess - If the policy is too permissive, downstream devices belonging to the ISP and those who it protects will not receive all of the protection possible - If the policy is too restrictive, downstream devices belonging to other parties will experience collateral damage - One size doesn’t fit all If we were to rework the document into this shape, would it address your concerns. Ron From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of C. M. Heard Sent: Wednesday, October 4, 2017 11:08 PM To: OPSEC <opsec@ietf.org> Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filtering-03 On Thu, 5 Oct 2017 11:10:06 +1300, Brian E Carpenter wrote: > On 05/10/2017 02:12, Joe Touch wrote: > >> On 9/29/2017 1:12 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote: >>> >>> This is to open a two week WGLC >>> for https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dopsec-2Dipv6-2Deh-2Dfiltering-2D03&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=pDMOABefbu8JHcDH3rcHvzOABmSLo8X0KGbiPvLqnpA&s=M7xHnDuuJxhA21iLVXO_-AZjAhvXwgaN__niQRcoBwc&e=>. >>> >> >> I do not agree with the claims of this document. It "informationally" >> advises against support for key IPv6 capabilities and undermines the >> extensibility of IPv6 by making recommendations about discarding >> currently unassigned codepoints. > > Here's the problem, Joe. It's a fact of life that many firewalls > discard a lot of stuff that they shouldn't - that's why we wrote > RFC 7045 - but in the real world, operators blunder around based > on folklore and vendors' defaults. We can't change any of that, but > we can try to issue sensible advice that, overall, will limit the > resulting breakage. IMHO this document, positioned correctly as > Informational, will do that: on balance, it makes the world a better > place. I am afraid that I do not agree that the document, in its present form, will do that. It says: The filtering policy typically depends on where in the network such policy is enforced: when the policy is enforced in a transit network, the policy typically follows a "black-list" approach, where only packets with clear negative implications are dropped. On the other hand, when the policy is enforced closer to the destination systems, the policy typically follows a "white-list" approach, where only traffic that is expected to be received is allowed. The advice in this document is aimed only at transit routers that may need to enforce a filtering policy based on the EHs and IPv6 options a packet may contain, following a "black-list" approach, and hence is likely to be much more permissive that a filtering policy to be employed e.g. at the edge of an enterprise network. The advice in this document is meant to improve the current situation of the dropping of packets with IPv6 EHs in the Internet [RFC7872<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7872&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-AWF2EfpHcAwrDThKP8&m=pDMOABefbu8JHcDH3rcHvzOABmSLo8X0KGbiPvLqnpA&s=KqV5UiI6Ie51NtocuTw9zMCtHX8aMheboGCPVCzdepA&e=>]. while at the same time promoting a **default deny** policy with respect to unrecognized options and unrecognized extension headers. That is antithetical to the mission of a **transit router**, which is to get packets transparently from point A to point B. It is especially egregious to dispense this advice for unrecognized extension headers, since they are indistinguishable from unrecognized transport protocols. If these things are blocked by **transit routers** it becomes impossible to deploy any new options or transport protocols. But we already know that, don't we? If we want to give constructive advice that really will make the world a better place, we should: 1.) Advise operators of **transit routers** to be transparent to everything other than the Hop-by-Hop extensions header, and provide detailed advice on what to do (based on the updates in RFC 8200) about Hop-by-Hop options. The default should be IGNORE unless there is an option you need to process. 2.) Reserve all the detailed filtering advicee for operators of firewalls, enterprise routers, and other systems whose mission it is to protect the end systems behind them (or to prevent misbehavior by said end systems). A default deny for unrecognized stuff is not unreasonable for such systems. 3.) Remind implementors of the following requirement from RFC 7045: Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but the default configuration MAY drop such packets. and add similar advice for options. Thanks and regards, Mike Heard
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Brian E Carpenter
- [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-filteri… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Joe Touch
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Ron Bonica
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Bob Hinden
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Brian E Carpenter
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… C. M. Heard
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Tim Chown
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Ron Bonica
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… Ron Bonica
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… Joe Touch
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… Brian E Carpenter
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… C. M. Heard
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… joel jaeggli
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… Ron Bonica
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… joel jaeggli
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Fernando Gont
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… Fernando Gont
- Re: [OPSEC] WGLC for draft-ietf-opsec-ipv6-eh-fil… Van De Velde, Gunter (Nokia - BE/Antwerp)
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Brian E Carpenter
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Fernando Gont
- Re: [OPSEC] [v6ops] WGLC for draft-ietf-opsec-ipv… Brian E Carpenter
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Nick Hilliard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Brian E Carpenter
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Nick Hilliard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Nick Hilliard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Fernando Gont
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Bob Hinden
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Nick Hilliard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Fernando Gont
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Ole Troan
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Nick Hilliard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… Fernando Gont
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard
- Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-… C. M. Heard