Subject: [sidr] about grandparenting

From: "Murphy, Sandra" <[email-masked]>
Date: Fri, 10 Aug 2012 20:45:43 +0000

speaking as regular ol' member

This is a discussion of grandparenting, NOT a discussion of adoption of the grandparenting draft.

There have been suggestions of several different actions a grandparent might do.  Most of the comments so far focus on issuance of CA certificates to a grandchild.  But there are other actions a grandparent might take.

For example.  One action already mentioned would be issuing ROAs for the grandchild, by the grandparent.  That doesn't disturb the consistency with the allocation system.  We have long discussed that providers might issue ROAs for RPKI-unprepared children.  The RPKI structure allows for multiple ROAs for the same prefix (for multihoming) and for multiple ROAS for more specifics inside the same space signed by the same entity (eg for TE advertisements).  

For example.  The grandparent could also host a CA service for the child.  That's allowed and is currently practiced.  Under that hosted CA service, the grandparent could issue a cert for the grandchild.  The process controlling this would be a matter for the agreement about the hosting service.

For example.  The grandparent could issue a CA cert for the grandchild and reclaim that address space from the child by issuing new CA certs for the child that omit the reclaimed space.   (For: it keeps allocation and RPKI consistent.  Against: it fractures allocations and can produce routing table bloat.)   I think I saw this in one message on the thread.  How, when, where, why, with what proof or limitations - all that is out-of-band process and can vary per situation.

For example.  The grandparent could issue a ROA that it itself was allowed to originate the grandchild's address space, and forward traffic to the child with the expectation that the child will forward traffic to the grandchild.  (This only works in cases where there is continued connectivity from child to grandchild.)   There's no CA cert action there, so it doesn't disturb the consistency with the allocation system.

I presume there are lots of others.

Do we want to try to record the many possibilities?  A complete list (ulp!)?  Reasons for and against certain critical ones?

--Sandy, speaking only as regular ol' member

---

From: Arturo Servin <[email-masked]>
Date: Fri, 10 Aug 2012 18:19:38 -0300

The problem with a grandparent is that it cannot certify a grandchild unless it has specific information about it, normally it would come from the son/daughter.

	I think the idea of the grandparent has good will, but I am not sure that we are following the right path.

Regards,
as

On 10 Aug 2012, at 17:45, Murphy, Sandra wrote:

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

---

From: Andy Newton <[email-masked]>
Date: Tue, 14 Aug 2012 14:07:44 +0000

On Aug 10, 2012, at 4:45 PM, Murphy, Sandra wrote:

> For example.  One action already mentioned would be issuing ROAs for the grandchild, by the grandparent.  That doesn't disturb the consistency with the allocation system.

I'm not speaking for anybody but me here, but I would think that the notion of RIRs issuing "operational" ROAs would be a BIG layer 9 issue.

-andy

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 14 Aug 2012 14:47:53 +0000

speaking as a regular ol' member:

On Tuesday, August 14, 2012 10:07 AM, Andy Newton [[email-masked]] said

>I'm not speaking for anybody but me here, but I would think 
>that the notion of RIRs issuing "operational" ROAs would be 
>a BIG layer 9 issue.

Given all the caveats below.

If you believe RIRs should not issue ROAs, what would be your preferred method to deal with that: (a) relying party policy - reject ROAs signed by x,y,z keys, (b) cert policy - some words in the CP (c) operational - registries promise not to implement a feature in their code that would allow this (d) contractual - the registry agreement promises that they will not do this,  (e) technical - some bits in the RPKI objects, etc.

(Why did you speak of an "operational" ROA?  What would a non-operational ROA be?)

List of caveats:

I presume you aren't implying that you think the RIRs will be the only or the primary members of the RPKI hierarchy.

And of course you are not speaking of the IANA objects that are now published as an RFC.

And of course you are not speaking of RIRs that have decided to run a hosted service for their members, where code on the RIR system is actually doing the signing operations that create ROAs that their members have requested.

And of course you are not speaking of RIRs who hold address space for their own operational purposes, eg for registry servers and such.

In the spirit of the IANA objects, I can see a potential of an RIR signing a ROA for the /8 from which they are allocating (or v6 equivalent) to keep bogus superblock announcements from being accepted.

--Sandy, speaking as regular ol' member

---

From: Andy Newton <[email-masked]>
Date: Tue, 14 Aug 2012 17:33:49 +0000

On Aug 14, 2012, at 10:47 AM, Murphy, Sandra wrote:

> If you believe RIRs should not issue ROAs

For clarification, I personally don't have an opinion on this. It is just my observation that there have been concerns about the roles of RIRs in the RPKI, and this would seem to collide with such concerns.

> , what would be your preferred method to deal with that: (a) relying party policy - reject ROAs signed by x,y,z keys, (b) cert policy - some words in the CP (c) operational - registries promise not to implement a feature in their code that would allow this (d) contractual - the registry agreement promises that they will not do this,  (e) technical - some bits in the RPKI objects, etc.

A, B, C, and D are above my pay grade. E, such as a grandchild bit in a ROA or something, is interesting but I doubt would resolve layer 9 concerns.

> (Why did you speak of an "operational" ROA?  What would a non-operational ROA be?)

ROAs that represent real routes, not things like IANA space. If there is a better term, let me know.

-andy