Re: Autonomous System Sanity Protocol

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

Received: from cnri by ietf.org id aa05542; 28 Apr 97 11:45 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa12482; 28 Apr 97 11:45 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA12970; Tue, 29 Apr 1997 01:38:00 +1000
Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12927; Tue, 29 Apr 1997 01:29:54 +1000
Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA08428; Tue, 29 Apr 1997 01:29:52 +1000 (from jnc@ginger.lcs.mit.edu)
Received: by ginger.lcs.mit.edu id AA29543; Mon, 28 Apr 97 11:29:44 -0400
Date: Mon, 28 Apr 1997 11:29:44 -0400
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Message-Id: <9704281529.AA29543@ginger.lcs.mit.edu>
To: big-internet@munnari.oz.au
Subject: Re: Autonomous System Sanity Protocol
Cc: jnc@ginger.lcs.mit.edu
Precedence: bulk

    From: Tony Li <tli@jnx.com>

    > If each router signs its path to D, then when router R chooses among
    > the routes given by each of its neighbors, it chooses one, and can
    > preserve that neighbor's signature, and then add its own.

    What's truly needed is a delegation of authority to advertise prefixes.

Yes. (But see my message about how that's more efficient, in practise, in
an MD system! :-)

    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.

Uhh, not quite. As I pointed out in a previous message, there's nothing to
stop someone taking the path X->Y->Z, signed at each stage, and stripping off
some elements and sending out what looks like a perfectly legitimate X->P.

However, I think I have come up with a way of signing routes to prevent
stripping by downstream sites, but I want to run it by some security whizzes
before I say more.

(Of course, to the extent that P can open a direct TCP connection to X, and
get it's database, this is a way of avoiding that. A fix would be to modify
BGP so it will only give signed routes to routers to which it has a direct
connection - and do so in a way which *includes* the next-hop router in the
signed route the NHR gets, to prevent the NHR collaborating with someone
else to give them a partial route.)

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


	Noel