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

[Warren Kumari <[e-mail]>]

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 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.

Again, I do think that the purpose of the document is good. Once it is
sufficiently clear and understandable, I think it will be very useful.

Comments / questions:
1: Abstract:
"This memo analyzes some operational problems which may arise from ROAs
containing multiple IP prefixes and recommends avoiding placing multiple IP
prefixes in one ROA as possible."
I'm unable to parse this — I think that there is a word or phrase missing
before "as possible".
Perhaps: "in one ROA as a possible mitigation" or just s/as possible././ ?


2: Introduction;
"However, at present there are no mandatory requirements describing that
the address space holders must issue a separate ROA for each IP prefix or a
ROA containing multiple IP prefixes."
I'm a little confused by the wording of this, probably because of the
"mandatory requirements describing" phrasing. I think that what you are
trying to say is either:
1: "However, at present there are no mandatory requirements that the
address space holders must issue a separate ROA for each IP prefix."
or
2: "However, at present there is no guidance to assist address space
holders in choosing to issue a separate ROA for each IP prefix or a ROA
containing multiple IP prefixes."
I *think* that you were trying to say #2 (and that this document provides
this)?

3: Problem Statement
I think that this section needs a bunch more references so that people know
what is being discussed — as an example: "A Certification Authority (CA)
may issue a separate ROA for each of its routing announcements." Are you
actually talking about a CA here? When someone starts reading this document
and comes across this sentence I suspect they will be *very* confused… This
needs (at least) references to RFC6480 Section 7.1, 7.3.

4: Suggestions

I think that these suggestions / recommendations are very poorly worded /
unclear.
#1 seems to be a recommendation, but #2 is more of a "if you cannot do #1,
then do this instead", so I think that there is actually only one
recommendation ("Just one prefix per ROA")?

"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."
This is really hard to parse - the recommendation seems to be that, by
default, each ROA should only contain a single prefix. Ok, cool… but it
this really to "to guarantee the stability and security of **RPKI**"? And
is that really the most important thing?
Isn't that the important thing here to ensure that the routing
announcement(s) remain valid and stable? And even if this recommendation is
followed, it doesn't *guarantee* this - it does help mitigate issues /
remove complexity and shared fate, but it doesn't guarantee anything.

"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."

This is really hard to parse, and also really low on detail — from a
readability standpoint it would be improved by changing to "2) In certain
scenarios, for example when the resource is very stable or the CA has
operational problems producing many ROAs, or to mitigate negative effects
on RP performance, the CA may choose to include multiple IP prefixes in a
single ROA."

But, I think that this section requires significantly more text to help an
operator make this / these decisions — are these the only scenarios where
they should include multiple prefixes? How many ROAs is too many (either to
expect a CA to be able to create, or where you might negatively affect
RPs )?   (as an aside, "RP" needs to be expanded / a reference).
In addition, I don't think that including multiple prefixes in a ROA really
counts as "aggregat[ing] multiple IP prefixes." - but this does raise an
important point which is not covered in the document.
If I currently have 1 ROA containing 192.168.0.0/24 and 192.168.1.0/24,
should I be making 2 ROAs (which the document seems to suggest), or should
I make one ROA containing 192.168.0.0/23? Surprisingly, the document makes
no mention of maxLength / RFC9319.

Nits:
1: Intro
O: "In Resource Public Key Infrastructure (RPKI), Route Origin
Authorization (ROA) is the digitally signed object which identifies that a
single Autonomous System (AS) has been authorized by the address space
holder to originate routes to one or more prefixes within the address
space[RFC6482]."

P: "In Resource Public Key Infrastructure (RPKI), a Route Origin
Authorization (ROA) is a digitally signed object which identifies that a
single Autonomous System (AS) has been authorized by the address space
holder to originate routes to one or more prefixes within the address space
[RFC6482]."

C: Grammar nits, but I also changed "a Route Origin Authorization (ROA) is
the digitally signed object " to "a Route Origin Authorization (ROA) is a
digitally object" —  having "the" made it sound like there can only be one
ROA for the address.

2: Problem Statement
2.1: "Besides, the CA certificate issued… "
and
2.2: "Furthermore, the use of ROA with a single IP prefix…"
These both start new paragraphs, and the "Besides" / "Furthermore" make it
sounds like they are continuations of an existing thought. I'd suggest
dropping the "Besides" / "Furthermore" to aid readability…

3: Suggestions
I think that this section title should be "Recommendations", but I'm not
actually sure (see above).

4:  Security Considerations
   "This memo does not give rise to additional security risks."
Really? It seems that suggesting that e.g: people take a ROA with many
thousands of prefixes and create thousands of individual ROAs *could*
theoretically cause stability issues (and so potentially DoS). Also isn't
the whole purpose of this document to make recommendations which improve
stability? If I ignore these recommendations, and my ROA for 192.168.1.0/24
becomes invalid (because I included some other prefixes) causing my route
to fall off the Internet (and so users follow 192.168.0.0/16 to EvilCorp),
isn't that a security consideration?


5:  Acknowledgements
"7.  Acknowledgements

   The authors would like to thanks the valuable comments made by
   members of sidrops WG and the list will be updated later."
It seems like "later" has come - can you please update the Acknowledgements
section?

Thank you again; I know that making edits to address nits can be annoying,
but we are expecting many people to read and review the document, and so
having it polished is important and polite (also, once people start
commenting on nits, they seem to continue :-) )
W