[Gen-art] Gen-ART Last Call review of draft-ietf-dhc-anonymity-profile-06

[Brian E Carpenter <[e-mail]>]

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.)