summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6482.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6482.txt')
-rw-r--r--doc/rfc/rfc6482.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc6482.txt b/doc/rfc/rfc6482.txt
new file mode 100644
index 0000000..23c46b7
--- /dev/null
+++ b/doc/rfc/rfc6482.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Lepinski
+Request for Comments: 6482 S. Kent
+Category: Standards Track D. Kong
+ISSN: 2070-1721 BBN Technologies
+ February 2012
+
+
+ A Profile for Route Origin Authorizations (ROAs)
+
+Abstract
+
+ This document defines a standard profile for Route Origin
+ Authorizations (ROAs). A ROA is a digitally signed object that
+ provides a means of verifying that an IP address block holder has
+ authorized an Autonomous System (AS) to originate routes to one or
+ more prefixes within the address block.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by
+ the Internet Engineering Steering Group (IESG). Further
+ information on Internet Standards is available in Section 2 of
+ RFC 5741.
+
+ Information about the current status of this document, any
+ errata, and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6482.
+
+Copyright Notice
+
+ Copyright (c) 2012 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
+ (http://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.
+
+
+
+
+
+Lepinksi, et al. Standards Track [Page 1]
+
+RFC 6482 Route Origin Authorization February 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Terminology ................................................3
+ 2. The ROA Content-Type ............................................3
+ 3. The ROA eContent ................................................3
+ 3.1. version ....................................................4
+ 3.2. asID .......................................................4
+ 3.3. ipAddrBlocks ...............................................4
+ 4. ROA Validation ..................................................5
+ 5. Security Considerations .........................................5
+ 6. Acknowledgments .................................................6
+ 7. References ......................................................6
+ 7.1. Normative References .......................................6
+ 7.2. Informative References .....................................6
+ Appendix A: ASN.1 Module..........................................8
+
+1. Introduction
+
+ The primary purpose of the Resource Public Key Infrastructure (RPKI)
+ is to improve routing security. (See [RFC6480] for more
+ information.) As part of this system, a mechanism is needed to allow
+ entities to verify that an AS has been given permission by an IP
+ address block holder to advertise routes to one or more prefixes
+ within that block. A ROA provides this function.
+
+ The ROA makes use of the template for RPKI digitally signed objects
+ [RFC6488], which defines a Crytopgraphic Message Syntax (CMS)
+ [RFC5652] wrapper for the ROA content as well as a generic validation
+ procedure for RPKI signed objects. Therefore, to complete the
+ specification of the ROA (see Section 4 of [RFC6488]), this document
+ defines:
+
+ 1. The OID that identifies the signed object as being a ROA.
+ (This OID appears within the eContentType in the
+ encapContentInfo object as well as the content-type signed
+ attribute in the signerInfo object).
+
+ 2. The ASN.1 syntax for the ROA eContent. (This is the payload
+ that specifies the AS being authorized to originate routes as
+ well as the prefixes to which the AS may originate routes.)
+ The ROA eContent is ASN.1 encoded using the Distinguished
+ Encoding Rules (DER) [X.690].
+
+ 3. An additional step required to validate ROAs (in addition to
+ the validation steps specified in [RFC6488]).
+
+
+
+
+
+Lepinksi, et al. Standards Track [Page 2]
+
+RFC 6482 Route Origin Authorization February 2012
+
+
+1.1. Terminology
+
+ It is assumed that the reader is familiar with the terms and concepts
+ described in "Internet X.509 Public Key Infrastructure Certificate
+ and Certificate Revocation List (CRL) Profile" [RFC5280] and "X.509
+ Extensions for IP Addresses and AS Identifiers" [RFC3779].
+
+ Additionally, this document makes use of the RPKI signed object
+ profile [RFC6488]; thus, familiarity with that document is assumed.
+ Note that the RPKI signed object profile makes use of certificates
+ adhering to the RPKI Resource Certificate Profile [RFC6487]; thus,
+ familiarly with that profile is also assumed.
+
+ 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 RFC
+ 2119 [RFC2119].
+
+2. The ROA Content-Type
+
+ The content-type for a ROA is defined as routeOriginAuthz and has the
+ numerical value of 1.2.840.113549.1.9.16.1.24.
+
+ This OID MUST appear both within the eContentType in the
+ encapContentInfo object as well as the content-type signed attribute
+ in the signerInfo object (see [RFC6488]).
+
+3. The ROA eContent
+
+ The content of a ROA identifies a single AS that has been authorized
+ by the address space holder to originate routes and a list of one or
+ more IP address prefixes that will be advertised. If the address
+ space holder needs to authorize multiple ASes to advertise the same
+ set of address prefixes, the holder issues multiple ROAs, one per AS
+ number. A ROA is formally defined as:
+
+ RouteOriginAttestation ::= SEQUENCE {
+ version [0] INTEGER DEFAULT 0,
+ asID ASID,
+ ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }
+
+ ASID ::= INTEGER
+
+ ROAIPAddressFamily ::= SEQUENCE {
+ addressFamily OCTET STRING (SIZE (2..3)),
+ addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress }
+
+
+
+
+
+Lepinksi, et al. Standards Track [Page 3]
+
+RFC 6482 Route Origin Authorization February 2012
+
+
+ ROAIPAddress ::= SEQUENCE {
+ address IPAddress,
+ maxLength INTEGER OPTIONAL }
+
+ IPAddress ::= BIT STRING
+
+ Note that this content appears as the eContent within the
+ encapContentInfo (see [RFC6488]).
+
+3.1. version
+
+ The version number of the RouteOriginAttestation MUST be 0.
+
+3.2. asID
+
+ The asID field contains the AS number that is authorized to originate
+ routes to the given IP address prefixes.
+
+3.3. ipAddrBlocks
+
+ The ipAddrBlocks field encodes the set of IP address prefixes to
+ which the AS is authorized to originate routes. Note that the syntax
+ here is more restrictive than that used in the IP address delegation
+ extension defined in RFC 3779. That extension can represent
+ arbitrary address ranges, whereas ROAs need to represent only
+ prefixes.
+
+ Within the ROAIPAddressFamily structure, addressFamily contains the
+ Address Family Identifier (AFI) of an IP address family. This
+ specification only supports IPv4 and IPv6. Therefore, addressFamily
+ MUST be either 0001 or 0002.
+
+ Within a ROAIPAddress structure, the addresses field represents
+ prefixes as a sequence of type IPAddress. (See [RFC3779] for more
+ details). If present, the maxLength MUST be an integer greater than
+ or equal to the length of the accompanying prefix, and less than or
+ equal to the length (in bits) of an IP address in the address family
+ (32 for IPv4 and 128 for IPv6). When present, the maxLength
+ specifies the maximum length of the IP address prefix that the AS is
+ authorized to advertise. (For example, if the IP address prefix is
+ 203.0.113/24 and the maxLength is 26, the AS is authorized to
+ advertise any more specific prefix with a maximum length of 26. In
+ this example, the AS would be authorized to advertise 203.0.113/24,
+ 203.0.113.128/25, or 203.0.113.0/25, but not 203.0.113.0/27.) When
+ the maxLength is not present, the AS is only authorized to advertise
+ the exact prefix specified in the ROA.
+
+
+
+
+
+Lepinksi, et al. Standards Track [Page 4]
+
+RFC 6482 Route Origin Authorization February 2012
+
+
+ Note that a valid ROA may contain an IP address prefix (within a
+ ROAIPAddress element) that is encompassed by another IP address
+ prefix (within a separate ROAIPAddress element). For example, a ROA
+ may contain the prefix 203.0.113/24 with maxLength 26, as well as the
+ prefix 203.0.113.0/28 with maxLength 28. (Such a ROA would authorize
+ the indicated AS to advertise any prefix beginning with 203.0.113
+ with a minimum length of 24 and a maximum length of 26, as well as
+ the specific prefix 203.0.113.0/28.) Additionally, a ROA MAY contain
+ two ROAIPAddress elements, where the IP address prefix is identical
+ in both cases. However, this is NOT RECOMMENDED as, in such a case,
+ the ROAIPAddress with the shorter maxLength grants no additional
+ privileges to the indicated AS and thus can be omitted without
+ changing the meaning of the ROA.
+
+4. ROA Validation
+
+ Before a relying party can use a ROA to validate a routing
+ announcement, the relying party MUST first validate the ROA. To
+ validate a ROA, the relying party MUST perform all the validation
+ checks specified in [RFC6488] as well as the following additional
+ ROA-specific validation step.
+
+ o The IP address delegation extension [RFC3779] is present in the
+ end-entity (EE) certificate (contained within the ROA), and each
+ IP address prefix(es) in the ROA is contained within the set of IP
+ addresses specified by the EE certificate's IP address delegation
+ extension.
+
+5. Security Considerations
+
+ There is no assumption of confidentiality for the data in a ROA; it
+ is anticipated that ROAs will be stored in repositories that are
+ accessible to all ISPs, and perhaps to all Internet users. There is
+ no explicit authentication associated with a ROA, since the PKI used
+ for ROA validation provides authorization but not authentication.
+ Although the ROA is a signed, application-layer object, there is no
+ intent to convey non-repudiation via a ROA.
+
+ The purpose of a ROA is to convey authorization for an AS to
+ originate a route to the prefix(es) in the ROA. Thus, the integrity
+ of a ROA MUST be established. The ROA specification makes use of the
+ RPKI signed object format; thus, all security considerations in
+ [RFC6488] also apply to ROAs. Additionally, the signed object
+ profile uses the CMS signed message format for integrity; thus, ROAs
+ inherit all security considerations associated with that data
+ structure.
+
+
+
+
+
+Lepinksi, et al. Standards Track [Page 5]
+
+RFC 6482 Route Origin Authorization February 2012
+
+
+ The right of the ROA signer to authorize the target AS to originate
+ routes to the prefix(es) is established through use of the address
+ space and AS number PKI described in [RFC6480]. Specifically, one
+ MUST verify the signature on the ROA using an X.509 certificate
+ issued under this PKI, and check that the prefix(es) in the ROA match
+ those in the certificate's address space extension.
+
+6. IANA Considerations
+
+ IANA has registered the following RPKI Signed Object:
+
+ ROA 1.2.840.113549.1.9.16.1.24 [RFC6482]
+
+7. Acknowledgments
+
+ The authors wish to thank Charles Gardiner and Russ Housley for their
+ help and contributions. Additionally, the authors would like to
+ thank Rob Austein, Roque Gagliano, Danny McPherson, and Sam Weiler
+ for their careful reviews and helpful comments.
+
+8. References
+
+8.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+ RFC 5652, September 2009.
+
+ [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
+ Addresses and AS Identifiers", RFC 3779, June 2004.
+
+ [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+ Housley, R., and W. Polk, "Internet X.509 Public Key
+ Infrastructure Certificate and Certificate Revocation List
+ (CRL) Profile", RFC 5280, May 2008.
+
+ [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
+ X.509 PKIX Resource Certificates", RFC 6487, February 2012.
+
+ [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template
+ for the Resource Public Key Infrastructure (RPKI)", RFC
+ 6488, February 2012.
+
+
+
+
+
+
+
+Lepinksi, et al. Standards Track [Page 6]
+
+RFC 6482 Route Origin Authorization February 2012
+
+
+ [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
+ Information technology - ASN.1 encoding rules:
+ Specification of Basic Encoding Rules (BER), Canonical
+ Encoding Rules (CER) and Distinguished Encoding Rules
+ (DER).
+
+8.2. Informative References
+
+ [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
+ Secure Internet Routing", RFC 6480, February 2012.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lepinksi, et al. Standards Track [Page 7]
+
+RFC 6482 Route Origin Authorization February 2012
+
+
+Appendix A: ASN.1 Module
+
+ This normative appendix provides an ASN.1 module that specifies the
+ ROA content in ASN.1 syntax.
+
+ RPKI-ROA { iso(1) member-body(2) us(840) rsadsi(113549)
+ pkcs(1) pkcs9(9) smime(16) mod(0) 61 }
+
+ DEFINITIONS EXPLICIT TAGS ::= BEGIN
+
+ RouteOriginAttestation ::= SEQUENCE {
+ version [0] INTEGER DEFAULT 0,
+ asID ASID,
+ ipAddrBlocks SEQUENCE (SIZE(1..MAX)) OF ROAIPAddressFamily }
+
+ ASID ::= INTEGER
+
+ ROAIPAddressFamily ::= SEQUENCE {
+ addressFamily OCTET STRING (SIZE (2..3)),
+ addresses SEQUENCE (SIZE (1..MAX)) OF ROAIPAddress }
+
+ ROAIPAddress ::= SEQUENCE {
+ address IPAddress,
+ maxLength INTEGER OPTIONAL }
+
+ IPAddress ::= BIT STRING
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lepinksi, et al. Standards Track [Page 8]
+
+RFC 6482 Route Origin Authorization February 2012
+
+
+Authors' Addresses
+
+ Matt Lepinski
+ BBN Technologies
+ 10 Moulton Street
+ Cambridge MA 02138
+ EMail: mlepinski@bbn.com
+
+ Stephen Kent
+ BBN Technologies
+ 10 Moulton Street
+ Cambridge MA 02138
+ EMail: skent@bbn.com
+
+ Derrick Kong
+ BBN Technologies
+ 10 Moulton Street
+ Cambridge MA 02138
+ EMail: dkong@bbn.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lepinksi, et al. Standards Track [Page 9]
+