SIDR Operations Z. Yan
Internet-Draft CNNIC
Intended status: Informational R. Bush
Expires: 9 June 2023 IIJ Research Lab & Arrcus, Inc.
G.G. Geng
Jinan University
T. de Kock
RIPE NCC
J. Yao
CNNIC
December 2022
Avoidance for ROA Containing Multiple IP Prefixes
draft-ietf-sidrops-roa-considerations-05
Abstract
In RPKI, the address space holder needs to issue an ROA object when
authorizing one or more ASes to originate routes to IP prefix(es).
During ROA issurance process, the address space holder may need to
specify an origin AS for a list of IP prefixes. Additionally, the
address space holder is free to choose to put multiple prefixes into
a single ROA or issue separate ROAs for each prefix according to the
current specification. 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 June 2023.
Yan, et al. Expires 9 June 2023 [Page 1]
Internet-Draft ROA considerations December 2022
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
4. Suggestions . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 4
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
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].
Each ROA contains an "asID" field and an "ipAddrBlocks" field. The
"asID" field contains one single AS number which is authorized to
originate routes to the given IP address prefixes. The
"ipAddrBlocks" field contains one or more IP address prefixes to
which the AS is authorized to originate the routes. If the address
space holder needs to authorize more than one ASes to advertise the
same set of IP prefixes, the holder must issue multiple ROAs, one for
each AS number. 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.
Yan, et al. Expires 9 June 2023 [Page 2]
Internet-Draft ROA considerations December 2022
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Problem Statement
A Certification Authority (CA) may issue a separate ROA for each of
its routing announcements. Alternatively, for a given ASN, it may
issue a single ROA for multiple routing announcements, or even for
all of its routing announcements. Since a given ROA is either valid
or invalid, the routing announcements for which that ROA was issued
will share fate when it comes to RPKI validation, and operator
practice in this respect may affect the stability and security of
RPKI.
Besides, the CA certificate issued by a parent may be replaced by the
parent at any time resulting in changes in resources. Any ROA object
that includes resources which are a) no longer contained in the new
CA certificate, or b) contained in a new CA certificate that is not
yet discovered by Relying Party (RP) software, will be rejected as
invalid. CAs should carefully coordinate ROA updates with resource
certificate updates. A CA can automate this process if a single
entity manages both the parent CA and the CA issuing the ROAs
(scenario D [[RFC8211] section 3]). However, in other deployment
scenarios, this coordination becomes more complex. Furthermore, for
the ROA containing multiple IP prefixes, the IP prefixes share the
same expiry configuration. If the ROA is not reissued timely, the
whole set of IP prefixes will be affected after expiry.
Furthermore, the use of ROA with a single IP prefix can minimize the
side-effect if prefixes are used in different scenarios or under some
temporary contracts. For example, a prefix could be allowed to be
originated from an AS only for a specific period of time, such as the
IP prefix was leased out temporarily. This would be more difficult
to manage, and potentially be more error prone if the ROA with
multiple IP prefixes was used.
4. Suggestions
The following suggestions should be considered during the process of
ROA issurance:
Yan, et al. Expires 9 June 2023 [Page 3]
Internet-Draft ROA considerations December 2022
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.
5. Security Considerations
This memo does not give rise to additional security risks.
6. IANA Considerations
This document does not request any IANA action.
7. Acknowledgements
The authors would like to thanks the valuable comments made by
members of sidrops WG and the list will be updated later.
This work was supported by the Beijing Nova Program of Science and
Technology under grant Z191100001119113.
This document was produced using the xml2rfc tool [RFC2629].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Yan, et al. Expires 9 June 2023 [Page 4]
Internet-Draft ROA considerations December 2022
[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification
Authority (CA) or Repository Manager in the Resource
Public Key Infrastructure (RPKI)", RFC 8211,
DOI 10.17487/RFC8211, September 2017,
<https://www.rfc-editor.org/info/rfc8211>.
8.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<https://www.rfc-editor.org/info/rfc2629>.
Authors' Addresses
Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
P.R. China
Email: yanzhiwei@cnnic.cn
Randy Bush
IIJ Research Lab & Arrcus, Inc.
Email: randy@psg.com
Guanggang Geng
Jinan University
No.601, West Huangpu Avenue
Guangzhou
510632
P.R. China
Email: gggeng@jnu.edu.cn
Ties de Kock
RIPE NCC
Stationsplein 11
Amsterdam
Netherlands
Email: tdekock@ripe.net
Yan, et al. Expires 9 June 2023 [Page 5]
Internet-Draft ROA considerations December 2022
Jiankang Yao
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
P.R. China
Email: yaojk@cnnic.cn
Yan, et al. Expires 9 June 2023 [Page 6]
