Mailing List Archive

On Apr 27, 2012 3:05 PM, "Paul Vixie" <vixie@isc.org> wrote:
>
>
http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem
>
> > "The problem: Border Gateway Protocol (BGP) enables routers to
> > communicate about the best path to other networks, but routers don't
> > verify the route 'announcements.' When routing problems erupt, 'it's
> > very difficult to tell if this is fat fingering on a router or
> > malicious
> > <
http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem
>,'
> > said Joe Gersch, chief operating officer for Secure64, a company that
> > makes Domain Name System (DNS) server software. In a well-known
> > incident, Pakistan Telecom made an error with BGP after Pakistan's
> > government ordered in 2008 that ISPs block YouTube, which ended up
> > knocking Google's service offline
> > <
http://slashdot.org/story/08/02/25/1322252/pakistan-youtube-block-breaks-the-world
>.
> > A solution exists, but it's complex, and deployment has been slow. Now
> > experts have found an easier way."
>
> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?
>

Taking what seriously ? The commitments to rpki you speak off ?

Late is a relative term.

It does not matter if the cat is white or black, as long as it cathes the
rat.

CB

On 04/27/2012 06:05 PM, Paul Vixie wrote:
> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?

first thing that sprung to mind was this:

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

line 408 ff. in the IETF 83 SIDR minutes

* http://www.ietf.org/proceedings/83/minutes/minutes-83-sidr.txt



Cheers
matthias

--
Matthias Waehlisch
. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
. Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

On Fri, 27 Apr 2012, Paul Vixie wrote:

> http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem
>
> > "The problem: Border Gateway Protocol (BGP) enables routers to
> > communicate about the best path to other networks, but routers don't
> > verify the route 'announcements.' When routing problems erupt, 'it's
> > very difficult to tell if this is fat fingering on a router or
> > malicious
> > <http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem>,'
> > said Joe Gersch, chief operating officer for Secure64, a company that
> > makes Domain Name System (DNS) server software. In a well-known
> > incident, Pakistan Telecom made an error with BGP after Pakistan's
> > government ordered in 2008 that ISPs block YouTube, which ended up
> > knocking Google's service offline
> > <http://slashdot.org/story/08/02/25/1322252/pakistan-youtube-block-breaks-the-world>.
> > A solution exists, but it's complex, and deployment has been slow. Now
> > experts have found an easier way."
>
> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?
>
>

* Paul Vixie:

> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?

The idea as such isn't new, this has been floating around for four
years or more, including at least one Internet draft,
draft-donnerhacke-sidr-bgp-verification-dnssec.

I don't know if we can get RPKI to deployment because RIPE and RIPE
NCC have rather serious issues with it. On the other hand, there
doesn't seem to be anything else which keeps RIRs relevant in the
post-scarcity world, so we'll see what happens.

> The idea as such isn't new, this has been floating around for four
> years or more, including at least one Internet draft,
> draft-donnerhacke-sidr-bgp-verification-dnssec.

draft-bates-bgp4-nlri-orig-verif-00.txt was '98

and we dropped it for good reasons

randy

On (2012-04-27 22:05 +0000), Paul Vixie wrote:

> this seems late, compared to the various commitments made to rpki in
> recent years. is anybody taking it seriously?

