- Test - lists.nanog.org

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 10 Apr '98

10 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

Re: AS8584 taking over the internet
by Tim Salo 10 Apr '98

10 Apr '98

> Date: Thu, 9 Apr 1998 18:58:33 -0400 > From: Scott Huddle <huddle(a)mci.net> > Subject: Re: AS8584 taking over the internet > [...] > ... and in fact have a health > dose of paranoia about giving routing control (i.e. the availability the > service) to a service that can be manipulated by a single person > See http://www.news.com/News/Item/0,4,18849,00.html Perhaps, you meant: http://www.news.com/News/Item/0,4,12382,00.html

1 0

Re: AS8584 taking over the internet
by Sean M. Doran 09 Apr '98

09 Apr '98

Scott, the DNS is in this use simply a distributed database, that with DNSSEC seems reasonably secure. The heirarchy in the DNS-protocol-using distributed database used for IP address to origin AS mapping need not branch off the DNS-protocol- using distributed database used for domain name->address mapping and the like, which we normally just call the DNS. Remember moreover that what one is doing is simply grabbing entries from a distributed database which can be used to synthesize a table which would be consulted by BGP border routers in determining whether to accept or reject a route. One could conceivably have a single zone which could be snarfed from well known places using the latest in authenticated file transfers. However, decentralization of work already happens in the transfer of IP address blocks from regional registries to local registries to more local registries still, and it seems to make sense to simultaneously distribute the work of maintaining the address-block-to-originating-AS map as well. Therefore, what one wants is a "root" which one can find at well known places and can retreive using the latest in authenticated file transfers, and which allows one to follow an authenticated tree of delegated zones in building a local table of mappings. Whether this "root" is really a parallel "." or something else seems academic; one will require the same mechanism to retrieve a cryptographically-authenticated copy of the "root" from well known sources that can prove, cryptographically, who they are. The solution proposed is incomplete, certainly, but not because of possible political instabilities in what we call the DNS. I am not sure why you raise the issue of trusting IP registries to delegate authority for any given subzone along with the addresses themselves. This doesn't seem to make sense. Perhaps you could explain this concern a little more concretely? Sean.

1 0

Re: AS8584 taking over the internet
by Scott Huddle 09 Apr '98

09 Apr '98

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

2 1

Re: AS8584 taking over the internet
by Scott Huddle 09 Apr '98

09 Apr '98

> > Harping just a little more, unless the IP registries take the lead and push > their hierarchical allocation tree data out and ISPs pick it up and do useful > filtering with it, this problem will continue to occur regularly. Talk to your > registry and your router vendors to start getting the pieces in place to get a > global solution. I like the idea of somehow using registry data to help build configs, but confess to not liking the idea of using DNS to do so (the IDR proposal), mostly because I don't see trusting the IP registries to do this, and in fact have a health dose of paranoia about giving routing control (i.e. the availability the service) to a service that can be manipulated by a single person See http://www.news.com/News/Item/0,4,18849,00.html -scott

3 2

Re: AS8584 taking over the internet
by Jerry Scharf 09 Apr '98

09 Apr '98

Wait, the horse is dead and partially dismembered, but we're still whacking away. Hopefully this will target the blows at the parts that are still not jelly. 1) Filtering is a good idea. If everyone did it, it would be a great idea. Getting everyone in the Internet to do anything is impossible, so maybe it's not the most useful solution. 2) there are groups working on ways to do announcement AS verification. there are two efforts in the IETF right now, in the RPS and IDR working groups. These will allow people to do distant source verification. These solutions look far more promising to me that saying everyone should filter. There is work beyond either of these proposals that gets harder, but both of these look to do a big chunk of problem for accidents like this. Harping just a little more, unless the IP registries take the lead and push their hierarchical allocation tree data out and ISPs pick it up and do useful filtering with it, this problem will continue to occur regularly. Talk to your registry and your router vendors to start getting the pieces in place to get a global solution. I think it is safe to say that more mail on NANOG saying people should neighbor filter will not solve this problem. Lets work on things that will. jerry

2 1