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@xxxxxxxxxxxxxxx web: http://www.si6networks.com
