- NANOG - lists.nanog.org

Juniper T Series routers
by Bob Procter 09 Sep '02

09 Sep '02

Does anyone have any opinions on the Juniper T Series routers that they can share? Reply off-list, I'm happy to summarise responses. Thanks & regards, Bob Procter, ntl Group Limited. The contents of this email and any attachments are sent for the personal attention of the addressee(s) only and may be confidential. If you are not the intended addressee, any use, disclosure or copying of this email and any attachments is unauthorised - please notify the sender by return and delete the message. Any representations or commitments expressed in this email are subject to contract. ntl Group Limited

1 0

Eugene Call for Presentations
by Susan Harris 09 Sep '02

09 Sep '02

Hi - just a reminder that abstracts are due this Monday, Sept. 16. * * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS NANOG 26 GENERAL SESSION TUTORIALS SPECIAL RESEARCH/OPERATIONS FORUM October 27-29, 2002 * * * * * * * * * * * * * * * * * The North American Network Operators' Group (NANOG) will hold its 26th meeting October 27-29, 2002, in Eugene, Oregon. The meeting will be hosted by the University of Oregon and Sprint. Registration opens September 4. NANOG 26 is a special occasion - the first joint meeting with ARIN, the American Registry for Internet Numbers. ARIN manages IP numbers for North and South America, the Caribbean, and sub-Saharan Africa. NANOG will meet as usual from Sunday to Tuesday, and ARIN from Wednesday to Friday. NANOG conferences provide a forum for the coordination and dissemination of technical information related to large-scale (i.e., national/international) Internet backbone networking technologies and operational practices. Meetings are held three times each year, and include two days of short presentations, plus afternoon/evening tutorial sessions and special forums. The meetings are informal, with an emphasis on relevance to current backbone engineering practices. NANOG conferences draw over 500 participants, mainly consisting of engineering staff from national service providers, and members of the research and education community. The meeting will be held at the Hilton Eugene and Conference Center. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Previous meetings have included presentations on: - Backbone traffic engineering - Inter-provider security and routing protocol authentication - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Cooperative inter-provider caching - Alternatives to hot-potato routing - Recommendations on queue management and congestion avoidance - Experience with differentiated services - Inter-domain multicast deployment - Backbone network failure analysis Tutorials have covered topics such as: - IP traffic management - BGP multihoming guide - ISP security: real world techniques - IP multicast technologies The special research/operations forum offers researchers a short time slot to present ongoing work for evaluation and feedback from the operations community. Topics include routing, network performance, statistical measurement and analysis, and protocol development and implementation. Researchers from academia, government, and industry are invited to participate. ------------------------------------------------------------------------------ HOW TO PRESENT Submit a detailed abstract or outline describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is September 16, 2002. While the majority of speaking slots will be filled by September 16, a limited number of slots will be available after that date for topics that are exceptionally timely and important. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by September 30, 2002. NANOG also welcomes suggestions/recommendations for tutorials, panels and other presentation topics. ---------------------------------------------------------------------------

1 0

Re: Baltimore train tunnels (was Re: Vulnerbilities of Interconnection)
by William B. Norton 09 Sep '02

09 Sep '02

At 09:47 PM 9/7/2002 -0400, Sean Donelan wrote: >Unlike phone calls, TCP traffic doesn't occur in fixed bandwidth >increments. TCP traffic, 90% of Internet traffic, is elastic. By design, >TCP adjusts the traffic rate to keep the bottleneck congested. As the >bottleneck moves, traffic reacts by increasing or decreasing the rate to >match the available capacity. This feedback occurs independently of what >is happening on nearby traffic paths. Even if there is available >capacity on elsewhere, the current Internet design is not very good at >using it. Some people view this as an inefficient use of available >capacity, other people view it as a self-protective mechanism. Thank Goodness for well-behaved applications, right? ( Misbehaving TCP stacks and UDP-based apps don't obey these back off rules. ) I remember Van Jacobson gave a presentation back in 1997 that spoke about the problems with applications that didn't exhibit these characteristics: http://www.academ.com/nanog/october1997/ It would be interesting to see some recent verification that well-behaved TCP-apps are the norm on the Internet...any data out there in this regard? Bill

