[170395] in North American Network Operators' Group
Re: IPv6 Security [Was: Re: misunderstanding scale]
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Mar 27 01:48:02 2014
From: Owen DeLong <owen@delong.com>
In-Reply-To: <53331477.1070701@prgmr.com>
Date: Wed, 26 Mar 2014 22:45:00 -0700
To: "Luke S. Crawford" <lsc@prgmr.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 26, 2014, at 10:55 AM, Luke S. Crawford <lsc@prgmr.com> wrote:
> On 03/24/2014 06:18 PM, Owen DeLong wrote:
>> DHCPv6 is no less robust in my experience than DHCPv4.
>>=20
>> ARP and ND have mostly equivalent issues.
>=20
> This depends a lot on what you mean by 'robust'
>=20
> 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.
>=20
> However, DHCPv6 isn't anywhere near as useful for me, as someone who =
normally deals with IPs that don't change, as DHCPv4 is.
>=20
> 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=92s very clear=85 64 bit mac is just used. =
48 bit mac is OR=92d 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=92t 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=92t 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.
>=20
That seems unnecessarily difficult.
Owen
