rfc9455v2.txt   rfc9455.txt 
skipping to change at line 22 skipping to change at line 22
August 2023 August 2023
Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP Avoiding Route Origin Authorizations (ROAs) Containing Multiple IP
Prefixes Prefixes
Abstract Abstract
When using the Resource Public Key Infrastructure (RPKI), address When using the Resource Public Key Infrastructure (RPKI), address
space holders need to issue Route Origin Authorization (ROA) space holders need to issue Route Origin Authorization (ROA)
object(s) to authorize one or more Autonomous Systems (ASes) to object(s) to authorize one or more Autonomous Systems (ASes) to
originate routes to IP address prefix(es). This memo discusses originate BGP routes to IP address prefix(es). This memo discusses
operational problems that may arise from ROAs containing multiple IP operational problems that may arise from ROAs containing multiple IP
prefixes and recommends that each ROA contain a single IP prefix. prefixes and recommends that each ROA contain a single IP prefix.
Status of This Memo Status of This Memo
This memo documents an Internet Best Current Practice. This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the received public review and has been approved for publication by the
skipping to change at line 71 skipping to change at line 71
5. Security Considerations 5. Security Considerations
6. IANA Considerations 6. IANA Considerations
7. Normative References 7. Normative References
Acknowledgements Acknowledgements
Authors' Addresses Authors' Addresses
1. Introduction 1. Introduction
In the RPKI, a ROA, which is a digitally signed object, identifies In the RPKI, a ROA, which is a digitally signed object, identifies
that a single AS has been authorized by the address space holder to that a single AS has been authorized by the address space holder to
originate routes to one or more IP prefixes within the related originate BGP routes to one or more IP prefixes within the related
address space [RFC6482]. address space [RFC6482].
Each ROA contains an asID field and an ipAddrBlocks field. The asID Each ROA contains an asID field and an ipAddrBlocks field. The asID
field contains a single AS number that is authorized to originate field contains a single AS number that is authorized to originate
routes to the given IP address prefix(es). The ipAddrBlocks field routes to the given IP address prefix(es). The ipAddrBlocks field
contains one or more IP address prefixes to which the AS is contains one or more IP address prefixes to which the AS is
authorized to originate the routes. authorized to originate the routes.
If the address space holder needs to authorize more than one AS to If the address space holder needs to authorize more than one AS to
advertise the same set of IP prefixes, multiple ROAs must be issued advertise the same set of IP prefixes, multiple ROAs must be issued
skipping to change at line 107 skipping to change at line 107
routing announcements. Alternatively, for a given asID, it can issue routing announcements. Alternatively, for a given asID, it can issue
a single ROA for multiple routing announcements, or even for all of a single ROA for multiple routing announcements, or even for all of
its routing announcements. Since a given ROA is either valid or its routing announcements. Since a given ROA is either valid or
invalid, the routing announcements for which that ROA was issued will invalid, the routing announcements for which that ROA was issued will
"share fate" when it comes to RPKI validation. Currently, no "share fate" when it comes to RPKI validation. Currently, no
existing RFCs provide recommendations about what kinds of ROAs to existing RFCs provide recommendations about what kinds of ROAs to
issue: one per prefix or one for multiple routing announcements. The issue: one per prefix or one for multiple routing announcements. The
problem of fate-sharing was not discussed or addressed. problem of fate-sharing was not discussed or addressed.
In the RPKI trust chain, the Certification Authority (CA) certificate In the RPKI trust chain, the Certification Authority (CA) certificate
issued by a parent CA to a delegate of some resources may be revoked issued by a parent CA to a delegatee of some resources may be revoked
by the parent at any time, which would result in changes to resources by the parent at any time, which would result in changes to resources
specified in the certificate extensions defined in [RFC3779]. Any specified in the certificate extensions defined in [RFC3779]. Any
ROA object that includes resources that are a) no longer entirely ROA object that includes resources that are a) no longer entirely
contained in the new CA certificate or b) contained in a new CA contained in the new CA certificate or b) contained in a new CA
certificate that has not yet been discovered by Relying Party (RP) certificate that has not yet been discovered by Relying Party (RP)
software will be rejected as invalid. Since ROA invalidity affects software will be rejected as invalid. Since ROA invalidity affects
all routes specified in that ROA, unchanged resources with associated all routes specified in that ROA, unchanged resources with associated
routes via that asID cannot be separated from those affected by the routes via that asID cannot be separated from those affected by the
change in CA certificate validity. They will fall under this invalid change in CA certificate validity. They will fall under this invalid
ROA even though there was no intention to change their validity. Had ROA even though there was no intent to change their validity. Had
these resources been in a separate ROA, there would be no change to these resources been in a separate ROA, there would be no change to
the issuing CA certificate and therefore no subsequent invalidity. the issuing CA certificate and therefore no subsequent invalidity.
CAs have to carefully coordinate ROA updates with updates to a CAs have to carefully coordinate ROA updates with updates to a
resource certificate. This process may be automated if a single resource certificate. This process may be automated if a single
entity manages both the parent CA and the CA issuing the ROAs entity manages both the parent CA and the CA issuing the ROAs
(Scenario D in [RFC8211], Section 3.4). However, in other deployment (Scenario D in [RFC8211], Section 3.4). However, in other deployment
scenarios, this coordination becomes more complex. scenarios, this coordination becomes more complex.
As there is a single expiration time for the entire ROA, expiration As there is a single expiration time for the entire ROA, expiration
will affect all prefixes in the ROA. Thus, changes to the ROA for will affect all prefixes in the ROA. Thus, changes to the ROA for
any of the prefixes must be synchronized with changes to other any of the prefixes must be synchronized with changes to other
prefixes, especially when authorization for a prefix is time bounded. prefixes, especially when authorization for a prefix is time bounded.
Had these prefixes been in separately issued ROAs, the validity Had these prefixes been in separately issued ROAs, the validity
interval would be unique to each ROA, and invalidity would only be interval would be unique to each ROA, and invalidity would only be
affected by reissuance of the specific parent CA certificate that affected by reissuance of the specific issuing parent CA certificate.
issued them.
A prefix could be allowed to originate from an AS only for a specific A prefix could be allowed to originate from an AS only for a specific
period of time, for example, if the IP prefix was leased out period of time, for example, if the IP prefix was leased out
temporarily. This would be more difficult to manage, and potentially temporarily. If a ROA with multiple IP prefixes was used, this would
be more error-prone, if a ROA with multiple IP prefixes was used. be more difficult to manage, and potentially be more error-prone.
Similarly, more complex routing may require changes in asID or routes Similarly, more complex routing may require changes in asID or routes
for a subset of prefixes. Reissuance of a ROA might result in for a subset of prefixes. Reissuance of a ROA might result in
changes to the validity of previously received BGP routes covered by changes to the validity of previously received BGP routes covered by
the ROA's prefixes. There will be no change to the validity of the ROA's prefixes. There will be no change to the validity of
unaffected routes if a) the time-limited resources are in separate unaffected routes if a) the time-limited resources are in separate
ROAs, or b) for more complex routing, each change in asID or a change ROAs, or b) for more complex routing, each change in asID or a change
in routes for a given prefix is reflected in a change to a discrete in routes for a given prefix is reflected in a change to a discrete
ROA. ROA.
The use of ROA with a single IP prefix can minimize these side The use of ROA with a single IP prefix can minimize these side
effects. It avoids fate-sharing irrespective of the cause, where the effects. It avoids fate-sharing irrespective of the cause, where the
parent CA issuing each ROA remains valid and where each ROA itself parent CA issuing each ROA remains valid and where each ROA itself
remains valid. remains valid.
4. Recommendations 4. Recommendations
Unless the CA has good reason to the contrary, an issued ROA SHOULD Unless the CA has good reasons to the contrary, an issued ROA SHOULD
contain a single IP prefix. contain a single IP prefix.
5. Security Considerations 5. Security Considerations
Issuing separate ROAs for independent IP prefixes may increase the Issuing separate ROAs for independent IP prefixes may increase the
file-fetch burden on the RP during validation. file-fetch burden on the RP during validation.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
 End of changes. 7 change blocks. 
9 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.48.