- Test - lists.nanog.org

route ingress
by Paul A Vixie 31 Dec '97

31 Dec '97

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.

4 4

Re: route ingress [summary]
by Paul A Vixie 30 Dec '97

30 Dec '97

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

1 0

Bogus announcement of 205.164.62.0/24 by AGIS
by Karl Denninger 30 Dec '97

30 Dec '97

Ladies and Gentlemen, Please be advised that AGIS is announcing 205.164.62.0/24, which is inside our assigned netblocks. Their NOC is being less than completely helpful at the present time, and has refused to provide with me an ETA for a fix. Please consider dropping all peering with AS4200 until they can resolve this. I am not impressed. Macro Computer Solutions, Inc. (NETBLK-MCSNET-64BLK) 1300 W. Belmont Chicago, IL 60657 Netname: MCSNET-64BLK Netblock: 205.164.0.0 - 205.164.63.255 Maintainer: MCS Coordinator: Denninger, Karl (KD124) karl(a)MCS.COM 312.803.6271 Domain System inverse mapping provided by: CEREBUS.MCS.COM 192.160.127.125 KITTEN.MCS.COM 192.160.127.90 Record last updated on 14-Feb-97. Database last updated on 24-Dec-97 05:47:34 EDT. The InterNIC Registration Services Host contains ONLY Internet Information (Networks, ASN's, Domains, and POC's). Please use the whois server at nic.ddn.mil for MILNET Information. Loop-Core1.Mcs.Net>show ip bgp 205.164.62.0 BGP routing table entry for 205.164.62.0/24, version 58913 Paths: (3 available, best #1) Advertisements of this net are suppressed by an aggregate. Local 0.0.0.0 Origin incomplete, metric 0, weight 32768, valid, sourced, best 5696 4200 207.98.189.129 from 207.98.189.129 (209.54.146.1) Origin IGP, valid, external 5646 1239 4200 206.54.225.149 from 206.54.225.149 (207.112.244.17) Origin IGP, valid, external Community: 370016922 -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

21 45

Deciding whose network block is whose?
by Sean Donelan 29 Dec '97

29 Dec '97

When some random person decides to announce a subnet, what do providers accept as proof the person has authority to announce that subnet to the global Internet? Or the other side, when some random person calls up complaining that someone else is announcing a subnet without authorization what do providers accept as proof that the announcement is invalid? For example, lets say a difficult to reach ISP on the other side of the planet decided to announce a subnet DRA had assigned for use by one of our customers. Would major providers take my word a Hong Kong provider was wrong? Would major providers accept the registration information in WHOIS and/or IRR the network block had been delegated to me, and to no one else. Would major providers accept a statement from the APNIC that the HK ISP had never been delegated any part of the network block? What do you do when a major provider's front-line customer service personnel don't understand the problem, but says since the other person is a customer they have to believe them? Of course, the major provider can't get a hold of the customer either. Do providers normally just let customers announce any network, and only review things after receiving complaints. If so, how do such providers expect people to complain when one of their customers is causing problems. How many days, weeks, months is considered normal to reach a competent person at a major ISP that has the authority to block such a bogus announcement by one of their customers? Since some (one) major provider has a policy of not giving trouble ticket numbers when a non-customer calls, how much ruckus must be caused to get their management's attention? This can cause partial network outages lasting weeks in some cases. I hate the idea of needing to resort to things like filing formal criminal complaints because of the dumb management policy at a major provider, but it has been required in some other industries these providers operate in. Slamming is a prohibited practice for long distance carriers, and the customer can more or less easily get their phone number switched back to their original provider. How does a customer do the same thing when their IP network block gets slammed by another provider, or a customer of another provider? There seem to be major problems with several of the widely referred to network registration databases. I see Telstra (AS1221) is once again, Dec 29, 1997, announcing 3.156.20.0/24. While its possible that General Electric has an office in Australia, it seems an odd announcement. Other than Sprint's global default for 0/1 (and then SPRINT has the nerve to complain when people point default at them) there is no information in the IRR about valid origin ASNs for Net 3/8. Although Mr. Bono spoke up about some of GE's activities, other than James C. Shearer, who would have authority over subnets from network 3/8? And what to do when the listed contact has left, or worse is a generic position name (e.g. hostmaster@ or noc@). Even going by company names isn't enough, because some companies have very similar names, are merged, unmerged, sliced and diced. For example, the various companies have "Data Research" in their name, but have nothing to do with DRA. Nor is the DRA in the UK isn't affliated with the DRA in the USA. Network blocks delegated to non-ISPs were fairly easy, because it is uncommon to see subdelegations. But if you look at net 12/8 (AT&T), customer subnets are appearing in announcements from other providers. How do you decide when network blocks can be delegated, or not? In net 12/8 case, the WHOIS database lists some delegations, but the IRR shows different ones. But with CIDR it is even complicated figuring out what type of delegation was done for subnets. Take the case of 205.164.62.0 which is from a network block delegated to MCS. The history of this block is a bit odd. It appears the block 205.164.0.0/16 was first delegated on March 15, 1995 to NET99. On March 29, 1995 205.164.0.0/18 was delegated to MCS. At some point later the delegation for 205.164.0.0/16 was deleted, and AGIS was delegated 205.164.64.0/18 and 205.164.128.0/17. Something funny happened to the database, because now MCS's registration date is March 29, 2019 (a Y2000 problem?). MCS registered a portion of their CIDR block in the IRR(MCI), 205.164.0.0/19. Goodnet registered an IRR(RADB) entry for 205.164.0.0/18. AGIS and PSI have overlapping registrations in the IRR(RADB) for 205.164.0.0/16. And, of course, there is the Sprint global default route in the IRR(RADB) for 192/2. Karl complained about AGIS announcing 205.164.62.0/24, but not about 205.164.13.0/24 which is also being announced by AGIS. How do you tell the difference between a customer trying to move a delegated network address when switching providers, and someone whose announcement would cause problems. The problem of bogus routing has been getting worse. Is it going to take a disaster to get the attention of various provider's management? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 5

ip directed-broadcast
by Ken Leland 29 Dec '97

29 Dec '97

This morning Sprint dropped the icmp echo reply filter in their link (t1) to my network in mid "smurf" attack. The link was immediately swamped to the point of multi-hundred ms average transit times, normally 12ms. I removed this link from service (temporarily, I was thinking) and called the Sprint Noc to try to resolve this problem. I was informed of the following, by the manager that indicated that he handles backbone-to-customer filter policy: 1.) they will not continue to try to trace this. (they had made some previous unsuccessful efforts) 2.) they will no longer filter icmp echo reply for me, even though they understand that my link is now useless without that. They do not have cpu cycles to spare for this purpose. 3.) they do not see this type of attack very often and don't consider it much of a problem. I find this rather perplexing to say the least. Comments? This attack is an ongoing problem so I hope it is seen as an operational issue. It is beginning to be a chronic problem (4 day duration). The US Secret Service, Computer Crime Division is apparently having resource problems. I should also commend UUnet and Agis for their excellent assistance in working with me to keep my network operational. Ken Leland Monmouth Internet

