Re: [v6ops] Rogue RAs was: ULA discussion #1 ULA+NAT

[David Farmer <[e-mail]>]

On 3/6/13 15:11 , Doug Barton wrote:
> On 03/06/2013 01:06 PM, Lorenzo Colitti wrote:
>> On Wed, Mar 6, 2013 at 1:02 PM, Doug Barton <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>         we have solutions for rogue RAs.
>>
>>
>>     Did you bring enough to share with the group? :)
>>
>>
>> I think we're using the ones recommended by the IETF...
>
> So perhaps you would consider writing up a draft to describe your
> deployment experience, how robust the solutions are under actual
> testing, etc. I keep hearing from people that this problem isn't solved
> yet. If you have solid evidence to the contrary it would be most welcome.

We have a basic IPv6 inbound ACL on every wired access port blocking RAs 
and DHCP server responses for IPv4 and IPv6.  By the way, IPv6 ACL 
support was a requirement when we selected our current switches in 2004. 
  We also announce the RA from our routers with high priority.  The 
later is necessary because our enterprise wireless solution doesn't 
support IPv6 ACLs yet.  These techniques are discussed in RFC 6104.

IPv6 ACLs or an automated RA-Guard, RFC 6105, block most rouge RAs 
caused by basic malicious activity or simple misconfiguration.  Setting 
your routers RAs to high priority can deal with rogue RAs caused by 
simple misconfiguration in most cases. 
Draft-ietf-v6ops-ra-guard-implementation addresses some ways malicious 
activity can evade basic Rouge RA mitigation.  That said the we haven't 
seen malicious activity in the wild.  But, until we implemented the 
above techniques rogue RAs from simple misconfiguration were a huge 
issue.  The above techniques have made our IPv6 network very stable.

There is one additional technique we have used, that is filtering IPv6 
traffic all together with a 86DD Ether-Type filter.  This is a drastic 
solution, but is necessary in one part of our network.  We have IPv6 
enabled on our 802.1x/WPA2-enterprise authenticated wireless network, 
but the authentication portal for our web-portal authenticated wireless 
network doesn't support redirection of IPv6 traffic.  Therefore, we 
filter all IPv6 traffic on the web-portal authenticated wireless network 
to prevent rogue RAs and make our entire network AAAA record safe.  Bad 
or rogue IPv6 is worse than no IPv6.  We are working with our enterprise 
wireless vendor to support IPv6 on their authentication portal and I 
believe it is a committed feature for a future release.

Hope that helps.

-- 
================================================
David Farmer               Email: [e-mail]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: [phone]
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================