Re: Autonomous System Sanity Protocol

Jeff Young <> Sun, 27 April 1997 14:15 UTC

Received: from by id aa19431; 27 Apr 97 10:15 EDT
Received: from cnri by id aa19046; 27 Apr 97 10:04 EDT
Received: from by CNRI.Reston.VA.US id aa09004; 27 Apr 97 10:04 EDT
Received: from (marvinthemartian []) by (8.8.5/8.8.5) with ESMTP id KAA28676; Sun, 27 Apr 1997 10:00:03 -0400 (EDT)
Message-Id: <>
To: Noel Chiappa <>
cc:,, 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." <>
Date: Sun, 27 Apr 1997 10:00:02 -0400
From: Jeff Young <>
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

> Return-Path: owner-Big-Internet@munnari.OZ.AU 
> Received: from ( [])
> 	by (8.8.5/8.8.5) with SMTP id PAA20824;
> 	Sat, 26 Apr 1997 15:00:11 -0400 (EDT)
> Received: from mailing-list by (8.6.9/1.0)
> 	id EAA09755; Sun, 27 Apr 1997 04:37:20 +1000
> Received: from munnari.OZ.AU by (8.6.9/1.0) with SMTP
> 	id EAA09734; Sun, 27 Apr 1997 04:29:47 +1000
> Received: from by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56)
> 	id SA04656; Sun, 27 Apr 1997 04:29:45 +1000 (from
> Received: by 
> 	id AA20681; Sat, 26 Apr 97 14:29:41 -0400
> Date: Sat, 26 Apr 97 14:29:41 -0400
> From: (Noel Chiappa)
> Message-Id: <>
> To:,
> Subject: Re: Autonomous System Sanity Protocol
> Cc: big-internet@munnari.OZ.AU,,
> 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 <>
>     > 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