Re: Autonomous System Sanity Protocol

William Allen Simpson <> Tue, 29 April 1997 20:05 UTC

Received: from cnri by id aa11353; 29 Apr 97 16:05 EDT
Received: from by CNRI.Reston.VA.US id aa18727; 29 Apr 97 16:05 EDT
Received: from mailing-list by (8.6.9/1.0) id FAA14872; Wed, 30 Apr 1997 05:58:02 +1000
Received: from munnari.OZ.AU by (8.6.9/1.0) with SMTP id FAA14820; Wed, 30 Apr 1997 05:50:29 +1000
Received: from by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA22295; Wed, 30 Apr 1997 05:50:24 +1000 (from
Received: from Bill.Simpson.DialUp.Mich.Net ( []) by (8.8.5/8.8.5) with SMTP id PAA07240 for <big-internet@munnari.OZ.AU>; Tue, 29 Apr 1997 15:50:18 -0400 (EDT)
Date: Tue, 29 Apr 97 19:17:18 GMT
From: William Allen Simpson <>
Message-Id: <>
Subject: Re: Autonomous System Sanity Protocol
Precedence: bulk

> From: Tony Li <>
> Date: 26 Apr 1997 18:54:18 -0700
> Exactly so.  What's truly needed is a delegation of authority to advertise
> prefixes.  We'd also need a means of verifying that authority.  What Radia
> describes is sufficient to guarantee that the path advertised matches
> reality, which is necessary if we're out to secure the protocol against
> liars and bad guys.
> However, if we assume that the basic protocol machinery is correct and are
> out to protect us against ourselves, the delegation problem is the correct
> one to solve.  Note that any practical solution probably requires some type
> of key management solution already deployed.  One then needs to be able to
> see a hierarchy of signed and trusted address space delegations.
I was with you right up to that last statement.

I posit that in protecting against "liars and bad guys", we also protect
"us against ourselves" by _ensuring_ that the basic machinery is correct.

I see no use at all for "signed and trusted address space delegations."

The delegation we need is from address space _TO_ AS (or router in the
AS, or confederation, or abstraction area, or what-have-you).  That is a
delegation of "routing authority" rather than of prefix heirarchy.

My thought is that the current DNS Security model does not do this
cleanly, but I may be missing something.  Simple Public Key
Infrastructure (SPKI) has a delegation of authority model as its basis.

How hard would it be to map SPKI or SDSI delegations of routing
authority into DNS-Sec for the inverse address mapping?
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2