- Test - lists.nanog.org

Re: "portscans" (was Re: Arbor Networks DoS defense product)
by Tim A.Irwin 20 May '02

20 May '02

> > From: Mitch Halmu <mitch(a)netside.net> > Date: 2002/05/19 Sun PM 11:32:20 EDT > To: Dan Hollis <goemon(a)anime.net> > CC: "'nanog(a)merit.edu'" <nanog(a)merit.edu> > Subject: Re: "portscans" (was Re: Arbor Networks DoS defense product) > > > > On Sun, 19 May 2002, Dan Hollis wrote: > > > netside has been a long time lunatic opponent of RBLs Wait for it... wait for it... here it comes... > First they came for the Communists, > and I didn't speak up, > because I wasn't a Communist. > Then they came for the Jews, > and I didn't speak up, > because I wasn't a Jew. > Then they came for the Catholics, > and I didn't speak up, > because I was a Protestant. > Then they came for me, > and by that time there was no one > left to speak up for me. > > (Rev. Martin Niemoller, 1945) > > --Mitch > NetSide > SCORE!!! And the point is awarded to Dan!

2 1

Peering BOF V - Call for Participants
by William B. Norton 20 May '02

20 May '02

Hi all - NANOG is only three weeks away and Monday evening at NANOG there will be another Peering BOF ; thanks to those that suggested this on the survey forms! We'll do this the same way as last time / the same way the Peering Personals ran at the last GPF: *Peering Coordinators*: Send me the completed RSVP form below. I'll assemble these into logos, icons, AS#s and contact info With this backdrop, each of you in turn get a chance to stand up and a) introduce yourself, your network, b) what you are looking for in a peer, c) why folks should want to peer with you, and d) which locations you currently or plan to peer. Making the initial contact with the potential peer is (oddly enough) the most difficult parts of peering, and the Peering Personals has proven to be an effective (and lively!) way to make those initial contacts. So *Peering Coordinators* - send me those RSVPs ! Since we only have 90 minutes I'm going to limit the number of Peering Coordinators to 25 or so. If there is time remaining we'll use the rest of the time for ad hoc Peering Personals as we did last time. A couple comments: I noticed on the thread "Interconnects" folks were talking about willingness to peer and MLPAs. At least from the conversations I had during my research on Peering, I found relatively little interest in MLPAs. For those using contracts for peering, folks preferred to control peering using their own contracts written by their lawyers, stating their evolving peering terms and conditions, and generally felt somewhat like they were losing control by signing up to a MLPA document. At the same time, I have found from running these Peering Personals and talking with these Peering Coordinators, that maybe 80% of all Peering Coordinators had a relatively open peering policy. By "Relatively Open" I mean that they would peer in any single location or multiple location with companies that they would not consider to be a prospective customer. This openness was surprising given all the huff and puff on mailing lists over the years about *not* being able to get peering. We'll see if my 80% figure rings true at the Peering BOF, and I'll share a couple anecdotes about an emerging set of significant traffic open peers at the Peering BOF. Bill ------------------ RSVP FORM ------------------------------ Clip Here --------------------------- Please Fill out and e-mail to wbn(a)equinix.com with Subject: Peering BOF V Name: ______________________ Email: ______________________ Title: ______________________ Company: ___________________ AS#(s): _____________________ Check each that applies: ___ We are an ISP (sell access to the Internet) -- OR -- ___ We are a Non-ISP (content company, etc.) ___ We are Content-Heavy -- OR -- ___ We are Access-Heavy ___ We generally require peering in multiple locations -- OR -- ___ We will peer with anyone in any single location ___Peering with Content Players or Content Heavy ISPs is OK by us ___ We have huge volumes of traffic (lots of users and/or lots of content) (Huge: > 1 Gbps total outbound traffic to peers and transit providers) ___ We have a global network ___ We require written contracts for peering ___ We have a U.S. Nation-Wide Backbone (East Coast, West Coast, and at least one location in the middle) ------------------------------------------- snip ------------------------------------------------

1 0

Re: Network Reliability Engineering
by Nigel Clarke 20 May '02

20 May '02

Try the "The Art of Testing Network Systems" ISBN: 0-471-13223-3 --- Nigel Clarke Network Security Engineer nigel(a)forever-networks.com

1 0

Re: "portscans" (was Re: Arbor Networks DoS defense product)
by Scott Gifford 19 May '02

19 May '02

"Stephen J. Wilcox" <steve(a)opaltelecom.co.uk> writes: > On 18 May 2002, Scott Gifford wrote: > > > > > Scott Francis <darkuncle(a)darkuncle.net> writes: > > > > [...] > > > > > And why, pray tell, would some unknown and unaffiliated person > > > be scanning my network to gather information or run recon if > > > they were not planning on attacking? I'm not saying that you're > > > not right, I'm just saying that so far I have heard no valid > > > non-attack reasons for portscans (other than those run by > > > network admins against their own networks). > > > > Before choosing an onling bank, I portscanned the networks of the > > banks I was considering. It was the only way I could find to get > > a rough assessment of their network security, which was important > > to me as a customer for obvious reasons. > > I would argue that this is not good practice and you dont have the > right to intrude on the workings of the banks network just because > you have the technology to do so.. if a telnet port was open would > you also check that you were unable to brute force your way in? That > is to say.. what exactly were you hoping to find and then do with > the results? I'm not arguing it's good practice. I'm giving it as an example of a reason why somebody might scan your network, even though they were not planning on attacking. ----ScottG.

