Re: Handling rogue RA feedback

[Stig Venaas <stig.venaas@uninett.no>]

Jun-ichiro itojun Hagino wrote:
> 	i'll try to summarize what i know of about handling rogue RAs.

Hi Itojun, some comments on this

> 
> 	- L2 switch solution: filter rogue RAs in the switches, just like
> 	  filter rogue DHCPv4.  you can detect potential RA sources by
> 	  MLD joins to ff02::2 (all-routers link local multicast addr).
> 	  CONS: you cannot protect victims within the same wireless
> 	  base station, for instance.

I think L2 solutions that can restrict RAs to known router ports would
be great.
> 
> 	- end node host firewall solution: at every node, look at the content
> 	  of RAs and reject them if they advertise prefixes like
> 	  fec0:0:0:xxxx::/64.
> 	  CONS: not widely deployable, can filter false positives
> 
> 	- KAME rafixd: shoot down rogue RAs by announcing against those rogue
> 	  RAs with 0 prefix/router lifetime
> 	  PROS: easy to deploy, maybe we should ship it with *BSD
> 	  CONS: need to take down the source of rogue RA anyways

I like this one, but isn't the 2 hour rule a problem here? If the stored
lifetime is more than 2 hours and the received is less...
> 
> 	using DHCPv6 is NOT a soultion, as you can see rogue DHCPv6 server/
> 	relay agent just like rogue RAs.

Like you did above, I think we should try to look at what issues people
currently see with rogue RAs and whether there are ways to improve RAs.

The main problem I experience, and have heard from others, is that if an
administrator through misconfiguration announces the wrong prefix (e.g.
router misconfiguration, wrong VLAN ID on a switch port, etc), someone
plugs a network cable in the wrong switch port, or some host by accident
announces bad RAs etc, then this will often affect all the IPv6 hosts on
the link. With DHCP you only affect the hosts that request configuration
before the problem is fixed. I.e. if an administrator reacts quickly the
impact of this error is much smaller than with RAs.

There are some obvious solutions to this. One is to only accept RAs at
startup. One could also in theory have a host only accept an RA every
hour or whatever. Of course the problem with this is that the host
cannot react to changes. I think the best thing with RAs is that a host
can quickly adapt to any changes, but that is also the problem.

SEND can make things more secure. It does not help that much with regard
to misconfiguration, except that the 2 hour rule is not a problem.

Stig

> 	  
> itojun
>