Re: [dhcwg] Martin Duke's Discuss on draft-ietf-dhc-v6only-05: (with DISCUSS and COMMENT)

[Jen Linkova <[e-mail]>]

On Thu, Jul 30, 2020 at 1:09 PM Martin Duke <[e-mail]> wrote:

>> How about we change the first paragraph of the Security Considerations
>> (https://tools.ietf.org/html/draft-ietf-dhc-v6only-05#section-6)  to:
>>
>> "An attacker might send a spoofed DHCPOFFER containing IPv6-only
>> Preferred option with the value field set to 0xffffffff, disabling
>> DHCPv4 on clients supporting the option. If the network is IPv4-only
>> such clients would lose connectivity, while on a dual-stack network
>> without NAT64 service only connectivity to IPv4-only destinations
>> would be affected. The recovery would require triggering a network
>> attachment event. However it should be noted that if the network does
>> not provide protection from a rogue DHCPv4 server the similar attack
>> vector can be executed by setting the Lease Time option value field to
>> 0xffffffff. The latter attack would also affect hosts without
>> IPv6-only Preferred option support. Therefore the security measures
>> against rogue DHCPv4 servers would be sufficient to prevent the
>> attacks specific to IPv6-only Preferred option."
>
>
> I would be satisfied with that additional text to close the DISCUSS.

Great, the text above will be added to -06 which I'll submit close to
the next Telechat date so more feedback could be incorporated.

>> > Sec 3.1 In client-generated messages, what is in the "Value field"? I presume
>> > this is one of those "client MUST set to zero and server MUST ignore" cases?
>>
>> The client does not send the full option. The client includes the
>> option code into the Parameter Request List option (see
>> https://tools.ietf.org/html/draft-ietf-dhc-v6only-05#section-3.2).
>>
>
> Oh wow, that is very subtly worded so I totally missed that. Sorry! If this is very much the pattern for other DHCP options (client uses a code, server has a full option) then carry on; if it's not the pattern, a little text in version 3.1 that only servers send this would be helpful.

I've updated the Code field description in Section 3.1 with the following text:
"The client includes the Code in the Parameter Request List in
DHCPDISCOVER and DHCPREQUEST messages as described in Section 3.2."

I hope this text makes it more explicit that the client is not sending
the full option.

-- 
SY, Jen Linkova aka Furry