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