If you reply to this, be sure your MUA respects the "Reply-To:" field above. I forgot to mention in my offer to summarize that no quotes will be identified since this is a potential security hole to some people with some neighbors. I am actually quite surprised that abuse of unallocated address space hasn't come up before now. I guess spamming was the first natural application for it. If I get more traffic on this topic I will summarize it also. My conclusions so are are: (1) most people know the importance of and the procedure for strict controls over end-system routes they inject, even if not everybody does it; (2) degree of enforcement of (1) is probably going to be a term of most peering agreements by this time next year; (3) enough folks are enough opposed to the RADB that intermediate-system route control probably won't come that way; (4) this is similar enough to other things known to be wrong with the BGP security model that we're probably in for a long march before we see work complete on it; (5) to the extent that abusers of unallocated space are spammers, the MAPS RBL is the only short term hope i have of controlling this. Thanks to all who replied. ------- Forwarded Messages

routing core allow it? subquestion 1: if the spammer is your customer.

While the route would propogate to my ibgp network in some cases, it would not be announced to the internet. I would be spammed, but my peers would not hear the announcements. [my net] filters its announcements to peers at the AS and IP address level. Only known-valid addresses of our customers are propogated to our peers.

subquestion 2: if the spammer is a customer of one of your BGP peers.

I would accept it in all cases.

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.

I would accept it it all cases. ------- Message 2

routing core allow it? subquestion 1: if the spammer is your customer.

no, we filter on the prefixes we announce.

subquestion 2: if the spammer is a customer of one of your BGP peers.

yes, we don't screen routes with an existing database

subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

yes, we don't screen routes with an existing database

i've sent reply-to to myself. i will summarize responses back to the list.

Just FYI, 2 of my 3 upstreams (namely Sprint and AGIS) would allow me or other customers to spam willynilly from unallocated ip's - namely they do not me filter on announced prefix. One of my upstreams, UUNET would not allow this - they make me call up with each new prefix I want to announce. Wow, thanks for the info, next thing these guys will be doing is spamming from cracked machines, like syn bombers. [ they do this now, at various levels of crackage. --vix ] ------- Message 3 [ this was randy's note, which he later recanted in mail to jhawk. --vix ] ------- Message 4

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.

1. No 2. Yes 3. Yes (The solutions to 2 and 3 are on the "list of things to do" but you know how that goes sometimes) ------- Message 5 Since this is a worthwhile question, it deserves to be answered, presuming that the names will be changed to protect the innocent, guilty and the lazy. [ yes. --vix ]

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.

Our answers are: No, our routing core would not allow spam from unallocated space 1. still no, except for a few "trusted" (bad word) BGP customers. 2. um, yes to some <sound of hand being slapped> (no to some and this list is growing). 3. yes, as we do not filter from our upstream (UUNET, AS701) Of course, for this to be no, the access-list is a bit extreme. ------- Message 6

routing core allow it? subquestion 1: if the spammer is your customer.

Nope.

subquestion 2: if the spammer is a customer of one of your BGP peers.

Almost certainly.

subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

I'm not sure what this means. if they're behind a customer then no. if they're behind a peer, then yes. If they're behind something else I'm not sure what the other somethings are. [ i should have been more explicit. i meant behind peers-of-peers-of-peers. i'm imputing a "yes" answer from you in that case. --vix ] ------- Message 7 We filter all BGP announcements from our customers and limit the = announcements to address space belonging to them or their customers. We = make them tell us what they are going to announce and we verify their = ownership of the address space. Yes, it is time consuming. I hope our policy sounds anal as we try to be as anal as possible with = IP sourcing and BGP announcements. [ you're being liberal in what you believe and conservative in what you generate, which is the classical internet approach, and which has led to spam-as-we-know-it and is about to cause wide scale problems in the routing system as well. --vix ] ------- Message 8

routing core allow it? subquestion 1: if the spammer is your customer.

Not unless the spammer was also a BGP feed from us (extremely rare; we don't BGP feed or accept from people who aren't actually multihomed, we static-route instead). If we had ANY reason to suspect that something like this was going on the BGP connection would be terminated with extreme prejudice. This kind of game requires active cooperation by the injector of the bogus route, and that means they're responsible. [ agreed. --vix ]

subquestion 2: if the spammer is a customer of one of your BGP peers.

Possibly, yes. We can't verify that a BGP peer is announcing only "good" things to us since we don't peer with the RADB (or similar).

subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

Yes. This one is rather impossible to prevent with the current technology unless you know of a way to do this that I'm not aware of. Indirect announcements (those with more than one external element in the as-path) are virtually impossible to verify or craft filters to handle, unfortunately. [ not really. give me three hours with the RADB and pathalias/pathparse and i'm sure i could hack something bloody and sticky together. whether there is a NOVRAM anywhere in the world large enough to contain the result is a separate question with a different and fatal answer. --vix ] ------- Message 9

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.

Yes to all, Sorry! But some of our transit providors do filter on address space, Digex, NAC and genuity being those three. I will have RPSL/RADB filtering sorted soon as I get the time. ------- Message 10 We filter input routes from our customers that we BGP peer with. We only redistribute static routes for customers that we do not peer with. We accept full routing announcements from our NSPs, Sprint and MCI. I know MCI filters what they hear from their customers, but I know Sprint is not very good about it. So we would be susceptible to bogus routes from Sprint and MCI. ------- Message 11

routing core allow it? subquestion 1: if the spammer is your customer.

No, all of our customers are filtered both on AS-path and network prefixes.

subquestion 2: if the spammer is a customer of one of your BGP peers.

We do not in general filter our bi-lateral peers. Those going through the RADB (about 25%) of course would not work unless they created and deleted routing objects.

subquestion 3: if the spamemr is a customer of a distant BGP-connected AS.

Probably it would work to us. ------- Message 12 [ someone answered obliquely... ]

one day the routing will collapse; you would think people might have been frightened by recent redistribution or deaggregation disasters, but people go blithely on not filtering.

[ and i followed up... ] there are a lot of fence sitters such as myself who know that filtering is good but who don't want to maintain 10,000 element filter lists for big peers like uunet and who don't want to just trust sprint to do the right thing and who don't want to run RPSLmumble. what's the right answer? ------- End of Forwarded Messages