Re: Autonomous System Sanity Protocol
Noel Chiappa <jnc@ginger.lcs.mit.edu> Mon, 28 April 1997 15:48 UTC
Received: from cnri by ietf.org id aa05757; 28 Apr 97 11:48 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa12579; 28 Apr 97 11:48 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA13025; Tue, 29 Apr 1997 01:40: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 1997 11:20:40 -0400
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
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 <RADIA_PERLMAN@novell.com> > 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
- Re: Autonomous System Sanity Protocol Bill Manning
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol Per Gregers Bilse
- Re: Autonomous System Sanity Protocol Pedro Marques
- Re: Autonomous System Sanity Protocol Tony Li
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol Michael Dillon
- Re: Autonomous System Sanity Protocol RADIA PERLMAN
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol Tony Li
- Re: Autonomous System Sanity Protocol Jeremy Porter
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol Valdis.Kletnieks
- Re: Autonomous System Sanity Protocol Andrew Partan
- Re: Autonomous System Sanity Protocol Tony Li
- Re: Autonomous System Sanity Protocol Jeff Young
- Re: Autonomous System Sanity Protocol Bill Manning
- Re: Autonomous System Sanity Protocol Tony Li
- Re: Autonomous System Sanity Protocol Donald E. Eastlake 3rd
- Re: Autonomous System Sanity Protocol Jon Crowcroft
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol Donald E. Eastlake 3rd
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol Andrew Partan
- Re: Autonomous System Sanity Protocol Noel Chiappa
- Re: Autonomous System Sanity Protocol William Allen Simpson
- Re: Autonomous System Sanity Protocol William Allen Simpson
- Re: Autonomous System Sanity Protocol Tim Bass
- Re: Autonomous System Sanity Protocol Jon Crowcroft