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

Mark ZZZ Smith <> Tue, 16 June 2015 05:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EF7F11B39AA for <>; Mon, 15 Jun 2015 22:12:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, GB_I_INVITATION=-2, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, HK_RANDOM_REPLYTO=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iGUrRCta83tt for <>; Mon, 15 Jun 2015 22:12:00 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1535B1B39AC for <>; Mon, 15 Jun 2015 22:11:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s2048; t=1434431519; bh=DFdMypUQlV69wL0YscCq5EE+IPNdeodiMS2h9cw4FuU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ZFglWcVRyb+8bTg32hKN2U3krCQinj8L2EU8Jgz5yQJnMmJ3uHuRSvPpgxnsHvcdURbevuiOCJW+17fEyBYkDUDpdMt4CZfJ6jcqIbPCqQ8deWnGD57QK9DytyISEud7PCaCoTlWGhAU7Map66VvikhiSL2+JbywOh6fOCO1fIGz9YvhNsvVUzQaI7f9JFITamKTZrn4nRf1ZH/fMUszVeso1vrHUvTfuZdDaQhlWxX7BJQGF5jjq/P/RxRlKcdfRr9WZB04p3i8P0R9+3h/qWLMwjt+UBZQ84zMmZrk7adv+Vk7eWOeIAgTJzwIAVWvNUlGcdC4zUagPPMhRfaHeg==
Received: from [] by with NNFMP; 16 Jun 2015 05:11:59 -0000
Received: from [] by with NNFMP; 16 Jun 2015 05:11:59 -0000
Received: from [] by with NNFMP; 16 Jun 2015 05:11:59 -0000
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: _9SZmhYVM1kYNycLzpmZK0E4yc6Y24XvXdOFGLF_jSBkX7MDJRy5_uw7M0WixMY tEyRGRESqa1qSV996jsSYXhZJXwVLkW4sJjwdiW3us1EEo1j51dPhdJl2czjjEgZXEgvkb9bW7Vw IqrqOfBaaRM04xycb9EbT701MhI1OLb8NcQkX.hGPloauIAOtQEs4tzyKtnOSNySfcLPrmaA0S7v o8_9Lje9gj6uKgvZJLgTYGqbjivguqXWO22sVgar0pF77D0ztNo5Y1r..V7mpap.DGxXxMiGW0M_ So8FJbKem9iH2gZ.9qkCdVIXNWs7c1XZr3C90O8QZR08UncN4D_.iflvRznYvDedcdKrgk_mj4qU 1zTBesoKvVAk_Ylh7pYQZayRbGrL2OwkCPng6GLaXalWlYXZnwM61J8xIT1cE2XNu2DhOyLFnsFL WzDvFBmoBwbpyILWhtYy1P9oOxrmIKccN0IJCN0hras8iMIAO6ObG5fzCV3OfumV2P6Gs1P78LYV E6m_yss.uDoINzV2Kza8Syev9pSMcdSz.cmHbwjXoxJzfdEbpwg--
Received: by; Tue, 16 Jun 2015 05:11:58 +0000
Date: Tue, 16 Jun 2015 05:11:57 +0000 (UTC)
From: Mark ZZZ Smith <>
To: Ca By <>, "Eric Vyncke (evyncke)" <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_4420640_10869934.1434431518026"
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [v6ops] Extension Headers / Impact on Security Devices
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Mark ZZZ Smith <>
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Jun 2015 05:12:04 -0000

      From: Ca By <>
 To: Eric Vyncke (evyncke) <> 
Cc: "" <>rg>; "" <> 
 Sent: Tuesday, 16 June 2015, 8:32
 Subject: Re: [v6ops] Extension Headers / Impact on Security Devices

On Monday, June 15, 2015, Eric Vyncke (evyncke) <> wrote:


As you probably know, Cisco handles PSIRT issues with care, so, I have no
clue on this specific advisory. My own (educated) guess is that the packet
causing a LC reload is fully RFC 2460 compliant but unusual, so, probably
(a guess again) a combination of extension headers triggering a bug.

