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

[Bob Hinden <[e-mail]>]

Fernando,

This is my personal views from reading the draft.

Generally I support the idea in this draft that another type of privacy addresses would be useful to add to IPv6.  For example, to not expose the vendor IDs in IEEE MAC addresses.  I have some comments on the internet draft.

Bob

------

Introduction

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 first is a presentation you prepared and the second is also written by you but not publicly available (the reference says "available on request").  I was able to find the presentation online.  It makes an argument that host scanning is possible because (in my words) that there is structure in how Internet IDs are formed.  It lists different type of IIDs found and reported in a paper by Malone.  This paper is primarily about the observed types of address in an operational test.  It includes stats on the percentage of IPv6 address types observed in live traffic (e.g., 50% SLACC based, 20% IPv4 based, etc.).   

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.  

-------

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.  

---------

5. Security Considerations

In the second paragraph the document says 

  "We note that this algorithm is meant to replace Modified EUI-64 format identifiers".  

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.

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?

-------

Sections 7.

I don't understand the purpose of this section.  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?  Perhaps rewriting it to show how addresses based on these IIDs prevent these problems.


----

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.