Well, well, well, isn't NANOG grand.

Looks to me like the public exposure and calls to our upstreams asking them to drop AS4200 routes on the floor got rather quick results.

Current status of 205.164.62.0/24:

Loop-Core1.Mcs.Net>show ip bgp 205.164.62.0 BGP routing table entry for 205.164.62.0/24, version 58913 Paths: (3 available, best #1) Advertisements of this net are suppressed by an aggregate. Local 0.0.0.0 Origin incomplete, metric 0, weight 32768, valid, sourced, best 5696 4200 (history entry) 207.98.189.129 from 207.98.189.129 (209.54.146.1) Origin IGP, external Dampinfo: penalty 891, flapped 1 times in 00:02:36 5646 1239 4200 (history entry) 206.54.225.149 from 206.54.225.149 (207.112.244.17) Origin IGP, external Community: 370016922 Dampinfo: penalty 902, flapped 1 times in 00:02:19

Thank you Nap.Net, GoodNet and NANOG.

Karl - GoodNet dropping peering with Agis would not be the solution for this problem. In any case, your example above would require Nap.Net to ask Sprint to drop peering with Agis... Please, in the future, open a trouble ticket with our NOC via email or voice phone call so we can work on this issues. We don't puruse the Nanog mailing list continuosly for incoming trouble reports from our customers. :-( Darin -- 'shredding packets around the world' ======================================================================== Darin Wayrynen, Chief Technology Officer, (602) 303-9500, darin@good.net

I *DID* open a trouble ticket BEFORE posting.

There are no trouble tickets in our ticket system opened by either yourself, any of your employees, or any of your downstream customers for the past few days. In fact, there were very few tickets opened at all. Do you have a ticket number?

If you are THIS disconnected from what goes on in your own company, perhaps we need a new upstream provider.

Actually, you know that I'm not disconnected from what goes on in this organization. I see every ticket that is opened, worked on, and closed, which is why when I read about your situations on the Nanog mailing list rather than our internal email system I get concerned that something is amiss, and check out the ticket system myself. Darin -- 'shredding packets around the world' ======================================================================== Darin Wayrynen, Chief Technology Officer, (602) 303-9500, darin@good.net

Karl Denninger sez:

On Fri, Dec 26, 1997 at 08:20:55PM -0700, Darin Wayrynen wrote:

...

...

I *DID* open a trouble ticket BEFORE posting.

There are no trouble tickets in our ticket system opened by either yourself, any of your employees, or any of your downstream customers for the past few days. In fact, there were very few tickets opened at all.

Do you have a ticket number?

...

If you are THIS disconnected from what goes on in your own company, perhaps we need a new upstream provider.

Actually, you know that I'm not disconnected from what goes on in this organization. I see every ticket that is opened, worked on, and closed, which is why when I read about your situations on the Nanog mailing list rather than our internal email system I get concerned that something is amiss, and check out the ticket system myself.

Darin -- 'shredding packets around the world' ======================================================================== Darin Wayrynen, Chief Technology Officer, (602) 303-9500, darin@good.net

That's ok Darin.

Copies of the email from your NOC people who were working the issue, and ultimately resolved the issue, will be attached to our cancellation - since you persist in calling me a liar in public.

Gee, Karl... I don't once seem him calling you a liar....... I do see him asking for the ticket number. Maybe the people who should have opened a ticket did not; it's impossible to say at this distance. But asking you for the number is a far cry from insulting you. Why not just post same? -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

Just thought that I would post that as one of goodnet's larger customers (DS3), we are VERY satisfied with their NOC, as well as their service. Whenever I have a problem, I can get a member of the goodnet staff to respond quicker than my other upstreams...:-) (hint Sprint) Reid Fishler Lightning Internet Services, LLC

Wait until you get smurfed and ask them to use the MCI-developed tracing tools and get a "duhhhhh" back in response.

They might have fixed this by now (since we bitched LOUDLY about this) but as of a few weeks ago the NOC had *no idea* how to trace this kind of activity - at all - nor any desire to learn.

Yes, we have them, and will attempt to use them in a real time situation if it occurs. Darin -- 'shredding packets around the world' ======================================================================== Darin Wayrynen, Chief Technology Officer, (602) 303-9500, darin@good.net

Karl, not to make excuses for goodnet, but neither Sprint nor ANS had too much of a clue when i contacted them about this either...Upstreams need to pay attention, and inform the level 1 staff (the people who pick up the phone) to take immediate action and not a ticket on a DoS. Reid Fishler

On Sat, Dec 27, 1997 at 01:24:05PM -0500, Reid B. Fishler wrote:

...

Just thought that I would post that as one of goodnet's larger customers (DS3), we are VERY satisfied with their NOC, as well as their service. Whenever I have a problem, I can get a member of the goodnet staff to respond quicker than my other upstreams...:-) (hint Sprint)

Reid Fishler Lightning Internet Services, LLC

Wait until you get smurfed and ask them to use the MCI-developed tracing tools and get a "duhhhhh" back in response.

They might have fixed this by now (since we bitched LOUDLY about this) but as of a few weeks ago the NOC had *no idea* how to trace this kind of activity - at all - nor any desire to learn.

-- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

On Sat, Dec 27, 1997 at 05:33:54PM -0500, Reid B. Fishler wrote:

Karl, not to make excuses for goodnet, but neither Sprint nor ANS had too much of a clue when i contacted them about this either...Upstreams need to pay attention, and inform the level 1 staff (the people who pick up the phone) to take immediate action and not a ticket on a DoS.

Well, actually, as was just demonstrated, they need to take immediate action _and_ open a ticket. _EVERYTHING_ should get ticketed. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Two words: Darth Doogie." -- Jason Colby, Tampa Bay, Florida on alt.fan.heinlein +1 813 790 7592

Hello Karl & All, Where or at what price are these tools available. Tia, JimL PS: In a further responce Karl was heard to say :

...

The bottom line is that MONTHS after these were made available your NOC crew

I never heard nor was made aware that these tools were available, even though I am an MCI Customer . :-(

Same here. Are they free or do they cost money? People want the tools. -- Phil Howard | w7x4y4z5@noplace2.net end5ads8@dumbads8.com suck1it7@dumbads7.edu phil | end6ads8@no52ads1.edu no2spam7@dumb7ads.net crash291@spammer6.org at | no1spam9@no57ads7.net crash075@spammer8.edu eat9this@spam1mer.edu milepost | stop5it8@spammer5.edu no53ads9@lame7ads.org no8way17@s3p3a9m9.com dot | eat0this@dumbads9.edu no5spam6@anyplace.com stop7865@no40ads3.edu com | a1b6c7d7@dumb8ads.edu no1spam5@lame8ads.edu no1way93@dumbads1.com

Phil Howard said once upon a time:

...

Hello Karl & All, Where or at what price are these tools available. Tia, JimL PS: In a further responce Karl was heard to say :

...

The bottom line is that MONTHS after these were made available your NOC crew

I never heard nor was made aware that these tools were available, even though I am an MCI Customer . :-(

Same here. Are they free or do they cost money?

People want the tools.

"DoSTrack v2.0 1997 MCI Telecommunications Code is available at: ftp://ftp.mci.net/outgoing/dostrack742812.tar DoSTracker WEB PAGE is at http://www.security.mci.net/dostracker" However, I was unable to get this to function properly with my Cisco. It never got past the "Password:" prompt. Any ideas?

On Sat, Dec 27, 1997 at 03:25:11PM -0700, Darin Wayrynen wrote:

I had to modify code to parse the password file. I did not try to determine if this was because I wasn't using the recommended hardware/software platform, or because the tool was created to work with a MCI specific environment.

While I can't comment on this specific problem, MCI's dostracker doesn't work if you are running DCEF. This makes dostracker useless in many networks. -dorian

Karl Denninger writes...

Then you damn well better not be permitting any of the following:

1) Forged source addresses (this CAN be stopped with specific filters on your interfaces, although some will bitch about the performance impact - depending on their specific choices)

Yet another case for pressing (now) ARIN (and others who allocate address space) to do address allocation in reasonable chunk sizes instead of forcing providers to accept little bits of address space a piece at a time. Prefix volume on BGP would be helped, too, by having fewer little pieces scattered all around. And with address space now on a paid basis, in theory people will generally ask for what they expect to need (there will be exceptions but they should be easy to spot), so there is more reason to actually give out requested allocations that are not obviously inflated.

2) Directed broadcasts (which are used to "create" these DOS attacks by bouncing the attack off a particularly-well-connected location, USUALLY a provider's internal infrastructure).

Block both of those and Smurfs would disappear. If you can trace the TRUE source of such an attack quickly, people will go to jail for this. The only reason they are popular is because the source addresses CAN be forged.

Specific information is always helpful. Unfortunately, if it has been given on NANOG, it can be missed due to the high noise level (yet another issue we need to work on). Would config examples in IOS and gated be too much to ask for (if someone only knows one, someone who knows the other should follow up).

THIS CAN BE PREVENTED.

Agreed. Let's make it easy. -- Phil Howard | die3spam@spammer3.org eat4this@dumb3ads.edu no1way94@dumbads5.org phil | no0way53@no9where.edu end9ads2@noplace0.org stop9361@dumb4ads.org at | no7spam1@spammer8.org die2spam@no5place.edu blow2me0@no39ads6.edu milepost | stop3it3@lame2ads.com w2x4y9z8@lame1ads.edu eat2this@noplace1.net dot | no14ads6@nowhere0.org no6spam1@spam8mer.com no5way06@nowhere3.net com | die6spam@no66ads9.com stop5758@no39ads5.org eat1this@anywhere.org

Karl wrote:

However, if a forged-source data stream IS traced to one of your customers, expect a harsh response from the general network community. This attack is well-enough known by now that I consider anyone unable to immediately and permanently deal with such an incident to be somewhere beneath contempt.

Well, it is going to take more education and pain, apparently. I've got 3 national backbones upstream and they all have a hell of a time just getting icmp-echo-reply filters in within hours of attack onset, and usually get nowhere with tracing this to an end perp. Granted, its a difficult, cooperative problem. One of the better respected of them, told me that their philosophy was to deliver all packets to me regardless of the source/type. This corker, is the type of logic one can apparently come up with when ones routers at Pensaulken are near fall-over. This upstream did install the filter, after escalation, fortunately. Until Cisco, et al, improves routers to the point where there is low cost icmp rate-limiting (or some other better solution) we will have a problem where backbones have to choose between expensive filtering of ICMP-echo-replies for very long periods of time or allowing customer connections to be randomly swamped (rendered useless) for hours by bored 13 year olds, from virtually anywhere on the net. The latter is of, essentially, zero economic value to us, at least. The current cost of per link filtering is apparently causing the backbone networks major grief. It is the only current, practical solution, as far as I can see, and yet they will do it very reluctantly because of the cpu impact. The will to trace this attack seems to be declining also, from my observation, as the sucess rate continues to be very poor (less than 5 percent by one upstream account, I doubt my other upstreams are even this organized). We need to get router fixes in place urgently, or bite the bullet on increased costs all around for expensive filters for long periods in current routers, with consequently more routers required. Backbone security teams should be reinforced as they appear to be losing their spirit. This problem, is disrupting the service of every isp in our region on a frequent basis and it is getting worse week by week. A, sometimes seen, tendency to suggest that only a few ISP's with problem attracting users are affected by this does not recognize the breath or depth of the problem, nor where it is heading. Ken Leland Monmouth Internet

Adrian wrote:

But this way, people can only spoof IPs from their own block, and not random addresses. It would kill smurf attacks, make tracing a tad(?) easier, etc, etc. And as I've mentioned before, not all types of floods are ICMP attacks. If you filter ICMP, then I'll start flooding with spoofed source addresses TCP packets with random sequence numbers and from IPs. What, you're going to ask routers to track all the TCP connections going through them now for validation? Erm, how many CPUs more are we going to need..? :)

Well, its that 200+ to 1 amplification thats readily available to spoofed ICMP echo packets that is really causing this problem to get out of hand. Any kid with a 28.8 link can effectively take down a T1. Without icmp broadcast amplification, someone who has to source 4megs to swamp a T1 for long periods of time will be easier to trace and will be far fewer in number. I regularly see attacks on our T3 that exceed 15Mbs. For the time being we are keeping up with this. Other providers in the area are being overrun. Our backup (smaller) links are often rendered useless.

I haven't looked at the MCI tools but my opinion is that if people start putting filters in, you would find the instances of flooding decline. All that needs to be done now is to discuss the best ways to do it (eg setting up a filter on a cisco which uses AS path regexps, so you can filter per interface on what people are announcing to you via BGP. That way, your downstreams can only send traffic with FROM IPs that they announce, and anyone who wants to spoof has to be speaking BGP. )

Granted, limiting source address spoofing will stop this and other problems. We have done this, to be net-friendly and in an attempt to avoid our 15 minutes of infamy. If this is generally doable then great. If not, in many cases, then we need rapid-onset/long-duration icmp-echo-reply filtering in our upstream/backbone connections for the forseeable future. Without this capability T1 net connections will become useless and T3 connections will become increasingly endangered. (If high availability is needed for the connection as it is for ours). This problem has been building here for over 4 months. Perhaps, we have a local holiday maximum this week, but in general I believe this situation will continue to worsen long term. Ken Leland Monmouth Internet

On Sun, Dec 28, 1997 at 09:17:28PM -0700, Dax Kelson wrote:

...

Adrian wrote:

...

But this way, people can only spoof IPs from their own block, and not random addresses. It would kill smurf attacks, make tracing a tad(?) easier, etc, etc. And as I've mentioned before, not all types of floods are ICMP attacks. If you filter ICMP, then I'll start flooding with spoofed source addresses TCP packets with random sequence numbers and from IPs. What, you're going to ask routers to track all the TCP connections going through them now for validation? Erm, how many CPUs more are we going to need..? :)

Something else that needs to be done is we need DEFAULT anti-spoof filters on all dialin boxes such as those made by Livingston, Ascend, USR, etc.

When a customer calls in and gets assigned an IP address the box should automatically apply an anti-spoof filter to that port dropping any packets with an IP source different than the one assigned.

Of course you need a way to overide that for customers who have networks routed to them. The box could the RADIUS "Framed-Route" entry as a hint to which networks to forward IPs from.

I've had an RFE in with Livingston for over a year to get that added to ComOS.

Dax Kelson Internet Connect, Inc.

Actually, if you have a "Framed-Route" entry, that's all you need. I'll talk to Livingston about this. They, uh, listen to our "suggestions"; we're a rather large user of their products. :-) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex support on ALL modems Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost

On Sun, 28 Dec 1997, Karl Denninger wrote:

...

are ICMP attacks. If you filter ICMP, then I'll start flooding with spoofed source addresses TCP packets with random sequence numbers and from IPs. What, you're going to ask routers to track all the TCP connections going through them now for validation? Erm, how many CPUs more are we going to need..? :)

If you did this the trace would be TRIVIAL.

Huh? ICMP floods vs TCP floods. Aren't they both IP or have I missed something glaringly obvious.

Then, the source network of the problem gets BGP-dropped until they kill the source account and/or connection. This reduces smurfing to a ONE TIME event, makes prosecution easy (anyone who thinks that such an attack, launched on interstate facilities, against any regional or larger ISP isn't something the Feds will want to get into is dreaming - its a slam-dunk that the limits on damage have been exceeded) and further, raises the bar on people who claim that they "can't fix this".

Yep.

All you need to do is prevent out-of-bounds traffic from being sent into your dedicated and dial equipment, and the problem now becomes trivial to solve.

Yep.

If it can be EASILY traced, it will stop being done. If you put these filters in place, the Smurfer will try to use a forged address and be dismayed when *nothing happens*. What's better, he won't KNOW that he's been filtered, and if you log the attempts you will know that someone tried and failed - which is a perfect reason to cancel their service.

Yep. Ok, so I agree with you completely. I thought I had made myself rather clear in the beginning. Oh well. I for one will be looking at integrating it into the setup here. Bar possible router load issues, it is a good idea and means when (and if) spoof attacks originate from our networks I can happily point to the client rather easily. :) adrian

On Sun, 28 Dec 1997, Bradley Reynolds wrote:

...

Huh? ICMP floods vs TCP floods. Aren't they both IP or have I missed something glaringly obvious.

Yes, both are independent of the network layer protocol which operates beneath them (which in this case is IP)

The difference is that you can filter icmp seperately from tcp to give you some sort of granularity with your acl policy. This is important in that if you deny icmp traffic to a specific segment of your network (or in from your serial interface for the whole thing) you are still vulnerable to the publicized attacks which exploit vulnerabilities inherent in TCP.

Yep. Or just a straight out 'lets spew packet' floods.

The whole point for this discussion was that you should be a responsible network administrator and understand the trouble you could cause the people you are connected to. Once you understand that, you can take use the facilities that your vendor provides to limit the damage so to speak.

Yep. I thought it was also just on generic spoofing/flooding and their impact on *EVERYONE*. Disabling icmp broadcasts on the router interfaces is fine, but later on someone will come up with something new, take advantage of (mis)configurations of networks, start blowing people's connections away, blah, blah, blah. I for one am for the access lists on interfaces to stop DOWNstreams abusing your network to flood others. Even if its just transit (no packet blooms like in smurf). Quite a bit of the current internet infrastructure is based upon trusting everyone who is connected to the network. And I for one certainly dont trust everyone on the network. Tightening up on things like this now would save a lot of pain and hassles later on. Adrian

At 12:05 PM 12/28/97 -0600, Karl Denninger wrote:

You don't want to filter ICMPs. What you want to filter is ANYTHING which came from an invalid source address *at your entrance* from your customer connections.

This is documented in: Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing; draft-ferguson-ingress-filtering-03.txt At the moment, we're trying to get this evntually published as an Informational RFC. More information can be found at: ftp://ftp.cert.org/pub/cert_advisories/CA-97.28.Teardrop_Land - paul

Ken Leland put this into my mailbox:

sure thing Karl, but its a virtual requirement that zillions of nets are ignoring, and getting 99.99 percent compliance will take serious time, if it is even doable. Without very high compliance the smurfkids will have readily available, low-bandwidth launch points that are the devil to trace. We need interim solutions, and icmp-echo-reply filtering is what we've got, *if* the backbones will continue to provide it.

I suspect the problem is that most nets were set up by consultants, and the people working at these companies/schools/whatever were instructed 'not to touch the internet box'. The consultant, then, is either no longer employed by the site or doesn't know about this (your average Novell CNE probably doesn't subscribe to NANOG). Perhaps if there were some sort of incentive; Ms. Hubbard and the InterNIC could make even more money by imposing some sort of penalty for noncompliance. They could even charge money for sites that don't read (or have) postmaster@ e-mail, and perhaps charge penalties for domains with out-of-date contact information, and make even more money. (Sorry; I've got an enormous flame about ARIN bottled up just looking for a venue; I promise I won't send it to NANOG.) Seriously, though, if nobody comes up with an incentive so that it will be harmful for sites NOT to implement these filters, folks can piss into the wind all they like, and absolutely nothing will happen. Spoofing has been a real problem for over a year now, and has shown no signs of going away. -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) I bet living in a nudist colony takes Founder, the DALnet IRC Network all the fun out of Halloween. e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/

