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

["Murphy, Sandra" <[e-mail]>]

Speaking as a regular ol' wg member:

wrt:

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

The architecture specifically allows there to be multiple ROAs for a single prefix.  That was a deliberate choice from long, long ago.

(For a look at the number of occurrences of multiple origins, you can look at http://bgp.he.net/report/multi-origin-routes.  (And thanks to HE for that site, btw.)  It gives a clue into some reasons why multiple origins might occur.)

--Sandy, speaking as regular ol' member

________________________________________
From: [e-mail] [[e-mail]] on behalf of Terry Manderson [[e-mail]]
Sent: Monday, June 11, 2012 8:28 PM
To: Roque Gagliano (rogaglia)
Cc: sidr wg list
Subject: Re: [sidr] draft-ymbk-rpki-grandparenting-00.txt

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.