BCP38 - Internet Death Penalty

Wed Mar 27 01:18:53 UTC 2013

----- Original Message -----
> From: "William Herrin" <bill at herrin.us>

> > So, here, you mean customers of such as "Road Runner Business", who
> > have an office full of workstations and maybe some servers.
> 
> Correct.
> 
> > The goal, unless I badly misunderstood it, was to *drop forged traffic
> > coming from this sort of source (assuming you generalize "my PC at
> > home on a cablemodem" as the limiting example of this class, which I
> > do).
> 
> 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.  I run much tinier networks than most people here.

But what I *do* understand of it is: you have to run it *at the edge
concentrator*, cause that's the only device which knows which packets to
accept... since *it assigned the address for the link*.

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.

Did I miss something?  Or was I simply unclear?

> >> 2. A BGP origin-only network is required to secure its BGP-speaking
> >> borders against source address spoofing. It may also secure
> >> spoofing
> >> from downstream networks (and in fact it SHOULD do so) but it
> >> avoids
> >> the IDP so long as its BGP-speaking borders are secured.
> >
> > This is the next size up of edge network; a buyer of transit.
> >
> > This item does no good; you're expecting *the potential bad actor*
> > *not to act badly*.
> 
> At last count there are fewer than 45,000 such systems worldwide, not
> millions upon millions like in group 1. This is a manageable number of
> potential bad actors to whom the IDP would apply.

Yes.  These are the people to whom edge nodes and private non-BGP nets
speak; the tier 3 4 and 5 network providers who run edge concentrators
and assign addresses.

> Also, we're not looking to catch bad actors here. We're looking to
> catch sloppy actors. We catch bad actors at step 3 by spanking their
> upstream transit ISPs for failing to prevent source spoofing.

...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.

> > *This* is Road Runner. Also Comcast, Mindspring, and the other Top 40
> > eyeball networks. It is also, of course, larger carriers who sell access
> > in addition to more traditional transit and possibly peering.
> 
> Correct.
> 
> > AFAICT, this is the spot where source-address-spoofing needs to be
> > *enforced*;
> 
> Unfortunately, it's also the spot where system complexity reaches a
> point where as a purely technical matter, source address filtering
> isn't always possible. You can filter your customers based on the
> routes they say they plan send you and you can filter your own
> internal networks based on the addresses you assign but filtering your
> peers for falsely sourced packets can be as intractable as filtering
> your upstream for falsely sourced packets.

I don't believe that's what I said.

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

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

> >> 4. Applying the IDP _does not_ mean you cut off the network.
> >> That'll
> >> piss of your customers as much or more than it pisses off theirs.
> >> The
> >> position is untenable. Instead, the IDP consists of redirecting the
> >> offender's public presence web sites to a web site which proclaims
> >> the
> >> IDP, lists the causes of the IDP and lists the actions required to
> >> lift the IDP.
> >
> > Unless I misunderstand you there, you're suggesting that inbound
> > HTTP to
> > public websites *operated by the spoofing entity* should be
> > redirected
> > to a site that shames them? Yeah, that will piss them off less...
> > :-)
> 
> 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?

> >> To ask the CEOs to authorize cutting off access to a competitor's web
> >> site with the full support and approval of a group of recognized
> >> Internet luminaries?
> >
> > The problem with that sub-approach is that luminaries (of the scale that
> > everyone will automatically listen to them), as Jon Postel has said, do
> > not scale.
> 
> 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?

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA               #natog                      +1 727 647 1274