The 6man chairs and the author have requested that I perform an
additional detailed review of
A Method for Generating Semantically Opaque Interface Identifiers with
IPv6 Stateless Address Autoconfiguration (SLAAC)
draft-ietf-6man-stable-privacy-addresses-13
High Level
==========
The document is well-written and has been subject to intense debate in
the WG.
I support taking it further.
Summary Recommendations
=======================
1. Proceed with the document and the proposed solution.
2. Given the likely ubiquitous deployment of this standard,
I think it would greatly enhance the credibility of the resulting RFC if
the WG could see running code on:
- Linux
- an embedded device or other memory-constrained device.
- (BSD implementation is already OK AFAIK)
3. I think there should be some words on the quality requirements of the
PRF F(), and also any security impact of this being weak/ predictable.
4. Add something on backwards compatibility
e.g. "An implementation MAY avoid using RIDs with u=1 if the implementor
is concerned about backwards compatibility with older SLAAC
implementations sharing the same L2 link."
Section 3 brushes this issue aside, but I still have doubts.
5. Add random delay before regenerating temporary addresses when
incrementing the DAD counter to avoid lock step behavior (section 4).
6. Clarify that "The use of non-volatile memory is optional, and hosts
that do not implement this feature are still compliant to the protocol
specification." (in section 4)
7. Restructure the intro.
8. Handle the nits.
Goals
=====
There's a balance between the requirements of an IID being opaque to
prevent unwanted correlation and tracking,
and the need for network managers to be able manage a network, and
remote users to connect to server processes.
Although far from being a universal solution, I think this document hits
the design goals that it sets out to achieve.
There are likely to be other solutions proposed for IID generation in
the future that have different design goals.
This document does not block such proposals, provided they implement DAD.
The incorporation of the shared secret mitigates that bad guys can
trivially guess or correlate
the opaque IID with much certainty when machines change IPv6 prefix
(although I recognise that there's a limited number
of bits of entropy in an IID and there are plenty of other mechanisms
that can be used
to achieve the same result.)
There is also extensive documentation on the "how to" section of the IID
generation,
which is likely to be useful if at any time the opaque IID has to be
"predicted" remotely by an administrator
who is a "good guy" (and thus who knows the shared secret and PRF).
Future Innovation & Backwards Compatibility
===========================================
A possible future extension of this IID generation mechanism (which is
currently contentious) could be to allow
SLAAC with IID of lengths other than 64 bits, and thus allow coexistence
of full CIDR + autoconfigured IPv6,
which could potentially solve issues with mobile tethering and Homenet
using a single /64 delegation.
Section 3 addresses backwards compatibility.
Technical
=========
I have some doubts about the (lack of) specification of the PRF F().
Achieving 64 bits of entropy is not trivial (especially on smaller
systems or those without many external inputs)
/IPv6 implementations conforming to this specification MUST generate
Interface Identifiers using the algorithm specified in this section
in replacement of any other algorithms used for generating "stable"
addresses with SLAAC/
Is this MUST per interface or per IPv6 node?
AFAICS there'd be no harm if a specialised LAN interface on a router
used MAC based SLAAC on one interface, but opaque addresses on another.
/Implementations conforming to this specification SHOULD provide the
means for a system administrator to enable or disable the use of this
algorithm for generating Interface Identifiers./
Again, per interface or per node?
Section 3 brushes aside likely IID collisions with older SLAAC
implementations but I still have doubts.
How about "An implementation of this algorithm MAY avoid using RIDs with
u=1 if the implementor is concerned about backwards compatibility with
older SLAAC implementations sharing the same L2 link."
Section 4 /Resolving Duplicate Address Detection (DAD) conflicts/
Should there be some words about random back-off / retry time to avoid
nodes lock-step incrementing the DAD counter?
e.g. "Hosts SHOULD introduce some random delay before regenerating a new
temporary address when incrementing the DAD counter, to avoid lock-step
behavior of multiple hosts" ?
Clarify that non-volatile memory is optional (in section 4)
e.g. "The use of non-volatile memory is optional, and hosts that do not
implement this feature are still compliant to the protocol specification."
Editorial
=========
IMHO The intro is a long slog to read and could do with having some
information either culled or broken up or moved elsewhere.
Specifically: The natural end of the introduction to me is the line
"Hence, there is a motivation to improve the properties of "stable"
addresses regardless of whether temporary addresses are employed or not."
plus
"This document specifies a method to generate Interface Identifiers
that are stable/constant for each network interface within each
subnet, but that change as hosts move from one network to another,
thus keeping the "stability" properties of the Interface Identifiers
specified in [RFC4291], while still mitigating address-scanning
attacks and preventing correlation of the activities of a node as it
moves from one network to another."
The information on "Relationship to Other standards" should probably be
separate from the Introduction, with subsections for "Temporary
Addresses", "SLAAC" and "DHCPv6" .
Key Words (2119) is also usually a separate section from what I can recall.
There are references to 2464. How about adding 2467 and 2470 or 3572?
Nits
====
indentation of /Cryptographically Generated /
indentation of / It should be noted that temporary addresses/
I understand that the indentation had some meaning, but it's lost
without the WG context.
s/ is a orthogonal to/ is orthogonal to/
s/replacing a Network Interface Card (NIC)/replacing a Network Interface
Card (NIC) or adding links dynamically to a Link Aggregation Group (LAG)/ ?
s/Including the optional Network_ID parameter when computing the RID
value above would cause the/
Including the optional Network_ID parameter when computing the RID value
above causes the/
Some pagination issues of the HTML version.
--
Regards,
RayH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
