How to preempt rogue RAs?

[Eric Vyncke (evyncke)]

Tore,

On WLAN (conference), the easiest way to fight the rogue-RA is simple to configure AP/WLC to prevent direct client to client communication.

On LAN, this behavior can also be done by enabling private VLAN (or whatever similar feature on another brand).

Both techniques have an obvious impact such as preventing bonjour (and many other things notably DAD :-( ) to work or direct PC/PC communication. Proxy-ARP helps for IPv4 but, AFAIK, my employer's routers do not have proxy-NDP yet.

But, the best way (assuming 'C brand' as someone named them :-) except Cat 2K) is to use the new PACL (Port ACL) such as:
ipv6 access-list ACCESS_PORT
    remark Block all traffic DHCP server -> client
    deny udp any eq 547 any eq 546
    remark Block Router Advertisements
    deny icmp any any router-advertisement
    permit any any

Interface gigabitethernet 1/0/1 <<<< same thing to do on ALL PC-facing ports
    switchport
    ipv6 traffic-filter ACCESS_PORT in

Else, sending the real RA with high priority and a short re-transmit time could also help.

Else, NDPMON is usually pretty good as well.

Note: how does this ISP fight rogue DHCPv4 server?

Hope this helps

-éric


> -----Original Message-----
> From: ipv6-ops-bounces+evyncke=cisco.com at lists.cluenet.de [mailto:ipv6-ops-
> bounces+evyncke=cisco.com at lists.cluenet.de] On Behalf Of Tore Anderson
> Sent: dimanche 31 octobre 2010 12:06
> To: Mikael Abrahamsson
> Cc: ipv6-ops at lists.cluenet.de
> Subject: Re: How to preempt rogue RAs?
> 
> * Mikael Abrahamsson
> 
> > Well, it's good that they did it, it's bad that they didn't do it properly.
> >
> > They're the ISP, they should make sure one customer can't affect other
> > customer by means of L2 or L3 errors/trickery, either intentional or
> > unintentional.
> 
> As Steinar Haug said in another message:  We can all agree that fixing
> the shared L2 is the best solution.
> 
> However, shared L2 deployment in IPv4-only networks with rogue RA
> problems is very common, it's certainly not something the ISP in
> question was alone about.  I'm grateful to them for working with me in
> trying to solve the problem instead of just ignoring it (which is what
> most networks I've contacted do).
> 
> I'd like to come up with a solution to the problem I could present to
> the next network on my list.  However if that includes drastically
> changing the access model and/or replacing lots of hardware...  Well,
> it'd be like tilting at windmills I suppose.  I'm not even sure it's at
> all possible to insulate users from each other in all cases.  How would
> you do it in a public WiFi network?  (I've heard that even the IETF har
> problems with rogue RAs on their conference network...  If they can't
> get it right, who can?)
> 
> My hope was that deploying native IPv6 would stop the 6to4 rogue RA
> madness.  After all, there's no reason whatsoever for a OS or HGW to
> bother with tunneling when native IPv6 service is available, and
> everything would have worked fine.  Of course, the ISP would still be
> vulnerable to malicious rogue RAs, but then again they already had that
> problem with rogue DHCPv4 servers and have been able to live with it so
> far.  IMHO it's a big problem if you can't retro-fit IPv6 onto
> infrastructure already running IPv4 and at the same time keep the
> operational stability for both protocols about the same.
> 
> Best regards,
> --
> Tore Anderson
> Redpill Linpro AS - http://www.redpill-linpro.com/
> Tel: +47 21 54 41 27