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

[Terry Manderson <[e-mail]>]

Hey Roque,

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

> On Jun 7, 2012, at 7:54 AM, Terry Manderson 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:
> "   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."

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