At 06:18 PM 11/4/2002, Sean Donelan wrote:

On Mon, 4 Nov 2002 bdragon@gweep.net wrote:

...

What about the other large isps? What would it take for you to do something? Chris is gracious enough to show up and participate, at least even if it does mean he has to wear nomex.

I'm in favor of source address filtering at the edges.

I'm opposed to some of the suggestions where to put source address filters, especially placing them in "non-edge" locations.

No argument there. Bogon filtering could (should?) be done everywhere, but ingress is best when done close to, well, the ingress point.

E.g. requiring address filters at US border crossings is a *bad* idea, worthy of an official visit from the bad idea fairy.

This would be a bad idea even if it were possible to clearly delineate border crossings somewhere. Many foreign ISPs collocate routers in the USA, leading to all kinds of fun questions of where borders lie in cyberspace.

Our networks, and our customer bases, are not identical. This is good and bad. Not to make excuses, the ease with which this can technically be done depends on your network and type of customer connections. Or more precisely how you aggregate customer connections.

Doing absolutely nothing, in any part of one's network seems unreasonable. For the large backbone providers, they might consider adding terms-of-service requirements for their downstreams, if they themselves can't implement on their equipment. UUNet was able to impose something like that with port 25 blocking, requiring their wholesale POP customers to add that to their RADIUS server configs. Even the Cisco RPF check that looks to see if there is ANY route to a net would be helpful. That would squelch out the packets with 0.0.0.0 source addresses and other such bogons. Cisco claims that's not even high overhead. Perhaps turning that on in the backbone routers would be worthwhile?

IMHO the edge is generally the best place to do source address filtering. After traffic is aggregated its more difficult.

Clearly. The question is the definition of aggregation. Is it the customer premesis router that must do the work, the aggregation router at the local ISP? The backbone vendor's aggregation router that regional ISPs attach to?

Some folks have already identified the technical limitations of some types equipment. And with the market, we're going to be stuck with that equipment for a while. In hindsight, if every provider and every equipment vendor did it from day 1, we would be in great shape.

Does that mean I can wave my magic wand and fix everything tomorrow? No.

Can I work on standards, vendors and purchasing agents to change this over time? Yes. Will yelling at me make it happen faster? I doubt it, but I know you will anyway.

When I first got involved in this back in 1996, this was my answer to those who complained their routers would melt. "Add it to your requirements document for your next round of purchasing" was a common comment. If you don't tell your vendors you need a feature, they won't spend their time on it. Cisco, to their credit, has been working on this issue. Their automated solutions have shortcomings, but they seem to be working on improvements. In edge cases with single-homed customers, there's really no excuse not to have an ACL to take care of the issue. The extra few lines of config (probably script generated anyway) would not hurt. Seems some folks won't even do that.