Re: [dhcwg] [Technical Errata Reported] RFC8415 (6269)

"Bernie Volz (volz)" <volz@cisco.com> Mon, 31 August 2020 14:46 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 1377E3A143A for <dhcwg@ietfa.amsl.com>; Mon, 31 Aug 2020 07:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 header.b=NjPEJcdc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=C/MyFKaf
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 64EaPzfBWcZj for <dhcwg@ietfa.amsl.com>; Mon, 31 Aug 2020 07:46:31 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A343A13E1 for <dhcwg@ietf.org>; Mon, 31 Aug 2020 07:46:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29928; q=dns/txt; s=iport; t=1598885191; x=1600094791; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XaU1G1w9A2HwM5YFylMM8btOMYhsEAIeJmf7GEt1VNI=; b=NjPEJcdcypWx4DNK/JyRH0TOxqBFK6qxStsVgwtVmvG2Pc9Vl3R5SmWh jv1TTZGD8yMRr3XUPsF8JmnixwAMgL1tTTxAMaUj1FFjhIzAglURod1H8 waXHhw48w5SHSytyhiYa1bYitD76/IBWI2vzzQw0aRqaNRAcbyKrOLjDR I=;
IronPort-PHdr: =?us-ascii?q?9a23=3A+amX+h++U9cuIf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZhCN//tmyVLFXJnc8bRDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGAsj1IlDeo2G193gVAB?= =?us-ascii?q?qsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKAADIDE1f/5NdJa1fDg4BAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBgXYHAQELAYEiLyMuB3BYLywKhC6DRgOEWIkegQKJCY5mgS4?= =?us-ascii?q?UgREDVQsBAQEMAQElCAIEAQGETAIXgjMCJDQJDgIDAQELAQEFAQEBAgEGBG2?= =?us-ascii?q?FXAyFcgEBAQQSEQoTAQE3AQsEAgEIEQQBASsCAgIfER0IAgQBDQUIGoMFgX5?= =?us-ascii?q?NAy4BDqVvAoE5iGF2gTKDAQEBBYEzAYQPDQuCEAMGgTgBgnCDZYEChU0bggC?= =?us-ascii?q?BEUOCGDU+gQSBFkICgSEmGhWDADOCLY99J4J3hmqDIohLkCtRCoJliGiMRoU?= =?us-ascii?q?lgwmJb5NeklGBbYhhgmeSIgIEAgQFAg4BAQWBVDqBV3AVGoJWAQEyUBcCDY4?= =?us-ascii?q?fDBeDToUUhQQFATh0NwIGAQkBAQMJfI8VAYEQAQE?=
X-IronPort-AV: E=Sophos;i="5.76,376,1592870400"; d="scan'208,217";a="553460914"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Aug 2020 14:46:30 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 07VEkUEK025775 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 31 Aug 2020 14:46:30 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 Aug 2020 09:46:30 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 31 Aug 2020 09:46:29 -0500
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 31 Aug 2020 09:46:29 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g8hRXb9x3+o1JYIwd46fEojhBotNJZ9yvHO1lDKLhyWQvwi2IHOi05ECmgQboI5SXJWprVGb9vFYLN0cU9ESJQKa0ydtONpne54X/oz8Owbc3B21998de+ff1qv+o8PCy5QTC1k/ocncFhvF/Yye3Sjrw1pt1XH0WI/YjsItWRjgI6y8pumPUgUd5PGICdP3vbm+/wEtDRD7z1M5dXZyQO2/8PCno0a4vvBl6E1l72f/ZqJGSh64fX+5nfVc/x188hylMzOZiSRhl7OXSUeb9RoZyCYUuU/5xzzaoXI15jSIqJd/OFR/f1FJriHCJOmn5sIyQjeiuGcgoUb3UB9wtg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XaU1G1w9A2HwM5YFylMM8btOMYhsEAIeJmf7GEt1VNI=; b=oaz/ElE34LQIgjG19aMIlOJy2uE8KyAhdifMY4iJBQTPxXdOd1XMVSNmvbgzCSEpb8KUiz0IuBSlS3m3siSJ0mh1AhmqYXtpU+oMRBq+DI4jUM2T/Lc/aT/be4L4Ytkwua2Y6a+iWccLkvdWw3jLT2T/dQM/0q4NHh1ya4K9g42skqPRmVsp/4gC1+0rkoT44lkvTyzwWLA3I/GkAk5OfAI5ywzdQ42d9aRqAORiYalAlqTVifr36vuSi19QEYjemwYPTFfzNIZ7vYYHb8sA/TH3a6vUh22SKA3S56Lpi4u9sV1/qdezdKEYfAjnq9aVInWTpPy3pJb+fVAnw2hSXw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XaU1G1w9A2HwM5YFylMM8btOMYhsEAIeJmf7GEt1VNI=; b=C/MyFKafEA9GRxEoLIEtyf1RS4kzXgzwtjHF+L7jYUAEhZfQxs1PCJsKR8p87wzlQKqb0JBEBWp0URqR7Drb/ca4ILMjcg8G0UMUMM5ybVH6ioxunlCkQ9iVb3g30eTmNI6AOyLispXJ7FsNhhvlDzhR5ZgjpGPenBKfsKC7Swc=
Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN6PR11MB1348.namprd11.prod.outlook.com (2603:10b6:404:46::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.21; Mon, 31 Aug 2020 14:46:28 +0000
Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::4ced:474b:c85e:9533]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::4ced:474b:c85e:9533%7]) with mapi id 15.20.3326.025; Mon, 31 Aug 2020 14:46:28 +0000
From: "Bernie Volz (volz)" <volz@cisco.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, "tomasz.mrugalski@gmail.com" <tomasz.mrugalski@gmail.com>, "msiodelski@gmail.com" <msiodelski@gmail.com>, "Andrew Yourtchenko (ayourtch)" <ayourtch@cisco.com>, "mcr+ietf@sandelman.ca" <mcr+ietf@sandelman.ca>, "jiangsheng@huawei.com" <jiangsheng@huawei.com>, "mellon@fugue.com" <mellon@fugue.com>, "twinters@iol.unh.edu" <twinters@iol.unh.edu>, "ek.ietf@gmail.com" <ek.ietf@gmail.com>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, "tim@qacafe.com" <tim@qacafe.com>
CC: "fhamme@united-internet.de" <fhamme@united-internet.de>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [Technical Errata Reported] RFC8415 (6269)
Thread-Index: AQHWfuTDwe7g55U7ukqqeAg+7mAHd6lSRS5Q
Date: Mon, 31 Aug 2020 14:46:28 +0000
Message-ID: <BN7PR11MB2547CB85EBCF595FEE42A340CF510@BN7PR11MB2547.namprd11.prod.outlook.com>
References: <20200830154615.6CECEF4076B@rfc-editor.org>
In-Reply-To: <20200830154615.6CECEF4076B@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: rfc-editor.org; dkim=none (message not signed) header.d=none;rfc-editor.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [24.233.121.124]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 93a3bbdc-3afd-4373-08ae-08d84dbca4ae
x-ms-traffictypediagnostic: BN6PR11MB1348:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BN6PR11MB1348BDDBE17621BECBBD8AE9CF510@BN6PR11MB1348.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: pj5/Fes61yqVT5LQkZXGjxulydtQXUu+hh4Gdt59bHyvO6sPC5Y93AhXBQvro37kaCL//XmsTX24jJUxtvdm2aXqFBPQoltwmZ2vx2ssUp+AuaomFv/9u7LBiSLaw0i5sPwE5ZXnZgI4BKyqELmTu7DM9RuDkSe08hjQZWZfPGE+X5QdAeWNv/64gqY/YaMV2BITyGQsnP/Bsxey7HXDqnpXpSMDFC/5D+R4IKZ5DeYLmZYBfs4tNZEr07nunybRfnXdR+ZsBppQE2PAovMcsZHQRwdJnkw+htHW0GxTeuYXk+u3e95Fr72w65MvNXdVPy5Ln6x2QS5F30ZAl5dx+cpXO81VDT4vpeg5TWqAx19lBXv3gj+ZpDxX/W+wDN6edVx3reOVvAh/xKeIesdT3v5P/4hqhs85NIIr90XQ22k12dj8YAsogf7KT7d9Uv0d
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(52536014)(86362001)(54906003)(110136005)(66946007)(64756008)(55016002)(9686003)(66446008)(66556008)(66476007)(71200400001)(8676002)(76116006)(316002)(2906002)(8936002)(5660300002)(966005)(66574015)(7696005)(7416002)(33656002)(4326008)(186003)(83380400001)(26005)(478600001)(53546011)(6506007)(921003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: PUc5RftHmklc5J9L5XykaPoACA67bFKp1WyOp5ImF8mGV0FRuQ5tz8HW2BP9AYUC2t07tp91L/AbjfutkN5xF0gjfPcp/x5JFrK+0jU6WaHZmlJdgMdC7E6hcguHKNggObExWB5FH7B2cYBvB3ZUwC5C9+QQbR1tobFa6Ok8GWkcMjb0yDgHZQEbmxnUE6lMI+rzLE6Oy1TEZG8SNeCV+02mw4lqK8SIhvOWGPqG7xUleDylxK1+ZDmOTR8GzrElZc6lPGu6ZM5vlEtshd782yGNkHNjwDhQnKaUHI1B9HVz3oQtSgyTTkg1/RAUvi4uMROKJpTkw8GhIWvjsCrzayswUrNuz1GKKgX37UErsmcYfebolWTBODMHtoBgH8EC0oIe1M7T3/y4TaVBNuu5w+cOGvconr/f4a2TwURs9DftBJKgTJVWhm/7wxB+ZCqmdnqMQSrdP8odXQIv8eeILwwRTrqgoS9R9gy0ukZr4uDFW27JWkDVqCA8V+2XEGuYz/nKdqSEFPn8fe6TTA2vS9pU4Y4OCdWL96jnOym0nUz2oNaT1xO0oAh6/hAebEo+96dUdWuxid99tCpbFQlL5aje/BmExn0/UHQEsRJBagMYU2wkyFUFu+6RVVkP+IsrGEdea3lHtZbaLjgqjclPaQ==
Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2547CB85EBCF595FEE42A340CF510BN7PR11MB2547namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2547.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 93a3bbdc-3afd-4373-08ae-08d84dbca4ae
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2020 14:46:28.2665 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: E7srZqwRQZ3Nm0yw7J9u2PPldwzzXYZRN+mWjCYGgnN8elTDgonGjh48WUaIN4o3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1348
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/IS955z1mhCjGuuWC4HCMkS75N2k>
X-Mailman-Approved-At: Mon, 31 Aug 2020 07:47:14 -0700
Subject: Re: [dhcwg] [Technical Errata Reported] RFC8415 (6269)
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: Mon, 31 Aug 2020 14:46:34 -0000

Hi:



It does look like the Information-Request is permitted to be unicast.



However, whether the Server Unicast is allowed in a Reconfigure itself is NOT specified. And, section 18.3.11 specifically states:



   The server MUST NOT include any other options in the Reconfigure

   message, except as specifically allowed in the definition of

   individual options.



And, the Server Unicast option text says nothing about this being allowed in a Reconfigure. (Perhaps there is text elsewhere that I missed.) So, I think Appendix B is correct (i.e., it does not allow a Server-Unicast option in a Reconfigure). Also, this would of course only apply to Renew and Information-Request (for a Reconfigure if it was allowed). Note: This does not prevent a previous exchange that provided the Server-Unicast from allowing the Renew or Information-Request triggered by a Reconfigure to be unicast by the client.





The following corrections are OK:



section 16:

"A server MUST discard any Solicit, Confirm, or Rebind messages it receives with a Layer 3 unicast destination address." (i.e., remove Information-Request)



section 18.2:

"If the client has a source address of sufficient scope that can be used by the server as a return address and the client has received a Server Unicast option (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, Decline, and Information-request messages to the server." (i.e., add Information-Request)



Note: Unicasting the Information-Request does create a condition where a client might fail to update its configuration if the target server is down. The reason the Request, Renew, Release, and Decline were allowed to use unicast was because these were targeted for a single server anyway and it optimized that communication (and reduced impact on other DHCPv6 servers that might receive and discard these packets because the Server Identifier did not match). I personally would have little issue if we decided the Information Request if it did not contain a Server Identifier option MUST NOT be unicast – the only time that the Server Identifier Option is explicitly included is in response to a Reconfigure. Again, this would be in my understanding of the spirit of when server unicast makes sense. So, if we go with that, the corrections would be:



section 16:

"A server MUST discard any Solicit, Confirm, Rebind, or Information-request (which does not contain a Server Identifier option (see Section 21.3)) messages it receives with a Layer 3 unicast destination address.



section 18.2:

"If the client has a source address of sufficient scope that can be used by the server as a return address and the client has received a Server Unicast option (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, Decline, and Information-request (only if it contains a Server Identifier option (see Section 21.3)) messages to the server."



I hope my suggested text makes it clear that this Server Identifier option only applies to Information-request.





While we could debate whether to allow Server Unicast option in a Reconfigure message itself, I think it best not to do this as it could be a security risk (though perhaps it is marginal if the attacker already knows the nonce). But that would be a change over the existing specification as best I can determine.



  *   Bernie



-----Original Message-----
From: RFC Errata System <rfc-editor@rfc-editor.org>
Sent: Sunday, August 30, 2020 11:46 AM
To: tomasz.mrugalski@gmail.com; msiodelski@gmail.com; Bernie Volz (volz) <volz@cisco.com>om>; Andrew Yourtchenko (ayourtch) <ayourtch@cisco.com>om>; mcr+ietf@sandelman.ca; jiangsheng@huawei.com; mellon@fugue.com; twinters@iol.unh.edu; ek.ietf@gmail.com; Eric Vyncke (evyncke) <evyncke@cisco.com>om>; Bernie Volz (volz) <volz@cisco.com>om>; tim@qacafe.com
Cc: fhamme@united-internet.de; dhcwg@ietf.org; rfc-editor@rfc-editor.org
Subject: [Technical Errata Reported] RFC8415 (6269)



The following errata report has been submitted for RFC8415, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)".



