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

From: Alexey Melnikov <[email-masked]>
Date: Fri, 07 Dec 2012 16:54:06 +0000

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 <[email-masked]> 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.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 7 Dec 2012 12:32:03 -0500

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
<[email-masked]>wrote:

> 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 <
> [email-masked]> are welcome.
>
> ----------------
>
> 1) Is the problem described/solved by draft-ymbk-rpki-**grandparenting-02
> Additional information is welcomed, but I don't want people to repeat the
> whole discussion.)
>
> Is draft-ymbk-rpki-**grandparenting-02 a reasonable starting point to
> 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
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/sidr<https://www.ietf.org/mailman/listinfo/sidr>
>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 7 Dec 2012 17:17:54 -0500

clarifying question in your example...

> wherever the fork occurred.

you mean a CRL would be updated with the previous certificate for 10.1.15.0/24 ?
So, you are essentially saying:
"Grandparenting == re-delegation + break-old-delegation-cert" ? (seems
ok to me...)

> ROA validation would need to check this, but the logic is quite simple.

or just adhere to the crl, right?

> On Fri, Dec 7, 2012 at 11:54 AM, Alexey Melnikov <[email-masked]>
> wrote:
>>
>> Hi,
>> next week. Comments on the mailing list or sent directly to WG chairs
>> <[email-masked]> are welcome.
>>
>> ----------------
>>
>> Is draft-ymbk-rpki-grandparenting-02 a reasonable starting point to become
>> a WG document? Please choose one of the following:
>>
>>
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/sidr
>
>
>
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: Byron Ellacott <[email-masked]>
Date: Wed, 12 Dec 2012 04:48:42 +0000

Hi Alexey,

These questions seem reasonable to me.  Did you want answers now, too?

  Byron

On 08/12/2012, at 2:54 AM, Alexey Melnikov <[email-masked]> wrote:

> 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 <[email-masked]> 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).
> 
> 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.
> 
>