4 4

Re: Seeking MAE-East Service for foreign ISPs..
by Neil J. McRae 29 Dec '97

29 Dec '97

On Thu, 25 Dec 1997 14:45:59 +0100 (CET) Winfried Haug <haug(a)seicom.net> wrote: I was told that MFS had stopped pluging in new connections to MAE-East, is this true? Regards, Neil. > Hello... > > we are going to establish a mae-east link from germany. Since it is a little > bit difficult due to the physical difference to do router-baby-sitting etc :- ) > we are looking for companies offering this service: > > -setup a cisco box at mae-east > -help to recover a lost or crashed router within a certain period (2-4 hrs). > > Could anyone give us some tips who is offering such a service. In order > to prevent ADs on this list, you could also mail me (haug(a)seicom.net) > if you dont prefer to answer on this list > > > Thx. > > Winfried Haug > > --- > Winfried Haug | SEICOM.DE & SCHWABEN.DE | Tel. +49 7121 9770 - 0 > Laiblinsplatz 12 | Internet+ISDN access & consulting | Fax. +49 7121 9770 -19 > 72793 Pfullingen | Access in STGT + RT + TUE + BB + LB | Rack +49 7127 989- X > haug(a)schwaben.net| 150*ISDN (64kb/X.75) / 100 * K56flex | Rack +49 711 9675 -X > haug(a)seicom.net |SAP-OSS * FTP * TELNET * NETNEWS * IRC | Rack +49 7121 709- X > * 10 MBit DE-CIX * 2 MBit INXS * 3 MBit ecrc/ebone * 2 Mbit Belwue * 2 Mbit W IN > > -- Neil J. McRae. Alive and Kicking. Domino: In the glow of the night. neil(a)DOMINO.ORG NetBSD/sparc: 100% SpF (Solaris protection Factor) Free the daemon in your <A HREF="http://www.NetBSD.ORG/">computer!</A>

