Re: rpki vs. secure dns?

[Alex Band <alexb () ripe net>]

On 29 May 2012, at 18:33, Richard Barnes wrote:

> > > > > > i can tell more than that. rover is a system that only works at all
> > > > > > when everything everywhere is working well, and when changes always
> > > > > > come in perfect time-order,
> > > > > Exactly like DNSSEC.
> > > >
> > > > no. dnssec for a response only needs that response's delegation and
> > > > signing path to work, not "everything everywhere".
> > >
> > > My impression was that ROVER does not need "everything, everywhere" to work to fetch the routing information for a 
> > > particular prefix -- it merely needs sufficient routing information to follow the delegation and signing path for 
> > > the prefix it is looking up. However, I'll admit I haven't looked into this in any particular depth so I'm probably 
> > > wrong.
> >
> > RPKI needs the full data set to determine if a BGP prefix has the status 'valid', 'invalid' or 'unknown'. It can't 
> > work with partial data. For example, if you are the holder of 10.0.0.0/16 and you originate the full aggregate from 
> > AS123 and a more specific such as 10.0.1.0/24 from AS456, then you will need a ROA for both to make them both 
> > 'valid'. If you only authorize 10.0.0.0/16 with AS123, then the announcement from AS456 will be 'invalid'. If you 
> > only authorize 10.0.1.0/24 from AS456, the announcement from AS123 will remain 'unknown'.
> >
> > So in RPKI, partial data – so you failed to fetch one of the ROAs in the set – can make something 'invalid' or 
> > 'unknown' that should actually be 'valid'.
> > http://tools.ietf.org/html/rfc6483#page-3
>
> I wouldn't read that as saying that the RPKI requires you to have full
> data in order to provide any benefit.  Where sufficient certs and ROAs
> exist to validate an announcement, you can mark it valid/invalid --
> just like ROVER, but with a harder failure case.

I don't mean that you need ROAs describing every route announcement in existence for it to be useful. 

What I mean is for an operator to determine if a route announcement is RPKI valid, invalid or unknown, they will need 
*all* ROAs that *have been created*. If they miss a ROA in the data set during the fetching process, a route can end up 
with the incorrect validity state. See my example.

> > As far as I know, ROVER doesn't work like that. You can make a positive statement about a Prefix+AS combination, but 
> > that doesn't mark the origination from another AS 'unauthorized' or 'invalid', there merely isn't a statement for 
> > it. (Someone please confirm. I may be wrong.)
>
> Of course, there's a reason that an announcement that contradicts a
> ROA is marked as invalid [RFC6483].  Such announcements are hijacks,
> the attacks that the RPKI is designed to prevent.  If ROVER doesn't
> provide a hard fail here, then it would seem to not be providing much
> security benefit.

That does seem the case. I don't think ROVER provides a hard fail. Can someone confirm?

> I agree with the person higher up the thread that ROVER seems like
> just another distribution mechanism for what is essentially RPKI data.

But does that distribution method easily allow you to get the full set of available data?

-Alex