Re: [CGA-EXT] FW: New Version Notification for draft-ietf-csi-dhcpv6-cga-ps-02

Jean-Michel Combes <> Mon, 31 May 2010 17:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A6DEB28C0EC for <>; Mon, 31 May 2010 10:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.897
X-Spam-Status: No, score=-0.897 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UIylF6Wl4FNJ for <>; Mon, 31 May 2010 10:35:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AF7C228C0E5 for <>; Mon, 31 May 2010 10:34:57 -0700 (PDT)
Received: by wwb39 with SMTP id 39so1218629wwb.31 for <>; Mon, 31 May 2010 10:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NZxHFrwLMhBSJ1B0Ek4VlBgts81G79c9AlGYR1lIdsQ=; b=g83qWQjC6Fh1E5qbHoAORKd7IEsNno+aWZeV/vUeDqyGL8Lr3+yIfirB9YLkEDExho LvP7JmeRRG7iqyuY09RKT4mox8r45Yye0hooBbWDPpu9PzFpHksAc9oTBQBpGshBKi6h Jw29J4R2n9W7umMiOcqGz7yPVppy3FCa6jCdo=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SU8kzWKO86k0ziJww//0hYBqRcPtVbrOhEqO4cAoKCit7Oq2ib3dROtl3xz9eJfxst w/GjfzHk1rzs7hsIuLriv7fGOn2LjPGY4Oi0+f6X3wOHss5pv6ijmCbEje+TFNAvqLx2 zNB//895w1RjAG5ousF/BbCjYzVqgXkhO7P7M=
MIME-Version: 1.0
Received: by with SMTP id p3mr4605272wbt.21.1275327276666; Mon, 31 May 2010 10:34:36 -0700 (PDT)
Received: by with HTTP; Mon, 31 May 2010 10:34:36 -0700 (PDT)
In-Reply-To: <001e01cae28a$f39df4e0$>
References: <Acriiplf2G4PtS0qTymYn4PDzbxGJgAACqUA> <001e01cae28a$f39df4e0$>
Date: Mon, 31 May 2010 19:34:36 +0200
Message-ID: <>
From: Jean-Michel Combes <>
To: Sheng Jiang <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [CGA-EXT] FW: New Version Notification for draft-ietf-csi-dhcpv6-cga-ps-02
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: Mon, 31 May 2010 17:35:24 -0000

Hi Sheng,

please, find a review of your document:

             DHCPv6 and CGA Interaction: Problem Statement



1. Introduction

   The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]
   can assign addresses statefully. Although there are other ways to
   assign IPv6 addresses [RFC4862, RFC4339], DHCPv6 is still useful when

I don't understand why RFC4339 is referenced because RFC4339 describes
main ways to get the IP address of a DNS server.
Now, IMHO, you may mention RFC5739.

   an administrator requires more control over address assignments to
   hosts. DHCPv6 can also be used to distribute other network
   configuration information.


2. Coexistence of DHCPv6 and CGA

   CGAs can be used with IPv6 Stateless Address Configuration [RFC4862].
   The public key system associated with the CGA address provides
   message origin validation and integrity protection without the need
   for negotiation and transportation of key materials.

   The current CGA specifications do not mandate which device generates
   a CGA address. In many cases, a CGA address is generated by the
   associated key pair owner, which normally is also the host that will
   use the CGA address. However, in a DHCPv6-managed network, hosts
   should obtain IPv6 addresses only from a DHCPv6 server. This

s/hosts should obtain IPv6 addresses/hosts should use IPv6 global addresses
The reason is because nothing prevents an node generating an IPv6
address which is already the case with Link Local addresses.

   difference of roles needs to be carefully considered if there is a
   requirement to use CGAs in DHCPv6-managed environments.


4. What CGA can do for DHCPv6


   Using CGAs in DHCPv6 protocol can efficiently improve the security of
   DHCPv6, because the address of a DHCPv6 message sender (which can be
   a DHCPv6 server, a reply agent or a client) can be verified by a
   receiver. The usage of CGA can efficiently avoid the abovementioned
   attacks. It improves the communication security of DHCPv6

"The usage of CGA can efficiently avoid the abovementioned attacks."
IMHO, it is not correct: the use of CGA allows to check that the IP
source address is really owned by the sender and the integrity of the
sent data if they are signed with the private key associated to the
public key used to generate the CGA. Nothing prevents a 'rogue' DHCPv6
server/relay generating its own CGA and send erroneous information (as
mentioned in the text about the attacks).
The missing point here, but which is mentioned in the last paragraph
of this section, is that a node may not be aware of what is the DHCP
relay/server's IP address (i.e. the node may only know the well-known
DHCPv6 Multicast addresses). IMHO, the issue is more or less like for
Router Advertisement messages security (i.e. is the owner's IP source
address authorized to be a router?)

   interactions. The usage of CGAs can also avoid DHCPv6's dependence on
   IPSEC [RFC3315] in relay scenarios. This mechanism is applicable in


   environments where physical security on the link is not assured (such
   as over certain wireless infrastructures) or where available security
   mechanisms are not sufficient, and attacks on DHCPv6 are a concern.

   A CGA generated from an unauthorized public & private key pair can
   prove the source address ownership and provide data integrity

   Furthermore, A CGA generated from a certificated public & private key
   pair can also achieve authorization for DHCPv6 servers or relays, or
   on another direction, user authorization. The public keys may be pre-
   configured on both parties of communication or have a third party
   authority available for users to retrieve public keys. The public
   keys will be used for users to generate CGAs and verify CGAs and
   signatures. The pre-configuration can also include configuring more
   CGA parameters such as SEC value or more depend on policies. The pre-
   configuration can even be the whole CGA and related parameters, but
   in this case the address will be fixed and this situation may not be
   desired when users want to keep their addresses unknown.

In the last sentence, who are the users? DHCP relay/server? DHCP clients?

Hope that may help you and thanks in advance for your reply.

Best regards.


2010/4/23 Sheng Jiang <>om>:
> A new version has been submitted. Comments from Alberto has been addressed
> in this version. Further comments are welcome.
> Regards,
> Sheng
>> -----Original Message-----
>> From: IETF I-D Submission Tool []
>> Sent: Friday, April 23, 2010 10:14 AM
>> To:
>> Subject: New Version Notification for draft-ietf-csi-dhcpv6-cga-ps-02
>> A new version of I-D, draft-ietf-csi-dhcpv6-cga-ps-02.txt has
>> been successfully submitted by Sheng Jiang and posted to the
>> IETF repository.
>> Filename:      draft-ietf-csi-dhcpv6-cga-ps
>> Revision:      02
>> Title:                 DHCPv6 and CGA Interaction: Problem Statement
>> Creation_date:         2010-04-22
>> WG ID:                 csi
>> Number_of_pages: 9
>> Abstract:
>> This document describes potential issues in the interaction between
>> DHCPv6 and Cryptographically Generated Addresses (CGAs).
>> Firstly, the scenario of using CGAs in DHCPv6 environments is
>> discussed.
>> Some
>> operations are clarified for the interaction of DHCPv6
>> servers and CGA-associated hosts. We then also discuss how
>> CGAs and DHCPv6 may have mutual benefits for each other,
>> including using CGAs in DHCPv6 operations to enhance its
>> security features and using DHCPv6 to provide the CGA
>> generation function.
>> The IETF Secretariat.
> _______________________________________________
> CGA-EXT mailing list