BCP38 - Internet Death Penalty

Wed Mar 27 13:37:15 UTC 2013

On Tue, Mar 26, 2013 at 9:18 PM, Jay Ashworth <jra at baylink.com> wrote:
>> From: "William Herrin" <bill at herrin.us>
>> Indeed. But it isn't achievable. $Random_SOHO will continue to be
>> hacked on a regular basis. He doesn't have someone working for him
>> with the skill to prevent it. Further victimizing him with a game of
>> whack-a-mole helps nobody.
>>
>> Besides, his failings aren't important to us. What's important to us
>> is that his failings don't impact us. We achieve that by insisting
>> that his ISP not leak his forged packets on to the public Internet. It
>> would be nice if his ISP didn't accept the forged packets at all, but
>> that's really not our problem and we don't need to make it our
>> business.
>
> It's possible I badly misunderstand how things like unicast-rpf work,
> Bill.

No, you're pretty close. The technology known as unicast-rpf works
anywhere there's a choke point where traffic to and from a given set
of IP addresses has no other candidate paths.

> When I say "drop forged traffic coming from...", *who I mean is 'his ISP'*,
> as you suggest in the next graf.  I don't see that there's anyway to *know*
> packets have a forged address anywhere north of the edge of the lowest tier
> IAP the connection is served from.

RPF is but a subset of source address filtering strategies, the one
where the source address filtering always mirrors the routing table.

As a origin-only BGP AS, I know exactly what sources I expect to leave
my system. And my ISPs know what source addresses I've told them to
expect. RPF won't work reliably on those links, but they can be
configured manually or with a tool to accept only the source addresses
I've declared.

If I declare 0.0.0.0/0, a reasonable ISP understands that I'm lying.
If I declare a particular /24 and two days later the ISP gets a trace
request from the apparent registrant (who isn't me) it's not hard to
infer that I may be a bad actor.

> Did I miss something?  Or was I simply unclear?

The problem with RPF is that understanding where you can and can't
employ it is part of a senior network engineer's skill set. But the
trivial network architectures where it can be applied are often handed
off to a junior network engineer.

The skill set is available primarily in the places where it can't be used.

> ...which you would detect ... how?  *Those* aggregator networks have
> no contractual reason to know what's a valid address coming to them,
> unlike the networks to which end sites attach directly.

They most certainly do have a valid contractual reason to know what
routes and source addresses their origin-only AS customer intends to
send them and the responsible transit networks already do filter those
links.

> Filtering based on routes doesn't help; that's *destination address*, not
> source, no?

Except for the special case where RPF is usable, that's correct.

> Yes, filtering your peers, or even transit customers, is effectively
> impossible; it has to be done where addresses are handed out.

Filtering that subset of your customers which consists of non-BGP
speakers and BGP origin-only networks is neither impossible nor
particularly hard. Harder than "rpf on", but not hard. Even if they
lie about what addresses to expect, they're not left with carte
blanche to impersonate any address at all.

The more transit BGP systems which do this, the smaller the spoofing
problem becomes. And there are few enough _transit_ BGP systems (less
than 10,000) that they can be realistically and usefully held
accountable for a failure to do so.

>> I don't care about about pissing them off. I care about pissing off my
>> customers. My customers will be pissed off if they can't reach their
>> customers and suppliers. Who will often be hosted by the target of the
>> IDP. But will much more rarely be the target of the IDP.
>
> Ok; I apologies; I have laid the bike down in the sandy corner at
> this point.  Huh?

My leeway with the CEO ends when I lose customers. So does yours.

For an IDP to be acceptable, the Penalty part has to be something
painful to the offender without pissing off my customers. Cutting him
off the network pisses off my customers who can no longer reach his
customers. It's why no one wins a peering battle with Cogent: Cogent
is willing to take the heat.

Deep sixing the packets to his particular web site is far more
tenable, especially when paired with an explanation of the credible
threat he poses to my customers' networks.

>> Which is A-OK because if we're applying more than 1 or 2 IDPs in a
>> year to folks who weren't intentionally bad actors then we're doing it
>> wrong. It shouldn't ever "scale."
>
> Yes, but you can't measure such a panel on output, you have to measure
> it on *input*, no?

Not particularly. There's nothing wrong with picking the worst current
offenders and letting the rest slide with a warning to clean up their
act or be next on the list.

Regards,
Bill Herrin

-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004