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

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 2 Sep 2015 21:45:30 +0000

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

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 22 Sep 2015 14:31:33 +0200

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.
> 
>  
> 
> 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.
> 
>  
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 22 Sep 2015 17:54:49 +0000

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. 

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

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

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:

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?"

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

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

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 22 Sep 2015 18:00:20 +0000

>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" <[email-masked]> wrote:

>>forward.
>Thanks for the comments. I thought that I applied your July 22
>suggestions, but obviously I missed some.
>
>>the client SHOULD
>>include
>>DHCPDISCOVER,
>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?
>
>>lease is still
>>issues the
>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?"
>
>>think I
>>would be
>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.
>
>>will ensure
>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
>
>

---

From: Marcin Siodelski <[email-masked]>
Date: Tue, 22 Sep 2015 20:23:20 +0200

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

> 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 statefu…

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.

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

Marcin