Subject: Re: Handling rogue RA feedback

From: Stig Venaas <[email-masked]>
Date: Thu, 16 Aug 2007 11:23:24 +0200

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Aug 2007 00:50:14 +0200

> startup.

That goes against the way RAs and prefixes time out and you can't  
renumber anymore.

What would help a lot is to ignore RAs with only 6to4 and site local  
prefixes (not just the prefixes, the entire RA) if there are also RAs  
from one or more other routers with non-6to4 / non-site local  
prefixes. 6to4 / site local are the prefixes that tend to be  
advertised by mistake.

Making sure you match the outgoing gateway with the source address  
prefix would pretty much do this automatically because 6to4 addresses  
are explicitly avoided in RFC 3484 tables and site local has a large  
"CIDR distance" from global unicast addresses.

An easy way to maintain a "bad router" list (which are then filtered)  
would also help.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 17 Aug 2007 08:10:29 +0900 (JST)

> lifetime is more than 2 hours and the received is less...

	i was not clear enough.

	KAME rafixd erases rogue router from the default router list on
	nodes that are on the same, by transmitting fake RA with router
	lifetime of 0.

	specwise, 2 hour rule is about prefix lifetime, not router lifetime.
	so there's no issue with 2 hour rule router lifetime.

	wrt on-link determination, i'd better summon jinmei :-)

itojun
# ipv6samurais.com: saving the world with code and sword

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 18 Aug 2007 01:15:35 +0900

At Thu, 16 Aug 2007 11:23:24 +0200,

> lifetime is more than 2 hours and the received is less...

It should not matter much in practice because the address will still
become deprecated (preferred lifetime becomes 0) immediately and it
will be less preferred as the source address of subsequent (new)
communication (as long as the node has another valid global IPv6
address and follows the default address selection rules defined in
RFC3484).

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 24 Aug 2007 22:14:02 +0200 (CEST)

Hi Stig,

>> 	  CONS: need to take down the source of rogue RA anyways

Another half solution is to monitor and alert malicious ND and RA usage.
Have a look at ndpmon at http://ndpmon.sf.net

I use it more than half a year now successfully.

> to misconfiguration, except that the 2 hour rule is not a problem.

What SEND implementations are available around?

Best Regards,
 		Janos Mohacsi

---

From: Stig Venaas <[email-masked]>
Date: Sat, 25 Aug 2007 01:42:41 +0200

Mohacsi Janos wrote:
[...]
> What SEND implementations are available around?

Only one I'm aware of is
http://www.docomolabs-usa.com/lab_opensource.html

Sadly I still haven't got around to play with it...

Stig