ARIN-2011-1: ARIN Inter-RIR Transfers - Last Call (expires in one week)

Valdis.Kletnieks at vt.edu Valdis.Kletnieks at vt.edu
Fri Nov 11 19:11:20 UTC 2011


On Fri, 11 Nov 2011 16:04:31 GMT, Nick Hilliard said:
> another practical upshot is that switch manufacturers now need to support 
> both RA Guard and DHCPv6 snooping instead of just a single protocol like we 
> have in ipv4.  That is, unless you're ok with the idea of arbitrary 
> priority RA packets floating around your network.

When did I ever say I was "OK with the idea"?

Our single biggest network security issue is the fact that every day, one or
two dozen of our users manage to get phished or hit by a drive-by, have their
credentials stolen, and then often get used to send through enough spam to land
us on various block lists, at which point the NANOG lurker in the next cubicle
has a Bad Day because he's part our e-mail team.  Most of the time we catch it,
and the user has a Bad Day because they have to deal with the fallout of
getting compromised.  But this stuff would happen if it was IPv4, IPv6,
IPv5.437 or tin-can-and-string.

RA Guard is so far down the list of *actual* day to day net operations issues
it's not funny.  I think the the last time we had to put the smackdown on
somebody advertising 2002: was like a year ago.  Yes, RA Guard is a
consideration.  But the subnets we *really* care about are more-or-less
physically secure, and the hosts are secure, so we don't see many RA games on
critical subnets unless we've *already* got a critical security event in
progress.  Dorms and the like are easier to RA-spoof - but our switches are all
managed, the symptoms of an RA issue are known to our NOC, and when we have an
issue, the offending port suddenly loses link. ;)

Would it be *nice* to have RA Guard and DHCP6 snooping in place? Yes.  Is it
totally impossible to deploy IPv6 until they're fully baked? Not at all - just
need to be aware of the issues and be prepared to mitigate.  Sure it raises the
risk level slightly - but we judge the risks of not being well-positioned for
IPv6 to be *much* higher.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111111/3aab9e4b/attachment.sig>


More information about the NANOG mailing list