Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Prefixes
draft-ietf-sidrops-roa-considerations-08

Thank you for the work on this document.

Many thanks to Jim Fenton for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/u5jsVYc221FPTkVsJm5WweRqe3M/. As Murray said, please respond to his comments.

I apologize for the ready-fire-aim DISCUSS :-(. As noted in the followup to that I do think that it's worth giving serious consideration to making this document part of BCP 185, though.

--

Thanks for this document, it seems useful. I do have some questions I'd like to invite you to discuss, although I don't consider them blocking to this Informational document. (I would probably make these a DISCUSS if it were intended to be a BCP.)

## COMMENTS

### Section 5, Recommendation to compress

In the security considerations, you reference [GSG17] as a strategy to mitigate file fetch burden. But [GSG17] (a) only claims a very modest compression rate (a little over 6% is what they report for the table they studied) and (b) it only applies in the case where there are topologically-related prefixes that can be compressed together without loss (e.g. the paper talks about compressing together 87.254.32/19, 87.254.32/20, and 87.254.48/20 into 87.254.32/19-20). For this optimization to mitigate the increased burden you talk about, there would have to have been some set of topologically-related prefixes grouped into a single ROA, that were divided into their own ROAs after the application of your recommendation. But this is very close to what you recommend against doing in Section 4! Even if all three of the prefixes (to use the example from [GSG17]) were being actively advertised in BGP, in Section 3 you argue forcefully that fate-sharing is harmful. Let's suppose the assigned user of 87.254.32/20 moved to a different provider, taking their prefix with them. Wouldn't that potentially lead to a problem such as what you're trying to mitigate by recommending individual ROAs? Isn't a so-called compressed ROA in the style of [GSG17], by construction, just a special case of putting multiple prefixes together in one ROA?

So, I have two concerns here: First, the recommendations of [GSG17] are counterproductive to the problem statement in Section 3. Second, in any case, the benefits reported by [GSG17] are seemingly too small to point to it as an effective mitigation for the problem you identify in Section 5.

### Section 4, is maxlen ok at all?

Based on my concerns above, I took a harder look at Section 4. Your second paragraph appears tailored (whether deliberately or not) to avoid ruling out [GSG17]:

   Where announced prefixes align and would permit aggregation, but the
   aggregated one is not announced in Border Gateway Protoco (BGP), it
   is not recommended to aggregate multiple announced prefixes into one
   ROA by adjusting prefix length ([RFC9319] Section 5: Recommendations
   about Minimal ROAs and maxLength).  Instead, each specific announced
   prefix should have its own ROA.

(Nit: "Protocol" misspelled in the draft as "Protoco")

This leaves open the door for the case where the more-specifics and their aggregate *are* announced into BGP, in that case, you allow for the [GSG17] approach to be used. But, per my argument in the previous question, isn't that counterproductive to your goals, since it forces those prefixes to share fate? Here's rewritten text that illustrates how to align the text to this position:

NEW:
   Even where announced prefixes align and would permit aggregation, it
   is not recommended to aggregate multiple announced prefixes into one
   ROA by adjusting prefix length ([RFC9319] Section 5: Recommendations
   about Minimal ROAs and maxLength).  Instead, each specific announced
   prefix should have its own ROA.

Although really, I think if you are convinced by my argument, the better solution would be to remove the paragraph in question, making Section 4 gloriously simple:

4.  Recommendations

   Unless the CA has good reasons to the contrary, the issued ROA SHOULD
   contain a single IP prefix.

and nothing more.

Thanks to Jim Fenton for his ARTART review.  Please respond to that if you haven't already.  (I may have missed it.)

I concur with the DISCUSS about document status.  BCP 14 text in an Informational document seems peculiar.

Thanks for the clarifications. My concerns have been answered.

Thank you to Sean Turner for the SECDIR review.

Thanks for working on this document. 

I just noted that the consensus boilerplate is unknown.

I am sympathetic to Paul's DISCUSS: why not being a BCP ?

Also, I am sure that the BGP expansion in 'Border Gateway Protoco (BGP)" is not required ;-)

(1) I support the point in Paul's DISCUSS (and Rob's comment) about this document being better suited as a BCP.  The content follows the same spirit (recommendations, not requirements) as rfc9319, and §4 refers directly to it.  I strongly suggest that this document be part of BCP 185.


(2) This draft should be marked as replacing draft-yan-sidrops-roa-considerations.


(3) Please also take a look at the rtg-dir review: https://mailarchive.ietf.org/arch/msg/sidrops/8SvQmskOL6xRIjOkSJr9ivG4Na4/

Thanks for the document, I found it easy to parse.

I do however support Paul's discuss and Rob's comment on this - that this may be better suited to a BCP.