On Thu, 27 Dec 2007 11:27:13 +0100 Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 26 dec 2007, at 22:40, Leo Bicknell wrote:
<snip>
It would be very interesting to me if the answer was "it's moot because we're going to move to CGA's as a step forward"; it would be equally interesting if the answer is "CGA isn't ready for prime time / we can't deploy it for xyz reason, so IPv6 is less secure than IPv4 today and that's a problem."
With IPv4, a lot of these features are developed by vendors and (sometimes) later standardized in the IETF or elsewhere. With IPv6, the vendors haven't quite caught up with the IETF standardization efforts yet, so the situation is samewhat different. For instance, SEND/CGA is excellent work, but we've only recently seen the first implementations.
Personally, I'm not a big fan of DHCPv6. First of all, from a philosophical standpoint: I believe that stateless autoconfiguration is a better model in most cases (although it obviously doesn't support 100% of the DHCP functionality). But apart from that, some of the choices made along the way make DHCPv6 a lot harder to use than DHCP for IPv4. Not only do you lack a default gateway (which is actually a good thing for fate sharing reasons) but also a subnet prefix length and any extra on-link prefixes.
I think it's interesting CGAs are being discussed in the same email as the one where you say you want to be able to express prefix length in DHCPv6 - because I'm guessing you want that feature to be able to shorten node addresses. One of the benefits of fixed length node addresses, at the 64 bit boundary, is that it has made CGA much simpler - the CGA designers knew from the outset that they were dealing with a single, fixed length 64 bit field to store the results of their crypto functions. If people had different length autoconfigured or DHCPv6 learned addresses, not only would CGA have to had be designed to support those varying field lengths, increasing it's complexity (and therefore increasing opportunities for implementation related security failure aka bugs with security consequences), it's also likely that CGA would have had to incorporate parameter checks to prevent people enabling it, when the node address length they've chosen is too short for the security strength CGA is designed to provide. If you don't perform these sorts of checks, then too weak CGA, because of too short node addresses, might give people a false sense of security - and I think that's far worse than no security at all. Regards, Mark. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"