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

From: Martin Duke via Datatracker <[email-masked]>
Date: Wed, 29 Jul 2020 16:01:43 -0700

Martin Duke has entered the following ballot position for
draft-ietf-dhc-v6only-05: Discuss

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-v6only/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Not so much an objection, but a question:

What would happen if, in response to a DHCPDISCOVER with the IPv6-only offer,
an attacker spoofed a DHCPOFFER with this option and a V6ONLY_WAIT value of
UINT32_MAX, when in fact there was no NAT64, or v6 capability, at all? Would
the very long timeout amplify existing DoS attacks on DHCP?

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

This seems like an important stepping stone to v6 adoption, so thanks.

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?

Sec 3.3
"If the client then
   issues a DHCPREQUEST for the address, the server MUST process it per
   [RFC2131], including replying with a DHCPACK for the address if in
   the meantime it has not been committed to another client."

What if it HAS been committed to another client? What then?

---

From: Jen Linkova <[email-masked]>
Date: Thu, 30 Jul 2020 11:30:59 +1000

Hi Martin,
Thanks for reviewing the document!

You are right, the attacker can disable DHCP for a longer period and
recovery would require disconnecting the client and reconnecting it
back.
However I suspect the attacker/a rogue DHCP server achieves more or
less the same result by offering a very long lease time (which is also
4 bytes, afair).

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."

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).

> What if it HAS been committed to another client? What then?

Our draft does not modify that behaviour.  Whatever the server is
doing in such a situation w/o v6-only option being requested. RFC2131
has that scenario covered:
"If the selected server is unable to satisfy the DHCPREQUEST message
     (e.g., the requested network address has been allocated), the
     server SHOULD respond with a DHCPNAK message."

--
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Thu, 30 Jul 2020 13:47:21 +1000

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

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

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

---

From: "Ms. Li HUANG" <[email-masked]>
Date: Thu, 30 Jul 2020 16:29:43 +0800

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 <[email-masked]> wrote:

> > 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.
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 30 Jul 2020 19:41:38 +0900

Jen,

suggested text LGTM, suggestions inline.

On Thu, Jul 30, 2020 at 10:31 AM Jen Linkova <[email-masked]> wrote:

> However it should be noted that if the network does
> 0xffffffff.

Suggest "... can be executed by offering an invalid address and setting the
Lease Time option value field to 0xffffffff."

> The latter attack would also affect hosts without
> IPv6-only Preferred option support.

Suggest "...would affect all hosts, not just hosts that support the
IPv6-only Preferred option."

Cheers,
Lorenzo

---

From: Jen Linkova <[email-masked]>
Date: Thu, 30 Jul 2020 22:02:20 +1000

Ack, the Github version updated.

On Thu, Jul 30, 2020 at 8:41 PM Lorenzo Colitti <[email-masked]> wrote:
> Suggest "... can be executed by offering an invalid address and setting the Lease Time option value field to 0xffffffff."
>
>>
> Suggest "...would affect all hosts, not just hosts that support the IPv6-only Preferred option."
>
> Cheers,
> Lorenzo