2 1

casual programming and network operations
by Adam Atkinson 08 Sep '02

08 Sep '02

Some of my colleagues appear to think that things like perl are so arcane that only I can do them. I have offered to do a _really_ basic introduction to perl (and unix shell stuff) tailored to what my colleagues might possibly use it for, and several people have expressed an interest. It has to be admitted that I only use quite basic features of perl myself, but my own experience has been that it's possible to do genuinely useful things knowing only tiny bits of it. (My experience with C has been otherwise, at least for the sorts of things I find myself wanting to do.) My intention is to try to get the message across using real-world examples which achieve something clearly useful, without using many features of the language. Preferably examples where doing it entirely by hand (or with a spreadsheet or editor) would be awkward enough that learning 3 things about perl and writing a script seems faster and/or more appealing. I would, for example, only (or initially?) use examples that use standard input and output, since you can achieve plenty that way. And no modules until/unless people are sold on the basic idea. And, to keep the scripts looking as undaunting as possible, no "die" statements, no checking of input, etc. (I know how daunting I find "simple" programs 3 pages long) Four examples which seem good to me would be: (i) going through Apache logs and listing the IP addresses from which Nimda attacks came. (via grep | cut | sort | uniq, and/or with perl) (ii) removing mysterious binary characters in otherwise clean log files (since this has actually happened to us) using tr (iii) reversing netmasks, so that lines of the form "120.1.0.0 255.255.128.0" can be turned into,say, "access-list 142 permit ip any 120.1.0.0 0.0.127.255" (iv) Using cron and expect to log in to a router periodically and do something to it. (to be concrete, get data from it and feed it to mrtg) Taking (iii) as a concrete example: I have upon occasion been given 200+ networks I needed to do this to, and it strikes me as a perfect applicaction for a perl script that uses only stdin and stdout for this audience, though not as a first example. It's a realistic task, and doing it by hand for 200 networks would be annoying. What are some other ways of doing (iii)? One person I asked said "load it into Excel and do search/replaces on the network masks until you've covered all those used". This isn't bad, it has to be said. I watched someone spend hours doing (ii) with Word, which doesn't feel right at all. To what extent do people feel that "casual grade" unix or Perl knowledge to this sort of level is useful in network operations? Even if experts are available, I wouldn't like to think it's necessary to disturb them for this sort of thing. Is it reasonable, when trying to sell some non-programmers on the idea that basic scripting is useful and possible, to deliberately omit -w, use strict, die, syslog and similar? In a 3-6 line script, that kind of stuff would take up more space than the actual "meat" and risk going against my "this isn't so hard, really" message. If forced to do (i)-(iv) without using scripting of any kind, I'd become quite annoyed. To be fair, (iv) clearly has to be scripted. Are there other reasonable non-scripting methods of doing (i)-(iii)? NB I'm not planning on claiming perl is uniquely wondrous. I just don't know enough tcl, python, ruby or rexx to show anyone how to do anything with them - and my own experience has been that you can use expect without knowing any tcl except some "lindex" stuff to read command-line parameters in. Does what I propose seem more useful or dangerous? I think my main aim is to show useful non-artificial examples as quickly as possible. Talking about loop structures, scalars vs arrays vs hashes etc. seems like exactly the wrong way to do. It seems to me that while (<>) { (stuff) } can be used as the basis of useful stuff. (Also, one of the main messages would be that the most important skill is taking an existing script and tweaking it, even if you don't know how some of it works.) Of course, I'd tell people that knowing other features as well might allow more to be done, but I wouldn't want to push people into using modules, objects, references, etc. -- Adam Atkinson (ghira(a)mistral.co.uk) Do not look into laser with remaining eye.

3 2

Re: Very large JoeJob in progress against Spamcop (fwd)
by J.A. Terranson 08 Sep '02

08 Sep '02

