Hi Roque,
On 8/06/12 11:10 PM, "Roque Gagliano (rogaglia)" <rogag...@cisco.com> 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." Fair enough, although I'm not so sure that it makes sense to > >> 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 comes from probably a bad memory of the early discussions relating to such 'uniqness' issues. >> >>> 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) 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? >> >> 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.). 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
