Re: [Sidrops] [WG ADOPTION] draft-yan-sidrops-roa-considerations - 04/16/2021

[Taiji Kimura <[e-mail]>]

Hi,

Tim's points sound to me.

I support adoption to discuss further on avoiding complexity
on processing ROA.

 -- kimura taiji

On 2021/03/29 23:06, Tim Bruijnzeels wrote:
> Hi,
> 
> I am not sure yet whether this should be a separate RFC in the end, or that this should be considered with other BCP work. But I support adoption so this can be discussed more thoroughly.
> 
> I have a number of comments / requests for clarity, most importantly:
> 
> = revocation?
> 
>    A large number of experiments for the process of ROA issuance have
>    been made on our RPKI testbed, it is found that the misconfigurations
>    during the issuance may cause the ROAs which have been issued to be
>    revoked.
> 
> I don't see how the ROAs would be revoked in this context. I think the problem is that ROAs which contain multiple prefixes can become invalid if one of the prefixes is lost by the issuing CA and the ROA is seen to 'over-claim'.
> 
> I.e. the problem that I see is fate-sharing. This has been discussed in the past and the advice - in general - was to issue ROAs on a per prefix basis if possible. Unless of course, as the authors also say, this would result in 100s of ROAs. There is a tradeoff to be considered.
> 
> 
> = analysis
> 
> It looks like an analysis was included in version -02 but has since been removed.
> 
> For the analysis I would like to raise that multi-prefix ROAs are not always a problem. The issue (that I see) arises when a parent shrinks a CA certificate before the child CA realizes this. This is an issue for remote children using RFC 6492 - they may find that the parent has already shrunk their certificate.
> 
> However, for hosted CAs where the parent and children live in the same system it is achievable to make sure that child CAs re-issue ROAs in advance of the parent re-issuing their CA certificate. So, the problem may never come up there. Meaning that just the occurrence of multi-prefix ROAs in such system is not necessarily an issue.
> 
> = redundant transmission?
> 
> From the document:
> 
>    That is to say, the update of the ROA containing multiple
>    IP address prefixes will lead to redundant transmission between RP
>    and BGP routers
> 
> I am not sure what the authors mean here. The RTR protocol is based on validated ROA prefixes (VRPs) (section 5.6/5.7 of RFC 8210). If there are ROA objects with many prefixes, then replacing those ROAs does not necessarily result in a lot of churn to the routers. Meaning if a ROA is replaced then only the difference in VRPs is sent to the router.
> 
> 
> Kind regards,
> Tim
> 
> 
> 
> 
>> On 26 Mar 2021, at 18:38, Chris Morrow <[e-mail]> wrote:
>>
>>
>> Howdy WG Folken,
>> The authors of:
>>  https://datatracker.ietf.org/doc/html/draft-yan-sidrops-roa-considerations
>>
>> had asked a while ago (probably 5 revisions ago :( ) for WG Adoption
>> of their draft. The draft abstract is:
>>
>>  "The address space holder needs to issue an ROA object when it
>>   authorizes one or more ASes to originate routes to multiple prefixes.
>>   During the process of ROA issuance, the address space holder needs to
>>   specify an origin AS for a list of IP prefixes.  Besides, the address
>>   space holder has a free choice to put multiple prefixes into a single
>>   ROA or issue separate ROAs for each prefix based on the current
>>   specification.  This memo analyzes and presents some operational
>>   problems which may be caused by the misconfigurations of ROAs
>>   containing multiple IP prefixes.  Some suggestions and considerations
>>   also have been proposed."
>>
>> a) Please consider this a WG Call for Adoption of this draft.
>>
>> 2) Please take a few moments to read the ~5 page draft and send along comments/
>> questions/complaints(in the form of fixed text) to the authors.
>>
>> iii) this call expires 04/16/2021 - April 16 2021
>>
>> Thanks!
>> -chris
>> wg-chair-persona
>>
>> _______________________________________________
>> Sidrops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops
>