Re: Operational comments on RAs vs DHC

[Tim Chown <tjc@ecs.soton.ac.uk>]

On Mon, Mar 19, 2007 at 07:22:23PM +0200, Rémi Denis-Courmont wrote:
> On Monday 19 March 2007 17:42:35 Tim Chown wrote:
> 
> > - Vendors adding RA snooping to L2 devices (doesn't help shared media
> > though)
> 
> Not sure what you mean... switches that trash RAs? how do they know which 
> ports leads to the legitimate router(s) - often different from the switch 
> itself?

Just like DHCP snooping today, you preconfigure it.
 
> > There really isn't a readily deployable countermeasure today, and I think
> > that's causing mild unrest with admins.   Of course, one can just wave the
> > issue away saying it's no different to rogue DHCP servers, though at least
> > there is DHCP snooping on some L2 equipment.
> 
> Some people listen for RAs on the link, and send spoof RA with a zero 
> lifetime, to pretend the offensive advertiser goes down. Of course, this 
> assumes that the advertiser only does multicast RAs, *or* L2 switch infra 
> does not support IPv6 multicast. Also this could break local ACLs.
> 
> Oh, and yes, that's ugly.

That's why I dscounted that option from the outset :)  I think Itojun wrote
the first such 'zapper', but it's a very ugly 'solution'.

> > The related issue is whether certain timers that have been standardised
> > are appropriate in the face of deployment experience.   Recovery from
> > an administratively configured 'errant' RA is another consideration.
> > The above measures may be of no benefit if the 'trusted' party messes up.
> > However one could also say a similar issue exists today for a host getting
> > a bad DHCP lease for a period should a DHC server be misconfigured.
> 
> Yes. It's easier to fix DHCPv4 problems because:
> - the victims users will usually get no connectivity at all, so they reboot or 
> whatever until this gets fixed,
> - the exposure time window is very limited.

The thing to consider (as well) is recovery from misconfiguration.  

-- 
Tim