- Test - lists.nanog.org

Network Reliability Engineering
by Pete Kruckenberg 18 May '02

18 May '02

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.

2 1

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

18 May '02

On Sat, May 18, 2002 at 04:10:53AM +0000, dr(a)kyx.net said: [snipage throughout] > > up your network, or risk being blackholed." If no response is received, and > > scans continue, blackhole. Simple as that, and puts responsibility back on > > the shoulders of the offending network. > > Oh but there _WILL_ be disputes. Even with spam there is considerable enough > gray area that I find solutions like the RBL distasteful, and the questions > surrounding what is and isn't a portscan will be much, much, worse. The > simple fact is that there are no good definitions of a portscan. I say this > because I work on developing IDSes and portscan detectors amongst other > things. there doesn't have to be a good definition. If network B receives what they consider to be a scan from network A, and network A does not reply to emails requesting explanation, network B can blackhole. Heck, network B can blackhole whoever they want for any or no reason. It's _their_ network. An agreed-upon definition of what constitutes a portscan is not required, by any means. > Port agile trojan scans won't be caught by any of your "portscan" detectors. > Your "portscan" detection will likely only catch admins who have misfired with > nmap, or kids playing, or legitimate network applications that have high In which case, a simple email to the network operator in question should clear up the confusion early in the game, with no harm done. If people can't be bothered to properly manage their contact information for netblocks, that's nobody's fault but their own. > Bitching about portscans is misdirected and stupid, while lacking a good > definition again, definition is not necessary. I think many network operators are simply tired of dealing with crap from other networks and operators that can't be bothered to clean things up. Consider it fair warning. As long as network operators are responsible for their networks, they can do as they please, including denying contact from arbitrary other networks for any or no reason. > of what a "portscan" is (with all deference to the popularity of nmap :-). > If you think you have some information there you do not want to leak, put in > measures to stop this, but route blocking based on contravention of some > dubious "portscan" regulation is like trying to swat flies with atomic bombs, > you may get the fly, but arguably the cure is worse than the disease. Maybe so, but that decision still belongs to the individual network operators. > > There's no point to what you have just said. When you find a machine has > > been rooted, unplug it from the network and commence forensic analysis. > > Knowingly allowing it to attack other networks is foolhardy at best. > > There we agree to disagree. Blindly shutting down attackers without any ID or > attempt to discern motive seems unwise. But your policies may differ. :-) This is what forensic analysis is for. You cut off the machine and then analyze it. Motive is generally pretty obvious - Yet Another Zombie for use in DDoS, an IRC shell, or a jumping point for further network penetrations. *yawn* The motives are mind-numbingly common at this point. If proper logging is in place, you won't lose any information by unplugging the machine as opposed to allowing the intruders to continue to do whatever they're doing. > I work with several groups that attempt to study intrusions and intruder > techniques. If the villains have broached your defenses and you simply > patch up the defenses with the same construct that was broached initially, > blindly hoping they'll go away... well... further more, if you don't > even look at the villains to identify their motive, strength and number, > simply pretending they aren't there... then you aren't being a good > defender. Forensic analysis after an intrusion does not require continuing to allow the intruders to do as they please. For honeypots, of course, this is a different matter. > Their loss if true. I pity the fool that cannot laugh. Just because I have a sense of humor, does not mean I find it amusing when people penetrate, or attempt to penetrate, my network. > > Neither are network operators whose networks are constantly under attack. > > This kind of thing loses its novelty the first time one of your machines is > > rooted and has to be wiped and rebuilt. > > > > Whether or not it's amusing to you is immaterial. If the person being > > scanned does not find it so, scans should cease, period. > > By all means if you are under attack, filter and protect yourself. > > However a "portscan" is not an attack. Precursor to an attack, certainly. As you mentioned earlier, forewarned is forearmed. If I find myself being scanned, as a responsible network operator I will contact the operator of the block in question, and if things are not cleared up to my satisfaction, I will take proactive measures to protect myself from the attacks that are sure to come by whatever means seem appropriate and necessary to me. regards, -- Scott Francis darkuncle@ [home:] d a r k u n c l e . n e t Systems/Network Manager sfrancis@ [work:] t o n o s . c o m GPG public key 0xCB33CCA7 illum oportet crescere me autem minui

2 1

Multicast at broadcast exchanges
by Stephen Griffin 18 May '02

18 May '02

Hmm, I was thinking about the topic of multicast at broadcast exchanges, and had a weird thought. Presently, the various participants may have divergent peering relationships and routing preferences. Such that RPF choices for the same (s,g) can go back to different places. If I remember correctly, all PIM routers on the same broadcast domain will elect a designated router, to keep from sending the same traffic for the same group multiple times. If network A is preferring network B (via localpref, for example) and network C is preferring network D, such that A rpf's to B for prefix E and C rpf's to D for prefix E, how would this be resolved? What if A doesn't peer with D at all, and C doesn't peer with B? Wouldn't one of B and D send the traffic, such that the other isn't sending any, regardless of the policies of any of the networks involved? What if the elected DR isn't one of B or D? The only "workaround" I could see, would be if the multicast traffic were unicasted across the exchange (much like how things are at the atm peering points). However, this nulls out the benefit of having a multicast broadcast exchange.

