Subject: [sidr] draft-ymbk-rpki-grandparenting-00.txt

From: Randy Bush <[email-masked]>
Date: Wed, 06 Jun 2012 07:00:28 -0700

this draft is relevant to the sidr wg work and i, as author, request it
be made a work item.

randy

From: [email-masked]
To: [email-masked]
Subject: New Version Notification for draft-ymbk-rpki-grandparenting-00.txt
Message-ID: <[email-masked]>
Date: Wed, 06 Jun 2012 06:59:03 -0700

A new version of I-D, draft-ymbk-rpki-grandparenting-00.txt has been succes=
sfully submitted by Randy Bush and posted to the IETF repository.

Filename:	 draft-ymbk-rpki-grandparenting
Revision:	 00
Title:		 Responsible Grandparenting in the RPKI
Creation date:	 2012-06-06
WG ID:		 Individual Submission
Number of pages: 5

Abstract:
   There are circumstances in RPKI operations where a resource holder&#39;s
   parent may not be able to, or may not choose to, facilitate full and
   proper registration of the holder&#39;s data.  As in real life, the
   holder may form a relationship to their grandparent who is willing to
   aid the grandchild.  This document describes simple procedures for
   doing so.

The IETF Secretariat

---

From: Byron Ellacott <[email-masked]>
Date: Thu, 7 Jun 2012 12:58:19 +1000

Hi Randy,

Why does the draft require that C's certificate not be modified to reflect the update in recorded holder of the INRs at A?  That would seem to be in disagreement with RFC 6484, to me.

  Byron

---

From: Terry Manderson <[email-masked]>
Date: Wed, 6 Jun 2012 22:54:19 -0700

Hi Randy,

I'm presuming that there are cases that prompt you to write this draft as
BCP. Are you able to elaborate on why (using the nomenclature from your
example)  "A" wouldn't re-issue the rpki certificate to "C" to be
"10.42.0.0/23,10.42.4.0/22,10.42.8.0/21,10.42.16.0/20,10.42.32.0/19,10.42.64
.0/18,10.42.128.0/17" (ie the 10.42.0.0/16 resources minus "C's" /23) and a
certificate to G of "10.42.2.0/23" since both "A" and "C" are in agreement
that "G" retains that prefix?

Or is this what you are trying to describe?

So far the wording seems (to me) that some certificate state will eventuate
that "A" issues a certificate for the 10.42.0.0/16 to "C" _AND_ creates a
10.42.2.0/23 resulting object (ROA etc) on "G's" behalf as a subordinate
object of "A's" 10/8?

I'm not sure that was the intent of the RPKI? Was it?

Cheers
Terry

On 7/06/12 12:00 AM, "Randy Bush" <[email-masked]> wrote:

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

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Thu, 7 Jun 2012 07:53:13 +0000

Terry,

On Jun 7, 2012, at 7:54 AM, Terry Manderson wrote:

Hi Randy,

I had the same reaction as you. I looked at the CP document and the Cert. Profile. The best reference to this use-case is the second paragraph of the Security Section on RFC 6487:

"   A resource certificate PKI cannot in and of itself resolve any forms
   of ambiguity relating to uniqueness of assertions of rights of use in
   the event that two or more valid certificates encompass the same
   resource.  If the issuance of resource certificates is aligned to the
   status of resource allocations and assignments, then the information
   conveyed in a certificate is no better than the information in the
   allocation and assignment databases."

My understanding of Randy's proposal is that both C and G will have for a period of time the "right of use" for the 10.42.2.0/23 address space. Your proposal on the first paragraph is an alternative but I would say that it will be much harder to "make before break".

Roque

Cheers
Terry

On 7/06/12 12:00 AM, "Randy Bush" <[email-masked]<mailto:[email-masked]>> wrote:

randy

From: [email-masked]<mailto:[email-masked]>
To: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-ymbk-rpki-grandparenting-00.txt
Message-ID: <[email-masked]<mailto:[email-masked]>>
Date: Wed, 06 Jun 2012 06:59:03 -0700

Abstract:

The IETF Secretariat
_______________________________________________
sidr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sidr

