Re: ROVER routing security - its not enumeration

[Doug Montgomery <dougm.tlist () gmail com>]

On 6/10/12 5:53 PM, "Paul Vixie" <vixie () isc org> wrote:

> Doug Montgomery <dougm.tlist () gmail com> writes:
>
> > > ...
> >
> > I think we debate the superficial here, and without sufficient
> > imagination.
> > The enumerations vs query issue is a NOOP as far as I am concerned.
> > With
> > a little imagination, one could envision building a box that takes a
> > feed
> > of prefixes observed, builds an aged cache of prefixes of interest,
> > queries
> > for their SRO records, re queries for those records before their TTLs
> > expire, and maintains a white list of "SRO valid" prefix/origin pairs
> > that
> > it downloads to the router.
>
> this sounds like a steady state system. how would you initially populate
> it,
> given for example a newly installed core router having no routing table
> yet?
>
> if the answer is, rsync from somewhere, then i propose, rsync from RPKI.
>
> if the answer is, turn off security during bootup, then i claim, bad idea.

Well, I should probably let the ROVER guys say what they have in mind.

The above started from my imagination that if you did not want routers
actually doing route-by-route queries, that it would be easy to build a
validating cache that behaves similar to a RPKI validating cache, but
pulling the info from rDNS as opposed to RPKI.

Maybe the ROVER guys have something else in mind (e.g., routers doing the
queries themselves, some other model of how the info ... Or its impacts
... Is effected on the router).

IFF you do imagine that there is a SRO validating cache box - you can
decompose the question of how one solves state skew between (1) rtr and
cache, (2) cache and info authoritative source, and (3) how new
authoritative information gets globally distributed/effected in the system.

Looking at just (1) (your question I think), we have a couple of different
questions to look at.

a. How does a router with no origin info (new router, router reboot),
synchronize with the cache (assuming the cache has state).

The current machinery of rtr-to-cache would work fine here.  Might need to
add a bit or two, but the basic problem is the same.

b. How does a cache with no state, build a list of prefix-origin pairs?
Clearly if one builds a SRO validating cache box, the usual techniques of
checkpointing state, having redundant cache's etc could be used ... But at
some level the question of having to get initial state, and what the
router does during that period (assuming that the stateless cache is his
only source) must be answered.

One way of thinking about these questions, is to ask how would it work in
RPKI?

If for origin validation we have a strict "don't fail open" during resets
requirement, then there are a lot of initialization questions we must
address in any system.  I.e., what does the router do, if its only RPKI
cache has to rebuild state from zero?  What does such a router do if it
looses contact with its cache?
 
At this point, I could propose more ideas, but probably going further with
my imagination is not important. The ROVER guys should tell us what they
have in mind, or someone interested in building a ROVER validating cache
should design one and tell us.

But maybe stepping back one level of abstraction, you can think of things
this way.

We have a top-down-enumeration vs query model.  One could put a cache in
the the query model to make it approximate an enumeration model, but only
to the point that one has, or can build a reasonably complete, list of
prefixes of interest.

If one admits that sometimes there will be cache misses (in the
query/cache model) and one might have to query in those cases, then the
trade off seems to be how often that occurs vs the responsiveness one
would get out of such a system for situations when the authoritative
information itself changes (case 3 above).  I.e., how fast could you turn
up a new prefix in each system?

Maybe the ROVER guys don't believe in caches at all.  In which case I
return you to the original "OMG! Enumeration vs Query thread".

I just don't think that is the most significant difference between the two
approaches.  

dougm


> > ...
> >
> > Point being, with a little imagination I think one could build
> > components
> > with either approach with similar  black box behavior.
>
> i don't think so. and i'm still waiting for a network operator to say what
> they think the merits of ROVER might be in comparison to the RPKI
> approach.
> (noting, arguments from non-operators should and do carry less weight.)
>
> -- 
> Paul Vixie
> KI6YSY