Alex P. Rudnev writes...

What are you talking about? If they have NETFLOW switching and NETFLOW accounting, it's easy to search for the router originated for the SMURF/initialised packets (this packets can be searched by the such list, or by the simular search pattern):

xxx permit ip any 0.0.0.255 255.255.255.0 log

And then it takes 5 minutes to look for the originating interface.

Yeah. And that leads to another router, then another, then another. How about automating the process. That's what it looks like DoStracker does. As was pointed out to me, if I have just one or two routers or one or two links into the Internet, then I can easily find where the attack is coming from. But if I have a large complex network ... -- Phil Howard | crash547@no41ads6.com no63ads9@spammer7.edu stop1ads@no9place.edu phil | end3ads6@no79ads0.com no6spam8@dumbads1.org stop6it2@dumbads7.edu at | no43ads7@noplace1.net no44ads3@no40ads8.net suck8it0@s0p5a7m7.com milepost | stop7ads@dumbads7.edu w0x2y8z4@dumb5ads.edu no7way22@anywhere.net dot | no6spam4@no6where.com eat2this@lame2ads.edu ads8suck@dumb2ads.net com | no2spam2@s2p0a9m8.com suck0it2@no14ads4.net blow9me7@noplace5.com

-----BEGIN PGP SIGNED MESSAGE----- JimL; At 02:39 PM 12/27/97 -0800, Network Operations Center wrote:

