October 2000 - Test - lists.nanog.org

RE: DOS Attacks and reliable network contact data.
by rdobbins＠netmore.net 22 Oct '00

22 Oct '00

Port 6667 is used quite a bit for IRC traffic, FYI. I think one of my customers got hit with 12mb/sec of this last night, too - didn't do anything, as I've done all the usual stuff to avoid becoming an amplifier. It ran into ACLs in one of my MPLS-enabled switches, which pretty much just ate it. The attack was definitely distributed, because it came in through two of my upstreams. Based upon purely subjective experience, the info I get back from whois from ARIN, APNIC, etc. has been looking more uniform, of late; I should think that some good regexp might do the trick. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Jason Slagle [mailto:raistlin@tacorp.net] Sent: Saturday, October 21, 2000 2:15 PM To: nanog(a)nanog.org Subject: DOS Attacks and reliable network contact data. I've seen an increase in DOS attacks over the past week or so, of a form I really haven't encountered before. Below are some logs. 22:30:52.821705 255.255.255.255.80 > 205.133.127.30.6667: R 0:0(0) ack 1062615418 win 0 22:30:52.821956 202.172.120.255.80 > 205.133.127.30.6667: R 0:0(0) ack 3046052966 win 0 22:30:52.822208 168.17.227.0.80 > 205.133.127.30.6667: S 21259901:21259901(0) ack 1412091198 win 2144 <mss 536> 22:30:52.822459 255.255.255.255.80 > 205.133.127.30.6667: R 0:0(0) ack 2473479669 win 0 22:30:52.822711 210.251.128.255.80 > 205.133.127.30.6667: R 0:0(0) ack 529389642 win 0 22:30:52.822962 195.53.123.0.80 > 205.133.127.30.6667: . ack 1625272127 win 9112 (DF) 22:30:52.823213 152.158.37.127.80 > 205.133.127.30.6667: R 0:0(0) ack 1362286194 win 0 Lots and lots of TCP ACK's from broadcast addresses. Looks like a new kind of indirect SYN/ACK flood based on broadcast addresses. Which led me to sort through my logs and do my best to get the amps shut down, which led me to my current problem/gripe. Their exists no reliable way to get the contact of a network without first querying arin, then apnic, then the .jp registry for instance. This is a royal PITA and is in no way scriptable that I can see. Am I wrong? Does such a thing exist? What can we do bout these attacks. Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - raistlin(a)tacorp.net - jslagle(a)toledolink.com - WHOIS JS10172 -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GE d-- s:+ a-- C++ UL+++ P--- L+++ E- W- N+ o-- K- w--- O M- V PS+ PE+++ Y+ PGP t+ 5 X+ R tv+ b+ DI+ D G e+ h! r++ y+ ------END GEEK CODE BLOCK------

2 1

RE: decreased caching efficiency?
by Roeland M.J. Meyer 22 Oct '00

22 Oct '00

Christian, I invite you to www.photoloft.com Each album is dynamic and the site uses FlashPix technology. Have fun with it. > -----Original Message----- > From: Christian Kuhtz [mailto:ck@arch.bellsouth.net] > Sent: Friday, October 20, 2000 12:14 PM > To: nanog(a)merit.edu > Subject: Re: decreased caching efficiency? > > On Fri, Oct 20, 2000 at 11:59:58AM -0700, Travis Grant wrote: > [..] > > Commerce sites are also dependent on dynamic technology > that cannot be > > cached. Although you will find sites that are entirely > static (buy.com & > > etoys.com) you will generally find that these models are > based on volume and > > that the majority of these sites have never seen a dollar > in profit. However > > the profitable boutique type sites like eStyle.com, are > entirely dynamic. > > Margins are protected by a contractual product line. When > you place an > > order, a query verifies inventory prior to final checkout. > In addition, > > product pages indicate whether items are in stock or not. > You cant cache > > these types of sites. > [..] > > Each and every button, product image etc could be cached, > regardless of the > dynamic nature of the website. Images cost cycles, bw. > > [..] > > Most caching implementations will cost way more than the > bandwidth costs > > they avoid. > > You get no argument there ;-). I never felt that you could > ever justify > caching in terms of bandwidth savings. You can only justify > in terms of > improving a users experience. And in that sense, you are > giving considerable > resources to a content origin, and a free service to them. > > That's why the CDN strategy is much more attractive, where > you have a hosting > relationship of some kind with the content origin. > > [..] > > load on the DB servers. But TTLs will usually have to be > set pretty low (2 > > seconds) in order to do this and the technologies will have > to be catered to > > web development environments (like cacheflow and ASP). > [..] > > Hmm, if you cache what I suggest above, that's not really > neccessary... No? > > Cheers, > Chris > > -- > Christian Kuhtz > Architecture, BellSouth.net > <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm > Atlanta, GA > "Speaking > for myself only." >

