Main Page

From BCP38
Jump to: navigation, search
Language: English  • EspaƱol
An example of BCP38 implementation in a large DHCP-addressed network

This is BCP38.info.

What's BCP38?

BCP38 is RFC2827: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.

So this site is documentation that explains these attacks, and education that tells network operators how to configure their networks to prevent them.

If you found this site because you heard BCP38 mentioned on the 21 Oct Science Friday, welcome! We've tried to make most of the site accessible to less technical people; if there are parts you don't understand, please drop a note to moderator [at] bcp38.info.

What??

Well, the gritty details are under those links, but in short, these are attacks launched across the Internet to take websites and other services off the air, often utilizing 'bots' on home and business PCs which the owners don't even know are there.

A recent example (likely) is a DDoS on the Dyn.com DNS service provider which made a number of very high profile websites based on the east coast of the US inaccessible for much of the morning of 21 October 2016. These can be really big attacks; if enough of them are running at the same time, aimed at strategically significant targets, they could take down the internet.

No. We're not making this up.

Yes, it matters.

How do they get away with that?

DoS attacks, and their even nastier cousins Distributed Denial Of Service Attacks, are hard enough to deal with, but if the packets which comprise the attack have forged source IP Addresses, it not only becomes harder to stop the attack, it also becomes impossible to determine where it's actually coming from.

Can we fix that?

The solution to this problem, described in RFC2827, which was written some 13 years ago by Paul Ferguson and Daniel Senie, is to block IP packets entering the internet which have source IP addresses which are forged -- IP addresses that were not assigned to the device which is sending them.

Why is that the solution? Well, because at least it gives you a handle on what to drop, and to whom to report the origin of the traffic, neither of which you have when machines are allowed to send packets with source addresses which are not assigned to them.

There are a small number of situations in which such packets are not fraudulent, but that percentage is small enough to be handled with manual exceptions, even in an environment where such packets are otherwise blocked at their source -- the 'Ingress Filtering' mentioned in the title of the RFC.

Isn't that complicated?

In general: no. BCP38 filtering to block these packets is most easily handled right at the very edge of the Internet: where customer links terminate in the first piece of provider 'aggregation' gear, like a router, DSLAM, or CMTS. Much to most of this gear already has a 'knob' which can be turned on, which simply drops these packets on the floor as they come in from the customer's PC.

So why don't people do it?

Many different reasons. Some people don't know they can; some don't know they should; some purposefully think they shouldn't.

Some think that it's a 'Tragedy of the Commons' situation. I encourage those people to read this.

In almost all cases, for almost all networks, the answer is actually "yes, you should, and no, it's not really hard." We'll cover that in much more detail inside this website.




The purpose of this website is to:

  • explain in depth why source IP address spoofing happens - why IP packets might arrive at a network with a source address that isn't expected
  • give some examples of why this might happen legitimately and because of bad actors
  • show what the results can be and how ingress filtering could have made them easier to mitigate, and
  • tell network operators in detail
    • why they should implement BCP38
    • how to implement it
    • how much -- if anything -- it will cost
    • what collateral damage it may cause
    • and (most importantly) how to sell it to their bosses.

Our goal in setting up BCP38.info is to make clear that there's a problem, explain what the problem is, and give you practical advice on what you can do to help solve it.


At various places in this wiki, you'll find definitions of things which are sometimes subject to some dispute; if you have a major dispute with how something is presented, please let us work it out on the Talk pages, rather than engage in revert wars on actual articles, might we?

This site is a wiki; we encourage those of you who have domain-specific knowledge on how and why BCP38 filtering works to register and contribute it. There are still several major articles that haven't been completed yet, primarily because they pertain to networks larger than mine. :-)

Information by Audience

End customers

Network Providers

...and the ever popular

And, finally, some backgrounders

Other Resources

  • How To's - Collection of articles about identification, configuration and prevention.
Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox