Mailing List Archive

On May 1, 2012, at 4:34 AM, Dobbins, Roland wrote:
> On Apr 28, 2012, at 5:05 AM, Paul Vixie wrote:
>> is anybody taking it seriously?
> It's hard to take seriously any proposal which is predicated upon recursive dependencies.

Do you mean the need to be able to use rsync to fetch the data to enable you to use rsync?
Or the need to be able to use bittorrent to fetch the data to enable you to use bittorrent?
Or the need to be able to use the DNS to fetch the data to enable you to use the DNS?

Regards,
-drc

On Mon, 30 Apr 2012 11:46:06 -0400
Randy Bush <randy@psg.com> wrote:

> > We need more flexible, distributed architecture behind - no matter -
> > which interests will be lobbied as we have got already.
>
> as i agree that there is a problem, i *very* eagerly await your
> proposal

As Radia says in her book, we're probably stuck with BGP forever, but I
frequently wonder if she is right in suggesting we could have done
better by having a link state protocol instead. It trades some set of
problems for another, but I don't find the dread this might instill
reason enough to avoid putting some research effort into it.

John

On May 1, 2012, at 8:18 PM, David Conrad wrote:

> Do you mean the need to be able to use rsync to fetch the data to enable you to use rsync?

A lot more than just rsync is necessary in order to allow rsync transactions to work. But, you know this already.

;>

> Or the need to be able to use bittorrent to fetch the data to enable you to use bittorrent?

A lot more than just BitTorrent is necessary in order to allow BitTorrent transactions to work. But, you know this already.

;>

> Or the need to be able to use the DNS to fetch the data to enable you to use the DNS?

A lot more than just DNS is necessary in order to allow DNS transactions to work - in this context, I'm specifically referring to routing.

But, you know this already, too.

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Luck is the residue of opportunity and design.

-- John Milton

On May 1, 2012, at 10:31 PM, John Kristoff wrote:

> As Radia says in her book, we're probably stuck with BGP forever, but I frequently wonder if she is right in suggesting we could have done
> better by having a link state protocol instead.

At the time, link-state protocols weren't practical for the scale required - even today, it would be problematic.

Ideally, this would be very nice, but I just don't think it's practical, even today.

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Luck is the residue of opportunity and design.

-- John Milton

Roland,

On May 1, 2012, at 8:49 AM, Dobbins, Roland wrote:
> On May 1, 2012, at 8:18 PM, David Conrad wrote:
>>> It's hard to take seriously any proposal which is predicated upon recursive dependencies.
>> Do you mean the need to be able to use [X] to fetch the data to enable you to use [X]?
> A lot more than just [X] is necessary in order to allow [X] transactions to work.
> ... - in this context, I'm specifically referring to routing.

So, you're saying that the entire RPKI+BGPSEC effort is hard for you to take seriously. OK.

Regards,
-drc

> Yes, recursive dependencies are an issue. I'm really surprised that folks are even seriously considering something like this, but OTOH, this sort of thing keeps cropping up in various contexts from time to time, sigh.

There are only a couple of ways to get past recursive dependencies.

You could simply carry everything in one protocol. This really isn't
practical.

You could develop an overlay protocol that carries the additional
information, so that internal routing is all that's needed to get to the
information you need to build external routing. We already have this, to
some degree today, with IGP/BGP.

You could design a system where most service providers who are likely to
be an upstream would be able to hold the information to kick start a
peer or customer's external routing, so the peer or customer only needs
a default to the upstream to get what they need.

#2 is the most desirable overall, but #3 is what we're most likely to
wind up with in the real world, for various reasons. And I don't know
that #3 is a bad result. There are situations where it won't work
(mostly thinking high mobility environments, or complete system
failures), but these don't seem to be big "stoppers," to me....

But again, here is something that should be brought into the
requirements process in the IETF and discussed as fully as possible, and
then that discussion recorded in a requirements document. AFAIK, it's
never really been discussed seriously, with all the options, advantages,
and disadvantages, enumerated and considered.

Russ

--
<><
riwhite@verisign.com
russw@riw.us

