PKS, and the DV/MD choice...

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

Received: from cnri by ietf.org id aa00911; 28 Apr 97 11:03 EDT
Received: from murtoa.cs.mu.OZ.AU by CNRI.Reston.VA.US id aa11685; 28 Apr 97 11:03 EDT
Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA12879; Tue, 29 Apr 1997 00:56:19 +1000
Received: from munnari.OZ.AU by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA12800; Tue, 29 Apr 1997 00:43:34 +1000
Received: from ginger.lcs.mit.edu by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA04100; Tue, 29 Apr 1997 00:43:32 +1000 (from jnc@ginger.lcs.mit.edu)
Received: by ginger.lcs.mit.edu id AA29183; Mon, 28 Apr 97 10:43:30 -0400
Date: Mon, 28 Apr 1997 10:43:30 -0400
From: Noel Chiappa <jnc@ginger.lcs.mit.edu>
Message-Id: <9704281443.AA29183@ginger.lcs.mit.edu>
To: big-internet@munnari.oz.au
Subject: PKS, and the DV/MD choice...
Cc: jnc@ginger.lcs.mit.edu
Precedence: bulk

	A private note from Mike O'Dell pointed out that checking a PKS
certificate (i.e. something that shows that R1 is in fact allowed to claim
that it is attached to X, Y etc) on every topology update sounded like
something that wasn't going to scale well.
	This in fact turns out to be a key point (and one I hadn't seen, and
a tip of the hatly hat to Mike :-) - because the PKS approach works *far*
better with MD systems than it does with DV! Here's why:

	In an MD system, you should only get updates from R1 when the
topology next to R1 changes (i.e. it's connect to some other router, or a
piece of the nework, changes), and each topology change is *guaranteed* to
send you only a small amount of data (i.e. what R1 is connected to now). I.e.
you don't get all of whatever routing table entries have changed - which
could be a lot of data items, each one of which would have to be checked, in
a DV system - you only get the one small connectivity update from R1.
	You then use that, together with pre-checked data already in your map
(note this, you checked the correctness of that data in the past, when you
first got it, and don't have to do so again now), to do the recomputation of
all the routing table entries locally.
	This is clearly much more tractable than applying PKS to a DV system,
where you'd have to check each routing table entry as it came in, which could
be rather painful after a topology change which caused lots of routes to
change.
	To me, this sounds like a key factor against application of PKS
techniques to a DV system....

	On a more general note, though, you have to balance security and
overhead. Remember the IAB thing on security and the internetwork layer - do
we check every packet to make sure it is authorized, and if so, how expensive
is that going to be? Not sure how that principle plays here...

	Noel