Re: Comments on <draft-gont-6man-stable-privacy-addresses-01>

[Fernando Gont <[e-mail]>]

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.



> 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?



> 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/

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.


> 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".

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?



> 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.


> 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.

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492