--------------------------------------

You may review the report below and at:

https://www.rfc-editor.org/errata/eid6269



--------------------------------------

Type: Technical

Reported by: Felix Hamme <fhamme@united-internet.de>



Section: GLOBAL



Original Text

-------------

section 16:

"A server MUST discard any Solicit, Confirm, Rebind, or Information-request messages it receives with a Layer 3 unicast destination address."



section 18.2:

"If the client has a source address of sufficient scope that can be used by the server as a return address and the client has received a Server Unicast option (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, and Decline messages to the server."





Appendix B does not permit a Server Unicast option in a Reconfigure message.



Corrected Text

--------------

section 16:

"A server MUST discard any Solicit, Confirm, or Rebind messages it receives with a Layer 3 unicast destination address."



section 18.2:

"If the client has a source address of sufficient scope that can be used by the server as a return address and the client has received a Server Unicast option (see Section 21.12) from the server, the client SHOULD unicast any Request, Renew, Release, Decline, and Information-request messages to the server."



Appendix B permits a Server Unicast option in a Reconfigure message.



Notes

-----

Section 18.4 allows transmission of Information-request messages with a unicast destination address, if the client received a message with Server Unicast option. (See also https://mailarchive.ietf.org/arch/msg/dhcwg/x80cmfTN8fpRViiN_RHNXes-zVg/)



Instructions:

-------------

This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary.



--------------------------------------

RFC8415 (draft-ietf-dhc-rfc3315bis-13)

--------------------------------------

Title               : Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

Publication Date    : November 2018

Author(s)           : T. Mrugalski, M. Siodelski, B. Volz, A. Yourtchenko, M. Richardson, S. Jiang, T. Lemon, T. Winters

Category            : PROPOSED STANDARD

Source              : Dynamic Host Configuration

Area                : Internet

Stream              : IETF

Verifying Party     : IESG