Re: [dhcwg] draft-ietf-dhc-rfc3315bis-10 - FW: Additional comments

"Bernie Volz (volz)" <volz@cisco.com> Fri, 19 January 2018 21:01 UTC

Return-Path: <volz@cisco.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 1A6651289B0 for <dhcwg@ietfa.amsl.com>; Fri, 19 Jan 2018 13:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.528
X-Spam-Level:
X-Spam-Status: No, score=-14.528 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 r7ILjlFmOTNT for <dhcwg@ietfa.amsl.com>; Fri, 19 Jan 2018 13:01:43 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497C1126FB3 for <dhcwg@ietf.org>; Fri, 19 Jan 2018 13:01:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27672; q=dns/txt; s=iport; t=1516395703; x=1517605303; h=from:to:subject:date:message-id:mime-version; bh=5tyb6XCOIhnXx/iCchK52UtTcqXzLKaUx9Qio3DVFjI=; b=VNYAbCHpMqKws64EroxAZE220VZa+t/J4ovEyMxz/ow4UrI5TNd1GLui iUfrDX+N59I8j4ZZdDb9E9QZIc43yGW4c8bFmnMDp5sV+4F4oV6KhpWta 4+l04E01PiEvAqtX17pxVgBb1B49buMsurhXu2/fnbfVW6oWGqVKdHOUR Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AACZW2Ja/4cNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJKRzFmdCUCB4NWiiSOYIICgwdDk2iCFwojhElPAhoohCA/GAE?= =?us-ascii?q?BAQEBAQEBAWsohSMBAQUjCh4BIh0BCBECAgEBKAMCBCMNFAkJAQQTCIlHZBCwa?= =?us-ascii?q?YInhBABhhwBAQEBAQEBAQIBAQEBAQEBAQEfhEiCFYM+AYMugy8CAQGBTwEBCDw?= =?us-ascii?q?QgmGCZQWjdQKID4N8iUKUIZcRAhEZAYE7AQ8QOYFPbxU9gioJgkscgWd4AYogD?= =?us-ascii?q?xgEgQmBFwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,382,1511827200"; d="scan'208,217";a="127496900"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jan 2018 21:01:42 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w0JL1giY012813 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <dhcwg@ietf.org>; Fri, 19 Jan 2018 21:01:42 GMT
Received: from xch-aln-003.cisco.com (173.36.7.13) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 19 Jan 2018 15:01:41 -0600
Received: from xch-aln-003.cisco.com ([173.36.7.13]) by XCH-ALN-003.cisco.com ([173.36.7.13]) with mapi id 15.00.1320.000; Fri, 19 Jan 2018 15:01:41 -0600
From: "Bernie Volz (volz)" <volz@cisco.com>
To: "'dhcwg@ietf.org'" <dhcwg@ietf.org>
Thread-Topic: draft-ietf-dhc-rfc3315bis-10 - FW: Additional comments
Thread-Index: AdORZ9NZzUqQUvuER7OlpJxzAMnHkQAAMgrQ
Date: Fri, 19 Jan 2018 21:01:41 +0000
Message-ID: <e4362757ef984159ba103d63d680662d@XCH-ALN-003.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.98.1.196]
Content-Type: multipart/alternative; boundary="_000_e4362757ef984159ba103d63d680662dXCHALN003ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/thuHlhaXH4JAFptFKKa2xuR9hf8>
Subject: Re: [dhcwg] draft-ietf-dhc-rfc3315bis-10 - FW: Additional comments
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: Fri, 19 Jan 2018 21:01:46 -0000

Oops, didn’t realize that his main comments didn’t make it to the DHC WG mailing list.

See them at https://www.ietf.org/mail-archive/web/secdir/current/msg07810.html.


-       Bernie

From: Bernie Volz (volz)
Sent: Friday, January 19, 2018 3:58 PM
To: dhcwg@ietf.org
Subject: draft-ietf-dhc-rfc3315bis-10 - FW: Additional comments

Here’s a list of additional comments provided by Kyle Rose when he was reviewing draft-ietf-dhc-rfc3315bis-10.


