July 2001 - Test - lists.nanog.org

Re: Improving Robustness of Distributed Services (Re: DDoS attacks)
by Marshall Eubanks 15 Jul '01

15 Jul '01

> > >On Thu, 12 Jul 2001, Dickson, Brian wrote: > >> - What is IRC, or for that matter net-news, at its heart? A transient, >> store-and-forward, one-to-many message system. >> >> In otherwords, multicast re-implemented on unicast, in some cases poorly and >> at great cost (news). > >AFAIK, there is no implemented multicasting protocol - routing and reliable >transport - that can scale to the number of groups, senders and receivers >visible in current IRC networks. Source-based trees would require the >order of 1E6 (S,G) pairs and core/RP-based routing would be an even easier >target for the SK's than IRC already is. > >Achieving instant group messaging on a global scale with convential multicast >is unlikely. Relevant academic research continues. > >J > > This sounds like a good application for SSM (which is, BTW, can be made much "harder" than ASM). Send many to one to a nearby server, which sends out one to many to interested parties. This way, participants would not need their own S,G. The crucial thing would be to make it fractal (hierarchical) in nature. I agree that multicasting will become a target for SK; in many ways I think the IRC attacks are a premonition of things to come. Regards Marshall Eubanks

1 0

RE: DDoS attacks
by Roeland Meyer 15 Jul '01

15 Jul '01

> From: Brad [mailto:brad@americanisp.net] > Sent: Thursday, July 12, 2001 9:18 AM > > On Thu, 12 Jul 2001, Roeland Meyer wrote: > > > > From: up(a)3.am [mailto:up@3.am] > > > Sent: Thursday, July 12, 2001 7:23 AM > > > > > I can't help but believe that if even 20% of them > > > were caught and had to spend just a little time (even > hours) with the > > > cops, and had their peecees confiscated, you'd not be seeing > > > nearly the problems we are now. > > > > This is the main point, a script-kiddie hunt, with > prosecution, is the ONLY > > real deterrent. Throw some of them in hotel greybar and > remove them from > > computing, for life, and we may see some of this turn around. > > I am just concerned about our current legal systems being > able to handle such cases efficently. Well.. Perhaps I > should not use 'legal systems' and 'efficently' in the same > sentence, but you get the idea ;) Think "Kaspureff" (AlterNIC). They went after, and nailed, him with gusto and efficiency. I think that the largest problem is "selective prosecution". A couple of years ago three MHSC servers were root-kitted via the BIND interface. It took 18x7 man-hours to scrub and bare-metal recover, without the suspect backups, those three servers. Even then, we couldn't jump the FBI's $60K damages hurdle. Yet, Kaspureff, with a lot less provable damage, got caught, grilled, and chilled. For those that don't know, this case is the best and most well-known example of [arguably] deliberate DNS cache poisoning on record. If you don't remember it then you need not comment. The point is that our legal systems can move with great alacrity, given sufficient motivation.

2 1

Improving Robustness of Distributed Services (Re: DDoS attacks)
by Dickson, Brian 15 Jul '01

15 Jul '01

> * Most of DoS attacks are against IRC networks. Hence, if we can get rid of those, the health of the Internet as a whole should improve. > * Experience gathered with this approach should be useful to developers and administrators of other distributed services and protocols. To paraphrase Lilu in _The Fifth Element_, "mooolteeeecaast". Multicast. It's a huge leap, which would require development, no doubt. However, consider the following: - What is IRC, or for that matter net-news, at its heart? A transient, store-and-forward, one-to-many message system. In otherwords, multicast re-implemented on unicast, in some cases poorly and at great cost (news). - What happens to IRC when you change this to multicast? IRC channels morph to multicast groups; RPs replace IRC servers; and most importantly, the infrasture "glue" no longer has a visible IP address, and becomes much less vulnerable to attack. Multicast has *intrisnic* RPF checking (that's how it works, in fact). Attackers cut themselves off first, before any propogation occurs. The protocol(s) deals with localized 'issues'. Anyone wishing to interrupt the IRC network would have to attack the entirety of the Internet, simultaneously. (This is *not* a challenge, really.) How difficult would it be to (a) implement, and (b) to migrate the users over to the new system? I can't speak to (a), never having operated a network with a network-administered IRC server (that I know of anyway ;-)). As to (b), if an initial gateway from unicast<->multicast (think MBGP<->DVMRP for the mbone) or many exist, should be easy. Show users that the new system is more resilient, and they'll use it. More importantly, have the operators and/or upstream networks promise to support the old system for a limited time only, after successful deployment of the new system. For network admins, the fact that it's more efficent for backbone use (a bigger factor near the edge, where bottom-tier ISPs with not many resources, and lots of IRC users - fill the modem ports with bandwidth, at no cost to your upstream link!) should be a selling point in and of itself. A significant number of top-tier networks already have the necessary multicast support and peering. Not much more needs to happen, beyond client and server software, and administrative tools. Multicast. A solution looking for a problem; a problem found, at last. :-) Brian Dickson

