Re: rpki vs. secure dns?

[Shane Amante <shane () castlepoint net>]

Alex,

First, I would note that there is a talk specifically on this subject coming up at NANOG 55, which is scheduled for 
Tuesday afternoon from 2:30 - 3 PM.  (Note, I'm not giving the talk, just pointing out that your questions may best be 
followed up face-to-face then).  Anyway, see below.

On May 29, 2012, at 9:23 AM, Alex Band wrote:
> On 29 May 2012, at 16:21, David Conrad wrote:
>
> > On May 29, 2012, at 4:02 AM, paul vixie 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
>
> 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.)

Actually, I believe it does.  Specifically, there are two types of DNS RR's:
a)  RLOCK: Route Lock
b)  SRO: Secure Route Origin
Please refer to the following URL for definitions of each: 
<http://tools.ietf.org/html/draft-gersch-grow-revdns-bgp-00#section-3>.

In short, an RLOCK is applied to a covering aggregate to indicate that each announcement at and more-specific to that 
covering aggregate require an SRO RR to be considered "Valid".  To re-frame your example above:

10.0.0.0/16 --
   RLOCK
   SRO AS123

Note, there is no SRO defined at 10.0.1.0/24.

Thus, if/when AS456 comes along and announces 10.0.1.0/24, it should be declared Invalid due to:
a)  A DNSSEC lookup for an SRO RR at 10.0.1.0/24 returns NXDOMAIN;
b)  Subsequent lookups for an RLOCK RR (and SRO RR to get the RLOCK's Origin AS) at a covering aggregate returns a 
positive acknowledgement at 10.0.0.0/16.

Of course, if you want /both/ IP prefixes to be considered Valid, then you would have to also define an SRO RR for the 
more-specific 10.0.1.0/24 as follows:
10.0.1.0/24
    SRO AS456

-shane