-          Bernie

From: Kyle Rose [mailto:krose@krose.org]
Sent: Wednesday, January 17, 2018 4:41 PM
To: draft-ietf-dhc-rfc3315bis.all@ietf.org; The IESG <iesg@ietf.org>;
Subject: Additional comments

I produced the following comments during my Secdir last call review that are not directly related to Secdir responsibilities.

Main points:

11: Should there be stronger 2119-style normative language prohibiting entities from parsing the DUID?

17.2: "When a client sends a DHCP message for the purpose of prefix delegation, it SHOULD be sent on the interface associated with the upstream router (ISP network)." This seems insufficiently general. ISTM that the client MUST send a DHCP request for prefix delegation on an interface with a DHCP server that has the ability to delegate prefixes for the scope of access required by the clients that will be issued addresses in those subnets. If you have a machine that connects to both the internet and to a private network, as well as hosting LANs of its own, the prefixes you want to assign to those LANs depends on whether you want clients on those networks to access the internet or the private network or both.

18.2.9: The first and third bullets at the top of the section seem to be in direct contradiction.

18.2.11: "The likelihood of delayed and out of order delivery is small enough to be ignored." Transport people may take exception to this statement. It might be sufficient to say something about the assumptions around delayed and out-of-order delivery for UDP on real networks.

20.3: With regard to replay detection, some questions are left unanswered: (1) How long should uniqueness of a replay detection value be enforced by clients? (2) Relatedly, how do you deal with rollover in a monotonically-increasing counter with a fixed width? (3) Can the monotonically-increasing counter value be per-server or must it be shared?

21.14: "...or by having DHCP clients release unused leases using the Release message." How is this actionable? Client behavior is what it is. This should be a normative statement if we want it to be implemented.


Questions/Clarifications:

18: Is a relay with sufficient knowledge permitted to forward a client packet to only the server specified by the matching DUID?

18.2: "When possible, the client SHOULD use the best configuration available and continue to request the additional IAs in subsequent messages [RFC7550]." Took a quick look at 7550. Does this mean to wait until T1/T2 and not keep retrying for those IAs? (This might be implied by the preference for a single state machine, but it might also be interpreted as continuing to request those IAs, resetting T1 and T2 every time.)

18.3.2: "The server MUST NOT cache its responses." Why?

20.3: "...the replay detection field MUST be set to the value of a strictly monotonically increasing counter." Is this counter per-server?

22: What is the security relevance of "Networks configured with delegated prefixes should be configured to preclude intentional or inadvertent inappropriate advertisement of these prefixes"?


Nits:

IAADDR in the glossary is a forward reference to elsewhere in the document. Should a section link be specified here? It's possible there are other instances of this type of thing in the glossary.

Under "singleton option", "once as a the top-level option" is malformed. (The RFC editor will probably pick this stuff up, but no reason not to fix it now.)

5.2: The second paragraph seems to be both redundant (it immediately follows the section describing the interaction) and misplaced (it's under a section addressing specifically "Exchanges Involving Four Messages").

7.3: Under REPLY, should there be an "or" inserted in the list "Solicit, Request, Renew, Rebind"?

12.1: s/Each IA/Each such IA/. Without "such", this statement taken out of context would mean something very different.

12.2: Similarly, "A client must create at least one distinct IA_PD" seems like it should have language limiting the class of clients to those requesting prefix delegation. Should the "must" here then be "MUST"?

13.2: Is "Each IA_TA option contains at lease one temporary address..." supposed to be "at least"?

14: Does there need to be an informational reference for the OSI layer terminology used, or is that just considered common knowledge at this point?

16.3: s/does/do in the third bullet: "contents of the Client Identifier option do not match..." Similarly in 16.6, bullet 2.

18.2.4: Remove spurious "server. server."

18.2.10.1<http://18.2.10.1>: s/Sends a Request message if any of the IAs in the Reply message contains the NoBinding status code to the server that responded./Sends a Request message to the server that responded if any of the IAs in the Reply message contain the NoBinding status code./