Subject:
Re: [v6ops] Question regarding RA-Guard evasion (ND and extension
headers)
From:
Ted Lemon <ted.le...@nominum.com>
Date:
Wed, 22 Jun 2011 20:56:52 -0400
To:
Mark Smith <i...@69706e6720323030352d30312d31340a.nosense.org>
CC:
v6...@ietf.org, ipv6@ietf.org
Content-Transfer-Encoding:
quoted-printable
Precedence:
list
MIME-Version:
1.0 (Apple Message framework v1242)
References:
<282787fa-c418-430c-b473-152b4ffe9...@gmail.com>
<m1qzlsp-0001...@stereo.hq.phicoh.net>
<20110622210451.60ad8...@opy.nosense.org>
<alpine.deb.2.00.1106221337411.19...@uplift.swm.pp.se>
<cf7c688f-9262-4a6c-9b57-cfddf94d2...@nominum.com>
<20110623095548.24d89...@opy.nosense.org>
In-Reply-To:
<20110623095548.24d89...@opy.nosense.org>
Message-ID:
<b5fba399-6aac-4036-a0d3-caa546190...@nominum.com>
Content-Type:
text/plain; charset="us-ascii"
Message:
7
On Jun 22, 2011, at 8:25 PM, Mark Smith wrote:
> You're right, with Ethernet being the wrong protocol.
Well, let's be clear here: Ethernet is apparently the wrong protocol*for you*.
You should be running 802.1x, not plain ethernet, because you have specific
needs that make plain ethernet an inappropriate choice for you.
But that wasn't what I was talking about. IPv6 has to work on ethernet.
IPv6 multicast is useful, and we (at least, some of us) want it to work. The
solution to the rogue RA problem is not to get rid of ethernet (or at least, so
I claim). Moreover, even supposing we could get rid of ethernet in the sense
that you mean, that would simply paper over the problem, not solve it. If we
want a secure network, we have to use secure protocols. Firewalls are a great
second-level defense (and your hub-and-spoke model is basically a firewall).
But they do not make your network secure: they simply make it harder to attack.
So if in fact it is impossible for RA to be adequately secured on an ethernet,
then we need to fix RA, or come up with a different solution, not slap a
bandage on it and call it done.
Sounds sensible.
Following are IMVVHO "requirements" from an operational perspective.
People have similar "issues" with ARP and DHCP (v4) and IPv4 today. But
today it is also trivial to filter BOOTP on networks with fixed
links/ports to make sure the default route and DNS server are set via
DHCP, and only the designated DHCP server/ DHCP relay can/will reply,
and that's generally been "good enough". For wireless, people are
generally employing something else, like 802.1X, anyway.
Sometimes I think we're in danger of making things so complex that the
simple filters will no longer work (and having to buy a complete new
generation of Ethernet LAN switches to make RA work does not sound
operationally attractive)
IMVHO If it was equally trivial as today to be able to completely filter
the messages that set the default route and the DNS server to certain
LAN ports or MAC addresses or IP source addresses or well-known port
numbers, and so be able to fairly reliably set the DNS server and the
default router on end hosts from a (weakly) trusted source, then the
"issue" would be "solved" for most users, because that would be no
different to today.
If people want to buy a new switch to implement RA Guard, then that's
fine too. But RA Guard should not be a prerequisite for reliably setting
of a default route on Ethernet, simply because corporate LAN switches
generally have to last 5-10 years or so before being replaced.
If the trust relationship between an end node and the source that
provides the configuration information on the default route and DNS
server could be made even stronger, all the better, but in a World of
roaming devices and guest users, that is not a trivial nut to crack
operationally.
regards,
RayH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
