June 2001 - Test - lists.nanog.org

black hat .cn networks
by Dan Hollis 08 Mar '02

08 Mar '02

http://wired.com/news/politics/0,1283,43437,00.html Time to drop AS4134. -Dan

16 17

Re: Open Peers at PAIX
by Richard A. Steenbergen 10 Jul '01

10 Jul '01

On Thu, Jun 28, 2001 at 12:46:04PM -0600, Pete Ashdown wrote: > > What follows is a list I compiled of organizations at PAIX who peer > without restrictions. Restrictions are "requirements" like nationwide > [...] > > Organization IP address AS# Email contact > > AboveNet 198.32.176.11 6461 noc(a)above.net > Exodus 198.32.176.15 3967 peering(a)exodus.net > Global Crossing 198.32.176.29 3549 peering(a)gblx.net These are the only large service provider networks I see listed. AboveNet would probably peer with a bum on the street outside PAIX if he could speak BGP, but AFAIK GBLX's requirements were at least 3 locations and bi-costal at a minimium. If I remember correctly Exodus is also slightly picky about its "ghetto peers", probably falling somewhere the middle of the other two. The rest of the list seems to basically fall into the categories of other "tier 2" regionals (Hurricane Electric, Maxim, etc), content looking for a way to save money on their transit bill (Hotmail, EA, etc), Asian networks who have a circuit to the US but aren't willing to cross it and will take any peers they can get (SingTel, KDD, etc), and misc small networks with little overwhelming value. Seems almost all the larger service providers are requiring at least bi-costal these days. You also missed a couple of the email contacts, abov is peering@ and lightning is not noc(a)cp.net :P -- 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)

9 11

IN-ADDR.ARPA Progress Report
by ARIN IN-ADDR Role 07 Jul '01

07 Jul '01

Goal: Reduce the size of the IN-ADDR.ARPA zone file. This file will be reduced in size by only containing name servers for /8 networks. Completed Steps: Apr 2001 - Established relationships with 2 companies to provide independent server networks for all ARIN IN-ADDR zone files. Jun 2001 - Released a new IN-ADDR.ARPA zone file generator to correct existing erroneous data. Next Step: July 9, 2001 - ARIN will begin revising the IN-ADDR.ARPA zone for those direct /8 delegations to ARIN. These /8 zone files will be serviced by the two ARIN nameserver networks. These changes will not affect the performance of reverse lookup in any of the IPv4 Address space. Please direct any questions to inaddr(a)arin.net. Ginny Listman Director of Engineering American Registry for Internet Numbers

2 1

Re: DDOS anecdotes
by Paul Vixie 02 Jul '01

02 Jul '01

> I'm having a hard time understanding this. Wouldn't it be easier/simpler for > these crackers to just install their bots on, oh say, 20 million machines > running XP than the crackers having to deal with installing the bot -and- > the code to do the spoofing on Win95/98/98SE/98ME? Doesn't matter. Either way it's an automated script-kiddie tool. No way either approach works if it requires manual keystrokes by the attacker.

12 18

[Fwd: Re: Peering LSR Violation]
by Rick Irving 02 Jul '01

02 Jul '01

