April 1998 - Test - lists.nanog.org

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

RE: AS8584 taking over the internet
by Dave Van Allen 10 Apr '98

10 Apr '98

-----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Thursday, April 09, 1998 11:51 PM To: Dalvenjah FoxFire Cc: nanog(a)merit.org Subject: Re: AS8584 taking over the internet > IOW, if some terrorist group manages to get set up where they can announce > BGP, they can toy essentially with whatever they like, until people/their > upstream gets a clue and installs filters. -before we get too hysterical, it may be worth noting that to date the -problems have been caused by lack of clue, not lack of ethics, morals, -or empathy. not that this is reason less for caution, but it might -guide our reaction towards the actual, as opposed to imagined, problems. -randy Nevertheless, he is right. Best regards, David Van Allen - FASTNET(tm) / You Tools Corporation dave(a)fast.net (888)321-FAST(3278) http://www.fast.net FASTNET - Business and Personal Internet Solutions

3 2

Re: oh, for goodness' sake.
by Stephen Sprunk 10 Apr '98

10 Apr '98

Michael Dillon wrote: > > One of the stated uses of .INT is for international databases and that > seems to be the reason that the reverse DNS for IPv6 is under .INT rather > than .ARPA. Of course it may not be too late for IPv6 to be changes and > for all important infrastructure info to be moved to .ARPA. We could even > rationalize things somewhat, i.e. > > IN-ADDR.ARPA > IP6.ARPA > NET.ARPA for IP netblock whois info > ARIN.NET.ARPA | > RIPE.NET.ARPA |-queries to NET.ARPA will be redirected to one of these > APNIC.NET.ARPA | > RS.ARPA - route servers > IANA.ARPA - IANA databases such as MIBs, port assignments > Quoted from RFC 1032: "ARPA" is a temporary domain. It is by default appended to the names of hosts that have not yet joined a domain. When the system was begun in 1984, the names of all hosts in the Official DoD Internet Host Table maintained by the NIC were changed by adding of the label ".ARPA" in order to accelerate a transition to the domain-naming system. Another reason for the blanket name changes was to force hosts to become accustomed to using the new style names and to modify their network software, if necessary. This was done on a network-wide basis and was directed by DCA in DDN Management Bulletin No. 22. Hosts that fall into this domain will eventually move to other branches of the domain tree. IN-ADDR.ARPA. is an obvious exception (reasoning in RFC 973), but I think it's clear that the above info has no place being put in ARPA. My vote's for NIC.INT. I'm still searching for the correct RFC on INT rules to see if that's appropriate, however. Stephen -- Stephen Sprunk "Oops." Email: sprunk(a)paranet.com Sprint Paranet -Albert Einstein ICBM: 33.00151N 96.82326W

7 6

Re: AS8584 taking over the internet
by Tony Li 10 Apr '98

10 Apr '98

hank(a)ibm.net.il (Hank Nussbacher) writes: > 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 I think an important point is that the implementation need not authenticate a path before it can use it. The vast majority of paths will not generate authentication failures. This policy does allow the temporary propagation of bad information, but the system can heal itself quickly. In the meantime, it means that everyone else gets reasonable convergence time. Tony

1 0

Re: AS8584 taking over the internet
by philip bridge 10 Apr '98

10 Apr '98

Indeed, in a perfect world, a route server would be the solution. But what always beats me in these situations is that the upstreams of ASes where these problems occur don't seem to be prefix filtering. Given the complexity of interdomain routing configs, misconfigurations by less experienced operators are to be expected, and to a certain extent can be forgiven. But it is hard to tolerate the behaviour of (supposedly) clueful upstreams who don't protect themselves and the rest of the Internet by having prefix filters on their downstream customers. It seems that the current state of the IRR and the supporting tools are in general simply too complex for a lot of people to get to grips with ... which includes me - we build ours manually :-( Perhaps the DNS based origin authentication proposal would have more success. We can only hope. Phil At 13:53 08/04/98 -0400, Abha Ahuja wrote: > >Or maybe, use a route server! > >-abha ;) > > >On Wed, 8 Apr 1998, philip bridge wrote: > >> Seems like... >> >> http://www.academ.com/nanog/feb1998/origin.html >> >> ...is long overdue. >> >> Phil >> >> At 02:53 PM 4/7/98 -0400, Mr. Dana Hudes wrote: >> >It is such accidents that reinforce the notion of per-prefix >> >filtering. >> >Of course if one changes one's IRR/RIPE DB/RADB entries to >> >deliberately >> >announce the world there could still be a problem with >> >auto-generated >> >accept policy. The solution to *that* is quality assurance of the >> >database, an ongoing issue in RIPE DB WG at least. >> > >> >Even then how does one prevent someone coding 'ANY' for their >> >announce policy when they should not? In the old NFSNET days >> >human inspection of IRR entries assured quality but that's not >> >practical anymore at a central registry. >> > >> >sure, one has accept policy but other than excluding RFC1918 and >> >your own address space and default you have no practical choice >> >but to reference the other guy's aut-num object and the >> >associated routes. >> > >> > >> >Dana Hudes >> >Graphnet >> > >> > >> >Bernhard Kroenung wrote: >> >> >> >> At the Moment AS4000 / AS8584 is announcing the whole internet :-( >> >> >> >> For programming the cuise-missiles or SS20's - here is the data : >> >> >> >> aut-num: AS8584 >> >> descr: Barak AS >> >> as-in: from AS4000 10 accept ANY >> >> as-in: from AS5585 100 accept ANY >> >> as-out: to AS4000 announce AS8584 >> >> as-out: to AS5585 announce AS8584 >> >> default: AS4000 10 >> >> admin-c: AS261-RIPE >> >> tech-c: AS261-RIPE >> >> mnt-by: AS8584-MNT >> >> changed: ashor(a)barakitc.co.il 971126 >> >> source: RIPE >> >> >> >> person: Amir Shor >> >> address: Barak I.T.C. >> >> address: 15 Ha-Melacaha St. >> >> address: Rosh Ha-Ayin 48091, Israel >> >> phone: +972 3 9001082 >> >> fax-no: +972 3 9001090 >> >> e-mail: ashor(a)barakitc.co.il >> >> nic-hdl: AS261-RIPE >> >> changed: ashor(a)barakitc.co.il 971112 >> >> source: RIPE >> >> >> >> Ciao >> >> Bernhard >> >> -- >> >> Bernhard Kroenung, Bahnhofstr 8, 36157 Ebersburg/Rhoen, Germany +49 6656 >> 910101 >> >> @work : bernhard(a)kroenung.de Work: +49 661 >> 9011777 >> >> @home : horke(a)Rhoen.De @school : >> Bernhard.Kroenung(a)Informatik.FH-Fulda.De >> > >> > >> >> >> >> ______________________________________________________________ >> Philip Bridge >> ++41 31 688 8262 bridge(a)ip-plus.net www.ip-plus.ch >> PGP: DE78 06B7 ACDB CB56 CE88 6165 A73F B703 >> > >__________________________________________________________________________ >-------------------------------------------------------------------------- >abha ahuja ahuja(a)merit.edu >Merit Network, Inc. 734.764.0294 > > > ============================================================== Philip Bridge Swisscom Data/Multimedia Voice: +41 31 688 8262 Private: +41 31 911 1694 Fax: +41 31 688 8151 mail: bridge(a)ip-plus.net PGP:www-swiss.ai.mit.edu/~bal/pks-commands-beta.html(447485ED) ==============================================================

6 6

Re: AS8584 taking over the internet
by Joe Provo - Network Architect 09 Apr '98

09 Apr '98

[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-

1 0