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

[Fernando Gont <fgont () si6networks com>]

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.

Agreed.


> 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:
http://tools.ietf.org/id/draft-gont-v6ops-ra-guard-evasion-01.txt

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".

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont () si6networks com
web: http://www.si6networks.com



_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/