February 2003 - NANOG - lists.nanog.org

Re: manhole covers
by Sean Donelan 22 Feb '03

22 Feb '03

Check out Georgetown in Washington DC, the exploding manhole capital of the world. They have a lot of experience with exploding manholes, from many different causes. The most recent incident was in the last couple of days. There is a lot of energy in being pumped into utility lines. A short circuit can release that energy into the underground vaults, and blow the manhole cover a considerable distance. http://www.washingtonpost.com/wp-dyn/articles/A33073-2003Feb19.html The Washington Post also has a special report covering exploding manholes http://www.washingtonpost.com/wp-dyn/metro/specials/manholes/ On Thu, 20 Feb 2003, Allen Hamner wrote: > I am a chemist who consults with the mayor of Bluefield WV where an > incident two weeks ago (a cold day) blew a 70 pound iron cover 10 feet > from an conduit tunnel containing several public untility lines. We > believe we can exclude a natural gas leak. Rumor has it that hydrogen > is involved, which may arise by electrolysis (?) or pyrolysis of > insulation (?). A previous incident had done no damage but this > explosion destroyed a nearby plate-glass window. > > There is no coal in the area so mine gas seepage is excluded. Sewer > gas is tentatively not an issue. The source of the spark is unknown. > > I would like to participate in the exchange on this topic. > > Allen Hamner (Ph.D.) > hamner_a(a)wvwc.edu

4 3

Fwd: A warning from Register.com, Inc.
by David Diaz 22 Feb '03

22 Feb '03

Thought this might be important. If anyone has any more information please post. dd We have learned that a Website located at Renewal-Center.com has been soliciting our customers and encouraging them to renew and enter their credit card, address, and other personal information. Register.com is not affiliated with Renewal-Center.com. Any renewal attempts through this site will not be successful. The personal information that you have provided to Register.com remains safe and secure. If you receive a solicitation from Renewal-Center.com, delete it. Customers who fall prey to this scheme could have their personal information abused. If you have already submitted your credit card information to Renewal-Center.com you should contact your credit card company immediately and have the card number cancelled and report the problem as fraud. We have taken the appropriate steps to have this Website turned off so that none of our customer's accounts or personal information will be threatened. In addition, we've contacted the appropriate authorities who are taking all necessary steps to address this situation. Register.com's customers are incredibly important to us. As always, we are committed to providing a secure environment for our customers and their information. Should you have any questions regarding this email or any inquiries concerning your Register.com account, please do not hesitate to contact us through our Website (<http://e.register.com/a/hA$VvaxADcorcAMSTdPAMNnRZiL/regi1>http://www.register.com) or by calling: Within the U.S. and Canada: (800) 899-9723 Outside the U.S. and Canada: +1 (902) 742-1466 Sincerely, Richard D. Forman President and CEO Register.com, Inc. -- David Diaz dave(a)smoton.net [Email] pagedave(a)smoton.net [Pager] www.smoton.net [Peering Site under development] Smotons (Smart Photons) trump dumb photons

2 1

Not to beat a dead hose, but about the Bank of America ATM Articl e
by Temkin, David 21 Feb '03

21 Feb '03

... some very interesting reading to follow up on the discussions that were had last month regarding ATM machine security and PIN storage. Turns out CitiBank has a serious flaw in their system that they'd rather everyone not know about. As well, as was noted, the PIN numbers are no longer stored on the cards. See the article @ cryptome: http://cryptome.org/pacc.htm <http://cryptome.org/pacc.htm> -Dave David Temkin S-I-G 401 City Avenue Bala Cynwyd, PA 19004 http://www.sig.com <http://www.sig.com/> IMPORTANT:The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Re: [Re: [Re: [Re: M$SQL cleanup incentives]]]
by Joshua Smith 21 Feb '03

21 Feb '03