On Sun, 2012-04-29 at 21:50 +0100, Nick Hilliard wrote:
> - the RIPE NCC is now funding a project for which there is no
> consensus policy supported by the RIPE community, and is doing this on
> the basis of a hair's breath majority vote amongst its membership.

Not only were the vote extremely narrow, a whopping ~97% of the voters
did not vote at all.

If we incorporate the no-shows, the vote statistics becomes something
like:

120 Yes
114 No
26 Abstain
~7400 No-shows

The membership got a chance to speak on the topic and largely didn't.

Best,
Martin

On May 2, 2012, at 12:46 AM, Russ White wrote:

> There are situations where it won't work (mostly thinking high mobility environments, or complete system failures), but these don't seem to be big "stoppers," to me....

Within the next 10 years, everything/everywhere is going to become a 'high-mobility environment', though . . .

<https://files.me.com/roland.dobbins/c07vk1>

;>

-----------------------------------------------------------------------
Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Luck is the residue of opportunity and design.

-- John Milton

more "threads from the crypt" as i catch up to 6000 missed nanog posts.

"Dobbins, Roland" <rdobbins@arbor.net> writes:

> On Apr 28, 2012, at 5:17 PM, Saku Ytti wrote:
>
>> People might scared to rely on DNS on accepting routes, but is this
>> really an issue?
>
> Yes, recursive dependencies are an issue. I'm really surprised that
> folks are even seriously considering something like this, but OTOH, this
> sort of thing keeps cropping up in various contexts from time to time,
> sigh.

so, first, i think you mean circular dependencies not recursive dependencies.

second, i'd agree that that's probably bad engineering.

third, rsync's dependencies on routing (as in the RPKI+ROA case) are not
circular (which i think was david conrad's point but i'll drag it to here.)

my reason for not taking ROVER seriously is that route filter preparation
is an essentially offline activity -- you do it from a cron job not "live".
and to do this you have to know in advance what policy data is available
which may or may not have the same coverage as "the routes you will receive
between one cron job and the next".

we could in other words use DNS to store route policy data if we wanted to
use a recursive zone transfer of all policy zones, as a replacement for
rsync. (but why would we do this? we have rsync, which worked for IRR data
for many years.)

ROVER expects that we will query for policy at the instant of need. that's
nuts for a lot of reasons, one of which is its potentially and unmanageably
circular dependency on the acceptance of a route you don't know how to
accept or reject yet.

my take-away from this thread is: very few people take RPKI seriously, but
even fewer take ROVER seriously.

--
Paul Vixie
KI6YSY

On May 28, 2012, at 1:59 PM, Paul Vixie wrote:
> third, rsync's dependencies on routing (as in the RPKI+ROA case) are not
> circular (which i think was david conrad's point but i'll drag it to here.)

Nope. My point was that anything that uses the Internet to fetch the data (including rsync) has a circular dependency on routing. It's just a question of timing.

> ROVER expects that we will query for policy at the instant of need.

Might want to review https://ripe64.ripe.net/presentations/57-ROVER_RIPE_Apr_2012.pdf, particularly the slide entitled "Avoid a Cyclic Dependency".

As far as I can tell, ROVER is simply Yet Another RPKI Access Method like rsync and bittorrent with its own positives and negatives.

Regards,
-drc

On 5/28/2012 9:42 PM, David Conrad wrote:
> On May 28, 2012, at 1:59 PM, Paul Vixie wrote:
>> third, rsync's dependencies on routing (as in the RPKI+ROA case) are not
>> circular (which i think was david conrad's point but i'll drag it to here.)
> Nope. My point was that anything that uses the Internet to fetch the data (including rsync) has a circular dependency on routing. It's just a question of timing.

when you say it's a question of timing, i agree, but then i think you
won't agree again. in batch mode i can express a policy that's true from
that moment forward until removed. in real time mode i have to be able
to express a policy which is both valid and reachable at the moment of
validation. that's a question of timing but the word "just" as in "just
a question of timing" trivializes a galaxy-sized problem space.

>
>> ROVER expects that we will query for policy at the instant of need.
> Might want to review https://ripe64.ripe.net/presentations/57-ROVER_RIPE_Apr_2012.pdf, particularly the slide entitled "Avoid a Cyclic Dependency".

