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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-sidrops-roa-considerations-08, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-05-10):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-roa-considerations@ietf.org, housley@vigilsec.com, keyur@arrcus.com, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Avoidance of ROA Containing Multiple IP Prefixes) to Best Current Practice


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'Avoidance of ROA Containing Multiple IP
Prefixes'
  as Best Current Practice

Note that this is the second IETF LC for this document - this first one went
through as Informational, but the (strong) feedback from the IESG Eval was
that it read much more like a BCP.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-05-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  When using the Resource Public Key Infrastructure (RPKI), address
  space holders need to issue Route Origin Authorization (ROA)
  object(s) to authorize one or more Autonomous Systems (ASes) to
  originate routes to IP address prefix(es).  This memo discusses
  operational problems which may arise from ROAs containing multiple IP
  prefixes and recommends that each ROA contains a single IP prefix.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc3779: X.509 Extensions for IP Addresses and AS Identifiers (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc6482: A Profile for Route Origin Authorizations (ROAs) (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc8211: Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) (Informational - Internet Engineering Task Force (IETF))

There was strong feedback during IESG Eval that this document reads like a BCP, and should be on the BCP track.
This will require a second IETF LC.

[Ballot comment]
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.

[Ballot discuss]
Adding a discussion point: considering that this document contradicts the recommendation in RFC 9319, which is a BCP, shouldn't it update RFC 9319, and shouldn't it be a BCP?

The BCP issue has already been raised, but I don't think the update thing has been mentioned. It seems as though it's the kind thing to do for users of BCP 185 -- it's the way we have, in our document set, of saying "oh hi, please don't assume all the information is just in this document here, please go check there too".

[Ballot comment]
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 ;-)

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
(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/

[Ballot discuss]
From the abstract, it seems this document is strongly urging some best practise. Why is this document Informational and not a BCP ? Unfortunately, the shepherd did not explain that.

  Any ROA object that includes resources which are a) no longer contained in the new CA certificate, or b) [...] , will be rejected as invalid.

Isn't a) the normal expected case? I understand case b) but why is case a) listed here? Or is this saying a ROA with 10 prefixes, of which 1 prefix is no
longer in the parent CA, will cause the entire ROA with 10 prefixes to be invalid, and not retain 9 valid prefixes? If so, I think the text should be clarified
to say that more clearly. If no so, then I think this case should be omitted from the sentence as it wouldn't be relevant to a "problem case".

[Ballot comment]
Thanks for this document.  Another easy to read and informative document on best operational practice.

I guess my only question is one of document status, i.e., whether this document would be more helpful as a BCP? I.e., whether that would help drive adoption/deployment.

Regards,
Rob

Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Dale Worley. Sent review to list. Submission of review completed at an earlier date.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-sidrops-roa-considerations-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist

The following Last Call announcement was sent out (ends 2023-02-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-roa-considerations@ietf.org, housley@vigilsec.com, keyur@arrcus.com, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Avoidance for ROA Containing Multiple IP Prefixes) to Informational RFC


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'Avoidance for ROA Containing Multiple IP
Prefixes'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-02-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  When using the RPKI, address space holders need to issue ROA
  object(s) to authorize one or more ASes to originate routes to IP
  prefix(es).  This memo discusses operational problems which may arise
  from ROAs containing multiple IP prefixes and recommends that each
  ROA contain a single IP prefix.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-roa-considerations/



No IPR declarations have been submitted directly on this I-D.

Shepherd Write-up for draft-ietf-sidrops-roa-considerations-05


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Informational.  Yes, the header calls for Informational RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  In Resource Public Key Infrastructure (RPKI), the IP address space
  holder needs to issue a Route Origin Authorization (ROA) to
  authorize one or more Autonomous System (AS) to originate routes for
  IP prefixes.  During the ROA issurance process, the address space
  holder may specify an origin AS for a list of IP prefixes.  The
  address space holder can choose to put multiple prefixes into
  a single ROA or issue separate ROAs for each prefix.  This memo
  analyzes some operational problems that may arise when ROAs contain
  multiple IP prefixes, and it recommends against placing multiple IP
  prefixes in one ROA, even though the RPKI specifications allow the
  address holder to do so.

  Working Group Summary:

  There is consensus for this document in the SIDRops WG.

  Document Quality:

  ROAs that follow the recommendation in this memo have been tested
  with several tools; no errors or concerns were found.
   
  Personnel:

  Russ Housley is the document shepherd.
  Warren Kumari is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document after
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SIDRops WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document does not use any RFC 2119 keywords; however, it includes
  RFC 2119 boilerplate text.  The boilerplate text should probably be
  dropped.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.

Shepherd Write-up for draft-ietf-sidrops-roa-considerations-05


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Informational.  Yes, the header calls for Informational RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  In Resource Public Key Infrastructure (RPKI), the IP address space
  holder needs to issue a Route Origin Authorization (ROA) to
  authorize one or more Autonomous System (AS) to originate routes for
  IP prefixes.  During the ROA issurance process, the address space
  holder may specify an origin AS for a list of IP prefixes.  The
  address space holder can choose to put multiple prefixes into
  a single ROA or issue separate ROAs for each prefix.  This memo
  analyzes some operational problems that may arise when ROAs contain
  multiple IP prefixes, and it recommends against placing multiple IP
  prefixes in one ROA, even though the RPKI specifications allow the
  address holder to do so.

  Working Group Summary:

  There is consensus for this document in the SIDRops WG.

  Document Quality:

  ROAs that follow the recommendation in this memo have been tested
  with several tools; no errors or concerns were found.
   
  Personnel:

  Russ Housley is the document shepherd.
  Warren Kumari is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document after
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SIDRops WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.

  This document does not use any RFC 2119 keywords; however, it includes
  RFC 2119 boilerplate text.  The boilerplate text should probably be
  dropped.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  No.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  No updates to the IANA registries are needed.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None are needed.