I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments.
For more information, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Document: draft-ietf-dhc-anonymity-profile-06.txt Reviewer: Brian Carpenter Review Date: 2016-02 IETF LC End Date: 2016-02-15 IESG Telechat date: Summary: Almost ready -------- Comment: -------- There is a reciprocal-RAND IPR disclosure against this draft Minor Issues: ------------- > 3.5. Client Identifier Option ... > In contradiction to [RFC4361], when using the anonymity profile, DHCP > clients MUST use client identifiers based solely on the link layer > address that will be used in the underlying connection. The use of "solely" bothers me. I understand why the ID must be based on the MAC address, but why can't it be (for example) a hash of that address with a pseudo-random nonce? "Solely" seems to exclude that sort of solution. ... > There are usages of DHCP where the underlying connection is a point > to point link, in which case there is no link layer address available > to construct a non-revealing identifier. If anonymity is desired in > such networks, the client SHOULD pick a random identifier that is > unique to the current link, using for example a combination of a > local secret and an identifier of the connection. Firstly, s/random/pseudo-random/ and s/unique/highly likely to be unique/ Secondly, this seems underspecified. Something more like https://tools.ietf.org/html/rfc7217#section-5 seems necessary. > 4.3. Client Identifier DHCPv6 Option ... > When using the anonymity profile without the benefit of randomized > link-layer addresses, clients that want to protect their privacy > SHOULD generate a new randomized DUID-LLT every time they attach to a > new link or detect a possible link change event. Firstly, again, it's always pseudo-random in a computer. Secondly, it isn't obvious from the text that you are really abusing the RFC 3315 format by using a bogus MAC address and bogus timestamp. I suggest rewriting the sentence: When using the anonymity profile without the benefit of pseudo-random link-layer addresses, clients that want to protect their privacy SHOULD generate a new pseudo-random identifier in DUID-LLT format every time they attach to a new link or detect a possible link change event. Syntactically this identifier will conform to [RFC3315] but its content is meaningless. > 4.5.2. Prefix delegation > > The interaction between prefix delegation and anonymity require > further study. For now, the simple solution is to avoid using prefix > delegation when striving for anonymity. When using the anonymity > profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of > address assignment. I see the issue, but this may be problematic for some scenarios. I think this choice needs to be reviewed in 6man. I will make that happen. > 5. Operational Considerations > > The anonymity profile has the effect of hiding the client identity > from the DHCP server. This is not always desirable. Some DHCP > servers provide facilities like publishing names and addresses in the > DNS, or ensuring that returning clients get reassigned the same > address. Many DHCP servers will only give addresses to pre-registered MAC addresses. That should probably be noted, because it will prevent all use of pseudo-random MAC addresses. (Another reason to hash the MAC address with a nonce.) _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