-------- Original Message -------- Subject: Re: Peering LSR Violation Date: Fri, 29 Jun 2001 11:07:58 -0700 From: Doug Junkins <junkins(a)orcasisland.verio.net> To: Rick Irving <rirving(a)onecall.net> CC: Dorian Kim <dorian(a)verio.net>, peering(a)verio.net, peering(a)onecall.net References: <AEEPICGDOHNHFODBPFCLOEHBCPAA.tfrancis(a)verio.net> <3B3B8688.9933F73(a)onecall.net> <20010628184256.D15999(a)blackrose.org> <3B3CC0E6.63BFBDB9(a)onecall.net> Rick, Please accept this as 30-days notice that Verio will turn down peering with OneCall unless LSR is permanently enabled on on the peering routers that border Verio. I'm sorry if your interpretation of the requirement in our peering policy is different than ours, but the following clause is clear: Verio reserves the right to not peer with anyone as Verio sees fit and to terminate any peering at any time with 30 days notice. Warm Regards, -Doug Junkins VP, IP Engineering Verio, Inc. On Fri, Jun 29, 2001 at 12:54:46PM -0500, Rick Irving wrote: > Dorian Kim wrote: > > > > On Thu, Jun 28, 2001 at 02:33:28PM -0500, Rick Irving wrote: > > > Rather than tell me -your- conclusion, why don't you tell > > > me what you are trying to achieve ? > > > > LSR is an important tool for us, both for diagnostics and for verification > > of certain peer checks. > > This is a generic smoke screen, I need specifics. > > There aren't many things LSR provides that cannot be provided in > another fashion, with cooperation. > > And, FWIW, with less security risks. > > www.onecall.net has interior -traceroute- pages to provide the > probable services you are attempting to acquire. (See diagnostics) > > > > > "Verio requires that peers permit LSR, loose source routing, at least > > > > at the routers bordering the peering." > > FWIW, we -do- permit LSR.... We turn -on- LSR by request.... > then turn it -off- , when the diagnostic phase is complete. > My NOC -is- staffed 24x7 to respond to such needs. > > Otherwise, LSR is inherently too insecure to -leave- enabled, > so we have to permit it on a case-by-case, instance by instance, > basis. > > > This has also been an explicit part of our peering > > policy as long as Verio has had a peering policy. > > Randy Bush also thought the best solution to bandwidth and > routing > was to buy MCI, UU, and SPRINT instead of peering, at one time. > > You know, in -his- case he may have been right. ;) > > (Just kidding, Randy... smile. :) > > However, We all learn. > > Like I said, perhaps you should tell me your goals, > rather than your conclusion. I think we could plumb > an appropriate solution. > > BTW: In addition to the Record Route header options you appear to > desire, > I'll leave you with Cisco's enigmatic LSR definition: > > ================================================================================= > Loose Source Routing > Allows you to specify a list of nodes that must be traversed when > going to the > destination. > ================================================================================= > > > > We are simply attempt to get you to turn on LSR at the border routers > > as you've agreed to when you agreed to our peering policy. > > We will. > > Please schedule a time, and limited duration, that a tech on my > side > can work with a tech on your side, so we can assist you in running > your diagnostics. > > Thanks in advance. > > > > > Regards, > > > > -dorian > > > > > You are aware that Loose Source Routing is a security risk, correct > > > ? > > > > > > Or, are you simply trying to "record route", and can't get something > > > back > > > ... And your response is to "Inform me" of your policy? > > > > > > > > > Teri Francis wrote: > > > > > > > > Onecall is currently in violation of Verio's peering agreement. Under > > > > the "Technical Policy" section of our peering agreement it states, > > > > > > > > "Verio requires that peers permit LSR, loose source routing, at least > > > > at the routers bordering the peering." > > > > > > > > Please enable LSR on the routers we are peering with. > > > > > > > > Our peering policy has also been updated. Please acknowledge your receipt > > > > of this agreement and your compliance of the policy. Please also include the > > > > entire text of the agreement in your reply. > > > > > > > > This notice will serve as a 30 day notice to depeer should we not > > > > receive a response from you. > > > > > > > > Regards, > > > > > > > > Verio Peering > > > > > > > > ----Verio Peering agreement----- > > > > > > > > Technical : for all trouble and problems with established peers > > > > Problems noc(a)verio.net +1 888 598-3746 or +1 214 290-8545 > > > > > > > > Abuse/SPAM : SPAM and similar abuses > > > > abuse(a)verio.net > > > > > > > > Security : for all other security-related issues > > > > security(a)verio.net > > > > > > > > Peering : for negotiations of changes in peering points etc > > > > peering(a)verio.net > > > > do NOT send to this address for technical problems with > > > > existing circuits > > > > > > > > --- > > > > > > > > AS : 2914 > > > > AS-macro : AS-VERIO > > > > Equinix-Ashburn : 206.223.115.12 r00.asbnva01 GigE > > > > MAE-East : 192.41.177.121 r00.mclnva01 Vienna FDDI [0] > > > > 192.41.177.196 r01.mclnva01 Vienna FDDI [0] > > > > 198.32.187.223 r00.mclnva01 VPI/VCI:0/323 aal5snap [1] > > > > CID: 0281b81b0052 > > > > MAE-West : 198.32.136.80 r00.snjsca01 San Jose FDDI [2] > > > > 198.32.136.126 r01.snjsca01 San Jose FDDI [2] > > > > 198.32.200.80 r00.snjsca01 VPI/VCI:0/107 aal5snap [1] > > > > CID: wz898473ip80 > > > > NASA-Ames : 198.32.136.89 r00.mtvwca02 Sunnyvale FDDI [2] > > > > PAIX : 198.32.176.14 r06.plalca01 GigE > > > > 198.32.176.47 r05.plalca01 GigE > > > > AADS : 206.220.243.34 r00.chcgil01 VPI/VCI:3/40 aal5snap > > > > LINX : 195.66.224.138 r00.londen02 100baseT [3] > > > > 195.66.224.139 r01.londen02 100baseT [3] > > > > Xchangepoint UK : 217.79.160.10 r00.londen02 GigE [3] > > > > 217.79.161.10 r01.londen02 GigE [3] > > > > > > > > [0] - Due to the impending terminatation of FDDI services at MAE-East, > > > > Verio is not adding new peers to our FDDI connections. > > > > > > > > [1] - Verio is only provisioning AAL5 best-effort PVCs via WorldCom's > > > > Peermaker for MAE-ATM. No guaranteed bandwidth PVCs will be > > > > accepted. > > > > > > > > [2] - Please peer with MFS-West or Ames only in the same location. Do not > > > > use the overburdened inter-site links. > > > > > > > > [3] - Verio is currently testing prefix filtering based on IRR entries on > > > > our LINX and Xchangepoint connections. You will need to provide > > > > Verio the name of your AS-set in the IRR that descibes the set of > > > > routes you will be announcing. Verio currently accepts the following > > > > route registries: RADB, RIPE, ALTDB, ARCSTAR and CW[4]. > > > > Peering filters will be updated each day automatically at 0100 UTC and > > > > loaded on the routers at 0400 UTC. Contact noc(a)verio.net for > > > > technical > > > > problems with prefix filters. These prefix filters do not replace or > > > > supercede our normal peering filters as described at: > > > > > > > > "http://info.us.bb.verio.net/routing.html#PeerFilter". > > > > > > > > [4] - Please note that due to problems mirroring RIPE 181 database, we are > > > > likely to phase out support for CW routing registry in the next few > > > > months unless CW upgrades their routing registry to be RPSL compliant > > > > and improves their reliability. > > > > > > > > --- > > > > > > > > To initiate peering, you need to send email agreeing to the following: > > > > > > > > General policy for public peering > > > > > > > > The Verio backbone peers with other transit ISPs, and only at the global > > > > exchange points to which the Verio backbone is connected. > > > > > > > > Verio does not peer with any ISP which is a Verio transit customer. > > > > > > > > In the United States, peering must be at least on both coasts, or one > > > > coast and Europe, with the peer having sufficient connectivity between > > > > points to support closest exit routing. > > > > > > > > In Europe, one peering is sufficient for now. Verio may choose to > > > > announce the same routes in Europe as the States, but Verio reserves the > > > > right to announce only that subset of our routes which are local. Of > > > > course, peer may choose to do either. > > > > > > > > Peer agrees to peer locally with Verio at any non-US peering points at > > > > which both appear. > > > > > > > > Peer is responsible for keeping Verio informed of their current contact > > > > information. Please send infomation and updates to: > > > > peering(a)verio.net > > > > noc(a)verio.net > > > > > > > > Technical Policy: > > > > > > > > Verio requires all BGP sessions have MD5 signature configured. > > > > > > > > Verio requires that peers permit LSR, loose source routing, at least at > > > > the routers bordering the peering. > > > > > > > > Verio requires that peers announce the same routing policy at all points > > > > where they peer with Verio. > > > > > > > > Peers are encouraged to, have NOCs with email addresses, phone numbers, > > > > and 24x7 coverage. > > > > > > > > Peers must agree to actively cooperate chasing security violations, > > > > denial of service attacks, and similar incidents. > > > > > > > > Peers must agree to actively respond to all technical issues within 48 > > > > hours. Non-response may result in depeering and other attention-getting > > > > mechanisms. > > > > > > > > Peers must not abuse the peering relationship by doing any of the > > > > following non exhaustive list: pointing default, resetting next hop, > > > > selling or giving next hop to others, etc. > > > > > > > > Verio reserves the right to not peer with anyone as Verio sees fit and > > > > to terminate any peering at any time with 30 days notice. > > > > > > > > Verio reserves the right to change this peering policy with 30 days > > > > notice. > > > > > > > > 01-JUN-2001