2 1

Re: Re[2]: "portscans" (was Re: Arbor Networks DoS defense product)
by JC Dill 19 May '02

19 May '02

On 07:50 AM 5/19/02, Ralph Doncaster wrote: > >> RD> I often like to know if a particular web server is running Unix or >> RD> Winblows. A port scanner is a useful tool in making that determination. >> >> [allan@ns1 phpdig]$ telnet www.istop.com 80 >> Trying 216.187.106.194... >> Connected to dci.doncaster.on.ca (216.187.106.194). >> Escape character is '^]'. >> HEAD / HTTP/1.0 >> >> HTTP/1.1 200 OK >> Date: Sun, 19 May 2002 01:47:57 GMT >> Server: Apache/1.3.22 (Unix) FrontPage/4.0.4.3 PHP/4.1.2 mod_fastcgi/2.2.8 > >Sure, it works on some servers, but try it on yahoo.com, cnn.com, ... <http://uptime.netcraft.com/up/graph/?mode_u=off&mode_w=on&site=www.cnn.com> Works for me, works from any system that has a browser. At any given time I'm *far* more likely to have a browser running than port scanning software, so this solution is also IMHO faster. jc

2 1

Network Physics
by Timothy Brown 19 May '02

19 May '02

Does anyone on the list have experience with Network Physics? Their product looks pretty good on paper, but I have to admit i'm a little skeptical about products in this class. Does anyone have some insight or some experience with the product, good or bad? Please send replies privately. If there's enough interest, i'll summarize. Thanks, Tim

1 0

Re: "portscans" (was Re: Arbor Networks DoS defense product)
by Johnny Eriksson 19 May '02

19 May '02

Ralph Doncaster <ralph(a)istop.com> writes: > I often like to know if a particular web server is running Unix or > Winblows. A port scanner is a useful tool in making that determination. > > <sarcasm> > And why, pray tell, would some stranger be carrying a concealed gun if > they were not planning on shooting someone? > </sarcasm> Maybe there is a difference between carrying a concealed portscanner and actually using one? --Johnny

1 0

You are invited to participate
by Sean Donelan 19 May '02

19 May '02

In 1999 the President's National Security Telecommunications Advisory Committee (NSTAC) published a report which concluded: "In summary, end-to-end NS/EP services cannot currently be offered via the public Internet. A number of factors (e.g., lack of NS/EP demand, market factors, and lack of regulatory mandates) make it unlikely that the same type of NS/EP services available in the PSN will be available over the Internet for the foreseeable future." Well, its now 2002 and things have changed. Both the FCC Network Reliablity and Interoperability Council (NRIC) and the NCS National Security Telecommunication Advisory Committee (NSTAC) are inviting ISPs to participate in their activities. Since they are busy writing reports about the Internet it might be nice to actually have some people with an Internet perspective. Did you know the next generation Internet will have a MPLS core? http://www.ncs.gov/nstac/nstac.htm FOR MORE INFORMATION ON NSTAC call (703) 607-6209 http://www.nric.org/ NRIC VI Contact PAMELA J. STEGORA AXBERG CHAIR, NRIC VI STEERING COMMITTEE OFFICE: 763-531-6000 FAX: 763-536-5041 CELL: 612-816-7767 EMAIL: pstegor(a)qwest.com 9700 SCHMIDT LAKE ROAD, ROOM 300 PLYMOUTH, MN 55442

1 0

Fwd: RE: Network Reliability Engineering
by blitz 19 May '02

19 May '02

>AHH, MTBF date from vendors....well, there goes the idea of THAT project. >You'll find that data, IF you can find it, will be calculated by sales >cretins, not engineers. >Check out this book: > > "High-Availability Network Fundamentals" > Cisco Press > ISBN 1-58713-017-3 > >Despite its Cisco Press origin, the book is 99% vendor-neutral and applies >to any equipment. It helps you calculate MTBF-based availability of entire >network paths, factoring in various types of redundancy. You're on your own >collecting actual MTBF data from vendors, but this book may help you put it >together into something sensible.

1 0

RE: Network Reliability Engineering
by Jason Young 18 May '02

18 May '02

Check out this book: "High-Availability Network Fundamentals" Cisco Press ISBN 1-58713-017-3 Despite its Cisco Press origin, the book is 99% vendor-neutral and applies to any equipment. It helps you calculate MTBF-based availability of entire network paths, factoring in various types of redundancy. You're on your own collecting actual MTBF data from vendors, but this book may help you put it together into something sensible. > -----Original Message----- > From: Pete Kruckenberg [mailto:pete@kruckenberg.com] > Sent: Saturday, May 18, 2002 6:13 PM > To: nanog(a)merit.edu > Subject: Network Reliability Engineering > > > > I'm looking for some good reference materials to do some > "reliability engineering" calculations and projections. > > This is to justify increased redundancy, and I want to > include quantifiable numbers based on MTBF data and other > reliability factors, kind of a scientific justification > instead of just the typical emotional appeal using analyst/vendor FUD. > > I'd appreciate references on how to do this in a network > environment (what data to collect, how to collect it, how to > analyze, etc). Also any data (or rules of thumb) on typical > MTBFs for network events that I won't find on vendor product > slicks (like what's the MTBF on IOS, or human-caused service > outages of various types, etc). > > If someone has put together something remotely like this > that they'd care to share, that'd be incredibly helpful. > > Thanks. > Pete. > >

1 0