In this specific case, I would not blame IPv6 or RFC 2460 but rather my
own company (even if the affected versions were quite old as new IOS-XR
versions appear to be immune to this bug). And I appreciate the humor in
your rhetorical question about which FW could protect a CRS... Air gap
probably :-)

More generally, regarding the 'parsing of the header' and performance, my
understanding (and I am NOT a HW engineer) is that there are multiple ways
to parse the header chain:
- purely software in low-end devices, should have a marginal performance
- specific ASIC in middle-end devices (read high end enterprise), probably
some limitations and heavy performance impact (but again within one
organization, so, easier to fix the root cause)
- a lot of specialized network processors in high-end devices (SP gears),
which is a similar case as the 'low-end device', performance impact but
marginal as parsing the chain of headers is not that hard after all _when_
coded correctly

As the extension headers are specific to IPv6, this is an area when we
will all learn (and have learned already) a lot of things...

I respectfully disagree with your last sentence. Of course, destination
AS/host SHOULD only accept useful, known and legit ext headers; but, why
would an ISP filter on ext headers if they do not harm their own infra or
a customer infra? Do you envision an Internet where only TCP/443 and
UDP/43 would be accepted?

Last point, the Internet will have to use IPv6 for 10 or 20 years at
least. If the IETF/ISP block all new _options_ in _existing_ extension
headers, then we will be stuck in 1997 for network innovation. While I do
not like taking security risks, I even fear more the lack of innovation.

I keep hearing this and it is very bizarre to hear 
With regards to 1997, believing that there will be innovation in the narrow waist of hour glass (network layer), that is very 1997. The network layer is stable and boring.... Hence it being narrow.  Innovation is welcome everywhere except network in the e2e model
/ Absence of evidence is not evidence of absence. 

