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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