1 0

RE: decreased caching efficiency?
by Roeland M.J. Meyer 22 Oct '00

22 Oct '00

Christian, I invite you to www.photoloft.com Each album is dynamic and the site uses FlashPix technology. Have fun with it. > -----Original Message----- > From: Christian Kuhtz [mailto:ck@arch.bellsouth.net] > Sent: Friday, October 20, 2000 12:14 PM > To: nanog(a)merit.edu > Subject: Re: decreased caching efficiency? > > On Fri, Oct 20, 2000 at 11:59:58AM -0700, Travis Grant wrote: > [..] > > Commerce sites are also dependent on dynamic technology > that cannot be > > cached. Although you will find sites that are entirely > static (buy.com & > > etoys.com) you will generally find that these models are > based on volume and > > that the majority of these sites have never seen a dollar > in profit. However > > the profitable boutique type sites like eStyle.com, are > entirely dynamic. > > Margins are protected by a contractual product line. When > you place an > > order, a query verifies inventory prior to final checkout. > In addition, > > product pages indicate whether items are in stock or not. > You cant cache > > these types of sites. > [..] > > Each and every button, product image etc could be cached, > regardless of the > dynamic nature of the website. Images cost cycles, bw. > > [..] > > Most caching implementations will cost way more than the > bandwidth costs > > they avoid. > > You get no argument there ;-). I never felt that you could > ever justify > caching in terms of bandwidth savings. You can only justify > in terms of > improving a users experience. And in that sense, you are > giving considerable > resources to a content origin, and a free service to them. > > That's why the CDN strategy is much more attractive, where > you have a hosting > relationship of some kind with the content origin. > > [..] > > load on the DB servers. But TTLs will usually have to be > set pretty low (2 > > seconds) in order to do this and the technologies will have > to be catered to > > web development environments (like cacheflow and ASP). > [..] > > Hmm, if you cache what I suggest above, that's not really > neccessary... No? > > Cheers, > Chris > > -- > Christian Kuhtz > Architecture, BellSouth.net > <ck(a)arch.bellsouth.net> -wk, <ck(a)gnu.org> -hm > Atlanta, GA > "Speaking > for myself only." >

1 0

DC Zoning Commission planning to limit carrier hotels?
by rdobbins＠netmore.net 21 Oct '00

21 Oct '00

http://washingtonpost.com/wp-dyn/articles/A41553-2000Oct19.html ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

3 2

Cheapest ethernet switch with monitor/mirror port?
by Dan Hollis 20 Oct '00

20 Oct '00

Looking for the cheapest ethernet switch with a monitor/mirror port. Recommendations? -Dan

3 2

RE: decreased caching efficiency?
by Travis Grant 20 Oct '00

20 Oct '00

