December 1997 - NANOG - lists.nanog.org

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

Re: Whoa; the 3 network?
by Randall Pigott 28 Dec '97

28 Dec '97

At 06:11 PM 12/23/97 +0000, some abusive halfwit wrote: >> >GE is heavily firewalled; i'm not suprised you didn't get any >answers. > >stupid experiment, really. And a stupid comment, really. No wonder GE no longer wants his services. Look, gang, the reason to do a public ping is that in the last analysis, GE only needs public IP addresses for those infrastructure machines that need public exposure and contact with the public internet. Granted, there are some exceptions. However, a ping -a should bring up at least every valid router on their network that sits in front of a firewalled virtual private network element, plus the firewall host itself. Most everything else sits behind a firewall. By definition, then, those machines can and should be proxied for external public internet connections and can use private network numbers. Those that are not behind the proxy and firewall can keep their public numbers. Despite transit across segments of the public internet, as Mr. Bono of GE so rightly pointed out, only the machines exposed to the public internet need public numbers. The goal here is only to find publicly pingable IPs in use, not to count all hosts behind firewalls. So much for the ex-GE contractor. It is apparent that GE had no more use for his comments than I do, since he is proud to still be able to at least call himself an ex-GE contractor. Mr. Bono, on the other hand, did state useful facts. He is a part of GE, and thus is limited to only pointing out facts that serve GE interests. What he did not point out is that number of employees <> number of needed public static IP addresses. First, the majority of GE employees are blue-collar clock-punchers in factories both in the US and especially overseas. They are not allowed time by the assembly line supervisors for internet access even if they did have the knowledge and desire to establish a permanent presence on the public internet. Second, assume for the moment that leaves maybe 300,000 or those 1.7 million workers eligible for having a white collar AND an office AND a desk with a static address PC on it. How many of these pee cees really have direct exposure to the public internet and are NOT behind a firewall? The one useful comment Mr. Ex-GE Contractor came up with is that GE is heavily firewalled. That means less than 5 percent or so actually see the internet without the blockage of a firewall. Those 5 percent or less are predominantly small offices with small one-segment LANs that do not need a firewall and do not justify a full period private leased line. Of course, back when there *was* a GEIS doing a viable public dial-in ISP business, all that was different. But no more. So let's say less than 60,000 static public IPs are needed for the entire 1.7 million employee GE. That is being generous, BTW. How then can you justify needing more than a single Class-B, or at most two or three worldwide? Only if you admit you use it inefficiently. You cannot convincingly argue that a heavily-firewalled corp needs 100 percent public IPs behind that proxy firewall. Equally, there is no defensible position from which to argue that those users cannot be proxied for virtually all external access from behind that firewall. Sure, if done all at once this would be a time-intensive renumbering process, but other major corps have completed renumbering plans within their normal pee cee workstation refresh cycles and have done so at minimal additional marginal cost over a 12 to 18 month period. GE should not be so bloated and ineffective that their IT staff cannot follow the lead of other corps and do this for the public good. I challenge GE to say that this is not so, and provide pertinent and defensible facts and figures to back it up. I believe that if the truth were know, Jack Kelly and gang are guilty of definitely warehousing hundreds of thousands and almost certainly millions of unneeded public IP addresses because they think they can get away with it and for no other reason. We through ARIN and others should be reallocated this address space for the public use of our subscribers. OK, even though the horse ran away long ago, that's a good tilt at a windmill anyway for ya........Happy Holidays to ALL Randall

10 13

Modem testing software..
by Young M. Park 28 Dec '97

28 Dec '97

Hi, Can anybody recommend me a good modem testing tool? It will be used on customer side to check how stable the connection is and what rate of speed it's actually getting. Thanks in advace for any responses. Young Park ______________________________ / _____) / Associate Engineer (___________________________________________ / Intranet Engineering | / \ Data Engineering | Address: 12502 Sunrise Vallery Dr. / \ Sprint International | Mailstop: VARESA0104 / \________________________| Reston, VA 20191-5606 \ | Phone: 703-689-6723 \ |__________________________________________\ email: ypark(a)sprint.net ypark(a)igate.sprint.com y.park(a)sprint.sprint.com

1 0

The Cidr Report
by Tony Bates 26 Dec '97

26 Dec '97

This is an auto-generated mail on Fri Dec 26 12:00:00 PST 1997 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 26Dec97 0) General Status Table History ------------- Date Prefixes 191297 46949 201297 46969 211297 46910 221297 46996 231297 47516 241297 47566 251297 47463 261297 47433 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 1662 Number of ASes announcing only one prefix: 778 (143 cidr, 635 classful) Largest number of cidr routes: 121 announced by AS3561 Largest number of classful routes: 583 announced by AS1 1) Gains by aggregating at the origin AS level --- 26Dec97 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 201 102 99 49.3% IMCI AS72 84 36 48 57.1% Schlumberger Information Network AS719 505 460 45 8.9% LANLINK autonomous system AS174 298 258 40 13.4% Performance Systems International AS271 80 46 34 42.5% BCnet Backbone AS1 583 551 32 5.5% BBNPLANET AS1257 296 265 31 10.5% SWIPnet Swedish IP Network AS701 473 443 30 6.3% Alternet AS2493 97 73 24 24.7% iSTAR Internet, Inc. AS5381 58 36 22 37.9% PowerTech Information Systems AS AS8517 75 55 20 26.7% ULAKNET-ASN AS6822 37 19 18 48.6% SuperOnline autonomous system AS6663 35 17 18 51.4% InterComp Bucharest AS3663 25 7 18 72.0% NETNET-NET AS3563 59 41 18 30.5% Pilot Network Services, Inc. AS2048 45 28 17 37.8% LaNet AS2561 36 20 16 44.4% Egyptian Networks AS6897 32 17 15 46.9% Global-One Spain AS3564 29 15 14 48.3% Microserve Infromation Systems In AS2907 110 96 14 12.7% SINET AS1239 268 254 14 5.2% SprintLink Backbone AS6846 30 17 13 43.3% UKRPACK.NET AS1785 162 149 13 8.0% NYSERNet Backbone AS5666 35 23 12 34.3% Omnes - A Schlumberger and Cable AS4000 74 62 12 16.2% Global IP AS2752 38 26 12 31.6% THOMSONCA-AS AS549 93 82 11 11.8% ONet Backbone AS3577 30 19 11 36.7% PREPnet-WEST AS2686 46 35 11 23.9% Autonomous System number for IBM AS816 54 44 10 18.5% UUNET Canada (ASN-UUNETCA-AS4) For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0