Re: Last Call: <draft-ietf-opsec-ipv6-eh-filtering-06.txt> (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC

Nick Hilliard <nick@foobar.org> Sat, 24 November 2018 15:37 UTC

Return-Path: <nick@foobar.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B527128B14; Sat, 24 Nov 2018 07:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 EZS-dfqFYm-X; Sat, 24 Nov 2018 07:37:04 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68731286E7; Sat, 24 Nov 2018 07:37:03 -0800 (PST)
X-Envelope-To: ietf@ietf.org
Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id wAOFaxRv059593 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Nov 2018 15:36:59 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local
Subject: Re: Last Call: <draft-ietf-opsec-ipv6-eh-filtering-06.txt> (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC
To: "C. M. Heard" <heard@pobox.com>
Cc: IETF <ietf@ietf.org>, OPSEC <opsec@ietf.org>
References: <CACL_3VExxwN6z-WHbp3dcdLNV1JMVf=sgMVzh-k0shNJFeADbQ@mail.gmail.com> <BLUPR0501MB2051A8FFB1DAFDCA9873B9E6AE700@BLUPR0501MB2051.namprd05.prod.outlook.com> <CACL_3VFSHqU-D+NJu=k2-p4tbjZukT7i7WEoX+5kdUtdHB4Rjw@mail.gmail.com> <CACL_3VGk0CsHObEgSwLdCp8agOWrjccB94-aynEz3Bv0w+EU+w@mail.gmail.com>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <475fe28a-aafe-d3b0-e665-fe97dd1439b8@foobar.org>
Date: Sat, 24 Nov 2018 15:36:58 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.5
MIME-Version: 1.0
In-Reply-To: <CACL_3VGk0CsHObEgSwLdCp8agOWrjccB94-aynEz3Bv0w+EU+w@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/4LBBFxnQtHLSVWg7gpnffZnTFFg>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Nov 2018 15:37:07 -0000

C. M. Heard wrote on 23/11/2018 16:20:
> while promoting a **/_default deny_/** policy with respect to unknown
> extension headers, experimental extension headers, and experimental 
> options. If every transit router followed that advice, it would be
> impossible to transmit packets containing these things across the open
> Internet. It is especially egregious to dispense that advice for
> unknown extension headers, since that would severely impede deployment
> of any new extension headers OR any new transport protocols in the open
> Internet (as the document itself notes, unknown extension headers are
> indistinguishable from unknown upper-layer protocol headers). This part
> of the document's advice does nothing to improve the situation reported
> in RFC 7872; if anything, it makes the situation worse. It certainly
> will not make the Internet work better.

transit operators would generally take the view that any data-plane 
packet which needs to be put through a slow path will be rate limited up 
to 100% loss.  We can argue endlessly at the IETF about the pros and 
cons of this from a protocol development and management point of view 
but at the end of the day, transit operators have networks to run, and 
there is a jarring disparity between data-plane forwarding speed and 
control-plane processing capacity.  If you expect one to bleed into the 
other, something needs to give.  This is often going to be 
silicon-specific; what is slow-pathed on one platform may not be 
slow-pathed on another, so generalised statements are difficult in this 
situation.

Transit operators are going to make their own decisions about what to do 
about packet filtering, and take any specific recommendation in an ID 
like this with a grain of salt.  In that respect, this document needs to 
be seen as a store of information to help people make informed decisions 
about what to do rather than being a prescriptive list.

Nick