- NANOG - lists.nanog.org

RE: Deciding whose network block is whose?
by Dave Van Allen 01 Jan '98

01 Jan '98

Sean, FASTNET filters on prefix and mask, AS and "authority", that being a combination of the whois database and the radb. If the customer wants to announce a new prefix, they must first have the radb matching the announcement and the IP allocation has to be assigned to them by a verifiable means, such as the NIC/ARIN. I we originate the route, we will ensure that the databases are up to date. All new BGP peers are also password authenticated, and we are converting current peers to that as well. Global tables from our peering and customer DS3 connections are passed through a ACL that checks for illegal routes, host routes and reserved numbers. We had an instance where a customer of ours notice that someone else was announcing a more specific from their /18. It wasn't easy nor fun to make this stop. It required many panic calls and a lot of aggravation. It's just too easy to do, both intentionally and by mistake. And then there is the potential of BGP DoS attacks to further complicate things. Maybe each BGP update for a route might pass some sort of identity flag in the pre-amble that provides a trace of how the route arrived, and perhaps something like the serial number of the originating router. Then someone more cleaver than I can come up with a way to use that extra information to more quickly trace and disable bad or invalid announcements, or use that information in some fashion to authenticate the Good Guy from the Bad Guy. It ain't the ol' Internet no more. Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions At 09:17 AM 12/29/97 -0600, Sean Donelan wrote: >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 > ************************************************************** 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." **************************************************************

1 0

Looking for unidirectional simplex satlink
by Hank Nussbacher 31 Dec '97

31 Dec '97

Can anyone point me at satellite providers who provide Internet unidirectional (simplex) satellite transmissions at E1 speed (unshared, non-broadcast), other than Interpacket, that cover the Middle East area? Thanks, Hank

3 2

Here we go again...
by Jay R. Ashworth 31 Dec '97

31 Dec '97

I guess whois is broken again, at least partially... I was hunting the HylaFax home page, and went off to whois(1) 'tpc.int'... who aren't listed. There isn't something I should know, is there? Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592

7 7

Re: route ingress
by Tony Li 31 Dec '97

31 Dec '97

> 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. Actually, it is being done. It's not ready for implementation yet. Tony

1 0

re: route ingress [summary 2]
by Paul A Vixie 31 Dec '97

31 Dec '97

