Hi£¬Tony, Thanks for the comments. Your concern is important for a security solution. But this document is a problem statement and it oversee possible solution space between dhcpv6 and cga. Security considerations are closely related to actual solutions. For this particular problem in section 4, we did propose a I-D in dhc wg: http://tools.ietf.org/id/draft-jiang-dhc-secure-dhcpv6-02.txt
Similarly as in SeND, CGA usage in dhcpv6 also need ADD like mechanism or pre-deployment of public key. The benefit of using public key crypto protection (compared with the symmetric crypto protection defined in dhcpv6) is discussed in detail in section 3 and 4 of the I-D. You are more than welcomed to read and discuss I-D. Best, Sean ÔÚÄúµÄÀ´ÐÅÖÐÔø¾Ìáµ½: >From: Tony Cheneau <[email protected]> >Reply-To: >To: [email protected], Sean Shen <[email protected]>, [email protected] >Subject: Comment on draft-jiang-csi-dhcpv6-cga-ps-03.txt >Date:Wed, 23 Sep 2009 11:28:20 +0200 (CEST) > >Hello, > > I have a small comment on section 4 of your draft: > " DHCPv6 message (from either a server, relay > agent or client) with a CGA as source address, can carry the CGA > Parameters data structure and a digital signature. The receiver can > verify both the CGA and signature, then process the payload of the > DHCPv6 message only if the validation is successful. In this way > DHCPv6 messages can be protected." > Maybe I missed something, but what is the gain from a security point of > view ? An attacker can still generate its own CGA and craft misleading > DHCP messages. Maybe you implicitly implied there was a mechanism similar > to ADD of SEND or that the Public Key is learned in a previous RS/RA > message exchange and ADD has been performed on the CGA. Either way, the > text seems unclear on this point, can you clarify this text in the next > version ? > > Best regards, > Tony Cheneau >
_______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
