- Test - lists.nanog.org

Re: Possible scam: "Network Abuse"
by Vadim Antonov 05 Aug '98

05 Aug '98

Begging? That may be a lot more malicious. "Give me your firewall's password so i can fix it". Sure, dude. --vadim >From errors-nohumans(a)merit.edu Tue Aug 4 20:57:38 1998 X-UIDL: fc9be4f13610259e5d584676031c5dcc Date: Tue, 04 Aug 1998 20:46:51 -0700 (MST) From: Ehud Gavron <GAVRON(a)ACES.COM> Subject: Possible scam: "Network Abuse" To: nanog(a)merit.edu Cc: GAVRON(a)ACES.COM Organization: ACES Research Inc. MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary_[ID_5lnQtjNa7nT7upy77S5Jzg]" Sender: owner-nanog(a)merit.edu --Boundary_[ID_5lnQtjNa7nT7upy77S5Jzg] Content-type: TEXT/PLAIN; CHARSET=US-ASCII This "fellow" sent out this email. Unfortunately, our networks were not used to attack him (or anyone), and upon request for NTP-stamped logs, he quit responding to email. I recommend warning your downstreams that this kind of scam is only just begging. Imagine... $100 for "no ip direc...." E --Boundary_[ID_5lnQtjNa7nT7upy77S5Jzg] Content-type: MESSAGE/RFC822 Return-path: <wrath(a)ns1.jerky.net> Received: from ns1.jerky.net by ACES.COM (PMDF V5.1-7 #EHUD) with ESMTP id <01IZZYRAD8E891W60X(a)ACES.COM> for gavron; Thu, 30 Jul 1998 04:29:16 MST Received: (from wrath@localhost) by ns1.jerky.net (8.8.7/8.8.7) id MAA06007 for gavron(a)ACES.COM; Thu, 30 Jul 1998 12:31:26 +0000 (GMT) Date: Thu, 30 Jul 1998 12:31:26 +0000 (GMT) From: Andrew Shoemaker <wrath(a)jerky.net> Subject: Network Abuse - Netblock 198.182.116.0 - IMPORTANT To: "gavron(a)ACES.COM" <gavron(a)ACES.COM> Message-id: <199807301231.MAA06007(a)ns1.jerky.net> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Hello My name is Andrew Shoemaker and I am the head security consultant at JNS. We recently were the target of a denial of service attack that saturated our Internet connection. This attack, known as a 'smurf' attack, uses unknowing relays to source the at tack. By relaying the attack through your network the attack is made anonymous and increases in strength. This type of attack causes degraded performance on both the attacked and relay networks and is the result of an improperly configured router at you r site. I urge you to fix your routers. If you are unable to do so, or do not know how I suggest you call a security consultant. JNS is willing to fix your router permanently for a one time fee of $100 US. If you are interested in this deal please co ntact me and I will send you a copy of our security contract and an invoice. Netblock 198.182.116.0 was found to produce 19 replys for each packet sent. This means if the attacker is sending at T1 speeds the amount of your bandwidth used in relaying the attack is equivalent to 19 T1s regards, Andrew Shoemaker JNS Security wrath(a)jerky.net 617.442.5408 --Boundary_[ID_5lnQtjNa7nT7upy77S5Jzg]--

1 0

Possible scam: "Network Abuse"
by Ehud Gavron 05 Aug '98

05 Aug '98

This "fellow" sent out this email. Unfortunately, our networks were not used to attack him (or anyone), and upon request for NTP-stamped logs, he quit responding to email. I recommend warning your downstreams that this kind of scam is only just begging. Imagine... $100 for "no ip direc...." E

1 0

Re: NOC info and Network Status Pages
by Tim Wolfe 05 Aug '98

05 Aug '98

On Tue, 4 Aug 1998, Jim Browne wrote: > At 16:38 -0700 8/4/98, Tim Wolfe wrote: > >I've linked all the network status pages I could find to the names of the > >providers on this page. > > > >http://www.clipper.net/noc-info.html > > > >Please direct corrections/comments/flames to tim(a)clipper.net > > I don't understand. The links go to the respective provider's main web page. > > Sorry I guess I wasn't clear enough, the Provider's that I couldn't find NOC/Network Status pages for I linked to their home pages. I thought that would be better than nothing for. Take a look at MCI. Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

NOC info and Network Status Pages
by Tim Wolfe 04 Aug '98

04 Aug '98

I've linked all the network status pages I could find to the names of the providers on this page. http://www.clipper.net/noc-info.html Please direct corrections/comments/flames to tim(a)clipper.net Thanks, Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

leaking of routes by AS3549
by Alan Hannan 04 Aug '98

04 Aug '98

At approximately 1830 UTC [12:00 noon PDT] globalcenter [AS3549] started announcing full routes to peers at most exchange points with an AS-Path of 3549 [customer-as] [worlds view]. This was due to a misconfiguration by a downstream customer and the peering session filters during a customer turn-up. This incident started at approximately 1830 UTC and abated approximately 1705 UTC. It appears that the BGP withdrawal propogation is quite latent due to improper congestion due to this event, but the withdrawls are processing. We apologize for any inconvenience this caused you or your customers. We are reavaluating our turn-up policies and routing filters to prevent a problem such as this from occuring again. Please contact our network operations center (noc(a)globalcenter.net) with any questions or concerns. Our internal operations ticket is 9808040108. -alan

1 2

Re: Network Status Web Sites
by Tim Kempka 04 Aug '98

04 Aug '98

