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

July 30 2020  S8

ipv6 only at changed , or perhaps dynamically mac alternative status, how
the current dhcpv6 workaround ?

Example 2019 to 2020 ipcfg has had 2 lladd defaulted gateway on the
endpoint after the modem.isp which is suspected copying external
route_device mac interface, included the modem device supplier and mim...

ISP, DEVICE SUPPLIERS ...NONE WARRANTY UNIQUE MAC.INT TIME, HOW TO MOVE IN
IPv6 SECURE ENV.?

Sincerely
Li  HUANG

On Thu, Jul 30, 2020, 11:47 Jen Linkova <furry13@gmail.com> wrote:

> On Thu, Jul 30, 2020 at 1:09 PM Martin Duke <martin.h.duke@gmail.com>
> 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
>
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg
>