(disclaimer I'm almost completely clueless on RPKI).

If two fails don't make win, then I think ROVER is better solution, doesn't
need any changes to BGP just little software magic when accepting routes.

People might scared to rely on DNS on accepting routes, but is this really
an issue? I'd anyhow prefer to run verification in 'relaxed' mode, where
routes which fail authorization are logged but accepted if there wasn't
pre-existing covering route. Only drop routes if they fail authorization
_AND_ there is pre-existing covering route.
Maybe after several more years of experience and working out kinks, I could
dare to try to run verification in 'strict' more. But 'relaxed' more
already would stop the real-life problems we've seen of route-hijackings. I
don't care much about unannounced net used for spamming really.

Nick Hilliard mentioned in other forum to me bootstrapping problem. DNS
would then be inherently part of your NMS, so install DNS in your NMS, and
NMS already exists in IGP. So infra for verification should be up, before
BGP is up.

--
++ytti

On 28 Apr 2012, at 11:56, Florian Weimer wrote:

> * Paul Vixie:
>
>> this seems late, compared to the various commitments made to rpki in
>> recent years. is anybody taking it seriously?
>
> The idea as such isn't new, this has been floating around for four
> years or more, including at least one Internet draft,
> draft-donnerhacke-sidr-bgp-verification-dnssec.
>
> I don't know if we can get RPKI to deployment because RIPE and RIPE
> NCC have rather serious issues with it. On the other hand, there
> doesn't seem to be anything else which keeps RIRs relevant in the
> post-scarcity world, so we'll see what happens.

Could you elaborate on what those issues are?

I can't speak for ROVER, but judging from Gersh's talk at RIPE64 and the discussion afterwards, it looks like it's just an old idea that was brought to the table again, with a few early adopters experimenting.

In the linked article Gersh says that RPKI is complex and deployment has been slow. In reality, since the RIRs launched an RPKI production service on 1 Jan 2011, adoption has been incredibly good (for example compared to IPv6 and DNSSEC). More than 1500 ISPs and large organizations world-wide have opted-in to the system and requested a resource certificate using the hosted service, or running an open source package with their own CA.

But it's not just that, these ISPs didn't just blindly get certificate and walk away. There are over 800 ROAs in the global system, describing more than 2000 prefixes ranging from /24s to /10s, totaling to almost 80 million IPv4 addresses worth of BGP announcements. Data quality is really good. All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better.

Global deployment statistics can be found here: http://certification-stats.ripe.net/

* Alex Band:

>> I don't know if we can get RPKI to deployment because RIPE and RIPE
>> NCC have rather serious issues with it. On the other hand, there
>> doesn't seem to be anything else which keeps RIRs relevant in the
>> post-scarcity world, so we'll see what happens.
>
> Could you elaborate on what those issues are?

A year ago, RIPE NCC received legal advice that RPKI-based takedowns
would not happen under Dutch law because Dutch law lacked any
provisions for that. This was used to deflect criticism that RPKI
deployment would result in too much concentration of power:

<http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005858.html>

The legal analysis turned out to be incomplete and the results
incorrect---legal counsel failed to consider public order legislation.
The validaty of such an order (issued in the Dnschanger context) is
currently being challenged in a Dutch court.

From the comments on these events, I infer that RIPE NCC still does
not want to exercise this level of control over routing, and the RIPE
community does not want RIPE to have such control. But assuming that
the order stands, RPKI will provide RIPE NCC with a tool that nobody
wants it to have, and RIPE NCC can be forced to use it. Depending on
the seriousness of those concerns, that's the end of RPKI deployment.

(However, the most likely outcome of the current court case is that
this particular police order will be found invalid on a formality,
such as lack of effectiveness, providing little insight on the
validity of future orders which are more carefully crafted.)

Regarding the post-scarcity future, if most address holders never have
to come back to the RIR to request more addresses, the number of
address-related RIR/LIR transactions will decrease. Organizations
have a tendency to resist decreases in business (even non-profits),
and RPKI is an obvious source of future business.

On Sat, Apr 28, 2012 at 03:04:07AM -0700,
Randy Bush <randy@psg.com> wrote
a message of 9 lines which said:

> draft-bates-bgp4-nlri-orig-verif-00.txt was '98
>
> and we dropped it for good reasons

Unfortunately, we have RFCs for good ideas but bad ideas never get
documented by the IETF (one of the few exceptions is RFC 3197). So,
bad ideas keep coming back and back again.

Would you explain in a few words why this was a bad idea? I personally
find Rover a very interesting idea, and which seems realistic.

On Sat, Apr 28, 2012 at 12:34:52PM +0200,
Alex Band <alexb@ripe.net> wrote
a message of 41 lines which said:

> In reality, since the RIRs launched an RPKI production service on 1
> Jan 2011, adoption has been incredibly good (for example compared to
> IPv6 and DNSSEC). More than 1500 ISPs and large organizations
> world-wide have opted-in to the system and requested a resource
> certificate using the hosted service, or running an open source
> package with their own CA.

I have an experience with the deployment of DNSSEC and the problem
with DNSSEC was not to have signed zones (many are, now) but to have
people *using* these signatures to check the data (i.e. validating in
a resolver).

RPKI has many ROA (signed objects) but how many operators validate
routes on their production routers? Zero?

> But it's not just that, these ISPs didn't just blindly get
> certificate and walk away.

Most of the ROAs are very recent. Again, the experience with DNSSEC
shows that starting is easy ("DNSSEC in siw minutes"). It's long term
management which is *the* problem. Wait until people start to change
the routing data and watch the ROAs becoming less and less correct...

> Data quality is really good.

It's not what you said:

"It is safe to say that overall data quality is pretty bad"
<https://labs.ripe.net/Members/AlexBand/resource-certification-rpki-in-the-real-world>
(good paper, by the way, thanks)

At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote on RPKI at the general meeting. The result was that the RIPE NCC has the green light to continue offering the Resource Certification service, including all BGP Origin Validation related functionality. It's correct that concerns were raised in the area of security, resilience and operator autonomy, as you mention. These concerns are continuously being evaluated and addressed. The response to the update that was given at RIPE 64 two weeks ago indicated that the membership and Community are happy with the approach the RIPE NCC is taking in this regard. Of course I realize that some people will never be convinced, no matter which steps are taken…

Looking at the bigger picture though, we shouldn't forget that what RPKI, ROVER and the IRR facilitate is merely the ability make a *statement* about routing (with varying degrees of reliability) and doesn't have a direct impact on BGP routing itself. Ultimately, it is up to the network operator to interpret the data that is entered in the system, allow them to make an informed decision and take action they deem appropriate. Everyone has the ability to apply an override on data they do not trust, or have a specific local policy for. In the toolsets for using the RPKI data set for routing decisions, such as the RIPE NCC RPKI Validator, every possible step is taken is taken to ensure that the operator is in the driver's seat.

Have a look here for a public example: http://rpki.netsign.net:8080/
Or install and try it yourself: http://www.ripe.net/certification/tools-and-resources

Cheers,

Alex

On 28 Apr 2012, at 13:35, Florian Weimer wrote:

> * Alex Band:
>
>>> I don't know if we can get RPKI to deployment because RIPE and RIPE
>>> NCC have rather serious issues with it. On the other hand, there
>>> doesn't seem to be anything else which keeps RIRs relevant in the
>>> post-scarcity world, so we'll see what happens.
>>
>> Could you elaborate on what those issues are?
>
> A year ago, RIPE NCC received legal advice that RPKI-based takedowns
> would not happen under Dutch law because Dutch law lacked any
> provisions for that. This was used to deflect criticism that RPKI
> deployment would result in too much concentration of power:
>
> <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-May/005858.html>
>
> The legal analysis turned out to be incomplete and the results
> incorrect---legal counsel failed to consider public order legislation.
> The validaty of such an order (issued in the Dnschanger context) is
> currently being challenged in a Dutch court.
>
> From the comments on these events, I infer that RIPE NCC still does
> not want to exercise this level of control over routing, and the RIPE
> community does not want RIPE to have such control. But assuming that
> the order stands, RPKI will provide RIPE NCC with a tool that nobody
> wants it to have, and RIPE NCC can be forced to use it. Depending on
> the seriousness of those concerns, that's the end of RPKI deployment.
>
> (However, the most likely outcome of the current court case is that
> this particular police order will be found invalid on a formality,
> such as lack of effectiveness, providing little insight on the
> validity of future orders which are more carefully crafted.)
>
> Regarding the post-scarcity future, if most address holders never have
> to come back to the RIR to request more addresses, the number of
> address-related RIR/LIR transactions will decrease. Organizations
> have a tendency to resist decreases in business (even non-profits),
> and RPKI is an obvious source of future business.
>

On Sat, Apr 28, 2012 at 01:17:10PM +0300,
Saku Ytti <saku@ytti.fi> wrote
a message of 27 lines which said:

> I think ROVER is better solution, doesn't need any changes to BGP
> just little software magic when accepting routes.

I like Rover but RPKI+ROA does not change BGP either (it will be a
different story with BGPsec).

> People might scared to rely on DNS on accepting routes, but is this
> really an issue?

RPKI+ROA depends on DNS too, since rsync://rpki.ripe.net/repository
will work only if DNS works. Not a problem in practice, since route
origins do not change every minute and the validating ROA cache can
work even if it can no longer update its data. Same thing with Rover:
temporary glitches in the DNS are not a practical problem (the router
keeps the old info).

> routes which fail authorization are logged but accepted if there
> wasn't pre-existing covering route. Only drop routes if they fail
> authorization _AND_ there is pre-existing covering route.

It is a bit more complicated: more-specific attacks, and so on. But,
yes, you're right. As Alex Band says, Rover, RPKI and the IRR make
(authenticated) statements about route origins. You then do what you
want (what your boss wants? what the FBI wants?) with these statements
(route-map, etc).

On 28 Apr 2012, at 14:57, Stephane Bortzmeyer wrote:

> On Sat, Apr 28, 2012 at 12:34:52PM +0200,
> Alex Band <alexb@ripe.net> wrote
> a message of 41 lines which said:
>
>> In reality, since the RIRs launched an RPKI production service on 1
>> Jan 2011, adoption has been incredibly good (for example compared to
>> IPv6 and DNSSEC). More than 1500 ISPs and large organizations
>> world-wide have opted-in to the system and requested a resource
>> certificate using the hosted service, or running an open source
>> package with their own CA.
>
> I have an experience with the deployment of DNSSEC and the problem
> with DNSSEC was not to have signed zones (many are, now) but to have
> people *using* these signatures to check the data (i.e. validating in
> a resolver).
>
> RPKI has many ROA (signed objects) but how many operators validate
> routes on their production routers? Zero?

First you need a robust system and reliable data. Native router support is coming along. We could be getting to a stage where people will use the data in production. Time will tell...

>> But it's not just that, these ISPs didn't just blindly get
>> certificate and walk away.
>
> Most of the ROAs are very recent. Again, the experience with DNSSEC
> shows that starting is easy ("DNSSEC in siw minutes"). It's long term
> management which is *the* problem. Wait until people start to change
> the routing data and watch the ROAs becoming less and less correct...
>
>> Data quality is really good.
>
> It's not what you said:
>
> "It is safe to say that overall data quality is pretty bad"
> <https://labs.ripe.net/Members/AlexBand/resource-certification-rpki-in-the-real-world>
> (good paper, by the way, thanks)

A lot has changed since I wrote that. :)