---

From: Terry Manderson <[email-masked]>
Date: Thu, 7 Jun 2012 17:30:29 -0700

Hey Roque,

On 7/06/12 5:53 PM, "Roque Gagliano (rogaglia)" <[email-masked]> wrote:

> I had the same reaction as you. I looked at the CP document and the Cert.
> Profile. The best reference to this use-case is the second paragraph of the
> Security Section on RFC 6487:

Thanks for that. But aren't we ultimately talking about _who_ issues the
ROAs and what their contents are in relation to the intent of the resource
user?

BTW, My understanding of that paragraph was about situations where you have
trust anchors that overlap.

> My understanding of Randy's proposal is that both C and G will have for a
> period of time the "right of use" for the 10.42.2.0/23 address space.

The idealistic stance might be that the RPKI and associated drafts should
not recommend a situation of ambiguity. Being able to have two different
ROAs (with different ASNs) for the same prefix issued by EE certs from
different res certs (thus different private keys) seems like it is making
life tough for the relying party.

>Your 
> proposal on the first paragraph is an alternative but I would say that it will
> be much harder to "make before break".

Is it?

So step wise since G is moving ISPs from C to A (and they originate the
route on G's behalf):

1) "C" has the 10.42.0.0/16, presumably ROA issued for 10.42.2.0/23, AS-'C'
(10.42.2.0/23 AS-"C" route VALID)
1.5) Worst case of "A" is slow between revoking/reissuing C's cert (all
routes UNKNOWN, but still routable)
2) "C" gets new cert from "A" for
10.42.0.0/23,10.42.4.0/22,10.42.8.0/21,10.42.16.0/20,10.42.32.0/19,10.42.64.
0/18,10.42.128.0/17. And recreates it's own ROAs (10.42.2.0/23 AS-"A" route
UNKNOWN)
3) "A" (on G's behalf) issues ROA for 10.42.2.0/23, AS-'A' (10.42.2.0/23
route VALID)

I think this is a very easy for a relying party to interpret, and 'get it
right'

If a recommendation comes forth that says:

step wise:
1) "C" has the 10.42.0.0/16, presumably ROA issued for 10.42.2.0/23, AS-'C'
(10.42.2.0/23 route VALID)
2) "A" on behalf of "G" issues ROA for 10.42.2.0/23, AS-'A' while ROA issued
for 10.42.2.0/23, AS-'C' exists (10.42.2.0/23 originated by both AS-"C" and
AS-"A" valid)
3) C removes the ROA 10.42.2.0/23, AS-'C' (10.42.2.0/23 originated by
AS-"G")

Keeping in mind that the example highlights that "C" is moving away from
provider "A", but keeping its address space. So at the point 2 is it clear
what is the intention of the IP address user "G"? Who it seems has no skin
in the game as "G" doesn't have a RPKI private key nor certificate.

I'm not sure (right now) that allowing multiple 'resource holders' to create
valid MOAS scenarios is a good idea. I accept MOAS do naturally exist, but
generally at the desire of one single resource holder or at least one would
hope.

Is my interpretation wrong here? Is this really just harmless? or does this
also then tease out political[*] aspects where an RIR can or might
'responsibly' issue RPKI objects from their own resource cert?

[*] yes, yes, the IETF is not a politically focused organisation. ;)

Terry

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Fri, 8 Jun 2012 13:10:20 +0000

Terry,

On Jun 8, 2012, at 2:30 AM, Terry Manderson wrote:

Hey Roque,

On 7/06/12 5:53 PM, "Roque Gagliano (rogaglia)" <[email-masked]<mailto:[email-masked]>> wrote:

This is more a question for Randy.

IMHO, his text says both:
"A may certify G's resources, or issue one or more EE certificates and ROAs for G's resources. Which is done is a local matter between A and G."

Your english is definitely better than mine, but I do not find any reference to trust anchors. I think it applies generally to any registry database.

How would a RP check this? (think particularly on bottom-up fetch + validation)
What the RFC 6487 security section is basically saying is that you should be at least as good as your registration back-end.

Your

