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

Enno,

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
impact
- 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 ;-)

-éric

On 11/06/15 11:58, "Enno Rey" <erey at ernw.de> 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
>http://www.insinuator.net/2015/06/is-ipv6-more-secure-than-ipv4-or-less/)
>"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.
>
>best
>
>Enno
>
>
>
>
>
>
>
> 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
>>my
>> 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" <silvia.hagen at sunny.ch> 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
>>idea.
>> >
>> >Silvia
>> >
>> >-----Urspr??ngliche Nachricht-----
>> >Von: ipv6-wg [mailto:ipv6-wg-bounces at ripe.net] Im Auftrag von Benedikt
>> >Stockebrand
>> >Gesendet: Sonntag, 17. Mai 2015 18:39
>> >An: ipv6-wg at ripe.net
>> >Betreff: Re: [ipv6-wg] Extension Headers / Impact on Security Devices
>> >
>> >Hi Enno and list,
>> >
>> >Enno Rey <erey at ernw.de> 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
>>is
>> >   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
>>implement
>> >  in hardware or an invitation to DoS when implemented in software on
>>an
>> >  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
>>valid
>> >reason to violate these "recommendations" for other than malicious
>> >purposes.
>> >
>> >
>> >Cheers,
>> >
>> >    Benedikt
>> >
>> >-- 
>> >Benedikt Stockebrand,                   Stepladder IT
>>Training+Consulting
>> >Dipl.-Inform.                           http://www.stepladder-it.com/
>> >
>> >          Business Grade IPv6 --- Consulting, Training, Projects
>> >
>> >BIVBlog---Benedikt's IT Video Blog:
>>http://www.stepladder-it.com/bivblog/
>> >
>> >
>> 
>
>-- 
>Enno Rey
>
>ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de
>Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902
>
>Handelsregister Mannheim: HRB 337135
>Geschaeftsfuehrer: Enno Rey
>
>=======================================================
>Blog: www.insinuator.net || Conference: www.troopers.de
>Twitter: @Enno_Insinuator
>=======================================================
>
>_______________________________________________
>v6ops mailing list
>v6ops at ietf.org
>https://www.ietf.org/mailman/listinfo/v6ops