Bryan Bradsby <Bryan.Bradsby(a)capnet.state.tx.us> wrote: > > > udp/1434 is not a reserved port. [...] legit > > > traffic that picked a random port to use for an ad-hoc use. > > > > it isn't legit for what i have in my network though :-) > i should clarify this - my data center has www/dns/ftp servers and a bunch of voip gateways (mostly cisco), so they all talk on the same udp ports (most of which are greater than 30000) my corporate lan does have a ms sql server or two (running on nt4), but there is no reason that those servers should be talking to anything outside of my network (or outside of their vlan) > > Really? So you're blocking udp/1434 both in and out? > yep > Got any DNS servers on your network? Any of your desktop clients use DNS? > options { query-source * port 53 }; > Recent versions of un*x BIND will pick a random port above 1024 for udp > conversations. It can and has picked 1434. destination port will be 53, i suppose it is possible that the client could pick 1434 for a source..... > > DNS clients will eventually timeout and fall back to another server, so > any problems would be transient, but the packets were legit, right? > on the off chance that someone's windows desktop picked 1434 for a source. those packets however will not be leaving my network. it may not be the best way to do all of it, but it keeps my network from being killed (it also helps that the lan admin keeps all the servers well patched) > > -bryan bradsby > Texas State Government Net > > > joshua (the grouchy ip/security/*nix guy sitting alone in the dark corner of the office) "Walk with me through the Universe, And along the way see how all of us are Connected. Feast the eyes of your Soul, On the Love that abounds. In all places at once, seemingly endless, Like your own existence." - Stephen Hawking -

1 0

FW: CERT Advisory CA-2003-06 Multiple vulnerabilities in SIP
by St. Clair, James 21 Feb '03

21 Feb '03

