Re: [dhcwg] Eric Rescorla's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Tue, 23 January 2018 00:14 UTC

Return-Path: <tomasz.mrugalski@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 E45D6127601; Mon, 22 Jan 2018 16:14:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 5ExE2_m-l7LF; Mon, 22 Jan 2018 16:14:14 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 CA0D2126BF6; Mon, 22 Jan 2018 16:14:13 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id g1so19504916wmg.2; Mon, 22 Jan 2018 16:14:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tUH5Fc/E6O//1+nds8allKkkAlolveS3MTxnbKmR51Y=; b=HUVrUcDkf8OtXBn+Gkf7TVqJMg5YftbDLwX1XIS75+dABqQ8hFRDC7Q1ipJEn9VUv/ 0UO/ZN5oHz2IEP9JCeCW9rzPYocDW1LVDxpwF30CffLl6BzFFXHMetvWNXG45f9l2q3V eTNsRvfiQbSTpvYXNWNhX21LidYZMedFeap0gAQQ6r23nt3sZX77RxsYEFu8fj2bWEar 4tHlJO6sMV3YJJ851aRoglk4ksfLsV+gMv1/CRa1YtvpABh9L03sc6+ZD4g7I1AnMKV4 RtLKXvZqHVIB2oLaUGCATOHPp09d8XjIFdLmHII2rkLBsW6chqSk12i1oUIEWHOh+XAa 58pQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tUH5Fc/E6O//1+nds8allKkkAlolveS3MTxnbKmR51Y=; b=toAe/7FomGANnBybgdG6YWthJJvM6qbH+yYlXhI2ZxSZnFVBvmT8a7dR1HNPWYTFN3 +eMJS/x32EHYq9mycN/A8hkPEsMXskPygbxa/LMaxu0QwM4t1tfBHmosqiJ0ySYvS+oL fNojD1LbtA59n+ykHrKe6+SqzJHCY+dBqew1NpE2DaoYuEtl6oaaZm+IPDixeKyya4qP 8zlgQ8C9G693iHrrhR3yl+7bZiXrXyWuHfCDb2SycQXg9NBoZKBRpP4xIyoZSFQmeihE N3i0OUrRGKBLK7g0oKWzO4CS/z+Vmb7B12LkG2AH1N2jDgikFsZr6eNJvM+Q04Jc+Ars 3mww==
X-Gm-Message-State: AKwxytda3MtqiYPKe4zvgiWJIasmkdkToYwK6lC3GhK2wpiQAL0kYjy+ NAn3bafAevm80z+kJcJNpaCRzJoA
X-Google-Smtp-Source: AH8x226yt2s9pdqdLN5+OqndiGKmtBY+I8c8IDOKJe3ZZh8nZobA0lDH1xLGgU8oH9yJNLww4s8+OA==
X-Received: by 10.80.245.52 with SMTP id t49mr16500456edm.47.1516666451927; Mon, 22 Jan 2018 16:14:11 -0800 (PST)
Received: from [192.168.1.100] (109241079151.gdansk.vectranet.pl. [109.241.79.151]) by smtp.googlemail.com with ESMTPSA id i2sm11968975edf.90.2018.01.22.16.14.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 16:14:11 -0800 (PST)
To: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-dhc-rfc3315bis@ietf.org, Ralph Droms <rdroms.ietf@gmail.com>, dhc-chairs@ietf.org, dhcwg@ietf.org
References: <151656279222.3388.17356187412394517479.idtracker@ietfa.amsl.com>
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Message-ID: <85bba58c-e7ef-ce42-50a5-3ba83f2abba0@gmail.com>
Date: Tue, 23 Jan 2018 01:14:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <151656279222.3388.17356187412394517479.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/ufjZoSwKBfievRhtRtvGdBEZIAw>
Subject: Re: [dhcwg] Eric Rescorla's No Objection on draft-ietf-dhc-rfc3315bis-10: (with COMMENT)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 23 Jan 2018 00:14:16 -0000

On 01/21/18 20:26, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-dhc-rfc3315bis-10: No Objection
Hi Eric,

Thank you for your review and your favourable ballot. See my answers below.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Document: draft-ietf-dhc-rfc3315bis-10.txt
> 
> This document was quite clear and well written. A few small comments
> below.
> 
> It would have been easier for me to have a bit of intro about why
> both the 4-message and 2-message rapid commit exchanges exist
> and maybe some guidance about when to use each one.
How about this text being added early to Section 5.1:
  "It is sometimes desired to expedite the configuration process from
  typical four messages down to two. This may be desired for couple
  reasons. The first one is when there is only one server available
  on link and there is no expectation that a second server would become
  available. The second is when completing of the configuration process
  as quickly as possible is a priority."

> I am finding the guidance on DUIDs a bit confusing. Rather than
> having a bunch of constructions that produce variable length
> things that are intended to be unique, why not just take all
> those values and feed them into a hash function and then you
> could just have UUIDs?
I was not participating in the original discussion that led to this
decision back around 2002, but I can imagine there was a need to
generate unique identifiers by devices with various capabilities (thus
with/without timestamp variants). This concept predates usage of UUIDs
in IETF, which as far as I can tell was first mentioned in RFC4122.

Anyway, this part of the spec hasn't changed in bis. It would be
extremely difficult to make any changes as there are millions of devices
that already use those DUID types.

> I'm a little sad that the transaction ID is so short. This doesn't
> seem like really enough to provide uniqueness against guessing
> attacks.
This was never meant as protection, simply as a way to differentiate
between separate transactions that could be happening at the same time.
Even if the transaction was much larger, it is sent by the client to a
multicast address.

> We're trying to discourage HMAC-MD5. Do you have any way to
> transition to something stronger?
Am afraid not at this time. The whole WG seriously tried very hard, but
the draft-ietf-dhc-sedhcpv6 was abandoned at revision -21.

> The description of how to actually do replay detection seems pretty
> thin. Do you think more detail would be helpful here.
It would. How about this text added to the end of Section 20.3:

"The client that receives a message with RDM field set to 0x00 MUST
compare its replay detection field with the previous value sent by
the same server. If this is the first time a client sees Authentication
option sent by the server, it MUST record the replay detection value,
but otherwise skip the replay detection check.

The servers that support reconfigure mechanism MUST ensure the replay
detection value is retained after restarts. Failing to do that will
cause the clients to refuse reconfigure messages sent by the server,
effectively rendering the reconfigure mechanism useless."

> S 1.
>    DHCPv6 can also provide only other configuration options (i.e., no
>    addresses or prefixes).  That implies that the server does not have
> 
> Perhaps "DHCP can also be used just to provide..."
Sounds good.

> S 2.
> Nit: do you want to cite 8174.
Yes.

> S 4.2.
> When acronyms are used ahead of their definition, it would be good to
> expand them.
Ok, will do that.

> S 21.22.
> What is the part of the IPv6-prefix after prefix-length filled with?
> Does it matter?
Should be filled with zeros by sender and ignored by the receiver. Will
add a text that clarifies that.

Tomek