---------- Forwarded message ---------- Date: Sat, 7 Sep 2002 10:41:54 -0400 From: Ellen <deputies(a)admin.spamcop.net> To: J.A. Terranson <measl(a)mfn.org> Subject: Re: Very large JoeJob in progress against Spamcop (fwd) Thanks for the CC of your email to valueweb! Ellen ----- Original Message ----- From: "J.A. Terranson" <measl(a)mfn.org> To: <appeals(a)admin.spamcop.net> Sent: Saturday, September 07, 2002 9:53 AM Subject: Very large JoeJob in progress against Spamcop (fwd) > > > ---------- Forwarded message ---------- > Date: Sat, 7 Sep 2002 08:51:00 -0500 (CDT) > From: J.A. Terranson <measl(a)mfn.org> > To: incidents(a)securityfocus.com > Cc: abuse(a)valueweb.com, abuse(a)spamcop.net > Subject: Very large JoeJob in progress against Spamcop > > > I have received a boatload of these, from a Valueweb customer > impersonating Julian Haight/SpamCop. The subject lines vary among a > fixed list, including the below "Spam from your network", "Spamcop is > watching you", "Spamcop will shut down your website", etc. > > Valueweb is a home-user DSL provider, and the origin IP of these is > clearly not SpamCop. > > Yours, > > J.A. Terranson > sysadmin(a)mfn.org > > ---------- Forwarded message ---------- > Return-Path: <abuse(a)spamcop.net> > Received: from spamcop.net ([64.70.191.50]) > by cliff.mfn.org (8.11.1/8.9.3) with SMTP id g87AKkc12347 > for <abuse(a)convictedchildmolesters.org>; Sat, 7 Sep 2002 05:20:47 -0500 (CDT) > (envelope-from abuse(a)spamcop.net) > Message-Id: <eg1oqcdsl67apkbd.6l7i2p113n0(a)spamcop.net> > Reply-To: spam.reporting(a)reports.spamcop.net > To: abuse(a)convictedchildmolesters.org > X-Mailer: X-Mailer: Web Based Pronto > From: abuse(a)spamcop.net > MIME-Version: 1.0 > X-Encoding: MIME > Content-Type: multipart/alternative; > boundary="----=_NextPart_38663300828774" > Date: Sat, 07 Sep 2002 06:25:28 -0500 > Subject: Spam from your network > > SpamCop.net - protecting the internet through technology > > > Why Am I Getting This Email? > > You have recieved this email because spamcop.net has had recent complaints related to your network (convictedchildmolesters.org) > > > What Types of complaints? > > Open mail ports, violations of our acceptable use polices, and other various complaints. EMail us for specifics... > > > What do I need to do? > > Close any open relays on your network, enforce a anti spam A.U.P. (Acceptable USse Policy), and shut down abusive users. > > SpamCop's original spam reporting service will help you report spam quickly and accurately. Or choose from a variety of filtering options ranging from the easiest web-mail account to advanced network-wide spam blocking. > > Accused of spamming? > > Answers to most common questions. Like: My email was blocked! SpamCop got it wrong! How can I fix it? Falsely accused? What is spam? Find help here for internet and hosting providers, small and large-scale bulk mailers and advertisers. > > > Other Questions or Comments? > > SpamCop has several dedicated (and spam-free) news groups where you can get help, suggest new features or report bugs. Or you can search the entire site, FAQ and all support-forum content in one place. > > > Reporting and Filtering Options.. > > VISIT http://spamcop.net > > > > Copyright (c) 1998-2002 Julian Haight, All rights reserved. jane42(a)mail.julianhaight.com > > > >

2 1

Re: Vulnerbilities of Interconnection
by sgorman1＠gmu.edu 08 Sep '02

08 Sep '02

