Mikael Abrahamsson wrote:
On Thu, 23 Jun 2011, Ray Hunter wrote:
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.
I don't see 5-10 year old LAN switches having any kind of capability
of filtering just certain IPv6 packets. They might have the
possibility of filtering all 0x86dd packet which is the sensible thing
to do unless one can secure it by other means.
Securing L2 networks is something not generally done today in
enterprise and surprisingly often in SP environments as well. This can
be seen by all the problems reported by Windows ICS v6 RA:s being sent
out and causing problems to other users (which in a properly build
network it shouldn't have the capability of doing, because those
packets should be filtered by the access network).
Many current devices implement DHCP snooping, IP source guard, and
similar ARP inspection filters for DHCP (v4) (as an alternative to
802.1x) because the user admin associated with L2 security technology is
generally a heavy operational burden. I don't have figures for the
percentage of people who would be affected by losing such equivalent
functionality if they moved to IPv6 today, but presumably there was an
operational "need", or else these IPv4 features would not have been
implemented. Obviously the likes of 802.1X are technologically far
superior, but that isn't always the deciding factor for implementation.
I can guess the answer the CFO will give those same people if they
request to renew their current L2 switches 5 years early just because
they need to implement RA Guard.
So what would those people do today to retain similar functionality for
IPv6 without investing heavily, or switching off IPv6?
> Short of encrypting all traffic and pre-distributing keys
If the WG has reached a stage of looking for a potential alternative
mitigation (and perhaps completely crazy out of the box thinking) that
doesn't involve replacing switches, may I humbly suggest consideration
of using the current DHCPv4/bootp mechanism to distribute an IPv6
address and MAC address (or some other stronger public-key) associated
with one or more trusted default routers in the initial network booting
process as a mitigation mechanism/ stop gap? The IPv6 hosts can then
defend themselves by filtering incoming RA messages to be from the
trusted source. I know it sounds truly awful, but it might work. IPv4
RFC1918 addresses are not going to run out. And it seems to me that's
the gap between DHCPv6 and DHCPv4 if you have a "problem" with rogue RA,
but you already have a decent solution in place for "secure enough"
DHCPv4 and DHCPv6. After all, IPv4 transport was also deemed acceptable
for use in resolving IPv6 AAAA records. If this is too far left field,
please simply ignore me :) Or better still, propose something smarter ;)
regards,
RayH
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