Hello Karl & All, Where or at what price are these tools available.

MCI's tracing tool, DoSTracker, is available- free of charge - at MCI's Security Web site; http://www.security.mci.net/dostracker . Please let me know if you have ANY problems with it. Keep in mind that it was designed with specific operating conditions in mind; mostly that you'll need a tool of this nature to trace denial of service attacks (of a wide variety) across a backbone that you own, in order to find it's ingress point. If you're a single-homed end customer (AND you have a small internal network), DoSTrack isn't going to be a very worthwhile tool for you.

Tia, JimL PS: In a further responce Karl was heard to say :

...

The bottom line is that MONTHS after these were made available your NOC

crew

I never heard nor was made aware that these tools were available, even though I am an MCI Customer . :-(

Sorry - Identifying the specific and correct contact within all our end customers who would be interested in such a tool is a difficult task (and I don't make it a habit of sending unsolicited commercial email messages, even if they are to our customers :> ), which is why discussion lists of this nature where created, and DoSTracker was announced on this list. Feel free to visit; http://infopage.mci.net and http://www.security.mci.net, which should provide you the type of information you are looking for, and is regularly (?) updated. Dale "We all live in a Yellow Subroutine..." ================================================================ Dale Drew MCI Telecommunications Sr. Manager internetMCI Security Engineering Voice: 703/715-7058 Internet: ddrew@mci.net Fax: 703/715-7066 MCIMAIL: Dale_Drew/644-3335

On Sat, 27 Dec 1997, Karl Denninger wrote:

...

On Sat, Dec 27, 1997 at 01:24:05PM -0500, Reid B. Fishler wrote:

...

Just thought that I would post that as one of goodnet's larger customers (DS3), we are VERY satisfied with their NOC, as well as their service. Whenever I have a problem, I can get a member of the goodnet staff to respond quicker than my other upstreams...:-) (hint Sprint)

Reid Fishler Lightning Internet Services, LLC

Wait until you get smurfed and ask them to use the MCI-developed tracing tools and get a "duhhhhh" back in response.

They might have fixed this by now (since we bitched LOUDLY about this) but as of a few weeks ago the NOC had *no idea* how to trace this kind of activity - at all - nor any desire to learn.

-----BEGIN PGP SIGNATURE----- Version: PGP for Business Security 5.5 Comment: http://www.security.mci.net iQCVAwUBNKV+pUgZkk8pWFn9AQFWKQP/cUyFanBKKwL3SoH6hhAlikKCyjY4ibjm AJtzkjHXXEvnXPqG8IKioCSaJTy6DwIM9HCDI8Fpu+ISM0XOHk7FRPFIw0SUSOLd 8Bi2pCW7sWUtv+4LsNIA9/gfUUlALyUm8VgXqMUdekNq7htgYDhc6vXGbH/p8ES8 XznwbE3ddJY= =8C1b -----END PGP SIGNATURE-----

As opposed to getting smurfed and asking MCI security to use MCI-developed tracing tools and get "duhhhhh" back in response?

(You know it's going to be a bad day when...)

Actually we had a customer being DoS'd yesterday and after a call to MCI's security center, they had it tracked down within an hour and filters in place. --------------------------------------------------------------------------- ** Andrew W. Smith ** awsmith@neosoft.com ** Chief Network Engineer ** ** http://www.neosoft.com/neosoft/staff/andrew ** 1-888-NEOSOFT ** ** "Opportunities multiply as they are seized" - Sun Tzu ** ---------------------------------------------------------------------------

I *DID* open a trouble ticket BEFORE posting.

If you are THIS disconnected from what goes on in your own company, perhaps we need a new upstream provider.

To the Nanog community, Karl did contact our Network Operation Center, and was forwarded to the Engineer on call, who contacted Agis, and apparently cleared up the problem. Our Engineer did not open a trouble ticket, and handled the issue privately between Karl, Agis, and himself. Mistake number 1. I was not able to verify this information before posting my request for a trouble ticket number from Karl because this specific Engineer is up at the Grand Canyon at the moment, and was not available to consult. Mistake number 2. I apologize if anyone misread my posts as to state that Karl is a liar or that GoodNet does not care about it's customers best interests. Darin -- 'shredding packets around the world' ======================================================================== Darin Wayrynen, Chief Technology Officer, (602) 303-9500, darin@good.net