4 3

Re: When will 128M not be enough?
by Marshall Eubanks 14 Jul '01

14 Jul '01

> > >up(a)3.am schrieb: > >> >> It looks like some recent aggregation has been helping to slow down the >> growth. Yes, us http://www.multicasttech.com/status/index.html (at ~ 102k), Telstra http://www.telstra.net/ops/bgp/index.html (at ~ 105k) and KPNQwest http://www.mcvax.org/~jhma/routing/bgp-hist.html (at ~ 103k) have had flat numbers of suffixes since about mid-June. IMHO it's way too soon to tell if this is really a new trend. Regards Marshall Eubanks >If you look at some figures (e.g. >http://www.employees.org/~tbates/cidr-report.html) it's even pretty stable >around 101K prefixes. > >128M should do if you only have two or three upstreams, soft reconfiguration >disabled and almost nothing else enabled. Does anyone have experience with >zebra/mrt/... as a route server?. I need one and would like to you for the >cheap server based solution instead of having to buy a fully fledged router. > >TIA > >-- Arnold >

1 0

Smurf Amplification and Sonoma Access
by Jon Stanley 14 Jul '01

14 Jul '01

I have a big problem with the Sonoma Access prodcut that I have not been able to figure out how to solve, hoping maybe someone here has the product and can help. Basically the problem is that the box is a smurf amplifer by default, and there seems to be no way to disable it. I have looked through both the console interface and the SonomaView GUI with no success. Being that we have a fairly significant amount of these on our network, this is a major problem. By the way, this product is the same as the Nortel Universal Edge 640, they bought Sonoma..... Any help would be appreciated....

1 0

DoS yada yada yada
by Richard A. Steenbergen 14 Jul '01

14 Jul '01

I'd just like to take a quick opportunity to clear up some misconceptions on the subject of Denial of Service which seem to have been running rampant around here. First off, I am a longer time EFNet user as well as a former EFNet admin, and I have probably been the target of every type of DoS you could imagine at one point or another. You should not mistake cynicism for a particular chat network for apathy about DoS. I also do not believe IRC as a service is any less deserving of protection from attacks, but I do believe it is far more explainable. Secondly, let's not kid ourselves about where DoS comes from. If EFNet has earned one distinction, it is as the source of every major DoS currently in use against the internet. These programs don't write themselves, nor do people learn to use them effectively for no reason. By far the VAST majority of EVERY attack anyone on this list will EVER see *IS* related to IRC, and if you think "la de da I'm just an innocent little network who gets attacked for no reason" then you obviously don't know what your users are doing. The attacks against other targets like yahoo ebay etc are very rare and happen only as a result of packet kids building a network for use against their IRC targets and then realizing there is a whole world out there that doesn't see attacks like this on a regular basis. Let's also get off our delusions of power that help us deal with the powerlessness of being a DoS victim, no one has filed serious litigation against a network for their unintentional involvement in a DoS, and if anyone does it surely won't be EFNet. We all want someone to blame, but the reality of the matter is that the vast majority of attack sources are victims without any real negligence, and the vast majority of attacks are simply not going to be traced back to the person responsible. None of this changes the fundamental need to design networks which are resistant to malicious disruption, but let's at least try to deal with the reality of the situation. One other comment I'll make for the people who take IRC so seriously as to get bent out of shape over these words: It's just IRC. Repeat that to yourself at least 10 times every night. And one last request, unless you really have something to contribute, please don't reply to this on-list. Thanks. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

