Resource Public Key Infrastructure (RPKI) object profile for Discard Origin Authorizations (DOA)

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 8 September 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

Internet operators commonly provide a means for adjacent networks to advertise routes in BGP with the intention that traffic matching such a route be discarded, rather than being forwarded towards the advertising network. This is referred to as Remotely Triggered Blackholing (RTBH), and is typically acheived through the use of a BGP Community [RFC1997]. [RFC7999] defines a "well known" community value for this purpose. The route used to signal an RTBH request is referred to as an RTBH route.¶

Inter-AS RTBH signalling, however, is in tension with the deployment of Route Origin Validation (ROV) based on the Resource Public Key Infrastructure (RPKI) [RFC6811]. Because a blackhole route is likely to have a prefix length greater than permitted in any covering ROA, an operator wishing to deploy routing policy to discard BGP paths with an ROV status of "Invalid", and simultaneously maintain a blackhole signalling service must choose either:¶

1. to exempt blackhole routes from processing based on ROV status, thus foregoing the benefit of ROV altogether; or¶
2. to insist that users of the blackhole signalling service create ROAs with a sufficiently large "maxLength" values to accomodate blackhole routes.¶

This document defines a Cryptographic Message Syntax (CMS) [RFC5652] profile for Discard Origin Authorizations (DOAs), for use with the Resource Public Key Infrastructure (RPKI) [RFC6480], along with associated processing rules.¶

DOAs can be used to validate whether incoming BGP route announcements carrying specific BGP Communities are meant to signify a request to discard IP traffic towards the IP destination carried in the BGP route. This enhances the concepts of [RFC3882] and [RFC7999], and can co-exist with deployed ROV policy.¶

2. DOA EncapsulatedContentInfo

DOA follows the Signed Object Template for the RPKI [RFC6488].¶

RpkiDiscardOriginAuthorization-2021
 { iso(1) member-body(2) us(840) rsadsi(113549)
   pkcs(1) pkcs9(9) smime(16) mod(0) TBD }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
 CONTENT-TYPE
 FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
   { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
     pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

 IPAddressOrRange, IPAddressRange, IPAddress, ASId
 FROM IPAddrAndASCertExtn -- in [RFC3779]
   { iso(1) identified-organization(3) dod(6) internet(1)
     security(5) mechanisms(5) pkix(7) mod(0)
     id-mod-ip-addr-and-as-ident(30) } ;

ct-discardOriginAuthorization CONTENT-TYPE ::=
   { TYPE DiscardOriginAuthorization IDENTIFIED BY
     id-ct-discardOriginAuthorization }

id-ct-discardOriginAuthorization OBJECT IDENTIFIER ::=
   { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
     pkcs-9(9) id-smime(16) id-ct(1) TBD }

DiscardOriginAuthorization ::= SEQUENCE {
   version             [0] INTEGER DEFAULT 0,
   ipAddrBlocks        IPListRange,
   originAsID          ASId,
   peerAsIDs           [1] SEQUENCE SIZE(1..MAX) OF ASId OPTIONAL,
   communities         [2] SEQUENCE SIZE(1..MAX) OF Community
}

IPListRange ::= SEQUENCE (SIZE(1..MAX)) OF IPAddressFamilyRange

IPAddressFamilyRange ::= SEQUENCE {
   addressFamily        OCTET STRING (SIZE(2..3)),
   addressOrRange       IPAddressOrRange,
   prefixLengthRange    PrefixLengthRange OPTIONAL -- if omitted, assume hostroutes
}

PrefixLengthRange ::= SEQUENCE {
   minLength            INTEGER,
   maxLength            INTEGER
}

Community ::= CHOICE {
   bgpCommunity        [0] OCTET STRING (SIZE(4)),
   bgpLargeCommunity   [1] OCTET STRING (SIZE(12))
}

END

3. DOA Validation

To validate a DOA the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional DOA-specific validation step:¶

• The IP delegation extension [RFC3779] MUST be present in the end-entity certificate (contained in the DOA), and every IP address prefix present in the ipAddrBlocks component of the DOA eContent is contained within the set of IP addresses specified in the EE certificate's IP address delegation extension.¶

4. RPKI-RTR protocol extensions

TODO: Seperate document?¶

5. BGP Route Matching

TODO: Seperate document?¶

A BGP speaker MAY assign to each path it receives from its peers one of 3 RTBH request validation states:¶

• Matched: a validated DOA object was found covering the prefix of the received path, and matching the contraints of the DOA;¶
• Unmatched: a validated DOA object was found covering the prefix of the received path, but the constraints of the DOA were not matched; or¶
• NotFound: a validated DOA object covering the prefix of the receieved path was not found.¶

Where "covering" is used as in its definition in Section 2 [RFC6811].¶

In order for a BGP path to be considered to have matched the constraints of a DOA object, the following conditions MUST be met:¶

• The route originated from the ASN listed in the ASId.¶
• The route was received from a PeerAS which is either the ASId or listed in the peerAsIDs field.¶
• The route's prefix length matches the listed permissible prefix lengths.¶
• The route is tagged with (TODO: one or more of?) the designated BGP community.¶

6. Route Origin Validation Co-Existance

It is important to observe that ROAs and DOAs can and will be issued for the same covered address space, and that the resulting ROV validation state MUST be entirely independent of the resulting DOA validation state.¶

In particular it is expected that legitimate RTBH routes will commonly receive a DOA validation state of 'Matched' whilst also receiving a ROV validation state of 'Invalid' due to the (likely) longer prefix-length of an RTBH route.¶

For this reason, it is recommended that operators construct policy so as to act on the DOA validation early in the routing policy application process, such that routes that are 'Matched' may be installed as RTBH routes, and routes that are 'Unmatched' or 'NotFound' can "fall-through" to be processed as "normal" routes, including the possible application of policy based on their ROV validation state.¶

Critically, in order that operators are able to construct policy according to their needs conforming implementations MUST NOT take any policy action on a route based on either its DOA or ROV validation state by default. See also [RFC8481].¶

8. Operational Considerations

TODO¶

9. Security Considerations

TODO¶

11. IANA Considerations

   Decimal   Description                      References
   -----------------------------------------------------------------------------
   [TBD]     id-mod-rpkiDOA                   [draft-spaghetti-sidrops-rpki-doa]

   Decimal   Description                      References
   -----------------------------------------------------------------------------
   [TBD]     id-ct-discardOriginAuthorization   [draft-spaghetti-sidrops-rpki-doa]

   Name          OID                          Reference
   ----------------------------------------------------
   DOA           1.2.840.113549.1.9.16.1.TBD  [RFC-TBD]

   Filename Extension  RPKI Object                  Reference
   ----------------------------------------------------------
   .doa                Discard Origin Authorization   [RFC-TBD]

   Type name: application
   Subtype name: rpki-doa
   Required parameters: None
   Optional parameters: None
   Encoding considerations: binary
   Security considerations: Carries an RPKI Discard Origin Authorization
                            [RFC-TBD].
   Interoperability considerations: None
   Published specification: This document.
   Applications that use this media type: RPKI operators.
   Additional information:
     Content: This media type is a signed object, as defined
              in [RFC6488], which contains a payload of a set of matching
              criteria as defined above in [RFC-TBD].
     Magic number(s): None
     File extension(s): .doa
     Macintosh file type code(s):
   Person & email address to contact for further information:
     Job Snijders <job@fastly.com>
   Intended usage: COMMON
   Restrictions on usage: None
   Author: Job Snijders <job@fastly.com>
   Change controller: Job Snijders <job@fastly.com>

Appendix A. Acknowledgements

TODO¶

Authors' Addresses