2 1

Automatic filtering - CISCO, you should think about this...
by Karl Denninger 29 Dec '97

29 Dec '97

Hi CISCO :-) I know this isn't their list, but since most major network providers run their stuff, this is as good a place as any to talk about this. How about an interface keyword such as "auto-inbound-filter", which does this: At STARTUP and when the LOCAL route table changes (ie: "ip route xxx..." statements) the system looks at the interfaces, and the local static routes, and builds an accept list for that interface. The list is stored in a "reserved" set of system access lists. Add a parmaeter which can be turned on (ie: log) which would add "log" to the end of the filter lists, so that anyone TRYING to smurf will get logged This would totally automate the process of inbound filtering to prevent or severely limit smurf attacks. Since filters which are based only on the source address are relatively cheap for the router to process, this would likely not seriously burden anyone in their direct connections. I'd love to see something like this, and it would reduce the complaint that its "too hard to manage" such things. -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

4 4

Re: smurf, the MCI-developed tracing tools (was Re: Bogus announcement) (fwd)
by Adrian Chadd 29 Dec '97

29 Dec '97

On Sun, 28 Dec 1997, Phil Howard wrote: > > ICMP floods vs TCP floods. Aren't they both IP or have I missed something > > glaringly obvious. > > ICMP floods have a greater impact because they can do broadcasts and cause > a storm on a LAN whereas TCP or UDP will only be a simple attack. Agreed. A flood is a flood of course of course.. expect when that flood is a horse.. oh wait. Wrong train of thought. Just think. I have a shell account on a KRaD 3li+3 shell box on a DS3. Some little lamer on a modem is annoying me. I go and flood their upstreams T1. Not as ugly as a smurf attack, I'll grant that one. But its still a flood. And when people start getting bigger links into their homes, it might become a problem. Adrian

1 0

Re: Whoa; the 3 network?
by Steve Blair 28 Dec '97

28 Dec '97

IMHO the 3, 10, and 32 networks are just the tip of the iceberg. Speaking from both sides(15 years networking as well as similar time doing applications), NAT, SOCKS, etc, are only pushing out the inevitable window. Networking professionals need to be actively promoting to applications vendors(and yes Virgina, I am internally) the inherent evils that all too commonly come with private address space. When applications clash with reserved address space, all pay. Consider the outsourcing companies, some of whom I've visited. Many companies are using private space already, most of whom are outside of the USA. Applications specifically written utilizing IP addresses, regardless of DNS space, etc, are prolific alover the place. As a result, any technology utilized by major, or minor ISP's will have a potential dangerous side effect, when things like DoS are concerned. Why? Because when you run a NOC, and you outsource, and a customer site is involved in something like smurfing, you're not going to know from whence the packets have come from. -- steve c blair tivoli systems inc sblair(a)dev.tivoli.com "And someday, with enough marketing thrust, pigs could fly"

1 0

What is this?
by Alex Rubenstein 28 Dec '97

28 Dec '97

Good morning. MCI, you got your ears on? whi4#sho ip bgp 206.239.237.226 BGP routing table entry for 206.239.237.226/32, version 1481803 Paths: (1 available, best #1, advertised over IBGP) 3561 204.70.65.53 from 204.70.65.53 (204.70.65.1) Origin IGP, valid, external, best Community: 666 Tracing the route to 206.239.237.226 1 border1-serial3-3.WestOrange.mci.net (204.70.65.53) [AS 3561] 4 msec 16 msec 4 msec 2 core1-fddi-0.WestOrange.mci.net (204.70.64.17) [AS 3561] 4 msec 4 msec 16 msec 3 core1.Atlanta.mci.net (204.70.4.141) [AS 3561] 56 msec 32 msec 40 msec 4 dec3800-1-fddi-0.Atlanta.mci.net (204.70.2.61) [AS 3561] 32 msec 60 msec 60 msec 5 dec3800-1-fddi-0.Atlanta.mci.net (204.70.2.61) [AS 3561] !H !H !H Any ideas?

4 3