5 7

The Cidr Report
by cidr-report＠cisco.com 14 Jul '01

14 Jul '01

This is an auto-generated mail on Fri Jul 13 23:00:00 PDT 2001 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to cidr-report(a)cisco.com. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 13Jul01 0) General Status Table History ------------- Date Prefixes 060701 101036 070701 100965 080701 100869 090701 100962 100701 100995 110701 101196 120701 101105 130701 100848 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: 11205 Number of ASes announcing only one prefix: 6646 (3807 cidr, 2839 classful) Largest number of cidr routes: 863 announced by AS701 Largest number of classful routes: 1429 announced by AS701 1) Gains by aggregating at the origin AS level --- 13Jul01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1335 997 338 25.3% Telstra Pty Ltd AS701 1429 1212 217 15.2% UUNET Technologies, Inc. AS4293 395 281 114 28.9% Cable & Wireless USA AS6595 161 57 104 64.6% DoD Education Activity Networ AS13999 104 8 96 92.3% Mega Cable S.A. de C.V. AS705 232 137 95 40.9% UUNET Technologies, Inc. AS6429 200 108 92 46.0% RdC Internet AS7018 730 639 91 12.5% AT&T AS4755 211 120 91 43.1% VSNL India AS2568 146 55 91 62.3% CTS Network Services AS4151 160 78 82 51.2% USDA AS8013 296 216 80 27.0% PSINet Ltd. Canada AS577 246 173 73 29.7% Bell Canada AS724 237 165 72 30.4% DLA Systems Automation Center AS7046 311 247 64 20.6% UUNET Technologies, Inc. AS6471 122 59 63 51.6% ENTEL CHILE S.A. AS3464 151 90 61 40.4% Alabama SuperComputer Network AS16473 113 54 59 52.2% Bell South AS16758 63 6 57 90.5% IKON Office Solutions AS1 570 514 56 9.8% BBN Planet AS1239 440 385 55 12.5% Sprint ICM-Inria AS226 144 91 53 36.8% Los Nettos AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS3908 202 151 51 25.2% Supernet, Inc. AS17561 112 61 51 45.5% Internet Service West Austral AS852 215 165 50 23.3% Telus Advanced Communications AS9842 54 5 49 90.7% Lotte Data Communication Comp AS2149 317 268 49 15.5% Performance Systems, Inc. AS5106 81 33 48 59.3% Ameritech Advanced Data Servi AS4323 231 183 48 20.8% Time Warner Communications, I 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

Cisco's connected->bgp redistribution
by alex＠yuriev.com 13 Jul '01

13 Jul '01

Hello, Can anyone shed some light on why cisco ignores "ip classless" when redistributing classless connected routes into bgp, making things such as /30 into /24s? Thanks, Alex

3 2

BigRed.com - cache poisoning for com/net/org domains
by Mike Batchelor 13 Jul '01