i read it. this is also what draft-gersch-grow-revdns-bpg says. this
makes for a "fail open" design -- the only thing the system can reliably
tell you is "reject". this precludes islands of, or a mode of, "fail
closed". while i don't consider a mode of "fail closed" to be
practically likely, i'd like to preserve the fig leaf of theoretical
possibility. (and the more likely possibility that islands of "fail
closed" could be sewn in.)

> As far as I can tell, ROVER is simply Yet Another RPKI Access Method like rsync and bittorrent with its own positives and negatives.

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, where that order is nowhere defined, and is in any
event uncontrollable.

rsync's punt of the ordering problem is batch mode with policy start
times rather than policy valid instants. to my mind anyone who doesn't
punt the ordering problem has to instead solve it. rover does neither.

paul

On Mon, May 28, 2012 at 10:01:59PM +0000,
paul vixie <vixie@isc.org> wrote
a message of 37 lines which said:

> 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. So, DNSSEC is doomed :-)

On Mon, May 28, 2012 at 08:59:28PM +0000,
Paul Vixie <vixie@isc.org> wrote
a message of 43 lines which said:

> ROVER expects that we will query for policy at the instant of
> need. that's nuts for a lot of reasons, one of which is its
> potentially and unmanageably circular dependency on the acceptance
> of a route you don't know how to accept or reject yet.

If someone starts to announce 2001:db8:f00::/48 *and* all the name
servers for 0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa are in 2001:db8:f00::/48,
then I suggest that he is wrong, not Rover...

On 5/29/2012 10:27 AM, Stephane Bortzmeyer wrote:
> On Mon, May 28, 2012 at 10:01:59PM +0000,
> paul vixie <vixie@isc.org> wrote
> a message of 37 lines which said:
>
>> 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".

> So, DNSSEC is doomed :-)

i hope not. if we had to start over on something that can protect the
cache against trivial pollution and also enable new applications like
DANE, we'd be ten years from first prototype instead of ten years from
ubiquity.

paul

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.

Regards,
-drc

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.)

-Alex

>>>>> 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

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.

> 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.)

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.

I agree with the person higher up the thread that ROVER seems like
just another distribution mechanism for what is essentially RPKI data.

--Richard

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.
>>>>
>>>> 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
>
> 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.

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.)
>
> 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

>>> 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
>>
>> 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.
>
> 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.

Oh, ok sure. The validation outcomes with full data will be different
than with partial data. But that's why the "unknown" state is there
-- as there's more data, things move from "unknown" to
"valid/invalid".


>>> 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.)
>>
>> 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?

From what little I know, it seems to me that ROVER is optimized for
point queries, rather than bulk data access. Which is the opposite of
making it easy to get full data :)

--Richard

On May 29, 2012, at 8:23 AM, Alex Band wrote:
> 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.

I think I now understand concerns about scaling... :-)

Regards,
-drc

On 2012-05-29 5:37 PM, Richard Barnes wrote:
>>> I agree with the person higher up the thread that ROVER seems like
>>> just another distribution mechanism for what is essentially RPKI data.

noting, that up-thread person also said "i havn't studied this in detail
so i'm probably wrong."

>> But does that distribution method easily allow you to get the full set of available data?
> >From what little I know, it seems to me that ROVER is optimized for
> point queries, rather than bulk data access. Which is the opposite of
> making it easy to get full data :)

that's close to the problem but it is not the problem.

RPKI is a catalogue. it's possible to fetch all of the data you could
need, before starting what's basically the "batch job" of computing the
filters you will use at BGP-reception-time to either accept or ignore an
incoming route. if your "fetch and recompute" steps don't work, then
you'll have to continue filtering using stale data. if that data becomes
too stale you're likely to have to turn off the filtering until you can
resynchronize.

ROVER is not a catalogue. it's impossible to know what data you could
need to precompute any route filters, and it's impossible to know what
'all possible rover data' is -- in fact that would be a nonsequitur. you
could i suppose query for every possible netblock (of every possible
size) but that's an awful lot of queries and you'd have to do it every
day in order to see new stuff or to know when to forget old stuff.

