[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] HP A-series switches are affected, too. [WAS: More on IPv6 RA-Guard evasion (IPv6 security)]
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
> 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
>>> 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.
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".