One thing I've heard several times now is "yes, I share an unrestricted IGP with some set of customers and so my net could be victimized by this trash, but we filter on egress to our BGP peers so we could not be a conduit." This is new and useful information for me -- it may mean that only a multinational network could get one of these prefixes into enough end systems to matter, and MOST (hint, hint, nudge, nudge) multinationals are doing static ingress. This problem may be solvable with small deltas in only a few bad spots. (You know who you are, we'll talk in Alburqurque.) The other thing I've learned from this escapade is that when folks think they can talk on NANOG without anyone flaming them by name afterward, some folks talk who normally don't. This may say something bad about the way we treat each other -- not everybody whose participation I value has thick enough skin to put up with my manners, much less those of some folks here I could name. ------- Forwarded Messages I am not replying to provide any sage input. I have none. I'm pretty new to BGP in general. I'm replying mainly to say thanks for directing a discussion that, to me, is fascinating, and from which I hope to learn a great deal. [ well, i'm not a real routing guy but i'm glad to help illuminate a topic. --vix ] I'm one of those newbies who is having to come up to speed in a hurry. I began contracting with XYZZY on a somewhat unrelated network upgrade project. Basically, for the time being, I've inherited the future of the network. I've done lots of IP networking, just not on this high a level, until now. I'm lurking. It's a tough crowd out there on NANOG. :-) My goal is to make/keep XYZZY a responsible networking outfit while learning enough to keep myself employed. :-) I won't take anymore of your time. I have included below a belated response to your earlier query. >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; I think so. We announce static routes only for those CIDR blocks allocated to us. >(2) degree of enforcement of (1) is probably going to be a term of most >peering agreements by this time next year; OK, I promise to bring it up when we next agree to a peering arrangement >(3) enough folks are enough opposed to the RADB that intermediate-system >route control probably won't come that way; I'm a newbie. I'm still working on understanding all the inner workings of RADB. I know what it does, but not how it works. [ so far it has run aground on the old prescriptive/descriptive debate, and some significant large providers have not joined the party. needless to say, it won't solve THIS problem until EVERYBODY uses it. --vix ] I believe the following three responses re true of our network as well > 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 would accept it it all cases. ------- Message 2 1. Currently, we filter what is advertised to our upstream providers so it would not get advertised to the Internet at large, but it would be propagated through our IBGP mesh and to our BGP peers/customers. So, I guess this is a "mostly" no. [ this is sometimes called "unintended transit" and it's a large enough problem that it's probably worth solving for operational reasons even apart from the security issues. you should filter on egress to your BGP neighbors no matter what. you should filter on ingress where possible, and use static ingress with any single homed customer. --vix ] 2. We do not filter inbound announcements from BGPpeers/customers/upstreams, so yes. We do plan to generate filters from IRR for the smaller ones in the near future (once they keep their information up to date), but it seems infeasible to do so for upstreams such as MCI, UUNet, etc. given the size of the resulting filters. [ yes, i worry about the large ones too, but way down below i'll waffle. using the IRR wherever possible makes sense unless you have high BGP wizardry on your staff in which case you'd want all the knobs to yourself. --vix ] 3. Yes, and I don't see a practical way to do it given current technology. When you talk about fixing the problems by changing BGP, I am curious what design you would propose to fix this. As I see it, the only practical way to validate advertised routes automatically is using digital signatures of address delegations, and validating the chain of delegations back to a root (configurable in the router). [ yes, that's my thinking, and it's also what i've heard from the security folks. --vix ] One problem with this is that the bandwidth required to exchange routing information will increase dramatically, as well as the memory required to store the routing information (since a peer will have to be able to pass on the certificate of a received route object). Do you see another solution to the problem? [ here's the promised waffle. routers have been getting bigger, and despite the lamentations of the "i want a routing table i can count on one hand" crowd, they are going to keep getting bigger. if IOS were still scalable, cisco would be selling MasPar-like RP's with a gigabyte of ram (expandable). then we have bgp itself, which is a delta protocol based on reliable TCP for its statekeeping, so other than at startup or during heavy route flap, the bandwidth consumed by BGP is microscopic compared to, say, DNS or SMTP. (note, i'm not comparing it to HTTP, next to which anything is microscopic.) finally, security engineering is all about tradeoffs. some balance will be found between the size of the keys and signatures, the complexity of the algorythms, and the economic realities of the market. i see a big overlap. --vix ] ------- Message 3 subquestion 1: if the spammer is your customer. They couldn't inject the route unless they registered with us first and that process should disallow it if it's unregistered. Using the IP address wouldn't get caught yet, we are waiting for Cengiz to add ingress filtering to RtConfig so we can build the filters out of the policy info stored at RADB. subquestion 2: if the spammer is a customer of one of your BGP peers. We only check that the route is tagged with an AS path that we are expecting to see from the peer so if they get it past the peer then we will believe it. subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. We lose here since we believe what we get from our provider. ------- Message 4 > routing core allow it? subquestion 1: if the spammer is your customer. no. customers are considered dangerous when armed with BGP. they are AS and prefix fitlered. > subquestion 2: if the spammer is a customer of one of your BGP peers. Only if they're ASpath is valid by RA registries. We are not [yet! in my copious spare time we will be!] prefix filtering on peers. > subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. n/a, if I read the question right. ------- Message 5 > routing core allow it? Yup, mostly. :( > subquestion 1: if the spammer is your customer. "No", but then we don't have any BGP customers either. We're in the process of creating a BGP service for those customers that want it. I'll be collecting this thread from NANOG as part of the argument to make sure we "do it right" and get the resources to make sure the answer to this question will remain "no". Of course, if the customer was multihomed we might still learn the route via the method in subquestion 3 because it would be a false assumption to apply the same filters to what we learn via their other upstreams as to what they announce to us. (Hmm. but we could make it a true assumption by writing the contract carefully... "tell us all routes you expect to originate in your AS even if you don't plan to announce them to us because we will filter you on our other borders too" ;) [ this is pretty common. no potential customer is going to choose a different provider based on this restriction -- or if they do, you're better off. --vix ] > subquestion 2: if the spammer is a customer of one of your BGP peers. "yes, unless RFC1918 addresses". I'm hoping to overbudget for the above so that we can change this to a "no" as well. That would probably rely on IRR data, which is also open to fakery, but the filter reloads wouldn't be realtime so it should still block 5 minute announcements. > subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. "yes, unless RFC1918 addresses". I notice that some of our "big" transit providers trust whatever some of the other "big" backbone carriers feed to them. It's interesting to see networks belonging to peering LANs at various IXPs show up from time to time. I'm not sure that this can be easily fixed. Maybe the solution is similar to the IP filtering one, in that it only works when everyone filters at all the 'little' BGP sessions so that we can then 'trust' what our backbones feed us. > i've sent reply-to to myself. i will summarize responses back to the list. Thanks for making me think. Do you realise that you accidentally posted something of operational content and interest to NANOG ? [ i didn't mean to. it was the only audience i could think of for my question. i don't think i'm part of a trend of any kind, though. --vix ] ------- Message 6 > up before now. I guess spamming was the first natural application for it. If we required all mail relayers to have valid in-addr.arpa DNS, this would be a non-issue. Unfortunately, when I used sendmail rules to enforce that, too many valid (but clueless) sites were prevented from passing mail into FDT, and I had to back down. [ the in-addr.arpa tree was never really populated at all the way it is now until uunet.uu.net, then the net's largest ftp server in the days before the web or even gopher, started requiring forward/reverse matches for all inbound anonftp connections. i think the progress we collectively made then is about all we can expect for the remainder of the experiment. --vix ] > (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. How impractical would it be to put all unallocated space in the RBL?? [ i did that today, but it's somewhat hopeless since i'm advertising /8's and the address thieves only need to offer something longer. it's time to hack on gated some and get it to automatically warn me when a more-specific comes in and occludes a particularly-tagged static. --vix ] It's hard to believe spam providers have stooped to this level...but assuming they have, I suppose the next step would be temporary theft of address space, though that would probably generate a lot more heat for them. The run of the mill small ISP or business on the net might not even notice a 5 minute interruption of routing, and would certainly lack the ability to track down those responsible. [ indeed. while this has been done from time to time it was always with the intent of doing harm to the network's owner, not just to steal their identity for various purposes. next april 1 we should see some demon- strations of this concept in hopefully friendly ways. --vix ] ------- Message 7 ***SEE the end re 7777:x communities for your BGP announcments*** >routing core allow it? In to us from the world? YES Out from us? We ingress filter most but not quite all customer traffic, so NO >subquestion 1: if the spammer is your customer. regular customer, NO (see above), BGP speaking customer (i provide transit for) YES - they are FEW and trusted. I may be using terms differently... I am using "BGP peer" as a peering point NO TRANSIT either way connection. >subquestion 2: if the spammer is a customer of one of your BGP peers. I'd use his routes internally, but would not propagate them. >subquestion 3: if the spamemr is a customer of a distant BGP-connected AS. We would pass it all like any other traffic. BUT, I was delighted to see you have now decided to blackhole them but have a problem perhaps you can help with! We are subscribed to your BGP blackhole system but are not currently using it internally because we had objections from downstream ISPs that hate spam but also are leary of censorship. I need to work out a scheme where I can selectively apply the blackholing routes for the rest of my customers, probably right into my 2501 at each of their sites! [ i think you should just use the DNS access method in that case. --vix ] However I would LOVE to immediately use the ones you send for unassigned blocks - all the /8s you listed in other email. PLEASE decide on a community or whatever to tag them with so I and others can selectively use this subset of the blackhole system, and skip the others for now. And, while you are at it, perhaps there are some other subtle subdivisions that also could benefit from having their own community. I assume the most logical community conventions would be 7777:x and x would be on a published list of special tags. Some thought might be made to more complex situations where a route might have multiple communities and could be tested for appropriately if it were known that that possibility existed. [ the gated version i'm using doesn't support communities at all. when it does, i will do what you said. --vix ] Also on your /8 announcements, won't the tighter masks of spammer 5 minute announcements override your /8 or am I missing something? [ yes. but i felt that the symbolic gesture was better than nothing. actually i think the IANA ought to be advertising real routes for these, blackholed of course, just to keep somebody else from camping on "by accident" as happens every year or two. --vix ] ------- End of Forwarded Messages

1 0

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