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

Jen Linkova <furry13@gmail.com> Thu, 30 July 2020 01:31 UTC

Return-Path: <furry13@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8F93A0B60; Wed, 29 Jul 2020 18:31:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMXAc2QLC4m7; Wed, 29 Jul 2020 18:31:11 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752953A092F; Wed, 29 Jul 2020 18:31:11 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id e13so24232341qkg.5; Wed, 29 Jul 2020 18:31:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EwySgjuDWus9dK9jJXEnNJV9jWrLl3qThPNIj7LC3Js=; b=Z/4Qz7OkIhPt1Lysy4AMQ86nEPkwDBdQUVozWwHZBKqojKNP8PvYa7q3pPUISkTITE Cdp+QbjI1MGGabctb7eEsbvRK5ZQdMWMb30k4SsI++JnD5cVeAalsdblsBBMM6G98Pgm AuGXYexIOHiz2lajpPzrTfXIhz31Q+wb8lPpYpJrASGsx/B1QEML8eWoaVP+slLxDGn6 3uR4VPyd7QFsoOXpuSpjU1yZWodKdycSJG4/MQobe4FW+dydC+kkNXUo9iB9BGM/W8EJ LEtzA0ITKa6jmOMVZ4Yv4B2WX9so3tnTBLDwWtLN819dIqyzY+79Llr65QRbKbAve/iy LKkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EwySgjuDWus9dK9jJXEnNJV9jWrLl3qThPNIj7LC3Js=; b=YXywbJhsUYB7cItMpD/1W8qISFFn0vXP8bzmmJ9WDeiPGlYTjfeSlrUqMGcWuMn/Rb /RE/CfB8C4X8la4ReLkxYfQv9daVSEY4GbQwDVqTn7elDtLJy2rJtiNIk5kr0gl+8+/g u5ZFD4kEE+2hq4vBBEXJpEiv0XptS5qicvXJcF96QZM5sUdUbRi5NKU4zV9U/j6v76O8 h/kunZmTIcZj4qyfmm+vm9IaMj26Quoikf9EijFGqSJzJ2137TOef5bfybO/2UGM0YGw 4A+X3l/dkVsd3wQy2ryrH6pjjwOOlK3fW4vVyEidgbUOZsr4VC6CuTSrHnMvJxmgzKjI yHZg==
X-Gm-Message-State: AOAM531nQ/mhhGd959uMB1fhboewM1lFhjlIi4ZE7iY984imY1pqHcMo 7pdJGh7QAuIgamVJf7VDpOK01SFYxPRdvWfOdPA=
X-Google-Smtp-Source: ABdhPJy0r0Y9LRbubrcItB3Yiz8nVpuipBVPTkjxx4ppk+TP1tAtQgCWxiD9uuTkQdAMlx4HdhqfZMFqzCI10JQTx4A=
X-Received: by 2002:a05:620a:a05:: with SMTP id i5mr20173580qka.444.1596072670418; Wed, 29 Jul 2020 18:31:10 -0700 (PDT)
MIME-Version: 1.0
References: <159606370302.11342.6386305944714261698@ietfa.amsl.com>
In-Reply-To: <159606370302.11342.6386305944714261698@ietfa.amsl.com>
From: Jen Linkova <furry13@gmail.com>
Date: Thu, 30 Jul 2020 11:30:59 +1000
Message-ID: <CAFU7BATqgZBJs5MaE-C9b6N28=bFS1m4rJQxpVEYX3y29NOFRg@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dhc-v6only@ietf.org, "Bernie Volz (volz)" <volz@cisco.com>, dhcwg@ietf.org, dhc-chairs@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/D4pyLR2THFtNKp-0tPh-yDxDTnE>
Subject: Re: [dhcwg] Martin Duke's Discuss on draft-ietf-dhc-v6only-05: (with DISCUSS and COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 01:31:13 -0000

Hi Martin,
Thanks for reviewing the document!

On Thu, Jul 30, 2020 at 9:01 AM Martin Duke via Datatracker
<noreply@ietf.org> wrote:
> ----------------------------------------------------------------------
> 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?

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


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

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

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

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