July 2001 - Test - lists.nanog.org

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

MPLS enabled networks in the future MANs
by srihari varada 02 Jul '01

02 Jul '01

Hello All: I would appreciate, if you could address the following questions as per your perceived vision of the future and experiences with the past such technologies: -- Would MPLS make it's way into MANs given the driving forces or promises of: (1) the VPNs, the Circuit Emulation service offering (from the user perspective), and (2) the Load balancing, the Fault Restoration, the scalability and the Unified control plane with CWDM/DWDM optical switches (from the network service provider point of view)? -- Is/Are there any MAN network service provider(s) considering the MPLS enabled networks for their future network architectures? If so how soon it could be? -- Would the Gigabit Ethernet be widely adopted as link layer for MPLS in the MANs given the investment in the Gigabit Ethernet based infrastructure that is already there? Would they complement well (for instance, load balancing, fault restoration) given the fact there are similarities in both of the approaches (tag switching, some QoS features)? -- Would pure IP and MPLS enabled domains co-exist for any reason that is not technical in nature? If so, what would be the motivation beyond legacy support? Regards, Srihari Varada TranSwitch Corporation 3 Enterprise Dr. Shelton, CT 06484.

1 0

Re: GRC rides again...
by auto261850＠hushmail.com 02 Jul '01

02 Jul '01

Damn I wanted to leave this alone. I really tried. But then I read his website... Another frickin' internet victim. Everybody did it to me. It wasn't my fault... He could have stopped this at anytime. It really wouldn't have taken much. Now a talk about our friend at GRC... Using windows for a security solution is bad enough. He left ports open on his pc's. Could have easily been stopped by the proper configuration. NSA has a pretty good guide for this. He left ports open on his firewall. Or did he. Not much mentioned here about firewalls. Ping and traceroute to his servers. From all the wonderful external addresses on the internet. Hello... Hello... Is anybody home here? Internet Security is just like car theft. At the end of the day the tow truck drives away with the alarm whaling away, the club on the steering wheel, stereo faceplate in the house, video camera running, clifford alarm system engaged, kill switch deployed, and big dog in the yard. Gotta put security at all levels. Take care of those windows boxes up front. The registry can be modified to stop ports, if the sockets list doesn't work. If you got a firewall, employ it correctly. You need more than one layer of protection here. PC based firewalls are handy but they are the VERY last line of defense. A little NAT would have been pretty handy here also. Then... After you get all that done, figure out exactly what you want to do on and around the Internet. At this point, once you are sure, call your friendly operator... He should have told Verio up front I need the following: FTP, HTTP, etc... and then said block everything else to my network. If he had done that, Verio being a customer oriented solution provider would have done so. Anybody would have. Money revolves around the idea of providing what the customer wants. Oh yeah.. .and when you finish. Test your solution... Know your risks and how you intend to deal with them... then test periodcally. A little definition for the three kinds of hackers... 1) script kiddies... this where most of these guys start off at. 2) copy cat's... They chunk code at this level. A little here and a little there. 3) Architect... Don't worry, you won't see it coming and better yet if you do you'll wish you hadn't. If a hacker gets to this level they normally hate levels one and two. They usually end up pushing Level one and two to the fine law enforcement people. The steps listed above will stop level one and level two hackers. Level three if he is sloppy. Note to Mr. Gibson... ISP's are not here to be mommy and daddy. Do your part then call to see what else is available but don't be an amatuer and think someone else should solve your problem.... Mitch At Mon, 2 Jul 2001 17:16:39 +0100, "David Howe" <DaveHowe(a)gmx.co.uk> wrote: > > >> The GRC page talks about his dos attack, and he also rants about the >> "dangers" of the IP stack in XP, but his dos attack didn't come from >sources >> sending spoofed packets, so source address filtering wouldn't have >helped >in >> this case. GRC complaining about the spoofed packet problem should >be a >> separate rant on his website (who knows...it probably is!). >I suspect that there were two attacks - because a few days after he >posted a >smug "I blocked all the compromised machines at the ISP and didn't even >notice later attacks" on his site, he posted a handsup "I surrender, > you >win" - and started ranting about the dangers of XP. The reaction is >about >what I would expect if his smug "I beat the haxors" page annoyed someone >enough that he *did* launch a spoofed attack, and one with a sufficient >variety of source IPs that there was no blocking it. > Free, encrypted, secure Web-based email at www.hushmail.com

1 0

