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

Brian E Carpenter <> Fri, 19 June 2015 20:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7D7181A1A07 for <>; Fri, 19 Jun 2015 13:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZZFBSPVt1rLX for <>; Fri, 19 Jun 2015 13:18:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 266711B29B9 for <>; Fri, 19 Jun 2015 13:15:03 -0700 (PDT)
Received: by pdbki1 with SMTP id ki1so97396889pdb.1 for <>; Fri, 19 Jun 2015 13:15:02 -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:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=HuLybM1ITB6TiZsKzYQzG0XIsO/BlJdnOoW4Kd+T+Ig=; b=mlC7DwlA8YipsWZij0SnaUnsNsDFfzYEVQ6OVdK6QSTfxc7R8gyvK9nEWzTM1Oo6dB jqF2XM74vBRFVlv4jdGtGIvKKJMibgyWguv3Ae7yITqim4EdzKzDQhMkm5jULPRHeNLF SN+aYteYWpnKEaNE2d5HTpFC1uu4hJXllfLgiRznV73n8/2N82pELazp0P8uKD9Caj4G PS/27YBpdu3X4DopSFvWmQkpefMCYi9T9ZXIqHR2FOnmE2RAKR2tKw2+0Ue7yxkM7CZd QnLsuZ7DHdx25sTfT5fEL6TwfRLe/m4P+X89gshvRTb2fkWcLDQATlE8AwN+27qfUS94 RHqg==
X-Received: by with SMTP id cp7mr35378171pad.36.1434744902724; Fri, 19 Jun 2015 13:15:02 -0700 (PDT)
Received: from ?IPv6:2406:e007:618e:1:28cc:dc4c:9703:6781? ([2406:e007:618e:1:28cc:dc4c:9703:6781]) by with ESMTPSA id mi1sm12088755pdb.17.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2015 13:15:01 -0700 (PDT)
Message-ID: <>
Date: Sat, 20 Jun 2015 08:15:08 +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.7.0
MIME-Version: 1.0
To: Mark ZZZ Smith <>, Enno Rey <>, Ole Troan <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>, "" <>
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: Fri, 19 Jun 2015 20:18:31 -0000

On 19/06/2015 21:13, Mark ZZZ Smith wrote:
>       From: Enno Rey <>
>  To: Ole Troan <> 
> Cc:; 
>  Sent: Friday, 19 June 2015, 18:34
>  Subject: Re: [v6ops] [ipv6-wg] Extension Headers / Impact on Security Devices
> Hi,
> On Fri, Jun 19, 2015 at 09:56:20AM +0200, Ole Troan wrote:
>>>>>> Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement).
>>>>> It would certainly make *me* happier???$,1s&
>>>> done.
>>>> RFC7112.
>>> As I wrote in another mail,
>>>> It may be relevant to ask for RFC 7112 support next time we're doing
>>>> an equipment RFQ (in a few years).
>>> ...
>>>> 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.
>>> And until such support is available, we have to deal with the current
>>> mess. Which may imply more filtering than some people would like.
>> I don???t think that follows.
> I would second the observation that this (subsequent action) actually happens.
> Not least because many consider it a reasonable approach not to process and/or to drop something that induces complexity & insecurity and which at the same time is not needed by any service or application (read: all EHs except ESP and, maybe in some corner cases, AH+FH).
> / I think you're only expressing the view of many security engineers, not the many network engineers or the many more users of networks. At an ISP, if you block traffic your customer wants send, all you get is angry customers. They're paying you to deliver any and all of their packets as well as possible, with as minimum restrictions as possible, ideally none, rather than the opposite. This is why I don't think you'll ever get consensus on deprecating EHs, because I think you're only coming the position of trying to solve problem (3) I described in my last email.

I don't think that's what he was saying. I think he was saying "enforce RFC 7112."
Discarding packets whose headers exceed the first fragment strikes me as very
reasonable, even before host stacks are updated to enforce RFC 7112 at the source.

What isn't reasonable is to say "laugh at RFC 7045". Anybody who purports to sell
IPv6 firewalls needs to support RFC 7045 in their next release.

The next order of business in the IETF (6man, not here) is to decide
whether we go further in fixing the standard, which I think you and Fred
are both advocating.


> / I'd also observe that deprecating EHs, other than ESP, AH+FH, TCP and UDP, would also prevent them from being used behind the ESP EH - where you won't be able to see what is in them, so you won't be able to care what is in them. You'll also be preventing people from other transport layer protocols, such as SCTP and DCCP, that are feasible to deploy over the IPv6 Internet that couldn't be over the IPv4 network because of IPv4 NAT and other middle boxes.
> thanks
> Enno
>> cheers,
>> Ole
> _______________________________________________
> v6ops mailing list