blocking rogue router advertisements on switches

[Eric Vyncke (evyncke)]

Typo: it is of course ICMP type = 134 (thanks Tim)

-é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 Eric Vyncke
> (evyncke)
> Sent: vendredi 6 mai 2011 9:05
> To: Gavin McCullagh; ipv6-ops at lists.cluenet.de
> Subject: RE: blocking rogue router advertisements on switches
> 
> Using an ACL to block rogue RA is the usual procedure indeed. While I cannot
> really understand (no time...) the semantic of your ACL, if you apply an
> layer-2 ACL blocking Ethernet packets with Ethertype 0x86DD, next header = 58
> and ICMP type = 136 to ports where there is no router (= not on your uplink),
> then you are 99.99% safe.
> 
> Of course, an evil attacker could insert any extension header between IPv6
> header and ICMP defeating your simple ACL but you will block all
> misconfigured PC :-)
> 
> There are other tools such as RAMOND, NDPMON and others which can also help
> mitigating this attack
> 
> 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 Gavin McCullagh
> > Sent: jeudi 5 mai 2011 18:56
> > To: ipv6-ops at lists.cluenet.de
> > Subject: blocking rogue router advertisements on switches
> >
> > Hi,
> >
> > we have rolled out IPv6 connectivity to our campus so students should all
> > use v6 where a AAAA is available.  Even if we hadn't, we'd probably still
> > be suffering from machines sending rogue router adverts, but such is life.
> >
> > We had a similar situation some years ago with rogue DHCP servers.  The way
> > we addressed that was to first use a tcpdump one-liner to detect udp port
> > 67 messages from wrong IP addresses and then to block messages with UDP
> > source port 67 on all user ports on our switches.  This might not be the
> > absolutely perfect approach, but we've found it to be pretty effective.
> >
> > An analogous approach for detecting rogue RAs, if I understand correctly is
> > to detect all icmp6 messages like this:
> >
> > tcpdump <.....>  icmp6 and ip6[40] == 134 and src host not
> $ALLOWED_RA_SERVER
> >
> > A typical captured frame looks something like
> >
> >          0x0000:  3333 0000 0001 000e 0cb1 33a8 86dd 6000
> >          0x0010:  0000 0050 3aff fe80 0000 0000 0000 020e
> >          0x0020:  0cff feb1 33a8 ff02 0000 0000 0000 0000
> >          0x0030:  0000 0000 0001 8600 ff1d 4000 0000 0000
> >          0x0040:  0000 0000 0000 0304 40c0 0027 8d00 0009
> >           <snip>....
> >
> > We use D-Link switches a fair bit which don't have IPv6 support per se, but
> > do have "packet content" filters (I think they may mean frame content).
> > I'm hoping to create a filter like this across all user ports:
> >
> > # inspect the IP protocol field and the type
> > create access_profile packet_content_mask offset_16-31 0x0 0xff000000 0x0
> 0x0
> > offset_48-63 0x0 0x0000ff00 0x0 0x0  port 1-48 profile_id 2
> > # match ICMPv6 and router adverts
> > config access_profile profile_id 2 add access_id 1 packet_content
> offset_16-
> > 31 0x0 0x3a000000 0x0 0x0 offset_48-63 0x0 0x00008600 0x0 0x0 deny
> >
> > This results in a filter like this:
> >
> >  ID  Mode
> >  --- ------ ----------------------------------------------------
> >  1   Deny   Offset 0-15  : 0x00000000 00000000 00000000 00000000
> >             Offset 16-31 : 0x00000000 3a000000 00000000 00000000
> >             Offset 32-47 : 0x00000000 00000000 00000000 00000000
> >             Offset 48-63 : 0x00000000 00008600 00000000 00000000
> >             Offset 64-79 : 0x00000000 00000000 00000000 00000000
> >
> > I can test and make sure that this will prevent the rogue RAs, but I'm
> > slightly concerned in case my filter is too general and I block something I
> > shouldn't.
> >
> > Does anyone know if this is a safe approach to the problem or am I going to
> > end up blocking some key traffic?
> >
> > Thanks in advance for any insight,
> >
> > Gavin
> >
> >