[153077] in North American Network Operators' Group
Re: rpki vs. secure dns?
daemon@ATHENA.MIT.EDU (Alex Band)
Tue May 29 13:06:19 2012
From: Alex Band <alexb@ripe.net>
In-Reply-To: <CACB24MsJqJRV18wgZF8X9_9Gu1vWR0kt0-p+sjs4k8-rssV3Ww@mail.gmail.com>
Date: Tue, 29 May 2012 19:05:01 +0200
To: Richard Barnes <richard.barnes@gmail.com>
Cc: paul vixie <vixie@isc.org>, nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On 29 May 2012, at 18:33, Richard Barnes 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
>>>> 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
> I wouldn't read that as saying that the RPKI requires you to have full
> data in order to provide any benefit. Where sufficient certs and ROAs
> exist to validate an announcement, you can mark it valid/invalid --
> just like ROVER, but with a harder failure case.
I don't mean that you need ROAs describing every route announcement in =
existence for it to be useful.=20
What I mean is for an operator to determine if a route announcement is =
RPKI valid, invalid or unknown, they will need *all* ROAs that *have =
been created*. If they miss a ROA in the data set during the fetching =
process, a route can end up with the incorrect validity state. See my =
example.
>> 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.)
>=20
> Of course, there's a reason that an announcement that contradicts a
> ROA is marked as invalid [RFC6483]. Such announcements are hijacks,
> the attacks that the RPKI is designed to prevent. If ROVER doesn't
> provide a hard fail here, then it would seem to not be providing much
> security benefit.
That does seem the case. I don't think ROVER provides a hard fail. Can =
someone confirm?
> I agree with the person higher up the thread that ROVER seems like
> just another distribution mechanism for what is essentially RPKI data.
But does that distribution method easily allow you to get the full set =
of available data?
-Alex