[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

RE: GRC rides again...
by Ron Buchalski 02 Jul '01

02 Jul '01

It depends on how qos is deployed. If a customer pays for a higher level of qos between corporate sites on a provider's network (and no qos for other traffic), the attack traffic would only consume the higher level of bandwidth when destined for that limited set of destinations. Otherwise, it would be handled with the same qos as other attack traffic. As far as attack traffic setting it's own qos levels (manipulating precedence bits), a provider who deploys and supports qos in the network should insure that they tag traffic properly at the edge. If a non-qos customer starts tagging traffic with the highest precendence, the provider should re-tag it with no precedence prior to passing it on to the network. Of course, this means deploying some level of qos at ALL entry points, not just those entry points for customers paying for higher levels of service. It may be possible for the features of qos to help limit the extent of the attack, but with no predictability of where the attack sources or attack destinations are, you'd either need to apply qos when the attack occurs (reactive), or deploy it EVERYWHERE, on ALL provider's networks (intensely proactive). I doubt that anyone has the time or effort to deploy worldwide qos in order to stop random (and small, compared to overall traffic) dos attacks. -rb >From: Dave Israel <davei(a)biohazard.demon.digex.net> >Reply-To: davei(a)biohazard.demon.digex.net >To: Roeland Meyer <rmeyer(a)mhsc.com> >CC: "'rdobbins(a)netmore.net'" <rdobbins(a)netmore.net>, "'David Howe'" ><DaveHowe(a)gmx.co.uk>, nanog(a)merit.edu >Subject: RE: GRC rides again... >Date: Mon, 2 Jul 2001 10:23:41 -0400 > > > >I doubt it. In fact, a clever hacker could figure out who has paid >for what qos, and use it to give attacking traffic high priority. >It adds another variable; it doesn't present a solution. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com

1 0

RE: GRC rides again...
by Roeland Meyer 02 Jul '01

02 Jul '01

Yes, but my first question was wrt QoS. Would it do any good? > -----Original Message----- > From: Roland Dobbins [mailto:rdobbins@netmore.net] > Sent: Monday, July 02, 2001 7:12 AM > To: Roeland Meyer > Cc: 'David Howe'; nanog(a)merit.edu > Subject: Re: GRC rides again... > > > > Implementing fully-compliant sockets in XP is -not- a security issue. > > There're LOTS of things wrong with the way Microsoft do > things, but this > simply isn't one of them. It's just amazing to me how credulous the > public are when harangued by such an obvious snake-oil salesman. > > Steve Gibson, a hero in his own mind. > > Roeland Meyer wrote: > > >>From: David Howe [mailto:DaveHowe@gmx.co.uk] > >>Sent: Monday, July 02, 2001 2:48 AM > >> > >>... With yet another "update" to the DDos pages. > >>http://grc.com/dos/intro.htm > >>and I quote: > >> > > > >>>Unfortunately, today we see only the operation of blind > >>> > >>self-interest from > >> > >>>Microsoft and the Internet's ISP's > >>> > >>As I seem to recall several members of this list offered him > >>help (and were rebuffed) perhaps they > >>would like to comment? He seems increasingly lost in > >>a fantasy world where everyone is out to get him.... > >> > > > > The question I have is, would QoS would do any good here? > > > > Other then that, he seems to be on a rant here. As much as > I hate to say it, > > I almost agree with MSFT here. That said, Novell stated, > decades ago, that > > MSFT never could understand network security. At the time, > I agreed with > > Novell. Current observation is, that MSFT has yet to learn. > Considering > > MSFT's workstation market-share, that is a problem for all of us. > > > > > -- > ------------------------------------------------------------ > Roland Dobbins <mordant(a)gothik.org> // 408.859.4137 voice >

2 1

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

RE: GRC rides again...
by Roeland Meyer 02 Jul '01

02 Jul '01

That sounds like a very good reason to NOT use QoS. > -----Original Message----- > From: Dave Israel [mailto:davei@biohazard.demon.digex.net] > Sent: Monday, July 02, 2001 7:24 AM > To: Roeland Meyer > Cc: 'rdobbins(a)netmore.net'; 'David Howe'; nanog(a)merit.edu > Subject: RE: GRC rides again... > > > > > I doubt it. In fact, a clever hacker could figure out who has paid > for what qos, and use it to give attacking traffic high priority. > It adds another variable; it doesn't present a solution. > > On 7/2/2001 at 07:15:08 -0700, Roeland Meyer said: > > > > Yes, but my first question was wrt QoS. Would it do any good? > > > > > -----Original Message----- > > > From: Roland Dobbins [mailto:rdobbins@netmore.net] > > > Sent: Monday, July 02, 2001 7:12 AM > > > To: Roeland Meyer > > > Cc: 'David Howe'; nanog(a)merit.edu > > > Subject: Re: GRC rides again... > > > > > > > > > > > > Implementing fully-compliant sockets in XP is -not- a > security issue. > > > > > > There're LOTS of things wrong with the way Microsoft do > > > things, but this > > > simply isn't one of them. It's just amazing to me how > credulous the > > > public are when harangued by such an obvious snake-oil salesman. > > > > > > Steve Gibson, a hero in his own mind. > > > > > > Roeland Meyer wrote: > > > > > > >>From: David Howe [mailto:DaveHowe@gmx.co.uk] > > > >>Sent: Monday, July 02, 2001 2:48 AM > > > >> > > > >>... With yet another "update" to the DDos pages. > > > >>http://grc.com/dos/intro.htm > > > >>and I quote: > > > >> > > > > > > > >>>Unfortunately, today we see only the operation of blind > > > >>> > > > >>self-interest from > > > >> > > > >>>Microsoft and the Internet's ISP's > > > >>> > > > >>As I seem to recall several members of this list offered him > > > >>help (and were rebuffed) perhaps they > > > >>would like to comment? He seems increasingly lost in > > > >>a fantasy world where everyone is out to get him.... > > > >> > > > > > > > > The question I have is, would QoS would do any good here? > > > > > > > > Other then that, he seems to be on a rant here. As much as > > > I hate to say it, > > > > I almost agree with MSFT here. That said, Novell stated, > > > decades ago, that > > > > MSFT never could understand network security. At the time, > > > I agreed with > > > > Novell. Current observation is, that MSFT has yet to learn. > > > Considering > > > > MSFT's workstation market-share, that is a problem for > all of us. > > > > > > > > > > > > > -- > > > ------------------------------------------------------------ > > > Roland Dobbins <mordant(a)gothik.org> // 408.859.4137 voice > > > > > > > -- > Dave Israel > Senior Manager, IP Backbone > Intermedia Business Internet >

1 0

RE: GRC rides again...
by Dave Israel 02 Jul '01

02 Jul '01

I doubt it. In fact, a clever hacker could figure out who has paid for what qos, and use it to give attacking traffic high priority. It adds another variable; it doesn't present a solution. On 7/2/2001 at 07:15:08 -0700, Roeland Meyer said: > > Yes, but my first question was wrt QoS. Would it do any good? > > > -----Original Message----- > > From: Roland Dobbins [mailto:rdobbins@netmore.net] > > Sent: Monday, July 02, 2001 7:12 AM > > To: Roeland Meyer > > Cc: 'David Howe'; nanog(a)merit.edu > > Subject: Re: GRC rides again... > > > > > > > > Implementing fully-compliant sockets in XP is -not- a security issue. > > > > There're LOTS of things wrong with the way Microsoft do > > things, but this > > simply isn't one of them. It's just amazing to me how credulous the > > public are when harangued by such an obvious snake-oil salesman. > > > > Steve Gibson, a hero in his own mind. > > > > Roeland Meyer wrote: > > > > >>From: David Howe [mailto:DaveHowe@gmx.co.uk] > > >>Sent: Monday, July 02, 2001 2:48 AM > > >> > > >>... With yet another "update" to the DDos pages. > > >>http://grc.com/dos/intro.htm > > >>and I quote: > > >> > > > > > >>>Unfortunately, today we see only the operation of blind > > >>> > > >>self-interest from > > >> > > >>>Microsoft and the Internet's ISP's > > >>> > > >>As I seem to recall several members of this list offered him > > >>help (and were rebuffed) perhaps they > > >>would like to comment? He seems increasingly lost in > > >>a fantasy world where everyone is out to get him.... > > >> > > > > > > The question I have is, would QoS would do any good here? > > > > > > Other then that, he seems to be on a rant here. As much as > > I hate to say it, > > > I almost agree with MSFT here. That said, Novell stated, > > decades ago, that > > > MSFT never could understand network security. At the time, > > I agreed with > > > Novell. Current observation is, that MSFT has yet to learn. > > Considering > > > MSFT's workstation market-share, that is a problem for all of us. > > > > > > > > > -- > > ------------------------------------------------------------ > > Roland Dobbins <mordant(a)gothik.org> // 408.859.4137 voice > > > -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

1 0

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