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

["Ben Campbell" <[e-mail]>]

This all looks good to me, thanks!

On 24 Feb 2016, at 7:16, Tomek Mrugalski wrote:

> 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