Re: [Full-disclosure] HP A-series switches are affected, too. [WAS:- More on IPv6 RA-Guard evasion (IPv6 security)]

From: Fernando Gont <>
To: Marc Heuse <>
Cc: Full Disclosure <>, <>,
Subject: Re: [Full-disclosure] HP A-series switches are affected, too. [WAS:- More on IPv6 RA-Guard evasion (IPv6 security)]

Hi, Marc,

On 09/01/2011 07:59 AM, Marc Heuse wrote:
>> FWIW, "publicly-released first" != "discovered" (ask Cisco's PSIRT if in
>> doubt) -- anyway, I'm just trying to trigger discussion and get feedback...
> when I reported to PSIRT they were not aware of the issue - so who
> called them first is unsettled :-) - however I published first ;-)

Again, please ask PSIRT. :-)

In any case, the world doesn't (or "shouldn't", at least) care about the
"who", but rather should care about the "what".

>> Anyway... I'd bet that every implementation that "followed" the spec is
>> vulnerable....
> it is not mentioned in the RFC that an interface does have to support
> unlimited autoconfigurated addresses on its interfaces, nor does it
> state an upper limit. 

I was referring to the RA-Guard spec (RFC6105), and not the SLAAC spec.

> so its undefined and up to the implementor. And
> those who thought about it and saw the DOS coming (Solaris, OpenBSD) put
> limits, others didnt (everybody else).

One could argue that good programming practice means that you enforce
limits on everything. That said, I agree that implementation advice is
strongly needed.

>>> By the way, I don't think it is a good idea to disallow any Extension
>>> Headers in ND-Messages, 
>> Consensus at the relevant IETF working-group (6man) seems to be to only
>> ban the Fragment Header (when SEND is not employed).
> not allowing ANY extension headers for NDP and RA is the way to go. But
> of course, doing this might break future features. Thats the reason that
> only the fragment header is planned to be banned. Networking people
> usually win over security people.

mmm... not really so. Bob Hinden himself seemed to be in favor of baning
all of them..

>> A more conservative approach would be to simply require that the
>> upper-layer header be present in the first fragment. (i.e., that the
>> first fragment contains all the information that you need to apply an ACL).
> and this is easily bypassed by overlapping fragments.


> All current operating systems allow overlapping fragments, Windows,
> OpenBSD, ... all.
> I know there is an RFC which forbids overlapping fragments, but nobody
> is implementing it.

IIRC, both Linux and Windows 7 do.

>>> I'd like switches to discard ND-Messages with
>>> more that e.g. 3 chained headers. 
>> The point was that this could be expensive (if at all possible) for the
>> RA-Guard implementation to do.
> the main problem for RA guard is that it *requires the clients to change
> their behaviour to be effective*:
>  - drop overlapping fragments
>  - drop RAs and NDPs which have extension headers / are fragmented
> and this will not be happening soon, if ever.

Please see:

It doesn't require any modifications at the client (assuming it
completely bans fragmented RAs).

> so until then, RA guard is reliability feature (prevent accidential RAs,
> e.g. by connection sharing of a Laptop) and no security feature.

As noted in my blog post, curiously enough the problem statement
(RFC6104) is about accidental RAs, while the RA-Guard "spec" itself aims
to be a "security device".

Fernando Gont
SI6 Networks

Copyright © 1995-2020 All rights reserved.