- Test - lists.nanog.org

Re: SMURF amplifier block list
by barton＠cent.net 12 Apr '98

12 Apr '98

> The following networks and masks are banned from our network at the core due > to being smurf amplifiers. The earlier suggestion to use the vixie blackhole system was rebuffed because the volunteers are just that, and already overworked. But re-using the existing infrastructure with suitable controls and a modest amount of cooperation and agreement has enormous potential. Using communities should be the key to safely adding different hit-lists to AS-7777 feeds. If current recipients of AS-7777 feeds could all simply add tests for specific communities to the existing route-maps being used to implement the black-holing, many different filters with even radically different policies can coexist on the same feed and each site can select which lists it chooses to use. The vixie folks could take additional feeds from selected 3rd parties and suitably tag these with the necessary communities, and yet not have to actively maintain the additional lists themselves. Paul's original list could be 7777:1, and perhaps the unsassigned address blocks should be 7777:2. Karl's list could be 7777:3 Problem areas would be when the same network is on several different hit-lists and needs the communities of each, and the fact that I believe the version of GATED Paul & Co. is running does not support communities. A simplifying rule might be that if a network were already on Pauls list(s) and tagged with 7777:1 or even combinations of communities Paul maintained, it simply would not be propagated with the addition 7777:3 community or whatever used for Karl's list. If it dropped off Paul's list(s), Karl's feed tagged 7777:3 would then be used. Perhaps the newer version of gated Paul hadn't yet installed a while ago solves all this, or perhaps someone has an idle cisco to loan/give Paul that could enable using communities with low impact on the volunteers. I wonder how many of the current recipients can handle adding a community list and then a match statement into their current black-hole route-map so it only does the current function despite additional lists being added, and if any remaining recipients unable or unwilling to deal with communities would mind using the additional filtering. Subject to the current legal agreements Paul demands, perhaps Karl could take Paul's current feed, the list of folks already signed up and authorised for the feed but that want MORE lists tagged with communities, and simply redistribute to them with his own additions suitably tagged. I don't know if they have changed, but the early AS-7777 instructions emphasised using the IP address of *THE* port facing towards Paul's machine. This is not necessary for this multi-hop application and may be difficult in a multi-homed world in any case. A loopback works well.

1 0

Cisco 'rsh' attacks?
by Louis Destree 12 Apr '98

12 Apr '98

Greetings, Over the past few days, my Cisco logs have shown several attemps of folks trying to rsh into my core routers. These attempts seem to happen within a very brief period of time, and so far there have been less than 8 attempts per 'attack' as if run by some sort of script. Below is the output from the latest attempt. You can see there were 4 attempts in 2 seconds. I'm a pretty fast typist, but I don't think I could pull that off by hand. Is this the 'next thing' we get to scramble about? Anyone else having these? Are there any Cisco router related security holes relating to rsh that these folks are trying to abuse? Thanks, Louis -- Louis A. Destree Senior Network Engineer FlashNet Communications destree(a)flash.net Apr 11 20:13:49 wormhole.flash.net 2279: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from 204.167.245.140 Apr 11 20:13:49 wormhole.flash.net 2280: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from 204.167.245.140 Apr 11 20:13:50 wormhole.flash.net 2281: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from 204.167.245.140 Apr 11 20:13:50 wormhole.flash.net 2282: %RCMD-4-RSHPORTATTEMPT: Attempted to connect to RSHELL from 204.167.245.140

2 1

RE: AS8584 taking over the internet
by Goldstein_William＠bns.att.com 11 Apr '98

11 Apr '98

