On Aug 19, 2010, at 1:27 AM, Xu Xiaohu wrote: > With multicast, many DHCP authentication mechanisms will not be available > any more, e.g., IPsec mechanism for securing the messages exchanged between > servers and relay agents, and CGA usage for DHCP server authentication. By > the way, is the 6rd domain deemed as a secure network for DHCP message > exchange?
I don't see how you would use IPsec for authenticating DHCP from the client--how would the client choose a security association? Hm, okay, maybe that works because the client has the DHCP server's IP address. Still, this doesn't seem to fit the problem very well--the client would have to go around with a long list of server IP addresses and security associations. If CGA authentication is one of the major goals, a solution to this would be for the client to request a unicast response. Servers that don't implement that would respond normally; servers that do implement it would respond via unicast to the client's unicast address, and could sign their response using CGA. The client could also send a CGA-based signature along with the message containing the unicast request--since the CGA address the client would be providing will only work if it belongs to the client, this is useful authentication. > I admit that the DHCP relay agent on the CPE could relay the > information-request message to ALL_SERVERS_OR_RELAY-AGENT_ADDRESS in a 6rd > tunnel towards a 6rd BR, However, is it actually an optimal choice? We have to remember that "optimal" can mean a lot of different things in this context. I agree that in principal what you are proposing is optimal in some cases, but overall, I am concerned that it creates a lot of problems for a very small benefit--thus all the questions. _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
