the resource public key infrastructure (rpki) is a global · the resource public key infrastructure...

Secure Inter-Domain Routing D. MandelbergInternet-Draft BBN TechnologiesIntended status: Best Current Practice May 13, 2015Expires: November 14, 2015

Simplified Local internet nUmber Resource Management with the RPKI draft-dseomn-sidr-slurm-02

Abstract

The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origination assertions. In the future, ISPs also will be able to use the RPKI to validate the path of a BGP route. Some ISPs locally use BGP with private address space or private AS numbers (see RFC6890). These local BGP routes cannot be verified by the global RPKI, and SHOULD be considered invalid based on the global RPKI (see RFC6491). The mechanisms described below provide ISPs with a way to make local assertions about private (reserved) INRs while using the RPKI’s assertions about all other INRs.

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 http://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 November 14, 2015.

Copyright Notice

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.

Mandelberg Expires November 14, 2015 []

Internet-Draft SLURM May 2015

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Validation Output Filtering . . . . . . . . . . . . . . . . . 4 3. Locally Adding Assertions . . . . . . . . . . . . . . . . . . 4 4. Configuring SLURM . . . . . . . . . . . . . . . . . . . . . . 4 5. Combining Mechanisms . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Informative References . . . . . . . . . . . . . . . . . 8 9.2. Normative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Example SLURM File . . . . . . . . . . . . . . . . . 10 Author’s Address . . . . . . . . . . . . . . . . . . . . . . . . 11

1. Introduction

The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. For example, the holder of a block of IP(v4 or v6) addresses can issue a Route Origination Authorization (ROA) [RFC6482] to authorize an Autonomous System (AS) to originate routes for that block.

Internet Service Providers (ISPs) can then use the RPKI to validate BGP routes. (Validation of the origin of a route is described in [RFC6483], and validation of the path of a route is described in [I-D.ietf-sidr-bgpsec-overview].) However, some ISPs locally use BGP with private address space ([RFC1918], [RFC4193], [RFC6598]) or private AS numbers ([RFC1930], [RFC6996]). These local BGP routes cannot be verified by the global RPKI, and SHOULD be considered invalid when using the RPKI. For example, [RFC6491] recommends the creation of ROAs that would invalidate routes for reserved and unallocated address space.



This document specifies two new mechanisms to enable ISPs to make local assertions about some INRs while using the RPKI’s assertions about all other INRs. These mechanisms support the second and third use cases in [I-D.ietf-sidr-lta-use-cases]. The second use case describes use of [RFC1918] addresses or use of public address space not allocated to the ISP that is using it. The third use case describes a situation in which an ISP publishes a variant of the RPKI hierarchy (for its customers). In this variant some prefixes and/or AS numbers are different from what the RPKI repository system presents to the general ISP population. The result is that routes for consumers of this variant hierarchy will be re-directed (via routing).

Both mechanisms are specified in terms of abstract sets of assertions. For Origin Validation [RFC6483], an assertion is a tuple of {IP prefix, prefix length, maximum length, AS number} as used by rpki-rtr version 0 [RFC6810] and version 1 [I-D.ietf-sidr-rpki-rtr-rfc6810-bis]. For BGPsec [I-D.ietf-sidr-bgpsec-overview], an assertion is a tuple of {AS number, subject key identifier, router public key} as used by rpki- rtr version 1. Output Filtering, described in Section 2, filters out any assertions by the RPKI about locally reserved INRs. Locally Adding Assertions, described in Section 3, adds local assertions about locally reserved INRs. The combination of both mechanisms is described in Section 5.

To ensure local consistency, the effect of SLURM MUST be atomic. That is, the output of the relying party must be either the same as if SLURM were not used, or it must reflect the entire SLURM configuration. For an example of why this is required, consider the case of two local routes for the same prefix but different origin AS numbers. Both routes are configured with Locally Adding Assertions. If neither addition occurs, then both routes could be in the unknown state [RFC6483]. If both additions occur then both routes would be in the valid state. However, if one addition occurs and the other does not, then one could be invalid while the other is valid.

In general, the primary output of an RPKI relying party is the data it sends to routers over the rpki-rtr protocol. The rpki-rtr protocol enables routers to query a relying party for all assertions it knows about (Reset Query) or for an update of only the changes in assertions (Serial Query). The mechanisms specified in this document are to be applied to the result set for a Reset Query, and to both the old and new sets that are compared for a Serial Query. Relying party software MAY modify other forms of output in comparable ways, but that is outside the scope of this document.



This document is intended to supersede [I-D.ietf-sidr-ltamgmt] while focusing only on local management of private INRs. Another draft [I-D.kent-sidr-suspenders] focuses on the other aspects of local management.

1.1. 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].

2. Validation Output Filtering

To prevent the global RPKI from affecting routes with locally reserved INRs, a relying party may be locally configured with a list of IP prefixes and/or AS numbers that are used locally, and taken from reserved INR spaces. Any Origin Validation assertions where the IP prefix is equal to or subsumed by a locally reserved IP prefix, are removed from the relying party’s output. Any Origin Validation assertions where the IP prefix contains a locally reserved IP prefix are removed; the relying party software SHOULD issue a warning when this action is taken. (Note that an Origin Validation assertion is not removed due to its AS number matching a locally reserved AS number.) Any BGPsec assertion where the AS number is equal to a locally reserved AS number is removed from the relying party’s output.

3. Locally Adding Assertions

Each relying party is locally configured with a (possibly empty) list of assertions. This list is added to the relying party’s output.

4. Configuring SLURM

Relying party software SHOULD support the following configuration format for Validation Output Filtering and Locally Adding Assertions. The format is defined using the Augmented Backus-Naur Form (ABNF) notation and core rules from [RFC5234] and the rules <IPv4address> and <IPv6address> from Appendix A of [RFC3986]. See Appendix A for an example SLURM file.

A SLURM configuration file, <SLURMFile>, consists of a head and a body. The head identifies the file as a SLURM configuration file, specifies the version of SLURM for which the file was written, and optionally contains other information described below. The body contains the configuration for Validation Output Filtering and Locally Adding Assertions.



SLURMFile = head body

head = firstLine *(commentLine / headLine)

body = *(commentLine / bodyLine)

firstLine = %x53.4c.55.52.4d SP "1.0" EOL ; "SLURM 1.0"

commentLine = *WSP [comment] EOL

headLine = *WSP headCommand [ 1*WSP [comment] ] EOL

bodyLine = *WSP bodyCommand [ 1*WSP [comment] ] EOL

comment = "#" *(VCHAR / WSP)

EOL = CRLF / LF

The head may specify a target. If present, the target string identifies the environment in which the SLURM file is intended to be used. The meaning of the target string, if any, is determined by the user. If a target is present, a relying party SHOULD verify that that the target is an acceptable value, and reject the SLURM file if the target is not acceptable. For example, the relying party could be configured to accept SLURM files only if they do not specify a target, have a target value of "hostname=rpki.example.com", or have a target value of "as=65536". If more than one target line is present, all targets must be acceptable to the RP.

headCommand = target

target = %x74.61.72.67.65.74 1*WSP ; "target" 1*VCHAR

The body contains zero or more configuration lines for Validation Output Filtering and Locally Adding Assertions. Each <del> command specifies an INR to use for Validation Output Filtering. Each <add> command specifies an assertion to use for Locally Adding Assertions.

bodyCommand = add / del

add = %x61.64.64 1*WSP ; "add" addItem

del = %x64.65.6c 1*WSP ; "del"



delItem

addItem = addItemPrefixAS / addItemASKey

; Add a mapping from a prefix and max length to an AS number. addItemPrefixAS = %x6f.72.69.67.69.6e.61.74.69.6f.6e 1*WSP ; "origination" IPprefixMaxLen 1*WSP ASnum

; Add a mapping from an AS number to a router public key. addItemASKey = %x62.67.70.73.65.63 1*WSP ; "bgpsec" ASnum 1*WSP RouterSKI 1*WSP RouterPubKey

delItem = delItemPrefix / delItemAS

; Filter prefix-AS mappings, using the given prefix delItemPrefix = %x6f.72.69.67.69.6e.61.74.69.6f.6e 1*WSP ; "origination" IPprefix

; Filter AS-key mappings for the given AS delItemAS = %x62.67.70.73.65.63 1*WSP ; "bgpsec" ASnum

IPprefix = IPv4prefix / IPv6prefix

IPprefixMaxLen = IPv4prefixMaxLen / IPv6prefixMaxLen

IPv4prefix = IPv4address "/" 1*2DIGIT IPv6prefix = IPv6address "/" 1*3DIGIT

; In the following two rules, if the maximum length component is ; missing, it is treated as equal to the prefix length. IPv4prefixMaxLen = IPv4prefix ["-" 1*2DIGIT] IPv6prefixMaxLen = IPv6prefix ["-" 1*3DIGIT]

ASnum = 1*DIGIT

; This is the Base64 [RFC4648] encoding of a router certificate’s ; Subject Key Identifer, as described in ; [I-D.ietf-sidr-bgpsec-pki-profiles] and [RFC6487]. This is the ; value of the ASN.1 OCTET STRING without the ASN.1 tag or length ; fields.



RouterSKI = Base64

; This is the Base64 [RFC4648] encoding of a router public key’s ; subjectPublicKeyInfo value, as described in ; [I-D.ietf-sidr-bgpsec-algs]. This is the full ASN.1 DER encoding ; of the subjectPublicKeyInfo, including the ASN.1 tag and length ; values of the subjectPublicKeyInfo SEQUENCE. RouterPubKey = Base64

Base64 = 1*(ALPHA / DIGIT / "+" / "/") 0*2"="

An implementation MAY support the concurrent use of multiple SLURM files. In this case, the resulting inputs to Validation Output Filtering and Locally Adding Assertions are the respective unions of the inputs from each file. The typical use case for multiple files is when the files have distinct scopes. For example, an organization may belong to two separate networks that use different private-use IP prefixes and AS numbers. To detect conflict between multiple SLURM files, a relying party SHOULD issue a warning in the following cases:

1. There may be conflicting changes to Origin Validation assertions if there exists an IP address X and distinct SLURM files Y,Z such that X is contained by any prefix in any <addItemPrefixAS> or <delItemPrefix> in file Y and X is contained by any prefix in any <addItemPrefixAS> or <delItemPrefix> in file Z.

2. There may be conflicting changes to BGPsec assertions if there exists an AS number X and distinct SLURM files Y,Z such that X is used in any <addItemASKey> or <delItemAS> in file Y and X is used in any <addItemASKey> or <delItemAS> in file Z.

5. Combining Mechanisms

In the typical use case, a relying party uses both output filtering and locally added assertions. In this case, the resulting assertions MUST be the same as if output filtering were performed before locally adding assertions. I.e., locally added assertions MUST NOT be removed by output filtering.

If a relying party chooses to use both SLURM and Suspenders [I-D.kent-sidr-suspenders], the SLURM mechanisms MUST be performed on the output of Suspenders.

6. IANA Considerations

TBD



7. Security Considerations

The mechanisms described in this document provide a network operator with additional ways to control its own network while making use of RPKI data. These mechanisms are applied only locally; they do not influence how other network operators interpret RPKI data. Nonetheless, care should be taken in how these mechanisms are employed.

8. Acknowledgements

The author would like to thank Stephen Kent for his guidance and detailed reviews of this document. Thanks go to Wesley Wang for the idea behind the target command, to Declan Ma for the idea behind use of multiple SLURM files, and to Richard Hansen for his careful reviews.

9. References

9.1. Informative References

[I-D.ietf-sidr-bgpsec-overview] Lepinski, M. and S. Turner, "An Overview of BGPsec", draft-ietf-sidr-bgpsec-overview-06 (work in progress), January 2015.

[I-D.ietf-sidr-lta-use-cases] Bush, R., "RPKI Local Trust Anchor Use Cases", draft-ietf- sidr-lta-use-cases-02 (work in progress), December 2014.

[I-D.ietf-sidr-ltamgmt] Reynolds, M., Kent, S., and M. Lepinski, "Local Trust Anchor Management for the Resource Public Key Infrastructure", draft-ietf-sidr-ltamgmt-08 (work in progress), April 2013.

[I-D.ietf-sidr-rpki-rtr-rfc6810-bis] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", draft-ietf- sidr-rpki-rtr-rfc6810-bis-03 (work in progress), March 2015.

[I-D.kent-sidr-suspenders] Kent, S. and D. Mandelberg, "Suspenders: A Fail-safe Mechanism for the RPKI", draft-kent-sidr-suspenders-03 (work in progress), April 2015.



