I think this discussion is pretty well played out. ------- Forwarded Messages

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.

Almost always no. Almost all BGP speaking customers are filtered by network and AS-Path. There are a couple who aren't who are filtered by network (i.e. are filtered by path only) who should know better. We are putting PRDB filtering on when we get the code ready.

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

Currently yes. Again we have PRDB filtering in the pipeline to fix this.

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

Currently yes. I do not currently plan to apply PRDB filtering to transit providers - the connectivity loss would be too great. We will also leave it off for large peers (UUnet for instance). *HOWEVER* we've got some experimental stuff which generates ACLs (i.e. filterlists) based on unallocated space, as well as BGP network filtering (the IP access group business mostly for our amusement - the real idea is to use these to automatically build customer facing anti-spoofing filters from RIPE/RA etc.). Blackholing stuff destined for unallocated blocks is neater by far. My fear is that people will instead pick an unused prefix as opposed to an unregistered one. IE if I advertize a /16 like 195.224.0.0 and the top /19 is not used, some joker will probably have a fair amount of success stealing the top /19 for a few minutes to spam with. Worse still, they probably would have a fair amount of success stealing an *inuse* more specific of a block - and that really does have nasty consequences. [ i think we can take for granted that spammers, at least, will only steal resources in ways they think won't be noticed. on the other hand, sequence number guessing such that you don't care if the recipient can EVER get a packet back to you, is probably even better by that measure. --vix ] ------- Message 2

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.

The Merit/RA/RSNG/etc folks keep logs containing every BGP announcement and withdrawal seen by the route servers.

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.

Believing any transitive source leads to the same vulnerability, whether it is BGP or a database like PRDB or IRR. The problem isn't one of too much trust or competence, but rather distrust and corporate priorities.

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.