Is it?

Here you break. UNKNOWN/NOT FOUND may have a different policy (loc. pref. ,etc.).

step wise:

I have not written RP software, but I believe it will be harmless as it would validate.  I do not believe iit breaks the CP document as the only reference to "unique holder" that I found was in the abstract section.

All in all, I think it is good that Randy raised this issue. I wonder if we need another document or add it to the "Use Case" document as it has not yet been ship to the IESG.

Roque

Terry

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Jun 2012 04:14:11 -0700

byron and all,

before the wanderings, there were three announcements.
   A  10.0.0.0/8
   C  10.42.0.0/16
   G  10.42.2.0/2 

gonna be hard to convince C to become chopped liver so that G can be
independent.  also gonna be a bit of pollution.

randy

---

From: Randy Bush <[email-masked]>
Date: Sat, 09 Jun 2012 15:30:59 -0700

> before the wanderings, there were three announcements.
                 /24

randy

---

From: Terry Manderson <[email-masked]>
Date: Mon, 11 Jun 2012 17:28:20 -0700

Hi Roque,

On 8/06/12 11:10 PM, "Roque Gagliano (rogaglia)" <[email-masked]> wrote:

> "A may certify G's resources, or issue one or more EE certificates and ROAs
> for G's resources. Which is done is a local matter between A and G."

Fair enough, although I'm not so sure that it makes sense to

> Your english is definitely better than mine, but I do not find any reference
> to trust anchors. I think it applies generally to any registry database.
> 

My understanding comes from probably a bad memory of the early discussions
relating to such 'uniqness' issues.

> How would a RP check this? (think particularly on bottom-up fetch +

As far as I can tell, without experimentation, is that any match would work.

So if both AS 'C' and AS 'G' originate the 10.42.2.0/23 route and both ROAs
may exist, then you have a MOAS event.

> What the RFC 6487 security section is basically saying is that you should be
> at least as good as your registration back-end.
> 

I think you are trying say "we know that G has the resource, but are going
to pretend they don't so we can cut a ROA for G, so that their routing works
but we can be lazy on changing certs to C."

That might not be a bad thing, if there was some way to inhibit C from
creating a ROA, that might mess with G. The idea that securing routing is
based on 'a legitimate holder' [rfc6480] being able to authorize one or more
ASes of its choosing appears to be relaxed in this text. Is that a slippery
slope?

> Here you break. UNKNOWN/NOT FOUND may have a different policy (loc. pref.

OK. lets just say "UNKNOWN". I feel more comfortable in knowing that a RP
can make decision based on unambiguous information. Be that implemented in
local policy application (local pref etc) or otherwise.

> 
> I have not written RP software, but I believe it will be harmless as it would
> validate.  I do not believe iit breaks the CP document as the only reference
> to "unique holder" that I found was in the abstract section.

Indeed. I always considered the holder to be very singular in nature.

> 
> All in all, I think it is good that Randy raised this issue. I wonder if we
> need another document or add it to the "Use Case" document as it has not yet
> been ship to the IESG.

Good question.

T.

---

From: Terry Manderson <[email-masked]>
Date: Mon, 11 Jun 2012 17:28:17 -0700

Hi Randy,

>> independent.  also gonna be a bit of pollution.

Can you define 'pollution'? in what sense? In C no longer going to announce
the full /16 aggregate? Is the goal here routing security, or bgp table
growth limitation?

Why does 'C' having their resource certificate list specifically what
resources they are in control of ("chopped liver") and therefore what they
can announce/route have any bearing on something that is a) the antecedent
for routing security, and B) something that is mostly machine generated and
machine parsed?

Cheers
Terry

---

From: "George, Wes" <[email-masked]>
Date: Tue, 12 Jun 2012 09:23:53 -0400

Randy -

I'm thinking that there's a simpler use case for this -

In the situation where A delegated space to C, who delegated it further to G, and G would like help managing data, but C is not willing or able to do so, and so G works with A to make this happen. The concept of changing providers may not be necessary to illustrate the point.

