Home page logo
/

nanog logo nanog mailing list archives

Re: Misconceptions, was: IPv6 RA vs DHCPv6 - The chosen one?
From: TJ <trejrco () gmail com>
Date: Wed, 28 Dec 2011 18:43:29 -0500

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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault