From owner-Big-Internet@munnari.OZ.AU Sat Apr 12 18:16:09 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id IA21327; Sat, 12 Apr 1997 18:16:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA21904; Sat, 12 Apr 1997 18:15:13 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA21887; Sat, 12 Apr 1997 18:06:44 +1000 From: Global1717@aol.com Received: from emout16.mx.aol.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id IA21566; Sat, 12 Apr 1997 18:06:40 +1000 (from Global1717@aol.com) Received: (from root@localhost) by emout16.mail.aol.com (8.7.6/8.7.3/AOL-2.0.0) id EAA28314 for big-internet@munnari.oz.au; Sat, 12 Apr 1997 04:06:38 -0400 (EDT) Date: Sat, 12 Apr 1997 04:06:38 -0400 (EDT) Message-Id: <970412040638_-1803964014@emout16.mail.aol.com> To: big-internet@munnari.OZ.AU Subject: new email list Precedence: bulk send me more info on new fresh email lists thanx Global1717@AOL.com From owner-Big-Internet@munnari.OZ.AU Sat Apr 26 19:57:47 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA27713; Sat, 26 Apr 1997 19:57:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA09071; Sat, 26 Apr 1997 19:54:58 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA09065; Sat, 26 Apr 1997 19:44:14 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA22703; Sat, 26 Apr 1997 19:44:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19156; Sat, 26 Apr 97 05:44:04 -0400 Date: Sat, 26 Apr 97 05:44:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704260944.AA19156@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, ietf@cnri.reston.va.us Subject: Re: Autonomous System Sanity Protocol Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li > We need to move to a routing architecture where maps are distributed, > *not* routing tables. Exactly how does this prevent the exchange of bad information? Well, a full-scale explanation is a major tome (we can explore that on Big-I in more detail if you want), but *briefly*, the idea is that you can i) prevent lots of kinds of bad information, and ii) deal much better with the kinds you can't stop. For instance, use of public key cryptography can prevent anyone else from originating bad information about connectivity inside or to X - their map updates will not be correctly signed with X's private key. Only "auhorized" agents of topological entity X (i.e. those allowed to distribute maps or abstractions of X, outside X) have the key to sign map data about X. (X and Y can still cooperate to lie about having connectivity between them, when in fact they do not, but you can (albeit with some work) detect that and work around it, if you have not only a map distribution system, but explicit routing too.) It can certainly prevent all unilateral bad information, i.e. based on someone incorrectly configuring their routers (or software/hardware bugs). Noel From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 02:36:26 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id QA05038; Sun, 27 Apr 1997 02:36:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA09530; Sun, 27 Apr 1997 02:35:06 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA09513; Sun, 27 Apr 1997 02:19:27 +1000 Received: from mail-relay.EU.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id QA06981; Sun, 27 Apr 1997 02:19:23 +1000 (from bilse@EU.net) Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by mail-relay.EU.net (8.8.5/8.6.10) with SMTP id SAA22105; Sat, 26 Apr 1997 18:19:06 +0200 (MET DST) Received: by jotun.EU.net id AA05241 (5.67a/IDA-1.5); Sat, 26 Apr 1997 18:19:05 +0200 Message-Id: <199704261619.AA05241@jotun.EU.net> From: Per Gregers Bilse Date: Sat, 26 Apr 1997 18:19:05 +0200 In-Reply-To: <9704260944.AA19156@ginger.lcs.mit.edu> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Noel Chiappa Subject: Re: Autonomous System Sanity Protocol Cc: big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US Precedence: bulk On Apr 26, 5:44, Noel Chiappa wrote: >[...] > It can certainly prevent all unilateral bad information, i.e. based on someone > incorrectly configuring their routers (or software/hardware bugs). We have the "technology" to do this today. It is called "customer prefix filtering", but it doesn't happen because for one reason or another a number of operators are unable to implement it. My point is that the current paradigm (which is for real, whether we like it or not) has a gaping hole in it: the infamous EGP->IGP->EGP redistribution chain, where information which is vital for consistent behaviour can and will be lost. I'm looking for a way to plug that hole. -- ------ ___ --- Per G. Bilse, Director Network Eng & Ops ----- / / / __ ___ _/_ ---- EUnet Communications Services B.V. ---- /--- / / / / /__/ / ----- Singel 540, 1017 AZ Amsterdam, NL --- /___ /__/ / / /__ / ------ tel: +31 20 5305333, fax: +31 20 6224657 --- ------- 24hr emergency number: +31 20 421 0865 --- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at EU.net From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 03:56:22 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA07226; Sun, 27 Apr 1997 03:56:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA09643; Sun, 27 Apr 1997 03:55:06 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA09626; Sun, 27 Apr 1997 03:50:32 +1000 Received: from trix.cisco.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA09594; Sun, 27 Apr 1997 03:50:29 +1000 (from roque@cisco.com) Received: (roque@localhost) by trix.cisco.com (8.6.12/8.6.5) id KAA21019; Sat, 26 Apr 1997 10:50:21 -0700 Date: Sat, 26 Apr 1997 10:50:21 -0700 Message-Id: <199704261750.KAA21019@trix.cisco.com> From: Pedro Marques To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, ietf@cnri.reston.va.us Subject: Re: Autonomous System Sanity Protocol In-Reply-To: <9704260944.AA19156@ginger.lcs.mit.edu> References: <9704260944.AA19156@ginger.lcs.mit.edu> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Precedence: bulk >>>>> "Noel" == Noel Chiappa writes: Noel> From: Tony Li >> We need to move to a routing architecture where maps are >> distributed, *not* routing tables. Noel> Exactly how does this prevent the exchange of bad Noel> information? Noel> Well, a full-scale explanation is a major tome (we can Noel> explore that on Big-I in more detail if you want), but Noel> *briefly*, the idea is that you can i) prevent lots of kinds Noel> of bad information, and ii) deal much better with the kinds Noel> you can't stop. Noel> For instance, use of public key cryptography can prevent Noel> anyone else from originating bad information about Noel> connectivity inside or to X - their map updates will not be Noel> correctly signed with X's private key. Only "auhorized" Noel> agents of topological entity X (i.e. those allowed to Noel> distribute maps or abstractions of X, outside X) have the Noel> key to sign map data about X. s/map/BGP route/g ... and everything you said still holds. ./Pedro. From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 03:59:03 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA05061; Sun, 27 Apr 1997 03:59:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA09663; Sun, 27 Apr 1997 03:57:58 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA09623; Sun, 27 Apr 1997 03:43:04 +1000 Received: from red.jnx.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA06694; Sun, 27 Apr 1997 03:43:01 +1000 (from tli@jnx.com) Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.6]) by red.jnx.com (8.8.5/8.8.5) with ESMTP id KAA19026; Sat, 26 Apr 1997 10:42:49 -0700 (PDT) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id KAA29850; Sat, 26 Apr 1997 10:42:37 -0700 (PDT) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol References: <9704260944.AA19156@ginger.lcs.mit.edu> From: Tony Li Date: 26 Apr 1997 10:42:37 -0700 In-Reply-To: jnc@ginger.lcs.mit.edu's message of 26 Apr 97 09:44:04 GMT Message-Id: <82hggty92q.fsf@chimp.jnx.com> Lines: 45 X-Mailer: Gnus v5.3/Emacs 19.34 Precedence: bulk jnc@ginger.lcs.mit.edu (Noel Chiappa) writes: > > We need to move to a routing architecture where maps are distributed, > > *not* routing tables. > > Exactly how does this prevent the exchange of bad information? > > Well, a full-scale explanation is a major tome (we can explore that on Big-I > in more detail if you want), but *briefly*, the idea is that you can i) > prevent lots of kinds of bad information, and ii) deal much better with > the kinds you can't stop. > > For instance, use of public key cryptography can prevent anyone else from > originating bad information about connectivity inside or to X - their map > updates will not be correctly signed with X's private key. Only "auhorized" > agents of topological entity X (i.e. those allowed to distribute maps or > abstractions of X, outside X) have the key to sign map data about X. This would seem to be a red herring. If you posit the use of PKC for map distribution it seems only fair to posit its use in a prefix distribution system. And this also presumes the existence of a mechanism to derive prefix authority. This is thought to be non-trivial. > It can certainly prevent all unilateral bad information, i.e. based on > someone incorrectly configuring their routers (or software/hardware bugs). How? If we consider a typical link state protocol today (as perhaps a degenerate example of map distribution), it's trivial to inject bad information and have it propagate throughout the immediate map. Further, unless there is intelligence (aka filtering) between the local map and the global map, it will tend to propagate globally. I would tend to agree with you more if we had a system where we had stronger abstraction boundaries and fewer abstraction violations. It would leave us with less need to propagate information from the immediate map to the global map because we'd simply be propagating the static abstraction information. Unfortunately, our inability to do this is more a function of the address allocation than the information distribution mechanism. As an example, consider a utopian world where we had an address assignment which maintained such strong abstraction boundaries. Using BGP4, one simply does proxy aggregation... Tony From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 04:36:11 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA05244; Sun, 27 Apr 1997 04:36:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA09743; Sun, 27 Apr 1997 04:35:07 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA09734; Sun, 27 Apr 1997 04:29:47 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA04656; Sun, 27 Apr 1997 04:29:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20681; Sat, 26 Apr 97 14:29:41 -0400 Date: Sat, 26 Apr 97 14:29:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704261829.AA20681@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, roque@cisco.com Subject: Re: Autonomous System Sanity Protocol Cc: big-internet@munnari.OZ.AU, ietf@cnri.reston.va.us, jnc@ginger.lcs.mit.edu Precedence: bulk From: Pedro Marques > use of public key cryptography can prevent anyone else from originating > bad information about connectivity inside or to X s/map/BGP route/g ... and everything you said still holds. No. There is a fundamental difference. If I'm X, I know, *authoritatively and definitively*, who is attached to me. I can then originate this information and sign it, in the form of map element information ("Hi, I'm X, and I'm attached to A, B and C, and here's the seal for that, encrypted with my private key".) You can use the concatentation of all such data (modulo, as I said, issues like people co-operating to lie about non-existent connections) to produce routing which is resistant to single-point failure and/or malice. However, in a destination vector system, such as BGP, X cannot know, authoritatively, the details of connectivity elsewhere. That means that Y can pass on to Z information about a route which Y has to X, and there is no way for X to sign *that* data, or even to verify that it is correct. (Extra detail, ignore if you don't care: Saying you can recursively sign the route doesn't help, I don't think - you can strip off later elements and work with a partial, and fully signed, route. In other words, if I get a route to X which is Z->Y->X, it *can't* be the case that when Z signed it, he only signed an indivisible composite - if so, how can you check that the Y->X portion is legitimate, and not something Z made up? You have to be able to check the Y->X component, and the X source, separately - and if you can do that you can snarf the Y->X component and discard the Z component.) Please think about the issues some, and study Radia Perlman's PhD thesis, (where you will find it all laid out) before claiming that the two are equivalently protectable, when they are not. Connectivity information is *fundamentally* different from *reachability* information. Noel From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 05:16:17 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA07072; Sun, 27 Apr 1997 05:16:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA09823; Sun, 27 Apr 1997 05:15:07 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA09801; Sun, 27 Apr 1997 04:56:55 +1000 Received: from pinky.junction.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id SA10239; Sun, 27 Apr 1997 04:56:53 +1000 (from michael@memra.com) Received: from sidhe.memra.com (sidhe.memra.com [199.166.227.105]) by pinky.junction.net (8.6.12/8.6.12) with ESMTP id LAA22339; Sat, 26 Apr 1997 11:56:37 -0700 Received: from localhost (michael@localhost) by sidhe.memra.com (8.6.12/8.6.12) with SMTP id LAA28805; Sat, 26 Apr 1997 11:52:00 -0700 Date: Sat, 26 Apr 1997 11:51:58 -0700 (PDT) From: Michael Dillon To: big-internet@munnari.OZ.AU Cc: roque@cisco.com, ietf@cnri.reston.va.us Subject: Re: Autonomous System Sanity Protocol In-Reply-To: <9704261829.AA20681@ginger.lcs.mit.edu> Message-Id: Organization: Memra Software Inc. - Internet consulting Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 26 Apr 1997, Noel Chiappa wrote: > Connectivity information is *fundamentally* different from *reachability* > information. Using maps implies that there is a central database that records the current state of this fairly static connectivity information and that routing announcements would be verified against this database to ensure that the announced routes correspond to edges on the map. So, who will manage the database and how will it be distributed so that this database does not become a single point of failure? Also, do you know if Perlman's thesis is available on the net? Michael Dillon - Internet & ISP Consulting Memra Software Inc. - Fax: +1-250-546-3049 http://www.memra.com - E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 06:56:37 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA01354; Sun, 27 Apr 1997 06:56:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA09948; Sun, 27 Apr 1997 06:55:08 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA09931; Sun, 27 Apr 1997 06:53:56 +1000 Received: from sjf-mail20.sjf.novell.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id UA10560; Sun, 27 Apr 1997 06:53:53 +1000 (from RADIA_PERLMAN@novell.com) Received: from INET-SJF-Message_Server by novell.com with Novell_GroupWise; Sat, 26 Apr 1997 13:53:52 -0700 Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Sat, 26 Apr 1997 10:52:53 -0700 From: RADIA PERLMAN To: big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol Precedence: bulk (Note: I removed IETF from the distribution list. Hope all the interested people are on big-internet.) Re: Also, do you know if Perlman's thesis is available on the net? No, it's not available on the net. I've been promising to write an informational RFC. That would probably be the easiest thing. I no longer have softcopy. So it wouldn't be the actual thesis, it would be a rewritten thing, possibly clearer now that I've had a few years of explaining it, and I won't have to ask whether there's a problem with copyright. It's also summarized in both my books (Interconnections: Bridges and Routers, chapter 11, and Network Security: Private Communication in a Public World, pp 462-465) Gee. 4 pages. It really is a simple scheme. I can also mail hardcopy of the thesis, but only to people who really really want to read it and soon. Otherwise, I'd rather people waited until I wrote the RFC. If you want me to mail hardcopy, email me your postal address. If I get more than, say, 20 responses, I don't promise to mail them out. If anyone has the appropriate tools for automatic conversion from hardcopy into softcopy, that would be nice (provided I check with MIT about copyright). Maybe the topic of small changes to what's deployed to ameliorate various types of Byzantine failures, mabye a BOF would be appropriate? Or a research group? Anyway, some thoughts... Having an authoritative database of all the potential links, and the routing algorithm only tells you which of those things are currently unreachable, might be nice. That database could be signed, and then replicated without concern for integrity protection, but unfortunately parts of the topology want to remain secret from other parts. (e.g., BGP has "don't pass this information to neighbor N", presumably because people want it). Maybe rather than passing around the authoritative database, there can be a tool that queries all the configured information at boundaries, or a hierarchy of such tools that explore their own portion of the topology, for sanity? A Byzantine failure of a true router can't be solved with having routers sign messages, because the compromised router will be able to generate a legitimate signature to prove he's one of the good guys. BGP is actually somewhat like a link state protocol, in that the entire path is given. If each router signs its path to D, then when router R chooses among the routes given by each of its neighbors, it chooses one, and can preserve that neighbor's signature, and then add its own. So there would be a signature for each BGP-hop. I don't think that solves too much, though, since the problem is a legitimate router being misconfigured rather than having malicious people inject messages. Radia ! From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 08:36:35 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA15612; Sun, 27 Apr 1997 08:36:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA10059; Sun, 27 Apr 1997 08:35:21 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA10053; Sun, 27 Apr 1997 08:32:31 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id WA12652; Sun, 27 Apr 1997 08:32:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21401; Sat, 26 Apr 97 18:32:21 -0400 Date: Sat, 26 Apr 97 18:32:21 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704262232.AA21401@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, michael@memra.com Subject: Re: Autonomous System Sanity Protocol Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Michael Dillon Using maps implies that there is a central database that records the current state of this fairly static connectivity information and that routing announcements would be verified against this database to ensure that the announced routes correspond to edges on the map. Nope. Why should there be? A couple of different things catch my eye here. First, I'm not sure what you mean by "routing announcements". Remember, nobody sends out their routing table any more. The *only* thing you ever say is "I'm X, and I'm attached to A, B, and C". (Major glossing over to handle issues of abstraction, but in essence this is true.) Second, why do you need a configured database to check any dynamic announcements against? To me, this is like saying you need a configured table to check DNS lookups against. Just as the collection of DNS zone files on disk *is* the (distributed) master database, from which entries get sent out to caches around the net, the set of information *in routers X1...Xn* that it is connected to A, B and C *is* the (distributed) master database, copies of which again get sent out to all the entities which need that information. The maps that people create (there is no central map, it would be an impossibly big database anyway) are done so by putting together the connectivity announcements that people make. (Think of people's maps as sets of cached connectivity announcements...) Since the sources of those announcements are absolutely authoritative for *their own* connectivity, there is no reason not to believe them. (You can decide to ignore them, but let's leave out that detail for now.) So, who will manage the database and how will it be distributed so that this database does not become a single point of failure? It's the fate-sharing design principle. X knows it is connected to A, B and C - so the "master" copy of the information *about X* is stored *in X*. If X goes away, who cares - the *need* for the information *about* X went away *with* X. There is no central database - the authoritative version of each piece of data is stored with the entity to which applies. Things get a little tricker when X is not a single physical entity, but a collection of entities acting as a logical entity. What happens there is that the virtual representation of X has to be (recursively) based on the real data about the physical things which make up X. So, at base, the initial, bootstrap data is still "fate-shared". You do have to have a protocol for the entities who make up X and are responsible for announcing it to the rest of the net to "filter" this data up, and agree on what representation of X they will present to people, etc and this is not trivial, but it does rest on the bootstrap of fate-shared data. Noel From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 11:56:21 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA00350; Sun, 27 Apr 1997 11:56:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA10265; Sun, 27 Apr 1997 11:55:10 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA10248; Sun, 27 Apr 1997 11:54:35 +1000 Received: from red.jnx.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id BA13086; Sun, 27 Apr 1997 11:54:33 +1000 (from tli@jnx.com) Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.6]) by red.jnx.com (8.8.5/8.8.5) with ESMTP id SAA04667; Sat, 26 Apr 1997 18:54:31 -0700 (PDT) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id SAA00750; Sat, 26 Apr 1997 18:54:19 -0700 (PDT) To: RADIA_PERLMAN@novell.com (RADIA PERLMAN) Cc: big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol References: From: Tony Li Date: 26 Apr 1997 18:54:18 -0700 In-Reply-To: RADIA_PERLMAN@novell.com's message of 26 Apr 97 17:52:53 GMT Message-Id: <82u3kt6xit.fsf@chimp.jnx.com> Lines: 23 X-Mailer: Gnus v5.3/Emacs 19.34 Precedence: bulk RADIA_PERLMAN@novell.com (RADIA PERLMAN) writes: > BGP is actually somewhat like a link state protocol, in that the entire > path is given. If each router signs its path to D, then when router R > chooses among the routes given by each of its neighbors, it chooses one, > and can preserve that neighbor's signature, and then add its own. So > there would be a signature for each BGP-hop. I don't think that solves > too much, though, since the problem is a legitimate router being > misconfigured rather than having malicious people inject messages. Exactly so. What's truly needed is a delegation of authority to advertise prefixes. We'd also need a means of verifying that authority. What Radia describes is sufficient to guarantee that the path advertised matches reality, which is necessary if we're out to secure the protocol against liars and bad guys. However, if we assume that the basic protocol machinery is correct and are out to protect us against ourselves, the delegation problem is the correct one to solve. Note that any practical solution probably requires some type of key management solution already deployed. One then needs to be able to see a hierarchy of signed and trusted address space delegations. Tony From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 13:16:35 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id DA09684; Sun, 27 Apr 1997 13:16:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA10364; Sun, 27 Apr 1997 13:15:10 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA10349; Sun, 27 Apr 1997 13:08:18 +1000 Received: from zephyr.isi.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id DA19133; Sun, 27 Apr 1997 13:08:17 +1000 (from bmanning@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-24) id ; Sat, 26 Apr 1997 20:05:44 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199704270305.AA01853@zephyr.isi.edu> Subject: Re: Autonomous System Sanity Protocol To: tli@jnx.com (Tony Li) Date: Sat, 26 Apr 1997 20:05:44 -0700 (PDT) Cc: RADIA_PERLMAN@novell.com, big-internet@munnari.OZ.AU In-Reply-To: <82u3kt6xit.fsf@chimp.jnx.com> from "Tony Li" at Apr 26, 97 06:54:18 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 646 Precedence: bulk > > However, if we assume that the basic protocol machinery is correct and are > out to protect us against ourselves, the delegation problem is the correct > one to solve. Note that any practical solution probably requires some type > of key management solution already deployed. One then needs to be able to > see a hierarchy of signed and trusted address space delegations. > > Tony Humm, perhaps a first, rough cut might be turning on DNS Security for the inverse delegations all the way down. That way you could get a "chain of custody" for the authoritative delegations. You could also discriminate proxy aggregations... :) --bill From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 15:16:57 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA22893; Sun, 27 Apr 1997 15:16:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA10500; Sun, 27 Apr 1997 15:15:12 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA10483; Sun, 27 Apr 1997 15:05:01 +1000 Received: from freeside.fc.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA20948; Sun, 27 Apr 1997 15:04:59 +1000 (from jerry@freeside.fc.net) Received: from freeside.fc.net (localhost.fc.net [127.0.0.1]) by freeside.fc.net (8.8.5/8.6.6) with ESMTP id AAA03232; Sun, 27 Apr 1997 00:01:20 -0500 (CDT) Message-Id: <199704270501.AAA03232@freeside.fc.net> To: bmanning@isi.edu (Bill Manning) Cc: tli@jnx.com (Tony Li), RADIA_PERLMAN@novell.com, big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol In-Reply-To: Your message of "Sat, 26 Apr 1997 20:05:44 PDT." <199704270305.AA01853@zephyr.isi.edu> Date: Sun, 27 Apr 1997 00:01:19 -0500 From: Jeremy Porter Precedence: bulk In message <199704270305.AA01853@zephyr.isi.edu>, Bill Manning writes: >> >> However, if we assume that the basic protocol machinery is correct and are >> out to protect us against ourselves, the delegation problem is the correct >> one to solve. Note that any practical solution probably requires some type >> of key management solution already deployed. One then needs to be able to >> see a hierarchy of signed and trusted address space delegations. >> >> Tony > > >Humm, perhaps a first, rough cut might be turning on DNS Security for the >inverse delegations all the way down. That way you could get a "chain of >custody" for the authoritative delegations. You could also discriminate >proxy aggregations... :) >--bill I'm not sure if/what your joking about, but I sure wouldn't trust inverse delegations to be correct, with companies out on the net deleting delegations in excess of their real authority. Of course if you did this at least you wouldn't have to worry about be routing addresses where the in-addr.arpa's wern't correctly delegated... The question with regard to trusted agencies is a real problem, and apparently one of the ones that still hasn't been solved. --- Jeremy Porter, Freeside Communications, Inc. jerry@fc.net PO BOX 80315 Austin, Tx 78708 | 1-800-968-8750 | 512-458-9810 http://www.fc.net From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 15:36:20 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA20677; Sun, 27 Apr 1997 15:36:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA10544; Sun, 27 Apr 1997 15:35:11 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA10534; Sun, 27 Apr 1997 15:27:11 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA21902; Sun, 27 Apr 1997 15:27:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22472; Sun, 27 Apr 97 01:27:05 -0400 Date: Sun, 27 Apr 97 01:27:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704270527.AA22472@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, tli@jnx.com Subject: Re: Autonomous System Sanity Protocol Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li > use of public key cryptography can prevent anyone else from originating > bad information about connectivity inside or to X - their map updates > will not be correctly signed with X's private key If you posit the use of PKC for map distribution it seems only fair to posit its use in a prefix distribution system. However, the fundamental difference between *connectivity* information and *reachability* information comes into play - the latter is not useful to you *until* it has been processed (i.e. not just replicated) through someone else (i.e. path selection is *inherently* a distributed computation, in which you use someone else's partial computation results), whereas connectivity information is only used *without* being touched in any way be the people who pass it on - so there is no way any errors/malice on their part can mess it up. Either you have it as the source sent it - or you don't. this also presumes the existence of a mechanism to derive prefix authority. This is thought to be non-trivial. How you find out, authoritatively, the public key for X is definitely a hard one. (It's even harder in bottom-up addressing systems instead of top-down, sigh...) But it isn't impossible - in fact (admittedly, without working out the details) in a top-down system, the same framework that works for DNS should work for addresses too, no? > It can certainly prevent all unilateral bad information, i.e. based on > someone incorrectly configuring their routers (or software/hardware > bugs). How? Because routing data is never modified/updated/added-to on its way to you, merely copied. You can be *guaranteed* that what you get is what the original sender sent. So there's no way anyone between you and the source can mess the data up, right? All they can do is try and stop the data from going through - but there are limits on how much good this will do them. If they are your only path between you and the source of the update - well, they can screw you anyway, by passing the routing update, but not your data. (Think of it as another form of fate-sharing - but this time, it's data and routing updates! :-) If they aren't, then if the routing update gets to you via another path, if you have an explicit/unitary routing architecture (also my assumption, surprise, surprise :-), your data can take the same path too. The other thing a single site, either confused/malicious, can try and do is inject bogus data (i.e. saying "I'm X and I'm connected to A, B, C ... "). But this doesn't work because the data will not match up - i.e. A is not also reporting that they are connected to X. So you can trivially filter that out. So, there's no way for a single site to cause havoc. Pairs of sites can get together are lie about connectivity, sure (and we can explore that case at length, if people are interested), but that's unlikely to happen except maliciously... (famous last words? :-) If we consider a typical link state protocol today (as perhaps a degenerate example of map distribution) Well, not so much degenerate, as in a different fundamental quadrant of design space, the two major axes (IMNSHO, anyway :-) being MD/DV, and hop-by-hop/unitary. it's trivial to inject bad information and have it propagate throughout the immediate map. Well, it would depend on the protocol design. If you can't have a link between X and Y unless each end reports connectivity to the other, you can't have unilateral announcements. (I don't know enough details of, e.g. OSPF to know if it would work to have only one end of a link announce it - anyone know?) Yes, a malicious site could try and fake both ends, but then you get into the next problem, which is that when X saw what looked like a more recent version of their data than their own last update (and again, this depends on the protocol details), they might try and "correct" it by sending out a new, "correct" update. Further, unless there is intelligence (aka filtering) between the local map and the global map, it will tend to propagate globally. I'm not quite sure what you had in mind here, but in an OSPF-like system where addresses and topology are so complete disconnected, so that routers and areas only report the address ranges they are connected to, it might look like there's a lot of potential for abuse - unless you have a delegation f authority along with PKC, so that router or area X can't announce that it's connected to address range R unless it has R's private key... I would tend to agree with you more if we had a system where we had stronger abstraction boundaries and fewer abstraction violations. Well, not to say we don't need that *anyway* (but for other reasons), but as long as you have private keys associated with topology naming abstractions, I think you're safe. It would leave us with less need to propagate information from the immediate map to the global map because we'd simply be propagating the static abstraction information. Unfortunately, our inability to do this is more a function of the address allocation than the information distribution mechanism. Yes, but again, this is more an issue of routing efficiency than security; just because A.1 is over here in B, detached from A, doesn't mean it needs A's private key, it only needs the key for A.1 - which it both i) has to have, and ii) is entitled to, anyway. The need to propogate information about exceptions out to larger and larger scopes until you find one that contains both the partitioned smaller entity (this is basically the partitioning problem, right?) and the "parent" entity is mostly just an efficiency one (i.e. the only cost is extra overhead), as far as I can see. Am I missing something? As an example, consider a utopian world where we had an address assignment which maintained such strong abstraction boundaries. Using BGP4, one simply does proxy aggregation... But even assuming 100% perfect address allocation, one *still* has the problem in all DV systems that data about X is only useful to you *after* it has been massaged/added-to by everyone in between you. Connectivity data is fundamentally different from reachability data.... Noel From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 15:56:55 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA28664; Sun, 27 Apr 1997 15:56:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA10606; Sun, 27 Apr 1997 15:55:13 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA10586; Sun, 27 Apr 1997 15:51:09 +1000 Received: from black-ice.cc.vt.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id FA22490; Sun, 27 Apr 1997 15:51:07 +1000 (from valdis@black-ice.cc.vt.edu) Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id BAA31818; Sun, 27 Apr 1997 01:51:00 -0400 Message-Id: <199704270551.BAA31818@black-ice.cc.vt.edu> To: bmanning@ISI.EDU (Bill Manning) Cc: tli@jnx.com (Tony Li), RADIA_PERLMAN@novell.com, big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol In-Reply-To: Your message of "Sat, 26 Apr 1997 20:05:44 PDT." <199704270305.AA01853@zephyr.isi.edu> From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <199704270305.AA01853@zephyr.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-773495472P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Sun, 27 Apr 1997 01:50:56 -0400 Precedence: bulk --==_Exmh_-773495472P Content-Type: text/plain; charset=us-ascii On Sat, 26 Apr 1997 20:05:44 PDT, Bill Manning said: > Humm, perhaps a first, rough cut might be turning on DNS Security for the > inverse delegations all the way down. That way you could get a "chain of > custody" for the authoritative delegations. You could also discriminate > proxy aggregations... :) Hmm.. but first, we have to actually get inverse delegations that work. Hell. In the past 5 days on our Listserv hub, I've seen no less than 661 *different* 'Lame server' messages from BIND for the *forward* lookup. On the other hand, Bill may be onto something here.. if we require that the people get their acts together enough so their nameserver forward and inverse tables are correct, and get crypto keys set up, that would probably nuke out all the marginal domains that have too low a cluon flux density. It wouldn't stop a determined and clued attacker, but at least we'd probably turn off most possible origins of "network meltdown from 'ISP Administration for Dummies'" type attacks.... -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_-773495472P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBM2LpPtQBOOoptg9JAQGVzwP/WD6B7nMw0//NflxGr4xWjpoW95kYgtgP +Q6aZO5uTml9KeFUcLcqSSKnfNXxRfqltA4y+yTLoA4py7DuE4/i98mGAriKUM7W CN8dqeH/YfUpqbrj8FR5DMDj6aNJPXdIUTUHxoNQcZc1fKNojaThQdaCS7zIDVTn kuvei9PPozg= =Cisb -----END PGP MESSAGE----- --==_Exmh_-773495472P-- From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 16:36:25 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA23432; Sun, 27 Apr 1997 16:36:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA10674; Sun, 27 Apr 1997 16:35:11 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA10670; Sun, 27 Apr 1997 16:29:24 +1000 Received: from home.partan.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA21786; Sun, 27 Apr 1997 16:29:21 +1000 (from asp@partan.com) Received: (from asp@localhost) by home.partan.com (8.6.12/8.6.12) id CAA00705; Sun, 27 Apr 1997 02:29:12 -0400 From: Andrew Partan Message-Id: <199704270629.CAA00705@home.partan.com> Subject: Re: Autonomous System Sanity Protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sun, 27 Apr 1997 02:29:12 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9704270527.AA22472@ginger.lcs.mit.edu> from "Noel Chiappa" at Apr 27, 97 01:27:05 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 734 Precedence: bulk > Yes, but again, this is more an issue of routing efficiency than security; > just because A.1 is over here in B, detached from A, doesn't mean it needs > A's private key, it only needs the key for A.1 - which it both i) has to > have, and ii) is entitled to, anyway. This is precisely the problem that we had. How do I stop unauthorized A.1s from being advertised? [The problem came in two parts. The first part was that suddenly a huge pile of more specifics (A.1s) were being advertised (incorrectly) by B. The second part is that the routes didn't get widthdrawn correctly - they still existed in various parts of the Internet some 24 hours after B disconnected itself from the Internet.] --asp@partan.com (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sun Apr 27 19:15:35 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA24382; Sun, 27 Apr 1997 19:15:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA10850; Sun, 27 Apr 1997 19:15:14 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA10833; Sun, 27 Apr 1997 18:55:28 +1000 Received: from red.jnx.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id IA21093; Sun, 27 Apr 1997 18:55:27 +1000 (from tli@jnx.com) Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.6]) by red.jnx.com (8.8.5/8.8.5) with ESMTP id BAA21349; Sun, 27 Apr 1997 01:55:24 -0700 (PDT) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id BAA01355; Sun, 27 Apr 1997 01:55:12 -0700 (PDT) Date: Sun, 27 Apr 1997 01:55:12 -0700 (PDT) Message-Id: <199704270855.BAA01355@chimp.jnx.com> From: Tony Li To: jnc@ginger.lcs.mit.edu Cc: jnc@ginger.lcs.mit.edu, tli@jnx.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9704270527.AA22472@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Autonomous System Sanity Protocol Precedence: bulk However, the fundamental difference between *connectivity* information and *reachability* information comes into play - the latter is not useful to you *until* it has been processed (i.e. not just replicated) through someone else (i.e. path selection is *inherently* a distributed computation, in which you use someone else's partial computation results), whereas connectivity information is only used *without* being touched in any way be the people who pass it on - so there is no way any errors/malice on their part can mess it up. Either you have it as the source sent it - or you don't. True. However, let's recall the problem that we're trying to solve. We are _NOT_ trying to solve Radia's Byzantine failures. [Not that it's not a worthy and interesting problem in its own right. It's just not the failure at hand.] How you find out, authoritatively, the public key for X is definitely a hard one. Agreed. Unfortunately, that's a basic requirement for ANY of these schemes. I don't claim to know enough about security to solve that problem. But it isn't impossible - in fact (admittedly, without working out the details) in a top-down system, the same framework that works for DNS should work for addresses too, no? The architecture is believably the same. It's not clear that the mechanisms would suffice. Note that top-down or bottom-up assignment generally doesn't seem to make a difference as far as I can tell. It looks like the leaf has some address space and to authenticate that, you have to be able to walk delegations back to a well known root. > It can certainly prevent all unilateral bad information, > i.e. based on someone incorrectly configuring their routers (or > software/hardware bugs). How? Because routing data is never modified/updated/added-to on its way to you, merely copied. You can be *guaranteed* that what you get is what the original sender sent. So there's no way anyone between you and the source can mess the data up, right? Again, it's irrelevant to the problem at hand. You lack the delegation information. The other thing a single site, either confused/malicious, can try and do is inject bogus data (i.e. saying "I'm X and I'm connected to A, B, C ... "). But this doesn't work because the data will not match up - i.e. A is not also reporting that they are connected to X. So you can trivially filter that out. Again true. Again not relevant. it's trivial to inject bad information and have it propagate throughout the immediate map. Well, it would depend on the protocol design. If you can't have a link between X and Y unless each end reports connectivity to the other, you can't have unilateral announcements. (I don't know enough details of, e.g. OSPF to know if it would work to have only one end of a link announce it - anyone know?) You are correct: you cannot fake bilateral connectivity and unilateral connections should be ignored in the SPF. However, you can still trivially fake the prefixes in the LSA and then sign the LSA. Game over. Are you sure you understand the problem Noel? Let's take a clear example. This is the LSA for MIT: Hi, we're MIT, we have connectivity to BBN Planet, Harvard and Cerfnet. We have prefixes 18/8, 36.0/9 and 36.128/9. Signed, Jeff Schiller Now, you're correct, the connectivity information would show up as bogus because the other sides wouldn't claim connectivity. However, what authenticates the prefix assignments? Just because it appears to be correctly signed by Jeff, do you take it verbatim? I don't. That would subvert all of Stanford. [You may argue that this is a good thing. ;-)] For security, I want to see MIT is assigned 18/8. Signed, Jon Postel Until then, there's no protection. Tony From owner-Big-Internet@munnari.OZ.AU Mon Apr 28 00:15:58 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA00549; Mon, 28 Apr 1997 00:15:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA11141; Mon, 28 Apr 1997 00:15:18 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA11124; Mon, 28 Apr 1997 00:00:43 +1000 Received: from postoffice.Reston.mci.net by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA00259; Mon, 28 Apr 1997 00:00:41 +1000 (from young@mci.net) Received: from mci.net (marvinthemartian [166.45.4.32]) by postoffice.Reston.mci.net (8.8.5/8.8.5) with ESMTP id KAA28676; Sun, 27 Apr 1997 10:00:03 -0400 (EDT) Message-Id: <199704271400.KAA28676@postoffice.Reston.mci.net> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: roque@cisco.com, big-internet@munnari.OZ.AU, ietf@cnri.reston.va.us Subject: Re: Autonomous System Sanity Protocol In-Reply-To: Your message of "Sat, 26 Apr 1997 14:29:41 EDT." <9704261829.AA20681@ginger.lcs.mit.edu> Date: Sun, 27 Apr 1997 10:00:02 -0400 From: "Jeff Young" Precedence: bulk so in addition to the registries that hold the routing information we need some kind of key repository for the exchange of information. then there's the new or improved protocol to handle passing and authenticating the information. that'd protect us from a lot (an even bigger previous - 192/8 - fiasco comes to mind). sounds like the use of registries is still a good start. Jeff Young young@mci.net > Return-Path: owner-Big-Internet@munnari.OZ.AU > Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) > by postoffice.Reston.mci.net (8.8.5/8.8.5) with SMTP id PAA20824; > Sat, 26 Apr 1997 15:00:11 -0400 (EDT) > Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) > id EAA09755; Sun, 27 Apr 1997 04:37:20 +1000 > Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP > id EAA09734; Sun, 27 Apr 1997 04:29:47 +1000 > Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) > id SA04656; Sun, 27 Apr 1997 04:29:45 +1000 (from jnc@ginger.lcs.mit.edu) > Received: by ginger.lcs.mit.edu > id AA20681; Sat, 26 Apr 97 14:29:41 -0400 > Date: Sat, 26 Apr 97 14:29:41 -0400 > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Message-Id: <9704261829.AA20681@ginger.lcs.mit.edu> > To: jnc@ginger.lcs.mit.edu, roque@cisco.com > Subject: Re: Autonomous System Sanity Protocol > Cc: big-internet@munnari.OZ.AU, ietf@cnri.reston.va.us, jnc@ginger.lcs.mit.edu > Precedence: bulk > Content-Type: text > Content-Length: 2081 > > allow these erroneous statements to go uncorrected.> > > From: Pedro Marques > > > use of public key cryptography can prevent anyone else from originating > > bad information about connectivity inside or to X > > s/map/BGP route/g > ... and everything you said still holds. > > No. There is a fundamental difference. > > If I'm X, I know, *authoritatively and definitively*, who is attached to me. > I can then originate this information and sign it, in the form of map element > information ("Hi, I'm X, and I'm attached to A, B and C, and here's the seal > for that, encrypted with my private key".) You can use the concatentation of > all such data (modulo, as I said, issues like people co-operating to lie > about non-existent connections) to produce routing which is resistant to > single-point failure and/or malice. > > However, in a destination vector system, such as BGP, X cannot know, > authoritatively, the details of connectivity elsewhere. That means that Y can > pass on to Z information about a route which Y has to X, and there is no way > for X to sign *that* data, or even to verify that it is correct. > > (Extra detail, ignore if you don't care: Saying you can recursively sign the > route doesn't help, I don't think - you can strip off later elements and work > with a partial, and fully signed, route. In other words, if I get a route to > X which is Z->Y->X, it *can't* be the case that when Z signed it, he only > signed an indivisible composite - if so, how can you check that the Y->X > portion is legitimate, and not something Z made up? You have to be able to > check the Y->X component, and the X source, separately - and if you can do > that you can snarf the Y->X component and discard the Z component.) > > Please think about the issues some, and study Radia Perlman's PhD thesis, > (where you will find it all laid out) before claiming that the two are > equivalently protectable, when they are not. > > Connectivity information is *fundamentally* different from *reachability* > information. > > Noel From owner-Big-Internet@munnari.OZ.AU Mon Apr 28 01:35:48 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA04941; Mon, 28 Apr 1997 01:35:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA11313; Mon, 28 Apr 1997 01:35:19 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11296; Mon, 28 Apr 1997 01:22:15 +1000 Received: from zephyr.isi.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA02321; Mon, 28 Apr 1997 01:22:14 +1000 (from bmanning@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-24) id ; Sun, 27 Apr 1997 08:22:09 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199704271522.AA08584@zephyr.isi.edu> Subject: Re: Autonomous System Sanity Protocol To: tli@jnx.com (Tony Li) Date: Sun, 27 Apr 1997 08:22:09 -0700 (PDT) Cc: jnc@ginger.lcs.mit.edu, tli@jnx.com, big-internet@munnari.OZ.AU In-Reply-To: <199704270855.BAA01355@chimp.jnx.com> from "Tony Li" at Apr 27, 97 01:55:12 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 830 Precedence: bulk > Hi, we're MIT, we have connectivity to BBN Planet, Harvard and > Cerfnet. We have prefixes 18/8, 36.0/9 and 36.128/9. > Signed, > Jeff Schiller > > Now, you're correct, the connectivity information would show up as bogus > because the other sides wouldn't claim connectivity. However, what > authenticates the prefix assignments? Just because it appears to be > correctly signed by Jeff, do you take it verbatim? I don't. That would > subvert all of Stanford. [You may argue that this is a good thing. ;-)] > For security, I want to see > > MIT is assigned 18/8. > Signed, > Jon Postel > So you would like to discriminate between the chain for 18/8 and the 36.128/9 yes? And find out that there is a viable chain for 18/8 and a broken chain for 36.128/9 from that particular AS? -- --bill From owner-Big-Internet@munnari.OZ.AU Mon Apr 28 14:16:31 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA20663; Mon, 28 Apr 1997 14:16:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA11963; Mon, 28 Apr 1997 14:15:33 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA11946; Mon, 28 Apr 1997 14:07:55 +1000 Received: from red.jnx.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id EA22827; Mon, 28 Apr 1997 14:07:49 +1000 (from tli@jnx.com) Received: from chimp.jnx.com (chimp.jnx.com [208.197.169.6]) by red.jnx.com (8.8.5/8.8.5) with ESMTP id VAA09613; Sun, 27 Apr 1997 21:07:29 -0700 (PDT) Received: (from tli@localhost) by chimp.jnx.com (8.7.6/8.7.3) id VAA02740; Sun, 27 Apr 1997 21:07:15 -0700 (PDT) Date: Sun, 27 Apr 1997 21:07:15 -0700 (PDT) Message-Id: <199704280407.VAA02740@chimp.jnx.com> From: Tony Li To: bmanning@ISI.EDU Cc: jnc@ginger.lcs.mit.edu, tli@jnx.com, big-internet@munnari.OZ.AU In-Reply-To: <199704271522.AA08584@zephyr.isi.edu> (bmanning@ISI.EDU) Subject: Re: Autonomous System Sanity Protocol Precedence: bulk So you would like to discriminate between the chain for 18/8 and the 36.128/9 yes? And find out that there is a viable chain for 18/8 and a broken chain for 36.128/9 from that particular AS? Exactly. Notice how this fixes the AS 7007 problem: everything's broken so we know to discard the routes. Tony From owner-Big-Internet@munnari.OZ.AU Mon Apr 28 16:16:06 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA10914; Mon, 28 Apr 1997 16:16:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA12097; Mon, 28 Apr 1997 16:15:32 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA12080; Mon, 28 Apr 1997 16:00:59 +1000 Received: from callandor.cybercash.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id GA25106; Mon, 28 Apr 1997 16:00:31 +1000 (from dee@cybercash.com) Received: by callandor.cybercash.com; id BAA25318; Mon, 28 Apr 1997 01:50:17 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma025312; Mon, 28 Apr 97 01:49:46 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA24447; Mon, 28 Apr 97 01:54:56 EDT Date: Mon, 28 Apr 1997 01:54:55 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Jeff Young Cc: roque@cisco.com, big-internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US Subject: Re: Autonomous System Sanity Protocol In-Reply-To: <199704271400.KAA28676@postoffice.Reston.mci.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk See RFC 2065. DNSSEC provides a way to securely distribute keys associated with domain names. By populating the in-addr.arpa tree with keys and securing the DNS tree above that point, you could provide for authoritative messages signed by an IP address as to what local connectivity it sees. Donald (Alternatively you could distribute the key and server list for the in-addr.arpa (and ip6.int or whatever it is) nodes and not have to secure the tree above that point. And I'm sure there are complication associated with classless in-addr delegation...but these are probably surmoutable.) On Sun, 27 Apr 1997, Jeff Young wrote: > Date: Sun, 27 Apr 1997 10:00:02 -0400 > From: Jeff Young > To: Noel Chiappa > Cc: roque@cisco.com, big-internet@munnari.oz.au, ietf@CNRI.Reston.VA.US > Subject: Re: Autonomous System Sanity Protocol > > so in addition to the registries that hold the routing information > we need some kind of key repository for the exchange of information. > then there's the new or improved protocol to handle passing and > authenticating the information. > > that'd protect us from a lot (an even bigger previous - 192/8 - fiasco > comes to mind). sounds like the use of registries is still a good start. > > Jeff Young > young@mci.net ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-Big-Internet@munnari.OZ.AU Mon Apr 28 18:35:55 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id IA28788; Mon, 28 Apr 1997 18:35:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA12264; Mon, 28 Apr 1997 18:35:34 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA12258; Mon, 28 Apr 1997 18:25:46 +1000 Received: from bells.cs.ucl.ac.uk by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id IA26216; Mon, 28 Apr 1997 18:25:36 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 28 Apr 1997 09:25:28 +0100 To: big-internet@munnari.OZ.AU Cc: J.Crowcroft@cs.ucl.ac.uk Subject: Re: Autonomous System Sanity Protocol In-Reply-To: Your message of "Sun, 27 Apr 1997 21:07:15 PDT." <199704280407.VAA02740@chimp.jnx.com> Date: Mon, 28 Apr 1997 09:25:26 +0100 Message-Id: <860.862215926@cs.ucl.ac.uk> From: Jon Crowcroft Precedence: bulk there seem to be a spate of routing problems and a gamut of solutions, with different time frame applicability.... 1. this incident (egp/igp/egp specific) has been well addressed by per and tony.... in the longer run, it seems to me that there are several pieces to any reasonably engineered systems design for stable, disaster resistent multi provider routing: 1/ trust chains - i) you need to sign updtes with a hash (RC4?) and progate aggregated routes with this, and then use PGP trust chaining - unfortuantely, this wont scale, or in fact deal with the specific current problem..... ii) as part of this, you need not only route settlements, but penalties...i.e. $$$ for trouble caused, as well as connectivity provided... 2/ use engineering statistics - e.g. i nthe mbone, we don't propogate route updates containing more than a plausible number of entries...this is heavy handed and manual/operater intensive, but there are a number of route pathologies (e.g. vern paxson's work identifies their salient parameters and dynamics) which could be used to either i) set alarms ii) automate sanity filters.... 3/ on a general (jnc type note), there does seem to be a problem "solving" the larger problem elegantly - piecewise refinement goes just so far, but a scheme to colour areas and exchange maps should be a lot more resistent to some collapses (though i don't really see how either nimrod or radia's byzantine routing solve the problem of an accidently or delibverately misconfigured AS..........the only way yo udo that is to use "safety in numbers" or redundancy... i) provide hints for routing from an alternate source (e.g. put GPS receivers in all border routers, and log their gographic posn; as part of the BGP and make sure that a reasoanble percentage of the relevant nets adverttized are actually "within" a border - yes i know lots are not, but a sanity check (to ring alarms) should be derivable from this.... ii) actually combine link state and distance vector - normally each LS router receives a bunch of LSAs from all other routers in an area - in distance vector, you get a route table from all neighbour routers if you got a part of the hierarchical route table from all other routes, then you could _vote_ (yes i know it doesn't scale, but you can be selective about who you need backup info from.....or trigger it based on engineering alarms from 2/...) 4/ multicast and rsvp are going to cause even more problems than unicast messups like this (because of the denial of service problems and multiplier effects they both have) unless the underlying system has some strong sanity checks..... what do you _expect_ as a provider ? what cosntraints does that put on what updates you should receive, and from whom? jon From owner-Big-Internet@munnari.OZ.AU Tue Apr 29 00:16:54 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA05325; Tue, 29 Apr 1997 00:16:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA12710; Tue, 29 Apr 1997 00:15:37 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA12704; Tue, 29 Apr 1997 00:14:39 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA03505; Tue, 29 Apr 1997 00:14:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28893; Mon, 28 Apr 97 10:14:07 -0400 Date: Mon, 28 Apr 97 10:14:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704281414.AA28893@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Jon Crowcroft ii) as part of this, you need not only route settlements, but penalties...i.e. $$$ for trouble caused The problem with this is that I think this latest case follows a typical model for many "large-scale" (not that this is on the same absolute scale as most, I admit) technological failures, which is that one or more "hidden" faults elsewhere in the system, faults which are pre-existent but which have remained hidden by not actually occurring are "excited" (in the technical sense) by what would otherwise be a small-scale "trigger" event. In our latest event, it does appear that the fact that "bad" routes continued to circulate in the system for some hours *after* the site that initiated them had been completely disconnected appears to show that we have an event in that class. Surely, it is *independent* faults elsewhere in the system, nothing to do with the site which initiated the event, which caused the event to be as severe as it was. If so, it's unfair to charge all the cost to the initiator - and any attempt to do so would probably wind up in the legal system. this is heavy handed and manual/operater intensive A technique which is going to be less and less applicable as the network grows. i don't really see how either nimrod or radia's byzantine routing solve the problem of an accidently or delibverately misconfigured AS I can't follow this - can you please give some examples of misconfiguration that you think this wouldn't handle? With PKS signing of all statments of the form "I'm router r19, and I'm connected to topology piece X", how can anyone initiate an update which cannot be verified? Each half of that statement has to be signed with the right private key. Which is not to say that this solves all possible problems; we can list them and discuss the countermeasures to them once we have this issue sorted out. actually combine link state and distance vector ... if you got a part of the hierarchical route table from all other routes, then you could _vote_ Again, I'm not following this - how would you use various neighbours' routing tables when it came to selecting paths (remember, I'm assuming explicit/ unitary path selection, *not* hop-by-hop)? Anyway, even if you are using a hop-by-hop design, such systems depend for their correct operation on everyone reaching the *same* conclusion on what the exact path is from X to Y (otherwise loops can form). The easiest way to do this is ensure that everyone i) has the same data, and ii) is using the exact same algorithm to turn that data into routes. (Unless you can use some high-powered proof to show that the results will always be the same, e.g. if everyone is required to compute the optimal path across the graph, it's OK to use different algorithms to do so, since that final state is precisely defined, mathematically, so how you get there is not crucial.) So, whatever your algorithm is, it better have that property, otherwise you loose... Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 29 00:56:06 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA32375; Tue, 29 Apr 1997 00:56:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA12867; Tue, 29 Apr 1997 00:55:37 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA12800; Tue, 29 Apr 1997 00:43:34 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA04100; Tue, 29 Apr 1997 00:43:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29183; Mon, 28 Apr 97 10:43:30 -0400 Date: Mon, 28 Apr 97 10:43:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704281443.AA29183@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: PKS, and the DV/MD choice... Cc: jnc@ginger.lcs.mit.edu Precedence: bulk A private note from Mike O'Dell pointed out that checking a PKS certificate (i.e. something that shows that R1 is in fact allowed to claim that it is attached to X, Y etc) on every topology update sounded like something that wasn't going to scale well. This in fact turns out to be a key point (and one I hadn't seen, and a tip of the hatly hat to Mike :-) - because the PKS approach works *far* better with MD systems than it does with DV! Here's why: In an MD system, you should only get updates from R1 when the topology next to R1 changes (i.e. it's connect to some other router, or a piece of the nework, changes), and each topology change is *guaranteed* to send you only a small amount of data (i.e. what R1 is connected to now). I.e. you don't get all of whatever routing table entries have changed - which could be a lot of data items, each one of which would have to be checked, in a DV system - you only get the one small connectivity update from R1. You then use that, together with pre-checked data already in your map (note this, you checked the correctness of that data in the past, when you first got it, and don't have to do so again now), to do the recomputation of all the routing table entries locally. This is clearly much more tractable than applying PKS to a DV system, where you'd have to check each routing table entry as it came in, which could be rather painful after a topology change which caused lots of routes to change. To me, this sounds like a key factor against application of PKS techniques to a DV system.... On a more general note, though, you have to balance security and overhead. Remember the IAB thing on security and the internetwork layer - do we check every packet to make sure it is authorized, and if so, how expensive is that going to be? Not sure how that principle plays here... Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 29 01:35:48 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA08578; Tue, 29 Apr 1997 01:35:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA12931; Tue, 29 Apr 1997 01:35:36 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12924; Tue, 29 Apr 1997 01:27:42 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA06850; Tue, 29 Apr 1997 01:27:35 +1000 (from huitema@bellcore.com) Received: from seawind.bellcore.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.51) id AA04404; Tue, 29 Apr 1997 01:27:31 +1000 (from huitema@bellcore.com) Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id LAA20751 for big-internet@munnari.oz.au; Mon, 28 Apr 1997 11:26:13 -0400 Date: Mon, 28 Apr 1997 11:26:13 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9704281126.ZM20749@seawind.bellcore.com> In-Reply-To: jnc@ginger.lcs.mit.edu (Noel Chiappa) "PKS, and the DV/MD choice..." (Apr 28, 10:43am) References: <9704281443.AA29183@ginger.lcs.mit.edu> X-Mailer: Z-Mail (3.2.1 10oct95) To: big-internet@munnari.OZ.AU Subject: Re: PKS, and the DV/MD choice... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk So, we want secure connectivity information, saying essentially that "net X is connected to AS Y". One option is to modify BGP-6 to carry certificates. But this is overkill -- the connectivity information is static, about as static as address assignment. Why not just place it in the DNS ? The inverse domains can be secured by DNS sec, with delegation traceable all the way up to the IANA. We could easily place an AS record in that hierarchy, e.g. "*.18.in-addr.arpa AS IN 12345". That would allow instant checks by just looking in the DNS, and a path to escalation in paranoia land for the security conscious. -- Christian Huitema From owner-Big-Internet@munnari.OZ.AU Tue Apr 29 01:37:34 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA07386; Tue, 29 Apr 1997 01:37:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA12958; Tue, 29 Apr 1997 01:37:20 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12927; Tue, 29 Apr 1997 01:29:54 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA08428; Tue, 29 Apr 1997 01:29:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29543; Mon, 28 Apr 97 11:29:44 -0400 Date: Mon, 28 Apr 97 11:29:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704281529.AA29543@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li > If each router signs its path to D, then when router R chooses among > the routes given by each of its neighbors, it chooses one, and can > preserve that neighbor's signature, and then add its own. What's truly needed is a delegation of authority to advertise prefixes. Yes. (But see my message about how that's more efficient, in practise, in an MD system! :-) What Radia describes is sufficient to guarantee that the path advertised matches reality, which is necessary if we're out to secure the protocol against liars and bad guys. Uhh, not quite. As I pointed out in a previous message, there's nothing to stop someone taking the path X->Y->Z, signed at each stage, and stripping off some elements and sending out what looks like a perfectly legitimate X->P. However, I think I have come up with a way of signing routes to prevent stripping by downstream sites, but I want to run it by some security whizzes before I say more. (Of course, to the extent that P can open a direct TCP connection to X, and get it's database, this is a way of avoiding that. A fix would be to modify BGP so it will only give signed routes to routers to which it has a direct connection - and do so in a way which *includes* the next-hop router in the signed route the NHR gets, to prevent the NHR collaborating with someone else to give them a partial route.) But this is all just intellectual fun - fixing any DV system is a waste of time, I think. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 29 01:38:42 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA04994; Tue, 29 Apr 1997 01:38:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA12978; Tue, 29 Apr 1997 01:38:29 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12907; Tue, 29 Apr 1997 01:19:09 +1000 Received: from callandor.cybercash.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA03482; Tue, 29 Apr 1997 01:19:07 +1000 (from dee@cybercash.com) Received: by callandor.cybercash.com; id LAA18844; Mon, 28 Apr 1997 11:09:37 -0400 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma018802; Mon, 28 Apr 97 11:09:12 -0400 Received: by cybercash.com (4.1/SMI-4.1) id AA01311; Mon, 28 Apr 97 11:14:18 EDT Date: Mon, 28 Apr 1997 11:14:18 -0400 (EDT) From: "Donald E. Eastlake 3rd" To: Michael Dillon Cc: big-internet@munnari.OZ.AU, roque@cisco.com Subject: Re: Autonomous System Sanity Protocol In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Why should there be a central database? Every host could do its own computation on all connectivity except for the computational effort. So you want to do it for a cluster of machines and you want to attenuate information from remote areas of the net. For a worked example, see OSPF. Donald On Sat, 26 Apr 1997, Michael Dillon wrote: > Date: Sat, 26 Apr 1997 11:51:58 -0700 (PDT) > From: Michael Dillon > To: big-internet@munnari.oz.au > Cc: roque@cisco.com, ietf@CNRI.Reston.VA.US > Subject: Re: Autonomous System Sanity Protocol > > On Sat, 26 Apr 1997, Noel Chiappa wrote: > > > Connectivity information is *fundamentally* different from *reachability* > > information. > > Using maps implies that there is a central database that records the > current state of this fairly static connectivity information and that > routing announcements would be verified against this database to ensure > that the announced routes correspond to edges on the map. So, who will > manage the database and how will it be distributed so that this database > does not become a single point of failure? > > Also, do you know if Perlman's thesis is available on the net? > > Michael Dillon - Internet & ISP Consulting > Memra Software Inc. - Fax: +1-250-546-3049 > http://www.memra.com - E-mail: michael@memra.com > > ===================================================================== Donald E. Eastlake 3rd +1 508-287-4877(tel) dee@cybercash.com 318 Acton Street +1 508-371-7148(fax) dee@world.std.com Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA) http://www.cybercash.com http://www.eff.org/blueribbon.html From owner-Big-Internet@munnari.OZ.AU Tue Apr 29 01:40:03 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA05978; Tue, 29 Apr 1997 01:40:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA13002; Tue, 29 Apr 1997 01:39:47 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12910; Tue, 29 Apr 1997 01:22:32 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA04450; Tue, 29 Apr 1997 01:22:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29486; Mon, 28 Apr 97 11:20:40 -0400 Date: Mon, 28 Apr 97 11:20:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704281520.AA29486@ginger.lcs.mit.edu> To: RADIA_PERLMAN@novell.com, big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: RADIA PERLMAN > do you know if Perlman's thesis is available on the net? I no longer have softcopy. That's what scanners are for! :-) I won't have to ask whether there's a problem with copyright. I doubt very much MIT would be *any* problem with this. Having an authoritative database of all the potential links, and the routing algorithm only tells yo u which of those things are currently unreachable, might be nice. I dunno. See my comments about "fate-sharing" between router R1, and information about what R1 is connected to. I don't think we can have a centralized database for connectivity, and if we are going to have a distributed one, we might as well make the routers the holders of the authoritative data - which co-locates the data with the routers. unfortunately parts of the topology w ant to remain secret from other parts. That's OK, most advanced systems have provision for hiding the internal topology of an abstraction from people whom they don't want to have it.. Maybe rather than passing around the authoritative database, there can be a tool that queries all the configured information at boundaries, or a hierarchy of such tools that explore their own portion of the topology I'm not sure quite what the point would be? Can you elucidate? (Also, are you assuming a classic hop-by-hop system for determing paths? Perhaps this comment is intended for such a system?) A Byzantine failure of a true router can't be solved with having routers sign messages, because the compromised router will be able to generate a legitimate signature to prove he's one of the good guys. Sure. The only way to detect such a router (which might simply trash 82% of all packets going through it) is to monitor the actual performance you get from the network, relative to any performace guarantee the network has made you, and if you aren't getting it, to try and fault-isolate. Expensive, complex and painful, but I don't see any alternative, *iff* automated protection against this kind of thing is an important goal. My take is that it might be, *for some people*, and the routing architecture should *allow* and *support* it for those who need it, and are willing to pay the price in overhead of so doing, but hopefully with zero cost to those who don't. BGP is actually somewhat like a link state protocol, in that the entire path is given. Yakov and I have this argument all the time! I claim they are fundamentally different - and up until now the only argument I had was that PV is a "back door kludge" way of distributing topology info, and i) is almost certainly not going to give you a complete map, and ii) just feels like a kludgy way of doing it (and we all know that sooner or later, kludges bite you in the a**). Now (see recent message on PKS overhead) I have another argument, which is that the way in which connectivity changes get propogated is fundamentally different too. If each route r signs its path to D, then when router R chooses among the aroutes given by each of its neighbors, it chooses one, and can preserve that neighbor's signature, and then add its own. ... I don't think that solves too much, though, since the problem is a legitimate router being misconfigured rather than having malicious people inject messages. I'm not sure quite what you're getting at here - are you saying that the problem is some router is misconfigured to think it is attached to D, when it in fact is not? If so, sigh, this is what I get for trying to *not* generate a massive tome in my original message - I leave out some of what I assumed (wrongly :-) were fairly obvious steps! I did expand in a later message: > Only "auhorized" agents of topological entity X (i.e. those allowed to > distribute maps or abstractions of X, outside X) have the key to sign > map data about X. but perhaps you missed it. Not only does router R9 have to have a private key (to veryify that updates which claim to be from it actually came from it), but topological abstraction X has to have a private key, so that all routers which can claim to be attached to it can do so authoritatively (i.e. they have to have that private key). This should fix most instances of bad configuration (i.e. excluding ones like R9 is authorized to originate abstractions of X, and originates a bad abstraction, or claims to have a working link to X, when in fact its link is broken). It does, I think, limit the scope of entities which can originate erroneous information about X to those entities to which X has entrusted a private key - and thus are probably under X's control. Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 29 01:56:01 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA08622; Tue, 29 Apr 1997 01:56:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA13061; Tue, 29 Apr 1997 01:55:37 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12941; Tue, 29 Apr 1997 01:36:25 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA05861; Tue, 29 Apr 1997 01:36:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29625; Mon, 28 Apr 97 11:36:11 -0400 Date: Mon, 28 Apr 97 11:36:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704281536.AA29625@ginger.lcs.mit.edu> To: asp@partan.com, jnc@ginger.lcs.mit.edu Subject: Re: Autonomous System Sanity Protocol Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk [The problem came in two parts. ... The second part is that the routes didn't get widthdrawn correctly - they still existed in various parts of the Internet some 24 hours after B disconnected itself from the Internet.] Right, and this was the part I found most interesting. Of course, I'd claim that failures like this are almost inevitable in DV type systems! :-) Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 29 01:57:13 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA08004; Tue, 29 Apr 1997 01:57:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA13086; Tue, 29 Apr 1997 01:56:56 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA13045; Tue, 29 Apr 1997 01:54:42 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA02545; Tue, 29 Apr 1997 01:54:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29781; Mon, 28 Apr 97 11:54:37 -0400 Date: Mon, 28 Apr 97 11:54:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704281554.AA29781@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, tli@jnx.com Subject: Re: Autonomous System Sanity Protocol Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Tony Li let's recall the problem that we're trying to solve. We are _NOT_ trying to solve ... Byzantine failures. Why not? Two points: First, you know the old line about "not being able to make things foolproof because fools are so stupid"? Something similar applies here. If you can make something proof against deliberate attack, it's *probably* (emphasis on the lack of complete certainty, the real world sometimes come up with failure modes not even the smartest foresaw) proof against various kinds of human error, which includes i) bugs, and ii) bad configuration. (From what I can tell, *both* seem to have played a role here.) Second, I am personally appalled, as an engineer, that we are not moving faster and more energetically to secure more highly what is *already* a major part of the world's communication infrastructure. I can pretty much guarantee you that if we don't, sooner or later, i) someone will come along and take the responsibility out of our hands (and rightly so), and ii) we'll end up with a lot of mud on our faces (and again, rightly so). Note that top-down or bottom-up assignment generally doesn't seem to make a difference as far as I can tell. It looks like the leaf has some address space and to authenticate that, you have to be able to walk delegations back to a well known root. Well, I'm not so sure about bottom-up (and maybe this is because you don't have the same model in mind attached to the phrase "bottom-up"). But I don't have time to go into that right now... it's irrelevant to the problem at hand. You lack the delegation information. I apparently explained myself poorly. I was assuming (sigh, when I take the steps in threes, to reduce the tome-volume, this always happens) authentication of connectivity (i.e. "I am connected to topology abstractions X, Y and Z") as well as source ("I'm router R1"). Are you sure you understand the problem Noel? Yes, actually. In fact, I'll warrant I've though about securing against attack more than just about anyone else. :-) Noel From owner-Big-Internet@munnari.OZ.AU Tue Apr 29 03:15:57 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA09457; Tue, 29 Apr 1997 03:15:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA13257; Tue, 29 Apr 1997 03:15:39 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA13240; Tue, 29 Apr 1997 03:05:09 +1000 Received: from home.partan.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA10627; Tue, 29 Apr 1997 03:05:06 +1000 (from asp@partan.com) Received: (from asp@localhost) by home.partan.com (8.6.12/8.6.12) id NAA14752; Mon, 28 Apr 1997 13:04:55 -0400 From: Andrew Partan Message-Id: <199704281704.NAA14752@home.partan.com> Subject: Re: Autonomous System Sanity Protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 28 Apr 1997 13:04:54 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9704281536.AA29625@ginger.lcs.mit.edu> from "Noel Chiappa" at Apr 28, 97 11:36:11 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 552 Precedence: bulk > [The problem came in two parts. ... The second part is that the routes > didn't get widthdrawn correctly - they still existed in various parts of > the Internet some 24 hours after B disconnected itself from the Internet.] > > Right, and this was the part I found most interesting. Of course, I'd claim > that failures like this are almost inevitable in DV type systems! :-) This was a failure in the propogation of the routing information - such failures can happen in DV or MP or any routing system. --asp@partan.com (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Wed Apr 30 05:37:20 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA23392; Wed, 30 Apr 1997 05:37:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA14787; Wed, 30 Apr 1997 05:36:01 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14781; Wed, 30 Apr 1997 05:32:49 +1000 Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA18301; Wed, 30 Apr 1997 05:32:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07733; Tue, 29 Apr 97 15:29:56 -0400 Date: Tue, 29 Apr 97 15:29:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9704291929.AA07733@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, tli@jnx.com Subject: Re: Autonomous System Sanity Protocol Cc: RADIA_PERLMAN@novell.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li > see my message about how that's more efficient, in practise, in > an MD system Sorry, I read your messgae. I found nothing there that says squat about that. Well, here's a high-level look at the issue of which is more efficient when you want to secure them. It's a characteristic of MD systems, as opposed to DV systems, that they i) ship less data around, and ii) use more local computational resources. This makes sense, since DV uses a distributed algorithm for doing path-selection, wheras MD doesn't; it uses multiple local algorithms. So, you expect DV to both i) ship more information around, as partial results of the distributed algorithm, and ii) use less local computational resources. However, this tradeoff comes back to bite you when you want to secure the two architectures. Data that comes in from the net you have to verify - whereas you can generally trust your local computations not to be subverted. So, the general characteristics of DV work against it when you want to secure such a system, in that you have to add security overhead to the thing it uses a lot of, i.e. communication outside the box. OTOH, MD systems use sparingly the thing you have to secure. I don't see any point to repeating the details all over again; if it's not already obvious that the single (well, it may be two, if a router-router link fails), small, connectivity updates generated in MD systems when a topology change occurs almost *has* to be less data than a number of (and potentially very numerous) routing table entries generated by a DV system, I don't know what else to say. Second order effects like each routing table update in a path vector system being potentially even more expensive to process due to the need to check each element in the path, we can leave for now - I'mm still puzzling over the conflicting interaction between i) the ability to cache previous results, and ii) the desire to protect against replays (see my recent message to Steve Kent on the IETF list). > But this is all just intellectual fun - fixing any DV system is a waste > of time, I think. So much for dealing with reality. Call me when you return to earth, eh? Our opinions differ as to the utility of further work on DV and MD approaches. Also, I don't feel any to deride people who can't understand that DV is a dead end. I wish everyone could see it as plainly as I (and others) do, but I don't knwo what else I can do except patiently keep explaining it. On a side note, until quite recently, I used to get very upset when I saw people in the IETF (and predecessors) doing something that I just *knew* was technically ill-advised, (e.g. IPv6), but I've come to understand that it doesn't do any good to bang my head on the wall, or get upset about it. It doesn't do anyone any good, least of all me. I just have to be patient and wait. Noel From owner-Big-Internet@munnari.OZ.AU Wed Apr 30 05:56:21 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA11682; Wed, 30 Apr 1997 05:56:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA14836; Wed, 30 Apr 1997 05:56:01 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14818; Wed, 30 Apr 1997 05:50:27 +1000 Received: from merit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA20898; Wed, 30 Apr 1997 05:50:21 +1000 (from wsimpson@greendragon.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm047-10.dialip.mich.net [141.211.6.52]) by merit.edu (8.8.5/8.8.5) with SMTP id PAA07237 for ; Tue, 29 Apr 1997 15:50:16 -0400 (EDT) Date: Tue, 29 Apr 97 19:08:10 GMT From: "William Allen Simpson" Message-Id: <5759.wsimpson@greendragon.com> To: big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol Precedence: bulk Unfortunately, connectivity was down all weekend to morningstar (until monday afternoon), and all these messages have been propagating to my mailbox all night.... Catching up: > From: Andrew Partan > > [The problem came in two parts. ... The second part is that the routes > > didn't get widthdrawn correctly - they still existed in various parts of > > the Internet some 24 hours after B disconnected itself from the Internet.] > > > > Right, and this was the part I found most interesting. Of course, I'd claim > > that failures like this are almost inevitable in DV type systems! :-) > > This was a failure in the propogation of the routing information > - such failures can happen in DV or MP or any routing system. > One of the features of securing the routing information would be to prevent these software bugs in the first place. In this case, the bad routes would not have been believed, and therefore not propagated. The bugs would have been detected much sooner (before shipping), as simple tests would have prevented any routing from occuring. An ounce of prevention is worth a pound of cure. And I agree with Noel, these particular forms of bug (bogus announcement with truncated path, and failure to withdraw) were both more likely to occur with DV style propagation. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Wed Apr 30 05:57:38 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA18747; Wed, 30 Apr 1997 05:57:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA14860; Wed, 30 Apr 1997 05:57:28 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14820; Wed, 30 Apr 1997 05:50:29 +1000 Received: from merit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA22295; Wed, 30 Apr 1997 05:50:24 +1000 (from wsimpson@greendragon.com) Received: from Bill.Simpson.DialUp.Mich.Net (pm047-10.dialip.mich.net [141.211.6.52]) by merit.edu (8.8.5/8.8.5) with SMTP id PAA07240 for ; Tue, 29 Apr 1997 15:50:18 -0400 (EDT) Date: Tue, 29 Apr 97 19:17:18 GMT From: "William Allen Simpson" Message-Id: <5760.wsimpson@greendragon.com> To: big-internet@munnari.OZ.AU Subject: Re: Autonomous System Sanity Protocol Precedence: bulk > From: Tony Li > Date: 26 Apr 1997 18:54:18 -0700 > Exactly so. What's truly needed is a delegation of authority to advertise > prefixes. We'd also need a means of verifying that authority. What Radia > describes is sufficient to guarantee that the path advertised matches > reality, which is necessary if we're out to secure the protocol against > liars and bad guys. > > However, if we assume that the basic protocol machinery is correct and are > out to protect us against ourselves, the delegation problem is the correct > one to solve. Note that any practical solution probably requires some type > of key management solution already deployed. One then needs to be able to > see a hierarchy of signed and trusted address space delegations. > I was with you right up to that last statement. I posit that in protecting against "liars and bad guys", we also protect "us against ourselves" by _ensuring_ that the basic machinery is correct. I see no use at all for "signed and trusted address space delegations." The delegation we need is from address space _TO_ AS (or router in the AS, or confederation, or abstraction area, or what-have-you). That is a delegation of "routing authority" rather than of prefix heirarchy. My thought is that the current DNS Security model does not do this cleanly, but I may be missing something. Simple Public Key Infrastructure (SPKI) has a delegation of authority model as its basis. How hard would it be to map SPKI or SDSI delegations of routing authority into DNS-Sec for the inverse address mapping? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 From owner-Big-Internet@munnari.OZ.AU Wed Apr 30 23:57:39 1997 Return-Path: Received: from murtoa.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id NA21616; Wed, 30 Apr 1997 23:57:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA15783; Wed, 30 Apr 1997 23:56:27 +1000 Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA15766; Wed, 30 Apr 1997 23:52:40 +1000 Received: from linux.silkroad.com by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id NA22252; Wed, 30 Apr 1997 23:52:36 +1000 (from bass@linux.silkroad.com) Received: (from bass@localhost) by linux.silkroad.com (8.7.3/8.6.9) id JAA24174; Wed, 30 Apr 1997 09:52:04 -0400 From: Tim Bass Message-Id: <199704301352.JAA24174@linux.silkroad.com> Subject: Re: Autonomous System Sanity Protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 30 Apr 1997 09:52:04 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, tli@jnx.com, RADIA_PERLMAN@novell.com, big-internet@munnari.OZ.AU In-Reply-To: <9704291929.AA07733@ginger.lcs.mit.edu> from "Noel Chiappa" at Apr 29, 97 03:29:56 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk Noel> (and predecessors) doing something that I just *knew* was technically Noel> ill-advised, (e.g. IPv6), but I've come to understand that it doesn't do any Noel> good to bang my head on the wall, or get upset about it. It doesn't do anyone Noel> any good, least of all me. I just have to be patient and wait. Just a suggestion, Noel. The world would greatly benefit by a very detailed technical book written by you (and others) . A book that completely documents your knowledge base. IMHO., you could move on to the 'next level' of the issue; and the 'world' would have a chance to catch up. Then your 'head banging' could be transformed into 'key banging'..... explaining to the more pedestrian engineers the nuts and bolts of your intellect. My guess is (apologies for the tacit barb) ... if Einstein could convince the world the value of relativity physics, then is it possible to move beyond 'banging heads' on scalable routing on a global scale. Best Regards, Tim