[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Handling rogue RA feedback



On 24-jul-2007, at 17:11, Jun-ichiro itojun Hagino wrote:

	i'll try to summarize what i know of about handling rogue RAs.

[...]

Another option would be for hosts to do something similar to neighbor unreachability detection for their default gateway.

One thing that annoys me to no end is that if router X sends out prefix A::/64 and router Y sends out B::/64, then node 1 will happily configure addresses A::1 and B::1, and then send out packets with source address A::1 over router Y. This is really a bad thing for efforts like shim6.

So trying to use the router that gave you the prefix for the source address you're using is a good start. The next one would be to avoid routers that announce obviously tunneled reachability such as 6to4 or Teredo.

Actually detecting whether a default gateway works and then switching to another would be more difficult, but that should help against rogue RAs and also (if/when a gateway address through DHCPv6 becomes possible) rogue or misconfigured DHCPv6 in most typical cases, although of course a careful attacker could deliver the packets after inspecting/modifying them, but we have IPsec/SEND against that, if you care enough to defeat an attacker that cares enough to do that you'll go through the effort of making those work.

And it will detect and repair a class of failures that is currently fatal.

Best thing, all of this can be done in implementations without the need to create or change protocols.