Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 - Respond by Dec 2, 2013

Sheng Jiang <jiangsheng@huawei.com> Tue, 19 November 2013 03:28 UTC

Return-Path: <jiangsheng@huawei.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0041AEC10 for <dhcwg@ietfa.amsl.com>; Mon, 18 Nov 2013 19:28:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.725
X-Spam-Level:
X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham
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 6A09hhW05cqx for <dhcwg@ietfa.amsl.com>; Mon, 18 Nov 2013 19:28:22 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 22A4F1AEC0C for <dhcwg@ietf.org>; Mon, 18 Nov 2013 19:28:21 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAL21598; Tue, 19 Nov 2013 03:28:15 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 03:28:07 +0000
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 19 Nov 2013 03:28:12 +0000
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.51]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Tue, 19 Nov 2013 11:28:08 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: "Bernie Volz (volz)" <volz@cisco.com>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 - Respond by Dec 2, 2013
Thread-Index: Ac7kgW5Zu29batgdRjKYwweN6OdP2gAT6/uA
Date: Tue, 19 Nov 2013 03:28:08 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923ADB1C77@nkgeml512-mbx.china.huawei.com>
References: <489D13FBFA9B3E41812EA89F188F018E1AD98DE0@xmb-rcd-x04.cisco.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD98DE0@xmb-rcd-x04.cisco.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.145]
Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B923ADB1C77nkgeml512mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 - Respond by Dec 2, 2013
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 19 Nov 2013 03:28:25 -0000

I have reviewed this document. Overall, I support to advance this document. There are several comments that may help the author to improve the document.

A couple of statements regarding to RFC3315 is not exactly correct”

In section 3, “RFC3315 doesn’t explicitly describe how the relay  agent can find out it should send a message towards the server or  towards the client.”

And In section 4.1, RFC 3315 “doesn’t define what a valid message is.” (Section 15 of RFC 3315 has defined how to valid every known type message.)

I believe these are only description issues that can be addressed with small changes of text. RFC3315 has clearly define both relay behavior and validation for all known message type. If the authors clarify the abovementioned statements only in the sense of unknown message, then the statement could become correct.

The last paragraph of section 4.1, the authors state “Then the server knows  the relay agent doesn’t support the new message.” How? There is no mechanism for server to identify whether the relay agent support the new message or not. However, on other side,  the server does not need to know whether the relay agent support the new message or not.

In section 5, it could be better to clearly define whether discarding is silent or some notification behavior. I guess silent discarding is simplest.

In section 6, the authors claim the current server or clients are vulnerable by unknown messages. It is unclear why. Although the current DHCPv6 specification does not define the discard behavior for unknown messages. It is an obvious choice of implementers. Personally, I don’t think there is reality threat by unknown messages.

Other editorial comments:

There are a few places using abbreviation, such as it’s doesn’t. It is informal to have them in a RFC.

There are several places the authors used relay/relays, which should be relay agent/agents.

It should be consistent “to client”, “towards client” or “toward client”.

In section 6, “The same  problem may happen in current DHCPv4 and DHCPv6 practice where the  attacker has to construct the fake DHCP message with an known type  code.” I guess “has to” is a mistake.

Best regards,

Sheng

From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Bernie Volz (volz)
Sent: Tuesday, November 19, 2013 1:15 AM
To: dhcwg@ietf.org
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv6-unknown-msg-03 - Respond by Dec 2, 2013


Folks, the authors of draft-ietf-dhc-dhcpv6-unknown-msg-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-unknown-msg-03) believe it is ready for working group last call. Please review this draft and indicate whether or not you feel it is ready to be published. Your input is important! Please respond by Dec 2nd, 2013.



At the time of this writing, there is no IPR reported against this draft.



Thanks,


-        Tomek & Bernie