Regarding adoption, I'm not certain I understand from the current text why this can't be incorporated into existing drafts as a brief note. If I'm interpreting this draft correctly, you're saying that there's nothing technically hard about doing this, but that there are some business and contractual issues to deal with, mainly on account of the potentially fractured business relationship between the parties involved, and proper validation of the information you're certifying. But that's true of any relationship where one party certifies on anothers' behalf. What's different about this case that requires it to be treated separately from other operational considerations? I love the "responsible grandparenting" title, but I'm just thinking it's easier for reader and implementer alike if this is consolidated.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Randy Bush
> Sent: Wednesday, June 06, 2012 10:00 AM
> To: sidr wg list
> Subject: [sidr] draft-ymbk-rpki-grandparenting-00.txt
>
> A new version of I-D, draft-ymbk-rpki-grandparenting-00.txt has been
> succes= sfully submitted by Randy Bush and posted to the IETF
> repository.
>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Tue, 12 Jun 2012 16:25:09 +0000

Speaking as a regular ol' wg member:

wrt:

>So if both AS 'C' and AS 'G' originate the 10.42.2.0/23 route and
>both ROAs may exist, then you have a MOAS event.

The architecture specifically allows there to be multiple ROAs for a single prefix.  That was a deliberate choice from long, long ago.

(For a look at the number of occurrences of multiple origins, you can look at http://bgp.he.net/report/multi-origin-routes.  (And thanks to HE for that site, btw.)  It gives a clue into some reasons why multiple origins might occur.)

--Sandy, speaking as regular ol' member

________________________________________
From: [email-masked] [[email-masked]] on behalf of Terry Manderson [[email-masked]]
Sent: Monday, June 11, 2012 8:28 PM
To: Roque Gagliano (rogaglia)
Cc: sidr wg list
Subject: Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt

Hi Roque,

Good question.

T.

---

From: Terry Manderson <[email-masked]>
Date: Tue, 12 Jun 2012 16:29:33 -0700

Hi Sandy,

On 13/06/12 2:25 AM, "Murphy, Sandra" <[email-masked]> wrote:

> The architecture specifically allows there to be multiple ROAs for a single
> prefix.  That was a deliberate choice from long, long ago.

Yes, I understand that - my interpretation and underlying assumption is that
MOAS still exist at the desire of a single resource holder.

While doing what Randy has documented is certainly possible with the current
architecture, I not sure if that in allowing parents and grandparents to be
able to assert a security condition of a MOAS without the full buy-in of the
resource holder is something that should be recommended.

T.

---

From: Andrei Robachevsky <[email-masked]>
Date: Fri, 29 Jun 2012 17:05:41 +0200

Hi Randy,

Randy Bush wrote on 06/06/2012 16:00:
[...]
> 
> Abstract: There are circumstances in RPKI operations where a
> resource holder&#39;s parent may not be able to, or may not choose
> to, facilitate full and proper registration of the holder&#39;s
> data.  As in real life, the holder may form a relationship to their
> grandparent who is willing to aid the grandchild.  This document
> describes simple procedures for doing so.
> 

The procedures make sense, but I am still trying to figure out what
the draft is trying to recommend.

Surely, what is described is technically possible, but it gives RPs no
clue if the procedures were followed. In fact, what a RP may see would
not be "congruent with the number resource allocation framework" [CP].

IMO a clean implementation would necessarily entail punching a hole in
C's certificate. But this is not what the draft recommends.

Andrei

---

From: Randy Bush <[email-masked]>
Date: Fri, 29 Jun 2012 08:44:23 -1000

> C's certificate. But this is not what the draft recommends.

if A and C both ran CAs, and G has used C's CA to issue a cert and ROA
for G's space, then (when C went unresponsive) A could either issue a
ROA to G or a cert and a ROA.  both work.  seems to me to be more a
matter of style than conformity.

it is no more a matter of 'hole punching' than A issuing a ROA for
various sub-pieces of its own space.  

what is interesting is the sharing of responsibility and control, not
that it is a subset of the space.  note that A might have owned a /16
which it then delegated a the whole /16 to C who redelegated the /16 to
G.  look ma, no holes!

randy