-Alex

[. sorry cameron, trying to keep things down to one message ]

> http://tech.slashdot.org/story/12/04/27/2039237/engineers-ponder-easier-fix-to-internet-problem
> http://www.itworld.com/security/272320/engineers-ponder-easier-fix-dangerous-internet-problem

and don't miss

http://www.theregister.co.uk/2012/04/23/ip_hijack_prevention/

free dinner at nanog/van for anyone who can explain how the dnssec
approach meets the defcon attack. hint: it is a path attack, not an
origin attack, and the dns pidgeon has no hooks to path attack
prevention. at ripe, joe gersh asked me for an example of a path attack
and i told him of the defcon demo. seems he also did not bother to do
his homework. but it makes good pr.

someone selling dnssec appliances flew a press release that a few
reporters bought without doing their homework. end of net predicted,
news at eleven.

> Taking what seriously ? The commitments to rpki you speak off ?

a thousand LIRs in the ripe region, 500 elsewhere? cisco code shipping
on a number of platforms, juniper soon. some of us have actually
started validating route origins in the real network using rpki and
cisco and juniper (test) code.

----

Saku Ytti <saku@ytti.fi> wrote:
> If two fails don't make win, then I think ROVER is better solution,
> doesn't need any changes to BGP just little software magic when
> accepting routes.

you are right, you have not done your homework. rpki-based origin
validation asks no changes to bgp.

> People might scared to rely on DNS on accepting routes, but is this
> really an issue?

yes. rpki can also have that issue as the certs can have urls that use
domain names. i believe they could use ip address urls instead. but
the gathering operation differs greatly between the rpki and the dnssec
based proposal. with the latter, you can't even tell you have the full
set.

----

the worry in the ripe region and elsewhere is what i call the 'virginia
court attack', also called the 'dutch court attack'. some rights holder
claims their movie is being hosted in your datacenter and they get the
RIR to jerk the attestation to your ownership of the prefix or your ROA.

this problem is inherent in any system which uses the address allocation
administrative hierarchy to attest to address space ownership, whether
rpki, dns-based, or hollerith cards.

i do not like it either. but it is a trade you make for security. and,
at ripe ljubljana, i think alex started to discuss some schemes to
ameliorate it. more later on this.

----

randy

> first thing that sprung to mind was this:
> http://www.cafepress.com.au/nxdomain

geoff wore one at ripe64. i was soooooo green with envy that he has
graciously sent one to meet me when i get home from travails.

see http://archive.psg.com/001213.ietf-dns.pdf for my comments on the
subject at an ietf plenary a dozen years ago.

randy

* Alex Band:

> At RIPE 63, six months ago, the RIPE NCC membership got a chance to
> vote on RPKI at the general meeting. The result was that the RIPE
> NCC has the green light to continue offering the Resource
> Certification service, including all BGP Origin Validation related
> functionality.

But this was done outside the Policy Development Process, which is
supposed to handle such things.

> It's correct that concerns were raised in the area of
> security, resilience and operator autonomy, as you mention. These
> concerns are continuously being evaluated and addressed.

I don't think so. Ultimately, it does not seem to be possible to get
this through the PDP.

The whole discussion is a bit odd: Even without RPKI, RIPE NCC already
has the power to directly influence global routing because it's
unreasonable to expect that the majority of their BGP peers employ
strict filtering. So they could inject more specifics as they see
fit, and thus blackhole pretty arbitrary chunks of address space.
However, so can most folks who of those who control routers in the
DFZ, and RPKI (or something similar) would change that at least.

On 28/04/2012 14:04, Alex Band wrote:
> they do not trust, or have a specific local policy for. In the toolsets
> for using the RPKI data set for routing decisions, such as the RIPE NCC
> RPKI Validator, every possible step is taken is taken to ensure that the
> operator is in the driver's seat.

Leaving aside technical matters, this is one of the more contentious
political issues with RPKI. RPKI is a tool which can be used to locally
influence routing decisions, but allows centralised control of prefix
authenticity. If this central point is influenced to invalidate a specific
prefix, then that will cause serious reachability problems for that prefix
on the Internet.

It will be difficult for politicians / legislators / LEAs to look at a
technology like this and not see its potential for implementing wide-area
Internet blocking. For sure, the LEAs currently looking at it are
extremely interested.

Nick

