On 2012-05-29 5:37 PM, Richard Barnes wrote:
I agree with the person higher up the thread that ROVER seems like just another distribution mechanism for what is essentially RPKI data.
noting, that up-thread person also said "i havn't studied this in detail so i'm probably wrong."
But does that distribution method easily allow you to get the full set of available data? From what little I know, it seems to me that ROVER is optimized for point queries, rather than bulk data access. Which is the opposite of making it easy to get full data :)
that's close to the problem but it is not the problem. RPKI is a catalogue. it's possible to fetch all of the data you could need, before starting what's basically the "batch job" of computing the filters you will use at BGP-reception-time to either accept or ignore an incoming route. if your "fetch and recompute" steps don't work, then you'll have to continue filtering using stale data. if that data becomes too stale you're likely to have to turn off the filtering until you can resynchronize. ROVER is not a catalogue. it's impossible to know what data you could need to precompute any route filters, and it's impossible to know what 'all possible rover data' is -- in fact that would be a nonsequitur. you could i suppose query for every possible netblock (of every possible size) but that's an awful lot of queries and you'd have to do it every day in order to see new stuff or to know when to forget old stuff. the problem is in time domain bounding of data validity and data reachability. ROVER expects you to be able to query for the information about a route at the time you receive that route. that's point-in-time validity and reachability, which you might not have depending on where the DNS servers are and what order you're receiving routes in. RPKI+ROA expects you to have periodic but complete access to a catalogue, and then your future use of the data you fetched has only the risk of staleness or invalidity, but never reachability. as others have stated, there is no reference collection of bad ideas. otherwise we would have written this one up in 1996 when a couple of dns people looked at the routing system and said 'hey what about something like [ROVER]?' and the routing people explained in detail why it wouldn't work. paul