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

["Bernie Volz (volz)" <[e-mail]>]

>I have no problem applying these changes, but
>I have a process question for Bernie. Do we
>want to apply changes before or after the
>WGLC concludes?


As comments are ideally supposed to be in by end of today (for anywhere on
Earth I assume), there isn’t much time left and starting on an update is
fine (I would wait to publish until tomorrow at the minimum).

It is always possible that more comments may arrive “later”, but that will
likely happen during final shepherd review, AD review, and IESG review
anyway.

- Bernie


On 9/22/15, 1:54 PM, "Christian Huitema" <[e-mail]> wrote:

>On Tuesday, September 22, 2015 5:32 AM, Marcin Siodelski wrote:
>> 
>> 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.
>
>Thanks for the comments. I thought that I applied your July 22
>suggestions, but obviously I missed some.
>
>> 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.
>
>I have no problem applying these changes, but I have a process question
>for Bernie. Do we want to apply changes before or after the WGLC
>concludes?
>
>> 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."
>
>We can certainly replace the current text:
>
>"There are scenarios in which a client connects to a network when a lease
>is still valid".
>
>By Marcin's suggested text:
>
>"There are scenarios in which a client connecting to a network remembers
>previously allocated address, i.e. is in the INIT-REBOOT state."
>
>Unless there are objections. Marcin, does the INIT-REBOOT use case covers
>the case of "Wi-Fi roaming to a different AP in the same network?"
>
>> 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?
>	
>For "normal" addresses, the behavior is clear: random MAC, MAC dependent
>DUID, random IAID, new addresses that cannot be traced to a previous
>connection with a different MAC. This is what we have implemented.
>
>I must say that our team did not implement the temporary address section
>of the draft. When it comes to temporary addresses, we only have
>experience with the SLAAC + DHCPv6 INFORM, not with stateful DHCPv6.
>
>> 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.
>
>The IAID is an identifier, or can be used as an identifier. So it is
>important to prevent usage of the IAID for correlating two different MAC
>Addresses used in two different sessions.
>
>-- Christian Huitema
>
>