Nick Hilliard (nick) writes:
>
> Leaving aside technical matters, this is one of the more contentious
> political issues with RPKI. RPKI is a tool which can be used to locally
> influence routing decisions, but allows centralised control of prefix
> authenticity. If this central point is influenced to invalidate a specific
> prefix, then that will cause serious reachability problems for that prefix
> on the Internet.

To me that seems like the most obvious problem, but as Alex put it,
"Everyone has the ability to apply an override on data they do not trust,
or have a specific local policy for."

> It will be difficult for politicians / legislators / LEAs to look at a
> technology like this and not see its potential for implementing wide-area
> Internet blocking.

> For sure, the LEAs currently looking at it are extremely interested.

Or the ITU ? :)

Cheers,
Phil

On 28/04/2012 18:27, Phil Regnauld wrote:
> To me that seems like the most obvious problem, but as Alex put it,
> "Everyone has the ability to apply an override on data they do not trust,
> or have a specific local policy for."

So what do you suggest to do with a roa lookup which returns "Invalid"?

Nick

On 28 Apr 2012, at 19:45, Nick Hilliard wrote:

> On 28/04/2012 18:27, Phil Regnauld wrote:
>> To me that seems like the most obvious problem, but as Alex put it,
>> "Everyone has the ability to apply an override on data they do not trust,
>> or have a specific local policy for."
>
> So what do you suggest to do with a roa lookup which returns "Invalid"?

In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17:

https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf

-Alex

> In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17:
>
> https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf

The same currently happens with DNSSEC, doing what Comcast calls
"negative trust anchors":
http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01




Rubens

Rubens Kuhl (rubensk) writes:
> > In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17:
> >
> > https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf
>
> The same currently happens with DNSSEC, doing what Comcast calls
> "negative trust anchors":
> http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01

Yes, NTAs was the comparison that came to my mind as well. Or even
in classic DNS, overriding with stubs. You will get bitten by a bogus/
flawed ROA, but you'll have to the chance to mitigate it. Any kind of
centralized mechanism like this is subject to these risks, no matter
what the distribution mechanism is.

On 28 Apr 2012, at 21:28, Phil Regnauld wrote:

> Rubens Kuhl (rubensk) writes:
>>> In case you feel a BGP announcement should not be "RPKI Invalid" but something else, you do what's described on slide 15-17:
>>>
>>> https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf
>>
>> The same currently happens with DNSSEC, doing what Comcast calls
>> "negative trust anchors":
>> http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01
>
> Yes, NTAs was the comparison that came to my mind as well. Or even
> in classic DNS, overriding with stubs. You will get bitten by a bogus/
> flawed ROA, but you'll have to the chance to mitigate it. Any kind of
> centralized mechanism like this is subject to these risks, no matter
> what the distribution mechanism is.

Now that we have cleared up the fact that any RPKI statement can be overridden, I want to address another tenacious misunderstanding in relation to what Randy said:

On 28 Apr 2012, at 15:58, Randy Bush wrote:

> the worry in the ripe region and elsewhere is what i call the 'virginia
> court attack', also called the 'dutch court attack'. some rights holder
> claims their movie is being hosted in your datacenter and they get the
> RIR to jerk the attestation to your ownership of the prefix or your ROA.

If a Dutch court would order the RIPE NCC to remove a certificate or ROA from the system, the effect would be that there no longer is an RPKI statement about a BGP route announcement. The result is that the announcement will have the RPKI status *UNKNOWN*. It will be like the organization never used RPKI to make the statement in the first place.

Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID route announcement; the result is RPKI UNKNOWN.

The only way a court order could make a route announcement get the RPKI status *INVALID* would be to:
1: Remove the original, legitimate ROA
2: Tamper with the Registry, inject a false ROA authorizing another AS to make the announcement look like a hijack

All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override.

-Alex

>> the worry in the ripe region and elsewhere is what i call the 'virginia
>> court attack', also called the 'dutch court attack'. some rights holder
>> claims their movie is being hosted in your datacenter and they get the
>> RIR to jerk the attestation to your ownership of the prefix or your ROA.
>
> If a Dutch court would order the RIPE NCC to remove a certificate or ROA from the system, the effect would be that there no longer is an RPKI statement about a BGP route announcement. The result is that the announcement will have the RPKI status *UNKNOWN*. It will be like the organization never used RPKI to make the statement in the first place.
>
> Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID route announcement; the result is RPKI UNKNOWN.
>
> The only way a court order could make a route announcement get the RPKI status *INVALID* would be to:
> 1: Remove the original, legitimate ROA
> 2: Tamper with the Registry, inject a false ROA authorizing another AS to make the announcement look like a hijack