-----Original Message----- From: CERT Advisory [mailto:cert-advisory@cert.org] Sent: Friday, February 21, 2003 10:25 AM To: cert-advisory(a)cert.org Subject: CERT Advisory CA-2003-06 Multiple vulnerabilities in implementations of the *** PGP Signature Status: unknown *** Signer: Unknown, Key ID = 0xD9513B39 *** Signed: 2/21/2003 10:19:02 AM *** Verified: 2/21/2003 1:09:03 PM *** BEGIN PGP VERIFIED MESSAGE *** CERT Advisory CA-2003-06 Multiple vulnerabilities in implementations of the Session Initiation Protocol (SIP) Original release date: February 21, 2003 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected SIP-enabled products from a wide variety of vendors are affected. Other systems making use of SIP may also be vulnerable but were not specifically tested. Not all SIP implementations are affected. See Vendor Information for details from vendors who have provided feedback for this advisory. In addition to the vendors who provided feedback for this advisory, a list of vendors whom CERT/CC contacted regarding these problems is available from VU#528719. Overview Numerous vulnerabilities have been reported in multiple vendors' implementations of the Session Initiation Protocol. These vulnerabilities may allow an attacker to gain unauthorized privileged access, cause denial-of-service attacks, or cause unstable system behavior. If your site uses SIP-enabled products in any capacity, the CERT/CC encourages you to read this advisory and follow the advice provided in the Solution section below. I. Description The Session Initiation Protocol (SIP) is a developing and newly deployed protocol that is commonly used in Voice over IP (VoIP), Internet telephony, instant messaging, and various other applications. SIP is a text-based protocol for initiating communication and data sessions between users. The Oulu University Secure Programming Group (OUSPG) previously conducted research into vulnerabilities in LDAP, culminating in CERT Advisory CA-2001-18, and SNMP, resulting in CERT Advisory CA-2002-03. OUSPG's most recent research focused on a subset of SIP related to the INVITE message, which SIP agents and proxies are required to accept in order to set up sessions. By applying the PROTOS c07-sip test suite to a variety of popular SIP-enabled products, the OUSPG discovered impacts ranging from unexpected system behavior and denial of services to remote code execution. Note that "throttling" is an expected behavior. Specifications for the Session Initiation Protocol are available in RFC3261: http://www.ietf.org/rfc/rfc3261.txt OUSPG has established the following site with detailed documentation regarding SIP and the implementation test results from the test suite: http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/ The IETF Charter page for SIP is available at http://www.ietf.org/html.charters/sip-charter.html II. Impact Exploitation of these vulnerabilities may result in denial-of-service conditions, service interruptions, and in some cases may allow an attacker to gain unauthorized access to the affected device. Specific impacts will vary from product to product. III. Solution Many of the mitigation steps recommended below may have significant impact on your everyday network operations and/or network architecture. Ensure that any changes made based on the following recommendations will not unacceptably affect your ongoing network operations capability. Apply a patch from your vendor Appendix A contains information provided by vendors for this advisory. Please consult this appendix and VU#528719 to determine if your product is vulnerable. If a statement is unavailable, you may need to contact your vendor directly. Disable the SIP-enabled devices and services As a general rule, the CERT/CC recommends disabling any service or capability that is not explicitly required. Some of the affected products may rely on SIP to be functional. You should carefully consider the impact of blocking services that you may be using. Ingress filtering As a temporary measure, it may be possible to limit the scope of these vulnerabilities by blocking access to SIP devices and services at the network perimeter. Ingress filtering manages the flow of traffic as it enters a network under your administrative control. Servers are typically the only machines that need to accept inbound traffic from the public Internet. Note that most SIP User Agents (including IP phones or "clien"t software) consist of a User Agent Client and a User Agent Server. In the network usage policy of many sites, there are few reasons for external hosts to initiate inbound traffic to machines that provide no public services. Thus, ingress filtering should be performed at the border to prohibit externally initiated inbound traffic to non-authorized services. For SIP, ingress filtering of the following ports can prevent attackers outside of your network from accessing vulnerable devices in the local network that are not explicitly authorized to provide public SIP services: sip 5060/udp # Session Initiation Protocol (SIP) sip 5060/tcp # Session Initiation Protocol (SIP) sip 5061/tcp # Session Initiation Protocol (SIP) over TLS Careful consideration should be given to addresses of the types mentioned above by sites planning for packet filtering as part of their mitigation strategy for these vulnerabilities. Please note that this workaround may not protect vulnerable devices from internal attacks. Egress filtering Egress filtering manages the flow of traffic as it leaves a network under your administrative control. There is typically limited need for machines providing public services to initiate outbound traffic to the Internet. In the case of the SIP vulnerabilities, employing egress filtering on the ports listed above at your network border may prevent your network from being used as a source for attacks on other sites. Block SIP requests directed to broadcast addresses at your router. Since SIP requests can be transmitted via UDP, broadcast attacks are possible. One solution to prevent your site from being used as an intermediary in an attack is to block SIP requests directed to broadcast addresses at your router. Appendix A. - Vendor Information This appendix contains information provided by vendors for this advisory. As vendors report new information to the CERT/CC, we will update this section and note the changes in our revision history. If a particular vendor is not listed below, we have not received their comments. America Online Inc Not vulnerable. Apple Computer Inc. There are currently no applications shipped by Apple with Mac OS X or Mac OS X Server which make use of the Session Initiation Protocol. Borderware No BorderWare products make use of SIP and thus no BorderWare products are affected by this vulnerability. Clavister No Clavister products currently incorporate support for the SIP protocol suite, and as such, are not vulnerable. We would however like to extend our thanks to the OUSPG for their work as well as for the responsible manner in which they handle their discoveries. Their detailed reports and test suites are certainly well-received. We would also like to reiterate the fact that SIP has yet to mature, protocol-wise as well as implementation-wise. We do not recommend that our customers set up SIP relays in parallel to our firewall products to pass SIP-based applications in or out of networks where security is a concern of note. F5 Networks F5 Networks does not have a SIP server product, and is therefore not affected by this vulnerability. Fujitsu With regards to VU#528719, Fujitsu's UXP/V o.s. is not vulnerable because the relevant function is not supported under UXP/V. IBM SIP is not implemented as part of the AIX operating system. IP Filter IPFilter does not do any SIP specific protocol handling and is therefore not affected by the issues mentioned in the paper cited. IPTel All versions of SIP Express Router up to 0.8.9 are sadly vulnerable to the OUSPG test suite. We strongly advice to upgrade to version 0.8.10. Please also apply the patch to version 0.8.10 from http://www.iptel.org/ser/security/ before installation and keep on watching this site in the future. We apologize to our users for the trouble. Hewlett-Packard Company Source: Hewlett-Packard Company Software Security Response Team cross reference id: SSRT2402 HP-UX - not vulnerable HP-MPE/ix - not vulnerable HP Tru64 UNIX - not vulnerable HP OpenVMS - not vulnerable HP NonStop Servers - not vulnerable To report potential security vulnerabilities in HP software, send an E-mail message to: mailto:security-alert@hp.com Lucent No Lucent products are known to be affected by this vulnerability, however we are still researching the issue and will update this statement as needed. Microsoft Corporation Microsoft has investigated these issues. The Microsoft SIP client implementation is not affected. NEC Corporation =================================================================== NEC vendor statement for VU#528719 =================================================================== sent on February 13, 2002 Server Products * EWS/UP 48 Series operating system * - is NOT vulnerable, because it does not support SIP. Router Products * IX 1000 / 2000 / 5000 Series * - is NOT vulnerable, because it does not support SIP. Other Network products * We continue to check our products which support SIP protocol. =================================================================== NETBSD NetBSD does not ship any implementation of SIP. NETfilter.org As the linux 2.4/2.5 netfilter implementation currently doesn't support connection tracking or NAT for the SIP protocol suite, we are not vulnerable to this bug. NetScreen NetScreen is not vulnerable to this issue. Network Appliance NetApp products are not affected by this vulnerability. Nokia Nokia IP Security Platforms based on IPSO, Nokis Small Office Solution platforms, Nokia VPN products and Nokia Message Protector platform do not initiate or terminate SIP based sessions. The mentioned Nokia products are not susceptible to this vulnerability Nortel Networks Nortel Networks is cooperating to the fullest extent with the CERT Coordination Center. All Nortel Networks products that use Session Initiation Protocol SIP) have been tested and all generally available products, with the following exceptions, have passed the test suite: Succession Communication Server 2000 and Succession Communication Server 2000 - Compact are impacted by the test suite only in configurations where SIP-T has been provisioned within the Communication Server; a software patch is expected to be available by the end of February. For further information about Nortel Networks products please contact Nortel Networks Global Network Support. North America: 1-800-4-NORTEL, or (1-800-466-7835) Europe, Middle East & Africa: 00800 8008 9009, or +44 (0) 870 907 9009 Contacts for other regions available at the Global Contact <http://www.nortelnetworks.com/help/contact/global/> web page. Novell Novell has no products implementing SIP. Secure Computing Corporation Neither Sidewinder nor Gauntlet implements SIP, so we do not need to be on the vendor list for this vulnerability. SecureWorx We hereby attest that SecureWorx Basilisk Gateway Security product suite (Firmware version 3.4.2 or later) is NOT VULNERABLE to the Session Initiation Protocol (SIP) Vulnerability VU#528719 as described in the OUSPG announcement (OUSPG#0106) received on Fri, 8 Nov 2002 10:17:11 -0500. Stonesoft Stonesoft's StoneGate high availability firewall and VPN product does not contain any code that handles SIP protocol. No versions of StoneGate are vulnerable. Symantec Symantec Corporation products are not vulnerable to this issue. Symantec does not implement the Session Initiation Protocol (SIP) in any of our products. Xerox Xerox is aware of this vulnerability and is currently assessing all products. This statement will be updated as new information becomes available. Appendix B. - References 1. http://www.ee.oulu.fi/research/ouspg/protos/ 2. http://www.kb.cert.org/vuls/id/528719 3. http://www.cert.org/tech_tips/denial_of_service.html 4. http://www.ietf.org/html.charters/sip-charter.html 5. RFC3261 - SIP: Session Initiation Protocol 6. RFC2327 - SDP: Session Description Protocol 7. RFC2279 - UTF-8, a transformation format of ISO 10646 8. Session Initiation Protocol Basic Call Flow Examples 9. Session Initiation Protocol Torture Test Messages, Draft _________________________________________________________________ The CERT Coordination Center thanks the Oulu University Secure Programming Group for reporting these vulnerabilities to us, for providing detailed technical analysis, and for assisting us in preparing this advisory. We would also like to acknowledge the "RedSkins" project of "MediaTeam Oulu" for their support of this research. _________________________________________________________________ Feedback on this document can be directed to the authors, Jason A. Rafail and Ian A. Finlay. ______________________________________________________________________ This document is available from: http://www.cert.org/advisories/CA-2003-06.html ______________________________________________________________________ CERT/CC Contact Information Email: cert(a)cert.org Phone: +1 412-268-7090 (24-hour hotline) Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh PA 15213-3890 U.S.A. CERT/CC personnel answer the hotline 08:00-17:00 EST(GMT-5) / EDT(GMT-4) Monday through Friday; they are on call for emergencies during other hours, on U.S. holidays, and on weekends. Using encryption We strongly urge you to encrypt sensitive information sent by email. Our public PGP key is available from http://www.cert.org/CERT_PGP.key If you prefer to use DES, please call the CERT hotline for more information. Getting security information CERT publications and other security information are available from our web site http://www.cert.org/ To subscribe to the CERT mailing list for advisories and bulletins, send email to majordomo(a)cert.org. Please include in the body of your message subscribe cert-advisory * "CERT" and "CERT Coordination Center" are registered in the U.S. Patent and Trademark Office. ______________________________________________________________________ NO WARRANTY Any material furnished by Carnegie Mellon University and the Software Engineering Institute is furnished on an "as is" basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied as to any matter including, but not limited to, warranty of fitness for a particular purpose or merchantability, exclusivity or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement. _________________________________________________________________ Conditions for use, disclaimers, and sponsorship information Copyright 2003 Carnegie Mellon University. Revision History Feb 21, 2003: Initial release *** END PGP VERIFIED MESSAGE ***

