BCP38 making it work, solving problems

Paul Vixie vixie at vix.com
Tue Oct 12 16:22:17 UTC 2004

> ...
> Example:
> the 'chris.net' network is a customer of MCI, his customer "bakker.net".
> 'bakker.net' decides 'chris.net' has priced transit cheaply this
> year/month/day and choses not to accept traffic from 'chris.net' but send
> all outbound traffic through 'chris.net'. 'chris.net' never seens routes
> for the sources sending this traffic, yet passes it along to the upstream,
> which also has no routes for 'bakker.net' via 'chris.net'.

uPRF is only one of several ways to implement BCP38.  you could do it with
contracts and reverse-SLA's and thus no technology (on your side) at all:
demand that a customer pay 10X his bill, or $1.00 per packet, whichever is
lower, if they emit packets with source addresses no explicitly named in
the contract.  why pay for expensive upgrades on your end of the link, when
all you really care about is that BCP38's rules are observed?

> Regardless, the point here is: "Things seem like they may be getting
> better, as 'security' requirements are now firmly being included into new
> equipment purchases."

that is of course good news.  but it demonstrates a pitfall in CFO-think,
which is the belief that participating in assymetric cost:benefit efforts
(where uunet bears the cost of an upgrade in order for all the non-uunet
parts of the internet to get the benefit of less spoofed traffic, and the
abuse incident costs don't drop nearly enough to pay for the upgrades) is
essentially a selfless act.

we all want cleaner ddos flows.  when we get ddos'd, we want to be able to
look at the source addresses, look 'em up in whois, and call the launch-isp,
and get things stopped.  we want to be able to turn on flow shaping and
know that an attacker can't cause us to use an arbitrarily large number of
buckets.  we *all* want these things.  even the bad guys, who are often the
victim of ddos attacks by other bad guys, want these things.

how are we going to get there?  the first thing is, some nets who want the
internet to work this way have to implement BCP38 in their own corner of the
internet.  then they have to start de-peering with nets who don't do it, and
offer a better rate to customers who do it than to those who don't.  then
they have to de-peer with anyone who doesn't require their peers and customers
to do it.  then they have to refuse as customers anyone who won't do it.

it's all very simple, and it's inevitable.  you and your CFO's have a couple
of choices to make.  first thing is, do you want the insurance companies,
government regulatory agencies, and ISO9000 people to be making these rules
or do you want to make them at the technical and business level?  (this is
called "industry self regulation" and it's an either-or proposition.)  second
choice to make is, do you want to do this early enough that you can fold it
into your normal purchase/retire cycle, or do you want it rammed down your
throat later in an irritating, short-timeframe, expensive, embarrassing way?

fergie complained about the lack of chutzpah among a community who used to
be distinguishable from other technical communities by that very chutzpah.
i agreed but pointed out that the same engineers are here, but with vastly
fewer of their buddies to help out, and vastly more supervision from the CFO
than used to be the case.  HOWEVER, there is still an opportunity to show
some leadership, and GET THIS DONE without waiting for fireman's fund and
a bunch of ISO9000 wonks to have to recognize it in a corporate risk profile.
Paul Vixie

More information about the NANOG mailing list