Re: [CGA-EXT] [dhcwg] Follow up request for review ofdraft-ietf-csi-dhcpv6-cga-ps

Sheng Jiang <shengjiang@huawei.com> Wed, 15 September 2010 01:47 UTC

Return-Path: <shengjiang@huawei.com>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6517D3A6846; Tue, 14 Sep 2010 18:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.758
X-Spam-Level:
X-Spam-Status: No, score=-0.758 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm3JsMTAjL63; Tue, 14 Sep 2010 18:46:59 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 17B793A6838; Tue, 14 Sep 2010 18:46:59 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8R008W6MAQGK@szxga01-in.huawei.com>; Wed, 15 Sep 2010 09:47:14 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8R00DNXMAQ0S@szxga01-in.huawei.com>; Wed, 15 Sep 2010 09:47:14 +0800 (CST)
Received: from j66104a ([10.110.98.171]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8R0090OMAPR3@szxml06-in.huawei.com>; Wed, 15 Sep 2010 09:47:14 +0800 (CST)
Date: Wed, 15 Sep 2010 09:47:13 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <A19EC513-6C71-467C-A447-83C5FE600BC2@nominum.com>
To: 'Ted Lemon' <Ted.Lemon@nominum.com>, 'Tony Cheneau' <tony.cheneau@it-sudparis.eu>
Message-id: <003201cb5477$eba4d240$ab626e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Thread-index: ActUYZKz2XVmP9e3Qwij1kNQqR6WUAAEpgQg
Cc: dhcwg@ietf.org, cga-ext@ietf.org, 'Droms' <rdroms.ietf@gmail.com>, Ralph@core3.amsl.com
Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review ofdraft-ietf-csi-dhcpv6-cga-ps
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Sep 2010 01:47:00 -0000

Hi, Ted,

There are actually two very different concerns you have. I reply below. 

Before that, I would like to state: as an informational document, draft-ietf-csi-dhcpv6-cga-ps aims
to analyze the all possible interactions between cga and dhcpv6. Whether these possibilities are
going to be defined as actual solutions in the future, it is another matter. In this draft, all we
say is there are such possibilities, their benefits and issues  (if you want, we can put more
analysis regarding to potential issues of this possibility). You may notice in this 04 version, we
have removed "Solution Requests" charpter, which was in previous version. We are not defining
solutions, even not requesting to define such solutions.

Your first concern is the security of this delegation operation. In all cases, the private key is
not transported through the network. The private key is only kept and used by its owner. This does
not say the delegation operation is security. Actually, other parameters and cga generation result
also need protection.  The existing security mechanism of DHCPv6 may be used. We can add more
clarification into the draft.

Your second concern is the big compute job may overload the server. True. Actaully, in this draft,
we state "The DHCPv6 server could then either compute the Modifier by itself, or redirect the
computation requirement to another server." The second server may be dedicated computational
server. Again, this draft only lists the possibilities. If you want, we can add more analysis on
the issues of this possibility.

Regards,

Sheng

> -----Original Message-----
> From: cga-ext-bounces@ietf.org 
> [mailto:cga-ext-bounces@ietf.org] On Behalf Of Ted Lemon
> Sent: Wednesday, September 15, 2010 7:07 AM
> To: Tony Cheneau
> Cc: dhcwg@ietf.org Group; cga-ext@ietf.org; Droms; 
> Ralph@core3.amsl.com
> Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review 
> ofdraft-ietf-csi-dhcpv6-cga-ps
> 
> On Sep 14, 2010, at 6:08 PM, Tony Cheneau wrote:
> > So, as long as the public/private key are generated on the node, I 
> > would say that you will not need to communicate the private key (in 
> > clear or in a ciphered form).
> 
> Actually, this is clear as mud to me.   What is the big 
> compute job that's being done on the server, then?   Can you 
> point me to the RFC I should be reading that explains all 
> this?   Sorry to be obtuse.   :'}
> 
> _______________________________________________
> CGA-EXT mailing list
> CGA-EXT@ietf.org
> https://www.ietf.org/mailman/listinfo/cga-ext