[153113] in North American Network Operators' Group
Re: rpki vs. secure dns?
daemon@ATHENA.MIT.EDU (Shane Amante)
Tue May 29 23:53:09 2012
From: Shane Amante <shane@castlepoint.net>
In-Reply-To: <276EF4CD-1710-4F71-8728-894C0433286A@ripe.net>
Date: Tue, 29 May 2012 21:52:17 -0600
To: Alex Band <alexb@ripe.net>
Cc: paul vixie <vixie@isc.org>, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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:
>=20
>> 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.=20
>>>=20
>>> no. dnssec for a response only needs that response's delegation and
>>> signing path to work, not "everything everywhere".
>>=20
>> 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.
>=20
> 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'.
>=20
> So in RPKI, partial data =96 so you failed to fetch one of the ROAs in =
the set =96 can make something 'invalid' or 'unknown' that should =
actually be 'valid'.
> http://tools.ietf.org/html/rfc6483#page-3
>=20
> 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=