PSINet recently announced free private peering for any ISP buying transit. How might this affect the frequency of AS8584-type problems? Bill Goldstein Senior Internet Specialist AT&T wgoldstein(a)att.com TEL:(412)642-7288 ---------- From: jprovo Sent: Thursday, April 09, 1998 10:44 PM To: nanog Cc: jprovo Subject: Re: AS8584 taking over the internet Received: from speedy1.bns.att.com (speedy1.bns.att.com [135.177.97.230]) by pawayn01.bns.att.com (8.8.6/1.3) with ESMTP id WAA13155 for <Goldstein_William/bcs_pawayn01(a)pawayn01.bns.att.com>; Thu, 9 Apr 1998 22:53:16 -0400 (EDT) Received: from kcig1.att.att.com (kcig1.att.att.com [135.38.78.194]) by speedy1.bns.att.com (8.7.3/2.5) with ESMTP id VAA18513 for <goldstein_william(a)bns.att.com>; Thu, 9 Apr 1998 21:54:41 -0500 (EST) Received: (from nuucp@localhost) by kcig1.att.att.com (AT&T/GW-1.0) id VAA14235; Thu, 9 Apr 1998 21:53:11 -0500 (CDT) >Received: by kcgw1.att.com; Thu Apr 9 21:53 CDT 1998 Received: by kcgw1.att.com; Thu Apr 9 21:53 CDT 1998 Received: from localhost (daemon@localhost) by merit.edu (8.8.7/8.8.5) with SMTP id WAA26613; Thu, 9 Apr 1998 22:46:55 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Thu, 9 Apr 1998 22:44:57 -0400 Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id WAA26537 for nanog-outgoing; Thu, 9 Apr 1998 22:44:56 -0400 (EDT) Received: from strato-fe0.ultra.net (strato-fe0.ultra.net [146.115.8.190]) by merit.edu (8.8.7/8.8.5) with ESMTP id WAA26533 for <nanog(a)merit.org>; Thu, 9 Apr 1998 22:44:52 -0400 (EDT) Received: from noc.ultra.net (noc.ultra.net [199.232.56.9]) by strato-fe0.ultra.net (8.8.8/ult.n14767) with ESMTP id WAA07955 for <nanog(a)merit.org>; Thu, 9 Apr 1998 22:44:51 -0400 (EDT) Received: (from jprovo@localhost) by noc.ultra.net (8.8.5/8.6.9/0.2jzp) id WAA12336 for nanog(a)merit.org; Thu, 9 Apr 1998 22:44:50 -0400 (EDT) Date: Thu, 9 Apr 1998 22:44:50 -0400 (EDT) From: Joe Provo - Network Architect <jprovo(a)ultra.net> Message-Id: <199804100244.WAA12336(a)noc.ultra.net> To: nanog(a)merit.org Subject: Re: AS8584 taking over the internet Sender: owner-nanog(a)merit.edu Content-Type: text -------------------------------------------------- [snip] > I believe that the implication was that: 1) they're not directly > connected to any of the major _US_ backbones, and 2) they're on the > other end of a fairly thin hose. > > And they can _still_ hose things this badly. > > This speaks not well of the architecture involved. No, no, it speaks _well_ for the architecture - equal opportunity hosage! There is no backone-hasage cabale; all that enter into bgp relationships can have a shot at hurting the net... ObContent: - yes, filters are Good. customers, especially if new to complicated things, should have both as-path and prefix filters placed against them. the questions to ask oneself regarding peers is "how clueful are they, really? and do their procedures allow only these clueful into the boxes? am I willing to tie my performance/reliability/ reputation to theirs in this intimate a fashion? are my bosses willing to do so? " People like to think in terms of the first question, not the last two. - yes, the IRR is good (and yes, their PGP implementation works); giving third parties the ability to verify your organization's "routing intent" cannot be construed as bad -- the data is publicly visible. there's nothing to hide. - yes, filtering doesn't mean not pushing IRR (or other forms of distributed data) on folks. IRR (or ...) doesn't mean not trying to more closely tie authentication/verification vs realtime; present tools are config-only, which aren't dynamic enough for the real net. joe -30-

2 1

Mae-west problems
by Wilson Chu 10 Apr '98

10 Apr '98

Hello, Currently the Mae-west fddi ring is experiencing hits which are causing many problems at and around mae-west. We are tracking MFS ticket number 202934. noc(a)above.net

1 0

Sprint ISC Number? - Not for Randy
by Jay Stewart 10 Apr '98

10 Apr '98

You can delete this one Randy, My Question? What happened to the Sprint ISC, calling their number: 800 232 6895, gets only the "sprint voice mail" system. I used to be able to reach the ISC direct this way, does anyone know a current working number? Jay Stewart Vice President Olympia Networking Services - "Premier Internet Access" Phone (360) 753.3636 Fax (360) 357.6160 http://www.olywa.net/

2 1

Re: AS8584 taking over the internet
by Hank Nussbacher 10 Apr '98

10 Apr '98

