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

Sheng Jiang <shengjiang@huawei.com> Tue, 29 June 2010 01:24 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 28E4B3A6A1B for <cga-ext@core3.amsl.com>; Mon, 28 Jun 2010 18:24:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.223
X-Spam-Level: *
X-Spam-Status: No, score=1.223 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_50=0.001, 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 NXjjYcTPvLB4 for <cga-ext@core3.amsl.com>; Mon, 28 Jun 2010 18:23:59 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id BDC9E3A6A0E for <cga-ext@ietf.org>; Mon, 28 Jun 2010 18:23:58 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4R00C9C57Y87@szxga03-in.huawei.com> for cga-ext@ietf.org; Tue, 29 Jun 2010 09:23:58 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L4R0082O57YSS@szxga03-in.huawei.com> for cga-ext@ietf.org; Tue, 29 Jun 2010 09:23:58 +0800 (CST)
Received: from j66104a ([10.110.98.171]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L4R008WQ57YFM@szxml04-in.huawei.com> for cga-ext@ietf.org; Tue, 29 Jun 2010 09:23:58 +0800 (CST)
Date: Tue, 29 Jun 2010 09:23:58 +0800
From: Sheng Jiang <shengjiang@huawei.com>
In-reply-to: <AANLkTimvpbOjgWpIESxRgVLcD1XN4oJRUlmiafdGMCtr@mail.gmail.com>
To: 'Jean-Michel Combes' <jeanmichel.combes@gmail.com>
Message-id: <002401cb1729$bfa01af0$ab626e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Thread-index: AcsA54sFgZK5puylTVuNEEAorTPlqgWQe2Tg
Cc: cga-ext@ietf.org
Subject: Re: [CGA-EXT] FW: New Version Notification for draft-ietf-csi-dhcpv6-cga-ps-02
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: Tue, 29 Jun 2010 01:24:00 -0000

Hi, Jean,

Thanks so much for your comments. It does help us to improve our draft. All your comments have been
addressed in the new 03 version.

http://tools.ietf.org/html/draft-ietf-csi-dhcpv6-cga-ps-03

Sorry for taking so long to react. I was in travels for a couple of assignment.

Best regards,

Sheng 

> -----Original Message-----
> From: Jean-Michel Combes [mailto:jeanmichel.combes@gmail.com] 
> Sent: Tuesday, June 01, 2010 1:35 AM
> To: Sheng Jiang
> Cc: cga-ext@ietf.org
> Subject: Re: [CGA-EXT] FW: New Version Notification for 
> draft-ietf-csi-dhcpv6-cga-ps-02
> 
> Hi Sheng,
> 
> please, find a review of your document:
> 
> 
>              DHCPv6 and CGA Interaction: Problem Statement
> 
>                   draft-ietf-csi-dhcpv6-cga-ps-02.txt
> 
> 
> [snip]
> 
> 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
> 
> <JMC>
> 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.
> <JMC>
> 
>    an administrator requires more control over address assignments to
>    hosts. DHCPv6 can also be used to distribute other network
>    configuration information.
> 
> [snip]
> 
> 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
> 
> <JMC>
> 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.
> <JMC>
> 
>    difference of roles needs to be carefully considered if there is a
>    requirement to use CGAs in DHCPv6-managed environments.
> 
> [snip]
> 
> 4. What CGA can do for DHCPv6
> 
> [snip]
> 
>    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
> 
> <JMC>
> "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?) <JMC>
> 
>    interactions. The usage of CGAs can also avoid DHCPv6's 
> dependence on
>    IPSEC [RFC3315] in relay scenarios. This mechanism is applicable in
> 
> <JMC>
> s/IPSEC/IPsec
> <JMC>
> 
>    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
>    protection.
> 
>    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.
> 
> <JMC>
> In the last sentence, who are the users? DHCP relay/server? 
> DHCP clients?
> <JMC>
> 
> 
> 
> Hope that may help you and thanks in advance for your reply.
> 
> Best regards.
> 
> JMC.
> 
> 2010/4/23 Sheng Jiang <shengjiang@huawei.com>:
> > 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 [mailto:idsubmission@ietf.org]
> >> Sent: Friday, April 23, 2010 10:14 AM
> >> To: shengjiang@huawei.com
> >> 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
> > CGA-EXT@ietf.org
> > https://www.ietf.org/mailman/listinfo/cga-ext
> >