Re: [Sidrops] [WGLC] draft-ietf-sidrops-roa-considerations-01 - Ends 10/March/2022

[YAN Zhiwei <[e-mail]>]

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.

BR,



YAN Zhiwei
 
From: Rob Austein
Date: 2022-03-07 09:06
To: Keyur Patel
CC: [e-mail]
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.