On Tue, Mar 26, 2013 at 9:18 PM, Jay Ashworth <jra@baylink.com> wrote:
From: "William Herrin" <bill@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@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004