The Abstract of the document is: ---- cut here ---- IPv6 offers a much larger address space than that of its IPv4 counterpart. The standard /64 IPv6 subnets can (in theory) accommodate approximately 1.844 * 10^19 hosts, thus resulting in a much lower host density (#hosts/#addresses) than their IPv4 counterparts. As a result, it is widely assumed that it would take a tremendous effort to perform host scanning attacks against IPv6 networks, and therefore IPv6 host scanning attacks have long been considered unfeasible. This document analyzes the IPv6 address configuration policies implemented in most popular IPv6 stacks, and identifies a number of patterns in the resulting addresses lead to a tremendous reduction in the host address search space, thus dismantling the myth that IPv6 host scanning attacks are unfeasible. ---- cut here ----
Any comments will be very welcome (note: this is a drafty initial version, with lots of stuff still to be added... but hopefully a good starting point, and a nice reading ;-) ).
in chapter 4, the distribution is not what I have seen, neither at customers, nor DNS analysis (host scanning results are biased of course and therefore not valid as comparison). 2008 - so four years ago - the IPv6 internet was different from what it is today, and the same will be the case four years in the future. but thats rather a marginal thing I guess.
the "abuse scan" mentioned by [Ybema2010] was most likely my scan I did on the IPv6 internet to perform a statistical analysis to optimize further ipv6 pentests (some rough results being in my ipv6 presentations from 2010-2011). I had some people complaining that they got something like 50k packets per minute (which means they were on a slow connection... ;-) ) (everyone who sent my ISP a "we dont want that" email got on the blacklist for future scans of course)
at my presentations at the coming conferences (HITB Kuala Lumpur in October, H2HC Sao Paulo in October and Hackingzone Cali in November) I will show all remote and local host detection techniques I have found and developed, and a little later the tool which does that will finally be released with a big update to thc-ipv6 with a lots of new tools and attacks. (in my trainings already includes all this stuff)
Greets, Marc
P.S. the reference date for Ybema2010 is wrong: August 2011 - but URL says /nanog/2010-September/
Nice to hear from you! -- Please find my comments in-line...
On 04/20/2012 04:32 AM, Marc Heuse wrote:
> in chapter 4, the distribution is not what I have seen, neither at
Seen for clients, or seen for servers? -- Note that the aforementioned distribution is for clients, rather than servers.
That said, those data are possibly outdated, and if not, will be as IPv6 gets deployed: e.g., I really doubt there will be such a large percentage of manually configured addresses in the case of "normal" clients.
> customers, nor DNS analysis (host scanning results are biased of course > and therefore not valid as comparison). 2008 - so four years ago - the > IPv6 internet was different from what it is today, and the same will be > the case four years in the future. but thats rather a marginal thing I > guess.
Agreed. The only reason for which I'm referencing Malone's paper is that I do not know of any other publication with more recent results. -- For instance, I was urging Malone to run his experiment again. :-)
> the "abuse scan" mentioned by [Ybema2010] was most likely my scan I did > on the IPv6 internet to perform a statistical analysis to optimize > further ipv6 pentests (some rough results being in my ipv6 presentations > from 2010-2011).
I've been meaning to drop you en e-mail about your presentation, but I think I never did so. (just to double-check if what you were doing is what I thought you were doing) -- more on this later (i.e., the actual questions/comments :-) )
BTW, which of your presentations should I reference for this? (conf name, where, when, url to slides, etc.)
> I had some people complaining that they got something like 50k packets > per minute (which means they were on a slow connection... ;-) ) > (everyone who sent my ISP a "we dont want that" email got on the > blacklist for future scans of course)
IIRC, you were not sweeping the address space, but rather grabbed some DNS names, bruteforced other names (with a dictionary), and tried those, right?
> at my presentations at the coming conferences (HITB Kuala Lumpur in > October, H2HC Sao Paulo in October and Hackingzone Cali in November) I > will show all remote and local host detection techniques I have found > and developed, and a little later the tool which does that will finally > be released with a big update to thc-ipv6 with a lots of new tools and > attacks. (in my trainings already includes all this stuff)
Please post a note when conference registration opens, or the like -- it's interesting stuff for the community to know about!
> Greets, > Marc
> P.S. the reference date for Ybema2010 is wrong: > August 2011 - but URL says /nanog/2010-September/
Hacking the xml (to produce the I-D) at night wasn't much of a good idea, it seems :-) -- I will fix this one in the next rev.
P.S.: I will also reference the two implementations posted recently on-list for the inverse-DNS-based scanning attack, too.
Section 1 says "ssentially" where I think you mean "essentially".
Section 3.1.2 of the draft states:
It is important to note that "privacy addresses" are generated in addition to traditional SLAAC addresses (i.e., based on IEEE identifiers): traditional SLAAC addresses are employed for incoming (i.e. server-like) communications, while "privacy addresses" are employed for outgoing (i.e., client-like) communications. This means that implementation/use of "privacy addresses" does not prevent an attacker from leveraging the predictability of traditional SLAAC addresses, since "privacy addresses" are generated in addition to (rather than in replacement of) the traditional SLAAC addresses derived from e.g. IEEE identifiers.
According to my best knowledge, this isn't completely true. I haven't tested this myself, but it seems that OpenBSD (in the -current and the upcoming 5.1) drops the EUI-64 address when a privacy address has been generated, thus having only the privacy address as global scope address. That changes the "discoverability" of those hosts significantly: if the randomization is done properly and the address isnt' stored in DNS, the host would be practically undetectable without extra information. Of course, one would expect that an OpenBSD box is used as a server of some kind, and that would make the abovementioned configuration rare.
> The Abstract of the document is: > ---- cut here ---- > IPv6 offers a much larger address space than that of its IPv4 > counterpart. The standard /64 IPv6 subnets can (in theory) > accommodate approximately 1.844 * 10^19 hosts, thus resulting in a > much lower host density (#hosts/#addresses) than their IPv4 > counterparts. As a result, it is widely assumed that it would take a > tremendous effort to perform host scanning attacks against IPv6 > networks, and therefore IPv6 host scanning attacks have long been > considered unfeasible. This document analyzes the IPv6 address > configuration policies implemented in most popular IPv6 stacks, and > identifies a number of patterns in the resulting addresses lead to a > tremendous reduction in the host address search space, thus > dismantling the myth that IPv6 host scanning attacks are unfeasible. > ---- cut here ----
> Any comments will be very welcome (note: this is a drafty initial > version, with lots of stuff still to be added... but hopefully a good > starting point, and a nice reading ;-) ).
Thanks so much for your feedback! -- Please find my comments in-line...
On 04/20/2012 08:01 AM, Christiaan Ottow wrote:
> Section 3.1.2 of the draft states:
> It is important to note that "privacy addresses" are generated in > addition to traditional SLAAC addresses (i.e., based on IEEE > identifiers): traditional SLAAC addresses are employed for incoming [....] > According to my best knowledge, this isn't completely true. I haven't > tested this myself, but it seems that OpenBSD (in the -current and > the upcoming 5.1)
Last time I checked (not long ago), OpenBSD did not implement RFC 4941 (privacy addresses) at all. Could you please double-check this?
> drops the EUI-64 address when a privacy address has > been generated, thus having only the privacy address as global scope > address.
This would be somewhat weird, since you usually want a stable address in addition of privacy/temporary addresses.
The second ping is to the address the host would have configured through EUI-64 SLAAC. This output seems to indicate that only the privacy address is configured.
> Thanks so much for your feedback! -- Please find my comments in-line...
> On 04/20/2012 08:01 AM, Christiaan Ottow wrote: >> Section 3.1.2 of the draft states:
>> It is important to note that "privacy addresses" are generated in >> addition to traditional SLAAC addresses (i.e., based on IEEE >> identifiers): traditional SLAAC addresses are employed for incoming > [....] >> According to my best knowledge, this isn't completely true. I haven't >> tested this myself, but it seems that OpenBSD (in the -current and >> the upcoming 5.1)
> Last time I checked (not long ago), OpenBSD did not implement RFC 4941 > (privacy addresses) at all. Could you please double-check this?
>> drops the EUI-64 address when a privacy address has >> been generated, thus having only the privacy address as global scope >> address.
> This would be somewhat weird, since you usually want a stable address in > addition of privacy/temporary addresses.
This could be problematic, since these addresses are valid for just 24 hours (vltime==86398). i.e., if you were used to e.g. days-long ssh sessions, this would break them.
That said, did you check whether OpenBSD configures new addresses once pltime becomes 0? If it doesn't, then after pltime seconds you'd have no "preferred" addresses. (After 24 hs or so, the system should have about 6 global addresses per interface -- assuming the same settings as above).
> This could be problematic, since these addresses are valid for just 24 > hours (vltime==86398). i.e., if you were used to e.g. days-long ssh > sessions, this would break them.
Wouldn't vltime becoming zero break sockets on any platform, regardless of the presence of another global address?
> That said, did you check whether OpenBSD configures new addresses once > pltime becomes 0? If it doesn't, then after pltime seconds you'd have no > "preferred" addresses. (After 24 hs or so, the system should have about > 6 global addresses per interface -- assuming the same settings as above).
So, this setup would not break connections I suppose, but would leave garbage addresses. I've leave the system running for a while to see when vltime becomes infty, and how long deprecated addresses stay behind when new addresses have been acquired.
>> This could be problematic, since these addresses are valid for just >> 24 hours (vltime==86398). i.e., if you were used to e.g. days-long >> ssh sessions, this would break them.
> Wouldn't vltime becoming zero break sockets on any platform, > regardless of the presence of another global address?
Yes, but if you have another address, at the very least you have the option to use such address. Here, since OpenBSD is only employing temporary addresses, you have no other option.
> So, this setup would not break connections I suppose,
vltime becomes infinity when pltime becomes o? -- that's kind of wierd.
> but would leave > garbage addresses. I've leave the system running for a while to see > when vltime becomes infty, and how long deprecated addresses stay > behind when new addresses have been acquired.
Cool! --Please post the results when you have them.
>> So, this setup would not break connections I suppose,
> vltime becomes infinity when pltime becomes o? -- that's kind of wierd.
I suspect this is done since no new address has been acquired yet. I discovered that my router doesn't send unsolicited RA's, and OpenBSD was waiting for one of those to configure a new temporary address. My hypotheses is that when pltime nears zero, a new temporary address is configured using an unsolicited RA. If no RA is received, vltime is changed to infty to prevent loss of connectivity. The man page states:
<snip> Temporary addresses are deprecated after 24 hours. Once a temporary address has been deprecated, a new temporary address will be configured upon reception of a router advertisement indicating that the prefix is still valid. Deprecated addresses will not be used for new connections as long as a non-deprecated address remains available. Temporary addresses become invalid after one week, at which time they will be removed from the interface. Address lifetime extension through router advertisements is ignored for temporary addresses. </snip>
>> but would leave >> garbage addresses. I've leave the system running for a while to see >> when vltime becomes infty, and how long deprecated addresses stay >> behind when new addresses have been acquired.
> Cool! --Please post the results when you have them.
