SIDR Operations Z. Yan
Internet-Draft CNNIC
Intended status: Informational R. Bush
Expires: October 26, 2021 Internet Initiative Japan
G. Geng
Jinan University
J. Yao
CNNIC
April 24, 2021
Problem Statement and Considerations for ROA containing Multiple
Prefixes
draft-ietf-sidrops-roa-considerations-00
Abstract
The address space holder needs to issue an ROA object when it
authorizes one or more ASes to originate routes to multiple prefixes.
During the process of ROA issuance, the address space holder needs to
specify an origin AS for a list of IP prefixes. Besides, the address
space holder has a free choice to put multiple prefixes into a single
ROA or issue separate ROAs for each prefix based on the current
specification. This memo analyzes and presents some operational
problems which may be caused by the ROAs containing multiple IP
prefixes. Some suggestions and considerations also have been
proposed.
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 October 26, 2021.
Yan, et al. Expires October 26, 2021 [Page 1]
Internet-Draft ROA considerations April 2021
Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem statement and Analysis . . . . . . . . . . . . . . . 3
4. Suggestions and Considerations . . . . . . . . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
8.1. Normative References . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Route Origin Authorization (ROA) is a digitally signed object which
is used to identify that a single AS has been authorized by the
address space holder to originate routes to one or more prefixes
within the address space[RFC6482].If the address space holder needs
to authorize more than one ASes to advertise the same set of address
prefixes, the holder must issue multiple ROAs, one per AS number.
However, at present there are no mandatory requirements in any RFCs
describing that the address space holders must issue a separate ROA
for each prefix or a ROA containing multiple prefixes.
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. The ROAs with
multiple prefixes is a common case that each ROA contains exactly one
Yan, et al. Expires October 26, 2021 [Page 2]
Internet-Draft ROA considerations April 2021
AS number but may contain multiple IP address prefixes in the
operational process of ROA issuance.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Problem statement and Analysis
As mentioned above, the address space holder needs to issue an ROA
object when it authorizes one or more ASes to originate routes to
multiple prefixes. During the process of ROA issuance, the address
space holder always needs to specify an origin AS for a list of IP
prefixes. Besides, the address space holder has a free choice to put
multiple prefixes into a single ROA or issue separate ROAs for each
prefix based on the current specification.
The potential influence of operations of ROAs containing multiple IP
prefixes on BGP routers may be considered. For the ROA containing
multiple prefixes, once increase or delete one <AS, ip_prefix> pair
in it, this whole ROA must be withdrawn and reissued. Through
sychronization with repository, Relying Party (RP) fetches a new ROA
object and then notify and send all the <AS, ip_prefix> pairs in this
ROA to BGP routers. That is to say, the update of the ROA containing
multiple IP address prefixes will lead to redundant transmission
between RP and BGP routers. So frequent update of these ROAs will
increase the convergency time of BGP routers and reduce their
performance obviously.
4. Suggestions and Considerations
The following suggestions should be considered during the process of
ROA issuance:
1) The issuance of ROAs containing a large number of IP prefixes may
lead to instability of BGP routing more easily than ROAs with fewer
IP prefixes even without misconfigurations.
A ROA which contains a large number of IP prefixes is more instable
and vulnerable to misconfigurations, because any update of these
prefixes may cause the issued ROA to be withdrawn. Besides, since
the misconfigurations of ROAs containing a larger number of IP
address prefixes may lead to much more serious consequences (a large-
scale network interruption) than ROAs with fewer IP address prefixes,
it is suggested to avoid issuing ROAs with a large number of IP
address prefixes.
Yan, et al. Expires October 26, 2021 [Page 3]
Internet-Draft ROA considerations April 2021
2) The number of ROAs containing multiple IP prefixes should be
limited and the number of IP prefixes in each ROA should also be
limited.
The extreme case (a single ROA can only contain one IP address
prefix) may lead to too many ROA objects globally, which may in turn
become a burden for RPs to synchronize and validate all these ROA
objects with the fully deployment of RPKI. So it seems that a
tradeoff between the number of ROAs and the number of IP prefixes in
a single ROA should be considered. However, considering the
stability and security of RPKI and BGP routing system is the most
important target, containing one IP address prefix in a single ROA is
recommended if the CA wants to avoids the potential instability and
risks.
3) A safeguard scheme is essential to protect the process of ROA
issuance
A safeguard scheme to protect and monitor the process of ROA issuance
should be considered. At least, when a ROA should be updated by the
address space holder because of the change of IP address prefix, the
CA GUI should warn the user that the ROA which is being created will
invalidate the current BGP announcement in the global BGP.
5. Security Considerations
TBD.
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
Yan, et al. Expires October 26, 2021 [Page 4]
Internet-Draft ROA considerations April 2021
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>.
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
Internet Initiative Japan
Email: randy@psg.com
Guanggang Geng
Jinan University
No.601, West Huangpu Avenue
Guangzhou 510632
China
Email: gggeng@jnu.edu.cn
Yan, et al. Expires October 26, 2021 [Page 5]
Internet-Draft ROA considerations April 2021
Jiankang Yao
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
P.R. China
Email: yaojk@cnnic.cn
Yan, et al. Expires October 26, 2021 [Page 6]
