Re: [dhcwg] WGLC on draft-ietf-dhc-anonymity-profile-03 - Respond by Sept. 22, 2015

[Marcin Siodelski <[e-mail]>]

I have read the version -03 of the document and I support it move
forward. However, I have some issues, which are mostly repeating what I
have said in my previous review from July 22nd, 2015.

3. Anonymity profile for DHCPv4
Normative language needs cleanup in this section.

- all messages MUST contain the appropriate Message Type. In the text
DHCPDISCOVER MUST contain Message Type, other messages SHOULD contain
Message Type. This is wrong.

- Similar applies to the client identifier. I think that in all cases
the client SHOULD send it (there may be cases when the client doesn't
send it though). Therefore, the DHCPDISCOVER case should not mandate
client identifier, as it does now.

- I wonder if there is any reason to state that the client SHOULD
include Parameter Request List option? The RFC2131 says it MAY. So, if
the client is not interested in receiving any options why SHOULD? And
why MUST in the DHCPDISCOVER case.

It also seems that you should probably replace DISCOVER with
DHCPDISCOVER, REQUEST with DHCPREQUEST and so on. They are the proper
names for the messages.

3.3. Requested IP address option

"There are scenarios in which a client connects to a network when a
lease is still valid".

I think this is to address the INIT-REBOOT case when the client wakes up
and sends Requested IP address option in the DHCPREQUEST message to
obtain the same address. That's ok, but I think it should be referred to
as INIT-REBOOT state because it is a naming convention from RFC2131.
Secondly, I guess the lease may not really be valid when the client
issues the DHCPREQUEST in the INIT-REBOOT state. It may have expired
(possibly short time ago) but the client will try to reclaim this lease
anyway, and maybe the server can still hand it out. So, it would be
probably better to say that

"There are scenarios in which a client connecting to a network remembers
previously allocated address, i.e. is in the INIT-REBOOT state."

or something like that.


4.4.1. Obtain temporary addresses

Some of my concerns sent in the previous review were not addressed. I
think I don't understand how the section about temporary addresses fits
into the principle guideline to randomize link layer addresses. In
particular, this section discusses replacing IAID to get the new
address, while preserving an old address. If the new address is
successfully assigned, the old address can be released or left to time
out. In any case, the client seems to be using the same MAC address
while this transition to the new IAID takes place, so the DHCP server
would be able to correlate the old address with the new address. Is this
the intent? Is it just giving the hint how to obtain IA_TA-like behavior
independently from the randomization of the MAC address?

In other words, if I am implementing a client with the anonymity profile
enabled, would I randomize MAC address, MAC address and IAID, or I'd
make it an option in the device?

Also, why is reference to the Section 4.4. specifically important:

"This, along with the mitigation technique discussed in Section 4.4,
will ensure that a client will get a new address that can be renewed...."
?

Randomizing the IAID doesn't imply randomizing MAC address, so I don't
understand why it has been mentioned here.

Marcin


On 02.09.2015 23:45, Bernie Volz (volz) wrote:
> Hi all,
> 
>  
> 
> This message starts the DHC Working Group Last Call to advance
> draft-ietf-dhc-anonymity-profile-03, Anonymity profile for DHCP clients,
> http://tools.ietf.org/html/draft-ietf-dhc-anonymity-profile-03. This
> document’s intended status is Standards Track.
> 
>  
> 
> Note: At present, there is 1 IPR against file against this document
> (http://datatracker.ietf.org/ipr/2654/).
> 
>  
> 
> This is a part of the WGLC of 3 documents
> (draft-ietf-dhc-dhcp-privacy-01,  draft-ietf-dhc-dhcpv6-privacy-01, and
> draft-ietf-dhc-anonymity-profile-03).
> 
>  
> 
> Please send your comments by September 22th, 2015. If you do not feel
> this  document should advance, please state your reasons why.
> 
>  
> 
> Bernie Volz is the assigned shepherd.
> 
>  
> 
> - Tomek & Bernie
> 
>  
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>