Re: [v6ops] Extension Headers / Impact on Security Devices

Brian E Carpenter <> Fri, 15 May 2015 20:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 442B01A1BFA for <>; Fri, 15 May 2015 13:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rk1VE7t0BK2M for <>; Fri, 15 May 2015 13:36:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD3DE1A0270 for <>; Fri, 15 May 2015 13:36:38 -0700 (PDT)
Received: by pabru16 with SMTP id ru16so27251018pab.1 for <>; Fri, 15 May 2015 13:36:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CCRegco97fo2gcqQMQBEYNI6A2C9PV89wxRi6vSh4Ro=; b=vdgS4VsMi3GUNqLRBMnNDhx6InvBq3uFGxhbztQL8WOoCiIGf8d7jHy4bQ11BXb9js H9KNZUXQrnd/rvsoBr1hbI8ErdpFvYjneW60ual3onBWpqzyO+wtr8ZqrBwrDFUMN2lP EHGvWY1WZj3IV+M4uTUqiltAmErjpNV81Y3lk4ZqU13xgXDSy2+J0m7MghKE/mDYRq9C Yy1vWqjh0YPAfIy8+xh2EvIDFDzCBNJUx/0qmbLvmu7Cq99i92G1L8xVVB/Fz2EizBkw Wj84Shfso52Z2JtcRn6pnjxUrs0RyBK3R5eqHU8GfP8A3406Irv2Jgcb512m0kT7R1Va 19fg==
X-Received: by with SMTP id pp4mr21754355pbb.134.1431722198325; Fri, 15 May 2015 13:36:38 -0700 (PDT)
Received: from ?IPv6:2406:e007:6f4c:1:28cc:dc4c:9703:6781? ([2406:e007:6f4c:1:28cc:dc4c:9703:6781]) by with ESMTPSA id zt9sm2735137pac.9.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 May 2015 13:36:37 -0700 (PDT)
Message-ID: <>
Date: Sat, 16 May 2015 08:36:46 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Enno Rey <>,
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 May 2015 20:36:40 -0000

On 15/05/2015 23:37, Enno Rey wrote:

> As for the topic itself I'd like to summarize our position as follows:
> - it has not happened in the past 17 yrs (since publication of RFC2460) that compelling, Internet-scale use cases of extension headers have been brought up.

I object to that logic. Firstly, the timescale is misleading: IPv6 deployment has
been so painfully slow that you really can't look at the 17 year span for
this argument; it's only within the last 5 years or so that the words "compelling"
and "Internet-scale" could be relevant. That's why the obvious issues in RFC 2460
were only fixed in 2013, by the way (RFC 7045). We haven't even had time for those
fixes to reach deployment.

Secondly, "compelling" is entirely a matter of judgement. There's no possibility
of a compelling case for something that is undeployable, and it's well known
that because of faulty handling of new extension headers by middleboxes, no
new extension headers are deployable today.

> - we're hence quite sceptical as for the "we might see cool use cases in 15-20 yrs" position someone expressed at the mic.

Of course you won't, until middleboxes stop breaking them. Extensibility is for the
future and unpredictable, by definition.

> - from a security perspective they turn out to be a nightmare for (a number of) current security architectures and controls. it is hence understandable (and we actually advise to do so) that they are blocked at the _border_ of networks that have not yet managed to identify a compelling use case.

That is automatically a self-fulfilling prophecy. The new rules in RFC 7045 were
carefully constructed to offer a way out of this. I hope your advice is to follow
those rules and to insist on products that allow this (correct defaults, for example).

> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to their number, order, options, fragmentable vs. unfragmentable part etc.) we do not expect that type of security issues to disappear soon (the main reason why we did not continue the IDPS research was that the involved student eventually delivered his thesis. one can probably find much more issues provided time & resources. following LANGSEC it might be impossible to "fix" all of them either).

I assume you are following documents like draft-ietf-6man-deprecate-atomfrag-generation,
RFC 7112, RFC 6946, etc. It isn't as if the IETF is unaware of the issues.

> Adding more parsing cycles & intelligence (read: silicon) is not an option, at least not for sth that doesn't have a use case.

Well, Moore's law is stll with us, so I think that is plain wrong as products evolve,
which is exactly why we should update the standards accordingly. Of course that applies
to vendors, not operators.

> - the results of this (blocking) approach have been observed and documented by Jen & Fernando and others (Tim Chown).
> - now that "this vicious circle" has gained sufficient ground it will be evfixesen less incentivized to develop a compelling use case. which is why we do not expect to see one in the future.

It's possible, but that doesn't mean that the IETF should give up on extensibility.
We should continue to mitigate the problems, which is what we've been doing for
several years, since they became apparent.

Nobody, I think, is arguing that the extensibility design in IPv6 is middlebox-friendly.
But that's history and we have to deal with it.