On Mar 26, 2013, at 11:19 AM, Darius Jahandarie <djahanda...@gmail.com> wrote:

> Well, I'm not sure this is what's being suggested by Jay, but many peering 
> agreements/policies have something in them that say "prevent spoofing to best 
> effort". Such statements could be strengthened in a global effort, and then 
> spoofed source addresses could lead to depeering much faster/harder than what 
> happens today. It would be reactionary rather than proactive, but still 
> better than what we have now where spoofing is kind of like "it can't be 
> helped".

I'll certainly say that I've worked for many an imperfect network when it comes 
to this.  I've always tried to drop bogons (non routed space) including spoofed 
packets.  While many a network is imperfect, there are places where we can 
improve.  The high-speed servers in data centers or part of your VM 
infrastructure is one example of a place where:

a) They aren't running BGP for multihoming with 10k prefixes 
b) have a fixed IP subnet for that edge host or management LAN
c) could quickly have unicast-rpf enabled with no impact.

If you have folks bringing in/out either known or unknown VMs, you must treat 
these as a possible risk.  Same goes for any colocation environment.

Those T1 customers you still have?  DS3 with one prefix and BGP on?  Turn on 
unicast-rpf there too.  You won't break anyone.

I recall going around and turning it on dozens of T1's at a time since they all 
had static routes.  Just because the link size is now gig-e (or 10G or 100G) 
doesn't mean it's not worth doing.

Consider this my plea to the community.  Ask the question: Can we spoof?  What 
happens when law enforcement comes to the door to confiscate a machine because 
it was involved in a 10's of gigs of attack?  what if it's 100's of gigs?  At 
what size of attack for what duration will make things change?  Are there 
simple places where unicast-rpf makes sense?  In front of the firewall is a 
simple place to drop spoofed packets.  You'd be surprised how many of them are 
broken and emit an internal IP anyways, so don't leak that.

I certainly see many places where simple steps like this will improve the 
overall ecosystem and make us safer.

Machines get compromised, but limit the scope of the possible abuse.  If 
nothing is done, will udp/53 become blackholed just like tcp/25 is for many 
folks?  Is that the type of network you want to debug and troubleshoot?

- Jared

Reply via email to