1 0

Support needed in LA (Downtown)
by Sven Engelhardt 21 Feb '03

21 Feb '03

Hello, can anyone provide a contact of a professional service company available in Downtown LA, I have a router there that needs to be packed up for shipment early next week. Please reply off-list. thanks in advance, Sven Engelhardt Manager Network Engineering -- Tiscali International Network phone: +49 6103 91 64 80 Robert Bosch Strasse 32 fax: +49 6103 91 64 64 D-63303 Dreieich / Germany e-mail: sven(a)tiscali.net

1 0

Staten Island refinery fire
by Kai Schlichting 21 Feb '03

21 Feb '03

News reports say that about 10:10am EST, a refinery (Mobile Port) at the channel between New Jersey and Staten Island caught fire due to a propane barge explosion: When I passed by the Verrezano Narrows bridge (on the other side of S.I., towards Brooklyn) at around 10:25am, there was a GIANT plume of smoke rising at least several miles into the air before being blown by the wind in south/south-eastern direction. www.news12.com and www.ny1.com are completely slashdotted right now, with www.cnn.com having slowed to a crawl.

1 0

Re: Homeland Security Alert System
by Martin Hannigan 21 Feb '03

21 Feb '03

On Thu, Feb 20, 2003 at 08:08:58PM -0500, Richard Irving wrote: > Yes. > > But, until elections 2004, the "FUD" field is hardcoded to "High". > > However, if there are changes to the -=actual=- dhs.gov status, > it sends out an automatic Amazon.Com order for > Hip Boots for all members of the list. > > Would you like to subscribe to the notification list ? [ snip ] > >Is anyone running an automated Terror Alert system that's > >real time with the DHS? Ok, that was interesting. :) The diving thing is my fun stuff. I'm actually working in Security. :) I was writing a little tool that scanned their page for the alert image name change, but that's subject to them making changes to their site and the images are multi layer graphics, etc. etc. I'm going to call them and see if they can offer a place to poll something simple that we can trip changes off in the NOC. If anyone does have some insight to anything they are doing, or a good contact number for the DHS webite, please ping me in email and I'll follow up if I find something or get them to do something. -M