How does this interact with the presence of certificates for supernets, though? That is, suppose an ISP creates a legitimate ROA for 12.0.0.0/8, after ensuring that all of its customers have legitimate ROAs for the various subnets of 12.0.0.0/8. Now, suppose one of these customers has its legitimate ROA revoked by a court order. Would the legitimate announcement of that subnet (originated by the customer's ASN) still result in UNKNOWN status, or would it look like a sub-prefix hijack because the announcement has a different ASN than the matching 12.0.0.0/8 prefix?

-- Jen

> Thus, removing a certificate or ROA *does NOT* result in an RPKI INVALID
> route announcement; the result is RPKI UNKNOWN.

Which is fine until UNKNOWNs are no longer permitted, a logical next
step. It may not apply globally, initially perhaps just a US anti
terrorist measure requiring all networks in the USA do it.

> The only way a court order could make a route announcement get the
> RPKI status *INVALID* would be to:
> 1: Remove the original, legitimate ROA
> 2: Tamper with the Registry, inject a false ROA authorizing another
> AS to make the announcement look like a hijack

Domains already get FBI hijacked so this seems plausible too.

> All in all, for an RPKI-specific court order to be effective in
> taking a network offline, the RIR would have to tamper with the
> registry, inject false data and try to make sure it's not detected so
> nobody applies a local override.

Doesn't need to be undetected, more likely it'll be quite overt
and have a big don't mess FBI entry in the RIR similar to
www.megaupload.com

brandon

On Sun, Apr 29, 2012 at 11:28:58AM -0400,
Jennifer Rexford <jrex@CS.Princeton.EDU> wrote
a message of 37 lines which said:

> How does this interact with the presence of certificates for
> supernets, though? That is, suppose an ISP creates a legitimate ROA
> for 12.0.0.0/8, after ensuring that all of its customers have
> legitimate ROAs for the various subnets of 12.0.0.0/8. Now, suppose
> one of these customers has its legitimate ROA revoked by a court
> order. Would the legitimate announcement of that subnet (originated
> by the customer's ASN) still result in UNKNOWN status, or would it
> look like a sub-prefix hijack because the announcement has a
> different ASN than the matching 12.0.0.0/8 prefix?

The second (and therefore Alex Band's example is not good). But it
depends on the value of the MaxLength attribute in the 12.0.0.0/8 ROA
(section 3.3 of RFC 6482).

If, in the future, RIRs or operators create ROAs for all the blocks
they manage, revocation of a ROA will be deadly.

On Sun, 29 Apr 2012, Stephane Bortzmeyer wrote:

> > How does this interact with the presence of certificates for
> > supernets, though? That is, suppose an ISP creates a legitimate ROA
> > for 12.0.0.0/8, after ensuring that all of its customers have
> > legitimate ROAs for the various subnets of 12.0.0.0/8. Now, suppose
> > one of these customers has its legitimate ROA revoked by a court
> > order. Would the legitimate announcement of that subnet (originated
> > by the customer's ASN) still result in UNKNOWN status, or would it
> > look like a sub-prefix hijack because the announcement has a
> > different ASN than the matching 12.0.0.0/8 prefix?
>
> The second (and therefore Alex Band's example is not good). But it
> depends on the value of the MaxLength attribute in the 12.0.0.0/8 ROA
> (section 3.3 of RFC 6482).
>
unclear as the scenario doesn't depend on the maxLength (wrt the
current specs). If there are valid covering ROAs in the RPKI and none of
them match in the origin AS (customer ROA removed), the route prefix is
invalid.

The scenario is similar to the case in which the ISP starts to create
a ROA for a superblock before the customer adds its route prefix into
the RPKI ... this happened with AT&T during testing, for example,
https://labs.ripe.net/Members/waehlisch/one-day-in-the-life-of-rpki



Cheers
matthias

--
Matthias Waehlisch
. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
. Takustr. 9, D-14195 Berlin, Germany
.. mailto:waehlisch@ieee.org .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

Alex,

On Apr 29, 2012, at 8:16 AM, Alex Band wrote:
> All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override.

I suspect the court order would simply say something like 'RIPE-NCC must, upon pain of contempt of court, take sufficient steps to invalidate the allocations made to customer X' and leave it up to you all to figure out how to do it. I doubt they'd care all that much about implementation details. Are you saying it is not possible for RIPE-NCC staff to do this? I also doubt the court would care too much about 'local override' as the "Tyranny of Defaults" would be sufficient for their needs (and they could probably sanction the folks in the Netherlands who they discovered did the override).

As Randy points out, this is not unique to SIDR-defined RPKI. It is applicable to any top-down hierarchical authorization mechanism. Security has (non-monetary) costs.

Regards,
-drc

On 29/04/2012 16:16, Alex Band wrote:
> All in all, for an RPKI-specific court order to be effective in taking a
> network offline, the RIR would have to tamper with the registry, inject
> false data and try to make sure it's not detected so nobody applies a
> local override.

You mean, like an FBI domain seizure on the basis of a US court order?

Realistically, it doesn't matter a whole lot if the occasional network here
or there applies a local override. If their upstream transit provider
isn't carrying the prefix (on the basis of similar simultaneous court
orders), it's game over for that prefix.

Nick

On 29 Apr 2012, at 22:03, David Conrad wrote:

> Alex,
>
> On Apr 29, 2012, at 8:16 AM, Alex Band wrote:
>> All in all, for an RPKI-specific court order to be effective in taking a network offline, the RIR would have to tamper with the registry, inject false data and try to make sure it's not detected so nobody applies a local override.
>
> I suspect the court order would simply say something like 'RIPE-NCC must, upon pain of contempt of court, take sufficient steps to invalidate the allocations made to customer X' and leave it up to you all to figure out how to do it. I doubt they'd care all that much about implementation details. Are you saying it is not possible for RIPE-NCC staff to do this? I also doubt the court would care too much about 'local override' as the "Tyranny of Defaults" would be sufficient for their needs (and they could probably sanction the folks in the Netherlands who they discovered did the override).
>
> As Randy points out, this is not unique to SIDR-defined RPKI. It is applicable to any top-down hierarchical authorization mechanism. Security has (non-monetary) costs.

Thanks David, I know that a court order doesn't have to specific. I just want to make people aware that in the case of RPKI, things are not as clear cut as "Revoked ROA = Offline network". It depends on many factors and I just want to offer a little perspective of what's involved.

-Alex

(P.S. I'm going on holiday for a week without internet access, so I won't be able to follow up on this thread for a while)

On 28/04/2012 14:04, Alex Band wrote:
> At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote
> on RPKI at the general meeting. The result was that the RIPE NCC has the
> green light to continue offering the Resource Certification service,
> including all BGP Origin Validation related functionality. It's correct
> that concerns were raised in the area of security, resilience and
> operator autonomy, as you mention. These concerns are continuously being
> evaluated and addressed. The response to the update that was given at
> RIPE 64 two weeks ago indicated that the membership and Community are
> happy with the approach the RIPE NCC is taking in this regard. Of course
> I realize that some people will never be convinced, no matter which
> steps are taken…

Alex, I have to take exception with your statement that people in the RIPE
region are generally happy about RPKI and the RIPE NCC RPKI project. They
aren't.

On the basis of some initial interest in the RIPE community several years
ago, the RIPE NCC embarked on a certification + rpki project. By way of
clarification for other readers of this mailing list, the RIPE NCC is a
Dutch company constituted to carry out the policy requirements of the RIPE
community. The way this is supposed to work is that the RIPE community
puts forward policy proposals, and the RIPE NCC carries these policies out.

Some time after the certification project was started in the NCC, a policy
proposal (2008-08) was floated in the RIPE community in order to turn this
into official RIPE policy, so that it could be formally carried out by the
RIPE NCC.

Mid last year, after extensive and heated discussion on the address policy
working group mailing list, that policy proposal was withdrawn from the
RIPE policy development process because it was clear that a large number of
people in the RIPE community were deeply uneasy about a variety of
implications. It is true that some of these concerns have been addressed
to some extent by the NCC, but the core issues of concern are fundamental
to RPKI.

Later that year, several potential proposals were put forward by the RIPE
NCC board at the Nov 2011 general meeting concerning the future of the RIPE
NCC certification project. The RIPE NCC members - who are a fee-paying
subset of the RIPE community - voted by 52% to 48% to keep funding the
project. By any objective measure, this is an alarmingly slim majority.

In short:

- a substantial number of people, both within the RIPE community and
within the RIPE NCC membership have serious concerns about the long-term
legal consequences of this project which have not (in their opinion) been
addressed adequately.

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

Nick

> As Randy points out, this is not unique to SIDR-defined RPKI. It is
> applicable to any top-down hierarchical authorization mechanism.
> Security has (non-monetary) costs.

as this derives from address space ownership's dependence on the current
hierarchic administrative allocation model, to fix it merely change the
administrative model or our trust model that depends on that hierarchy.

randy

On 29 Apr 2012, at 22:50, Nick Hilliard wrote:

> On 28/04/2012 14:04, Alex Band wrote:
>> At RIPE 63, six months ago, the RIPE NCC membership got a chance to vote
>> on RPKI at the general meeting. The result was that the RIPE NCC has the
>> green light to continue offering the Resource Certification service,
>> including all BGP Origin Validation related functionality. It's correct
>> that concerns were raised in the area of security, resilience and
>> operator autonomy, as you mention. These concerns are continuously being
>> evaluated and addressed. The response to the update that was given at
>> RIPE 64 two weeks ago indicated that the membership and Community are
>> happy with the approach the RIPE NCC is taking in this regard. Of course
>> I realize that some people will never be convinced, no matter which
>> steps are taken…
>
> Alex, I have to take exception with your statement that people in the RIPE
> region are generally happy about RPKI and the RIPE NCC RPKI project. They
> aren't.

That's not what I said. :)

> - a substantial number of people, both within the RIPE community and
> within the RIPE NCC membership have serious concerns about the long-term
> legal consequences of this project which have not (in their opinion) been
> addressed adequately.


I already linked to my RIPE64 presentation from two weeks ago before, but here it is again:
https://ripe64.ripe.net/presentations/77-RIPE64-Plenery-RPKI.pdf

Slide 2-4: we heard you. This is what I said:

>> The response to the update that was given at
>> RIPE 64 two weeks ago indicated that the membership and Community are
>> happy with the approach the RIPE NCC is taking in this regard.

This is where I suspect you may be:

>> I realize that some people will never be convinced, no matter which
>> steps are taken…

So all in all you quoted me well. :)

-Alex

Now getting in my car for some internet-free holidays in the sun. See you all in a week!

> free dinner at nanog/van for anyone who can explain how the dnssec
> approach meets the defcon attack. hint: it is a path attack, not an
> origin attack, and the dns pidgeon has no hooks to path attack
> prevention. at ripe, joe gersh asked me for an example of a path attack
> and i told him of the defcon demo. seems he also did not bother to do
> his homework. but it makes good pr.
....
> you are right, you have not done your homework. rpki-based origin
> validation asks no changes to bgp.

Free dinner to anyone who can explain how the RPKI piece of the SIDR
work resolves path attacks. You're comparing apples to oranges here.
Neither a DNS based solution nor the RPKI will resolve path attacks, so
neither apply to the type of attack you're talking about.

There are solutions for this sort of attack. Everything from completely
loose, community based solutions to totally control freak horrible
solutions, like BGP-SEC (and which doesn't really solve the problem anyway).

> yes. rpki can also have that issue as the certs can have urls that use
> domain names. i believe they could use ip address urls instead. but
> the gathering operation differs greatly between the rpki and the dnssec
> based proposal. with the latter, you can't even tell you have the full
> set.

The problem at hand is relying on routing to build the routing system.
How does using an IP address rather than a DNS based hostname change the
need for routing to work before routing can work?

Reality check: I don't know that this is all that important, in the end.
So long as you can use an IGP locally with a default route to reach a
copy of the database, whether it be based on DNS, an RPKI, or anything
else, then you can bootstrap your EGP routing. If everything goes down
at the same time, then you would just start rebuilding from the places
where the root servers live, no matter what system's root servers we're
talking about.

So I think this is a bit of a red herring at the EGP level.

> i do not like it either. but it is a trade you make for security. and,
> at ripe ljubljana, i think alex started to discuss some schemes to
> ameliorate it. more later on this.

The problem is worse than your initial estimate. A day's worth of
downtime can cost you your business in total, not just some lost revenue.

No matter whether or not you agree with the article's premise, at least
some provider folks are starting to ask some hard questions --which is a
good thing! Let's not shut the conversation down by making broad
proclamations about how the problem has been solved, "move along,
nothing to see here," etc. There is something to see here, so slow down
and take a look. Rubbernecking, in this case, is encouraged.

Russ


--
<>< Scripture Alone, Grace Alone, Faith Alone
http://thinkinginchrist.com/

On Mon, Apr 30, 2012 at 09:41:51AM -0400,
Russ White <russw@riw.us> wrote
a message of 60 lines which said:

> Neither a DNS based solution nor the RPKI will resolve path attacks,

I want to be sure of the terminology: what is deployed presently is
the bundle RPKI+ROA. As their name say, ROA can only be used against
origin attacks. But RPKI can be used for other things than RPKI+ROA,
including BGP-sec (against path-based attacks), no?

> I want to be sure of the terminology: what is deployed presently is
> the bundle RPKI+ROA. As their name say, ROA can only be used against
> origin attacks. But RPKI can be used for other things than RPKI+ROA,
> including BGP-sec (against path-based attacks), no?

wfm

>> Neither a DNS based solution nor the RPKI will resolve path attacks,
>
> I want to be sure of the terminology: what is deployed presently is
> the bundle RPKI+ROA. As their name say, ROA can only be used against
> origin attacks. But RPKI can be used for other things than RPKI+ROA,
> including BGP-sec (against path-based attacks), no?


The RPKI can provide the keying infrastructure on which a mechanism to
"protect the path," (controversial terminology in and of itself) could
be based. Is that the right basis for path validation? I don't know that
we should assume this. But key distribution is the easy part of the
problem here.

The hard part is determining what we're trying to protect and what the
tradeoffs are in trying to defend against those attacks. BGP-SEC assumes
we care about verifying the path a "routing object" takes through the
network, we don't much care about replay attacks, policy is off the
table (except one policy specific folks care about), and operators are
willing to replace their hardware specifically to resolve this problem.

Is this the right set of presuppositions to make? The provider
community, IMHO, hasn't really participated too much in this entire
discussion, so we don't really know the answers to this question.

Russ

> Reality check: I don't know that this is all that important, in the end.
> So long as you can use an IGP locally with a default route to reach a
> copy of the database, whether it be based on DNS, an RPKI, or anything
> else, then you can bootstrap your EGP routing. If everything goes down
> at the same time, then you would just start rebuilding from the places
> where the root servers live, no matter what system's root servers we're
> talking about.

or you wait for the Elders of the Internet to visit with blessings
http://www.youtube.com/watch?v=iDbyYGrswtg

brandon

Brandon Butterworth (brandon) writes:
>
> or you wait for the Elders of the Internet to visit with blessings
> http://www.youtube.com/watch?v=iDbyYGrswtg

Didn't randy just chime in ?

On Apr 28, 2012, at 6:34 AM, Alex Band wrote:

> All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better.

We should be more careful with statements such as this, they're conflating important things that add to the confusion in this area.

None of these implementations support "RPKI" today. What they support is a new protocol for onboarding routing policy data (some call this a [VRP], essentially prefix,origin bindings) into soft state in a router.

-danny

[VRP] https://ripe64.ripe.net/presentations/74-120417.sidr-origin.pdf

Danny,
just one more comment.

So named vendor's support can be the worst case when there are no practical ways to deploy and it is absolutely
not clear - should we follow this hierarchical model - I think it is the key point as we pushed ourselves by inertia to this way of thinking.


Imho - it is way to nowhere in such form

We need more flexible, distributed architecture behind - no matter - which interests will be lobbied as we have got already.



On Apr 30, 2012, at 6:53 PM, Danny McPherson wrote:

>
> On Apr 28, 2012, at 6:34 AM, Alex Band wrote:
>
>> All in all, RPKI has really good traction and with native router support in Cisco, Juniper and Quagga, this is only getting better.
>
> We should be more careful with statements such as this, they're conflating important things that add to the confusion in this area.
>
> None of these implementations support "RPKI" today. What they support is a new protocol for onboarding routing policy data (some call this a [VRP], essentially prefix,origin bindings) into soft state in a router.
>
> -danny
>
> [VRP] https://ripe64.ripe.net/presentations/74-120417.sidr-origin.pdf
>

> 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

randy

Personally I find the BitTorrent approach interesting.

Jared Mauch

On Apr 30, 2012, at 11:46 AM, 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
>
> randy

Randy -
you know that I'm enough stupid- means straightforward -

may be the way is not only technical (recomendations design) - but also to combine with some policy changes as
splitting allocations and assignments (may be changing who is responsible for what?)

Or we follow the traditional way(means hierarchy) or we are capable to introduce one more
level for flexebility - we should be honest that all techinical design just follows some political or quasi-political decisions.
But I think it can be changed.

Dima
On Apr 30, 2012, at 7:46 PM, Randy Bush 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
>
> randy

* Alex Band:

> All in all, for an RPKI-specific court order to be effective in
> taking a network offline, the RIR would have to tamper with the
> registry, inject false data and try to make sure it's not detected
> so nobody applies a local override.

Please keep in mind that this is what's happening with DNS: registries
are not only forced by the courts to remove delegations, but to
delegate names to specific parties.

On the other hand, it's not entirely clear whether this is such a bad
thing.

On Mon, Apr 30, 2012 at 11:51 AM, Jared Mauch <jared@puck.nether.net> wrote:
> Personally I find the BitTorrent approach interesting.

this conflates the 2 (at least!) topics here:
1) distribution of repository data
2) heirarchy of authority for the data which is in the repository

-chris

> On Apr 30, 2012, at 11:46 AM, 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
>>
>> randy
>

Randy:

> as i agree that there is a problem, i *very* eagerly await your proposal

Reality: A few years back there were a half a dozen options proposed.
soBGP, pgBGP, IRR based solutions, etc. Just recently PSVs were
discussed and dismissed as a live option.

Why?

1. Only S-BGP/BGP-SEC will solve the "man in the middle attack," within
the parameter of "I won't ever tell anyone what any of my policies are!"
This single requirement --solving one specific policy issue without
advertising policy-- has been the center pin of the entire discussion
for a number of years.

2. Any time someone proposed something different, long threads ensue
with lots of talk about how these folks don't know what they're talking
about, etc., but which contain very little technical discussion, or
thoughts on tradeoffs, etc. Any technical discussion is limited to
taking out the "man in the middle attack," and beating it over the heads
of those making the proposal --repeatedly.

So the bottom line is this: The current requirements were written around
the ability of one particular solution to solve one particular policy
issue in a way that's acceptable to a very small set of operators.

A single root has been a requirement for a long time, as well --we had
this discussion a very long time ago. No other solution proposed had a
single root, and S-BGP/BGP-SEC didn't have to use a single root. But a
single root somehow made it into the requirements, and it's stayed there
ever since.

If you want honestly more options, go back and rethink your requirements.

Russ

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.

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

Luck is the residue of opportunity and design.

-- John Milton

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.

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

Luck is the residue of opportunity and design.

-- John Milton

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

"ah, the force is strong in this one."

On 2012-05-30 3:52 AM, Shane Amante wrote:
> On May 29, 2012, at 9:23 AM, Alex Band wrote:
>> ...
>>
>> 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>.

as dns is an unreliable protocol, and is not atomic across multiple
questions, what is the effect of seeing one of those rrsets but not the
other? (here again we see the disadvantage of starting from incomplete
information.)

On 2012-05-30 4:24 AM, Shane Amante wrote:
> On May 29, 2012, at 8:44 PM, Paul Vixie wrote:
>> ...
>>
>> 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.

my comment on that draft was (on the dnsop mailing list, march 10, 2012):

> your draft-gersch-dnsop-revdns-cidr-01 is very clean and simple; the
> draft and the design are of admirable quality. as a co-author of RFC
> 2317 i agree that it does not suit the needs of bgp security since it
> seeks only to provide a method of fully naming hosts, not networks.
>
> importantly, i see no reference to RFC 1101 in your draft. RFC 1101
> describes a way to name networks, and while at first it did not seem to
> be compatible with CIDR, implementation (in "netstat -r" back in BSD/OS
> 3.1) showed that RFC 1101 was in fact not as classful as it appeared.
...
> you may find that some of your work has already been done for you, or,
> you may find that this is related work that should be referenced in your
> draft along with the reasons why your proposed method is necessary.

joe and dan (authors of this draft) responded:

> thanks for your comments and support. We will definitely reference RFC draft 1101 in our next version.

and indeed this was done, but weakly:

> Changes from version 01 to 02
...
> Expanded the related work discussion to include RFC 1101.

looking at draft -02 we see:

> 4.1. Naming via RFC 1101
>
> The problem of associating records with network names dates back to
> at least [RFC1101]. This work coincides with some of the early
> development of DNS and discusses issues regarding hosts.txt files.
> The RFC observation makes a key observation that one should provide
> "mappings for subnets, even when nested".
>
> The approach taken here clearly states how to map an IPv4 prefix that
> is on an octet boundary. The RFC maps "10.IN-ADDR.ARPA for class A
> net 10, 2.128.IN-ADDR.ARPA for class B net 128.2, etc." This is
> essentially the same as the approach proposed here, although we
> append an "m" label (discussed later in this document).
>
> [RFC1101] also mentions more specific subnets, but the details are
> limited. We believe the approach proposed here builds on the best
> ideas from this RFC and expands on the details of how the naming
> convention would work.

in other words no explaination for why the existing RFC 1101 encoding
will not serve, even though RFC 1101 encoding been used for network
naming in the CIDR era, without limitation.

this reader is left wondering, what's the real impetus here?

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

i think you're paying insufficient attention to this discussion, if you
think that failure predictions have not already been well made with
respect to the rover approach to routing security.

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

see also <http://queue.acm.org/detail.cfm?id=1242499>.

paul

>> 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] --
> i think you're paying insufficient attention to this discussion, if
> you think that failure predictions have not already been well made
> with respect to the rover approach to routing security.

