- Test - lists.nanog.org

NSI again removes services
by Ehud Gavron 21 Oct '99

21 Oct '99

The ever-changing NICNAMES/whois service once again does not show _ANY_ dates -- creation, update, or database update. Of course the obnoxious and non-legaly-binding statement has moved, now to the top of the response. I sure wish NSI got rid of their lawyers and hired some techies. I sure wish the alternate registries could display this kind of date data. Ehud

12 15

Interesting - No reaction to a smurf
by Richard Irving 21 Oct '99

21 Oct '99

We currently have an ongoing attack, and cannot get a directly adjacent network to respond. (Participate in a traceback) The list at puck.nether.net has a few errors.... Jared: The following phone number is disconnected: Concentric Network Corp. internex.net, concentric.net, concentric.com 2828 +1 408 327 2470 noc(a)internex.net The phone number appears to be no longer operational. The email gets an auto-responder. We have not received a human response to an "urgent" in over 24 hours. :( We have an ongoing attack that has been running for over 48 hours total so far....... Would someone with Concentrics (IP Clueful) Security please contact me! (And while you are at it, please update puck's NOC contact list) You appear to have a script kiddie pointing smurf at a downstream. Thanks! Richard Irving One Call Communications, Inc.

3 3

Your morning FUD
by Austin Schutz 21 Oct '99

21 Oct '99

http://news.excite.com/news/zd/991020/12/report-warns-of SAN FRANCISCO -- Internet performance is too low to support serious transactional business by ASPs, and trends indicate that improvements may be inadequate over the next several years, a recent study has found. Northeast Consulting Resources Inc., of Boston, reports that the growing complexity of Web pages and increased network delays will reverse improvements in Internet performance built over the last four years. The findings are bad news for application service providers, which promise to deliver enterprise resource planning and customer relationship management applications. "When the ASP applications come, the time of reckoning will appear," Peter Sevcik, an analyst for NCRI, said earlier this month at the 1999 Global Internet Performance Conference here. Router runaround NCRI says technology improvements have cut the average download time of basic business Web pages from 12 seconds to 6 seconds since 1995, a significant drop despite a 120 percent increase in page size. However, those improvements may not be sustainable over the next three years because overall delays within the Internet have become significantly higher, due primarily to the increasing number of routers. More routers are added as sites deploy additional hardware to provide more scalability. The increasing number of router hops imposed upon data could deteriorate availability to about 9 seconds, the study found. NCRI based its study on data provided by Keynote Systems Inc., a San Mateo, Calif., Web performance research company that publishes the Keynote Business 40 Internet Performance Index, an industry benchmark based on the performance and reliability of 40 leading business Web sites. Keynote announced here at the conference the Keynote Consumer 40 Internet Performance Index, which will be based on the performance of 40 consumer Web sites accessed through a 56K-bps modem. Indexes also will be available for digital subscriber line and cable modems, and the whole package will be sold as the Keynote Consumer Perspective service, which will be available later this quarter, company officials said. Pricing was not yet available.

1 0

Traffic engineering tools
by Sean Donelan 21 Oct '99

21 Oct '99

At NANOG the lack of traffic engineering tools came up. Has anyone heard of any packages coming to market. Or looked if tools from other industries could be used as a starting point. Anything from the electric power transmission or road traffic world we could use? Or do IP packets have such different properties (e.g. re-transmission, independent next-hop behavior, etc), its not a good idea to even try.

1 0

TACACS or Radius daemon on Linux
by mnolan＠southshore.com 20 Oct '99

20 Oct '99

Hi, We are an ISP running several Cisco 2500s, 5200s, and 5300s as access servers. Currently we are entering each user into each box. We are looking to set up a Red Hat Linux machine as either a TACACS or Radius server to centrally validate all our users. Does anyone have any experience running a TACACS or Radius daemon on Linux? Where is a good place to find a Linux TACACS or Radius daemon? I heard that although TACACS is a Cisco product, Radius has more accounting and statistics capability, runs well on Linux, and will validate for Ciscos. Any help would appreciated. Thanks, Mike

7 6

RPSL Transition
by Mark Borchers 20 Oct '99

20 Oct '99

I didn't make it to Montreal, so please forgive me if this subject was covered at the conference. Some recent correspondence with the RA folks seems to indicate that the RIPE-181 database and the RPSL database are not being merged. Thus, when transitioning to RPSL, all objects for an AS (Maintainer, AS, and the rest) will need to be re-registered. Or am I mistaken? -- Mark Borchers Splitrock Services Network Engineering 9012 New Trails Dr. (281) 465-1200 The Woodlands, TX 77381 mborchers(a)splitrock.net http://www.splitrock.net/

2 1

virtual domain limit?
by mnolan＠southshore.com 20 Oct '99

20 Oct '99

Hi, Our web server is running Red Hat 5.2 (Linux). We were recently told that we have exceeded the limit number of domains on our system. We haven't been able to contact our tech support person since then to get a clarification. We recently added four domains, and our web pages promptly went down. He said that we had 167 domains and the limit was set to 165. Actually we only have 78 domains. This is really confusing. I do know that we are running all our domains off one IP using the NameVirtualHost directive in httpd.conf Does anyone know anything about a limit of domains setting? Any help would be appreciated. Thanks, Mike

1 0

Re: FW: your mail
by Alex P. Rudnev 20 Oct '99

20 Oct '99

Yes, about _just another etc_... But I am very sceptical about the PIX, in contra to IOS FW FS, because: - if you need L3 level firewaii (smart filtering), PIX have not enougph network capabilities, and is too expansive. In our (KIAE, not RELCOM) case, PIX can't work on the trunk (ISL), can't work by the ATM, and so on... On the other hand, if wee need next level firewall, it should be context level firewall, which work as proxy and prevent mail bombs, macro viruses, .EXE trojans ets. AS I know, PIX can't do it. And we have not _soft_ firewall features which can protect against the scattered scanning, simple intrusions etc withouth (almost) complex configuration and access restriction for the internal users... > Date: Tue, 19 Oct 1999 13:08:49 -0700 > From: Glen Shok <gshok(a)cisco.com> > To: Alex P. Rudnev <alex(a)Relcom.EU.net>, Robert E. Seastrom <rs(a)seastrom.com> > Cc: Alex "Mr. Worf" Yuriev <alex(a)netaxs.com>, Rubens Kuhl Jr. <rkuhljr(a)uol.com.br>, nanog(a)merit.edu, Stephen Sprunk <ssprunk(a)cisco.com>, rs(a)valhalla.seastrom.com > Subject: Re: FW: your mail > > Guess I am a little late in replying... > > Where do you guys get your rumors about hardware??? > Anyway... > > The FW feature set on the 7500 is just another layer of protection and shouldn't be compared to the > performance of, say, using a PIX in front of your Internet Connection(s). > > Glen > > The preceding information is provided by "Glen" and not by "Cisco Systems", blah blah blah...insert legal stuff here.... > > > At 03:15 PM 9/27/1999 +0400, Alex P. Rudnev wrote: > > >Folks, why all you are saying about the Gigabit traffic for the firewall? > > > >Usially, firewall stand between intranet and internet, and it should > >proceed your upstream traffic, not more... And than, it's important to > >measure the throughput in packets/per_second, not in the gigabits... > > > >Everything other is true - I suggess no one good firewall can proceed > >gigabit traffic at all, and only a few specially designed boxes can > >proceed 100Mbit traffic. But just again - it's a rare case when you does > >have 100Mbit upstream link. > > > >Alex. > > > >On 25 Sep 1999, Robert E. Seastrom wrote: > > > > > Date: 25 Sep 1999 21:26:59 -0400 > > > From: Robert E. Seastrom <rs(a)seastrom.com> > > > To: "Alex \"Mr. Worf\" Yuriev" <alex(a)netaxs.com> > > > Cc: "Rubens Kuhl Jr." <rkuhljr(a)uol.com.br>, nanog(a)merit.edu, > > > Stephen Sprunk <ssprunk(a)cisco.com>, rs(a)valhalla.seastrom.com > > > Subject: Re: FW: your mail > > > > > > > > > > > > > > > I have listened to their seminar about this... As the simple L5 firewall > > > > > > it's not bad, through it realise the fixed set of ruls and defends your > > > > > > from the simple SMTP attacks only. But anyway, IOS FW is just what 90% of > > > > > > the customers need... > > > > > > > > > > How would IOS FW perform on Cisco 7x00-class equipment with 100M-to-Gigabit > > > > > traffic ? > > > > > > > > Umm... Very poorly. > > > > > > At the low end it's acceptable. Gigabit traffic sucks on 7500 series > > > routers even without any kind of filtering. > > > > > > The 7000-series routers, if they have an SSE, will do standard and > > > extended access lists in the switch engine. Now, given the > > > limitations of CX-FEIP-2TX boards (the only faste boards that will > > > work in a non-RSP 7000), you are lucky to get 70 mbit/sec through > > > that. If you have fddi, you can get most of the way to 100 mbit/sec > > > one way (the CX-FIP cards, which are the only FDDIs that work in a > > > 7000, won't do full-duplex). > > > > > > The 7500-series routers, you really want to get a VIP2-50 rather than > > > a 2-40 or lower if you're going to be doing filtering on the linecard. > > > You can load the fast ethernets up just fine there. > > > > > > 400 mbit/sec seems to be the upper limit of the currently shipping > > > generation of gigE cards for the 7500 series. > > > > > > Hope this helps (and standing by for corrections from the #cisco IRC mafia...) > > > > > > ---Rob > > > > > > > > > > > > >Aleksei Roudnev, Network Operations Center, Relcom, Moscow > >(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) > >(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax) > > > > > > > ------------------------------------------------------------------------------------------- > Glen Shok Phone: 1.650.404.3594 > Systems Engineer Cell: 1.415.215.7279 > NSP Norcal Operation Pager: 1.800.365.4578 > > Jack thought it twice, and thought that that that made it true. > > Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)

1 0

Re: NSI again removes services
by Dean Anderson 20 Oct '99

20 Oct '99

Hmm. I always thought the unix tip command was a reference to tip and ring of phone line pairs. This sounds more likely... Something for Peter Salus... --Dean Around 12:36 PM 10/19/1999 -0700, rumor has it that hardie(a)equinix.com said: >> TAC as in tacacs? > >Yep. The original TACACS specification was in a BBN technical >memo, CC-0045; RFC 1492 contains an informal specification >of the extended version that Cisco implemented. The background >section of RFC 1492 gives a bit of the history: > >Background > > There used to be a network called ARPANET. This network consisted of > end nodes (hosts), routing nodes (IMPs) and links. There were (at > least) two types of IMPs: those that connected dedicated lines only > and those that could accept dial up lines. The latter were called > "TIPs." > > People being what they were, there was a desire to control who could > use the dial up lines. Someone invented a protocol, called "TACACS" > (Terminal Access Controller Access Control System?), which allowed a > TIP to accept a username and password and send a query to a TACACS > authentication server, sometimes called a TACACS daemon or simply > TACACSD. This server was normally a program running on a host. The > host would determine whether to accept or deny the request and sent a > response back. The TIP would then allow access or not, based upon > the response. > > While TIPs are -- shall we say? -- no longer a major presence on the > Internet, terminal servers are. Cisco Systems terminal servers > implement an extended version of this TACACS protocol. Thus, the > access control decision is delegated to a host. In this way, the > process of making the decision is "opened up" and the algorithms and > data used to make the decision are under the complete control of > whoever is running the TACACS daemon. For example, "anyone with a > first name of Joe can only login after 10:00 PM Mon-Fri, unless his > last name is Smith or there is a Susan already logged in." > > The extensions to the protocol provide for more types of > authentication requests and more types of response codes than were in > the original specification. > > The original TACACS protocol specification does exist. However, due > to copyright issues, I was not able to obtain a copy of this document > and this lack of access is the main reason for the writing of this > document. This version of the specification was developed with the > assistance of Cisco Systems, who has an implementation of the TACACS > protocol that is believed to be compatible with the original > specification. To be precise, the Cisco Systems implementation > supports both the simple (non-extended) and extended versions. It is > the simple version that would be compatible with the original. > > Please keep in mind that this is an informational RFC and does not > specify a standard, and that more information may be uncovered in the > future (i.e., the original specification may become available) that > could cause parts of this document to be known to be incorrect. > > This RFC documents the extended TACACS protocol use by the Cisco > Systems terminal servers. This same protocol is used by the > University of Minnesota's distributed authentication system. > > > regards, > Ted Hardie > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2

Re: TACACS or Radius daemon on Linux
by Dean Anderson 19 Oct '99

19 Oct '99

I'm not currently running Radius on linux, but I expect there are several possibilities that will run fine under linux. A good list was just posted here several days ago. You certainly don't want to be putting accounts on each box, especially if you have more than one. Your cisco's will do both tacacs and radius. Somehow, Radius seems to have beaten out tacacs in popularity though. Also, you might want to consider using RADIUS for accounting instead of syslog or none at all. --Dean Around 03:49 PM 10/19/1999, rumor has it that mnolan(a)southshore.com said: > >Hi, > >We are an ISP running several Cisco 2500s, 5200s, and 5300s as access >servers. Currently we are entering each user into each box. > >We are looking to set up a Red Hat Linux machine as either a TACACS or >Radius server to centrally validate all our users. > >Does anyone have any experience running a TACACS or Radius daemon >on Linux? Where is a good place to find a Linux TACACS or Radius >daemon? > >I heard that although TACACS is a Cisco product, Radius has more >accounting and statistics capability, runs well on Linux, and will >validate for Ciscos. > >Any help would appreciated. > >Thanks, >Mike > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0