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

Brian E Carpenter <> Sat, 24 November 2018 20:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA09E130F59; Sat, 24 Nov 2018 12:18:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cvXLag-L2Ptq; Sat, 24 Nov 2018 12:17:59 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::644]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A53C0130F56; Sat, 24 Nov 2018 12:17:59 -0800 (PST)
Received: by with SMTP id x21-v6so12014114pln.9; Sat, 24 Nov 2018 12:17:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JJwa+28a2PNLnZCXGOziq+zhOj0z/iTpBuDztU9ZCy0=; b=ltdBCTLjLN4Eyb2ks9Cbz0xG6/X/4nDDNX/ym7WaoZ/90Z2fjgwBL8ekhX0SQh+lCq JxnF3uzF7rarOixQVKh7Rt7NeibR7XDxKKAyx+K7V4rsMxONFzwcQK3EtzGx1ZGi+x0R LL/tD6CHsSFnR6v0u9c1iDS9z+iR26XPMSrxcLTH8MFzdUJy4fxKWoGxci6GkOr9s7tV 4PkLIOth857GzCflZrNS3P0i+oQo0uRXuyaZzNgg5SSctgzR51IsJYvA3cb0c0wEb5Ux irb2v6vOcU/+6WEQ78xl68tQe/hlZsOZ8sDbxqc7YEyQCRj0RgO6yaTIrkMoAJMBPQ5Q V3Mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JJwa+28a2PNLnZCXGOziq+zhOj0z/iTpBuDztU9ZCy0=; b=DYmbcJiwzgbjEeZGJu8QBMwS1dsC5bYmDXxikJQy+gVxEYj7knCd2V9tJhLknT5BPz gKLSWtoq4qIyokNWrQBquT7kI37ttx4Q7joAvhmJYhppyDzvDi5WqAEnLZ7EMhuKoBij ly20RLpOG7WYuEZVAHymcyVYH2CLUVl+ffDwUlAgyqfppNSNNIL7NbVbFKUxjPfLBgwL v8aIGGaAoU4Z2fWaLUnA89zGga/gRBg/ODsYz9PxWRX2QjsqR3vUZC9OlnvZ8qBWs9sX 9p7Mb28qZI8kR+wohQqgnE4luCFkebywkkNR021UVRm+OfZkJMEe1BMPCWUH278LY3Tj jofg==
X-Gm-Message-State: AA+aEWZJrLs+uCqwWcpkh9s2Xq2S5N+w5hP0c8nnir648Bb/M8X1PO7Y ckkxHsln3aEmaO1glOynL6hDyYB0
X-Google-Smtp-Source: AFSGD/UzrhyU43xW4dyiR8WXLRxYlzotUwXNShisjmw+rX8nGT5F385R5Z3TeoIyLPlANzgN15sPfA==
X-Received: by 2002:a17:902:7587:: with SMTP id j7mr21202499pll.191.1543090678691; Sat, 24 Nov 2018 12:17:58 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id s79sm197937pgs.50.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Nov 2018 12:17:57 -0800 (PST)
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" <>, Nick Hilliard <>
Cc: OPSEC <>, IETF <>
References: <> <> <> <> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Sun, 25 Nov 2018 09:17:53 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 24 Nov 2018 20:18:02 -0000

On 2018-11-25 05:14, C. M. Heard wrote:
> On Sat, Nov 24, 2018 at 7:37 AM Nick Hilliard <> wrote:
>> 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.
> It's not clear to me what that has to do with the specific comments
> that I made (and that you elided).  I would understand if I had brought
> up handling of, say, HbH options rather than default drop policies for
> unknown (and experimental) header types.  Perhaps you could clarify.

As background, the *end* of the discussion of HbH in the draft says:

   Finally, when
   packets containing a HBH Options EH are processed in the slow-path,
   and the underlying platform does not have any mitigation options
   available for attacks based on these packets, we recommend that such
   platforms discard packets containing IPv6 HBH Options EHs.

I'm not sure what else a firewall recommendation could say (as a default
configuration, because the whole document is really about defaults). But
it's worth reading the preceding text at
to get the context for that "Finally".

>> 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.
> Agreed, that's the most useful part of the document. But it does in
> addition give specific advice, and that advice should be reasonable
> as a default.
> My primary objection is to the advice that says discard unknown
> EHs and upper-layer protocols by default.  That advice needs to
> be more nuanced -- as is the advice for unknown option types
> given in Sec. 4.4.5,   I see no reason why these cases should
> get different advice.

Let's see. We have:

3.5.2.  Specification

   The processing of unknown IPv6 EHs is specified in [RFC8200] and

In fact RFC8200 doesn't discuss EH processing by intermediate nodes.
RFC7045 does (see ).
Again, read the whole section for context, but the key sentence is:

   Forwarding nodes MUST be configurable to allow packets containing
   unrecognised extension headers, but the default configuration MAY
   drop such packets.

That was a careful compromise between the ideal (a transparent Internet)
and reality (an Internet with security-aware operators). The current draft
changes this MAY into a lower-case should:

3.5.5.  Advice

   Intermediate systems should discard packets containing unknown IPv6

I'm with Mike Heard. This is an informational document attempting
to override a Proposed Standard. That's not OK.

That doesn't mean Nick Hilliard is wrong. Operators make their own
decisions, so I think that is what the draft should say. Something like:

3.5.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing unknown IPv6 EHs.

And at the same time, delete the 2nd and 3rd sentences of this:

3.5.3.  Specific Security Implications

   For obvious reasons, it is impossible to determine specific security
   implications of unknown IPv6 EHs.  However, from security standpoint,
   a device should discard IPv6 extension headers for which the security
   implications cannot be determined.  We note that this policy is
   allowed by [RFC7045].

I don't expect these changes to have much impact in the real world,


> Mike Heard