First you have to decide what is "unallocated address space." Unallocated by whom: IANA, a regional registry, a provider, or even an end-user? And I suspect it isn't just a question of unallocated address space, but also what used to be known as "connected status." There are several allocated address blocks which are never announced to the Internet. Longest match rules of CIDR makes any network subnet that isn't actively being used vulnerable to unnoticed hijacking. The reason its important to decide what type of unallocated address space is involved is because there are a variety of ingress filters used by different providers and they stop different things. The common methods are 1) filtering by expected address, 2) filtering by AS number or path, 3) filtering by exception, e.g. blocking martian networks. Or filtering using a combination of those methods. A provider might block announcements from net 1.1.1.1, but not block 213.1.1.1. [ i am primarily interested in space which has not been allocated by IANA, or which has been allocated by IANA but not by the regional registry yet. unused portions of allocated, connected, advertised blocks are so much harder for me to track that i know i never shall track them. --vix ] Answers to your questions 1: We have a lot of backdoor connections to sites that are also connected to the former NSF regional networks. In general, we have to filter our customer connections to prevent all sorts of routing leaks, not just unallocated address announcements. BGP speaking customers provide a list of network numbers and ASNs they plan to announce. Currently they are manually verified against WHOIS and then entered into the IRR databases. BGP core routers have egress filters to prevent both unintended transit, and unknown network announcements. This also acts as a belt-and-suspenders approach to preventing unintended network announcements beyond our network. 2: All BGP peers are passed through an "Oops filter" blocking patently offensive network announcements (martians, extremely long prefixes, broadcast, loopback and default). Unallocated addresses aren't blocked (currently) by my Oops filter. A few BGP peers have explicit network address ingress filters, which would block an unallocated address. 3: Currently I don't have any source ASN/IP address cross-checking. A distant BGP-connected AS could announce any network I accept from the BGP peer in tha path directly connected to me. The same Oops filter or applies in any case. And finally, a couple of untested filters For those that prefer "if it isn't explicitly denied, allow it": ! Based on ftp://ftp.isi.edu/in-notes/iana/assignments/ipv4-address-space ! as of Dec 30, 1997, check for new allocations if used ! IANA - Reserved access-list 100 deny ip 0.0.0.0 0.255.255.255 any access-list 100 deny ip 1.0.0.0 0.255.255.255 any access-list 100 deny ip 2.0.0.0 0.255.255.255 any access-list 100 deny ip 5.0.0.0 0.255.255.255 any access-list 100 deny ip 7.0.0.0 0.255.255.255 any ! IANA - Private Use access-list 100 deny ip 10.0.0.0 0.255.255.255 any ! IANA access-list 100 deny ip 23.0.0.0 0.255.255.255 any access-list 100 deny ip 27.0.0.0 0.255.255.255 any access-list 100 deny ip 37.0.0.0 0.255.255.255 any access-list 100 deny ip 39.0.0.0 0.255.255.255 any access-list 100 deny ip 41.0.0.0 0.255.255.255 any access-list 100 deny ip 42.0.0.0 0.255.255.255 any access-list 100 deny ip 58.0.0.0 0.255.255.255 any access-list 100 deny ip 59.0.0.0 0.255.255.255 any access-list 100 deny ip 60.0.0.0 0.255.255.255 any ! IANA - Reserved 64/8 - 127/8 (Note: 127/8 is LOOPBACK, not RESERVED) access-list 100 deny ip 64.0.0.0 63.255.255.255 any ! IANA - Private Use access-list 100 deny ip 172.16.0.0 0.15.255.255 any ! IANA - Private Use access-list 100 deny ip 192.168.0.0 0.0.255.255 any ! IANA - Reserved 213/8 - 223/8 access-list 100 deny ip 213.0.0.0 0.255.255.255 any access-list 100 deny ip 214.0.0.0 1.255.255.255 any access-list 100 deny ip 216.0.0.0 7.255.255.255 any ! IANA - Multicast 224/8 - 239/8 access-list 100 deny ip 224.0.0.0 15.255.255.255 any ! IANA - Reserved 240/8 - 255/8 access-list 100 deny ip 240.0.0.0 15.255.255.255 any ! If not denied above, assume address is an allocated IPv4 unicast address access-list 100 permit ip any any For those that prefer "unless explicitly allowed, deny it": ! Based on ftp://ftp.isi.edu/in-notes/iana/assignments/ipv4-address-space ! as of Dec 30, 1997, check for new allocations if used access-list 100 permit ip 3.0.0.0 0.255.255.255 any access-list 100 permit ip 4.0.0.0 0.255.255.255 any access-list 100 permit ip 6.0.0.0 0.255.255.255 any access-list 100 permit ip 8.0.0.0 0.255.255.255 any access-list 100 permit ip 9.0.0.0 0.255.255.255 any access-list 100 permit ip 11.0.0.0 0.255.255.255 any access-list 100 permit ip 12.0.0.0 0.255.255.255 any access-list 100 permit ip 13.0.0.0 0.255.255.255 any access-list 100 permit ip 14.0.0.0 0.255.255.255 any access-list 100 permit ip 15.0.0.0 0.255.255.255 any access-list 100 permit ip 16.0.0.0 0.255.255.255 any access-list 100 permit ip 17.0.0.0 0.255.255.255 any access-list 100 permit ip 18.0.0.0 0.255.255.255 any access-list 100 permit ip 19.0.0.0 0.255.255.255 any access-list 100 permit ip 20.0.0.0 0.255.255.255 any access-list 100 permit ip 21.0.0.0 0.255.255.255 any access-list 100 permit ip 22.0.0.0 0.255.255.255 any access-list 100 permit ip 24.0.0.0 0.255.255.255 any access-list 100 permit ip 25.0.0.0 0.255.255.255 any access-list 100 permit ip 26.0.0.0 0.255.255.255 any access-list 100 permit ip 28.0.0.0 0.255.255.255 any access-list 100 permit ip 29.0.0.0 0.255.255.255 any access-list 100 permit ip 30.0.0.0 0.255.255.255 any access-list 100 permit ip 31.0.0.0 0.255.255.255 any access-list 100 permit ip 32.0.0.0 0.255.255.255 any access-list 100 permit ip 33.0.0.0 0.255.255.255 any access-list 100 permit ip 34.0.0.0 0.255.255.255 any access-list 100 permit ip 35.0.0.0 0.255.255.255 any access-list 100 permit ip 36.0.0.0 0.255.255.255 any access-list 100 permit ip 38.0.0.0 0.255.255.255 any access-list 100 permit ip 40.0.0.0 0.255.255.255 any access-list 100 permit ip 43.0.0.0 0.255.255.255 any access-list 100 permit ip 44.0.0.0 0.255.255.255 any access-list 100 permit ip 45.0.0.0 0.255.255.255 any access-list 100 permit ip 46.0.0.0 0.255.255.255 any access-list 100 permit ip 47.0.0.0 0.255.255.255 any access-list 100 permit ip 48.0.0.0 0.255.255.255 any access-list 100 permit ip 49.0.0.0 0.255.255.255 any access-list 100 permit ip 50.0.0.0 0.255.255.255 any access-list 100 permit ip 51.0.0.0 0.255.255.255 any access-list 100 permit ip 52.0.0.0 0.255.255.255 any access-list 100 permit ip 53.0.0.0 0.255.255.255 any access-list 100 permit ip 54.0.0.0 0.255.255.255 any access-list 100 permit ip 55.0.0.0 0.255.255.255 any access-list 100 permit ip 56.0.0.0 0.255.255.255 any access-list 100 permit ip 57.0.0.0 0.255.255.255 any access-list 100 permit ip 61.0.0.0 0.255.255.255 any access-list 100 permit ip 62.0.0.0 0.255.255.255 any access-list 100 permit ip 63.0.0.0 0.255.255.255 any ! IANA - Private Use access-list 100 deny ip 172.16.0.0 0.15.255.255 any ! 128-191/8 access-list 100 permit ip 128.0.0.0 63.255.255.255 any ! IANA - Private Use access-list 100 deny ip 192.168.0.0 0.0.255.255 any ! 192-212/8 access-list 100 permit ip 192.0.0.0 15.255.255.255 any access-list 100 permit ip 208.0.0.0 3.255.255.255 any access-list 100 permit ip 212.0.0.0 0.255.255.255 any ! If not permitted above, assume address is not an allocated IPv4 address access-list 100 deny ip any any [ i have to caution against installing such filters in most networks, since it will make it really really hard for us as a community to ever use that unallocated space. this is one instance where it is safer to use the RBL (which has synchronized withdrawal) than to filter things locally. though i would feel pretty great if IANA would advertise routes to its unallocated space, just to "claim" it. --vix ] ------- Message 3 Because you indicated some concern over the silent replies the first time around, I will add our "me too". We filter our outbound announcements, and specify them using network statements anyway. Injecting routes is not a good way for us to do things. Regarding route announcements we listen to, we accept them without filters, and carry full tables, so we are susceptible to remote AS's which add unallocated routes, then withdraw them. We are multihomed to only two providers, Sprint and XXX. XXX gets most of their routes from MCI, whom I believe peers with the RADB, while the Sprint peerage is likely to be more suspect. We do not allow relay mail, so we are more likely to be stung by this than inflict it on someone else. ------- Message 4

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. No, we have filters on our outgoing that allow out only the networks we are currently advertising.

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

