[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.