[170414] in North American Network Operators' Group
Re: IPv6 Security
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Mar 27 08:39:05 2014
From: Owen DeLong <owen@delong.com>
In-Reply-To: <20140327.085206.74744053.sthaug@nethelp.no>
Date: Thu, 27 Mar 2014 05:34:23 -0700
To: sthaug@nethelp.no
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Mar 27, 2014, at 12:52 AM, sthaug@nethelp.no wrote:
>>> No, it is LESS robust, because the client identifier changes when =
the
>>> SOFTWARE changes. Around here, software changes MUCH more often =
than
>>> hardware. Heck, even a dual-boot scenario breaks the client
>>> identifier stability. Worse yet, DHCPv6 has created a scenario =
where
>>> a client's IPv4 connectivity and IPv6 connectivity break under
>>> /different/ scenarios, causing difficult-to-troubleshoot
>>> half-connectivity issues when either the hardware is replaced or the
>>> software is reloaded.
>>=20
>> Any client whose DUID changes on software re-install has a very poor =
choice of default DUID and should be configurable for a better choice of =
DUID. That is not DHCPv6=1B.F=1BN"s fault.
>=20
> It is reality. DHCPv6 needs to take reality into account.
>=20
> DHCPv6 as defined in RFC 3315 does not offer client MAC address at all
> (thus making the job more difficult for a number of organizations).
Yes it does=1B$B!D=1B(B
What do you think =1B$B!H=1B(BLink Layer Address=1B$B!I=1B(B (RFC 3315, =
Section 9.1 Type 3)
is? =46rom RFC-3315 Section 9.4, it seems pretty clear that is exactly =
what
this is intended to be. True, it includes an additional 16 bits of media =
type,
but I don=1B.F=1BN"t see that as being a problem.
> All I've seen so far indicates that this was a deliberate choice by
> the DHCPv6 designers, and in my opinion a very poor one. Fortunately
> we now have RFC 6939 (DHCPv6 Client Link-Layer Address Option), and
> we're waiting for vendors to implement this. That solves one half of
> the problem.
Yes and no.
At the time RFC3315 was written, network cards changed independent of
motherboards on a regular basis and this fact was a source of great
consternation for DHCPv4 operators. Over time, that changed AFTER
RFC3315 was written, but if you read section 9.4, it seems pretty clear =
that
this change was anticipated by the authors and that DUID-LL was intended
for the situation we have today.
Clients failing to implement DUID-LL as defined in RFC-3315 can hardly =
be
blamed on DHCPv6.
> The other half is to actually let the DHCPv6 lease be based directly
> on the MAC address. The language in RFC 3315, as I read it, makes this
> difficult or impossible.
Reread section 9.4=1B$B!D=1B(B It seems not only possible, but =
recommended from my reading.
The problem isn=1B.F=1BN"t that the MAC address isn=1BN"t allowed. The =
problem is that the clients
aren=1B.F=1BN"t properly using permanent MAC addresses as DUID.
Owen