rfc 3439, the most complex document about simplicity you can imagine

randy

Another difference between RPKI and ROVER which hasn't come up much:

RPKI incorporates a lot of pre-existing machinery from X.509 et al.
This drags in some tedious detail which makes people's eyes cross, but
it gives us some tools which simply aren't available in DNS at
present. In particular, X.509's CRL mechanism combined with the way
that RPKI uses CMS messages with single-use EE certificates means that
in RPKI we have a way to revoke individual objects (eg, ROAs) at will.
DNSSEC only just barely has revocation at all, and that only for
DNSKEYs. The nearest equivalent to per-object revocation one could do
in DNSSEC would be either:

- generate a new ZSK, re-sign everything in the zone with the new
ZSK except for the RRsets you want to get rid of, and revoke the
old ZSK, or

- keep as many distinct ZSKs in the zone as you intend to have
distinctly revocable groups of objects in the zone, and make sure
you sign the right objects with the right ZSKs.

Neither of these solutions is very good: the first may involve
re-signing a lot of data every time you change anything, while the
latter is complex and tends to bloat the zone's apex DNSKEY RRset.

I suppose a third option would be to make every DNS owner name in the
reverse tree be a separate zone. Doesn't seem like an improvement.

Summarizing a few other things other people have mentioned:

- The normal operating mode with RPKI is to fetch everything rather
than do a point query. We've spent the last decade or so making
that harder to do with DNS (blocking AXFR/IXFR, using NSEC3 instead
of NSEC, etc). This makes it fairly difficult to know in advance
what queries one should be asking ROVER (as Paul Vixie puts it,
ROVER isn't a catalogue). When I pressed the ROVER folks about this
at the Paris IETF meeting, they mumbled something about maybe
walking the IRR or other external databases as a way of knowing what
DNS queries to issue.

- Circular dependencies are a problem. Helical dependencies can be
made to work, but this says that one probably should not be
depending on routing to make a point query to make decisions about
routing. If you look at the architecture of the existing RPKI
validators (well, mine and BBN's, anyway, not sure about RIPE's but
suspect they took the same approach), we've gone to some trouble to
make sure that the validator will continue to work across network
outages as long as the collected data haven't expired or been
revoked. In theory one could do the same thing with bulk transfers
of DNS (whether AXFR/IXFR or NSEC walking, if they worked) but it
would not work well with point queries.

- ROVER gives us no traction on path validation (BGPSEC), it's limited
to origin validation. RPKI can certify both prefixes and ASNs,
which gives it the basics needed to support path validation as well
as origin validation. ASNs have no hierarchical structure, thus
would be a very poor match for encoding as DNS names.

- Some of the DNS aspects of ROVER are a little strange. In
particular, as currently specified ROVER requires the relying party
to pay attention to DNS zone cuts, which is not normal in DNS (the
basic DNS model since RFC 883 has been that zones are something for
the zone administrator to worry about, resolvers mostly just see a
tree of RRsets). ROVER requires the relying party to check for the
same data in multiple zones and pay close attention to zone cuts.
While it is certainly possible to do all this, it is not a matter of
issuing a simple DNS query and you're done. DNS caching effects can
also complicate matters here if the zone structure is changing:
think about what happens if you have cached responses to some (but
not all) of the queries you need to make to figure out whether to
allow a more specific route punched out of a larger prefix block.

- The reuse of existing infrastructure argument for ROVER is somewhat
disingenuous -- it's only partial reuse of existing infrastructure.
ROVER's new encoding of prefixes as DNS names means that a lot of
new stuff would need to be deployed, and attempting to be backwards
compatible with the existing DNS reverse tree adds some complexity
to ROVER's architecture (conflicting data for same prefix can appear
in multiple zones, relying party has to sort this out, yum).

As far as I can tell, ROVER doesn't solve any of the hard problems in
RPKI. It's a different encoding of a partial subset of the data, with
some of the features removed.

On Mon, 28 May 2012, David Conrad wrote:

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

Not quite. ROVER's SRO & RLOCK statements have different semantics
than RPKI ROAs, and there are semantics that may not be (practically)
expressible in ROVER.

ROVER's semantics depend on DNS zone structure. The protection
offered by the RLOCK statement stops when a zone cut is reached --
longer routes are allowed unless there's an RLOCK in every descendant
zone. Having DNS users care about zone structure is, to quote Rob
Austein, "not normal".

-- Sam Weiler