William, Where does caching make sense? Static assets that can be stored on the edge closest to customers ie images, audio, video. These needs are served by your Akamais, IBeams, and Evokes. One other place where it makes sense to cache, in your Corporate environement. There will probably be a flux point for cost savings in respect to bandwidth if a company is able to get the majority of web traffic to remain on the LAN. But in regards to a caching architecture for your web site. Sites that have any revenue tied to advertising will benefit highly from knowing exact demographics, exact visitor counts, etc... In addition advertisers pay more for "targeted advertising" and targeted advertising is done with Dynamic technologies that can not be cached (the banner can be cached and await retrieval). Push technologies are to the advertising industry as napster is to the music industry. Acting as a catalyst in '96, the advertising industry recognized the benefit of targeted advertising that push technologies offer and embraced the internet. There are entire business models built on this principle (pioneers ADFORCE - formerly IMGIS, recent newbies alladvantage, mvalue, etc...). Commerce sites are also dependent on dynamic technology that cannot be cached. Although you will find sites that are entirely static (buy.com & etoys.com) you will generally find that these models are based on volume and that the majority of these sites have never seen a dollar in profit. However the profitable boutique type sites like eStyle.com, are entirely dynamic. Margins are protected by a contractual product line. When you place an order, a query verifies inventory prior to final checkout. In addition, product pages indicate whether items are in stock or not. You cant cache these types of sites. Granted this architecture is hard to scale, but they represent a rare breed of commerce vendors making cash. And by the way saving bandwidth is not justified for the majority of the market. 80% of deployed sites are sucking less than 2Mbps in monthly fees. Most caching implementations will cost way more than the bandwidth costs they avoid. Some dynamic site architectures will benefit from caching if the cache product is able to reduce the number of web servers required in a farm and/or if the cache engine working with the web farm is able to reduce the load on the DB servers. But TTLs will usually have to be set pretty low (2 seconds) in order to do this and the technologies will have to be catered to web development environments (like cacheflow and ASP). Travis Grant System Architect www.kore.com -----Original Message----- From: William Allen Simpson [mailto:wsimpson@greendragon.com] Sent: Friday, October 20, 2000 7:04 AM To: nanog(a)merit.edu Subject: Re: decreased caching efficiency? Dana Hudes wrote: > > I vehemently disagree with the statement that impressions do not make any sense, > only clickthroughs. There is such a thing as brand awareness, a situation where > a banner ad is good for itself even if it doesn't lead to click through. > Of course, in that case, the benefit is to the advertiser. That is, they get the benefit, but you don't get paid. Not my problem. That seems to follow "not make any sense", but YMMV. > It is NOT for YOU to decide what business model makes sense for MY > business relationship with MY advertisers. > Nope. You can have any business relationship you'd like. But, by the same token, it is not for *YOU* to decide that *I* have to pay to support YOUR business decision. Last time I looked, there's no constitutional right that guarantees that you can make money. > I pay my ISP to carry IP packets around. But, you don't pay ME to carry your IP packets around. My customers pay me. I pay my upstream. Therefore, I pay my upstream as little as possible. > In some cases certainly your cache is in fact a copyright violation. > Interesting, if true. Perhaps you could provide a citation? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

3 3

Re: DC Zoning Commission planning to limit carrier hotels?
by Steve Sobol 20 Oct '00

20 Oct '00

