Fernando, On Apr 17, 2012, at 9:33 PM, Fernando Gont wrote:
> Hi, Bob, > > Thanks so much for your feedback! Please find my responses in-line... > > 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. >> To justify this the document references two documents >> [Gont-DEEPSEC2011] [CPNI-IPv6]. > [....] >> 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. >> It would be helpful if you could provide some data or analysis that >> justifies this to quantify the risk. In my reading the references >> don't do that. > > 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. 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. 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. > >> 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). > > > >> 5. Security Considerations >> >> In the second paragraph the document says >> >> "We note that this algorithm is meant to replace Modified EUI-64 >> format identifiers". > > Note: What I meant here is that there are meant to be used instead of > the MAC-based addresses. Based on your comment (and after re-reading the > relevant specs), it seems that this para needs to be tweaked as follows: > > 1) s/to replace/to be an alternative to/ > 2) s/Modified EUI-64 identifiers/IIDs based on IEEE identifiers/ I think for now, I suggest an alternative approach. This should be stated earlier in the document too. > > Thoughts? > > > >> This is the first time the document says this. If it intends to do >> this, it should be in the main part of the document and not first >> appear in the security considerations. The document makes a clear >> argument why it is preferable to MAC based IIDs, but it doesn't >> justify replacing Modified EUI-64 identifiers. It's a would be a >> major change to the IPv6 Address Architecture that I don't think is >> warranted. > > 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. 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. > > >> The algorithm in Section 3. even clears the U/L bit to be compatible >> with the Modified EUI-64 IIDs. I think document may be confusing >> IEEE MAC based Modified EUI-64 Interface IDs with the format defined >> in the IPv6 Address Architecture that can accommodate different types >> of tokens (MAC based, random number based, manual assignment, etc.) >> to create IIDs. >> >> Please clarify? > > You're right. Throughout the document, most references to "Modified > EUI-64 identifiers" really mean "IEEE-derived IIDs". Thanks, as I suspected. > 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. 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. > > > >> Sections 7. >> >> I don't understand the purpose of this section. > > This Section was essentially added to address the comments during my > presentation of this document at the Paris IETF (e.g., that RFC4941 > address, by themselves, the problem of host-tracking). > > > >> It comes after the >> Acknowledgement section and before References. It reads like open >> issues and says it might be removed. Is it meant as an appendix? > > Yes. I realized of the wrong placement of this section *after* > submitting it, and hence this shows up as Section 7 rather than as an > Appendix. -- I've already fixed this in my working copy of the I-D, and > hence this will appear as an Appendix in the next rev. Sounds good. > > >> Perhaps rewriting it to show how addresses based on these IIDs >> prevent these problems. > > FWIW, this section tries to show that if you implement RFC4941 while > still implementing the MAC-based addresses, both host-scanning attacks > and host-tracking remain possible. > > >> References: >> >> [CPNI-IPv6] Gont, F., "Security Assessment of the Internet Protocol >> version 6 (IPv6)", UK Centre for the Protection of National >> Infrastructure, (available on request). >> >> I am not sure this will be acceptable by the RFC-Editor. There >> isn't enough information to know who to ask to to get a copy. It >> would be better if it was available online. > > I'm working to make this happen. Cool! Thanks, Bob > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fg...@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
