Re: [dhcwg] review of draft-ietf-dhc-sedhcpv6-02.txt

Sheng Jiang <jiangsheng@huawei.com> Mon, 16 June 2014 03:06 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 BF3351B29F7 for <dhcwg@ietfa.amsl.com>; Sun, 15 Jun 2014 20:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 TdRFyLhzs2_L for <dhcwg@ietfa.amsl.com>; Sun, 15 Jun 2014 20:06:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3571A0265 for <dhcwg@ietf.org>; Sun, 15 Jun 2014 20:06:57 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIL30957; Mon, 16 Jun 2014 03:06:55 +0000 (GMT)
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 16 Jun 2014 04:06:55 +0100
Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.03.0158.001; Mon, 16 Jun 2014 11:06:43 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: Francis Dupont <Francis.Dupont@fdupont.fr>, "dhcwg@ietf.org" <dhcwg@ietf.org>
Thread-Topic: [dhcwg] review of draft-ietf-dhc-sedhcpv6-02.txt
Thread-Index: AQHPhxHHDWmmVtn3xk6Y2sFvCvyQjptzBFBw
Date: Mon, 16 Jun 2014 03:06:43 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE8C3F8@nkgeml512-mbx.china.huawei.com>
References: <201406131413.s5DEDxGn042278@givry.fdupont.fr>
In-Reply-To: <201406131413.s5DEDxGn042278@givry.fdupont.fr>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/tb4LBcyDQpUKPjijwbcEXkZ6VG0
Subject: Re: [dhcwg] review of draft-ietf-dhc-sedhcpv6-02.txt
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: Mon, 16 Jun 2014 03:06:59 -0000

Hi, Francis,

Thanks so much for your review. We will address most of your comments in the next update. However, your proposed "drop the certificate option" is too magnificent, for which we need WG consensus to change it. There are some explanation and opinions from authors below.

>But my main concern is the applicability of the certificate stuff
>(*public key* certificate BTW). The issue is either the node has
>fully access to the PKI and a pointer (e.g., IKEv2 URI and hash)
>is simpler/better, or a mechanism has to provide the trust anchor,
>the certificate chain and crls, etc. It was done in SEND the (very)
>hard way...
>
>In the case of secure DHCPv6 IMHO it should be more efficient
>to postpone the certificate stuff, so I propose:
> - drop the certificate option

We fully agree the deployment of PKI is difficult. However, in the secure DHCPv6, the certificate is one of alternative mechanisms, parallel with leap of faith mode. The two modes provide different levels of security. They are complementary for each other. Furthermore, without the support a PKI, the certificates can also be used in the LoF mode. In any case, the deployment could choose only public key plus LoF mode, if PKI is too complicated for them. Therefore, we think keeping the possibility of certificate mode has more benefit than harm.

Best regards,

Sheng + Dacheng