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

Eric, All,

On Mon, May 18, 2015 at 06:07:45AM +0000, Eric Vyncke (evyncke) wrote:
> Let me chime in ;-)
> 
> On this topic, I am suffering of schizophrenia with a double personality...
> 
> - security person: I hate when there are too many options and sub-options
> and my usual recommendation is to use white list approach at the
> destination (being plain layer-4 ACL or more content filtering) and at the
> source (let's try to cut down covert channels): block unused ports, block
> unused protocols (remember IP protocol 41), block unused extension headers
> and drop everything which is not a normal IP packet (from address spoofing
> to invalid EH chain).

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
=======================================================