So why is "IPv4 with longer addresses" a problem anyway?

Benedikt Stockebrand me at benedikt-stockebrand.de
Tue Jun 1 15:39:51 CEST 2010


Hi Nick and list,

Nick Hilliard <nick at foobar.org> writes:

> Depending on RA means:
>
> - loss of service measured in (by default) minutes in the case of router
> failure

if you had actually either tried this or at least taken a proper look
at the specs, then you'd know that the upper bound here is 45s
(REACHABLE_TIME \times MAX_RANDOM_FACTOR, as defined in RFC 4861) plus
whatever another round of neighbor discovery takes (usually <1s).

That's well within standard TCP timeouts, and yes, I've actually taken
the time to double (in the RFC) and triple (in a quick test setup)
check this.

> - serious security problems due to rogue RA announcements by unauthorised
> network clients

That's a problem inherent in all multiple access networks and not
specific to Autoconf.  I can do the same in an IPv4 network with VRRP
or HSRP clustered routers or whatever by well known ARP manipulation
attacks, among other things.

It's admittedly bad that router, and especially WLAN access point,
vendors haven't yet widely implemented ways to filter rogue RAs like
they filter rogue DHCP servers, but that's an implementation problem,
not a specification one.

Beyond that, if you can't get your network topology sorted out in a
way that prevents these issues simply by not allowing any unauthorized
clients into your sensitive subnets, that's hardly something you can
blame Autoconf for.  You can't expect the network layer to fix all
security issues stemming from your link layer.

> Either of these problems on their own makes RA unsuitable for most
> applications other than enthusiast / home / playpen.

Since you keep trying to insinuate that I don't know about data center
operations: Take a look at http://www.top500.org/system/5090.  Among
the lessons I've learned from building that system is that the only
way to get reliability is to avoid complexity where it doesn't
contribute to the system---especially if you run 24/7 and have to
ensure that you always have a team on call duty who can handle the
system in all of its aspects.

I'm not saying that this is a setup where I'd use router failover
based on Autoconf, but if I ever had to build anything like that again
I'd test all the options available (VRRP, HSRP, passive OSPF, passive
RIP, Autoconf, whatever redundancy features the application software
offers, custom failover scripts) before I'd jump to conclusions.

> But, if you want to operate your network with lousy availability
> characteristics and where any arbitrary client can hijack the
> network, then by all means, please go ahead and do so.  Just don't
> pretend that it's going to be reliable.

Again, maybe you should just fix your networks.  From your comments I
suggest you start with separating nodes with different privileges into
separate subnets.  Then maybe split subnets with a significant number
of machines in there (use a bit of quantitative risk analysis to find
an adequate number for your setup) into smaller ones to contain the
impact of any (intentional or accidential) incident.  If you can't get
physical security straight, consider to use 802.1x.


    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Benedikt Stockebrand, Dipl.-Inform.   http://www.benedikt-stockebrand.de/



More information about the ipv6-ops mailing list