Re: [sidr] RPKI <-> allocation consistency

[Brian Dickson <[e-mail]>]

On Tue, Sep 4, 2012 at 1:55 PM, Stephen Kent <[e-mail]> wrote:

>
>
>> Make-before-break is fully possible with exclusivity.
>>
> In the general case, the resources are transferred between two CAs, and
> these CAs need not be
> ISPs, e.g., they might be RIRs. So, before an ISP can issue ROAs for the
> newly-received INRs,
> the ISP has to have these INRs added to it's CA cert. If the parent of
> that CA was not the parent
> for the ISP that previously held the resources, then it too has to have
> the INRs in question added
> to its cert, and so on. Thus means that, in general, there will be more
> that one CA, at corresponding
> tiers of the RPKI, that will have the same INRs in their 3779 extensions.
> Equivalently, this means
> that some CA will have issued certs to two of its children, where the
> certs overlap (wrt the INrs
> being transferred).


Let's work a straw man example.

First, the assumptions:
(1) We have existing delegations, CA_1A -> CA_1B -> CA_1C
(2) The 3779 extensions of each of these includes some INR, call it
INR_A.B.C.D/N (with exact match on each delegation)
(3) The whole of INR_A.B.C.D/N is being moved somewhere else
(3a) IMPORTANT => No "hole" in an original INR is going to exist, i.e.
there does not exist some A.B.C.E/(N-M) which covers A.B.C.D/N, which is an
INR in the 3779 of CA_1A, CA_1B, or CA_1C.
(4) It is possible to update a {CA, manifest, CRL} set to replace an
earlier instance of {CA, manifest, CRL} which includes the same set of
INRs, with different INR delegations. This is the basic mechanism for
allocation or reaping INRs.
(5) Moving an INR from CA_X to CA_Y, where CA_X and CA_Y are both children
of CA_W, is possible in a single move (using step (4) mechanics).

In all of the following, if the letter N appears in an object's name, it
means the 3779 extension includes A.B.C.D/N.

First, step by step, create new CA objects and "move" the INR up the tree
using them in an iterative fashion:
CA_1A->CA_1B->{CA_1C', CA_1CN} where CA_1CN contains *only* INR_A.B.C.D/N,
and CA_1C' no longer has A.B.C.D/N in its 3779.
CA_1A->{CA_1B', CA_1BN}
{CA_1A', CA_1AN} (signed by CA_1A's RIR or by root TAL)

Now, move the INR to the new CA parent, and then move it down the tree to
its final location (each X' is X plus 3779 addition of A.B.C.D/N):
{CA_2A, CA_2AN}
CA_2A'->{CA_2B, CA_2BN}
CA_2A'->CA_2B'->{CA_2C, CA_2CN}

And finally merge the new INR with its new owner's main CA:
CA_2A->CA_2B->CA_2C' (with CA_2C' being CA_2C plus 3779 addition of
A.B.C.D/N)

I think the above steps can be reduced to one move, where the original INR
is removed from CA_1A and added to CA_2A, as long as all the descendants of
CA_2A already had the INR included (but not validating since the
parent-most CA didn't yet have the INR in the 3779 extension).

-----

However, if there *is* a need for the old parents to cover the INR, then
the semantics are missing explicit hole-punching.

Hole-punching is needed to disambiguate overlapping certs, so as to assure
RPs the uniqueness of INRs.

A "hole" is the positively-asserted proven non-existence of permitted
matching INRs, and need to be "glued" to matching (covering) INRs wherever
INRs are delegated.

Let me know if I need to go into more detail on "hole" semantics.

(Holes are less common today than they were 15 years ago, but they are
still critical to any kind of resource validation methodology, to avoid the
entire hijacking issue.)

Brian


>
>  Exclusivity enforced at the CA level still allows for multiple ROAs (and
>> thus multiple announcing AS).
>>
> Since this is not just a ROA question, I am ignoring the parts of your
> message that focus on ROAs, or on
> BGP details that seem to be the result of this (confused) focus.
>
> Steve
>