On Fri, Jan 3, 2014 at 9:40 AM, Doug Barton <dougb@dougbarton.us> wrote:
On 01/02/2014 10:30 PM, TJ wrote:
I'd argue that while the timing may be different, RA and DHCP attacks are largely the same and are simply variations on a theme.
Utter nonsense. The ability to nearly-instantly switch traffic for nearly-all nodes on the network is a very different thing than what a rogue DHCP server could do, even if you have ridiculously short lease times, which most don't.
The IPv6 protocol does not give you such an ability (by accident - a hacker can steal your IPv4 network too with your completely unprotected network). There seems to be a lack of detailed understanding of the RFCs in this thread. Adding a new router to an already running network will add a second router to all clients. But no clients will actually switch to the new router unless the old one fails. That is the behavior specified in the RFC. Actual implementations might do something different, but that is hardly the fault of the protocol designer. Have anyone here actually tested this, or are we just making up stuff? Another person claimed that there would be 15 minuttes or more until the network was fixed, after removing a rogue router. That too is completely wrong. Every client will monitor the currently used router. If it stops responding for 30 seconds, the clients will switch to an alternative router. Also, routers are supposed to monitor their uplink. If the uplink is down, no RA should be sent on the downlinks and any current active prefixed should be withdrawn. Not all routers implement this, but at the least the CPEs are starting to do it correctly. This whole thread builds on the assumption that you are using equipment with either bad implementation or bad configuration. Blocking RA from client ports is just one simple ACL rule on the switch. Many vendors have a very simple option to enable it. You are not running a clean ship if you skip this, just the same as you are required to block DHCP servers from client ports. Regards Baldur