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

"Eric Vyncke (evyncke)" <> Mon, 15 June 2015 22:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B555E1B2C91 for <>; Mon, 15 Jun 2015 15:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -13.811
X-Spam-Status: No, score=-13.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p_lk6ZM0m57l for <>; Mon, 15 Jun 2015 15:15:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 12F6C1B2C8F for <>; Mon, 15 Jun 2015 15:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=11472; q=dns/txt; s=iport; t=1434406559; x=1435616159; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IHLPNzQLgdbiR3tJN70asxfXNOGTuzs8dwalyw0eqag=; b=UmXu89EZ3h7m/ROY5xX1Ma25o17GuDIeHZyjf+tHi7UuJNnMz3/ZsW94 J+Y1jnxTBz32pXm88AauSx5+LOUYWK4Be5VZqDL89zTr628hMxhKgNm76 GzfACQKMycZnZZFT755jWmyQzp6iZLSXdPIi7Osy5qPotO5sx+t4uY/ho 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,621,1427760000"; d="scan'208";a="159736298"
Received: from ([]) by with ESMTP; 15 Jun 2015 22:15:37 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t5FMFbFq023800 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Jun 2015 22:15:37 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 15 Jun 2015 17:15:37 -0500
From: "Eric Vyncke (evyncke)" <>
To: Enno Rey <>, "" <>
Thread-Topic: [v6ops] Extension Headers / Impact on Security Devices
Thread-Index: AQHQpGf5Wn5pwe9fwkWXgHffM0Q9gZ2unjGA
Date: Mon, 15 Jun 2015 22:15:36 +0000
Message-ID: <>
References: <> <> <F1D4404E5E6C614EB9D3083F4D15A7E7C4A92C@hex02> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
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: Mon, 15 Jun 2015 22:16:01 -0000


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.

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