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

From: Sheng Jiang <[email-masked]>
Date: Tue, 29 Jun 2010 09:23:58 +0800

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:[email-masked]] 
> Sent: Tuesday, June 01, 2010 1:35 AM
> To: Sheng Jiang
> Cc: [email-masked]
> 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 <[email-masked]>:
> > 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:[email-masked]]
> >> Sent: Friday, April 23, 2010 10:14 AM
> >> To: [email-masked]
> >> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cga-ext
> >