IPv6 Security [Was: Re: misunderstanding scale]

Thu Mar 27 05:45:00 UTC 2014

On Mar 26, 2014, at 10:55 AM, Luke S. Crawford <lsc at prgmr.com> wrote:

> On 03/24/2014 06:18 PM, Owen DeLong wrote:
>> DHCPv6 is no less robust in my experience than DHCPv4.
>> 
>> ARP and ND have mostly equivalent issues.
> 
> This depends a lot on what you mean by 'robust'
> 
> Now, I have dealt with NAT, and I see IPv6 as a technology with the potential to make my life less unpleasant.   I really want IPv6 to succeed.
> 
> However, DHCPv6 isn't anywhere near as useful for me, as someone who normally deals with IPs that don't change, as DHCPv4 is.
> 
> With DHCPv4, my customers all get an address based on their mac that doesn't change if their box is re-installed.  I configure this on the DHCP server, and the customer can run whatever dhcp client they like on whatever OS they like and they get the same IP every time.

Other than it being based on DUID instead of MAC (which, btw, DUID can be based on MAC), this is also possible in DHCP6.

> With DHCPv6 there is a time-based identifier that is added to the mac that makes it impossible, as far as I can tell, to give the customer a consistent IP across OS wipes without doing significant client configuration.

Nope. Not true.

> There are many ways to skin this cat; stateless autoconfig looks like it mostly works, but privacy extensions seem to be the default in many places; outgoing IPv6 from those random addresses will trip my BCP38 filters.   That, and reading the standard, it sure doesn't sound like consistency was a goal, even though it seems fairly consistent experimentally.  there's a lot of "generally" and "may"  in the text about what it adds to the mac in order to get the local identifier.

Why would your BCP38 filters be filtering down below the prefix level? The random addresses all still have the same 64 bit prefix.

For non-privacy addresses, it’s very clear… 64 bit mac is just used. 48 bit mac is OR’d with 0x0200 0000 0000 and then split at the OUI/ESI boundary (24 bits) where 0xfffe is inserted. Thus 1234.5678.abcd would become 1234.56ff.fe78.abcd and 0123.4567.89ab would become 0323.45ff.fe67.89ab.

For privacy addresses, this is kind of all over the map and multiple different algorithms with different entropic properties are proposed. Worse, Micr0$0ft doesn’t conform to the standard at all and, instead, uses no entropy to provide an address that is different per prefix, but the same every time for the same prefix.

> It might make sense to just give everyone their own vlan and their own /64;  that would, of course, bring its own problems and complexities (namely that I've gotta have the capability to deal with more customers than I can have native vlans -  not impossible to get around, but significant added complexity.)

I don’t see the point of that.

> I suppose I can also just keep DHCPv4 around, and if folks want IPv6, well, they have to wire down the address themselves.   That's how I'm doing it now.
> 

That seems unnecessarily difficult.

Owen