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
- PKS, and the DV/MD choice... Noel Chiappa
- Re: PKS, and the DV/MD choice... Christian Huitema
- Re: PKS, and the DV/MD choice... Mathew Lodge
- Re: PKS, and the DV/MD choice... Matt Crawford