Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices Thu, 18 June 2015 06:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9BB4D1B3054 for <>; Wed, 17 Jun 2015 23:54:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 19K5mc4FGJb0 for <>; Wed, 17 Jun 2015 23:53:59 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id E653E1B3053 for <>; Wed, 17 Jun 2015 23:53:58 -0700 (PDT)
Received: (qmail 77095 invoked from network); 18 Jun 2015 06:53:56 -0000
Received: from (HELO localhost) ( by with SMTP; 18 Jun 2015 06:53:56 -0000
Date: Thu, 18 Jun 2015 08:53:56 +0200 (CEST)
Message-Id: <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [v6ops] [ipv6-wg] 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: Thu, 18 Jun 2015 06:54:01 -0000

> > Yes, we're aware of RFC7112. It's just: no OS we know and no devices we're aware of (feel free to provide pointers) implement RFC 7112 as of today. 
> No, it's too new. But I suggest that it gives you license to drop packets
> with fragmented header chains, and tell anyone who complains that they
> don't conform to the IPv6 standard.

It may be relevant to ask for RFC 7112 support next time we're doing
an equipment RFQ (in a few years).

> > but many attack tools implement the techniques mentioned above. Which is why quite some operators (in particular, but not only) from enterprise and managed service provider/cloud space drop all EHs except, maybe, AH+ESP.
> Whereas dropping *all* EHs breaks the IPv6 standard.

Obviously. But until RFC 7112 support is available, I believe we will
see a significant amount of breakage for IPv6 extension headers - and
header chains will be limited to significantly less than 1280 bytes.

> EHs as an extension mechanism are *not* innovation. They've been in the design
> for 20 years. I'm actually with Fred on this: it's time for the hardware
> designers to step up. With RFC 7112, we've told them that the maximum packet
> size they need to parse is 1280 (after removing tunneling overhead).

IPv6 extension header processing is sufficiently complex that I'm not
at all sure that "time for the hardware designers to step up" will be
enough. My prediction is that we'll see security alerts from hardware
manufacturers for many years to come, due to the complexity.

Steinar Haug, AS 2116