Subject: [sidr] On 0/0 at the 5 TAs - Some comments on the motivations

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 08 Sep 2016 11:39:33 -0300

Hello all

I'm going to provide the best answers I can to the questions that have 
been made in the mailing list. I'm spinning a new thread so we don't 
hijack the WG directionz one.

Intentionally I'm **not** going to answer any emails that invoke 
politics. Those who feel they need answers from that side of things know 
who you can refer to.

First of all, thanks for the feedback. To be honest, I am quite 
surprised that it took this long. This document was first presented in 
Buenos Aires, which was almost 5 months ago.

This decision to move to 0/0 is a solution born more of necessity than 
desire for the following reasons:

a. There exist political obstacles to a global trust anchor of 0/0 that 
are, at the moment and for the foreseeable future, insurmountable. This 
is regrettable, but also a reality and should not be denied.

b. Due to the above, there is an inconsistent model of trust anchors 
published by the RIRs. This solution does fix this problem, making the 
overall RPKI at least consistent.

c. The RPKI does not have a graceful mechanism for which to handle "ERX 
space" (networks managed by one RIR placed under the IANA allocation for 
another RIR). As inter-RIR transfers become more common place, the ERX 
space will become more fluid and a source of conflict. Management of ERX 
space is all the more difficult to manage under the RPKI as there is no 
make-before-break mechanism built-in to the RPKI nor does the RFC 6492 
protocol provide a mechanism for parent-to-child messaging with which to 
enable a make-before-break mechanism.

d. Given the fluidity of the ERX space mentioned above and the current 
validation algorithm, there is foreseeable fragility of the system that 
is solved by this solution. The IETF is working on changing the 
validation algorithm, but this change has been in progress for years and 
is still dependent on a timetable for publication of new ROAs by all CAs 
and installation of new software by all RPs.

e. Given that there is no global trust anchor and the RIRs each operate 
offline Trust Anchors for security, having just the resources actually 
assigned or allocated by the respective RIR, would require a trip to the 
datacenter for each inter-RIR transfer which will incur delays and 
result in resources showing up at two RIRs simultaneously, or none of 
the RIRs for some time as TA certificates are updated independently.

Thanks to all!

-Carlos

---

From: Rob Austein <[email-masked]>
Date: Thu, 08 Sep 2016 11:37:01 -0400

Hi, Carlos.  Technical question:

Do the current RIR CA implementations support the client role of the
"up-down" provisioning protocol, and, if so, has there been any recent
interop testing of this, either against other RIR CA implementations
or against mine?

APNIC's original implementation did support it.  I think RIPE's
implementation sort of supported it at one point but they did not
consider it production-ready.  Dunno about the others, and all of this
was a while ago, haven't heard much about it recently.

---

From: "Carlos M. Martinez" <[email-masked]>
Date: Thu, 08 Sep 2016 12:57:57 -0300

Hi Rob,

I’ll let each RIR answer for themselves. In our case (LACNIC), we 
don’t support up/down. We’ve had a very rough implementation of a 
‘parent’ CA for a while, but since there is essentially no demand 
for it from our members, the project always gets down-prioritized.

If the GTA was to gain any traction, we’d commit resources accordingly 
in order to support it from the ‘child’ side.

In short: it’s not the availability of up-down what has stalled the 
GTA.

tks!

Carlos

On 8 Sep 2016, at 12:37, Rob Austein wrote:

> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Sandra Murphy <[email-masked]>
Date: Thu, 8 Sep 2016 19:17:27 -0400

speaking as a regular ol’ member:

> On Sep 8, 2016, at 11:57 AM, Carlos M. Martinez <[email-masked]> wrote:
> 
> Hi Rob,
> 
> I’ll let each RIR answer for themselves. In our case (LACNIC), we don’t support up/down. We’ve had a very rough implementation of a ‘parent’ CA for a while, but since there is essentially no demand for it from our members, the project always gets down-prioritized.
> 
> If the GTA was to gain any traction, we’d commit resources accordingly in order to support it from the ‘child’ side.
> 
> In short: it’s not the availability of up-down what has stalled the GTA.

If you had a client side implementation, then if a GTA did get established, you would be able to interact with the GTA for certification of your resources -- immediately.

That may also be why Rob asked his question, I dunno.  It’s why I was interested in the answers.

I think you have said “not yet, but we would 'commit resources accordingly’ ", which is reassuring.  It could mean “make this our highest priority, bar none”.  Good to know.  Of course, it might mean something quite different.

—Sandy, speaking as regular ol’ member

---

From: Andy Newton <[email-masked]>
Date: Fri, 9 Sep 2016 13:28:32 +0000

On Sep 8, 2016, at 7:17 PM, Sandra Murphy <[email-masked]<mailto:[email-masked]>> wrote:

On Sep 8, 2016, at 11:57 AM, Carlos M. Martinez <[email-masked]<mailto:[email-masked]>> wrote:

Hi Rob,

For ARIN, we have code for both sides of the relationship tested against the Dragon software and some of the other RIRs. We allow for delegated CAs today in production, but the vast majority of network operators do not opt for it.

This is the salient point.

Additionally, each RIR must establish and actively maintain a parent-child relationship with each other RIR.

-andy

---

From: Daniel Shaw <[email-masked]>
Date: Mon, 12 Sep 2016 10:20:55 +0400

> For ARIN, we have code for both sides of the relationship tested against the Dragon software and some of the other RIRs. We allow for delegated CAs today in production, but the vast majority of net…

Just a quick note on AFRINIC’s implementation: we do support up-down, and have previously also tested with a couple of other RIRs. Testing was some years ago now.

> This is the salient point.

Yes.

- Daniel