Subject: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-dhcpv6-privacy-04: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 17 Feb 2016 15:07:18 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-dhcpv6-privacy-04: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-privacy/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-2:
If this is strictly an analysis with no proposed solution, why does it
need 2119 keywords? Actually, I only found one MAY, and that seemed more
a statement of fact than a new requirement.

-5.6:
This seems to talk about pervasive monitoring in a very general sense.
Can you say something about how that specifically relates to dhcpv6?

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 24 Feb 2016 14:16:31 +0100

Oops, seems nobody answered this comment yet.

> draft-ietf-dhc-dhcpv6-privacy-04: Yes
2119 references removed, normative language removed (MAY is now lower case).

> Can you say something about how that specifically relates to dhcpv6?
Sure. Here's the proposed text for section 5.6. The first paragraph
comes from RFC7258 (this addressed a comment made earlier that suggested
to borrow the text directly rather than try to describe PM with our own
words). The last two paragraphs are new. Are they sufficient?

5.6.  Pervasive monitoring

   Pervasive Monitoring (PM) is widespread (and often covert)
   surveillance through intrusive gathering of protocol artefacts,
   including application content, or protocol metadata such as headers.
   Active or passive wiretaps and traffic analysis, (e.g., correlation,
   timing or measuring packet sizes), or subverting the cryptographic
   keys used to secure protocols can also be used as part of pervasive
   monitoring.  PM is distinguished by being indiscriminate and very
   large scale, rather than by introducing new types of technical
   compromise.  See [RFC7258] for a discussion about PM.

   In the DHCPv6 context, PM approach can be used to collect any
   identifiers discussed in Section 3.  DHCPv4 and DHCPv6 are especially
   susceptible as the initial message sent (SOLICIT in case of DHCPv6)
   is one of the very first packets sent when visiting a network.
   Furthermore, in certain cases this packet can be logged even on
   networks that do not support IPv6 (some implementations initiate
   DHCPv6 even without receiving RA with M or O bits set).  This may be
   an easily overlooked attack vector when IPv6-capable device connects
   to an IPv4 only network, gains only IPv4 connectivity, but still
   leaks its stable identifiers over DHCPv6.

   Using PM approach, attacks discussed in Sections 5.1, 5.2, 5.3, 5.4,
   5.5, 5.7, 5.8 and possibly 5.9 apply.

Once we sort out this last comment, I can upload -05 and it should be
ready to go.

Thanks,
Tomek

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 24 Feb 2016 09:10:09 -0600

This all looks good to me, thanks!