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.
Here we agree, I believe the difference might be that you don't consider the edge of your network to be the edge. If the edge only encompasses where "Joe Bob" connects, then we have no belt and suspenders for when things go wrong. It also allows the largest isps to continue doing nothing or very little.
I'm opposed to some of the suggestions where to put source address filters, especially placing them in "non-edge" locations. E.g. requiring address filters at US border crossings is a *bad* idea, worthy of an official visit from the bad idea fairy.
What is bad about filtering facing non-customers, if loose rpf is used? I'm assuming this is what you mean by "border crossings" rather than the literal.
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.
Is there anywhere you can apply rpf today, while working towards the rest for tomorrow? I can't speak for everyone, but I like it when people do what they can. I don't personally have RPF deployed "everywhere" in the network I run, but I am deploying it, piece by piece. "Progress, not perfection" as the saying goes.
IMHO the edge is generally the best place to do source address filtering. After traffic is aggregated its more difficult. 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.
The only equipment I'm heard here which has serious issues related to feature availability is the 12000 (which was never a particularly good aggregation device to begin with). RPF works fine on 7200, 7500, and 6500, from my experience. I've not used 12000's for customer aggregation since they historically haven't been designed for or adequate in that respect. As such, I can understand providers not being able to apply RPF immediately on 12000's, at least unless they are acquiring E3 cards for new installs.
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.
All I asked for in my last message was whether folks were making progress, and if they weren't to point out the trouble areas so we could all pool our collective resources to address the stoppage. This doesn't mean full deployment must occur by tomorrow (I'ld fail), but that it be something each network is working towards. However, we never hear "we're working on deploying rpf, but having snags" but hear instead "rpf won't work for us". The latter always feels more philosophical than technical, even if there are real technical issues at play. If there are technical issues, I want to help in getting them addressed (short of buying folks gear appropriate for customer aggregation, sorry I don't have money to donate). So, in this vein, is there gear other than old 12000 linecards that can't do RPF? Is anyone still using 2500's or 4500's? What non-hardware reasons are there not to do some flavor of rpf? Is there a situation where even loose rpf will not work?