Re: Autonomous System Sanity Protocol

Noel Chiappa <jnc@ginger.lcs.mit.edu> Sat, 26 April 1997 18:44 UTC

Received: from cnri by ietf.org id aa26889; 26 Apr 97 14:44 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa12594; 26 Apr 97 14:44 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: Noel Chiappa <jnc@ginger.lcs.mit.edu>
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

<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