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

Marcin Siodelski <> Tue, 22 September 2015 18:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4E811A92E6 for <>; Tue, 22 Sep 2015 11:23:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4_MHKa1P9wlb for <>; Tue, 22 Sep 2015 11:23:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FD151A908A for <>; Tue, 22 Sep 2015 11:23:25 -0700 (PDT)
Received: by lamp12 with SMTP id p12so22568706lam.0 for <>; Tue, 22 Sep 2015 11:23:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=QX+h9vEGsrXINo44mZga/Sd3lDgxN+7N+92xJG6U4OA=; b=gwwK/J6QVScJWSXAwbg+NlP8i4V7Rc6kzdqwQ7JZNBAccZJeX9s4X+kZhLr4mgiqUb RzxUH0nEVNEgpy5EKvyAC59VcY38trM2ipcrK2GnH5ZF6lHvloHWdmOlgBVFZy5xoN4F v1ILt4U6U860svEJlXtQP9e+VJd1wug1xqszmW0ZZ6Y+J02CamZpcPkIkwgBpaoGeuQb 8EImTrThU2uY0XPld/bv11KWQLJ1uIlNxHPPT8ZVhZr6KhWJl0LPytpiUTQ2bg74sQ4z 4S3H4VdsNzcxB/oGdqqdZ1IpyqpAaijAZfa5reBbsnUSMyNrFt5zvkDaY6qbHAhPi9FG jhvQ==
X-Received: by with SMTP id uq12mr10314918lac.35.1442946203355; Tue, 22 Sep 2015 11:23:23 -0700 (PDT)
Received: from MacBook-Pro-Marcin.local ( []) by with ESMTPSA id g141sm185063lfe.38.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2015 11:23:22 -0700 (PDT)
To: Christian Huitema <>, "Bernie Volz (volz)" <>, "" <>
References: <> <> <>
From: Marcin Siodelski <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 22 Sep 2015 20:23:20 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-anonymity-profile-03 - Respond by Sept. 22, 2015
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Sep 2015 18:23:28 -0000

On 22.09.2015 19:54, Christian Huitema 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
>> 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?"

I think it does, if the client doesn't have means to determine, or
doesn't determine that it is connecting to a different AP, it would
likely do INIT-REBOOT thing.

You could drop the "INIT-REBOOT", if you like, in my proposed text but
the rest is more accurate than what appears in the draft.

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

It doesn't really answer my question, Christian. It is very good that
the draft is based on the field experience. But lack of the field
experience in some area doesn't mean we leave it matter open or
underspecified in the draft.

This whole section about temporary addresses somehow doesn't fit into
the rest of the document, IMO. And, it seems it is not even necessary
given that you didn't bother to implement it. So why is this actually here?

If we envisage that it may  be useful to keep it in this draft it should
be made clear how this corresponds to the basic mode of operation when
the anonymity profile is enabled, i.e. when MAC address is randomized.

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

But section 4.4. talks about not using the same server identifier that
was used when the previous MAC address was in use. Why does it matter in
the context of IAID randomization?