Re: Autonomous System Sanity Protocol
Jeff Young <young@mci.net> Sun, 27 April 1997 14:15 UTC
Received: from ietf.org by ietf.org id aa19431; 27 Apr 97 10:15 EDT
Received: from cnri by ietf.org id aa19046; 27 Apr 97 10:04 EDT
Received: from postoffice.Reston.mci.net by CNRI.Reston.VA.US id aa09004; 27 Apr 97 10:04 EDT
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: Noel Chiappa <jnc@ginger.lcs.mit.edu>
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
Sender: ietf-request@ietf.org
From: Jeff Young <young@mci.net>
Source-Info: From (or Sender) name not authenticated.
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 > > <My apologies to the IETF list for getting into routing grup, but I can't > allow these erroneous statements to go uncorrected.> > > From: Pedro Marques <roque@cisco.com> > > > 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
- 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