rpki vs. secure dns?

Wed May 30 03:52:17 UTC 2012

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