It's in-band only in the sense of delivery. The worst that a corruption of the underlying network can do to you is deny you updates; it can't convince you that a route validates when it shouldn't. And even denying updates to your RPKI cache isn't that bad, since the update process doesn't really need to be real-time. Things will stay the same until you start hitting expiration times. The ultimate worst case is that everything expires and there are no RPKI-validated routes ... just like today. --Richard On Mon, Jan 24, 2011 at 9:11 PM, Roland Dobbins <rdobbins@arbor.net> wrote:
On Jan 25, 2011, at 8:59 AM, Danny McPherson wrote:
I just don't like the notion of deploying a brand new system with data that at the end of the day is going to look an awful lot like the existing in-addr.arpa delegation system that's deployed, and introduce new hierarchical shared dependencies that don't exist today.
Right - so, the macro point here is that in order to make use of rPKI so as to ensure the integrity of the global routing system, the presupposition is that there's already sufficient integrity in said routing global system for the rPKI tree to be successfully walked in the first place, given that it's all in-band, right?
And since it's all in-band, anyways, with the recursive dependencies that implies, why not make use of another, pre-existing inband hierarchical system which is explicitly designed to ensure the integrity of its answers, and which is already in the initial stages of its deployment - i.e., DNSSEC?
Note I'm not advocating this position, per se, just being sure I understand the argument for purposes of discussion.
------------------------------------------------------------------------ Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>
Most software today is very much like an Egyptian pyramid, with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.
-- Alan Kay