Re: Autonomous System Sanity Protocol

Noel Chiappa <> Tue, 29 April 1997 19:50 UTC

Received: from cnri by id aa11043; 29 Apr 97 15:50 EDT
Received: from by CNRI.Reston.VA.US id aa18436; 29 Apr 97 15:50 EDT
Received: from mailing-list by (8.6.9/1.0) id FAA14799; Wed, 30 Apr 1997 05:39:46 +1000
Received: from munnari.OZ.AU by (8.6.9/1.0) with SMTP id FAA14781; Wed, 30 Apr 1997 05:32:49 +1000
Received: from by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id TA18301; Wed, 30 Apr 1997 05:32:40 +1000 (from
Received: by id AA07733; Tue, 29 Apr 97 15:29:56 -0400
Date: Tue, 29 Apr 97 15:29:56 -0400
From: Noel Chiappa <>
Message-Id: <>
Subject: Re: Autonomous System Sanity Protocol
Precedence: bulk

    From: Tony Li <>

    > see my message about how that's more efficient, in practise, in
    > an MD system

    Sorry, I read your messgae. I found nothing there that says squat about

Well, here's a high-level look at the issue of which is more efficient
when you want to secure them.

It's a characteristic of MD systems, as opposed to DV systems, that they i)
ship less data around, and ii) use more local computational resources. This
makes sense, since DV uses a distributed algorithm for doing path-selection,
wheras MD doesn't; it uses multiple local algorithms. So, you expect DV to
both i) ship more information around, as partial results of the distributed
algorithm, and ii) use less local computational resources.

However, this tradeoff comes back to bite you when you want to secure the two
architectures. Data that comes in from the net you have to verify - whereas
you can generally trust your local computations not to be subverted. So, the
general characteristics of DV work against it when you want to secure such a
system, in that you have to add security overhead to the thing it uses a lot
of, i.e. communication outside the box. OTOH, MD systems use sparingly the
thing you have to secure.

I don't see any point to repeating the details all over again; if it's not
already obvious that the single (well, it may be two, if a router-router link
fails), small, connectivity updates generated in MD systems when a topology
change occurs almost *has* to be less data than a number of (and potentially
very numerous) routing table entries generated by a DV system, I don't know
what else to say.

Second order effects like each routing table update in a path vector system
being potentially even more expensive to process due to the need to check
each element in the path, we can leave for now - I'mm still puzzling over the
conflicting interaction between i) the ability to cache previous results, and
ii) the desire to protect against replays (see my recent message to Steve
Kent on the IETF list).

    > But this is all just intellectual fun - fixing any DV system is a waste
    > of time, I think.

    So much for dealing with reality.  Call me when you return to earth, eh?

Our opinions differ as to the utility of further work on DV and MD approaches.

Also, I don't feel any to deride people who can't understand that DV is a dead
end. I wish everyone could see it as plainly as I (and others) do, but I don't
knwo what else I can do except patiently keep explaining it. On a side note,
until quite recently, I used to get very upset when I saw people in the IETF
(and predecessors) doing something that I just *knew* was technically
ill-advised, (e.g. IPv6), but I've come to understand that it doesn't do any
good to bang my head on the wall, or get upset about it. It doesn't do anyone
any good, least of all me. I just have to be patient and wait.