You also have the problem of cascading failures. Just because there are redundant paths and alternate peering locations does not mean those facilites have the bandwidth to handle all the redirected traffic. If A gets swamped you go to B if the redrected traffic is to much for B then you go to C and so on - each time the amount of traffic increases and the avialble bandwidth decreases. According to the analysis I've seen and run on the the Baltimore incident this is the jest of how a few cut lines rippled across the Internet. I would think Alex's scenario would have a bigger impact than that incident. sean ----- Original Message ----- From: alex(a)yuriev.com Date: Friday, September 6, 2002 10:29 am Subject: Re: Vulnerbilities of Interconnection > > > > > > > Lets bring this discussion to a some common ground - > > > > > > What kind of implact on the global internet would we see > should we observe > > > nearly simultaneous detonation of 500 kilogramms of high > explosives at N of the > > > major known interconnect facilities? > > > > N? Well, if you define N as the number of interconnect > facilities, such > > as all the Equinix sites > > Lets say that N is 4 and they are all in the US, for the sake of the > discussion. > > > (and I'm not banging on Equinix, it's just > > where we started all this) then I think globally, it wouldn't > make that > > much difference. People in Tokyo would still be able to reach > the globe > > and both coasts of the US. > > This presumes that the networks peer with the same AS numbers > everywhere in > the world, which I dont think they do. > > The other thing to think about is that the physical transport will be > affected as well. Wavelenth customers will lose their paths. Circuit > customers that rely on some equipment located at the affected > sites, losing > their circuits. > > Alex > > >

2 1

JoeJob against Spamcop: Update
by J.A. Terranson 07 Sep '02

07 Sep '02

Having now received *thousands* of these gems from Valueweb, I finally called them... They ack'd being aware of this issue, however, they were under the impression it has been "resolved" (which, oddly enough, did not include the killing of the responsible user). They claimed this IP would be killed immediately, so if anyone gets any of these with a timestamp after this email, you need to contact Valueweb: +1-954-334-8080. ---------- Forwarded message ---------- Return-Path: <webmaster(a)spamcop.net> Received: from mx2.spamcop.net ([64.70.191.50]) by cliff.mfn.org (8.11.1/8.9.3) with SMTP id g87K6Ac14571 for <info(a)anthraxtheater.org>; Sat, 7 Sep 2002 15:06:10 -0500 (CDT) (envelope-from webmaster(a)spamcop.net) From: webmaster(a)spamcop.net To: info(a)anthraxtheater.org Reply-To: spam.reporting(a)reports.spamcop.net Message-Id: <4i37rkb0j84p312.6fsw4j814skj(a)mx2.spamcop.net> MIME-Version: 1.0 X-Encoding: MIME Content-Type: multipart/alternative; boundary="----=_NextPart_468383874800666524434" X-Mailer: X-Mailer: Microsoft Outlook Express 5.00.2615.200 Subject: Your network is being compromised Date: Sat, 07 Sep 2002 16:10:52 -0500 SpamCop.net - protecting the internet through technology Why Am I Getting This Email? You have recieved this email because spamcop.net has had recent complaints related to your network (anthraxtheater.org) What Types of complaints? Open mail ports, violations of our acceptable use polices, and other various complaints. EMail us for specifics... What do I need to do? Close any open relays on your network, enforce a anti spam A.U.P. (Acceptable USse Policy), and shut down abusive users. SpamCop's original spam reporting service will help you report spam quickly and accurately. Or choose from a variety of filtering options ranging from the easiest web-mail account to advanced network-wide spam blocking. Accused of spamming? Answers to most common questions. Like: My email was blocked! SpamCop got it wrong! How can I fix it? Falsely accused? What is spam? Find help here for internet and hosting providers, small and large-scale bulk mailers and advertisers. Other Questions or Comments? SpamCop has several dedicated (and spam-free) news groups where you can get help, suggest new features or report bugs. Or you can search the entire site, FAQ and all support-forum content in one place. Reporting and Filtering Options.. VISIT http://spamcop.net Copyright (c) 1998-2002 Julian Haight, All rights reserved. jane42(a)mail.julianhaight.com

1 0

SpamCop Forgeries
by Marius Strom 07 Sep '02

07 Sep '02

FYI, for those of you who get worried when you see mail from spamcop hitting your postmaster addresses: http://www.julianhaight.com/forgery.shtml It may be forged. -- /-------------------------------------------------> Marius Strom | Always carry a short length of fibre-optic cable. Professional Geek | If you get lost, then you can drop it on the System/Network Admin | ground, wait 10 minutes, and ask the backhoe http://www.marius.org/ | operator how to get back to civilization. \-------------| Alan Frame |---------------------->

1 0

