Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01

Hi Zhiwei,

> On 25 Apr 2022, at 08:26, Ties de Kock <tdekock@ripe.net> wrote:
> 
> Hi Zhiwei,
> 
>> On 24 Apr 2022, at 04:43, YAN Zhiwei <yanzhiwei@cnnic.cn <mailto:yanzhiwei@cnnic.cn>> wrote:
>> 
>> Hello, Christopher, 
>> Yepp.
>> 
>> And all, 
>> Then if there is any special scenario (from either CA or RP consideration) in which aggregation can maintain stability, please feedback.
> 
> I provided you with motivated scenarios in an off-list thread.
> 
> Instead of a call for more explanation about scenarios where aggregation
> increases stability I feel that the draft should first try to clarify what risks
> the advice tries to guard against.
> 
> For example, in this thread, you mentioned overclaiming. In the off-list thread,
> you mentioned, "if one ROA was signed mistakenly, the influence can be reduced
> if “one-prefix-per-ROA”". It helps if these scenarios are clarified and included
> in the draft.

I have seen the significant changes in -02, and the changes did not address my
issues.

In my opinion, to move forward, this draft needs - at least while drafting - a
more precise overview of what scenarios it tries to improve.

The "Problem statement and Analysis" section has significant issues. As
mentioned earlier, I can not reproduce the issue with traffic between RP and
router. The expiry scenario strikes me as a contrived situation that is either
managed by a CA implementation or reflects CA intent.

While I agree that - depending on the situation - there are motivating reasons
to issue a ROA per prefix, I do not think this draft (sufficiently) supports
this approach.

Kind regards,
Ties de Kock

> 
> Kind regards,
> Ties
> 
> 
>> BR,
>> 
>> YAN Zhiwei
>>  
>> From: Christopher Morrow <mailto:christopher.morrow@gmail.com>
>> Date: 2022-04-22 22:56
>> To: YAN Zhiwei <mailto:yanzhiwei@cnnic.cn>
>> CC: Rob Austein <mailto:sra@hactrn.net>; keyur <mailto:keyur@arrcus.com>; sidrops <mailto:sidrops@ietf.org>
>> Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022
>> 
>> 
>> On Sun, Apr 17, 2022 at 10:52 PM YAN Zhiwei <yanzhiwei@cnnic.cn <mailto:yanzhiwei@cnnic.cn>> wrote:
>> Hello, guys,
>> 
>> As Rob, George, Di and others mentioned, there are two sides to everything. Especially for a security service, the basic motivation of RPKI is for more secured routing system, while it will surely introduce other new risks. We want to optimize it during its designing, but it’s more important to deploy and test it with a more simple logic. I totally agree with Tim, there are some specific situations (…AS0 ROAs for unallocated space that some RIRs publish…) where the resources are more stable and with low risk wrt overclaim, it’s worthy to pack the ROAs together to improve the RP’s efficiency. Then if we have rough consensus about this principles, what we need to do are:
>> 
>> 1) Describe the one-prefix-per-ROA as a basic advice of CA operation;
>> 
>> 2) List the specific scenarios which have low risk wrt overclaim as the optimization situations CA may consider.
>> 
>> 
>> sounds like your advice is: "largely do 1 / prefix", with guidance on when to expand that, perhaps an algorithm even...
>> Is it worth noting that at the top levels there may be more skew toward aggregating  vs singular records? (or would that fall out of the research being done perhaps?)
>> I'm pretty sure a 'one size fits all' will not work :) so your plan seems reasonable to me.
>>  
>> BR,
>> 
>> YAN Zhiwei
>>  
>> From: Rob Austein <mailto:sra@hactrn.net>
>> Date: 2022-03-07 09:06
>> To: Keyur Patel <mailto:keyur@arrcus.com>
>> CC: sidrops@ietf.org <mailto:sidrops@ietf.org>
>> Subject: Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022
>> I support publication of this draft.
>>  
>> Two comments, for whatever they're worth:
>>  
>> 1) In retrospect, the ability to specify multiple prefixes in a single
>>    ROA seems like premature optimization: it's solving a problem I'm
>>    not convinced we really have, at the expense of creating a new one.
>>  
>> 2) I tend to think about the multiple-prefix ROA problem in terms of
>>    "fate sharing": unless all the prefixes involved are in some way so
>>    closely tied to each other that there will never be a change to one
>>    of them that isn't a change to all, they should be separate ROAs.
>>  
>>  
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org <mailto:Sidrops@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org <mailto:Sidrops@ietf.org>
>> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>