Re: Autonomous System Sanity Protocol

Noel Chiappa <jnc@ginger.lcs.mit.edu> Mon, 28 April 1997 16:08 UTC

Received: from cnri by ietf.org id aa06868; 28 Apr 97 12:08 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa12941; 28 Apr 97 12:08 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA13102; Tue, 29 Apr 1997 01:57:58 +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 1997 11:54:37 -0400
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
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 <tli@jnx.com>

    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