[167901] in North American Network Operators' Group
Re: turning on comcast v6
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Tue Dec 31 14:14:36 2013
From: Leo Bicknell <bicknell@ufp.org>
In-Reply-To: <042b01cf0657$37bedb50$a73c91f0$@tndh.net>
Date: Tue, 31 Dec 2013 13:08:49 -0600
To: Tony Hain <alh-ietf@tndh.net>
Cc: 'Jamie Bowden' <jamie@photon.com>,
'North American Network Operators' Group' <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--Apple-Mail=_CED7725B-3A5B-42C9-9847-9BE5A0A79F8A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On Dec 31, 2013, at 12:36 PM, Tony Hain <alh-ietf@tndh.net> wrote:
> likely pointless. Do you really believe that dhcp messages picked up =
by the
> rogue router wouldn't end up answering with the wrong values and =
breaking
> both IPv4 & IPv6? Next, do you really believe that DHCP Guard for an =
IPv4
> aware switch will do anything when an IPv6 DHCP message goes by? Don't =
you
> have to replace every switch and reconfigure anyway? Or is rogue DHCP
> service a problem that goes away with IPv4? Why do people continue to =
insist
> that a cornerstone of their network security model is tied to an =
inherently
> insecure protocol that was never intended to be used as a security =
tool? ...
> but I digress =85
In the scenario I described, which I suggest is extremely common, the=20
rogue router will not provide any DHCPv4 client with an address, ever.
It is configured to forward to a DHCP sever, and based on the steps I
suggested it has no route to reach it. It will forward the packet out
its down uplink, and never get a reply. It is in fact 100% benign.
Let me repeat, it's 100% benign, and will not affect any users, ever.
Yes, if the router has a local DHCP server there would be an issue. But
that's not actually very common, most of the people running DHCP want a
central server and the logging that goes along with it.
I'll admit my scenario was contrived, constructed to specifically show
ONE aspect of the problem. It is not the only operational issue, but
it is one that is easy for engineers to understand and replicate. =
However,
it's also common. I know multiple people who shot themselves in the =
foot
in this very way, with operational networks. It's not a theoretical
problem, it's one that happens every day.
Here's another problem that happens every day in data centers and =
offices.
Someone accidentally bridges two VLAN's together for a few minutes by
plugging in a cable to the wrong port, realizing it and then unplugging
it. In an IPv4+DHCPv4 world the majority of the time the impact is,
well, NONE. No hosts notice. Some switches compute a new spanning tree
adjacency and some broadcast traffic goes where it shouldn't, but =
everything
remains operational. Do the same with IPv6 and all of the hosts on one =
of
the two VLAN's will instantly stop working.
There are controlled environments, like a single tenant data center
where a rogue DHCP server is simply not a security concern, but where
a tech accidentally bridging VLAN's is a very real possibility.
The fact of the matter is that the scale, scope, and impact from a rogue
DHCP server is entirely different from a rogue RA server. IPv4+DHCP
is operationally much more robust in the face of various scenarios,
where as IPv6+RA pretty much always results in near instantaneous 100%
failure.
> Unfortunately there have been too many voices demanding a 'one size =
fits
> all' approach within the IETF, and we have gotten to the current =
situation
> where you need to deploy parts of both models to have a functional =
network.
> RFC 6106 is a half-baked concession from the 'dhcp is the only true =
way'
> crowd to allow home networks to be functional, but if you want =
anything more
> than DNS you have to return to the one-true-way, simply because =
getting
> consensus for a more generic dhcp-options container in the RA was not =
going
> to happen. The Routing Information DHCP option has been held hostage =
by
> those that might be described as a 'dhcp is broken by design' crowd, =
because
> many saw that as a bargaining point for consensus around a more =
feature rich
> RA. Both hard line positions preventing utility in the other model are
> wrong, but in the presence of a leadership mantra of =
one-size-fits-all,
> neither side was willing to allow complete independent functionality =
to the
> other.=20
I think you describe the IETF situation reasonably well. The internal=20=
bickering between the "RA camp" and the "DHCP camp" have largely =
prevented
either one from producing something robust.
> Making progress on the Routing Information option requires a clear =
scenario
> to justify it, because vast swamp of dhcp options that have ever been =
used
> in IPv4 are not brought forward without some current usage case. Lee =
was
> asking for that input, and while the scenario you paint below might be
> helped by that option, it presumes that every device on the network =
has
> additional configuration to ignore an errant RA sent from the router =
being
> configured simply because the network is supposed to using DHCP.
This is some extremely circular logic.
We can't have DHCP until there are options in devices to ignore RA's.
We can't have an option to ignore RA's in devices, because at the moment =
RA's
are the only way to get a default route so it doesn't make sense.
Someone has to go first, the other side will follow. I suggest it makes
a lot more sense to get working DHCP, before pressuring end-user boxes
to have an option or even default to ignoring RA's.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--Apple-Mail=_CED7725B-3A5B-42C9-9847-9BE5A0A79F8A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIVAwUBUsMWQbN3O8aJIdTMAQJCrg//QG1n2pLneVWt3nr1fbIRzKnF4++IDhz0
XtSl/SOUGl44fFWGohHlKmj9U8lZOuNHYuZiCjIzVnSTGF825Dr50SYGLYjlpTDn
IExuhiSu0xWkyL5yYtSGo0aXC2yRZXekc6FPwm6CV+bCGQO2QfSnh3ONGHvlfkmi
JqQU1jrBqOBg+G4lXvJ4IQdWK/341ZyBVaa3Zlly+LgOnq0F1rNgU6l8Elv4f7uf
R2tqN3arXdeHmE9fOjSPKGPWKbali8DyR92nRTbFDuM/9r7X5swI6eXQk3jQdZhW
O5L/PDJUlXm6LPn5FDUqPC7FA53R+FL0Qoo+yRUtq8aa1ofq2YEqaYbAK0yQZYOw
6oTxH7C9caN7s3AvdA0m5a6R4+Siz8lMNpNnnel1wA3SP8zRXE+FEb0vcCDhxcUo
0OUEXUXUlay/6Q7a6uKZeGbsxiy2FOdXf37swxihnJqa993xF90MoqgAnDTnpGR4
snGTMDh+LjINRz3A6Oski1zPnB6Otgcyg6qv0gix/rN7CjAkeGo13PRZB8HxI2yU
4HLPKYEyVdpI93C5bDm1Aa2HEg59beq57sh03uD/PhrReFcOjQja/qMClbkMDlSe
cNVLhIxGz2xi2Vx3HoJBcKsknuUE+t9qUbpMh3TBZSsKsW9YYi/GvLoRX7ljaByj
VARaF81UHqI=
=EHx7
-----END PGP SIGNATURE-----
--Apple-Mail=_CED7725B-3A5B-42C9-9847-9BE5A0A79F8A--
