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