"John K. Doyle, Jr." wrote: > Various cities in the Bay Area are rapidly enacting anti-.com zoning > ordnances. This isn't specific to data centers. The problem is that, out > here at least, the .com explosion is of sufficient magnitude that it has a > tendency to wipe out "business districts." What happens is that the .com > companies are WAY better funded than your average shoe-shine stand, burger > joint, or even neighborhood pharmacy. So, they can afford to pay way more > rent than a traditional business can. Pretty soon, you look up and there > is NO retail to be seen anywhere in the business district. > > Now imagine the ripple effect. I've read about this phenomenon in the SFO area, although what I read mentioned residential housing. (Several friends who live there have confirmed what I've read). Wouldn't it be better to enforce an anti-price-gouging law that capped the amount of rent landlords could charge? -- North Shore Technologies, Cleveland, OH http://NorthShoreTechnologies.net Steve Sobol, BOFH - President, Chief Website Architect and Janitor Linux Instructor, PC/LAN Program, Natl. Institute of Technology, Akron, OH sjsobol(a)NorthShoreTechnologies.net - 888.480.4NET - 216.619.2NET

1 0

RE: decreased caching efficiency?
by Roeland M.J. Meyer 20 Oct '00

20 Oct '00

> Also don't confuse profit with revenue. A mistake that many make. One can have lots of revenue and still have negative profits.

1 0

Re: decreased caching efficiency?
by Dana Hudes 20 Oct '00

20 Oct '00

I can point out plenty of examples of large sites which do not work without JavaScript. Also don't confuse pofit with revenue. On Fri, 20 Oct 2000, Hendrik Visage wrote: > On Fri, Oct 20, 2000 at 12:43:51PM -0400, Dana Hudes wrote: > > > > > > ----- Original Message ----- > > From: "Majdi S. Abbas" <msa(a)samurai.sfo.dead-dog.com> > > To: "Dana Hudes" <dhudes(a)hudes.org> > > Cc: <nanog(a)merit.edu> > > Sent: Friday, October 20, 2000 12:33 PM > > Subject: Re: decreased caching efficiency? > > > > > > > > > > On Fri, Oct 20, 2000 at 10:24:27AM -0400, Dana Hudes wrote: > > > > No, you are interfering with my revenue stream by preventing > > > > my getting credit for the banner impression. > > > > > > Tough. Banner ads aren't a guaranteed form of revenue. > > > > Neither is being an ISP a guarantee of revenue. > > Depends on a couple of factors, but it could be a pretty decent > form of "guaranteed" revenue. > > > > How would you feel if I said my cache at home filters banner > > > content out? > > > > I hope my JavaScript would detect this and refuse to display the photograph. > > Sofar you've given us LOTS of reasons NOT to visit your site (BTW, url > to exclude from our caches ;^) > > This will actually make several people turn away from your site, as > people don't always like java/javascript and have it actually turned > off, like when browsing via a Nokia 9110, lynx etc. > > Hendrik >

1 0

The Cidr Report
by Tony Bates 20 Oct '00

20 Oct '00

This is an auto-generated mail on Fri Oct 20 12:00:00 PDT 2000 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 20Oct00 0) General Status Table History ------------- Date Prefixes 131000 88713 141000 88736 151000 88773 161000 88779 171000 88976 181000 89084 191000 89049 201000 89411 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: 8803 Number of ASes announcing only one prefix: 5049 (2823 cidr, 2226 classful) Largest number of cidr routes: 930 announced by AS701 Largest number of classful routes: 1133 announced by AS701 1) Gains by aggregating at the origin AS level --- 20Oct00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 431 152 279 64.7% BCnet Backbone AS1221 590 439 151 25.6% TELSTRA-AS AS816 595 454 141 23.7% UUNET Canada (ASN-UUNETCA-AS4) AS9269 177 46 131 74.0% Hong Kong CTI AS2609 128 8 120 93.8% EUnet-TN AS9304 130 17 113 86.9% Hutchcity AS6429 222 112 110 49.5% FirstCom Internet AS7545 159 55 104 65.4% TPG Internet Pty Ltd AS8013 467 364 103 22.1% PSINET-CA AS7046 355 254 101 28.5% UUNET-CUSTOMER AS4755 200 101 99 49.5% Videsh Sanchar Nigam Ltd. India AS705 356 259 97 27.2% ALTERNET-AS AS7657 313 220 93 29.7% The Internet Group Limited AS7496 126 35 91 72.2% Power Up AS174 539 453 86 16.0% Performance Systems International AS4293 341 259 82 24.0% Internal ASN for C&W AS13999 91 9 82 90.1% UNKNOWN AS701 1133 1052 81 7.1% Alternet AS6595 137 56 81 59.1% DODDSEUR AS3908 251 172 79 31.5% Supernet, Inc. AS577 249 176 73 29.3% Bell Backbone AS724 220 153 67 30.5% DLA-ASNBLOCK-AS AS7018 574 508 66 11.5% AT&T WorldNet Service Backbone AS5106 100 37 63 63.0% AADS-COLUMBUS AS226 168 106 62 36.9% USC/Information Sciences Institut AS3749 121 61 60 49.6% TECNET AS16758 63 6 57 90.5% UNKNOWN AS8151 181 126 55 30.4% UNINET-MX AS8895 97 43 54 55.7% Saudi Arabia AS AS7568 78 24 54 69.2% C.S. Communications Co., Ltd. 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