On Wed, Dec 28, 2011 at 18:16, Doug Barton <[email protected]> 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
