Fw: [spoofing-tf] BCP38 Business Case Document

Stephen Satchell list at satchell.net
Sun Apr 29 13:50:01 UTC 2007


Interesting this should come up.  I run a small multihomed network in 
Reno, NV, with a couple /21s and 65 megabits of upstream.  For the last 
few weeks, one of my co-location customers has been attacked with SYN 
floods with forged source-IP addresses, overloading the SonicWall he 
has, and when the SonicWall folds under the traffic I get ARP storms in 
that LAN segment.

Traffic capture shows that the perps are using bogus source packet 
addresses to hide their activities.  This is confirmed by my ingress 
BOGON filters, whose counters start spinning at an aggregate rate of 
6,000 packets per second.  The bandwidth impact is fairly low -- this is 
a SYN flood attack, after all.

When I contacted my upstream, he tells me that the packets were coming 
in from *every one* of his Tier 1 peers, so the packets were impossible 
to trace back to their source.  That says the injection point was quite 
a few hops away from his routers, if the traffic was able to spread that 
widely across multiple Tier 1 networks.

I had to use other means to stop these DDoS attacks.

My own network policy:

* I deny packets from my customers to the Internet whose source address 
is *not* within my assigned netblocks.  Any such attempt is logged and 
followed up.  I also specifically check for network and broadcast 
addresses, and deny packets with those addresses, too.

* I deny packets from the Internet to my customers whose source address 
*is* in my netblocks, to prevent secondary attacks. (This filtering also 
exposes routing mistakes *very* quickly.)

* I deny packets from the Internet to my customers whose source address 
appears in a BOGON list, manually maintained.  My BOGON list includes 
RFC 1918 netblocks (but see below).

* I null-route packets from my customers to the Internet directed to RFC 
1918 private-network netblocks.  This is a "belt and suspenders" type 
action, so there is zero leakage either inbound or outbound.

To implement these policies, I maintain a single copy each of the 
ingress and egress access lists on a protected TFTP server.  All edits 
of the access list go into these master lists, under version control. 
Periodically, or when necessary because of update or attack, the master 
lists are loaded into all edge routers at the same time.  This ensures 
that all routers have the *same* list, that updates are propagated to 
*all* ingress/egress filters, and it simplifies maintenance.

REQUEST FOR COMMENT:  For maintenance reasons, my BOGON rules are 
limited to full /8s.  I'm interested in comments from others on tge 
effectiveness of building in more rules based on longer prefixes, to /10 
or /12 or perhaps even /16, so that /8s with small allocations get 
better coverage in the ACL list.

TESTIMONIAL:  I have had attackers establish themselves on my network, 
and also attackers from outside try to nail a customer.  BCP38 has 
helped lessen the impact of the inbound attacks, and stopped the 
outbound attacks cold.  Most importantly, though, BCP38 allows the 
customers not being attacked to be minimally affected during any attack.

