Hi, Ted, There are actually two very different concerns you have. I reply below.
Before that, I would like to state: as an informational document, draft-ietf-csi-dhcpv6-cga-ps aims to analyze the all possible interactions between cga and dhcpv6. Whether these possibilities are going to be defined as actual solutions in the future, it is another matter. In this draft, all we say is there are such possibilities, their benefits and issues (if you want, we can put more analysis regarding to potential issues of this possibility). You may notice in this 04 version, we have removed "Solution Requests" charpter, which was in previous version. We are not defining solutions, even not requesting to define such solutions. Your first concern is the security of this delegation operation. In all cases, the private key is not transported through the network. The private key is only kept and used by its owner. This does not say the delegation operation is security. Actually, other parameters and cga generation result also need protection. The existing security mechanism of DHCPv6 may be used. We can add more clarification into the draft. Your second concern is the big compute job may overload the server. True. Actaully, in this draft, we state "The DHCPv6 server could then either compute the Modifier by itself, or redirect the computation requirement to another server." The second server may be dedicated computational server. Again, this draft only lists the possibilities. If you want, we can add more analysis on the issues of this possibility. Regards, Sheng > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Ted Lemon > Sent: Wednesday, September 15, 2010 7:07 AM > To: Tony Cheneau > Cc: [email protected] Group; [email protected]; Droms; > [email protected] > Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review > ofdraft-ietf-csi-dhcpv6-cga-ps > > On Sep 14, 2010, at 6:08 PM, Tony Cheneau wrote: > > So, as long as the public/private key are generated on the node, I > > would say that you will not need to communicate the private key (in > > clear or in a ciphered form). > > Actually, this is clear as mud to me. What is the big > compute job that's being done on the server, then? Can you > point me to the RFC I should be reading that explains all > this? Sorry to be obtuse. :'} > > _______________________________________________ > 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
