Re: [sidr] Reboot: questions regarding WG acceptance of draft-ymbk-rpki-grandparenting-02

[Brian Dickson <[e-mail]>]

Top-reply for convenience:
(This is strictly my opinion/observation and does not represent the
viewpoint of any organization per se)

1. Yes, there is a problem alluded to that might need to be solved.
2. C - no, this draft is not the place to solve the problem.

The root of the problem, is limitations imposed by the design of RFC 3779
for how resources are delegated.

The routing system uses "longest match wins".
The RPKI needs to accommodate the exclusivity of prefixes that are both
routed (as less-specific) and delegated-and-routed (as more-specific).

Specifically, when a resource has some portion of it "forked" (either by
the resource holder, or by any parent of the resource holder), the encoding
of the resource needs to have that "fork" encoded.

The "fork" needs to be "tied" to the resource, in such a way as to prevent
the same resource being available for certification by more than one party.

So, the place to do this is in RFC3779-bis, and inherit the changes
(possibly involving modifications) in the rest of the document suite of
SIDR.

Brian

P.S. Here is a worked example to illustrate this concept:

Suppose the initial state of affairs is as follows:
10.0.0.0/8 is delegated by IANA to RIR "A". RIR "A" does not route any
portion of this block, but only doles out portions of it.
10.1.0.0/16 is delegated by RIR "A" to LIR "A1". Again, not routed.
10.1.0.0/20 is delegated by LIR "A1" to ISP "B". ISP B routes this prefix.
10.1.15.0/24 is delegated by ISP "B" to customer "C". C routes this prefix,
which is more-specific and preferred over 10.1.0.0/20.

Now add to the above, that ISP "B" goes out of business.

The proposed way of directly assigning the 10.1.15.0/24 to "C" would be to
have the delegation done directly to "C" by RIR "A", or by LIR "A1".
(Or by IANA, only included for completeness, i.e. this would likely never
happen.)

And, in order to continue to assure the uniqueness of the assignment, the
corresponding delegations would need to explicitly call out the
NON-delegation of 10.1.15.0/24, attached to the delegation chain starting
wherever the fork occurred.

So, if the direct delegation is done by LIR "A1", the new delegations by A1
would be:
10.1.0.0/20 minus 10.1.15.0/24 (from LIR "A1" to ISP "B" (which is defunct,
presumably, but whose assets might be sold to another party))
10.1.15.0/24 (to "C" directly)

Or if the direct delegation is done by RIR "A", the delegations would be:
10.1.0.0/16 minus 10.1.15.0/24 (from RIR "A" to LIR "A1")
10.1.15.0/24 (from RIR "A" to end-user "C")
10.1.0.0/20 minus 10.1.15.0/24 (from LIR "A1" to ISP "B")

The "minus foo" would need to be attached to any delegation covering "foo",
throughout the delegation hierarchy, once such a "fork" occurs.
ROA validation would need to check this, but the logic is quite simple.

On Fri, Dec 7, 2012 at 11:54 AM, Alexey Melnikov
<[e-mail]>wrote:

> Hi,
> Sorry for procrastinating on this for so long.
>
> Here are questions I would like to ask WG participants. At this point I
> would like to ask people to review the questions and let me know if you
> think they are contradictory. If they are clear, I will poll the WG early
> next week. Comments on the mailing list or sent directly to WG chairs <
> [e-mail]> are welcome.
>
> ----------------
>
> 1) Is the problem described/solved by draft-ymbk-rpki-**grandparenting-02
> actually a problem that the WG needs to address? (Answer: yes or no.
> Additional information is welcomed, but I don't want people to repeat the
> whole discussion.)
>
> 2) If you answered "yes" to the question #1, please also answer the
> following question:
>
> Is draft-ymbk-rpki-**grandparenting-02 a reasonable starting point to
> become a WG document? Please choose one of the following:
>
>
> a) Ready for Adoption (whether or not you have some specific issues with
> it. Also, this answer is unrelated to whether this should be a separate
> draft or a part of an existing draft).
>
> b) Needs more work BEFORE Adoption
>
> c) Should not be adopted. In particular this mean that you don't believe
> any amount of work on the proposed draft will address your issues. So any
> solution to this problem should be a new draft written from scratch.
>
> d) Abstain/don't care
>
>
> 3) If you answered "a" or "b" above, please also answer the following
> question:
>
> Does this need to be in a standalone draft, or can it be incorporated into
> another existing WG draft? When answering this question please only base
> your answer on technical reasons, in particular please leave the decision
> on who is going to edit the document (if it is standalone) to WG chairs.
>
>
> ______________________________**_________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr>
>