the problem is in time domain bounding of data validity and data
reachability. ROVER expects you to be able to query for the information
about a route at the time you receive that route. that's point-in-time
validity and reachability, which you might not have depending on where
the DNS servers are and what order you're receiving routes in. RPKI+ROA
expects you to have periodic but complete access to a catalogue, and
then your future use of the data you fetched has only the risk of
staleness or invalidity, but never reachability.

as others have stated, there is no reference collection of bad ideas.
otherwise we would have written this one up in 1996 when a couple of dns
people looked at the routing system and said 'hey what about something
like [ROVER]?' and the routing people explained in detail why it
wouldn't work.

paul

http://www.cafepress.com/nxdomain/8592477

randy, who will be wearing his at nanog

> http://www.cafepress.com/nxdomain/8592477
> randy, who will be wearing his at nanog

oops! should acknowledge that it was a gracious gift from geoff, to
whom i had introduced http://sugru.com/ the hacker's playdough

randy

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

Paul,

On May 29, 2012, at 8:44 PM, Paul Vixie wrote:
> On 2012-05-29 5:37 PM, Richard Barnes wrote:
>>>> I agree with the person higher up the thread that ROVER seems like
>>>> just another distribution mechanism for what is essentially RPKI data.
>
> noting, that up-thread person also said "i havn't studied this in detail
> so i'm probably wrong."
>
>>> But does that distribution method easily allow you to get the full set of available data?
>>> From what little I know, it seems to me that ROVER is optimized for
>> point queries, rather than bulk data access. Which is the opposite of
>> making it easy to get full data :)
>
> that's close to the problem but it is not the problem.
>
> RPKI is a catalogue. it's possible to fetch all of the data you could
> need, before starting what's basically the "batch job" of computing the
> filters you will use at BGP-reception-time to either accept or ignore an
> incoming route. if your "fetch and recompute" steps don't work, then
> you'll have to continue filtering using stale data. if that data becomes
> too stale you're likely to have to turn off the filtering until you can
> resynchronize.
>
> ROVER is not a catalogue. it's impossible to know what data you could
> need to precompute any route filters, and it's impossible to know what
> 'all possible rover data' is -- in fact that would be a nonsequitur. you
> could i suppose query for every possible netblock (of every possible
> size) but that's an awful lot of queries and you'd have to do it every
> day in order to see new stuff or to know when to forget old stuff.
>
> the problem is in time domain bounding of data validity and data
> reachability. ROVER expects you to be able to query for the information
> about a route at the time you receive that route. that's point-in-time
> validity and reachability, which you might not have depending on where
> the DNS servers are and what order you're receiving routes in. RPKI+ROA
> expects you to have periodic but complete access to a catalogue, and
> then your future use of the data you fetched has only the risk of
> staleness or invalidity, but never reachability.
>
> as others have stated, there is no reference collection of bad ideas.
> otherwise we would have written this one up in 1996 when a couple of dns
> people looked at the routing system and said 'hey what about something
> like [ROVER]?' and the routing people explained in detail why it
> wouldn't work.

Just one correction to the above. As pointed out in Section 4 of draft-gersch-grow-revdns-bgp-00 "near-real-time route origin verification" is merely one instantiation of the "ROVER concept". Please refer to that section for other potential uses of such published data.

I would also ask people to expand their minds beyond the "it must have a (near-)real-time mechanism" directly coupled to the Control Plane" for a variety of reasons. Such a tight coupling of /any/ two systems inevitably, and unfortunately, will only fail at scale in ways that likely would never have been predicted a priori[1] -- unfortunately, you only learn this lesson afterward. Question is: how quickly can you detect and react to unwind the specific problem w/out having to turn it off completely, (i.e.: "shields down")? Alternatively, is it more prudent to engineer some 'sanity' safeguards, (i.e.: back away from the 'real-time' aspect), to avoid this from happening at all or at least extremely rarely?

-shane

[1] FWIW, Dave Meyer has been doing some thinking about "complexity" for a while now, drawing analogies from outside of networking/computing, and has some fascinating insight. I'm sure if there's enough interest, he'd be willing to discuss it. Who knows, we may even learn something. :-)