3 2

The Cidr Report
by CIDR Report 18 May '02

18 May '02

This is an auto-generated mail on Fri May 17 23:00:00 PDT 2002 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 17May02 0) General Status Table History ------------- Date Prefixes 100402 108550 110402 108701 120502 109917 130502 109712 140502 109853 150502 109940 160502 109828 170502 109785 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 10.1.1.1/32 from AS(65302) *** Bogus 10.1.1.1/32 from AS(65303) AS Summary ---------- 1) Gains by aggregating at the origin AS level --- 17May02 --- For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Does anyone still offer DVMRP tunnels?
by Lyndon Nerenberg 17 May '02

17 May '02

Is there anyone out there still providing DVMRP multicast tunnels? Our network provider simply isn't interested in providing native multicast. If anyone close to Group Telecom (sorry, I don't have their AS handy at the moment) would be willing to establish a tunnel with us, please contact me directly. Thanks. --lyndon

2 1

Re: Arbor Networks DoS defense product
by Dan Hollis 17 May '02

17 May '02

On Thu, 16 May 2002, Dragos Ruiu wrote: > Some people are get all hyper and complain. Which is silly imho. > If you don't like it, stop your network from responding to it. Thats exactly what we plan to do with BGP blackholes and landmines. > Don't bitch and whine if your equipment is silly and leaks info. It's > not the world's problem to compensate for _your_ inferior network > architecture or shoddily designed network hardware. Then you shouldnt be whining about a BGP blackhole system. > Portscanning by no means proves "intent". Or should provoke hostile reaction. Blackholing isnt hostile its defensive. > But then again I'm of the radical opinion that if your host is compromised > it is your fault for not taking appropriate precautions on inbound filters or > gateways. The blackholing is the response to networks which cant be bothered to clean up their compromised hosts. Youre ranting against the wrong target im afraid. Please go back and read the thread from the beginning. > I can't help it if your host does funny things when I send them funny > packets.... :-) Why are you sending funny packets? -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

4 4

Re: Arbor Networks DoS defense product
by Dan Hollis 17 May '02

17 May '02

On Thu, 16 May 2002, Dragos Ruiu wrote: > But how do you plan to arbitrate disputes about what merits blackholing > and not on behalf of others? And what guidelines do you use to decide > on how to initiate black holing? (not critical here, just curious?) Thats the beauty here, one can provide multiple databases (eg rogue networks which refuse to shutdown their portscanners, proven spamhausen in bed with spammers, proven active attackers, etc.) and service providers can opt in as they like, and apply whatever policy to those routes that they like. > > Why are you sending funny packets? > Any number of reasons... like I have a compromised host > and I'm watching what it does before shutting it down... So you have a compromised host attacking sites, you know about it, and you're allowing it to continue. Whoops it just defaced a federal government site, and now it has your ip address all over it... I don't think i'd want to open myself to that kind of liability... When we catch compromised hosts, we cut their balls off instantly. > Or maybe the packets don't look funny to me :-). > Or perhaps the packets were so funny I thought I'd share. ;-) > Humor is often in the eye of the beholder :-). Military networks arent well known for their sense of humor, and neither are federal interest sites... -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

2 1

Re: Arbor Networks DoS defense product
by Dan Hollis 17 May '02

17 May '02

On Thu, 16 May 2002, Dragos Ruiu wrote: > But that said. Blackholing as a response for portscanning > is stupid. > If you are a small communications end-point it's dumb. > Just run portsentry for a while with auto-firewall rules > if you need convincing. > If you are a communications service provider providing > packet transit for others (even employees), it's hostile. What if you are portscanned repeatedly by a network and that network refuses to shut down their scanners even after being asked many times (eg, rogue chinese and korean networks) I think that you should leave network policy up to the service provider to decide. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

2 1

Re: Arbor Networks DoS defense product
by Dan Hollis 16 May '02

16 May '02

On Wed, 15 May 2002, Lyndon Nerenberg wrote: > I usually avoid blackhole subscription lists like this. They let > the attacker take out your legitimate peers by spoofing the source. If they can take out your legitimate peers by spoofing end to end TCP connections, then you have got some really enormous problems that need to be addressed. I don't think spoofing will be a problem for the landmines. Most attacks (99%?) are tcp. -Dan -- [-] Omae no subete no kichi wa ore no mono da. [-]

9 20

rbl for apnic ranges
by Sabri Berisha 16 May '02

16 May '02

Hi all, Recently there have been discussions on blackholing 211.* on mailboxes. Because I was sick and tired of the massive amount of spam (and non-responsive network admins) I decided to blackhole them too. Because 211.* also has a piece of .au in it, simply listing 211.0.0.0/8 was not an option for me. I decided to put up a list, based on ftp://ftp.apnic.net/pub/apnic/dbase/data/country-ipv4.lst which lists the allocations per country in the form of <countrycode>.rbl.cluecentral.net ie cn.rbl.cluecentral.net, and make it pubically available. You can check the list at http://www.cluecentral.net/rbl which is in the tinydns-data format and of course use it for black/whitelisting purposes. It is not yet updated automagically, I will write something for that soon. -- Sabri Berisha "I route, therefore you are" ~ my own opinions etc ~

2 2