Re: [sidr] RPKI <-> allocation consistency

[Brian Dickson <[e-mail]>]

On Fri, Aug 31, 2012 at 9:24 AM, Tim Bruijnzeels <[e-mail]> wrote:

> Hi,
>
> On 31 Aug 2012, at 14:34, Brian Dickson wrote:
>
> So, does it not make sense that the RPKI, meaning its design,
> architecture, procedures, etc., should actually enforce exclulsivity?
>
>
> I think that INRs appearing on certs in multiple locations, different TAs,
> or different branches, are not really a *technical* problem. Meaning that
> if these certs are used to sign objects they are just complementary. It
> doesn't matter whether one CA signs a set of objects or the same set
> (content) is signed by multiple CAs. Plus, this feature is actually needed
> when doing make-before-break transfers of live networks.
>
>
I think maybe it would help to do a worked example (straw man), on an
example where a live network would be transitioned from one CA to another
(versus one ASN to another).

Do you have an example in mind?

I think distinguishing PI vs PA (semantic attributes, but necessarily
something to consider) in detailing the straw man would help.

Are you thinking of situations where the owner (organization) changes but
the announcing ASN does not?
Or where the ASN changes but the owner (organization) does not?
Or where both owner and ASN change?

Thanks,
Brian




> Of course it's important that information is correct. But the notion that
> uniqueness of resources in the tree guarantees correctness seems
> fundamentally flawed to me. Correctness is assumed by transitive trust
> placed in the TA(s), and can only be manually verified by comparing certs
> to public registration databases.
>

If correctness cannot be confirmed via automated mechanism, this is a fatal
scaling flaw.

Or do you mean that this is a corollary of the uniqueness? In which case, I
don't see how you reach that conclusion, and it would be helpful to show
the steps in getting there.

Brian

P.S. I'm arguing not only uniqueness, but completeness, i.e. that the
entire number space must be enumerated, where the state of every number or
block in the space is well defined, and no overlaps occur. Enumeration
would need to occur at each "manifest" level, as either "ROA", "used but no
ROA", "reserved (bogon)", "unassigned", or "delegated", with corresponding
references to actual signed objects. And enumeration must be specifically
possible with minimal cost/effort, so that RPs can confirm the uniqueness
(via the ROA validation prior to rpki-rtr).