Fernando, On Apr 19, 2012, at 11:50 PM, Fernando Gont wrote:
> Hi, Bob, > > On 04/18/2012 05:55 PM, Bob Hinden wrote: >>> On 04/17/2012 08:58 PM, Bob Hinden wrote: >>>> In the Introduction the draft mentions that the IEEE MAC based >>>> interface identifiers don't eliminate the threat from host >>>> scanning. >>> [....] >>>> The problem I see is that this doesn't justify the claim that >>>> there is a problem with host scanning with MAC based interface >>>> identifiers. >>> >>> Fair enough. I will address this in the next rev of the document. >> >> This is an area I would like to know more about, and it would be good >> to quantify the problem. > > I've just posted this drafty I-D, which hopefully shed some light on the > subject (or triggers further discussion): > <http://www.ietf.org/id/draft-gont-opsec-ipv6-host-scanning-00.txt> > > (this one might be a better reference) Thanks. I will take a look. > > >> Off the top of my head, if an attacker knew the subnet prefix, it >> could guess a company_id, it would have to scan ~17M (2^24) addresses >> per company_id. That would only result in finding the devices using >> that company_id. > > Agreed. But in a number of scenarios (e.g., ISP X provisioned with > vendor X) that may be all you need. That said, please look at the > discussion on virtualization in draft-gont-opsec-ipv6-host-scanning-00.txt > > >> This would have to be repeated many times to find >> even the majority of devices on a single subnet. This is clearly >> easier than having to scan 2^64 addresses in a single subnet, but >> still considerably harder than than a /24 IPv6 subnet. > > I think the key question here is whether these attacks are feasible or not. > > For example, consider an attacker remotely-scanning the v6-enabled IETF > meeting network. He'd probably target: > > * Apple's (Macs, iPads, iPhones) > * Dell's > * IBM's > * HP's > * Toshiba's > * Samsung's I agree, I would do that too :-) However, it also depends a lot on how many companies IDs each vendor has and how they allocate them to their devices. For example, I looked at http://standards.ieee.org/develop/regauth/oui/public.html and did a search for Apple and found about 150 assigned company_id's. [Note: It's "about" because some companies have "Apple" in their address]. The IEEE page also says: "Firms and numbers listed may not always be obvious in product implementations, as some manufacturers subcontract component manufacture and others include registered firm OUIs in their products." The point I am trying to make here is that we should characterize the risk here accurately. It's not as simple as get one company_id and then start scanning. > > > and he'd already discover a fair share of the hosts connected to the > network. > > Certainly not perfect, certainly harder than in IPv4, but still feasible. > > Now, if the same nodes implemented > draft-gont-6man-stable-privacy-addresses, the attacker would be better > off trying something else. > Agreed. It also hides the company_id. > >>>> 2. Design Goals >>>> >>>> Could these types of Interface Identifiers also be generated by >>>> DHCPv6 servers. I would think that it would be useful to >>>> generate these hard to predict IIDs when a DHCPv6 server is >>>> providing addresses. This would be much better than assigning >>>> them linearly that are easy to predict and scan for. >>>> >>>> That is, the same approach could be used to create IIDs for SLAAC >>>> and DHCPv6. >>> >>> Agreed. Do you think this should be incorporated in this I-D, or >>> that this should be addressed in a different I-D? >> >> Not sure. If the algorithm could be the same, then it would make >> sense to include both use cases (SLACC and DHCPv6). > > The algorithm could be essentially the same, probably with slight > modifications (e.g., DUID rather than Modified_EUI64). -- Just thinking > whether procedurally-speaking it'd be better to incorporate this here, > or have it as a separate document in dhcwg. > > > >>> I could certainly live with this document simply specifying an >>> alternative scheme for generating addresses (without formally >>> replacing/obsoleting any other method). However, I think it would >>> be appropriate that we recommend (somewhere... either in this doc, >>> in a document updating node requirements, in a future >>> node-requirements-bis, or wherever), that a scheme such as this is >>> RECOMMENDED over the ones embedding IEEE identifiers. >> >> I think there are some tradeoff here that we are discussing. > > FWIW, when it comes to draft-gont-6man-stable-privacy-addresses vs > IEEE-derived ones, the only tradeoff I can think of is, if anything, > simplicity for privacy. > > But yes, when one thinks about IIDs as a whole (IEEE-derived, > draft-gont-6man-stable-privacy-addresses, and RFC4941) there are a > number of aspectes to consider. > > > >> We may >> need some more experience before making a decision. In the short >> term pushing for a compete change might well be perceived as a >> disruptive change to IPv6 deployment. A good starting point is >> defining them as an alternative. > > I can certainly live with that. > > >>> That said, documents such as "Transmission of IPv6 Packets over >>> Ethernet Networks" mandate the generation of Modified-EUI-64 format >>> identifiers from IEEE identifiers. So I'm not sure what the right >>> approach (specs-wise) would be. e.g., formally update RFC 4291, >>> noting that besides what's in the "Transmission of IPv6 Packets >>> over XXX" documents, IIDs can be generated as specified in >>> draft-gont-6man-stable-privacy-addresses, or something else? >> >> I suggest looking at RFC4941 Privacy Extentions as the model. That >> created the privacy IIDs without having update any other documents. > > Will do. I should note, however, that privacy addresses do not seem to > be widely implemented, and even less widely enabled by default (and they > have been around for 10+ years). > > > >> I think the IPv6 Address Architecture supports a range of Interface >> IDs and this draft fall under that. For example, the IPv6 over <foo> >> documents, don't keep people from using manually configured >> addresses, privacy addresses, etc. > > My point was mostly about how to signal implementers that this > alternative exists, and also how to provide advice regarding what > algorithm is most desirable. > > Being able to benefit from the increase IPv6 address space to mitigate > host-scanning attacks would be a good thing, and an improvement over IPv4. Agreed. Thanks, Bob > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: [email protected] > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
