Sean puts this very nicely... I was away today so I missed the rest of the traffic and looking it over alot of it was not relevant. I'll put in some comments here though. On Mon, 4 Nov 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.
Sure, so are most operators, including me. Define the edge the right way, as Sean says, though. The edge is the customer CPE, or even the LAN router inside the customer network. As close as possible to actual hosts that can spoof.
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.
In general, knowing what ips a 'peer' is going to send you is very difficult. One would hope that all peers would have all customers implement filtering as close to their hosts as possible. This isn't a reality today :( Putting filtering, of any type, in a 'core' spot is asking for trouble. Doing much other than routing at the core is a bad plan. In the future perhaps filtering and other magic would be possible in the core, but in reality it will almost always be a tough thing to do. :(
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.
This is a good point. If you are aggregating customers on gear where the uRPF filtering is done in software you will severely impact performance with anything over oc3 rates :( Do not confuse acls with uRPF, acls on t1 aggragation isn't workable unless your 'network' lives in your basement. uRPF is only feasible in some small circumstances. Making the assumption that because your network works with uRPF and thus Sean's or Ryan's or Paul's will isn't really valid. I would like to believe that the majority of NSP/ISP operators have atleast considered uRPF, or some kind of mitigation techniques. We have, and for us the current possibilities aren't feasible :( for a number of technical reasons which the respective's vendors are aware.
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.
Yes, filter at the 'edge', where 'edge' == 'as close to the host as possible'. Possibly this could be accomplished by a config default in IOS/JunOS... something akin to 'no ip directed broadcast'... or atleast that possibility was raised at the NANOG Security BOF. This won't solve any problems in the short term, but it is a move in the right direction.
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.
This is the tact that we are taking inside UUNET today. We are trying to work on a consensus document for 'Network Equipment Requirements'. This effort is being headed up by Mr. George Jones, I believe this document is headed out for IETF work and possibly additions to BCP 38 ? Barry Greene is helping out on this along with some folks from Merit. The focus of this is to get everyone possible asking for the same thing from their vendors. For a long time every vendor through the door would say: "security what?", "Filtering what?", "You are the ONLY person asking for this capability." This was the response to: Radius authentication for management access, tacacs auth for management access, auth for management access, filtering, filtering at line rate, filtering on all interfaces... the list goes on of things that one would assume are 'standard' on any network gear. UUNET, atleast, has been asking all vendors we see/speak-with/test for the list of things in George's document for the last 2 years. -Chris "Nomex, whats that?" Morrow.