Re: Alpha test of MAE filtering capability
At 07:49 PM 1/30/97 -0500, Matthew E. Pearson wrote:
Or you could just your the RADB Route Servers like a reasonable ISP :)
Dear Mr. Pearson, I just noticed a message right before this from Stan Barber, directing people to a search engine for NANOG notes. I suggest that you hop on that site and search from something like "default route", "peering" (which ought to be fun to read anyway), and maybe "peering abuse" or something like that. In fact, you may want to browse through the entire site, and become familiar with the last NANOG before you go jumping around and sticking your foot in your mouth. However, you are most likely a busy person, so I'll graciously pass on my thoughts (having attended the most recent NANOG meeting in A2), concerning Mr. Feldman's announcement. During that NANOG, concern was expressed over the ease of abusing the exchange point by pointing a default route at any member of that exchange point. Obviously this only works on an exchange point where any entity can reach any other entity whether or not a peering agreement exists (a feature pointed out by our friends at the ATM NAP's). The solution that Mr. Feldman allows us to at least eliminate possible abuse from non peers. If a peer chooses to commit such abuse, one can just terminate the peering session, a stiff penalty in our current times (considering the increasing difficulty of obtaining valuable peering agreements), and add that entities IP address to the above mentioned filter list on the exhange point switch. We, who were recently a victim of such abuse, will definately use this feature as soon as it is made available. Thank you for your patience while reading my take (and this is only my take) on this subject. Hope to see you at the next NANOG on Feb 10th & 11th. Chris A. Icide Nap.Net, L.L.C.
The solution that Mr. Feldman allows us to at least eliminate possible abuse from non peers. If a peer chooses to commit such abuse, one can just terminate the peering session, ..., and add that entities IP address to the above mentioned filter list on the exhange point switch.
We, who were recently a victim of such abuse, will definately use this feature as soon as it is made available.
I think that this is the wrong approach. Better to monitor it, prove that it happened, and remove offenders from the IXP's altogether. The IXP contracts should include just such a provision. In CIX's case, we want to be able to send third-party BGP among members so that those members will get eachother as next-hop and therefore get better throughput (and put less load on the CIX routers.) I've fought with this on PB-SMDS and now I'm seeing it on DEC PAIX. We should remove from the Internet community anyone who commits theft of service by pointing default at someone else -- but we should not make valid third party BGP topologies difficult or impossible. Your fellow IXP members are deserving of your trust, until they show that they aren't, and the paternalistic "let's remove the temptation" approach is just offensive.
Paul A. Vixie writes:
Your fellow IXP members are deserving of your trust, until they show that they aren't, and the paternalistic "let's remove the temptation" approach is just offensive.
Well, fundamentally it comes down to the fact that it's easier to make sure it can't happen than to figure out that it is happening and make someone stop it. If you can just avoid the subject entirely, it's much easier. (3rd party BGP is also not an unalloyed win.) Of course, if you don't agree with this viewpoint then you can certainly not filter in the networks you run. That's your choice.
the paternalistic "just remove the temptation" approach is offensive because it makes the starting assumption that the other people on the net are out to rip you off. it also makes the assumption that you'd rather they try and fail than that they try and get kicked out of an IXP. it's true that third party BGP is often the wrong solution, but it is sometimes the right solution, too. pointing default at someone is not unlike sending spam, in that both are theft of service. i know that in the case of spam we try where possible to make it useless to inject spam, but that our strongest weapon has always been and will always be cancelling accounts, UDP'ing whole domain names, and blackholing network blocks. a bad person ought not be presented with "if i do this it may not work" but rather "if i do this i will be wiped off the face of the 'net." port filtering makes all the wrong assumptions and solves none of the underlying problems. it is, however, easier than doing the right thing.
participants (3)
-
Chris A. Icide -
Joseph Malcolm -
Paul A Vixie