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

[Terry Manderson <[e-mail]>]

Hi Roque,


On 8/06/12 11:10 PM, "Roque Gagliano (rogaglia)" <[e-mail]> 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.