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

["Roque Gagliano (rogaglia)" <[e-mail]>]

Terry,

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

Hey Roque,

On 7/06/12 5:53 PM, "Roque Gagliano (rogaglia)" <[e-mail]<mailto:[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?

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

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

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

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

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

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?

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


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

Terry