all,
the ADs have asked us to ensure that there are good review of documents in the
working group, prior to them being advanced to the IESG.
as a part of document last calls in the 6man working group, Bob and I want to
try
using volunteers and/or w.g. chair reviewers, that take specific responsibility
to
review documents in WG last call.
Bob and I have reviewed this document.
General comments:
--------------------------
We do see the usefulness of a interface-id generation algorithm, that results
in stable identifiers per IPv6 prefix, while not being derived from link-layer
MAC addresses.
The mechanism proposed could be viewed as an modification of temporary
addresses (RFC4941)
with lifetime handling as for SLAAC, or as an extension to CGA (RFC3972) address
generation where the public key is removed from the hash.
The method for generating "Stable privacy addresses" needs to be as well
specified
as temporary addresses (RFC4941).
We do wonder if the method of generating these addresses could be a
modification of the
algorithm in RFC4941, or if at least, larger parts of the text in RFC4941 could
be
references avoiding having to duplicate lots of text into this document.
We do not believe the current revision of the document is ready to advance to
the IESG.
Major points:
-----------------
- Stable Privacy Enhanced Addresses (SPE Addresses) should not be a replacement
for the
algorithm specified in RFC2464. It is an alternative. Section 3 needs
modification.
- The algorithm in the document is underspecified.
o It should specify the hash function. E.g. MD5 as RFC4941.
o It should handle reserved interface-ids (see 4941).
o We suggest renaming the “secret key” to “modifier”. And add text describing
how to ‘maintain’ the modifier (section 3 of RFC3972).
o It would be useful to include an example algorithm as has been done in some
other documents.
o Not all implementations use interface indexes
- Clarify what lifetimes these addresses have.
- Specify the default for DAD retries (IDGEN_RETRIES)
- Clarify the requirements for stable storage (compared to RFC2464)
Minor points:
-----------------
Don't use the term "static addresses" as that implies static aka manual
configuration.
These addresses are not static in that sense.
Section 3, Last Paragraph:
The reference to Node Information Queries only applies if the attacker is
onlink.
Current text overstates the problem. Move to security considerations. Addresses
will
leak regardless, in other communication, email header etc.
6. Security Considerations.
s/in replacement of/as an alternative to/
Third bullet:
The bullet on host-scanning needs some justification.
Fourth bullet: This is not a security issue.
Paragraph after bullets:
s/algorithm is meant to replace/meant to supplement/
Best regards and Merry Christmas,
Bob and Ole--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
