Re: [dhcwg] WGLC on draft-ietf-dhc-dhcp-privacy-01 - Respond by Sept. 22, 2015

[Marcin Siodelski <[e-mail]>]

I have read this document and I support advancing it in general, but
this document (as well as the companion v6 document) requires another
revision which corrects some of the issues (mostly nits).

I have similar comments about typos and some little errors in the text,
which I already mentioned for the companion DHCPv6 document. It would be
best to make the proof reading of the whole document and correcting
these errors before submitting it to IESG, to avoid the concerns about
lack of diligence.

Some other comments follow...


3.2. Address Fields & Options

OLD:
"The 'yiaddr' field [RFC2131] in DHCP message is used to allocate
   address from the server to the client."

NEW:
The 'yiaddr' field [RFC2131] in DHCP message is used to convey allocated
address  from the server to the client.


3.3. Client FQDN Option

" ... with the associated AAAA and PTR RRs." Did you mean A rather than
AAAA?

3.7.

"   After the relevant DHCP exchanges have taken place, the location
   information is stored on the end device rather than somewhere else,
   where retrieving it might be difficult in practice."

Similar comments as for the DHCPv6 document:
- what is end device?
- what is somewhere else?
- retrieving? you mean by an attacker who want to obtain sensitive
information about the client?

3.8.

"   The Client System Architecture Type Option [RFC4578] is used by DHCP
   client to send a list of supported architecture types to the DHCP
   server.  It is used to provide configuration information for a node
   that must be booted using the network rather than from local storage.
"

This option is not used to provide configuration information but it is
rather sent by the client to ask for the specific configuration conveyed
in different options. no?

4.

"   This section describes available DHCP mechanisms that one can use to
   protect or enhance one's privacy."

I don't think it is really true for this section. It rather describes
the mechanism that makes the client vulnerable to some sort of attacks,
rather than to protect.

Marcin


On 16.09.2015 20:45, Tomek Mrugalski wrote:
> With my co-chair hat off: I think the problem of DHCP privacy is
> important and DHC should publish problem analysis document such as this
> one. Therefore I support this document moving forward.
> 
> Disclaimer: I'm a co-author of this draft.
> 
> With my co-chair back on, I'd like to remind people that while this
> document has been presented during DHC meetings several times and always
> had favourable reception, the continuous support for it is not implied.
> It is really helpful if you could clearly say that you support this
> document (or state your objections if you don't). Doing a simple +1 is
> useful, doing a thorough review is better.
> 
> Tomek
> 
> On 02.09.2015 23:44, Bernie Volz (volz) wrote:
>> This message starts the DHC Working Group Last Call to advance
>> draft-ietf-dhc-dhcp-privacy-01, Privacy considerations for DHCPv4  -- 
>> http://tools.ietf.org/html/draft-ietf-dhc-dhcp-privacy-01. This
>> document’s intended status is Informational. At present, there is no IPR
>> file against this document.
>>
>> 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
>