Re: [Sidrops] AD Review: draft-ietf-sidrops-roa-considerations

[延志伟 <[e-mail]>]

Hello, Warren,
About the cost caused by seperately signing ROA, we made some experiments(just for reference) to see the synchorization latency with different polocies (ROA with a single prefix vs. ROA with multiple prefixes). 
The experiment was tested on the data of lacnic as sample. Lacnic contains 9843 ROAs and 17866 IP prefixes (by July 20th 2022). Since only private address space could be used in test environment, experiment chose the segment of 10.0.0.0/8. For mapping IP prefixes to 10.0.0.0/8 as possible, increasing the MaxLength of IP prefixes by 8 (e.g. 165.98.219.0/24 is changed to 10.165.98.219/32). IP prefixes with MaxLength larger than 24 were ignored. CA issued ROAs with a single prefix and multiple prefixes respectively, the ROAs issued by these two ways contain all IP prefixes mapped to 10.0.0.0/8. RP synchronized 30 times by using RPKI RRDP for each way. 
After each synchronization completed, the cache of RP was deleted. The experiment used two dual-core 4GB RAM servers to test, uses Krill as CA and uses Routinator as RP (one server ran Krill to issue certificates and ROAs, another ran Routinator to synchorize data). The experimental result is shown as following.
   +------------------- +-----------------+-----------------------+
   |             |    ROA with  |    ROA with      |
   |             | a single prefix | multiple prefixes   |
   +--------------------+-----------------+-----------------------+
   |  number of ROAs  |    17866    |     9843       |
   +--------------------+-----------------+-----------------------+
   |synchorization time |   16.62s    |   13.81s        |
   +--------------------+-----------------+-----------------------+
Experimental result shows in cases where using ROA with a single prefix would increase the number of ROAs (of course it will), however, the synchorization latency does not increase obviously.


Additionaly again, as a "informational" draft, the recommendation is not a mandatory requirement, (just reminding people to take care of the consequences of "fate-sharing" caused by containing multiple prefixes in one ROA during operation).


Hope this answer your worries.
BR,
Zhiwei






On Thu, Jan 26, 2023 at 2:35 PM, Russ Housley <[e-mail]> wrote:


Warren:


I'd like to pushback on a few of your comments as document shepherd. See below.


On Jan 8, 2023, at 2:12 PM, Warren Kumari <[e-mail]> wrote:


Hi there, authors (and WG),


Thank you for writing this document.


I think that what it is trying to accomplish is useful; but, unfortunately I think that it needs a fair bit more work to be clear enough to publish.


The entire document seems to be "A ROA is an atomic entity, and can be either be valid or invalid. As a single invalid prefix makes the entire ROA invalid, it is recommended that ROA creators minimize fate-sharing by ensuring that each ROA only contain one prefix. Unfortunately this may not always be feasible, and so this document includes guidance on deciding when to include multiple prefixes in a ROA." (actually, it doesn't really seem to do that latter — Suggestion #2 just seems to say "Well, sometimes you can't, so… ˉ\_(ツ)_/ˉ ")


I do not think that is a great summary. The authors are encouraging operator to put one address block in a ROA, even though the syntax allows several. The authors are not advocating the rejection of ROAs that contain multiple address blocks. I think this guidance is pretty clear in the Introduction.






Me neither; my summary could have been written in a less irreverent manner, but I didn't think that the authors were advocating that. I'm not entirely sure how you got that impression from my summary, but it wasn't intended… 









I think that the suggestions / recommendations section needs a fair bit of work and discussion; I'm trying to decide if I should return the document to the WG for focused discussion or if I should continue to hold it.


There are two suggestionsL


1) It's the most important to guarantee the stability and security of RPKI, and it is recommended to include a single IP prefix in each ROA in default.


2) In some special scenarios, where the resource is very stable, a CA has operational problems producing increased number of individual ROAs, or to avoid the possible affects on RP performance, the CA may choose to aggregate multiple IP prefixes.


You seem to be suggesting the removal of the second one.




No, not at all. 



What I was suggesting it that the document provide guidance to operators to help them evaluate *when* having multiple prefixes in a ROA is appropriate. 



George Michaelson (I believe) provided some text which goes some of the way to addressing this:



"In some special scenarios, for example where the resource ownership

   and route origin state is stable (e.g., the IP addresses of a DNS

   root server and the related AS number), or a CA has operational

   problems producing increased number of individual ROAs, or if the

   goal is to implement fate-sharing for a set of prefixes as a

   deliberate policy then multiple IP prefixes may be grouped into one

   ROA."



I think that that is a good start - I personally think that it should be more detailed, but this does at least provide *some* guidance.  



But if we look at the ROA NuIO8K_wom-_zZ1LKOdYVM9zIvA (https://jdr.nlnetlabs.nl/#/search/NuIO8K_wom-_zZ1LKOdYVM9zIvA ) — this seems to be a ROA allowing  Bezeqint to announce > 4000 prefixes[0]. If I'm the operator of Bezeqint, how do I evaluate the above recommendations? I'm not really clear what "operational problems producing increased number of individual ROAs" means. It is "managing 4,000 individual ROAs is hard? (e.g if I use a 1 year validity, I have to reissue, on average, ~11 per day) Or is it "much of the tooling doesn't do well with this scale"? Or something else? As an operator, how do I figure out if this is safe or not? 



Also, dropped from original text was "or to avoid the possible affects on RP performance."



I'm assuming that someone has done the calculations to figure out what the scale the changes are if everyone does this, but I don't think that I've seen it. 

 E.g if Bezeqint (~4,000 prefixes), and Turkcell (~1,200 prefixes in a ROA) and  BSNL-NIB (~3,700 prefixes in a ROA), and […] all just reissue with a single prefix per ROA what are the implications for RP? 






I acknowledge that the scenarios could use further discussion, but I am not sure that holding this document from IETF Last Call is the best way to get this advice out to all operators.





You have other very actionable comments after these high-level comments. I'm sure the authors will tackle them once the high-level ones are sorted.






George Michaelson has helped by providing a number of suggested edits, and I've also attempted to help by sending PRs (https://github.com/Jooyyaan/RPKI/pulls?q=is%3Apr+)  A number of the PRs are still open, but even without these, the changes between the WGLCed version and the current version are fairly large: 

https://author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-roa-considerations-05&url2=draft-ietf-sidrops-roa-considerations-06&difftype=--html



As noted in https://github.com/Jooyyaan/RPKI/pull/4  :

"Here are some initial grammar suggestions - these are mostly from my AD review, and I'm trying to restrict them to only be editorial. However, as this involves a fairly large amount of text changes, I may want to ask the WG to confirm that I haven't accidentally changed the meaning."





If the chairs are confident that this new version still has WG consensus  (AKA, the changes are just editorial) I'm willing to IETF LC it.  I'd be  *happier* starting IETF LC if someone points me at analysis showing that my concern about the "what if everyone does this?!" is unfounded, but...



W

[0]: Actually, much more likely is that I've completely misunderstood the JDR UI, but I'm not in front of a machine that easily lets me parse this manually… 








Russ