13 Jul '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There was a weird problem posted to this list by Tim Langdell on May 24, 2001 (see http://www.mcabee.org/lists/nanog/msg01330.html) I am experiencing the same problem, though I am certain it is not due to any registry hacks/trojans/virii on the Windows clients, as Tim's message thread suggested. The problem is that my Win2K DNS server is resolving non-existent domains under com, net or org, to the bigred.com website at 64.177.155.101, instead of giving NXDOMAIN as it should. Let me show you what I have found in my poisoned cache. I did all these queries from a Unix host that resolves through a different nameserver that has not been poisoned. My Win2K DNS server, which services Windows clients on our LAN, is the one I am querying at 172.25.1.104. Check it out: ; <<>> DiG 8.1 <<>> @a.gtld-servers.net nosuchdomainexists.com. any ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUERY SECTION: ;; nosuchdomainexists.com, type = ANY, class = IN ;; AUTHORITY SECTION: com. 1D IN SOA A.GTLD-SERVERS.NET. hostmaster.nsiregistry.NET. ( 2001071201 ; serial 30M ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum ;; Total query time: 96 msec ;; FROM: upolu to SERVER: a.gtld-servers.net 192.5.6.30 ;; WHEN: Fri Jul 13 11:58:03 2001 ;; MSG SIZE sent: 40 rcvd: 117 OK, so such domain exists in the gTLD servers. So far so good. But my Win2K DNS says otherwise: ; <<>> DiG 8.1 <<>> @172.25.1.104 nosuchdomainexists.com. ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUERY SECTION: ;; nosuchdomainexists.com, type = NS, class = IN ;; ANSWER SECTION: nosuchdomainexists.com. 4m51s IN NS ns.above.net. nosuchdomainexists.com. 4m51s IN NS ns.eli.net. ;; ADDITIONAL SECTION: ns.above.net. 22h35m53s IN A 207.126.96.162 ns.eli.net. 23h54m5s IN A 209.63.0.2 ;; Total query time: 4 msec ;; FROM: upolu to SERVER: 172.25.1.104 ;; WHEN: Fri Jul 13 11:58:24 2001 ;; MSG SIZE sent: 40 rcvd: 119 Fascinating. Both of these nameservers say NXDOMAIN for nosuchdomainexists.com, same as the gTLD servers. Now check this out. I ask my cache for the A record of the non-existent domain: ; <<>> DiG 8.1 <<>> @172.25.1.104 nosuchdomainexists.com. a ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; nosuchdomainexists.com, type = A, class = IN ;; ANSWER SECTION: nosuchdomainexists.com. 59m40s IN A 64.177.155.101 ;; Total query time: 3 msec ;; FROM: upolu to SERVER: 172.25.1.104 ;; WHEN: Fri Jul 13 11:58:47 2001 ;; MSG SIZE sent: 40 rcvd: 56 Once I have made this query, the Win2K cache has some different glue for it: ; <<>> DiG 8.1 <<>> @172.25.1.104 nosuchdomainexists.com. ns ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUERY SECTION: ;; nosuchdomainexists.com, type = NS, class = IN ;; ANSWER SECTION: nosuchdomainexists.com. 59m27s IN NS dnsc.nsq.com. ;; ADDITIONAL SECTION: dnsc.nsq.com. 59m38s IN A 66.34.52.233 ;; Total query time: 13 msec ;; FROM: upolu to SERVER: 172.25.1.104 ;; WHEN: Fri Jul 13 11:59:01 2001 ;; MSG SIZE sent: 40 rcvd: 79 Iiiiinteresting. But what else is f'ed up here? I ask my Win2K cache for the address of a.gtld-servers.net and get back 66.34.52.224. In fact, my cache says all the gTLD servers have this address, except for z.gtld-servers.net (yes, "z") for which it gives the address 198.41.3.40. Non-existent gtld-servers.net get the address of the bigred.com website from my Win2K cache. Thing is, the nameserver at 66.34.52.224 is lame for names under gtld-servers.net, and refers me back to the correct names and addresses for the root zone. It is also lame for the nosuchdomainexist.com name that I was testing with. What gives???? How did my cache get poisoned, and how can the poisoning be continuing to affect resolution this way, when none of the poisoned glue appears to work at all?? I'm totally stumped. - --- ALL YOUR BASE ARE BELONG TO US SOMEBODY SET UP US THE BOMB -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQA/AwUBO09tr0ksS4VV8BvHEQK7owCgxXlaFfUUGpOdemmgBhXk9IH180cAn3oc OjC8lHvY0wGs7J7FciTyZXmB =dcfg -----END PGP SIGNATURE-----

1 0

Re: Cisco's connected->bgp redistribution
by Dave Israel 13 Jul '01

13 Jul '01

Alex, Make sure you don't have "auto-summary" turned on. Auto-summary is always classful, and therefore nearly always evil. -Dave On 7/13/2001 at 16:20:40 -0400, alex(a)yuriev.com said: > > > Hello, > Can anyone shed some light on why cisco ignores "ip classless" when > redistributing classless connected routes into bgp, making things such as > /30 into /24s? > > Thanks, > Alex > > -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

3 2