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