We don't have any customers doing BGP to us, but I would throw filters down on their connection as well, so only the networks they were advertising or ones they planned to advertise could get out.

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

Connected to my AS? I think the response to 2 would apply to 3. If not to my AS, there's not much I can do about it. ------- Message 5

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. no.

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

currently yes, changed to no in a week.

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

currently yes, changed to no in a week. ------- Message 6 From: smd@clock.org

...

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.

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?

There is no right answer; it is endemic to the IP (v4/v6) addressing structure. The right thing to do is to can development on IPv6 since it (mo's proposal notwithstanding) irretrievably suffers the same problems with respect to the trust versus dynamism trade-off for external routing. Next, work on developing some of the good ideas which were abandoned after (and during) ROAD/BIGTEN in favour of the current IPv6 proposal, letting the best get picked through natural (rather than committee) selection. IOW, work out a scheme whereby translating gateways can be used to make it possible to build a multiprotocol catenet which supports current and future applications decently. Then let people choose what they want to run where. Note that this is essentially (and ironically) what Bound's NNAT amounts to, although his is more a clever hack rather than something architecturally sound. My gut feeling is that admitting that IPv4 will be around in some form or another for a long time will allow us to focus on fixing some of its near-term deficiencies, none of which have been touched on in IPv6 development. That in turn buys us more time to develop and learn from the partial deployment of alternative protocols. Current answer for the routing system: prayer? Sean. ------- End of Forwarded Messages