- NANOG - lists.nanog.org

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

Re: So.. you want to track some DoS traffic?
by Richard A. Steenbergen 01 Jul '01

01 Jul '01

On Sun, Jul 01, 2001 at 05:34:06PM -0400, Christopher L. Morrow wrote: > > A brief overview of the method would be: "Track the attack from the > after effect of the attack, not the attack itself" Hrm interesting combination of two different techniques... Your border filter method is more commonly done with a community tag which triggers the route-map setting nexthop to a null routed IP block. You can even allow your customers to null route their own IP space within your network without them having to get in touch with your security people. The "backskatter" you are monitoring makes a nice hack for gathering information from many routers which don't support this kind of intelligent mass-management on their own. You could also setup a dedicated sniffing machine or machines and alter the nexthop to route the original DoS their way, if you want to find out details of the attack. It would also be interesting, especially on a UU scale, to do statistical sampling of backskatter generated by the victim instead of that generated by your routers. I'd also be interested in seeing someone setup a global realtime backskatter analysis just for a kind of "DoS weather report". Of course you should probably mention the only global analysis of spoofed attacks by the replies generated to their attacks I am aware of, at: http://www.caida.org/outreach/papers/backscatter/index.xml If you provided a customer community tag so your clued victims could do it theirselves, you could automatically monitor the ICMP Unreachables and already have a list of the ingress interfaces ready without any human interaction, kindof like the Call Trace functionality for phones which records the information for easy processing if charges are filed. If enough other networks did this you could probably stand a half decent chance of catching an attack that is shorter then the "few hours" normally required to get interprovider cooperation. If you really wanted to get nuts, this could fairly easily be packaged up into a program which runs on a unix machine and automatically cooperates with other providers running this service to trace spoofed attacks back to their source. Of course this is all a nasty hack around the lack of a protocol for communicating traceback and source-filtering information directly between routers, but I suspect this method would be a lot easier to actually get written, deployed, and used because of layer 8. -- 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)

1 0

So.. you want to track some DoS traffic?
by Christopher L. Morrow 01 Jul '01

01 Jul '01

First off, everyone already should know that these views are mine, not UUNET/WCOM/UUcom's... Ok, with the recent craziness on NANOG about DoS Attacks, spoofed packets, tracking attacks and other DoS related junk I figured I'd post out a quicky tracking method that does NOT require hop-by-hop tracking. This method works will pretty much all spoofed attacks (synfloods/smurfs for instance). A brief overview of the method would be: "Track the attack from the after effect of the attack, not the attack itself" A link to the details, which includes cut/paste router config bits for Cisco and Juniper routers. I'd include other router vendor cut/paste but I only had time to figure out the two included... if someone wants to post proper other configs (verified hopefully) I'll add them in also. Link: http://www.secsup.org/Tracking/ Credit: Credit should go to those listed in the link, UUNET's TAC-Eng group, UUNET's Net-Sec group, UUNET's Customer Router Security Group, dies(a)pulltheplug.com and a few others I have forgotten. The goal of posting this info out to NANOG is to get other backbone's to implement this so attacks can be traced in less time and with less effort by all parties. I can succesfully track an attack across my backbone in under 2 minutes with this method where the hop-by-hop has taken me over 8 hours in extreme circumstances (as Paul Vixie can attest since he waited on the call while I did it). Suggestions for improvement or deletions to these procedures would be welcome as well. Thanks, --Chris (chris(a)uu.net)

1 0

Choosing Peering vs Transit
by EA Louie 01 Jul '01

01 Jul '01

List - I'm curious as to how one chooses to Peer versus buy Transit in the Internet. What are the determining factors, if I were to start an ISP, on which I would do to get my network recognized by the Internet and how I would get my customers out into the backbone. thanks Eric

3 2

Procedural Outage Reduction Report
by Sean Donelan 01 Jul '01

01 Jul '01

> "Routine testing" could well mean "our most junior technician > was told to clean up the mess of cables, and one fell out." > I'm sure that's happened to everyone here.... I do not know what happened inside Worldcom. However, when human error is identified as the cause, always ask yourself did the human have a chance? Often it seems like the junior technician is made the scapegoat for inadequate supervision, equipment or training. ATIS and NRIC have identified "procedural errors" as an area of increasing concern for the reliability of the telecommunications network. Through the mandatory FCC reporting mechanism, ATIS and NRIC have identified common errors and recommended changes across carriers. You can read their recommendations at http://www.atis.org/atis/nrsc/nrschome.htm Well, you could, if the links on ATIS' web site actually worked. ATIS has no legal authority, and neither Worldcom nor any other carrier has to follow (or even read) its recommendations. But Internet Service Providers should be aware of the Lessons Learned (the hard way) in other industries.

1 0

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