Problem Statement and Considerations for ROAs issued with Multiple Prefixes
draft-yan-sidrops-roa-considerations-04
|
| Document |
Type |
|
Active Internet-Draft (individual)
|
|
Last updated |
|
2020-03-29
|
|
Stream |
|
(None)
|
|
Intended RFC status |
|
(None)
|
|
Formats |
|
plain text
pdf
htmlized
bibtex
|
| Stream |
Stream state |
|
(No stream defined) |
|
Consensus Boilerplate |
|
Unknown
|
|
RFC Editor Note |
|
(None)
|
| IESG |
IESG state |
|
I-D Exists
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
SIDR Operations Z. Yan
Internet-Draft CNNIC
Intended status: Informational R. Bush
Expires: September 30, 2020 Internet Initiative Japan
G. Geng
J. Yao
CNNIC
March 29, 2020
Problem Statement and Considerations for ROAs issued with Multiple
Prefixes
draft-yan-sidrops-roa-considerations-04
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 misconfigurations of 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 September 30, 2020.
Yan, et al. Expires September 30, 2020 [Page 1]
Internet-Draft draft-yan-sidrops-roa-considerations March 2020
Copyright Notice
Copyright (c) 2020 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
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 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 for 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 September 30, 2020 [Page 2]
Show full document text