On 06/13/2012 02:28 PM, Dave Hart wrote:

...

The aforementioned article is available at: <http://searchsecurity.techtarget.com/tip/Analysis-Vast-IPv6-address-space-actually-enables-IPv6-attacks>

...

"published" and "available" are misleading at best.

It is not. Just scroll down the page, and you'll find the whole article. -- it was easy to talk crap than to do that, right?

The article is teased with a sentence and a half, truncated by a demand for an email address with tiny legalese mentioning a privacy policy and terms of use that undoubtedly would take far longer to read than Gont's valuable content.

You don't need to read that to scroll the page down past it.

...

(FWIW, it's a human-readable version of the IETF Internet-Draft I published a month ago or so about IPv6 host scanning (see: <http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning>))

I guess I'll take a look at this to see what you're smoking.

I find it amazing the number of people that will talk crap when one publishes something when compared to the number of people that provides technical comments or criticism (even if it's "you're completely wrong because of this and that). Read the article. Have something to add or complain about the technical contents? -- Do it. But otherwise try to keep a good signal/noise ratio, please.

...

You can get "news" about this sort of stuff by following @SI6Networks on Twitter.

"news" in quotes is appropriate given it's really eyeball harvesting for marketing purposes.

Please do the math regarding the number of posts/tweets announcing publications to the number of posts/tweets doing marketing (probably just those about trainings). Then comment. Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

It seems I saw that title came through an article somewhere but I have a slight problem with stating that "Vast IPv6 address space actually enables IPv6 attacks". Going from an IPv4 32 bit address space to a IPv6 128 bit address space like you mentioned in the article would be a tedious effort to scan. But you also make the following assumptions: <Quote> A number of options are available for selecting the Interface ID (the low-order 64 bits of an IPv6 address), including: .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. Unfortunately, each of these options reduces the potential search space, making IPv6 host-scanning attacks easier and potentially more successful. <End Quote> That sounds fine and dandy but in reality, Internet facing IPv6 native or dual-stack systems that are installed with any security forethought at all would not embed any of these options with the exception of the last one (transitional or coexistence) only if forced to do so. I agree that some IPv6 addresses are set up to have catchy names, but why set up hundreds or even thousands of IPv6 addresses with IPv6 addresses that you try to remember like we did with IPv4? I will also concede that Microsoft has not helped with issuing multiple IPv6 addresses using "privacy" settings even if a static IPv6 address is set. In general, I just don't agree with your conclusions, and with proper IPv6 firewall rules, the network should still be as secure as the IPv4 systems. Not more insecure just because they run an IPv6 stack. Curtis -----Original Message----- From: Dave Hart [mailto:davehart@gmail.com] Sent: Wednesday, June 13, 2012 12:29 PM To: Fernando Gont Cc: NANOG Subject: Re: Article: IPv6 host scanning attacks On Wed, Jun 13, 2012 at 6:52 AM, Fernando Gont <fernando@gont.com.ar> wrote:

Folks,

TechTarget has published an article I've authored for them, entitled "Analysis: Vast IPv6 address space actually enables IPv6 attacks".

The aforementioned article is available at: <http://searchsecurity.techtarget.com/tip/Analysis-Vast-IPv6-address-s pace-actually-enables-IPv6-attacks>

"published" and "available" are misleading at best. The article is teased with a sentence and a half, truncated by a demand for an email address with tiny legalese mentioning a privacy policy and terms of use that undoubtedly would take far longer to read than Gont's valuable content.

(FWIW, it's a human-readable version  of the IETF Internet-Draft I published a month ago or so about IPv6 host scanning (see: <http://tools.ietf.org/html/draft-gont-opsec-ipv6-host-scanning>))

I guess I'll take a look at this to see what you're smoking.

You can get "news" about this sort of stuff by following @SI6Networks on Twitter.

"news" in quotes is appropriate given it's really eyeball harvesting for marketing purposes. Cheers, Dave Hart

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: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1