Terry, On Jun 8, 2012, at 2:30 AM, Terry Manderson wrote:
Hey Roque, On 7/06/12 5:53 PM, "Roque Gagliano (rogaglia)" <rogag...@cisco.com<mailto:rogag...@cisco.com>> 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
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
