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

[Tomek Mrugalski <[e-mail]>]

Oops, seems nobody answered this comment yet.

On 18.02.2016 00:07, Ben Campbell wrote:
> Ben Campbell has entered the following ballot position for
> draft-ietf-dhc-dhcpv6-privacy-04: Yes
> ----------------------------------------------------------------------
> 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.
2119 references removed, normative language removed (MAY is now lower case).

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