On 06/13/2012 08:24 PM, Karl Auer wrote: > On Wed, 2012-06-13 at 15:22 -0500, STARNES, CURTIS wrote: >> I have a slight problem with stating that "Vast IPv6 address space >> actually enables IPv6 attacks". > > So do I.
As noted, so do I. :-) > Compared to IPv4, scanning IPv6 is much, much harder, and that > is (I think) the most important thing to know. IMO, the important thing to know is that IPv6 host scanning attacks are not infeasible -- even when it has been used as a marketing argument for years. > The analysis was good in that it offered a bit of consideration to the > scanning issue, but... > > "Some estimates peg the length of time for a host-scanning attack on a > single IPv6 subnet at 500,000,000 years!" > > It's not an estimate. It's a approximation based on scanning a /64 > subnet at a thousand probes per second. 18 billion billion (addresses in > one /64) divided by one thousand, divided by 31536000 (the number of > seconds in a year) - works out to about 500,000,000. Exactly. Nice math, but it suffers from an incorrect assumption: that attacker will do brute force scans in the same way that they did for v4. In v4, the scale of the "problem" was small enough that even doing a bad job a la "brute force" was good enough. With v6, one needs to put more brains into the scanning logic, or else won't be able to get away with it. > >> .Embed the MAC address; >> .Employ low-byte addresses; >> .Embed the IPv4 address; >> .Use a "wordy" address; >> .Use a privacy or temporary address; >> .Rely on a transition or coexistence technology. > > Why do you not mention DHCP in this list? You do mention it elsewhere. > DHCPv6 will in general supply random addresses. You say that "some" > DHCPv6 servers produce sequential addresses - could you please give an > example? I use Nominum's DCS, which certainly does NOT do this very > foolish thing. Let me check what I'm running in my test lab (I will come back to you regarding this one) -- most likely KAME's implementation? > Low-byte addresses are generally going to be on high-value devices, > which will usually be servers (whose existence is thus public knowledge > anyway) There's a subtle detail here: One thing is having individual addresses being publicly available, but another is being able to find them all very easily. Example: Say I'm running hundreds of web sites on the same subnet (just an *example*).. You might argue that each of those addresses is 2public knowledge". However, that doesn't mean it's trivial for an attacker to (easily) find out all "alive" sites on a given subnet. If you use predictable addresses, that becomes possible. > Embedded IPv4 addresses are going to be a reducing problem, and in the > scenario you mention, as well as in most other scenarios, again mostly > on machines that have very strong protections from firewalls and their > own packet filters. I tend to disagree about "strong protection". For instance, recent findings seem to indicate lack of parity in filtering rules for v6 and v4 -- i.e., unfortunately, it's quite common that something that is blocked in v4 is *allowed* on v6. > Wordy addresses will be an issue for some vanishingly small percentage > of systems, and generally systems that their owners want people to see > (Facebook being a good example). These are generally going to be systems > whose existence is public knowledge anyway. Agreed. > All transition technologies are a reducing problem. The primary > transition technology - dual stack - has no technology-specific problems > in respect of scanning (except perhaps that the scanner, at least in > theory, gets two bites at the cherry). Agreed. > I think you are making a minor issue look far bigger than it is. IMO, IPv6 host scanning attacks being feasible is not e big thing by itself -- for instance, we have "survived" this problem for v4, so at least in theory there's no reason to believe that the sky is going to fall for the v6 case. What *is* important, IMO, is the amount of IPv6 mythology that there is out there, which leads to incorrect assumptions, and eventually to negative implications. >From the general "security considered during the design of the protocol rather than as an 'add on'" to "scanning attacks are impossible". When it comes to scanning, IMO it's more of "oh, yeah, it's feasible.. and the fix is obvious... let's fix it", than "let's gets scared about ipv6 host scannign". > I feel > the privacy issues around SLAAC are far more significant in the real > world than any threat from scanning. Unfortunately, one still hears in IETF corridors things like "not everyone needs privacy" from some mobile vendors... (sigh) > PS: I still like your RFC about stable privacy addresses. Thanks. That's where the "meat" is.. FWIW, articles such as the one I forwarded are mostly meant to raise awareness, such that folks in the position of implementing stuff such as draft-ietf-6man-stable-privacy-addresses actually do it. > PPS: There seems to be a diagram missing in the discussion of embedded > MAC addresses, after the word "syntax". Will check. Thanks! Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