Fergie wrote:
> While we're working out problems on the IETF SAVA list, I'd like
> to float this here (if you haven't already seen it), and hear some
> comments from the NANOG landscape.
> 
> Is this relevant?
> 
> Thanks,
> 
> - ferg
> 
> [snip]
> 
> From: Daniel Karrenberg <daniel.karrenberg at ripe.net>
> To: RIPE IP Anti-Spoofing Task Force <spoofing-tf at ripe.net>
> Date: Thu, 26 Apr 2007 16:14:31 +0200
> 
> 
> Here is the latest draft of the "Network Hygiene Pays Off"
> document.  The goal is to publish this after Talinn.
> 
> Daniel
> 
> ----
> 
> "Network Hygiene Pays Off"
> 
> The Business Case for IP Source Address Verification
> 
> 
> Joao Luis Silva Damas
> Daniel Karrenberg
> 
> v0.3
> Tue Apr 24 09:45:15 CEST 2007
> 
> 
> Introduction
> 
> IP source address verification entirely prevents a class of prevalent
> reflector-type DDoS attacks, helps to track down attacking hosts and
> simplifies some network management tasks.  Yet a significant number of
> ISPs do not deploy it at the edge of their networks.  Common wisdom
> seems to be that doing so would be expensive and would only help they
> "other guy" who is being attacked.  This memo tries to contrast common
> wisdom with some facts. 
> 
> 
> What is BCP38
> 
> BCP 38 is a "Best Current Practice" document of the IETF.
> BCP 38, RFC 2827, is designed to limit the impact of distributed
> denial of service attacks, by denying traffic with spoofed addresses
> access to the network, and to help ensure that traffic is traceable
> to its correct source network.  As a side effect of protecting the
> Internet against such attacks, the network implementing the solution
> also protects itself from this and other attacks, such as spoofed
> management access to networking equipment. BCP 38 has been updated
> by BCP 84, RFC3704. 
> 
> 
> No Confidence in IP Source Addresses is Bad
> 
> Suppose you need to investigate some unusual traffic flows or you
> just plain want to analyze current traffic load.  If you do not do BCP38
> there is absolutely nothing you can get to know about the source of a
> packet from the packet alone.  You cannot trust the source address at
> all.  They packet could have entered your network *anywhere*.  Can that
> be good? 
> 
> Suppose someone launches an attack on one of your customers with packets
> that appear to come from another customer.  The victim will likely request
> that you take action and stop the harmful traffic that appears to originate
> from another customer of yours.  If you do not do BCP38 you will have
> to tell the
> victim that this traffic could come from anywhere and that you cannot
> determine very quickly where the traffic is indeed coming from. 
> 
> 
> Someone Can Pretend to be You 
> 
> Even worse, if you do not do BCP38 an attacker can launch an attack with
> packets that appear to be coming from one of the machines you operate
> yourself.  Imagine the reaction of a customer that gets attacked by such
> packets.  Are they going to trust you when you explain it is not really
> you?  What will they think if you tell them that your network operating
> practices allow such masquerading?  Imagine the cost of that. 
> 
> 
> Good Practice is Not Hard
> 
> It is not hard to prevent such a scenario.  You simply have to do BCP38
> towards your customers and drop all packets with internal source addresses
> coming in from external peerings.  Once you have done that you
> *know* exactly who has sent a packet with an internal source address
> and you also know that any packet with an external source address must
> have come in via one of the external peerings. 
> 
> Some multi-homing customers may require special configuration efforts.
> However these are neither impossible or very costly if implemented
> well. Our how-to documents explain the technical details.
> Since large classes of customers cannot be multi-homed to start with,
> you can gain a lot by starting to do BCP38 for them.
> 
> 
> Doing BCP38 Helps A Lot and Builds Confidence
> 
> Doing BCP38  helps a lot with analyzing anomalies and makes understanding 
> normal traffic load very much more reliable. 
> 
> In case any attacks or anomalies do happen, you can determine with
> any source within your own network or from any customer with
> confidence, simply by looking at the traffic itself!  The decision about
> any countermeasures can be made very quickly and without any involved
> specialist traceback analysis. 
> 
> In case the source of the attack traffic is external, you can also state
> that with confidence to your customers and take action.
> 
> 
> Reflector Attacks Cannot Happen Between Customers
> 
> If you do not do BCP38 one customer can attack another with a DoS
> reflector attack.  Consider your responsibility and possible liability
> if this were possible.  If you do BCP38 your customers cannot do this to
> each other and any reflector attack traffic has to come from outside
> your network, thus form outside your direct responsibility. 
> 
> 
> Doing BCP38 is Good Publicity
> 
> Showing that you operate your network responsibly and safely is good
> publicity; stating that you do BCP38 is helps with that.  Showing
> responsibility for operating safely discourages regulation and
> legislation of operating practices.  Consider the difficulty to convince
> policy makers that enabling users to lie about their "caller-ID" is your
> normal operating practice. 
> 
> 
> Consider All Costs
> 
> When considering the cost of implementing BCP38 in your network, you
> should consider the costs of not doing so together with the costs for
> implementation of BCP38 itself.  The savings in the network management
> area and in mitigation of DoS attacks may well outweigh the
> implementation costs.  The added good publicity and confidence in good
> operating practices should not be neglected either. 
> 
> 
> Testimonials of ISPs Who Do BCP38
> 
> [Add ISP statements about experiences, illustrating both cost and
> benefits.]
> 
> 
> [end]
> 
> --
> "Fergie", a.k.a. Paul Ferguson
>  Engineering Architecture for the Internet
>  fergdawg(at)netzero.net
>  ferg's tech blog: http://fergdawg.blogspot.com/
> 
> 




More information about the NANOG mailing list