If we want to replace IPSec with something else for relay to relay/relay to server communication, we could always just allow use of the AUTH option. There's little need for CGA.
However, I don't believe there's a need to find an alternative to IPSec. I think you need to step back and figure out exactly what problem you're trying to solve by adding this capability. Just beause we could do something, doesn't mean we should. Personally, I still find that using the keys used by SEND (CGA) with the AUTH option to authentication servers (and possibly clients to servers) is the most interesting beause if you've already distributed those keys, it avoids having to distribute yet another set of keys. And, the folks that manage the routers often manage the DHCPv6 servers as well. - Bernie -----Original Message----- From: Sean Shen [mailto:[email protected]] Sent: Wednesday, January 21, 2009 4:52 AM To: Bernie Volz (volz); 'JiangSheng 66104' Cc: [email protected]; [email protected] Subject: RE: [CGA-EXT] [dhcwg] "Secure DHCPv6 Using CGAs"draft-jiang-dhc-secure-dhcpv6-01 Hi, Bernie, Thank you for the detailed review. I was not able to access email regularly recently and the situation will remain for another week or 10 days, but I will try to reply as fast as I can. Please see comments in lines: >Note that while the AUTH option needs to be generated last >(since it covers the entire message), it does not have to be >the LAST option in the message. > >In DHCPv6, no entity (relay agent or server) adds options to >the messages while it is 'in-flight' as is done for the DHCPv4 >relay agent option. Once the message is formed, a relay may >encapsulate it in a Relay Message option in its own message, >but that does NOT alter the original message. > >I think: >- CGA Signature can be anywhere in the message. >- CGA Signature covers the ENTIRE message EXCEPT for some of >its own fields and the AUTH option. >- The AUTH option covers the ENTIRE message, including the CGA >Signature option. > >This way, the AUTH gives complete protection of the entire >message as it was intended to. It works. >I'm not sure if it will be common for the SIGNATURE and AUTH >to be used together, as it seems to me that using the AUTH >message gives the better protection to begin with. But, if >they are used together, it works. Sure they can be used together. The good part of SIGNATURE is that it can be used in relay senarios, thus we don't need to rely on IPSEC for protection. (for the issue you found in relay scenario, please see the following comments) >I'd also highly recommend the CGA stuff be limited to clients >and servers (a client can add/server validate). Note that a >server can NOT use this for to provide proof of a CGA (the >server's source address) because this ONLY works when the >client and server are on the same link. >If a relay agent is involved, the source address of the packet >sent to the client is a relay agent address and thus the >Signature would never validate. Thanks for the issue you found, it's very important. The souce address lost problem happened only for SERVER-->Relay-->Client. For Client-->Relay-->Server, the souce address is kept in "link-address" field of relay messages. Comparing AUTH and SIGNATURE, we have the situation: No Relay C-->R-->S S-->R-->C AUTH yes no no SIGNATURE yes yes yes with proper solution* Possbile solutions*: Server's DHCP message (in relay senario) carry source address of server. For example, this can be done by defining new option to carry server's source address; or simply use the Server Identifier Option, define a new "link address plus time" type for DUID content. SIGNATURE is good for Relay scenarios where AUTH does not work. Entities along the route can sign messages as long as have the ability and are configured to do so. Receiver's can tell which signature belongs to whom. There are no pair-wise configurations of symmetric keys. For the questions whether all relay nodes should sign the message or whether the server/client should verify all the signatures, personally I think we can leave the decision for implementations or policys. Of course it's worth discussion whether we should enforce it in protocol. BW, Sean _______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