5 4

RE: Homeland Security Alert System
by St. Clair, James 21 Feb '03

21 Feb '03

Martin, >From the NANOG perspective, the best place to tie your own alert system to nat'l threat levels is with the Telecomm ISAC, which is run out of the NCS. That is the 27/7/365 commander center for telecomm sector security. Bear in mind, a change in the HSAS may NOT be as a result of a specific threat to Telecomm, so get with the ISAC instead. Jim -----Original Message----- From: Martin Hannigan To: nanog(a)merit.edu Sent: 2/20/03 7:35 PM Subject: Homeland Security Alert System Is anyone running an automated Terror Alert system that's real time with the DHS? -M

1 0

The Cidr Report
by cidr-report＠potaroo.net 21 Feb '03

21 Feb '03

This report has been generated at Fri Feb 21 21:46:27 2003 AEST. The report analyses the BGP Routing Table of an AS4637 (Reach) router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org/as4637 for a current version of this report. Recent Table History Date Prefixes CIDR Agg 14-02-03 119071 85433 15-02-03 119072 85385 16-02-03 118946 85348 17-02-03 118884 85299 18-02-03 118939 85352 19-02-03 119053 85338 20-02-03 119156 85478 21-02-03 119400 85502 AS Summary 14614 Number of ASes in routing system 5749 Number of ASes announcing only one prefix 1577 Largest number of prefixes announced by an AS AS701 : ALTERNET-AS UUNET Technologies, Inc. 73048064 Largest address span announced by an AS (/32s) AS568 : SUMNET-AS DISO-UNRRA Possible Bogus Routes 10.0.0.0/8 AS4637 REACH Reach Network Border AS 192.168.0.0/16 AS4637 REACH Reach Network Border AS Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 21Feb03 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 119491 85471 34020 28.5% All ASes AS3908 1062 565 497 46.8% SUPERNETASBLK SuperNet, Inc. AS18566 482 6 476 98.8% COVAD Covad Communications AS701 1577 1145 432 27.4% ALTERNET-AS UUNET Technologies, Inc. AS4151 524 92 432 82.4% USDA-1 USDA AS7018 1427 1034 393 27.5% ATT-INTERNET4 AT&T WorldNet Services AS4323 529 170 359 67.9% TW-COMM Time Warner Communications, Inc. AS7843 569 234 335 58.9% ADELPHIA-AS Adelphia Corp. AS7046 578 246 332 57.4% UUNET-CUSTOMER UUNET Technologies, Inc. AS6197 478 158 320 66.9% BATI-ATL BellSouth Network Solutions, Inc AS1221 1119 821 298 26.6% ASN-TELSTRA Telstra Pty Ltd AS4355 402 120 282 70.1% ERMS-EARTHLNK EARTHLINK, INC AS22927 295 14 281 95.3% AR-TEAR2-LACNIC TELEFONICA DE ARGENTINA AS1239 960 680 280 29.2% SPRINTLINK Sprint AS705 447 194 253 56.6% ASN-ALTERNET UUNET Technologies, Inc. AS4814 261 15 246 94.3% CHINANET-BEIJING-AP China Telecom (Group) AS1 666 435 231 34.7% GNTY-1 Genuity AS6347 330 101 229 69.4% DIAMOND SAVVIS Communications Corporation AS6198 433 204 229 52.9% BATI-MIA BellSouth Network Solutions, Inc AS22291 243 32 211 86.8% CHARTER-LA Charter Communications AS17676 227 26 201 88.5% GIGAINFRA XTAGE CORPORATION AS690 498 308 190 38.2% MERIT-AS-27 Merit Network Inc. AS209 523 335 188 35.9% ASN-QWEST Qwest AS4134 304 117 187 61.5% CHINANET-BACKBONE No.31,Jin-rong Street AS2386 443 263 180 40.6% INS-AS AT&T Data Communications Services AS2048 260 87 173 66.5% LANET-1 State of Louisiana AS852 604 445 159 26.3% ASN852 Telus Advanced Communications AS7303 240 90 150 62.5% AR-TAST-LACNIC Telecom Argentina Stet-France Telecom S.A. AS17557 340 190 150 44.1% PKTELECOM-AS-AP Pakistan Telecom AS22773 181 31 150 82.9% CCINET-2 Cox Communications Inc. Atlanta AS6140 283 137 146 51.6% IMPSAT-USA ImpSat Total 16285 8295 7990 49.1% Top 30 total Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0