5 6

Akamai Servers: Normal or Weird?
by Chris Rapier 02 Jul '01

02 Jul '01

Is something funny happening with them lately or is it normal to see 45Mbps of UDP traffic between akamai servers (45Mps peak, average for the past 24 hours is around 15Mbps. Prior to that it wasn't enough to show up in our graphs). More information: Our akamai farm is the one recieving all of the data - its coming into our various akamai hosts on port 1455. I've never looked at this traffic before so I don't know if this is normal or not. I understand that the servers have to talk to each other to distribute content but why UDP and why consume so much bandwidth? Chris

3 5

Statement of WorldCom, Inc. on Nasdaq Network Service Interruption
by Sean Donelan 02 Jul '01

02 Jul '01

It appears Worldcom is learning. A few years ago when Worldcom had an outage affecting the Chicago Board of Trade, Mr. Ebbers didn't make a public statement for over a week. This time Worldcom had a public statement in less than five hours. BTW, did anyone ever receive an actual explaination for what happened two years ago when Worldcom lost their frame-relay? I never did. Statement of WorldCom, Inc. on Nasdaq Network Service Interruption 6/29/2001 6:47:00 PM CLINTON, Miss., Jun 29, 2001 /PRNewswire via COMTEX/ -- WorldCom, Inc. provides network services to the Nasdaq Stock Market, Inc. Today, Nasdaq experienced a service interruption at approximately 2:31 p.m. EDT that affected the quality of stock quotations and resulted in the suspension of Nasdaq's SOES and SelectNet trading systems. All service to the network system, supplied and managed by WorldCom, was restored at approximately 3:33 p.m. EDT. WorldCom's preliminary investigation into this issue indicates that it was apparently caused during routine testing of a development system for Nasdaq and resulted in the service interruption. WorldCom is continuing its investigation. Additional details will be made available as they are known. Said WorldCom, Inc. CEO and President Bernard J. Ebbers, "We very much regret this market interruption. For nine years, Nasdaq has been a valued customer. We have resolved this issue and will continue to work with Nasdaq to take all steps necessary to ensure it does not recur."

6 5

The Cidr Report
by Tony Bates 30 Jun '01

30 Jun '01

This is an auto-generated mail on Fri Jun 29 23:00:01 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 me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 29Jun01 0) General Status Table History ------------- Date Prefixes 220601 101078 230601 100823 240601 100985 250601 101071 260601 101116 270601 100751 280601 100644 290601 100654 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: 11095 Number of ASes announcing only one prefix: 6545 (3732 cidr, 2813 classful) Largest number of cidr routes: 1029 announced by AS701 Largest number of classful routes: 1429 announced by AS701 1) Gains by aggregating at the origin AS level --- 29Jun01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1366 1019 347 25.4% TELSTRA-AS AS701 1429 1216 213 14.9% Alternet AS4293 398 283 115 28.9% part of AS assignment AS4287 - AS AS6595 157 58 99 63.1% DoD Education Activity Network As AS705 237 141 96 40.5% part of AS assignment AS701 - AS7 AS6429 202 107 95 47.0% ATT LA Internet Chile AS7018 734 648 86 11.7% AT&T WorldNet Service Backbone AS4755 211 129 82 38.9% Videsh Sanchar Nigam Ltd. Autonom AS4151 159 77 82 51.6% part of AS assignment AS4151 - AS AS8013 300 220 80 26.7% PSINet Ltd. Canada AS13999 98 18 80 81.6% Mega Cable S.A. de C.V. AS577 246 173 73 29.7% Bell Advanced Communications Inc. AS724 238 166 72 30.3% part of AS assignment AS721 - AS7 AS6471 113 50 63 55.8% ENTEL CHILE S.A. AS7046 306 245 61 19.9% UUNET Technologies, Inc. AS3464 151 90 61 40.4% Alabama Research and Education Ne AS1 585 526 59 10.1% GTE Internetworking AS16758 63 6 57 90.5% IKON Office Solutions AS1239 446 391 55 12.3% SprintLink Backbone AS226 144 91 53 36.8% Los Nettos AS6413 65 13 52 80.0% Southern Online Systems, Inc. AS3908 207 155 52 25.1% Supernet, Inc. AS17561 112 61 51 45.5% Internet service provision to Wes AS9842 54 5 49 90.7% Lotte Data Communication Company AS852 211 163 48 22.7% Telus Advanced Communications AS5106 82 34 48 58.5% Ameritech Advanced Data Services, AS2149 300 252 48 16.0% PSINET-2 AS15290 237 190 47 19.8% AT&T Canada IES AS855 143 97 46 32.2% part of AS assignment AS853 - AS1 AS3602 226 180 46 20.4% Sprint Canada Inc. 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 IOS Vulnerability
by Larry Diffey 30 Jun '01

30 Jun '01

CERT and Cisco have issued a warning about a vulnerability in the Cisco IOS starting at version 11.3 and affecting all later versions. If your Cisco equipment is HTTP enabled and you're not using TACACS+ or RADIUS for authentication it is vulnerable to complete takeover. The hack is very simple. Please read the Cisco warning and/or the CERT advisory for further information. The warnings were released yesterday. Happy Hacker Stopping. Larry Diffey

3 2

Nasdaq Breaks Down for 2nd Day, Disrupts Trading
by Rishi Singh 29 Jun '01

29 Jun '01

New York, June 29 (Bloomberg) -- The Nasdaq Stock Market broke down for a second straight day, disrupting traders for about 90 minutes this afternoon on one of the busiest days of the year. The No. 2 U.S. stock exchange cancelled its aftermarket session. Complete story here: http://quote.bloomberg.com/fgcgi.cgi?ptitle=Top%20Financial%20News&s1=blk&tp =ad_topright_topfin&refer=topsum&T=markets_bfgcgi_content99.ht&s2=blk&bt=ad_ position1_topfin&middle=ad_frame2_topfin&s=AOz0AhxPxTmFzZGFx

4 3