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
