Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?

[TJ <trejrco () gmail com>]

On Wed, Dec 28, 2011 at 18:16, Doug Barton <dougb () dougbarton us> wrote:

> On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
> > However, this has two issues. First, with RAs there are no risks that
> > incorrect default information is propagated because the default
> > gateway itself broadcasts its presence.
>
> Unless you have a malicious user on the network in which case all
> traffic immediately switches to the malicious user's gateway. This is in
> contrast to DHCP where the similar attack only affects new/renewing
> hosts. I'm aware that SEND is trying to solve this problem, but it's not
> yet deployed.

Right, the window is tighter for DHCPv4 as compared to SLAAC.
That is why RA Guard is a really useful thing we should support to prevent
accidental maliciousness, and perhaps enhance RA Guard to account for
more skillful evasive (fragmented, etc.) malicious RAs.

In the former case, a simple ARP-spoofing attack (for IPv6, ND spoofing)
and you are back in ... but that is a separate paragraph :).


> With DHCP, it is possible to
> > inject incorrect information. In my opinion, people are
> > underestimating the problems that occur with IPv4 DHCP and the
> > additional issues that would be introduced in IPv6 by adding this
> > feature.
>
> I think that people already know of and have solutions for the security
> issues that exist for DHCP today.

And what is the percentage of environments that use those things?  (From
personal experience, 0% ... although certainly it is higher than that.)
 And yet, their IPv4 networks are up & running just fine ... In the big
picture, this has always been fairly low on the scale.  Make RA Guard a
norm for "host ports" and move forward.



> > Second, publishing specifications, implementing them and waiting for
> > users to adopt them takes a very, very long time. For DHCPv6 support,
> > the time from first publication (2003) until wide availability (2011)
> > has been 8 years. Are we ready to live in a half-baked world for
> > another half a decade or more just so we can add this feature, while
> > layer 2 filtering and VLANs more easily support similar
> > functionality?
>
> 10-12 years ago I attempted to make 2 points to the IPv6 literati. First
> that IPv6 would not be widely adopted in the enterprise until it had
> full DHCP parity with v4. Second that the easiest way to do that would
> be to declare all existing DHCPv4 options that are relevant to IPv6 as
> existing in DHCPv6 by fiat, and to prevent new v6-only options from
> using option numbers that already exist for v4 (and vice versa). I was
> laughed out of the room on both counts. (If anyone wants more of the
> history, see
> https://www.ietf.org/mail-archive/web/ipv6/current/msg15129.html)
>
> The good news is that it's not too late to fix DHCPv6. We're at a
> watershed moment where it's just possible that we'll get the ability to
> assign a default gateway added to it due to, for lack of a better term,
> market forces. This would be a major paradigm shift. As you point out
> the development lead time on stuff like that is rather painful, however
> if we took advantage of the camel's nose under the tent and included
> "everything relevant that DHCPv4 can do" in that update, we'd be in a
> pretty good condition in a year or so.

And, FWIW, I support making DHCPv6 "more complete" as well.
(Although, annoying to some, I don't mind DHCPv6 waiting for the M bit to
be sent in an RA - again separate paragraph!)


/TJ