[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996.

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.

[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012.

[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, February 2012.

[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.

[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, January 2013.

[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, April 2013.

[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, July 2013.

9.2. Normative References

[I-D.ietf-sidr-bgpsec-algs] Turner, S., "BGP Algorithms, Key Formats, & Signature Formats", draft-ietf-sidr-bgpsec-algs-09 (work in progress), January 2015.



[I-D.ietf-sidr-bgpsec-pki-profiles] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests", draft-ietf-sidr-bgpsec-pki- profiles-10 (work in progress), January 2015.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.

Appendix A. Example SLURM File



SLURM 1.0

# This file is only intended to be used on a relying party running # on rpki.example.com. target hostname=rpki.example.com # this is a comment

# Reserve IP prefixes for local use. del origination 10.0.0.0/24 del origination fd0b:dd1d:2dcc::/48

# Reserve AS numbers for local use. del bgpsec 64512 del bgpsec 64513

# Allow either 64512 or 64513 to originate routes to 10.0.0.0/24. add origination 10.0.0.0/24 64512 add origination 10.0.0.0/24 64513

# 64512 originates fd0b:dd1d:2dcc::/52 and sub-prefixes up to length # 56. add origination fd0b:dd1d:2dcc::/52-56 64512

# However, 64513 originates fd0b:dd1d:2dcc:42::/64. add origination fd0b:dd1d:2dcc:42::/64 64513

# 64513 also originates fd0b:dd1d:2dcc:100::/52 add origination fd0b:dd1d:2dcc:100::/52 64513

# Authorize router keys to sign BGPsec paths on behalf of the # specified ASes. Note that the Base64 strings used in this # example are not valid SKIs or router public keys, due to line # length restrictions in RFCs. add bgpsec 64512 Zm9v VGhpcyBpcyBub3QgYSByb3V0ZXIgcHVibGljIGtleQ== add bgpsec 64512 YmFy b3IgYSBmbG9jayBvZiBkdWNrcw== add bgpsec 64513 YWJj bWF5YmUgYSBkaWZmZXJlbnQgYXZpYW4gY2Fycmllcj8=

Author’s Address

David Mandelberg BBN Technologies 10 Moulton St. Camridge, MA 02138 US

Email: [email protected]


Network Working Group T. BruijnzeelsInternet-Draft O. MuravskiyIntended status: Standards Track RIPE NCCExpires: August 18, 2015 B. Weber Cobenian R. Austein Dragon Research Labs D. Mandelberg BBN Technologies February 16, 2015

RPKI Repository Delta Protocol draft-ietf-sidr-delta-protocol-00

Abstract

In the Resource Public Key Infrastructure (RPKI), certificate authorities publish certificates, including end entity certificates, and CRLs to repositories on publication servers. Relying Parties (RP) retrieve the published information from the repository and MAY store it in a cache. This document specifies a delta protocol which provides relying parties with a mechanism to query a repository for changes, thus enabling the RP to keep its state in sync with the repository.

Status of this Memo




This Internet-Draft will expire on August 18, 2015.

Copyright Notice


Bruijnzeels, Muravskiy, ExpiresAAugust 18, 2015 [Page 1]

Internet-Draft RPKI Repository Delta Protocol February 2015

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.

Table of Contents

1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. RPKI Repository Delta Protocol Implementation . . . . . . . . 3 3.1. Informal Overview . . . . . . . . . . . . . . . . . . . . 3 3.2. Update Notification File . . . . . . . . . . . . . . . . . 5 3.2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Cache Concerns . . . . . . . . . . . . . . . . . . . . 5 3.2.3. File Format and Validation . . . . . . . . . . . . . . 5 3.2.4. Publication Server Initialisation . . . . . . . . . . 6 3.2.5. Publishing Updates . . . . . . . . . . . . . . . . . . 6 3.3. Snapshot File . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.2. Cache Concerns . . . . . . . . . . . . . . . . . . . . 7 3.3.3. File Format and Validation . . . . . . . . . . . . . . 8 3.4. Delta File . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2. Cache Concerns . . . . . . . . . . . . . . . . . . . . 11 3.4.3. File Format and Validation . . . . . . . . . . . . . . 11 3.5. SIA for CA certificates . . . . . . . . . . . . . . . . . 13 4. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Full Synchronisation . . . . . . . . . . . . . . . . . . . 14 4.2. Processing Deltas . . . . . . . . . . . . . . . . . . . . 14 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

1. Requirements notation


2. Introduction



In the Resource Public Key Infrastructure (RPKI), certification authorities (CAs) publish certificates [RFC6487], RPKI signed objects [RFC6488] , manifests [RFC6486] and CRLs to repositories. CAs may have an embedded mechanism to publish to these repositories, or they may use a separate publication server and communication protocol. RPKI repositories are currently accessible using rsync, allowing Relying Parties (RPs) to synchronise a local copy of the RPKI repository used for validation with the central repositories using the rsync protocol [RFC6481].

This document specifies an alternative repository access protocol based on notification, snapshot and delta files that an RP can retrieve over http(s). This allows RPs to perform a full (re-)synchronisation of their local copy of the repository using snapshot files. However, typically RPs will use delta files to keep their local repository updated after initial synchronisation.

This protocol is designed to be consistent with the publication protocol [I-D.ietf-sidr-publication] and treats publication events of one or more repository objects as immutable events that can be communicated to relying parties. This approach helps to minimize the amount of data that traverses the network and thus helps minimize the amount of time until repository convergence occurs. This protocol also provides a standards based way to obtain consistent, point in time views of a single repository eliminating a number of consistency related issues. Finally, this approach allows for caching infrastructure to be used to serve this immutable data, and thus helps to reduce the load on a publication server when a large a number of relying parties are querying it.

3. RPKI Repository Delta Protocol Implementation

3.1. Informal Overview

Certification Authorities (CA) in the RPKI use a publication server to publish their RPKI products, such as manifests, CRLs, signed certificates and RPKI signed objects. This publication server may be remote, or embedded in the CA engine itself. Certificates in the RPKI that use a publication server that supports this delta protocol include a special Subject Information Access (SIA) pointer referring to a notification file.

The notification file includes a globally unique session_id in the form of a version 4 UUID, and serial number that can be used by the Relying Party (RP) to determine if it and the repository are synchronised. Furthermore it includes a link to the most recent complete snapshot of current objects that are published by the publication servers, and a list of links to delta files, for each revision starting at a point determined by the publication server, up to the current revision of the repository.



This notification file is intended to be small so that is can easily be fetched over HTTP(S). The publication server may use HTTP caching infrastructure to reduce its load. The publication server should should avoid using a long caching interval, since the length of this interval determines when RPs will receive updated notification files, and thereby new products produced by Certification Authorities using this publication server. It is recommended that of no longer than five minutes is used for caching this file. If the caching infrastructure supports it another useful approach would be to expire the cache for the notification file URI as soon as a new notification file is known to be published.

An RP that first learns about a notification file location can download it, and then proceed to download the latest snapshot file, and thus create a local copy of the repository that is in sync with the publication server. The RP should remember the location of this notification file, the session_id and current serial number.

RPs are encouraged to re-fetch this notification file at regular intervals, but should not try to fetch the same file more frequently than once per minute. After re-fetching the notification file, the RP may find that there are one or more delta files available that allow it to synchronise with the current state.

If no contiguous chain of updates is available, or if the session_id has changed, the latest snapshot should be used instead. In this case the RP should then add the objects found in the latest snapshot to its local repository.

As soon as the RP fetches new content in this way it should start a validation process using its local repository. An example of a reason why an RP may not do this immediately is because it has learned of more than one notification location and it prefers to complete all its updates before validating.

The publication server may use http caching infrastructure to reduce its load. It should be noted that snapshots and deltas for any given session_id and serial number contain an immutable record of the state of the publication server at a certain point in time. For this reason these files can be cached indefinitely. To support this the publication server must use a globally unique URL for the location of



each of these snapshot and delta files. It is recommended that old versions of snapshot and delta files remain available for download for some time after they have last appeared on a notification file to provide some resiliency in case relying parties are slow to process.

3.2. Update Notification File

3.2.1. Purpose

The update notification file is used by RPs to discover whether any changes exist between the state of the publication server’s repository and the RP’s cache. It describes the location of the files containing the snapshot and incremental deltas which can be used by the RP to synchronize with the repository.

3.2.2. Cache Concerns

A repository server MAY use caching infrastructure to cache the notification file and reduce the load of http(s) requests to a central repository server. However, since this file is used by RPs to determine whether any updates are available it is strongly RECOMMENDED to use a short interval for caching, to avoid unnecessary delays. A maximum of delay of 5 minutes after a new notification file has been published seems like a reasonable compromise. This delay should not cause major problems for RPs and routing since a similar human time scale is expected to be involved in updating the contents of the RPKI on the one hand, i.e. creating and publishing new ROAs or router certificates, and updating actual BGP announcements in routers on the other. That said, real world measurements are needed on this subject, so this recommended maximum time may be subject to change in future.

There are various ways to ensure that the notification file is only cached for a certain time in caching infrastructure and different solutions, such as commercial Content Delivery Networks (CDNs), may provide different ways of achieving this. For example some CDNs have custom support to cache a file such as this notification file indefinetely, but allow a central server to notify the CDN through some protocol that an update is available and trigger the CDN to then refresh this file. In general a publication server may find certain HTTP headers to be useful, such as: Cache-Control: max-age=300

Finally it shoulf be noted that snapshot and delta files are intended to be cache-able for a much longer longer time. In support of this the URIs for each snapshot and delta file for a given session_id and serial number MUST be unique and the contents of those files MUST NOT change.

3.2.3. File Format and Validation

Example notification file:



<notification xmlns="HTTP://www.ripe.net/rpki/rrdp" version="1" session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28" serial="2"> <snapshot uri="HTTP://rpki.ripe.net/rpki-ca/rrdp/EEEA7F7AD96D85BBD1F7274FA7DA0025984A2AF3D5A0538F77BEC732ECB1B068.xml" hash="EEEA7F7AD96D85BBD1F7274FA7DA0025984A2AF3D5A0538F77BEC732ECB1B068"/> <delta serial="2" uri="HTTP://rpki.ripe.net/rpki-ca/rrdp/198BD94315E9372D7F15688A5A61C7BA40D318210CDC799B6D3F9F24831CF21B.xml" hash="198BD94315E9372D7F15688A5A61C7BA40D318210CDC799B6D3F9F24831CF21B"/> <delta serial="1" uri="HTTP://rpki.ripe.net/rpki-ca/rrdp/8DE946FDA8C6A6E431DFE3622E2A3E36B8F477B81FAFCC5E7552CC3350C609CC.xml" hash="8DE946FDA8C6A6E431DFE3622E2A3E36B8F477B81FAFCC5E7552CC3350C609CC"/> </notification>

The following validation rules must be observed when creating or parsing notification files:

o A RP MUST NOT process any update notification file that is not well formed, or which does not conform to the RELAX NG schema outlined in Section 5 of this document. o The XML namespace MUST be HTTP://www.ripe.net/rpki/rrdp o The encoding MUST be us-ascii o The version attribute in the notification root element MUST be 1 o The session_id attribute MUST be a random version 4 UUID unique to this session o The serial attribute must be an unbounded, unsigned positive integer indicating the current version of the repository. o The notification file MUST contain exactly one ’snapshot’ element for the current repository version. o If delta elements are included they MUST form a contiguous sequence starting at a revision determined by the publication server, up to the current version of the repository. o The hash attribute in snapshot and delta elements must be the hexadecimal encoding of the SHA-256 hash of the referenced file. The RP SHOULD verify this hash when the file is retrieved and reject it if it does not match.

3.2.4. Publication Server Initialisation

When the publication server (re-) initialises it MUST generate a new random version 4 UUID to be used as the session_id. Furthermore it MUST then generate a snapshot file for serial number ONE for this new session that includes all currently known published objects that the publication server is responsible for. This snapshot file MUST be made available at a URL that is unique to this session and version, so that it can be cached indefinitely. The format and caching concerns for snapshot files are explained in more detail below in Section 3.3. After the snapshot file has been published the publication server MUST publish a new notification file that contains the new session_id, has serial number ONE, has one reference to the snaphot file that was just published, and that contains no delta references.

3.2.5. Publishing Updates

Whenever the publication server receives updates from a CA it SHOULD generate an update as follows.



The new repository serial MUST be one greater than the current repository serial. A new delta file MUST be generated for this new serial, that contains all the updates, i.e. new, replaced and withdrawn objects, as a single change set. This delta file MUST be made available at a URL that is unique to this session and version, so that it can be cached indefinitely. The format and caching concerns for delta files are explained in more detail below in Section 3.4.

The publication server MUST also generate a new snaphost file for this new serial, that contains all current objects for this new serial. In other words it should include all publish elements found in this update, and it should exclude all previous publish elements for objects that have been withdrawn or updated. As above this new file MUST be made available at a URL that is unique to this session_id and new version before proceeding.

Finally an updated notification file MUST be created by the publication server. This new notification file MUST include a reference to the new snaphot file. The file SHOULD also include available delta files for this and previous updates. However, the server MUST not include more delta files than, when combined, exceed the size of the current snapshot.

The publication server MAY also choose to include fewer delta files if it is found that the efficiency gain in keeping notification files small outweighs the overhead of forcing a small number of relying parties to process full snapshot files. At the time of this writing it is not completely clear what would constitute reasonable parameters to determine this balance. Real world measurements are needed to help this discussion. Possible approaches are:

o The publication server may learn the retrieval distribution of old delta files by RPs over time, and decide to exclude deltas from the point where less than e.g. 0.1% of RPs would retrieve them. o The server may decide to support deltas only for a limited time, e.g. 6 hours. So that RPs can recover easily from restart or reasonably short outage scenarios, and are only forced to do a full re-sync in case of prolonged outages.

If the publication server is not capable of performing the above for some reason, then it MUST perform a full re-initialisation, as explained above in Section 3.2.4.

3.3. Snapshot File

3.3.1. Purpose

A snapshot is intended to reflect the complete and current contents of the repository. There it MUST contain all objects from the repository current as of the time of the publication.




A repository server MAY use caching infrastructure to cache snapshot files and reduce the load of http(s) requests to a central repository server. To support this it is important that snaphot files for a specific session_id and serial have a unique URL. The files themselves reflect the content of the repository at a specific point in time, and for that reason they never change. Aside from space concerns this means that these files MAY therefore be cached indefinitely.

To support RPs that are slow to process old, possibly cached, notification files, the publication server SHOULD ensure that old snapshot files remain available for some time after have last appeared on a notification file. It is RECOMMENDED that these files are kept for at least two times as long as the notification file cache period, i.e. 10 minutes. However, space permitting, the publication server is welcome to keep these files available for longer.


Example snapshot file:



<snapshot xmlns="HTTP://www.ripe.net/rpki/rrdp" version="1" session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28" serial="5932"> <publish uri="rsync://bandito.ripe.net/repo/671570f06499fbd2d6ab76c4f22566fe49d5de60.cer"> MIIFNDCCBBygAwIBAgIBAjANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJUQTAeFw0xNDExMTMw MzU4MjlaFw0xNTExMTMwMzU4MjlaMDMxMTAvBgNVBAMTKDY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZj NGYyMjU2NmZlNDlkNWRlNjAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDOlUYxDPwu hqVSG5VXcg96qTYt9aKOH8qV2lAU/jnY1rRl2W5Uoa8RrAIseou8ltLKonMcVulHyoyY+J9GqrzN 45vRSgBaOuvLn6nTuoD0LQsD/m8c/wEmFjQllirxQykLGJLXn1eKdUs/OXGgrAUPzgvkciJdsg69 6X44deHcbCU0ZQZSLxZBZEqjfgyoYgww9n/hK5Sfkb44LsBK1lESdBSRrTpFizrCxl22ptsH0eW4 ek80CV5YgCg4F4u9xlzS2DvB+1X3Nl1vvTZ6TJlpVjIVcvE+sKQ50ntUwWG1+lOJc+twRehhiCAb yHhfaxID4B+7h5Rcpkh1Q1AUMG9JAgMBAAGjggJ3MIICczAdBgNVHQ4EFgQUZxVw8GSZ+9LWq3bE 8iVm/knV3mAwHwYDVR0jBBgwFoAUd4IboVLl+9bEbD6VrCsnqRClFNUwDwYDVR0TAQH/BAUwAwEB /zAOBgNVHQ8BAf8EBAMCAQYwRQYIKwYBBQUHAQEEOTA3MDUGCCsGAQUFBzAChilodHRwOi8vYmFu ZGl0by5yaXBlLm5ldC9ycGtpLWNhL3RhL3RhLmNlcjCCATAGCCsGAQUFBwELBIIBIjCCAR4wVwYI KwYBBQUHMAWGS3JzeW5jOi8vYmFuZGl0by5yaXBlLm5ldC9yZXBvLzNhODdhNGIxLTZlMjItNGE2 My1hZDBmLTA2ZjgzYWQzY2ExNi9kZWZhdWx0LzCBgwYIKwYBBQUHMAqGd3JzeW5jOi8vYmFuZGl0 by5yaXBlLm5ldC9yZXBvLzNhODdhNGIxLTZlMjItNGE2My1hZDBmLTA2ZjgzYWQzY2ExNi9kZWZh dWx0LzY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZjNGYyMjU2NmZlNDlkNWRlNjAubWZ0MD0GCCsGAQUF BzANhjFodHRwOi8vYmFuZGl0by5yaXBlLm5ldC9ycGtpLWNhL25vdGlmeS9ub3RpZnkueG1sMFsG A1UdHwRUMFIwUKBOoEyGSnJzeW5jOi8vYmFuZGl0by5yaXBlLm5ldC9yZXBvLzc3ODIxYmExNTJl NWZiZDZjNDZjM2U5NWFjMmIyN2E5MTBhNTE0ZDUuY3JsMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUH DgIwHgYIKwYBBQUHAQcBAf8EDzANMAsEAgABMAUDAwDAqDANBgkqhkiG9w0BAQsFAAOCAQEAkAnl E+Fm1r3cmW8EEwhq4Wo37j7qC8ciU/E/zJqptROd8M8+2PDjCF8K7plf/SqYNUWjCk8zQv7Siala DP3JNI7oWkJ5K9zSU/qPGD8UbrfK5EF4g+++OAsxsOf/qeMVdZ6FlPIUV0wYj2s9w1zz/r16HFV6 QO785ajB50foqo/oQ74BSRbrlYkWrM8U45rdSiAMlyr0lHgv0OCqNK6AVR6y9Sp6bBUi7RotZ5FN x0TgBRTA6xp4pjG5FimX1SanMaW1hgYqdc4X5aZ9gPiyqvBcOtFq91WnNTsm5Ox0cPNDCkMPLAwW pHOiFA0PlD0vBPrvTR1hsgfKGd318Qzq+w== </publish> <publish uri="rsync://bandito.ripe.net/repo/77821ba152e5fbd6c46c3e95ac2b27a910a514d5.mft"> MIAGCSqGSIb3DQEHAqCAMIACAQMxDzANBglghkgBZQMEAgEFADCABgsqhkiG9w0BCRABGqCAJIAE gd0wgdoCAguWGA8yMDE0MTIwMzE4MDgzMloYDzIwMTQxMjA0MTgwODMyWgYJYIZIAWUDBAIBMIGm MFEWLDY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZjNGYyMjU2NmZlNDlkNWRlNjAuY2VyAyEAh0nT6uSg nJQhGAnKgjxb9TDeGu9AEd8QK+GHXYop0U8wURYsNzc4MjFiYTE1MmU1ZmJkNmM0NmMzZTk1YWMy YjI3YTkxMGE1MTRkNS5jcmwDIQAZ658FmRCmFfxCpTfE8hZN00MnUEdohOiISZflCPbrUwAAA

AAA AKCAMIIEcjCCA1qgAwIBAgICC5gwDQYJKoZIhvcNAQELBQAwDTELMAkGA1UEAxMCVEEwHhcNMTQx MjAzMTgwODMyWhcNMTQxMjEwMTgwODMyWjAzMTEwLwYDVQQDEyhlY2Y0NjhkMDY1MTMyNzFmNTkz MjZhNjQ2MGZmOTFhYTNiNGU2Njk4MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkiYz EpnsqHIPNEl/LvJmfZfOYzRlhv0Ewqg/RLi6XsE5dhWi0YAiFLbz0v/PfAjmJJFO6STsXkmc5Cpp PoAl2+Ffx9Zujzy95hCNMqNgPSsqA92eAStLJALlvWrlYgTQEBV/hIjetDOEY/fL49gajyuKghOh +zgeEUCVhdIArEj/4j5E1vI7flwJjLP8SI36IWlKoz6cd88Gm8bLQRURAfe2lKW0quJk0RHOnPZk babWuiiByoU24DCSy1+TBY4mEK6bi1R0iONqeYfaSUrxvWcDh8V6gNikiB+tfwRxrIOO1RTnKnlI hIe2OC5mkP2gMY5ZUyynJZnS3Or+CY3IcQIDAQABo4IBtDCCAbAwHQYDVR0OBBYEFOz0aNBlEycf WTJqZGD/kao7TmaYMB8GA1UdIwQYMBaAFHeCG6FS5fvWxGw+lawrJ6kQpRTVMA4GA1UdDwEB/wQE AwIHgDBFBggrBgEFBQcBAQQ5MDcwNQYIKwYBBQUHMAKGKWh0dHA6Ly9iYW5kaXRvLnJpcGUubmV0 L3Jwa2ktY2EvdGEvdGEuY2VyMGYGCCsGAQUFBwELBFowWDBWBggrBgEFBQcwC4ZKcnN5bmM6Ly9i YW5kaXRvLnJpcGUubmV0L3JlcG8vNzc4MjFiYTE1MmU1ZmJkNmM0NmMzZTk1YWMyYjI3YTkxMGE1 MTRkNS5tZnQwWwYDVR0fBFQwUjBQoE6gTIZKcnN5bmM6Ly9iYW5kaXRvLnJpcGUubmV0L3JlcG8v Nzc4MjFiYTE1MmU1ZmJkNmM0NmMzZTk1YWMyYjI3YTkxMGE1MTRkNS5jcmwwGAYDVR0gAQH/BA4w



DDAKBggrBgEFBQcOAjAhBggrBgEFBQcBBwEB/wQSMBAwBgQCAAEFADAGBAIAAgUAMBUGCCsGAQUF BwEIAQH/BAYwBKACBQAwDQYJKoZIhvcNAQELBQADggEBAAjCpzNzjj7QGhmIG3Elt49cHUJe865w y2Uq3ZKW2aZgA5It29D07XlsHO8tM0EWVXTxsBbpdkiEnzQ4G8Zx/ZI09vLSJ8ZjzSh42QeMaNt6 6zslilaw9rQcm/5jwxN18BRniwU/oavfRbn36AhfCmpegII/4DTZWjI63wucRrYHTHZm6ZajnHKU DT1viomKZoZZDAUB4oQ7pN/Mw+t1K9F50VKz+9i3tnVhyt5wVaoEn/4sGRAL680A8Su0MKiyc69t 3DYqnvSgYtFNiBbHhNYooBpraylh5r7WngBxfm+VJYkSaPxU8T6sSz/Capt+1S2UWJGTcFaZl251 bm8nmXcAADGCAawwggGoAgEDgBTs9GjQZRMnH1kyamRg/5GqO05mmDANBglghkgBZQMEAgEFAKBr MBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGjAcBgkqhkiG9w0BCQUxDxcNMTQxMjAzMTgwODMy WjAvBgkqhkiG9w0BCQQxIgQgOUbuFjfSw4aMeIgLlDmT5xI7D05/mH6zVETECtMzWb0wDQYJKoZI hvcNAQEBBQAEggEAbhfERg8rgzy0GAIPDKj5kNk+owpm7WnRDiUo+6Y30zfKKjFhh1L+N0Ei7b6q r934eqEoac23wycF/A1e3+d4PoLzvFrm1n9rIia4BaD8GiUle6FEHd5njS7jOt5Kuej64yDFCHtv ipt8tGFik4MpvEmP5EOhZ1cU/sErvlpdEsxQCaLsb6JUbIvoIHnWGXHE54QXkBvlucUSxypRoqW3 SnAX0vo0F1YNrSDe05So3pjjSmNHOuFFnxZMja+lIMMWTFylbKQJNpLIrb9a/uarfiL9BrGODWqE dzQh+k3QkTAUojq+YADL+ixO0eg2zpPm+eEU1F2+bGP2M5rbaUfqngAAAAAAAA== </publish> <publish uri="rsync://bandito.ripe.net/repo/77821ba152e5fbd6c46c3e95ac2b27a910a514d5.crl"> MIIBnzCBiAIBATANBgkqhkiG9w0BAQsFADANMQswCQYDVQQDEwJUQRcNMTQxMjAzMTgwODMyWhcN MTQxMjA0MTgwODMyWjAVMBMCAguXFw0xNDEyMDMxODA4MzJaoDAwLjAfBgNVHSMEGDAWgBR3ghuh UuX71sRsPpWsKyepEKUU1TALBgNVHRQEBAICC5YwDQYJKoZIhvcNAQELBQADggEBAFQHr/2ids7e hmfnX+PmyePSN2EM1fBMLwMud6dqyBF42iNa8N0H/jxMAkgm7SS98TUupZg1aIwqxLwGakFS6VeD +zCnCGEeMUlXTpZaICDxMxJuJLBOVbqP2amPxWJ22g0+gTXM9KPAoWlNyAiMaNUP+nawjyfMzQ4c WJjIi1kRHnIhiu9cZwEh9Ns/sC3adPJ8NV6LPpMkQDQvIynxV/fbTf/EwwwRfLy1szGLZSdml4G0 gHohkWaosr4R2A7sZOc/PZGtstqpBRTD8RwVJx0pseC6Zp/01WH/FjzNpXahFPgR1QXy3qBGEHRh xA08g0+QiGSz+QX5PPQ2dBkTRIY= </publish> </snapshot>

The following validation rules must be observed when creating or parsing snapshot files:

o A RP MUST NOT process any snapshot file that is not well formed, or which does not conform to the RELAX NG schema outlined in Section 5 of this document. o The XML namespace MUST be HTTP://www.ripe.net/rpki/rrdp. o The encoding MUST be us-ascii. o The version attribute in the notification root element MUST be 1 o The session_id attribute MUST match the expected session_id in the reference in the notification file. o The serial attribute MUST match the expected serial in the reference in the notification file. o The hexadecimal encoding of the SHA-256 hash of this snapshot file MUST match the hash attribute in the reference in the notification file.

3.4. Delta File

3.4.1. Purpose



An incremental delta file contains all changes for exactly one serial increment of the publication server. In other words a single delta will typically include all the new objects, updated objects and withdrawn objects that a Certification Authority sent to the publication server. In its simplest form the update could concern only a single object, but it is recommended that CAs send all changes for one of their key pairs: i.e. updated objects as well as a new manifest and CRL as one atomic update message.


A repository server MAY use caching infrastructure to cache delta files and reduce the load of http(s) requests to a central repository server. To support this it is important that delta files for a specific session_id and serial have a unique URL. The files themselves reflect the content of the repository at a specific point in time, and for that reason they never change. Aside from space concerns this means that these files MAY therefore be cached indefinitely.

To support RPs that are slow to process old, possibly cached, notification files, the publication server SHOULD ensure that old delta files remain available for some time after have last appeared on a notification file. It is RECOMMENDED that these files are kept for at least two times as long as the notification file cache period, i.e. 10 minutes. However, space permitting, the publication server is welcome to keep these files available for longer.


Example snapshot file:



<delta xmlns="HTTP://www.ripe.net/rpki/rrdp" version="1" session_id="9df4b597-af9e-4dca-bdda-719cce2c4e28" serial="5932"> <publish uri="rsync://bandito.ripe.net/repo/3a87a4b1-6e22-4a63-ad0f-06f83ad3ca16/default/671570f06499fbd2d6ab76c4f22566fe49d5de60.mft" hash="226AB8CD3C887A6EBDDDF317F2FAFC9CF3EFC5D43A86347AC0FEFFE4DC0F607E"> MIAGCSqGSIb3DQEHAqCAMIACAQMxDzANBglghkgBZQMEAgEFADCABgsqhkiG9w0BCRABGqCAJIAE gYkwgYYCAguWGA8yMDE0MTIwMzE4MDg0MFoYDzIwMTQxMjA0MTgwODQwWgYJYIZIAWUDBAIBMFMw URYsNjcxNTcwZjA2NDk5ZmJkMmQ2YWI3NmM0ZjIyNTY2ZmU0OWQ1ZGU2MC5jcmwDIQD1h9mcwKzN 70He/gIMVxszGJlIXLh/TGzkaNTXxLixmwAAAAAAAKCAMIIFGjCCBAKgAwIBAgICC5YwDQYJKoZI hvcNAQELBQAwMzExMC8GA1UEAxMoNjcxNTcwZjA2NDk5ZmJkMmQ2YWI3NmM0ZjIyNTY2ZmU0OWQ1 ZGU2MDAeFw0xNDEyMDMxODA4NDBaFw0xNDEyMTAxODA4NDBaMDMxMTAvBgNVBAMTKDMzMTI1YzA4 NmEwOWEyOTJkYzQxMWI1MzkwODA2ZDA4NTMxM2E1MTQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCak1G7912fuezSWPpPqER3aZaP4HShGiIiRWeJLOYKpklAeSO8kRa9R+yDCa9CMi1B lewW/C5Coomb9teVZRg31YkpZlXqqNGg8GVesNMJX3ryuizQ+WRUcgwJoakqWH7wPu5zdfFj4Cpk BpgJF+6TBYwXTjAmxfFP0hm0QLWCLxEd1gBGEdBmOogHqfOZHU95GLjllzsPRmR13kyh7BbYMie+ ENJAqqKBlQvW86xPEDMJKUc0uQDnTPCZQBqFwE1xrgUAuSCfJMUguAE8clsshOFe8ROF9t6NIBxK oxA+PTYCpcthCBtdCFyWn/SLp1pb3gIA6xP9ESGlRHNumPL3AgMBAAGjggI2MIICMjAdBgNVHQ4E FgQUMxJcCGoJopLcQRtTkIBtCFMTpRQwHwYDVR0jBBgwFoAUZxVw8GSZ+9LWq3bE8iVm/knV3mAw DgYDVR0PAQH/BAQDAgeAMGcGCCsGAQUFBwEBBFswWTBXBggrBgEFBQcwAoZLcnN5bmM6Ly9iYW5k aXRvLnJpcGUubmV0L3JlcG8vM2E4N2E0YjEtNmUyMi00YTYzLWFkMGYtMDZmODNhZDNjYTE2L2Rl ZmF1bHQvMIGWBggrBgEFBQcBCwSBiTCBhjCBgwYIKwYBBQUHMAuGd3JzeW5jOi8vYmFuZGl0by5y aXBlLm5ldC9yZXBvLzNhODdhNGIxLTZlMjItNGE2My1hZDBmLTA2ZjgzYWQzY2ExNi9kZWZhdWx0 LzY3MTU3MGYwNjQ5OWZiZDJkNmFiNzZjNGYyMjU2NmZlNDlkNWRlNjAubWZ0MIGJBgNVHR8EgYEw fzB9oHugeYZ3cnN5bmM6Ly9iYW5kaXRvLnJpcGUubmV0L3JlcG8vM2E4N2E0YjEtNmUyMi00YTYz LWFkMGYtMDZmODNhZDNjYTE2L2RlZmF1bHQvNjcxNTcwZjA2NDk5ZmJkMmQ2YWI3NmM0ZjIyNTY2 ZmU0OWQ1ZGU2MC5jcmwwGAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjAhBggrBgEFBQcBBwEB/wQS MBAwBgQCAAEFADAGBAIAAgUAMBUGCCsGAQUFBwEIAQH/BAYwBKACBQAwDQYJKoZIhvcNAQELBQAD ggEBAEO1dSFDN4wZqtZ0fWo5G0YVN+mtk6tKhHPFwX7ydTofnHZkE2pO7C93XcgPcP4zLUBPt5kS aH+0vcBxs9Vg//58cHRUEHhls9O/XcS8RXCVkNiga+9NB5s4oi0+i/gDU3eOUqE/jqSJAJAS+Ehi tvNh0LuLrW92NrOfbYDk29how3uxK4JucIAQ05i63l7EAeQp3WeI8nVzB9Rfrkv+PSV+57mSXXtJ /jWu3kyjvsxRjeUL3Im2Z1F48zfVF6pVaDT7ib4YbKOyAQTMpi4W6NZwgQskda9B8/0qV/d+2JrC m3Ozm0t2laoH8xKP/OC33bBXLCxUvkVqvB/Y+TUXfAEAADGCAawwggGoAgEDgBQzElwIagmiktxB G1OQgG0IUxOlFDANBglghkgBZQMEAgEFAKBrMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGjAc BgkqhkiG9w0BCQUxDxcNMTQxMjAzMTgwODQwWjAvBgkqhkiG9w0BCQQxIgQgdNPMbp9lJJHNMmIz

00ff73VkVFYWo2Uf6/b4zIzFZucwDQYJKoZIhvcNAQEBBQAEggEAXHNHm+DUD1s9IQMewvKsoNGi fXL2jG3yfuGys5x1aJji3bIKGiU+weHmnP9aoH9UFRLk6pW1wFOS0+6M87UD8cU17w9F10e0258S 9p7xHMgbrYqXrX9OucMqiN4M+ThDzyDXnfNAOgw5XNJu9KRndS9vyXS6lcvD7JTOhkyqKsrqHXlM 0pX+rYFtrF2RNjB54veooSkcKGojXReLttZbvVKWKwkVg2RJy4tt7MOGU0Q6qa/J5S7O6xvwPjkY yCFvrHm+CgeXoR/3Hg/Rk/NdsK4K1u5dXhRh3KYv4P/hnGSD83aFE9t/DTicvl6SjaXFCtLtJlTX BqSW7wgZ6OoLxwAAAAAAAA== </publish> <publish uri="rsync://bandito.ripe.net/repo/3a87a4b1-6e22-4a63-ad0f-06f83ad3ca16/default/671570f06499fbd2d6ab76c4f22566fe49d5de60.crl" hash="2B551A6C10CCA04C174B0CEB3B64652A5534D1385BEAA40A55A68CB06055E6BB"> MIIBxTCBrgIBATANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQDEyg2NzE1NzBmMDY0OTlmYmQyZDZh Yjc2YzRmMjI1NjZmZTQ5ZDVkZTYwFw0xNDEyMDMxODA4NDBaFw0xNDEyMDQxODA4NDBaMBUwEwIC C5UXDTE0MTIwMzE4MDg0MFqgMDAuMB8GA1UdIwQYMBaAFGcVcPBkmfvS1qt2xPIlZv5J1d5gMAsG A1UdFAQEAgILljANBgkqhkiG9w0BAQsFAAOCAQEAIbL+8connmKLeypzs/P6FOHv8elmLp6dFlId SDpZT7p6y9xLZkvuow39XOs6NB1AOA+92uao9hEV1XuEBGP98nsx0frL8HJtKcEn0q5LGqA4YeBG n28+Ldvlh4DetiKvFpsKW/VYqjRumHcgTdWpESY/f9hH3xW6JCggH5cFGFF/dCsCdGT1v+m53zf4 Dlz8KhRDEaok3UMycX9XUWMB5HSwf05Qrha2LIFf66uk6AQQEmV9ZiBq3IdbkdNd90TIVDMvnSW/ p9Xygdx8azaE2+hsOc9J7+E2kBuu4isLhvfZmChtFpxIUrljQRD4iUil8/xmB6MAIptoF1EslpAI aw== </publish> <withdraw uri="rsync://bandito.ripe.net/repo/3a87a4b1-6e22-4a63-ad0f-06f83ad3ca16/default/example.roa" hash="2B551A6C10CCA04C174B0CEB3B64652A5534D1385BEAA40A55A68CB06055E6BB"/> </delta>



Note that a formal RELAX NG specification of this file format is included later in this document. A RP MUST NOT process any update notification file that is incomplete or not well formed.

The following validation rules must be observed when creating or parsing snapshot files:

o A RP MUST NOT process any delta file that is not well formed, or which does not conform to the RELAX NG schema outlined in Section 5 of this document. o The XML namespace MUST be HTTP://www.ripe.net/rpki/rrdp. o The encoding MUST be us-ascii. o The version attribute in the notification root element MUST be 1 o The session_id attribute MUST be a random version 4 UUID unique to this session o The session_id attribute MUST match the expected session_id in the reference in the notification file. o The serial attribute MUST match the expected serial in the reference in the notification file. o The hexadecimal encoding of the SHA-256 hash of this snapshot file MUST match the hash attribute in the reference in the notification file. o A publish element MUST include a hash attribute, if the object is intended to replace another object in the RPKI, and its value MUST be the hexadecimal encoding of the SHA-256 hash of the replaced object. If the published object does not replace another object the hash attribute MUST NOT be included. Note that this is an extension to the publication protocol that is not, yet, reflected in [I-D.ietf-sidr-publication]. o Similarly a withdraw element MUST contain a hash attribute with the hexadecimal encoding of the SHA-256 hash of the withdrawn object. Including the hashes in this manner allows relying parties to identify specific objects by their hash rather than the URI where they are found.

3.5. SIA for CA certificates

Certificate Authorities that use this delta protocol MUST have an instance of an SIA AccessDescription in addition to the ones defined in [RFC6487],

AccessDescription ::= SEQUENCE { accessMethod OBJECT IDENTIFIER, accessLocation GeneralName }

This extension MUST use an accessMethod of id-ad-rpkiNotify, see: [IANA-AD-NUMBERS],

id-ad OBJECT IDENTIFIER ::= { id-pkix 48 } id-ad-rpkiNotify OBJECT IDENTIFIER ::= { id-ad 13 }



The accessLocation MUST be a URI [RFC3986], using the ’HTTP’ or ’HTTPS’ protocol, that will point to the update notification file for the publication server that publishes the products of this CA certificate.

Relying Parties that do not support this delta protocol MUST MUST NOT reject a CA certificate merely because it has an SIA extension containing this new kind of AccessDescription.

4. Relying Party Use

4.1. Full Synchronisation

When a Relying Party first encounters a notification file URI as an SIA of a certificate that it has validated it SHOULD retrieve the notification file and download the latest snapshot to get in sync with the current version of the publication server.

The RP SHOULD reject the snapshot file and raise an operator alert, if its hash does not match the hash listed in the notification file. However, if the RP does not have any prior state it may choose to process this snapshot file anyway. It should be noted that the RPKI objects are protected by object security, so problems or attacks on the publication server or transport can result in witholding or replaying old objects, but it cannot force the RP to accept invalid objects. Using the remaining or old objects for validation is probably better than rejecting everything, since the latter could be used as a denial of service vector on relying parties.

4.2. Processing Deltas

It is RECOMMENDED that the RP notes the URI, session_id and serial number when it first learns about a notification file. The RP MAY then poll the file to discover updates. How frequently the RP does this is largely up to local policy. The polling frequency determines in part what propogation time that a RP is willing to accept between the moment that a change is published in the RPKI, and the moment that those changes are processed and validated. As discussed in Section 3.2.2 there does not seem to be a need to have a propogation time that is below five minutes. Since the publication server infrastructure MAY cache the notification file for up to five minutes a slightly more frequent polling strategy may be useful, however the RP SHOULD NOT poll more frequently than once per minute. More frequent polling would only result in marginal gains in propagation, while causing unnecessary load on the caching infrastructure.

If the RP finds that the session_id has changed, or if it cannot find a contiguous chain of links to delta files from its current serial to publication server’s current serial, then it MUST perform a full synchronisation instead of continuing to process deltas.



If the RP finds a contiguous chain of links to delta files from its current serial to the publication server’s current serial, and the session_id has not changed, it should download all missing delta files. If any delta file cannot be downloaded, or its hash does not match the hash listed on the notification file, or if no such chain of deltas is availabe, or the session_id has changed, then the RP MUST perform a full synchronisation instead.

New objects found in delta files can be added to the RPs local copy of the repository. However, it is RECOMMENDED that the RP treats object updates and withdraws with some skepticism. A compromised publication server may not have access to the certification authorities’ keys, but it can pretend valid objects have been withdrawn. Therefore it may be preferred to use a strategy where local copies of objects are only discarded when the RP is sure that they are no longer relevant, e.g. the CA has explicitly revoked them, removed the objects from a valid manifest that it issued, or they have expired.

5. XML Schema

The following is a RELAX NG compact form schema describing version 1 of this protocol.



# # RelaxNG schema for RPKI Repository Delta Protocol (RRDP). #

default namespace = "HTTP://www.ripe.net/rpki/rrdp"

version = xsd:positiveInteger { maxInclusive="1" } serial = xsd:nonNegativeInteger uri = xsd:anyURI uuid = xsd:string { pattern = "[\-0-9a-fA-F]+" } hash = xsd:string { pattern = "[0-9a-fA-F]+" } base64 = xsd:base64Binary

# Notification file: lists current snapshots and deltas

start |= element notification { attribute version { version }, attribute session_id { uuid }, attribute serial { serial }, element snapshot { attribute uri { uri }, attribute hash { hash } }, element delta { attribute serial { serial }, attribute uri { uri }, attribute hash { hash } }* }

# Snapshot segment: think DNS AXFR.

start |= element snapshot { attribute version { version }, attribute session_id { uuid }, attribute serial { serial }, element publish { attribute uri { uri }, base64 }* }

# Delta segment: think DNS IXFR.

start |= element delta { attribute version { version }, attribute session_id { uuid }, attribute serial { serial }, delta_element+ }

delta_element |= element publish { attribute uri { uri },



attribute hash { hash }?, base64 }

delta_element |= element withdraw { attribute uri { uri }, attribute hash { hash } }

# Local Variables: # indent-tabs-mode: nil # comment-start: "# " # comment-start-skip: "#[ \t]*" # End:


TBD


This document has no actions for IANA.

8. Acknowledgements

TBD

9. References

[I-D.ietf-sidr-publication] Weiler, S., Sonalker, A. and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", Internet-Draft draft-ietf-sidr-publication-05, February 2014.

[IANA-AD-NUMBERS] "SMI Security for PKIX Access Descriptor", , <http:// www.iana.org/assignments/smi-numbers/smi-numbers.xhtml #smi-numbers-1.3.6.1.5.5.7.48>.


[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.

[RFC6481] Huston, G., Loomans, R. and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.

[RFC6486] Austein, R., Huston, G., Kent, S. and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.



[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.

Authors’ Addresses

Tim Bruijnzeels RIPE NCC


Oleg Muravskiy RIPE NCC


Bryan Weber Cobenian


Rob Austein Dragon Research Labs


David Mandelberg BBN Technologies



SIDR S. KentInternet-Draft BBNIntended status: Informational D. MaExpires: November 21, 2015 ZDNS May 20, 2015

Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI) draft-kent-sidr-adverse-actions-00

Abstract

This document analyzes actions by or against a CA or independent repository manager in the RPKI that can adversely affect the Internet Number Resources (INRs) associated with that CA or its subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository manager) and fetched by Relying Parties (RPs). The analysis is performed from the perspective of an affected INR holder.

Status of This Memo




This Internet-Draft will expire on November 21, 2015.

Kent & Ma Expires November 21, 2015 [Page 1]

Internet-Draft RPKI Adverse CA Actions May 2015

Copyright Notice





Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Analysis of RPKI Repository Objects . . . . . . . . . . . . . 4 2.1. ROA . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Manifest . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Ghostbusters Record . . . . . . . . . . . . . . . . . . . 8 2.4. Certificate Revocation List . . . . . . . . . . . . . . . 8 2.5. CA Certificates . . . . . . . . . . . . . . . . . . . . . 9 2.6. Router Certificates . . . . . . . . . . . . . . . . . . . 11 3. Analysis of Actions Relative to Scenarios . . . . . . . . . . 12 3.1. Scenario A . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Scenario B . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Scenario C . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4. Scenario D . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Detection and Remediation . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18

1. Introduction

Both Suspenders [I-D.kent-sidr-suspenders] and RPKI Validation Reconsidered [I-D.ietf-sidr-rpki-validation-reconsidered] address mistaes by Resource Public Key Infrastructure (RPKI) [RFC6480] Certification Authorities (CAs) (with respect to subordinate CAs). However, mistakes are not the only way that adverse changes to RPKI data can arise. A CA or repository operator might be subject to an attack [RFC7132]. For a CA, if an attack allows an adversary to use the private keys of that CA to sign RPKI objects, then the effect is analogous to the CA making mistakes. There is also the possibility that a CA or repository operator may be subject to legal measures that compel actions that result in generating "bogus" signed objects or removing legitimate repository data. In many cases, such actions may be hard to distinguish from non-malicious mistakes, other than with respect to the time required to remedy the adverse action. Thus this document examines the implications of adverse actions with respect to Internet Number Resources (INRs) irrespective of the cause of the actions. The document proposes mitigation strategies that take into account the nature of adverse actions, e.g., distinguishing malicious vs. erroneous actions.



This document analyzes the various types of actions by a CA (or independent repository manager) that can adversely affect the Internet Number Resources (INRs) associated with that CA, as well as the INRs of subordinate CAs. The analysis is based on examination of the data items in the RPKI repository, as controlled by a CA (or independent repository manager) and fetched by Relying Parties (RPs). The analysis is done from the perspective of an affected INR holder.

1.1. Terminology


2. Analysis of RPKI Repository Objects

This section enumerates the RPKI repository system objects and examines how changes to them affect Route Origination Authorizations (ROAs) and router certificate validation. Identifiers are assigned to errors for reference by later sections of this document.

The RPKI repository [RFC6481] contains a number of (digitally signed) objects that are fetched and processed by RPs. The principal goal of the RPKI, until the deployment of BGPsec [I-D.ietf-sidr-bgpsec-overview], is to enable an RP to validate ROAs [RFC6482]. A ROA binds address space to an Autonomous System Number (ASN). A ROA can be used to verify BGP announcements (with respect to route origin) [RFC6483]. The most important objects in the RPKI (for origin validation) are ROAs; all of the other RPKI objects exist to enable the validation of ROAs in a fashion consistent with the INR allocation system. Thus errors that result in changes to a ROA, or to RPKI objects needed to validate a ROA, can cause RPs to reach different conclusions about the validity of the bindings expressed in a ROA.

When BGPsec is deployed, router certificates [I-D.ietf-sidr-bgpsec-pki-profiles] will be added to repository publication points. These are End-Entity (EE) certificates used to verify signatures applied to BGP update data, to enable path validation [I-D.ietf-sidr-bgpsec-protocol]. Router certificates are as important to path validation as ROAs are to origin validation.

The objects contained in the RPKI repository are of two types: conventional PKI objects (certificates and Certificate Revocation Lists (CRLs)) and RPKI-specific signed objects. The latter make use of a common encapsulation format [RFC6488] based on the Cryptographic Message Syntax (CMS) [RFC5652]. A syntax error in this common format



will cause an RP to reject the object as invalid. In turn, this may cause a ROA at a publication point to be considered invalid.

Adverse actions take several forms:

* Deletion (D) is defined as removing an object from a publication point, without the permission of the INR holder.

* Suppression (S) is defined as not deleting an object, or not publishing an object, as intended by an INR holder. This action also includes retaining a prior version of an object in a publication point when a newer version is available for publication.

* Corruption (C) is defined as modification of a signed object in a fashion not requiring access to the private key used to sign the object. Thus a corrupted object will not carry a valid signature. Implicitly, the corrupted object replaces the legitimate version.

* Modification (M) is defined as publishing a version of an object that differs from the version authorized by the INR holder (but which is still syntactically valid). Implicitly, the legitimate version of the affected object is deleted and replaced by the modified object. The signature on the modified object will be valid in the RPKI.

* Revocation (R) is defined as revoking a certificate (EE or CA) by placing its serial number on the appropriate CRL, without authorization of the INR holder.

* Injection (I) is defined as introducing an instance of a signed object into a publication point. It assumes that the signature on the object will be viewed as valid by RPs.

The first three of these actions (deletion, suppression, and corruption) can be effected by any entity that manages the publication point of the affected INR holder. (An entity with the ability to act as a man-in-the-middle between an RP and a repository also can effect these actions with respect to the RP in question.)

The latter three actions (modification, revocation, and injection) nominally require access to the private key of the INR holder.

All six of these actions also can be effected by a parent CA. A parent CA could reissue the INR holder’s CA certificate, generate new signed objects using the private key associated with the reissued certificate, and publish these objects at a location of its choosing.



Most of these actions may be performed independently or in combination with one another. For example, a ROA may be revoked and deleted or revoked and replaced with a modified ROA. Where appropriate, the analysis of adverse actions will distinguish which of these individual actions, or combinations thereof, yield different outcomes for RPs. Recall that the focus of the analysis is the impact on ROAs and router certificates, with respect to RP processing.

2.1. ROA

In addition to the generic RPKI object syntax checks, ROA validation requires that the signature on the ROA can be validated using the public key from the EE certificate embedded in the ROA [RFC6482]. It also requires that the EE certificate be validated consistent with the procedures described in [RFC6482] and [RFC6487]. Adverse actions against a ROA can cause the following errors:

A-1.1 A ROA may be deleted from the indicated publication point.

A-1.2 A ROA may be revoked on the CRL for the publication point.

A-1.3 Publication of a newer ROA may be suppressed.

A-1.4 A ROA may be corrupted.

A-1.5 A valid ROA may be replaced with a corrupted ROA, which will be rejected by RPs.

A-1.6 A ROA may be modified so that the Autonomous System Number (ASN) or one or more of the address blocks in a ROA is different than the values authorized by the INR holder. (This action assumes that the modified ROA’s ASN and address ranges are authorized for use by the INR holder.)

A-1.7 If an INR holder intends to issue and publish two (or more) new ROAs for the same address space, one (or more) of the new ROAs may be suppressed while the other is published.

A-1.8 If an INR holder intends to delete all ROAs for the same address space, some of them may be held while the others are deleted.

2.2. Manifest

Each repository publication point contains a manifest [RFC6486]. The RPKI incorporates manifests to enable RPs to detect suppression and/ or substitution of (more recent) publication point objects, as the



result of a mistake or attack. A manifest enumerates (by filename) all of the other signed objects at the publication point. The manifest also contains a hash of each enumerated file, to enable an RP to determine if the named file content matches what the INR holder identified in the manifest.

A manifest is an RPKI signed object, so it is validated as per [RFC6488]. If a manifest is modified in a way that causes any of these checks to fail, the manifest will be considered invalid. Suppression of a manifest itself (indicated by a stale manifest) also can cause an RP to not detect suppression of other signed objects at the publication point. However, RPs are not required to reject publication point entries in the face of an invalid manifest. If a signed object at a publication point can be validated (using the rules applicable for that object type), then an RP MAY accept that object, even if there is no matching entry for it on the manifest.

Corruption, suppression, modification, or deletion of a manifest might not affect RP processing of other publication point objects, as specified in [RFC6486]. However, many RP implementations ignore objects that are present at a publication point but not listed in a valid Manifest. Thus the following actions against can impact RP processing:

A-2.1 A Manifest may be deleted from the indicated publication point.

A-2.2 A Manifest may be revoked on the CRL for the publication point.

A-2.3 Publication of a newer Manifest may be suppressed.

A-2.4 A Manifest may be corrupted.

A-2.5 A valid Manifest may be replaced with a corrupted Manifest, which will be rejected by RPs.

A-2.6 A Manifest may be modified to remove one or more objects.

A-2.7 A Manifest may be modified to add one or more objects.

A-2.8 A Manifest may be modified to list an incorrect hash for one or more objects.



2.3. Ghostbusters Record

The Ghostbusters record [RFC6493] is a signed object that MAY be included at a publication point, at the discretion of the INR holder or publication point operator. The record is validated according to [RFC6488]. Additionally, the syntax of the record is verified based on the vCard profile contained in [RFC6493]. Errors in this record do not affect RP processing. However, if an RP encounters a problem with objects at a publication point, the RP may use information from the record to contact the publication point operator.

Adverse actions against a Ghostbusters record can cause the following error:

A-3.1 Suppression, deletion, or corruption of a Ghostbusters record could prevent an RP from contacting the appropriate entity when a problem is detected by the RP. Modification of a Ghostbusters record could cause an RP to contact the wrong entity, thus delaying remediation of an detected anomaly. All of these actions are viewed as equivalent from an RP processing perspective; they do not alter RP validation of ROAs or router certificates. However, these actions can interfere with remediation of the action when detected by an RP.

2.4. Certificate Revocation List

Each publication point contains a CRL that enumerates revoked (and not yet expired) certificates issued by the CA associated with the publication point [RFC6481].

Adverse actions against a CRL can cause the following errors:

A-4.1 If a CRL is deleted, RPs will continue to use an older, previously fetched Certificate Revocation List. As a result, they will not be informed of any changes in revocation status of subordinate CA or router certificates or affected subordinate signed objects, e.g., ROAs or CA certificates. This action is essentially equivalent to corruption of a CRL, since a corrupted CRL will not be accepted by an RP.

A-4.2 If publication of the most recent CRL is suppressed, an RP will not be informed of the most recent revocation status of subordinate CA or router certificates or affected subordinate signed objects. If an EE certificate has been revoked and the associated signed object is still present in the publication point, an RP might mistakenly treat that



object as valid. (This would happen if the object is still in the manifest or the RP is configured to process valid objects that are not on the manifest.) This type of action is of special concern if the affected object is a ROA, a router certificate, or a subordinate CA certificate (since suppression of revocation of any of these objects can have a substantial impact on the RPKI).

A-4.3 If a CRL is modified to erroneously list a signed object’s EE certificate as revoked, the corresponding object will be treated as invalid by RPs, even if it is present in a publication point. If this object is a ROA, the (legitimate) binding expressed by the ROA will be ignored by an RP. If a CRL is modified to erroneously list a router certificate as revoked, a path signature associated with that certificate will likely be treated as invalid by RPs.

A-4.4 If a CRL is modified to erroneously list a CA certificate as revoked, that CA and all subordinate signed objects will be treated as invalid by RPs. Because RPs acquire RPKI data based on AIA and SIA extensions in CA certificates, revocation of a CA certificate may cause RPs to not retrieve all subordinate signed objects. Thus erroneous revocation of a CA certificate may have significant implications for RPs.

A-4.5 If a CRL is modified to omit a revoked EE, router, or CA certificate, RPs may continue to accept the revoked, signed object as valid. This contravenes the intent of the INR holder.

2.5. CA Certificates

Every INR holder is represented by one or more CA certificates. An INR holder has multiple CA certificates if it holds resources acquired from different sources. Also, every INR holder has more than one CA certificate during key rollover [RFC6489] and algorithm rollover [RFC6916].

If a publication point is not a leaf in the RPKI hierarchy, then the publication point will contain one or more CA certificates, each representing a subordinate CA. Each subordinate CA certificate contains a pointer (SIA) to the publication point where the signed objects associated with that CA can be found [RFC6487].



A CA certificate is a complex data structure and thus errors in that structure may have different implications for RPs depending on the specific data that is in error.

Adverse actions against a CA certificate can cause the following errors:

A-5.1 Revocation or deletion of a CA certificate would cause an RP to not be able to locate signed objects generated by that CA. Suppression of a CA certificate with a changed SIA value would have an equivalent effect. Thus an RP would be unaware of the INR bindings asserted in subordinate ROAs, and the RP would be unable to validate router certificates.

A-5.2 Corruption of a CA certificate will cause it to be rejected by RPs. In turn, this will cause any subordinate signed objects to become invalid.

A-5.3 If a CA certificate is modified, but still conforms to the RPKI certificate profile [RFC6485], it will be accepted by RPs. If an [RFC3779] extension in this certificate is changed to exclude INRs that were previously present, then subordinate signed objects will become invalid if they rely on the excised INRs. If these objects are CA certificates, their subordinate signed objects will be treated as invalid. If the objects are ROAs, the binding expressed by the affected ROAs will be ignored by RPs. If the objects are router certificates, BGPsec_Path attributes [I-D.ietf-sidr-bgpsec-protocol] verifiable under these certificates will likely be considered invalid.

A-5.4 If the SIA extension of a CA certificate is modified to refer to another publication point, this will cause an RP to look at another location for subordinate objects. This could cause RPs to not acquire the objects that the INR holder intended to be retrieved. In turn, RPs would not be able to acquire (much less validate) ROAs, router certificates, or any subordinate CA certificates associated with that CA.

A-5.5 If the AIA extension in a CA certificate is modified, it would point to a different CA certificate, not the parent CA certificate. This extension is used only for path discovery, not path validation. Path discovery in the RPKI is usually performed on a top-down basis, starting with TAs and recursively descending the RPKI hierarchy. Thus there



may be no impact on the ability of clients to acquire and validate certificates if the AIA is modified.

A-5.6 If the Subject Public Key Info (and Subject Key Identifier extension) in a CA certificate is modified to contain a public key corresponding to a private key held by the parent, the parent could sign objects as children of the affected CA certificate.

2.6. Router Certificates

Router certificates are used by RPs to verify signatures on BGPsec_Path attributes carried in Update messages.

Each AS is free to determine the granularity at which router certificates are managed [I-D.ietf-sidr-bgpsec-pki-profiles]. Each participating AS is represented by one or more router certificates. During key or algorithm rollover, multiple router certificates will be present in a publication point, even if the AS is normally represented by just one such certificate.

Adverse actions against router certificates can cause the following errors:

A-6.1 Suppression, revocation, or deletion of a router certificate would cause an RP to not be able to verify signatures applied to BGPsec_Path attributes on behalf of the AS in question. In turn, this would cause the route to be treated with lower preference than competing routes that have valid BGPsec_Path attribute signatures. (However, if another router certificate for the affected ASN is valid and contains the same AS number and public key, and is in use by that AS, there would be no effect on routing. This scenario will arise if a router certificate is renewed, i.e., issued with a new validity interval.) Modification of a router certificate that causes it to fail syntax checks will result in the certificate being rejected by RPs. Absent a valid router certificate, BGPsec_Path attributes associated with that certificate will be unverifiable. In turn, this would cause the route to be treated with lower preference than competing routes that have valid BGPsec_Path attribute signatures.

A-6.2 If a router certificate is modified to represent a different ASN, but it still passes syntax checks, then this action could cause signatures on BGPsec_Path attributes to be associated with the wrong AS. This could cause signed



routes to be inconsistent with the intent of the INR holder.

3. Analysis of Actions Relative to Scenarios

This section examines the types of problems that can arise in four scenarios described below. We consider mistakes, (successful) attacks against a CA or a publication point, and situations in which a CA or publication point manager is compelled to take action by a law enforcement authority.

We explore the following four scenarios:

A. An INR holder operates its own CA and manages its own repository publication point.

B. An INR holder operates its own CA, but outsources management of its repository publication point to its parent or another entity.

C. An INR holder outsources management of its CA to its parent, but manages its own repository publication point.

D. An INR holder outsources management of its CA and its publication point to its parent.

Note that these scenarios focus on the affected INR holder as the party directly affected by an adverse action. The most serious cases arise when the INR holder appears as a high-tier CA in the RPKI hierarchy; in such situations subordinate INR holders may be affected as a result of an action. A mistake by or an attack against a "leaf" has more limited impact because all of the affected INRs belong to the INR holder itself.

In Scenario A, actions by the INR holder can adversely affect all of its resources and, transitively, resources of any subordinate CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited to its own INRs.)

In Scenario B, actions by the (outsourced) repository operator also can adversely affect the resources of the INR holder, and those of any subordinates CAs. (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs and the damage is limited, as in Scenario A.) The range of adverse effects here includes those in Scenario A, and adds a new potential source of adverse actions, i.e., the outsourced repository operator.



In Scenario C, all signed objects associated with the INR holder are generated by the parent CA but are self-hosted. (We expect this scenario to be rare, because an INR holder that elects to outsource CA operation seems unlikely to manage its own repository publication point.) Because that CA has the private key used to sign them, it can generate alternative signed objects---ones not authorized by the INR holder. However, erroneous objects created by the parent CA will not be published by the INR holder IF the holder checks them first. Because the parent CA is acting on behalf of the INR holder, mistakes by or attacks against that entity are equivalent to ones effected by the INR holder in Scenario A.

The INR holder is most vulnerable in Scenario D. Actions by the parent CA, acting on behalf of the INR holder, can adversely affect all signed objects associated with that INR holder, including any subordinate CA certificates. These actions will presumably translate directly into publication point changes, because the parent CA is managing the publication point for the INR holder. The range of adverse effects here includes those in Scenarios A, B, and C.

3.1. Scenario A

In this scenario, the INR holder acts as its own CA and it manages its own publication point. Mistakes by the INR holder can cause any of the actions noted in Section 2. A successful attack against this CA can effect all of the modification, revocation, or injection actions noted in that section. (We assume that objects generated by the CA are automatically published). An attack against the publication point can effect all of the deletion, suppression, or corruption actions noted in that section.

3.2. Scenario B

In this scenario, the INR holder acts as its own CA and but it outsources management of it own publication point. Mistakes by the INR holder can cause any of the actions noted in Section 2. A successful attack against its CA can effect all of the modification, revocation, or injection actions noted in that section (assuming that objects generated by the CA are automatically published). Here, actions by the publication point manager (or attacks against that entity) can effect all of the deletion, suppression, or corruption actions noted in Section 2.

3.3. Scenario C

In this scenario, the INR holder outsources management of its CA to its parent, but manages its own repository publication point. Mistakes by the INR holder, acted upon by the parent CA, can cause



any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect, unless the INR holder checks the signed objects before publishing them. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2. An attack against the INR holder can effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the INR holder is managing its publication point). (An attack against the INR holder implies that the path it uses to direct the parent CA to issue and publish objects has been compromised.)

3.4. Scenario D

In this scenario an INR holder outsources management of both its CA and its publication point to its parent. Mistakes by the INR holder, acted upon by the parent CA, can cause any of the actions noted in Section 2. Actions unilaterally undertaken by the parent CA also can have the same effect. A successful attack against the parent CA can effect all of the modification, revocation, or injection actions noted in Section 2. An attack against the parent CA can effect all of the deletion, suppression, or corruption actions noted in Section 2 (because the parent CA is managing the INR holder’s publication point).

4. Detection and Remediation

Each INR holder SHOULD check the signed objects available in its publication point, to detect problems, on a regular basis. This document RECOMMENDS that each INR holder perform such checks as a side-effect of acquiring RPKI data for local processing, e.g., 3-4 times a day. Third parties also can perform checks in behalf of RPs, to detect adverse actions. This is consistent with the outsourcing options noted in the use cases in Section 1. In either situation, detection of adverse actions requires that the cognizant party have available a reference set of RPKI data for the INR holder. The reference set includes all signed objects in the publication point(s) of the INR holder plus the CA certificate for each publication point.

If an adverse action is the result of a mistake by, or an attack against, a superior CA or a repository manager, the INR holder SHOULD contact the relevant entity as soon as possible. It is expected that a mistake by these entities normally will be corrected and new objects published within 24-72 hours. An attack against a superior CA or repository manager also should be remedied by the affected parties, but the time to repair the damage may be longer, because of the additional activities that may accompany responding to an attack.



In both of these situations, the harmful effects of adverse actions can be mitigated if RPs delay acting on changes that might be attributable to adverse actions. This observation motivates the introduction of hysteresis into the RPKI validation process, at least with respect to changes that are indicative of an adverse action. The idea is that an RP would continue to accept as valid objects that were previously valid (based on local cache history), and ignore recent changes, for some interval. However, sometimes an INR holder may wish to make a change that might be viewed as an adverse action, without encountering such a delay.

To accommodate this situation, the RPKI can be extended to allow an INR holder to provide independent confirmation of such changes. A mechanism of this sort could prevent mistakes by a superior CA or repository manager from having an immediate, adverse effect. If the independent confirmation is not completely dependent on the RPKI repository and CA system, it can be immune to mistakes by or attacks against superior CAs and repository managers, and outsourced CA and repository managers.

The effects of an attack on an INR holder itself may not be countered by a mechanism of this sort; an adversary who can attack a CA and/or repository management function of an INR holder may be able to attack the independent confirmation mechanism at the same time. The use of a separate mechanism does create the potential for additional safeguards against such attacks. However, the extent to which this potential is achieved will depend on how an INR holder implements and manages this mechanism.

If a superior CA or repository manager is compelled to engage in an adverse action against an INR holder, e.g., by a law enforcement agency, use of an independent confirmation mechanism also may be able to counter such an action. In this situation, the actions are not likely to be reversed quickly, unlike a mistake or attack. This situation might argue for a longer period of delay. An INR holder and a subordinate INR holder may disagree about an action that invalidates the holdings of the subordinate. The addition of hysteresis and an independent confirmation mechanism to the RPKI ought not deprive an INR holder of the legitimate ability to take such actions. This argues for a time limit on the hysteresis and confirmation mechanism, consistent with the business practices of RPKI CAs. This time limit should be long enough to allow affected entities to remedy mistakes and recover from attacks. It also should be short enough to not impede the resolution of legitimate actions by an INR holder relative to subordinate INR holders.




This informational document describes a threat model for the RPKI, focusing on mistakes by or attacks against CAs and independent repository managers. It is intended to support the design of future RPKI security mechanisms that seek to address the concerns associated with such actions.


This document has no actions for IANA.

7. Acknowledgements

The authors would like to thank Richard Hansen and David Mandelberg for their review feedback. The authors also thank Richard Hansen for his editorial assistance.

8. References


[I-D.ietf-sidr-bgpsec-overview] Lepinski, M. and S. Turner, "An Overview of BGPsec", draft-ietf-sidr-bgpsec-overview-06 (work in progress), January 2015.

[I-D.ietf-sidr-bgpsec-pki-profiles] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests", draft-ietf-sidr-bgpsec-pki- profiles-10 (work in progress), January 2015.

[I-D.ietf-sidr-bgpsec-protocol] Lepinski, M., "BGPsec Protocol Specification", draft-ietf- sidr-bgpsec-protocol-11 (work in progress), January 2015.


[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.



[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.

[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012.

[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.

[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, February 2012.

[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.

[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.

[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, February 2012.

[RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, April 2013.

[RFC7132] Kent, S. and A. Chi, "Threat Model for BGP Path Security", RFC 7132, February 2014.




[I-D.ietf-sidr-rpki-validation-reconsidered] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., Newton, A., and A. Aina, "RPKI Validation Reconsidered", draft-ietf-sidr-rpki-validation-reconsidered-01 (work in progress), January 2015.

[I-D.kent-sidr-suspenders] Kent, S. and D. Mandelberg, "Suspenders: A Fail-safe Mechanism for the RPKI", draft-kent-sidr-suspenders-03 (work in progress), April 2015.


Stephen Kent BBN Technologies 10 Moulton St Cambridge, MA 02138-1119 USA

EMail: [email protected]

Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian, Beijing 100190 China

EMail: [email protected]


IDR and SIDR K. SriramInternet-Draft D. MontgomeryIntended status: Standards Track US NISTExpires: January 6, 2016 B. Dickson Twitter, Inc. July 5, 2015

Methods for Detection and Mitigation of BGP Route Leaks draft-sriram-idr-route-leak-detection-mitigation-01

Abstract

In [I-D.ietf-grow-route-leak-problem-definition], the authors have provided a definition of the route leak problem, and also enumerated several types of route leaks. In this document, we first examine which of those route-leak types are detected and mitigated by the existing origin validation (OV) [RFC 6811] and BGPSEC path validation [I-D.ietf-sidr-bgpsec-protocol]. Where the current OV and BGPSEC protocols don’t offer a solution, this document suggests an enhancement that would extend the route-leak detection and mitigation capability of BGPSEC. The solution can be implemented in BGP without necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC is one way of implementing it in a secure way. We do not claim to have provided a solution for all possible types of route leaks, but the solution covers several, especially considering some significant route-leak attacks or occurrences that have been observed in recent years. The document also includes a stopgap method for detection and mitigation of route leaks for the phase when BGPSEC (path validation) is not yet deployed but only origin validation is deployed.

Status of This Memo




This Internet-Draft will expire on January 6, 2016.

Sriram, et al. Expires January 6, 2016 [Page 1]

Internet-Draft Route Leak Detection and Mitigation July 2015

Copyright Notice



Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Related Prior Work . . . . . . . . . . . . . . . . . . . . . 3 3. Mechanisms for Detection and Mitigation of Route Leaks . . . 4 3.1. Route Leak Protection (RLP) Field Encoding by Sending Router . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Recommended Actions at a Receiving Router for Detection of Route Leaks . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Recommended Actions at a Receiving Router when the Sender is a Customer . . . . . . . . . . . . . . . . 8 3.2.2. Recommended Actions at a Receiving Router when the Sender is a Peer . . . . . . . . . . . . . . . . . . 9 3.3. Possible Actions at a Receiving Router for Mitigation . . 10 4. Stopgap Solution when Only Origin Validation is Deployed . . 10 5. Design Rationale and Discussion . . . . . . . . . . . . . . . 11 5.1. Is route-leak solution without BGPSEC a serious attack vector? . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Comparison with other methods, routing security BCP . . . 12 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 17

1. Introduction

In [I-D.ietf-grow-route-leak-problem-definition], the authors have provided a definition of the route leak problem, and also enumerated several types of route leaks. In this document, we first examine



which of those route-leak types are detected and mitigated by the existing Origin Validation (OV) [RFC6811] and BGPSEC path validation [I-D.ietf-sidr-bgpsec-protocol]. For the rest of this document, we use the term BGPSEC as synonymous with path validation. The BGPSEC protocol provides cryptographic protection for some aspects of BGP update messages. OV and BGPSEC together offer mechanisms to protect against mis-originations and hijacks of IP prefixes as well as man- in-the-middle (MITM) AS path modifications. Route leaks (see [I-D.ietf-grow-route-leak-problem-definition] and references cited at the back) are another type of vulnerability in the global BGP routing system against which OV and BGPSEC so far offer only partial protection.

For the types of route leaks enumerated in [I-D.ietf-grow-route-leak-problem-definition], where the current OV and BGPSEC protocols don’t offer a solution, this document suggests an enhancement that would extend the detection and mitigation capability of BGPSEC. The solution can be implemented in BGP without necessarily tying it to BGPSEC. Incorporating the solution in BGPSEC is one way of implementing it in a secure way. We do not claim to provide a solution for all possible types of route leaks, but the solution covers several relevant types, especially considering some significant route-leak occurrences that have been observed frequently in recent years. The document also includes (in Section 4) a stopgap method for detection and mitigation of route leaks for the phase when BGPSEC (path validation) is not yet deployed but only origin validation is deployed.

2. Related Prior Work

The basic idea and mechanism embodied in the proposed solution is based on setting an attribute in BGP route announcement to manage the transmission/receipt of the announcement based on the type of neighbor (e.g. customer, provider, etc.). Documented prior work related to said basic idea and mechanism dates back to at least the 1980’s. Some examples of prior work are: (1) Information flow rules described in [proceedings-sixth-ietf] (see pp. 195-196); (2) Link Type described in [RFC1105-obsolete] (see pp. 4-5); (3) Hierarchical Recording described in [draft-kunzinger-idrp-ISO10747-01] (see Section 6.3.1.12). The problem of route leaks and possible solution mechanisms based on encoding peering-link type information (e.g. p2c, c2p, p2p, etc.) in BGPSEC updates and protecting the same under BGPSEC path signatures have been discussed in IETF SIDR WG at least since 2011. Dickson developed the initial Internet draft of these mechanisms in a BGPSEC context; see [draft-dickson-sidr-route-leak-solns]. The draft expired in 2012. [draft-dickson-sidr-route-leak-solns] defined neighbor relationships on a per link basis, but in the current draft the relationship in



encoded per prefix, as prefixes with different business models are often sent over the same link. Also [draft-dickson-sidr-route-leak-solns] proposed a second signature block for the link type encoding, separate from the path signature block in BGPSEC. By contrast, in the current draft when BGPSEC-based solution is considered, cryptographic protection is provided for Route Leak Protection (RLP) encoding using the same signature block as that for path signatures (see Section 3.1).

3. Mechanisms for Detection and Mitigation of Route Leaks

Referring to the enumeration of route leaks discussed in [I-D.ietf-grow-route-leak-problem-definition], Table 1 summarizes the route-leak detection capability offered by OV and BGPSEC for different types of route leaks. (Note: Prefix filtering is not considered here in this table. Please see Section 4.)

A detailed explanation of the contents of Table 1 is as follows. It is readily observed that route leaks of Types 1, 5, 6, and 7 are not detected by OV or even by BGPSEC. Type 2 route leak involves changing a prefix to a subprefix (i.e. more specific); such a modified update will fail BGPSEC checks. Clearly, Type 3 route leak involves mis-origination or hijacking, and hence can be detected by OV. In the case of Type 3 route leak, there would be no existing ROAs to validate a re-originated prefix or subprefix, but instead a covering ROA would normally exist with the legitimate AS, and hence the update will be considered Invalid by OV.



+---------------------------------+---------------------------------+ | Type of Route Leak | Detection Coverage and Comments | +---------------------------------+---------------------------------+ | Type 1: U-Turn with Full Prefix | Neither OV nor BGPSEC (in its | | | current form) detects Type 1. | | ------------------------------- | ------------------------------- | | Type 2: U-Turn with More | In OV, the ROA maxLength may | | Specific Prefix | offer detection of Type 2 in | | | some cases; BGPSEC (in its | | | current form) always detects | | | Type 2. | | ------------------------------- | ------------------------------- | | Type 3: Prefix Mis-Origination | OV by itself detects Type 3; | | with Data Path to Legitimate | BGPSEC does not detect Type 3. | | Origin | | | ------------------------------- | ------------------------------- | | Type 4: Leak of Internal | For internal prefixes never | | Prefixes and Accidental | meant to be seen (i.e. routed) | | Deaggregation | on the Internet, OV helps | | | detect their leak; they might | | | either have no covering ROA or | | | have an AS0-ROA to always | | | filter them. In the case of | | | accidental deaggregation, OV | | | may offer some detection due to | | | ROA maxLength. BGPSEC does not | | | catch Type 4. | | ------------------------------- | ------------------------------- | | Type 5: Lateral ISP-ISP-ISP | Neither OV nor BGPSEC (in its | | Leak | current form) detects Type 5. | | ------------------------------- | ------------------------------- | | Type 6: Leak of Provider | Neither OV nor BGPSEC (in its | | Prefixes to Peer | current form) detects Type 6. | | ------------------------------- | ------------------------------- | | Type 7: Leak of Peer Prefixes | Neither OV nor BGPSEC (in its | | to Provider | current form) detects Type 7. | +---------------------------------+---------------------------------+

Table 1: Examination of Route-Leak Detection Capability of Origin Validation and Current BGPSEC Path Validation

In the case of Type 4 leaks involving internal prefixes that are not meant to be routed in the Internet, they are likely to be detected by OV. That is because such prefixes might either have no covering ROA or have an AS0-ROA to always filter them. In the case of Type 4 leaks that are due to accidental deaggregation, they may be detected due to violation of ROA maxLength. BGPSEC does not catch Type 4. However, route leaks of Type 4 are least problematic due to the



following reasons. In the case of accidental deaggregation, the offending AS is itself the legitimate destination of the leaked more- specific prefixes. Hence, in most cases of this type, the data traffic is neither misrouted not denied service. Also, leaked announcements of Type 4 are short-lived and typically withdrawn quickly following the announcements. Further, the MaxPrefix limit may kick-in in some receiving routers and that helps limit the propagation of sometimes large number of leaked routes of Type 4.

Realistically, BGPSEC may take a much longer time being deployed than OV. Hence solution proposals for route leaks should consider both scenarios: (A) OV only (without BGPSEC) and (B) OV plus BGPSEC. Assuming an initial scenario A, and based on the above discussion and Table 1, it is evident that in our proposed solution method, we need to focus primarily on route leaks of Types 1, 2, 5, 6, and 7. In Section 3.1 and Section 3.2, we describe a simple addition to BGP that facilitates detection of route leaks of Types 1, 2, 5, 6, and 7. The simple addition involves a Route Leak Protection (RLP) field, which is carried in an optional transitive path attribute in BGP. When BGPSEC is deployed, the RLP field will be accommodated in the existing Flags field (see [I-D.ietf-sidr-bgpsec-protocol]) which is cryptographically protected under path signatures.

3.1. Route Leak Protection (RLP) Field Encoding by Sending Router

The key principle is that, in the event of a route leak, a receiving router in a provider AS (e.g. referring to Figure 1, ISP2 (AS2) router) should be able to detect from the prefix-update that its customer AS (e.g. AS3 in Figure 1) SHOULD NOT have forwarded the update (towards the provider AS). This means that at least one of the ASes in the AS path of the update has indicated that it sent the update to its customer or peer AS, but forbade any subsequent ’Up’ forwarding (i.e. from a customer AS to its provider AS). For this purpose, a Route Leak Protection (RLP) field to be set by a sending router is proposed to be used for each AS hop.



/\ /\ \ route-leak(P)/ \ propagated / \ / +------------+ peer +------------+ ______| ISP1 (AS1) |----------->| ISP2 (AS2)|----------> / ------------+ prefix(P) +------------+ route-leak(P) | prefix | \ update /\ \ propagated \ (P) / \ / \ ------- prefix(P) \ / \ update \ / \ \ /route-leak(P) \/ \/ / +---------------+ | customer(AS3) | +---------------+

Figure 1: Illustration of the basic notion of a route leak.

For the purpose of route leak detection and mitigation proposed in this document, the RLP field value SHOULD be set to one of two values as follows:

o 00: This is the default value (i.e. "nothing specified"),

o 01: This is the ’Do not Propagate Up’ indication; sender indicating that the prefix-update SHOULD NOT be forwarded ’Up’ towards a provider AS.

There are two different scenarios when a sending AS SHOULD set the ’01’ indication in a prefix-update: (1) when sending the prefix- update to a customer AS, and (2) to let a peer AS know not to forward the prefix-update ’Up’ towards a provide AS. In essence, in both scenarios, the intent of ’01’ indication is that any receiving AS along the subsequent AS path SHOULD NOT forward the prefix-update ’Up’ towards its (receiving AS’s) provider AS.

One may argue for additional RLP indications: for example, ’10’ to specify ’Propagate to Customers Only’, and possibly ’11’ to signal ’Do Not Propagate’ (i.e. NO_EXPORT). But in the interest of keeping the methodology simple, the choice of two RLP field values as defined above (00 - default, and 01 - ’Do not Propagate Up’) is all that is needed. This two-state specification in the RLP field can be shown to work for detection and mitigation of route leaks of Types 1, 2, 5, 6, and 7, which are the focus here (see Section 3.2 and Section 3.3).



The proposed RLP encoding SHOULD be carried in BGP-4 [RFC4271] updates in an optional transitive path attribute. In BGPSEC enabled routers, the RLP encoding SHOULD be accommodated in the existing Flags field in BGPSEC updates. The Flags field is part of the Secure_Path Segment in BPGSEC updates [I-D.ietf-sidr-bgpsec-protocol]. It is one octet long, and one Flags field is available for each AS hop, and currently only the first bit is used in BGPSEC. So there are 7 bits that are currently unused in the Flags field. Two (or more if needed) of these bits can be designated for the RLP field. Since the BGPSEC protocol specification requires a sending AS to include the Flags field in the data that are signed over, the RLP field for each hop (assuming it would be part of the Flags field) will be protected under the sending AS’s signature.

3.2. Recommended Actions at a Receiving Router for Detection of Route Leaks

The recommended receiver actions differ slightly depending on whether the update is received from a customer or a peer. When detecting route leaks of Type 1, 2, and 7, the receiving router is dealing with a customer as the sender. When detecting route leaks of Type 5 and 6, the receiving router is dealing with a peer as the sender.

3.2.1. Recommended Actions at a Receiving Router when the Sender is a Customer

We provide here an example set of receiver actions that work to detect and mitigate route leaks of Types 1, 2, and 7. This example algorithm serves as a proof of concept. However, other receiver algorithms or procedures can be designed (based on the same sender specification as in Section 3.1) and may perform with greater efficacy, and are by no means excluded.

A recommended receiver algorithm for detecting a route leak is as follows:

A receiving router SHOULD mark an update as a Route-Leak if ALL of the following conditions hold true:

1. The update is received from a customer AS.

2. It is Valid in accordance with the Origin Validation (OV) and BGPSEC protocols. (Note: BGPSEC validation is not applicable if update is not signed).



3. The update has the RLP field set to ’01’ (i.e. ’Do not Propagate Up’) indication for one or more hops (excluding the most recent) in the AS path.

The reason for stating "excluding the most recent" in the above algorithm is as follows. The provider AS already knows that the most recent hop in the update is from its customer AS to itself, and it does not need to rely on the RLP field value set by the customer for detection of route leaks.

A receiving router expects the RLP field value for any hop in the AS path to be either 00 or 01. However, if a different value (say, 10 or 11) is found in the RLP field, then an error condition will get flagged, and any further action is TBD.

3.2.2. Recommended Actions at a Receiving Router when the Sender is a Peer

The sender and receiver actions described in Section 3.1 and Section 3.2.1 clearly help detect and mitigate route leaks of Types 1, 2, and 7. With a slightly modified interpretation of the RLP encoding on the receiver side, they can be extended to detect lateral ISP-ISP-ISP route leaks (Type 5) as well as leaks of provider prefixes to peer (Type 6). (Note: RLP encoding procedure by sending routers remains the same as described in Section 3.1.)

A recommended receiver algorithm for an ISP to detect a route leak of either Type 5 or Type 6 is as follows:

A receiving BGPSEC router SHOULD mark an update as a Route-Leak if ALL of the following conditions hold true:

1. The update is received from a lateral ISP peer.

2. It is Valid in accordance with the Origin Validation (OV) and BGPSEC protocols. (Note: BGPSEC validation is not applicable if update is not signed).

3. The update has the RLP field set to ’01’ indication for one or more hops (excluding the most recent) in the AS path.

In the above algorithm, the receiving AS interprets the ’01’ indication slightly strongly (i.e. stronger than in Section 3.2.1) to mean "the update SHOULD NOT have been propagated laterally to a peer ISP like me either". The rationale here is based on the fact that settlement-free ISP peers accept only customer prefix-routes from each other. The receiving AS applies the logic that if a preceding AS (excluding the most recent) set ’01’ indication, it means that the



update was sent to a peer or a customer by the (preceding) AS, and the update should not be traversing a lateral peer-to-peer link subsequently.

3.3. Possible Actions at a Receiving Router for Mitigation

After applying the above detection algorithm, a receiving router may use any policy-based algorithm of its own choosing to mitigate any detected route leaks. An example receiver algorithm for mitigating a route leak is as follows:

o If an update from a customer AS is marked as a Route-Leak, then the receiving router SHOULD prefer a Valid signed update from a peer or an upstream provider over the customer’s update.

A basic principle here is that the presence of ’01’ value in the RLP field corresponding to one or more AS hops in the AS path of an update coming from a customer AS informs a receiving router in a provider AS that a route leak is likely occurring. The provider AS then overrides the "prefer customer route" policy, and instead prefers a route learned from a peer or another upstream provider over the customer’s route.

4. Stopgap Solution when Only Origin Validation is Deployed

During a phase when BGPSEC path validation has not yet been deployed but only origin validation has been deployed, it would be good have a stopgap solution for route leaks. The stopgap solution can be in the form of construction of a prefix filter list from ROAs. A suggested procedure for constructing such a list comprises of the following steps:

o ISP makes a list of all the ASes (Cust_AS_List) that are in its customer cone (ISP’s own AS is also included in the list). (Some of the ASes in Cust_AS_List may be multi-homed to another ISP and that is OK.)

o ISP downloads from the RPKI repositories a complete list (Cust_ROA_List) of valid ROAs that contain any of the ASes in Cust_AS_List.

o ISP creates a list of all the prefixes (Cust_Prfx_List) that are contained in any of the ROAs in Cust_ROA_List.

o Cust_Prfx_List is the allowed list of prefixes that is permitted by the ISP’s AS, and will be forwarded by the ISP to upstream ISPs, customers, and peers.



o Any prefix not in Cust_Prfx_List but announced by any of the ISP’s customers is marked as a potential route leak. Then the ISP’s router SHOULD prefer a Valid (i.e. valid according to origin validation) and ’not marked’ update from a peer or an upstream provider over the customer’s marked update for that prefix.

Special considerations with regard to the above procedure may be needed for DDoS mitigation service providers. They typically originate or announce a DDoS victim’s prefix to their own ISP on a short notice during a DDoS emergency. Some provisions would need to be made for such cases, and they can be determined with the help of inputs from DDoS mitigation service providers.

For developing a list of all the ASes (Cust_AS_List) that are in the customer cone of an ISP, the AS path based Outbound Route Filter (ORF) technique [draft-ietf-idr-aspath-orf] can be helpful (see discussion in Section 5.2).

5. Design Rationale and Discussion

In this section, we will try to provide design justifications for the methodology specified in Section 3, and also answer some anticipated questions.

5.1. Is route-leak solution without BGPSEC a serious attack vector?

It has been asked if a route-leak solution without BGPSEC, i.e. when RLP bits are not protected, can turn into a serious new attack vector. That answer seems to be: not really! Even the NLRI and AS_PATH in BGP updates are attack vectors, and RPKI/OV/BGPSEC seek to fix that. Consider the following. Say, if 99% of route leaks are accidental and 1% are malicious, and if route-leak solution without BGPSEC eliminates the 99%, then perhaps it is worth it (step in the right direction). When BGPSEC comes into deployment, the route leak protection (RLP) bits can be mapped into BGPSEC (using the Flags field) and then necessary security will be in place as well (within each BGPSEC island as and when they emerge).

Further, let us consider the worst-case damage that can be caused by maliciously manipulating the RLP bits in an implementation without BGPSEC. An AS that wants to intentionally leak a route would alter the RLP encodings for the preceding hops from ’01’ (i.e. ’Do not Propagate Up’) to ’00’ (default) wherever applicable. It is true that in that case a receiving router would not be able to detect the leak for the specific prefix-route by the RLP mechanism described here. However, the receiving router may still detect and mitigate it in some cases by applying other means such as prefix filters [RFC7454] and AS path filters [draft-ietf-idr-aspath-orf]. If some



malicious leaks go undetected (for RLP without BGPSEC) that is possibly a small price to pay for the ability to detect the bulk of route leaks that are accidental.

5.2. Comparison with other methods, routing security BCP

It is reasonable to ask if techniques considered in BCPs such as[RFC7454] (BGP Operations and Security) and [NIST-800-54] may be adequate to address route leaks. The prefix filtering recommendations in the BCPs may be complementary but not adequate. The difficulty is in ISPs’ ability to construct prefix filters that represent their customer cones (CC) accurately, especially when there are many levels in the hierarchy within the CC. In the RLP-encoding based solution described here, AS operators signal for each prefix- route propagated, if it SHOULD NOT be subsequently propagated to a provider/peer.

AS path based Outbound Route Filter (ORF) described in [draft-ietf-idr-aspath-orf] is also an interesting complementary technique. It can be used as an automated collaborative messaging system (implemented in BGP) for ISPs to try to develop a complete view of the ASes and AS paths in their CCs. Once an ISP has that view, then AS path filters can be possibly used to detect route leaks. One limitation of this technique is that it cannot duly take into account the fact that prefixes with different business models are often sent over the same link between ASes. Also, the success of it depends on ASes at all levels of the hierarchy in a CC participate and provide accurate information (in the ORF messages) about the AS paths they expect to have in their BGP updates to their provider ISP(s).

6. Summary

It should be emphasized once again that the proposed route-leak detection method using the RLP encoding is not intended to cover all forms of route leaks. However, we feel that the solution covers several important types of route leaks, especially considering some significant route-leak attacks or occurrences that have been frequently observed in recent years. The solution can be implemented in BGP without necessarily tying it to BGPSEC. The proposed solution without BGPSEC can detect and mitigate accidental route leaks, and the same with BGPSEC can detect and mitigate malicious route leaks as well. Carrying the proposed RLP encoding in an optional transitive path attribute in BGP is proposed, but in order to prevent abuse, the RLP encoding would require cryptographic protection. Incorporating the RLP encoding in the BGPSEC Flags field is one way of implementing it securely using an already existing protection mechanism provided in BGPSEC path signatures.




The proposed Route Leak Protection (RLP) field requires cryptographic protection in order to prevent malicious route leaks. Since it is proposed that the RLP field be included in the Flags field in the Secure_Path Segment in BPGSEC updates, the cryptographic security mechanisms in BGPSEC are expected to also apply to the RLP field. The reader is therefore directed to the security considerations provided in [I-D.ietf-sidr-bgpsec-protocol].


No updates to the registries are suggested by this document.

9. Acknowledgements

The authors wish to thank Danny McPherson and Eric Osterweil for discussions related to this work. Also, thanks are due to Jared Mauch, Jeff Haas, Warren Kumari, Amogh Dhamdhere, Jakob Heitz, Geoff Huston, Randy Bush, Ruediger Volk, Andrei Robachevsky, Sue Hares, Keyur Patel, Wes George, Chris Morrow, and Sandy Murphy for comments, suggestions, and critique. The authors are also thankful to Padma Krishnaswamy, Oliver Borchert, and Okhee Kim for their comments and review.

10. References


[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.


[Cowie2010] Cowie, J., "China’s 18 Minute Mystery", Dyn Research/ Renesys Blog, November 2010, <http://research.dyn.com/2010/11/ chinas-18-minute-mystery/>.

[Cowie2013] Cowie, J., "The New Threat: Targeted Internet Traffic Misdirection", Dyn Research/Renesys Blog, November 2013, <http://research.dyn.com/2013/11/ mitm-internet-hijacking/>.



[draft-dickson-sidr-route-leak-solns] Dickson, B., "Route Leaks -- Proposed Solutions", IETF Internet Draft (expired), March 2012, <https://tools.ietf.org/html/draft-dickson-sidr-route- leak-solns-01>.

[draft-ietf-idr-aspath-orf] Patel, K. and S. Hares, "AS path Based Outbound Route Filter for BGP-4", IETF Internet Draft (expired), August 2007, <https://tools.ietf.org/html/draft-ietf-idr-aspath- orf-09>.

[draft-kunzinger-idrp-ISO10747-01] Kunzinger, C., "Inter-Domain Routing Protocol (IDRP)", IETF Internet Draft (expired), November 1994, <https://tools.ietf.org/pdf/draft-kunzinger-idrp- ISO10747-01.pdf>.

[Gao] Gao, L. and J. Rexford, "Stable Internet routing without global coordination", IEEE/ACM Transactions on Networking, December 2001, <http://www.cs.princeton.edu/˜jrex/papers/ sigmetrics00.long.pdf>.

[Gill] Gill, P., Schapira, M., and S. Goldberg, "A Survey of Interdomain Routing Policies", ACM SIGCOMM Computer Communication Review, January 2014, <https://www.cs.bu.edu/˜goldbe/papers/survey.pdf>.

[Giotsas] Giotsas, V. and S. Zhou, "Valley-free violation in Internet routing - Analysis based on BGP Community data", IEEE ICC 2012, June 2012, <http://www0.cs.ucl.ac.uk/staff/V.Giotsas/files/ giotsas.icc.2012.pdf>.

[Hiran] Hiran, R., Carlsson, N., and P. Gill, "Characterizing Large-scale Routing Anomalies: A Case Study of the China Telecom Incident", PAM 2013, March 2013, <http://www3.cs.stonybrook.edu/˜phillipa/papers/ CTelecom.html>.

[Huston2012] Huston, G., "Leaking Routes", March 2012, <http://labs.apnic.net/blabs/?p=139/>.

[Huston2014] Huston, G., "What’s so special about 512?", September 2014, <http://labs.apnic.net/blabs/?p=520/>.



[I-D.ietf-grow-route-leak-problem-definition] Sriram, K., Montgomery, D., McPherson, D., E. Osterweil, and B. Dickson "Problem Definition and Classification of BGP Route Leaks", draft-ietf-grow-route-leak-problem- definition-02 (work in progress), July 2015.

[I-D.ietf-sidr-bgpsec-protocol] Lepinski, M., "BGPsec Protocol Specification", draft-ietf- sidr-bgpsec-protocol-12 (work in progress), June 2015.

[Kapela-Pilosov] Pilosov, A. and T. Kapela, "Stealing the Internet: An Internet-Scale Man in the Middle Attack", DEFCON-16 Las Vegas, NV, USA, August 2008, <https://www.defcon.org/images/defcon-16/dc16- presentations/defcon-16-pilosov-kapela.pdf/>.

[Khare] Khare, V., Ju, Q., and B. Zhang, "Concurrent Prefix Hijacks: Occurrence and Impacts", IMC 2012, Boston, MA, November 2012, <http://www.cs.arizona.edu/˜bzhang/ paper/12-imc-hijack.pdf/>.

[Labovitz] Labovitz, C., "Additional Discussion of the April China BGP Hijack Incident", Arbor Networks IT Security Blog, November 2010, <http://www.arbornetworks.com/asert/2010/11/additional- discussion-of-the-april-china-bgp-hijack-incident/>.

[LRL] Khare, V., Ju, Q., and B. Zhang, "Large Route Leaks", Project web page, 2012, <http://nrl.cs.arizona.edu/projects/ lsrl-events-from-2003-to-2009/>.

[Luckie] Luckie, M., Huffaker, B., Dhamdhere, A., Giotsas, V., and kc. claffy, "AS Relationships, Customer Cones, and Validation", IMC 2013, October 2013, <http://www.caida.org/˜amogh/papers/asrank-IMC13.pdf>.

[Madory] Madory, D., "Why Far-Flung Parts of the Internet Broke Today", Dyn Research/Renesys Blog, September 2014, <http://research.dyn.com/2014/09/ why-the-internet-broke-today/>.

[Mauch] Mauch, J., "BGP Routing Leak Detection System", Project web page, 2014, <http://puck.nether.net/bgp/leakinfo.cgi/>.



[Mauch-nanog] Mauch, J., "Detecting Routing Leaks by Counting", NANOG-41 Albuquerque, NM, USA, October 2007, <https://www.nanog.org/meetings/nanog41/presentations/ mauch-lightning.pdf/>.

[NIST-800-54] Kuhn, D., Sriram, K., and D. Montgomery, "Border Gateway Protocol Security", NIST Special Publication 800-54, July 2007, <http://csrc.nist.gov/publications/nistpubs/800-54/ SP800-54.pdf>.

[Paseka] Paseka, T., "Why Google Went Offline Today and a Bit about How the Internet Works", CloudFare Blog, November 2012, <http://blog.cloudflare.com/ why-google-went-offline-today-and-a-bit-about/>.

[proceedings-sixth-ietf] Gross, P., "Proceedings of the April 22-24, 1987 Internet Engineering Task Force", April 1987, <https://www.ietf.org/proceedings/06.pdf>.

[RFC1105-obsolete] Lougheed, K. and Y. Rekhter, "A Border Gateway Protocol (BGP)", IETF RFC (obsolete), June 1989, <https://tools.ietf.org/html/rfc1105>.

[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013.

[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, February 2015.

[Toonk] Toonk, A., "What Caused Today’s Internet Hiccup", August 2014, <http://www.bgpmon.net/ what-caused-todays-internet-hiccup/>.

[Wijchers] Wijchers, B. and B. Overeinder, "Quantitative Analysis of BGP Route Leaks", RIPE-69, November 2014, <https://ripe69.ripe.net/presentations/157-RIPE-69- Routing-WG.pdf>.



[Zmijewski] Zmijewski, E., "Indonesia Hijacks the World", Dyn Research/Renesys Blog, April 2014, <http://research.dyn.com/2014/04/ indonesia-hijacks-world/>.


Kotikalapudi Sriram US NIST


Doug Montgomery US NIST


Brian Dickson Twitter, Inc.



Network Working Group R. AusteinInternet-Draft Dragon Research LabsIntended status: Standards Track R. BushExpires: December 1, 2015 IIJ Lab / Dragon Research Lab G. Huston G. Michaelson Asia Pacific Network Information Centre May 30, 2015

Resource Transfer in the Resource Public Key Infrastructure draft-ymbk-sidr-transfer-00

Abstract

Transfer within the RPKI of actual address space and/or autonomous system number resources between two Internet registries (ISPs, RIRs, NIRs, etc.) is reasonably achievable for most useful operational needs. In this paper, we describe, at a high level, how this may be accomplished.

Status of This Memo




This Internet-Draft will expire on December 1, 2015.

Copyright Notice


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

Austein, et al. Expires December 1, 2015 [Page 1]

Internet-Draft Resource Transfer in the RPKI May 2015

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 and Terms . . . . . . . . . . . . . . . . . . . 2 2. A Simplistic Case . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Steps in Simple Case . . . . . . . . . . . . . . . . . . 4 2.2. The Torn Euro Protocol . . . . . . . . . . . . . . . . . 4 3. A More Complex Case . . . . . . . . . . . . . . . . . . . . . 5 3.1. The Indirect Buyer . . . . . . . . . . . . . . . . . . . 6 3.2. The Difference Between Buyer and Seller Chain . . . . . . 7 4. Transfer in the Absense of a Common Ancestor . . . . . . . . 7 5. Transfer in process: Resources Change Forced from Above . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 9

1. Introduction and Terms

To paraphrase the Introduction of [RFC6480], the "Resource Public Key Infrastructure (RPKI) represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and is a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security."

An Internet Registry (IR) is the IANA, a Regional Internet Registry (RIR), a National Internet Registry (NIR), a Local Internet Registry (LIR), a Internet Service Provider (ISP), or an end site which may hold IP resources and is the subject of one or more certificates using [RFC3779] extensions in the Resource Public Key Infrastructure (RPKI), see [RFC6480].

It is desirable to transfer resources between resource-holding entities in the RPKI, and to do so without violating contracts, policies, etc., and while maintaining operational reliability and administrative accuracy with minimal administrative overhead.



+------------+ | Swing | | Point | | IR | +------------+ ^ ^ +-------+ +-------+ | | +------------+ +------------+ | Selling | | Buying | | IR | | IR | | | | | +------------+ +------------+ Fig 1. The Simplest Example of Seller, Buyer, and Swing Point

Seller and Buyer are used to describe the end parties to a transfer, the selling IR transferring the resource(s) to the buying IR. For the purposes of this document, the terms seller and buyer are used, although layer nine considerations may require less commercial formal roles.

Transfer is the sale and corresponding purchase of literal address space or autonomous system numbers between two parties. The seller relinquishing some amount of resource and the buyer being allocated a similar amount but not the same literal address space, is not a transfer, and is not further considered here.

A Swing Point is the IR at the lowest point in the RPKI hierarchy which the seller and buyer have as a common parent and which has agreed to be used as the agent of transfer.

While there is no automated method for the RPKI to assist the parties to a transaction in determining that all business and policy aspects of a transaction are satisfied, these layer eight and nine issues can be resolved using normal business practices.

2. A Simplistic Case



+------------+ | Swing | | Point | | IR | +------------+ 4 ^ ^ | ^ 4 +----------+ | | +----------+ | | | | v | | | +------------+ | | +------------+ | Selling | 2 | | 3 | Buying | | IR | | | | IR | | | | | | | +---------+--+ | | +--+---------+ | | | | 1 | | | | v | | v .---------. | | .---------. |Resources|-----+ +--->|Resources| ‘---------’ ‘---------’ Fig 2. Steps in a Simple Transfer

2.1. Steps in Simple Case

As a formal business relationship between all parties to a transfer provides a level of trust which allows simple transactions, we first consider the simple case where the seller and the buyer are both directly known to the swing point, see Figure 1.

The transfer is done in the following steps (see Figure 2):

1. The seller creates a certificate describing the subset of the seller’s resources which are to be transferred. 2. The seller tells the swing point that it wishes to transfer the resources described by the certificate to the buyer. 3. The swing point issues a new expanded certificate to the buyer describing the buyer’s old holdings plus the new resources. 4. When the seller and the buyer are comfortable that both the technical aspects (customers swung, routing done, etc.) and the business aspects of the transfer have been accomplished, they inform the swing point which then shrinks the seller’s resource certificate, removing the transferred resources.

2.2. The Torn Euro Protocol

Due to issues of cancellation, reneging, and fraud, step 4 above, where the seller and the buyer tell the swing point that the deal is done, needs to be formal in some fashion. For this purpose, we



envision a yet to be described torn Euro protocol, where the buyer and the seller each hold one half of a virtual torn Euro note, and the swing point believes the transaction to be complete when it has received both halves and they match.

This protocol has yet to be described, and Steve Kent has taken on the task of looking for an existing simple example that can be borrowed for the purpose.

3. A More Complex Case

What happens when the seller is not a direct customer of the swing point, see Figure 3.

+------------+ | Swing | | Point | | IR | +------------+ ^ ^ +-------+ +-------+ | | +------------+ +------------+ |Intermediate| | Buying | | IR | | IR | | | | | +----.-------+ +------------+ ^ +-------+ | +------------+ | Selling | | IR | | | +------------+ Figure 3. The Case of The Indirect Seller

The swing point needs to be assured that it is contractually able to move the resource given its relationship to the Other IR. As RFC 3779 extensions do not codify business issues such as PI/PA, and rights to resell, this has to be handled out of band, there is no way to automate it. But this is part of today’s IR address space management process and will continue to be handled manually.

Therefore the process is the same as for the simple case, except that, before issuing the expanded certificate to the buyer in step 3, the swing point must assure itself that policy and contractual issues are cleared. It might be well-advised to contact the intermediate IR



and gain its consent, possibly with the assistance of the seller. The bottom line is that the swing point does own/control the resource being transferred, and therefore has the prerogative to act within its perception of the liabilities it is incurring.

This freedom allowing the seller to be indirectly related to the swing point may be induced to more levels of indirection. It is the swing point’s obligation to perform diligence on the iterative financial, contractual, and policy obligations of the relationships down to the seller. Unfortunately, the RPKI can not automate this.

3.1. The Indirect Buyer

The case where the buyer is not directly known to the swing point is more difficult. Among other issues, the buyer may not be an existing resource holder at all, i.e. there may be no path down from the IANA root to the buyer. In this case, the buyer must explore the graph and choose an IR with which to contract a relationship. This can be both a business issue and a policy issue, e.g. can a buyer in Asia choose a parent which is, directly or indirectly, an ARIN customer?

The case where the buyer contracts directly to become a customer of the swing point has been explored above. What if the buyer becomes a grandchild of the swing point, as in figure 4?

+------------+ | Swing | | Point | | IR | +------------+ ^ ^ +-------+ +-------+ | | +------------+ +------------+ | Selling | |Intermediate| | IR | | IR | | | | | +------------+ +------------+ ^ +-------+ | +------------+ | Buying | | IR | | | +------------+ Figure 3. The Case of The Indirect Buyer



Somewhat analogously to the case of the indirect seller, the swing point has to iteratively verify that the IRs between it and the buyer are all willing to contractually and technically accept the resource(s) to be allocated to the buyer. But, in the case of the indirect buyer, the iterative conditions are much stronger. In the indirect seller case, the swing point has contractual control of the chain between it and the seller. In the case of the indirect buyer, all intermediate IRs between the swing point and the buyer must give business and technical consent. The swing point can not force its child to issue a resource certificate to the buyer.

Things may not be as bad as they appear at first blush. The buyer is actually contracting to its parent, and part of that contract will presumably be that the parent agrees to issue the resource certificate to the buyer when it receives the resource from it’s parent. And this presumably applies to the buyer’s parent’s relationship to a grandparent and so forth. On the other hand, the swing point has no mechanical way to test the willingness of the IRs on the buyer’s indirect chain. But the swing point can know when the buyer is happy that it has received the resources, as the buyer will give it the buyer’s half of the torn Euro.

3.2. The Difference Between Buyer and Seller Chain

Essentially, the difference between an indirect buyer chain and an indirect seller chain is that the swing point has the logical, though maybe not contractual, prerogative to pull address space from the seller’s chain, but does not have the power to push it down the buyer’s chain. All IRs on the buyer’s chain must agree to certify downward toward the buyer.

4. Transfer in the Absense of a Common Ancestor

For political reasons, the current RPKI structure has no single root trust anchor. There are a number of roots, e.g. the five RIRs who do not descend from the IANA. This creates considerable complexity and some risk for resource transfers between entities without a common ancestor.

To work around this problem, each RIR certifies a subsidiary Certificate Authority for each other RIR to which it transfers resources, see Figure 4, and issues the transferred resources to that subsidiary CA.



+------+ | RIPE | +------+ | | +-----------+-------+-------+-----------+ | | | | | | | | | | v v | v v +-------+ +-------+ | +-------+ +-------+ | APNIC | |AfriNIC| | | ARIN | |LACNIC | +-------+ +-------+ | +-------+ +-------+ v +-----------+ | Members | +-----------+

Figure 4: The RIRs each certify proxy CAs for all of the other RIRs.

But, to use the example of Figure 4, the APNIC CA to which RIPE issues resources is, in fact, run by APNIC under APNIC’s Business Certificate PKI (see [RFC6492] Section 3) and uses an APNIC-provided publication point.

Thus APNIC has under its control, among other things, four CAs, one with resources from each of the other CAs. And similarly for each of the other RIRs.

So the swing point for a transfer from an APNIC member to a RIPE member is the APNIC CA. And an APNIC member holding resources originated by APNIC as well as resources transferred in from another RIR, e.g. RIPE, actually holds two resource certificates.

This could probably be made more complicated and brittle, but it would require serious effort.

5. Transfer in process: Resources Change Forced from Above

Even though both seller and buyer have agreed to a transfer, the seller might try to not relinquish the resource, hoping to sell it more than once. Therefore it may become necessary to force closure for a non-compliant seller. In this case, a resource holding would be changed, shrunk, by force from above.

A ’normal’ (i.e. what the RPKI design anticipated) resource shrinkage is initiated by the leaf resource holder and propagates upward toward



the root of the tree. At no point in this process does a holder claim more than their parent believes they have.

When a resource is forcibly removed from ’above’, the shrinkage propagates downward. Until the ultimate holder relinquishes the resource, at some point in the path down the tree a child holds more resources than its parent believes it does. As the protocol model is bottom initiated polling, see [RFC6492], the time window of exposure of this over-claiming can be relatively large.


Ghu only knows.

7. Acknowledgements

Thanks Mom!


Nothing is required of the IANA; though it would make some things a lot simpler if the IANA was the root TA/CA of the entire tree.

9. References


[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, February 2012.


[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.


Rob Austein Dragon Research Lab 40 Gavin Circle Reading, MA 01867 USA




Randy Bush IIJ / Dragon Research Labs 5147 Crystal Springs Bainbridge Island, Washington 98110 US


Geoff Huston Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 AU


George Michaelson Asia Pacific Network Information Centre 6 Cordelia St South Brisbane, QLD 4101 AU