Re: How about a game of chess? (was Re: Vulnerbilities of Interconnection)
by sgorman1＠gmu.edu 07 Sep '02

07 Sep '02

Actually I do not know how to play chess maybe *Risk*, but your point is well taken. The intent is not provide a public recipe for taking down the Internet, that would be the opposite goal of the research to begin with. Regardless it is difficult line to tread and it is best to err on the side of caution. As for sampling biases - that is why it is only anecdotal evidence and the need for it to be questioned. Reports of Vinny accidently announcing his router as AS701 do not make it to the media very often. That aside the suggestion of how to model the Internet are very useful and the closer these models can get to operational reality the better. The intent being methodology not revealing data. Waites' approach is a good first step, but what next. Also if you know capacties how do you model a cascading effect that encompasses intra- network and inter-network traffic flows. Also it might be easier to calculate transition probabilities by summing across the rows of the adjaceny matrix then dividing the row components by the sum. ----- Original Message ----- From: Sean Donelan <sean(a)donelan.com> Date: Friday, September 6, 2002 12:52 pm Subject: How about a game of chess? (was Re: Vulnerbilities of Interconnection) > > On Thu, 5 Sep 2002 sgorman1(a)gmu.edu wrote: > > Is there a general consensus that cyber/internal attacks are more > > effective/dangerous than physical attacks. Anecdotally it seems the > > largest Internet downages have been from physical cuts or failures. > > I think you have a sampling bias problem. > > The "biggest" national/international network disruptions have > generallybeen the result of operator error or software error. Its > not always easy > to tell the difference. It may be better for carrier PR spin > control to > blame a software/router/switch vendor. > > Until recently physical disruptions have been due to causes which > don'teffect the stock price, carriers were more willing to talk > about them. > Carriers usually don't fire people due to backhoes, hurricanes, > floods, or > train derailments. > > What does this say about the effect of an external or internal > cyber-attack? > > Not much. Naturally occuring physical and procedural disruptions have > different properties than a directed attack. Not the least is > hurricanesand trains don't read NANOG, and generally don't alter > their behavior > based on the "recommendations" posted. > > Wouldn't you prefer a good game of chess? > > >

3 3

Re: Vulnerbilities of Interconnection
by sgorman1＠gmu.edu 06 Sep '02

06 Sep '02

Quite a few researchers have looked at the topology of AS interconnection. They have found that AS connectivity follows a power law - i.e. the vast majority have a few connections while a small minority has the majority of connections. Same as an earthquake - most are small and not noticable but a few are huge, smash a boulder and you get the same thing. Lots of dynamic networks follow this topology. The upside is that they are incredibly robust to random failures but very susceptible to targeted failures. For details see: http://www.physicsweb.org/article/world/14/7/09 ----- Original Message ----- From: Jared Mauch <jared(a)puck.Nether.net> Date: Friday, September 6, 2002 2:20 pm Subject: Re: Vulnerbilities of Interconnection > > On Fri, Sep 06, 2002 at 01:55:40PM -0400, batz wrote: > > On Fri, 6 Sep 2002, Pawlukiewicz Jane wrote: > > :would be difficult to reach. I'd have to run a model to be > sure, but > > :every one of the major seven have rerouting methodologies that > would> :recover from the loss. And I don't think they exclusively > peer at > > > > ASN's to "fail", then see who is still connected, but we are > > still dealing with connectivity relatve to us and our peers, > > even 5+ AS-hops away. > > > > I would imagine this is one of the tasks CAIDA.org is probably > > working on, as it seems to fall within their mission. > > Coming up with the as interconnection data is actaully fairly > easy if you parse route-views data. This obviously doesn't cover > every possible interconnection that exists but it does provide > a large swath of data to review for the interconnection > postulation. > > Looking at that data, (this is an old snapshot) the top ten > networks are: (in #10->#1 order) > > conn ASN > ----+---- > 161 3356 > 229 1 > 242 2914 > 248 209 > 274 6461 > 277 3561 > 295 3549 > 328 7018 > 484 701 > 493 1239 > > - Jared > > -- > Jared Mauch | pgp key available via finger from jared(a)puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are > only mine. > >

1 0