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

"Laganier, Julien" <> Wed, 15 September 2010 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B98613A698E; Wed, 15 Sep 2010 08:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.553
X-Spam-Status: No, score=-106.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wru1N1DDHt+K; Wed, 15 Sep 2010 08:55:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2FCF73A69BB; Wed, 15 Sep 2010 08:55:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1284566162; x=1316102162; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<> |To:=20Ted=20Lemon=20<>,=20Tony=20Ch eneau=0D=0A=09<>|CC:=20"dhcwg@"=20<>,=20" "=0D=0A=09<>,=20Droms=20<rdroms.ietf@gmai>,=20""=0D=0A=09<Ralph@core3.ams>|Date:=20Wed,=2015=20Sep=202010=2008:56:01=20-0700 |Subject:=20RE:=20[CGA-EXT]=20[dhcwg]=20Follow=20up=20req uest=20for=20review=20of=0D=0A=09draft-ietf-csi-dhcpv6-cg a-ps|Thread-Topic:=20[CGA-EXT]=20[dhcwg]=20Follow=20up=20 request=20for=20review=20of=0D=0A=09draft-ietf-csi-dhcpv6 -cga-ps|Thread-Index:=20ActUYZcyQDNVkOOgToS0CVAZg2RW5gAi0 TNg|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1F6826>|References:=20<21C043C9>=0D=0A=09<57452427>=0D=0A=09<201009>=0D=0A=20<A19EC513-6C71->|In-Reply-To:=20<A19EC> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=/PkszJa7Kfk67YLRjYNqZSWY5ao5hA6t4CJr/d0Uito=; b=S35dKR8yIX1WH+NeCepkk2OakaTX6q2x6277TCzAfo4SLk1zHa86a+pK F/MYJ0pFda7e+oni1HMsIYS7i2BhiAvhaireT7m8xjIed0oJM1QqHTYcs HOs0Z6MOs0st4oAencRKtkUlpLikES6Ss441B+3sOI/5TIS1621udtwvO U=;
X-IronPort-AV: E=McAfee;i="5400,1158,6106"; a="54437869"
Received: from ([]) by with ESMTP; 15 Sep 2010 08:56:01 -0700
X-IronPort-AV: E=Sophos;i="4.56,371,1280732400"; d="scan'208";a="85721083"
Received: from (HELO ([]) by with ESMTP/TLS/RC4-MD5; 15 Sep 2010 08:56:01 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 15 Sep 2010 08:56:01 -0700
Received: from ([]) by ([]) with mapi; Wed, 15 Sep 2010 08:56:01 -0700
From: "Laganier, Julien" <>
To: Ted Lemon <>, Tony Cheneau <>
Date: Wed, 15 Sep 2010 08:56:01 -0700
Thread-Topic: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps
Thread-Index: ActUYZcyQDNVkOOgToS0CVAZg2RW5gAi0TNg
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: " Group" <>, "" <>, Droms <>, "" <>
Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-ietf-csi-dhcpv6-cga-ps
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Sep 2010 15:55:45 -0000


Some clarifications:

Ted Lemon wrote:
> Sent: Tuesday, September 14, 2010 4:07 PM
> To: Tony Cheneau
> Cc: Group;; Droms;
> Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review of draft-
> 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.   :'}

If you have a look at the CGA generation algorithm described in RFC 3972 you will see that there are potentially two distinct computationally intensive tasks:

1. generation of public-private (RSA) key pair
2. generation of a CGA modifier value for a given Security Parameter (Sec) as per RFC 3972. (The Sec is used to harden the resistance of brute force attacks on the 64-bits IIDs of CGAs.)

#2 above might become computationally intensive for values of the Sec higher than zero (if it's zero any Modifier satisfies 3972). Back in 2002 I remember running the algorithm on then standard personal computers (e.g., x86 / ~1GhZ) and it would took ~20 seconds for Sec = 1 and a couple of minutes for Sec = 2. I do not remember going higher...

I understand the proposal is to offload #2 to the server while #1 would not be. 

IMHO it does not any make sense to offload when Sec is set to 0 because the computational load is nil. 

When Sec is set to 1 the computational load of #2 seems to be in the same order of magnitude as for #1, which does not necessarily means that offloading is useless as #1 might not need to be done by the constrained device itself (e.g., it's been offload to someone else, and result is stored on a smartcard.)

That being set I have not been convinced yet that there's a real world use case for Sec values higher than zero.