At 07:25 PM 4/9/98 -0400, Scott Huddle wrote: >I have and remain unconvinced and or confused ;) The proposal allows >an operator to verify a valid origin AS for a given prefix (i.e. "config" >sorry if I'm being loose with the word) by using the DNS system with >"bgp.in-addr" extensions. I'm not sure which part of the random >route announcement problem that dnssec solves in this case? It can >help with the "are they indeed are who they say they are", but it >doesn't solve the "are they supposed to be doing what they said that >they're doing" case. Has anyone benchmarked how long it will take to resolve 50,000 bgp.in-addr's after a line hiccup or a "clear ip bgp *"? -Hank > >And you didn't address my paranoia about not trusting the DNS ;) > >-scott > >> you may wish to read the draft. it did not suggest using the dns to >> configure. and you may also want to look into dnssec. >> >> randy >> > >

3 2

Reciprocal shell accounts for network testing
by Mike Levy 10 Apr '98

10 Apr '98

Hi, We're looking for ISP's in diverse areas and on diverse backbones (we are on MCI and UUNET) who would be interested in trading shell accounts to be used for purpose of network diagnosis (trace, ping, etc.) Thanks, ------------------------------------- Mike Levy (206)217-0158 Cortland Electronics Corp mike(a)cortland.com Seattle, WA 98109

3 2

oh, for goodness' sake.
by Danny O'Brien 10 Apr '98

10 Apr '98

% whois ripe.net Reseaux IP Europeens - Network Coordinati on Centre (RIPE-DOM) Singel 258 Amsterdam, NH 1016 AB NL Domain Name: RIPE.NET Domain Status: On Hold <<<<<<------ ...

14 18

The Cidr Report
by Tony Bates 10 Apr '98

10 Apr '98

This is an auto-generated mail on Fri Apr 10 12:00:00 PDT 1998 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. 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 xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 10Apr98 0) General Status Table History ------------- Date Prefixes 030498 50479 040498 50660 050498 50519 060498 50595 070498 50748 080498 50724 090498 50529 100498 50729 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 3448 Number of ASes announcing only one prefix: 1614 (846 cidr, 768 classful) Largest number of cidr routes: 412 announced by AS3561 Largest number of classful routes: 1036 announced by AS701 1) Gains by aggregating at the origin AS level --- 10Apr98 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS4293 437 213 224 51.3% IMCI AS2493 553 338 215 38.9% iSTAR Internet, Inc. AS816 672 461 211 31.4% UUNET Canada (ASN-UUNETCA-AS4) AS3602 467 302 165 35.3% Sprint Canada Inc. AS174 774 617 157 20.3% Performance Systems International AS701 1036 881 155 15.0% Alternet AS3749 218 63 155 71.1% TECNET AS8505 154 34 120 77.9% Middle East Technical University AS2939 186 77 109 58.6% SCAROLINA-AS AS2048 162 90 72 44.4% LaNet AS11003 126 56 70 55.6% UNKNOWN AS5668 116 47 69 59.5% Century Telephone Inc. AS3221 107 39 68 63.6% EENet Autonomous System AS271 112 53 59 52.7% BCnet Backbone AS3804 199 141 58 29.1% Bell Solutions AS10928 99 41 58 58.6% UNKNOWN AS549 209 159 50 23.9% ONet Backbone AS1239 538 488 50 9.3% SprintLink Backbone AS1221 272 223 49 18.0% AARNET-AS AS72 84 36 48 57.1% Schlumberger Information Network AS4755 85 37 48 56.5% Videsh Sanchar Nigam Ltd. India AS6392 79 32 47 59.5% MidWest Communications, Inc. AS7046 154 108 46 29.9% UUNET-CUSTOMER AS4763 122 76 46 37.7% Telstra New Zealand AS1982 161 118 43 26.7% Northwest Nexus, Inc. AS4740 351 309 42 12.0% ASN-OZEMAIL (Ozemail Pty Ltd) AS852 157 117 40 25.5% AGT Advance Communication AS684 92 52 40 43.5% Manitoba Regional Network Backbon AS4200 134 95 39 29.1% AGIS (Apex Global Information Ser AS3493 164 126 38 23.2% INTERLINK 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

RE: Sprint ISC Number? - Not for Randy
by Jay Stewart 10 Apr '98

10 Apr '98

> I have had success as recently as 2 weeks ago calling that very number... > just use option 3 once the voices begin speaking... Thanks, it was a temporary problem, they had a power outage in reston and their pbx went down temporarily. Jay Stewart Vice President Olympia Networking Services - "Premier Internet Access" Phone (360) 753.3636 Fax (360) 357.6160 http://www.olywa.net/

1 0