[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
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
Best thing, all of this can be done in implementations without the
need to create or change protocols.