i've been tracking some spammers through unallocated address space of late. i'm about to have to turn on extreme-level debugging in my bgp speaker, since what's been happening is that a route is injected "somewhere" to unallocated space, a whole boatload of relayspam is unloaded in a matter of minutes, and the unallocated-space route is withdrawn. so i read with some interest the recent nanog discussions about how folks knew that a given customer really was the owner of some prefix they wanted to use. while i heard some good answers from some well known parties, the silence from the ramparts was deafening. a lot of younger ISP's inject their IGP into their EGP. we hear about this when autoaggregation fails, but we don't hear about it when routing table bloat doesn't cause us to focus our attention on it. older ISP's all or mostly all know that everything they inject into their EGP should be a nailed up static, and that the multihomed exceptions are few enough to treat as one-off's. however, when you set up BGP peerage with somebody, you're at the mercy of whatever level of selectivity they use in their injections. that is, most folks do not use RPSL or the PRDB or whatever to control what they'll listen to from a BGP peer. the assumption of trust and competence still runs high among people who speak BGP to each other. so the question that's got me perturbed at the moment is, if a spammer wanted to spam from unallocated address space using five minute windows, would YOUR routing core allow it? subquestion 1: if the spammer is your customer. subquestion 2: if the spammer is a customer of one of your BGP peers. subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. i've sent reply-to to myself. i will summarize responses back to the list.
however, when you set up BGP peerage with somebody, you're at the mercy of whatever level of selectivity they use in their injections. that is, most folks do not use RPSL or the PRDB or whatever to control what they'll listen to from a BGP peer. the assumption of trust and competence still runs high among people who speak BGP to each other.
only among those who have not been burned.
so the question that's got me perturbed at the moment is, if a spammer wanted to spam from unallocated address space using five minute windows, would YOUR routing core allow it? subquestion 1: if the spammer is your customer. subquestion 2: if the spammer is a customer of one of your BGP peers. subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.
no to all, of course. filters are your friend. filters are your friends' friend. randy
filters are your friend. filters are your friends' friend.
Yes, but centralized database is not the answer. For one, it is liable to be screwed up completely from time to time (that much, InterNIC experience shows us). It is expensive to maintain; and the problem of accuracy of the information within is quite acute. The political implications of a cenrtalized agency are even worse; i do not think we want a replay of the domain name debate. The only real solution is strong cryptographical authentication of the ownership of routing prefixes. For some reason i do not see any serious work in that direction being done. For now, it may be a good idea for tier-1 providers to adhere to a procedure similar to that used (or used to be used) by Sprint: no customer routing information is accepted before customer's border box configuration passed inspection by Sprint staff. No-nos included unfiltered redistribution of IGP into BGP and lack of anti-transit AS-path filters. ---vadim
At 04:13 PM 12/30/97 -0800, Vadim Antonov wrote:
filters are your friend. filters are your friends' friend.
Yes, but centralized database is not the answer. For one, it is liable to be screwed up completely from time to time (that much, InterNIC experience shows us). It is expensive to maintain; and the problem of accuracy of the information within is quite acute. The political implications of a cenrtalized agency are even worse; i do not think we want a replay of the domain name debate.
The only real solution is strong cryptographical authentication of the ownership of routing prefixes. For some reason i do not see any serious work in that direction being done.
For now, it may be a good idea for tier-1 providers to adhere to a procedure similar to that used (or used to be used) by Sprint: no customer routing information is accepted before customer's border box configuration passed inspection by Sprint staff. No-nos included unfiltered redistribution of IGP into BGP and lack of anti-transit AS-path filters.
Vadim, Your policy above is unwise from the perspective that it seems to believe that configuration errors are a one time problem. A more reasonable policy is to help your customers learn how to setup filters properly, and then filter heavily on /your/ router to make certain hat no matter what they do they can't effect either your internal, or external routing. ************************************************************** Justin W. Newton voice: +1-650-482-2840 Senior Network Architect fax: +1-650-482-2844 PRIORI NETWORKS, INC. http://www.priori.net Legislative and Policy Director, ISP/C http://www.ispc.org "The People You Know. The People You Trust." **************************************************************
for customer routes, the irr has been demonstrated to work well. not for peers. randy
participants (4)
-
Justin W. Newton
-
Paul A Vixie
-
Randy Bush
-
Vadim Antonov