/ Consider what the network and host situation was in 1997 (wired network access, desktops outselling laptops, dialup Internet for residential, corporates in total probably being the largest spenders on Internet access) to today and the near future (wireless networks, smartphones/tablets being the dominant Internet access device in some markets - and they're multi-homed, M2M/IoT considered to be place where the greatest expansion of Internet connected devices is going to occur in the near future.)
/ IPv6 has had relatively little adoption, and it is only starting to increase quite rapidly in the last few years and that is mainly because of mobile networks. There hasn't and still doesn't seem to be much thinking about how IPv6's differences from IPv4's can be taken advantage of yet - an "IPv4 first" or an "IPv4 == IPv6" mindset seems to be still very common (I think the network virtualisation space is where this is might be most prominent - I think most of the technologies they're inventing require fork lift network upgrades, so the costs of deploying IPv6 at the same time become a lot less significant. So if there is a "cheap" opportunity to deploy IPv6, and IPv6 is going to be the long term network layer 3, why not optimise for it now? That was the thinking behind my "Enhancing Virtual Network Encapsulation with IPv6" draft) 
/ We don't want to disable innovation opportunities that IPv6 may provide before people have arrived at an "IPv6 first" or "IPv4 != IPv6" mindset.  

Let's talk on Thursday at Silvia's IPv6 Conference in Zurich ;-)


On 11/06/15 11:58, "Enno Rey" <> wrote:
>the problem here is the definition of "normal IP packet" as of RFC2460.
>To illustrate this I just quote from today's Cisco advisory (Cisco IOS XR
>Software Crafted IPv6 Packet Denial of Service Vulnerability) on packets
>potentially crashing CRS-3 line cards:
>"The vulnerability is due to incorrect processing of an IPv6 packet
>carrying IPv6 extension headers that are valid but unlikely to be seen
>during normal operation. An attacker could exploit this vulnerability by
>sending such an IPv6 packet to an affected device that is configured to
>process IPv6 traffic. An exploit could allow the attacker to cause a
>reload of the line card, resulting in a DoS condition."
>two question come to mind here:
>- is a "valid but unlikely" extension header chain "normal"?
>- what ("combination of FW & IPS or whatever") would you put in front of
>a CRS?
>my (sad) expectation is that we'll see much more of these (types of)
>issues in the future. given the current level of freedom that the RFC2460
>leaves (see also discussion/picture in
>"properly parsing an IPv6 packet, let alone in wire speed" seems a pretty
>much unsolvable task to me.
>That said I still fail to see any useful extension header besides AH&ESP
>(not even FH) to be transported in the Internet.
> If your firewall cannot implement this policy, then
>> it is time to change or to use a combination of FW & IPS or whatever.
>> - network person: as I will live with IPv6 for the rest of my life,
>>then I
>> want a way to extend it and I need any packet to travel to my source to
>> destination. Any IPv6 packet should be able to traverse the
>> Internet/private network as long as its layer-3 header is valid
>> (filtering/dropping can be done exceptionally for good operational
>> reason). Did we remember the IPv4 teardrop attack? It is blocked by
>> default by most routers for years ;-)
>> Bugs will plague us for ever... And make our life more complex than the
>> above description of course ;-)
>> -??ric
>> On 17/05/15 20:43, "Silvia Hagen" <> wrote:
>> >Hi
>> >
>> >I keep stumbling about that "recommendational wording" in RFC 2460
>> >everytime I teach it.
>> >
>> >Couldn't we update RFC2460 and make this list a strict order?
>> >
>> >I would want my firewall to notify me if the EHs in a packet do not
>> >follow the list.
>> >And limiting the number of possible EHs per packet might be a good
>> >
>> >Silvia
>> >
>> >-----Urspr??ngliche Nachricht-----
>> >Von: ipv6-wg [] Im Auftrag von Benedikt
>> >Stockebrand
>> >Gesendet: Sonntag, 17. Mai 2015 18:39
>> >An:
>> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices
>> >
>> >Hi Enno and list,
>> >
>> >Enno Rey <> writes:
>> >
>> >> hope everybody had a great #RIPE70 meeting. We did!
>> >> Many thanks to the organizers and chairs!
>> >
>> >and thanks to the actual speakers as well the speakers we had to turn
>> >down due to time constraints, too:-)
>> >
>> >> If the chairs consider this appropriate we will happily give a
>> >> presentation on this stuff in Bucharest or at another occasion.
>> >
>> >Sounds good to me!
>> >
>> >> - looking at the "liberty" RFC2460 provides as for ext_hdrs (wrt to
>> >> their number, order[...]
>> >
>> >Actually, as far as I'm concerned that's the real core of the problem.
>> >Or more specifically, the first two lines of RFC 2460, section 4.1:
>> >
>> >   When more than one extension header is used in the same packet, it
>> >   recommended that those headers appear in the following order:
>> >
>> >followed on the next page by
>> >
>> >   Each extension header should occur at most once, except for the
>> >   Destination Options header which should occur at most twice (once
>> >   before a Routing header and once before the upper-layer header).
>> >
>> >Note in particular that these are not even RFC 2119 "SHOULD" or
>> >"RECOMMENDED" and such.
>> >
>> >The impact here is actually at least twofold:
>> >
>> >- It is impossible to implement this as a simple pipeline architecture
>> >  in hardware; at least for cases deviating from the "recommendations"
>> >  above this effectively becomes either excessively complex to
>> >  in hardware or an invitation to DoS when implemented in software on
>> >  otherwise hardware router.
>> >
>> >- As I understand it, at least some of the issues you have found are
>> >  effectively based on violating the second paragraph quoted, making it
>> >  impossible to come up with a lower bound on how long the header chain
>> >  can actually get and therefore leading to the fragmentation related
>> >  attacks and similar you have discovered.
>> >
>> >The original idea was that the extension headers are processed strictly
>> >in the order they occur, so one question to ask is if there is any
>> >reason to violate these "recommendations" for other than malicious
>> >purposes.
>> >
>> >
>> >Cheers,
>> >
>> >    Benedikt
>> >
>> >--
>> >Benedikt Stockebrand,                   Stepladder IT
>> >Dipl.-Inform.                 
>> >
>> >          Business Grade IPv6 --- Consulting, Training, Projects
>> >
>> >BIVBlog---Benedikt's IT Video Blog:
>> >
>> >
>Enno Rey
>ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg -
>Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>Handelsregister Mannheim: HRB 337135
>Geschaeftsfuehrer: Enno Rey
>Blog: || Conference:
>Twitter: @Enno_Insinuator
>v6ops mailing list

v6ops mailing list

v6ops mailing list