At 10:13 AM 8/4/98 -0700, you wrote: >I'm in the process of compiling a list of Network status pages for the >various larger NSPs. (ie http://www.noc.uu.net/) If anyone has pages for >Sprint, MCI, et al please let me know. When I get a decent number of links, >I'm going to put up a page on our site and I'll post the URL here. > >Thanks, > > Status site for FlashNet Communications is http://status.flash.net/ Tim Kempka ____________________________________________________ Tim Kempka E-Mail: tim(a)flash.net Network Engineer Pager: page_tim(a)flash.net FlashNet Communications Phone: 817-589-2390 ext. 378

1 0

Network Status Web Sites
by Tim Wolfe 04 Aug '98

04 Aug '98

I'm in the process of compiling a list of Network status pages for the various larger NSPs. (ie http://www.noc.uu.net/) If anyone has pages for Sprint, MCI, et al please let me know. When I get a decent number of links, I'm going to put up a page on our site and I'll post the URL here. Thanks, Tim --------------------------------------------------- Tim Wolfe, Network Administrator ClipperNet Internet Access Services tim(a)clipper.net 541.431.3360 voice 541.431.1176 fax ...Across the Desktop and around the World... ---------------------------------------------------

1 0

RE: Q:Why router with ATM interface comes out earlier than pure SONET interface?
by Christian Kuhtz 04 Aug '98

04 Aug '98

> Hmm. How would you assure per-application Quality-of-Service > without letting > the network explicitely know about application behaviour, i.e. signalling > those parameters and establishing some state within network nodes - read: > connection oriented ? How would you ? Even IP's approaches to this problem > are stateful. Clearly define your requirements. Otherwise this discussion is academic. Give me a scenario and I'll engineer you an IP QoS traffic engineering solution. How many "different" application specific behaviors does one need and make up a manageable quantity of CoS across a service provider network? I don't think you'll ever see more than half a dozen or so anytime soon. How exactly do you sell 64 different classes of service to customers? "I would like CoS #57, please." -- "Would you like fries with that, sir?" How is Cos #57 different from CoS #56 or #58? Signaling assumes connection oriented networking. The question is whether you really need to "signal" across the core of a network. Why does the entire core need to know about everything? IP QoS is fundamentally different from a traffic engineer point. You don't define pipes, like in ATM. You don't associate QoS characteristics to a given pipe, because you don't have pipes like in ATM. You define rates, you define drop policies and queuing policies on a per <insert the a defineable *packet* characteristic here>. My point being that all you ATM QoS bigots need to stop thinking like ATM and forget the idea of a connection pipe at the transporrt layer, and listen to us IP QoS bigots :). Perhaps we actually do have a point, and one doesn't actually need ATM. Am I making any sense? I think a Q&A model for this discussion would be best, especially considering the "bandwidth" limitations of all participating parties.. Cheers, Chris -- Christian Kuhtz, BellSouth Corp., Sr. Network Architect <ck(a)bellsouth.net> 1100 Ashwood Parkway, Atlanta, GA 30338 <ck(a)gnu.org> "Legalize free-enterprise murder: why should governments have all the fun?" -- /usr/games/fortune

2 1

Checked out GIP.ORG lately?
by Michael Dillon 04 Aug '98

04 Aug '98

When was the last time you looked at http://www.gip.org ? Here's a quote from "Internet Foundations: Breaking Technology Bottlenecks": It is to achieve these goals that the Global Internet Project (GIP) - a voluntary, international organization of primarily Internet software, hardware and service providers and telecommunications industry CEOs and senior executives - presents this paper. It aims to identify a set of potentially crippling bottlenecks and offer forward-looking recommendations on how to eliminate or minimize such barriers to sustainable Internet growth. ... The Internet's development to date has been as haphazard as it has been delightful, more a function of random entrepreneurial initiative than of mature planning. The time has come to balance entrepreneurial spirit with sophisticated planning, within the largely voluntary framework that always has characterized Internet growth. ... Toward that end, GIP recommends the convening of a summit, ideally late in 1998 or early in 1999, to explore the foundations of future Internet development. The summit would be international in scope, bringing together key Internet players, at the most senior levels, from both the private and nonprofit sectors to consider opportunities and bottlenecks in the four key areas discussed in this paper - end-user software and hardware, high speed access, backbone networks, and server capabilities. ... Backbone Networks Recommendations * Providers of backbone networks should be able to interconnect with other backbone providers under reasonable terms in a competitive market environment. * Industry should evolve to schemes where services at different grades carry their own costs, dictated by the market. To read the whole paper check out http://www.gip.org/gip10.htm but please do explore the rest of the website as well. -- Michael Dillon - Internet & ISP Consulting Memra Communications Inc. - E-mail: michael(a)memra.com Check the website for my Internet World articles - http://www.memra.com

1 0

Re: OUTAGE: Aug 3, 1998
by Sean Donelan 04 Aug '98

04 Aug '98

It appears several Cascade switches in Worldcom's frame-relay network had a problem. Atlanta, Dallas and Washington DC are reportedly the focus of current repair efforts. Although we saw problems in PVCs passing through several other locations. I received a private comment on my previous message. I'm not trying to pick on any one service provider. I know stuff happens to everyone. I too have royally messed up a network, and have my share of dumb programming mistakes. I attempt to rotate the particular concrete examples used. Hypotheticals are nice, but until you name names, no one pays attention. Which is more effective? Using the Hinsdale Central Office fire as a concrete example, or discussing in general the importance of employee training and responding to remote alarms. There are some common themes which run through my messages. It should be interesting to compare how Worldcom and Ascend handle this incident compared to how AT&T and Cisco handled their frame-relay incident. Oh, by the way, those Worldcom sales people who were calling AT&T customers last time. Guess what. What comes around, goes around. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0