Problem Statement and Considerations for ROAs issued with Multiple Prefixes
draft-yan-sidrops-roa-considerations-03

Document Type Active Internet-Draft (individual)
Last updated 2019-09-10
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: March 13, 2020                        Internet Initiative Japan
                                                                 G. Geng
                                                                  J. Yao
                                                                   CNNIC
                                                      September 10, 2019

   Problem Statement and Considerations for ROAs issued with Multiple
                                Prefixes
                draft-yan-sidrops-roa-considerations-03

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 March 13, 2020.

Yan, et al.              Expires March 13, 2020                 [Page 1]
Internet-Draft    draft-yan-sidrops-roa-considerations    September 2019

Copyright Notice

   Copyright (c) 2019 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 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 March 13, 2020                 [Page 2]
Internet-Draft    draft-yan-sidrops-roa-considerations    September 2019
Show full document text