randy/draft-6486bis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

some egregious typos

Browse source
This commit is contained in:
Randy Bush 2020-07-06 10:58:40 -07:00
parent 69899755f3
commit 968033f009
1 changed files with 174 additions and 174 deletions
Download patch file Download diff file Expand all files Collapse all files

344
draft-ymbk-sidrops-6486bis.txt
View file

@ -6,11 +6,11 @@ Network Working Group R. Austein
Internet-Draft Arrcus, Inc. Internet-Draft Arrcus, Inc.
Updates: 6486 (if approved) G. Huston Updates: 6486 (if approved) G. Huston
Intended status: Standards Track APNIC Intended status: Standards Track APNIC
Expires: December 26, 2020 S. Kent Expires: January 7, 2021 S. Kent
Independent Independent
M. Lepinski M. Lepinski
New College Florida New College Florida
June 24, 2020 July 6, 2020
Manifests for the Resource Public Key Infrastructure (RPKI) Manifests for the Resource Public Key Infrastructure (RPKI)
@ -48,14 +48,14 @@ Status of This Memo
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 26, 2020. This Internet-Draft will expire on January 7, 2021.
Austein, et al. Expires December 26, 2020 [Page 1] Austein, et al. Expires January 7, 2021 [Page 1]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
Copyright Notice Copyright Notice
@ -88,18 +88,18 @@ Table of Contents
5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 8 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 8
5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8 5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8
5.2. Considerations for Manifest Generation . . . . . . . . . 9 5.2. Considerations for Manifest Generation . . . . . . . . . 9
6. Relying Party Use of Manifests . . . . . . . . . . . . . . . 9 6. Relying Party Processing of Manifests . . . . . . . . . . . . 9
6.1. Manifest Processing Overview . . . . . . . . . . . . . . 10 6.1. Manifest Processing Overview . . . . . . . . . . . . . . 11
6.2. Acquiring a Manifest for a CA . . . . . . . . . . . . . . 11 6.2. Acquiring a Manifest for a CA . . . . . . . . . . . . . . 11
6.3. Detecting Stale and or Prematurely-issued Manifests . . . 11 6.3. Detecting Stale and or Prematurely-issued Manifests . . . 11
6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 11 6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 12
6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12 6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12
6.6. Out of Scope Manifest Entries . . . . . . . . . . . . . . 12 6.6. Out of Scope Manifest Entries . . . . . . . . . . . . . . 12
6.7. Termination of Processing . . . . . . . . . . . . . . . . 12 6.7. Failed Fetches . . . . . . . . . . . . . . . . . . . . . 12
7. Publication Repositories . . . . . . . . . . . . . . . . . . 12 7. Publication Repositories . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 15
@ -109,9 +109,9 @@ Table of Contents
Austein, et al. Expires December 26, 2020 [Page 2] Austein, et al. Expires January 7, 2021 [Page 2]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
1. Introduction 1. Introduction
@ -165,9 +165,9 @@ Internet-Draft RPKI Manifests June 2020
Austein, et al. Expires December 26, 2020 [Page 3] Austein, et al. Expires January 7, 2021 [Page 3]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
2. Manifest Scope 2. Manifest Scope
@ -221,9 +221,9 @@ Internet-Draft RPKI Manifests June 2020
Austein, et al. Expires December 26, 2020 [Page 4] Austein, et al. Expires January 7, 2021 [Page 4]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
4. Manifest Definition 4. Manifest Definition
@ -277,9 +277,9 @@ Internet-Draft RPKI Manifests June 2020
Austein, et al. Expires December 26, 2020 [Page 5] Austein, et al. Expires January 7, 2021 [Page 5]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
specified in nextUpdate or until a manifest is issued with a greater specified in nextUpdate or until a manifest is issued with a greater
@ -333,9 +333,9 @@ Internet-Draft RPKI Manifests June 2020
Austein, et al. Expires December 26, 2020 [Page 6] Austein, et al. Expires January 7, 2021 [Page 6]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
encompasses a CRL, the nextUpdate field of the manifest MUST match encompasses a CRL, the nextUpdate field of the manifest MUST match
@ -389,9 +389,9 @@ Internet-Draft RPKI Manifests June 2020
Austein, et al. Expires December 26, 2020 [Page 7] Austein, et al. Expires January 7, 2021 [Page 7]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
5. Manifest Generation 5. Manifest Generation
@ -445,9 +445,9 @@ Internet-Draft RPKI Manifests June 2020
Austein, et al. Expires December 26, 2020 [Page 8] Austein, et al. Expires January 7, 2021 [Page 8]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
Note that the manifest does not include a self reference (i.e., Note that the manifest does not include a self reference (i.e.,
@ -493,27 +493,43 @@ Internet-Draft RPKI Manifests June 2020
manifest associated with each active CA instance that is publishing manifest associated with each active CA instance that is publishing
into the common repository publication point (directory). into the common repository publication point (directory).
6. Relying Party Use of Manifests 6. Relying Party Processing of Manifests
Each RP MUST determine which signed objects it will use for Each RP must determine which signed objects it will use for
validating assertions about INRs and their use (e.g., which ROAs to validating assertions about INRs and their use (e.g., which ROAs to
use in the construction of route filters). Manifests are designed to use in the construction of route filters). As noted earlier,
Austein, et al. Expires December 26, 2020 [Page 9] Austein, et al. Expires January 7, 2021 [Page 9]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
allow an RP to detect manipulation of repository data and/or errors manifests are designed to allow an RP to detect manipulation of
by a CA or repository manager. Unless _all_ of the files enumerated repository data, errors by a CA or repository manager, and/or active
in a manifest can be obtained by an RP (either from a publication attacks on the communication channel between an RP and a repository.
point or from a local cache), an RP MUST ignore the data associated Unless all of the files enumerated in a manifest can be obtained by
with the publication point. This stringent response is needed to an RP during a fetch operation, the fetch is considered to have
prevent an RP from misinterpreting data associated with a publication failed and the RP MUST retry the fetch later.
point, and thus possibly treating invalid routes as valid, or vice
versa. [RFC6480] suggests (but does not mandate) that the RPKI model employ
fetches that are incremental, e.g., an RP transfers files from a
publication point only if they are new/changed since the previous,
successful, fetch represented in the RP's local cache. This document
avoids language that relies on details of the underlying file
transfer mechanism employed by an RP and a publication point to
effect this operation. Thus the term "fetch" refers to an operation
that attempts to acquire the full set of files at a publication
point, consistent with the id-ad-rpkiManifest URI extracted from a CA
certificate's SIA (see below).
If a fetch fails, it is assumed that a subsequent fetch will resolve
problems encountered during the fetch. Until such time as a
successful fetch is executed, an RP SHOULD use cached data from a
previous, successful fetch. This response is intended to prevent an
RP from misinterpreting data associated with a publication point, and
thus possibly treating invalid routes as valid, or vice versa.
The processing described below is designed to cause all RPs with The processing described below is designed to cause all RPs with
access to the same local cache and RPKI repository data to achieve access to the same local cache and RPKI repository data to achieve
@ -521,159 +537,148 @@ Internet-Draft RPKI Manifests June 2020
operation, different RPs will access repositories at different times, operation, different RPs will access repositories at different times,
and some RPs may experience local cache failures, so there is no and some RPs may experience local cache failures, so there is no
guarantee that all RPs will achieve the same results with regard to guarantee that all RPs will achieve the same results with regard to
validation of RPKI data validation of RPKI data.
Note that there is a "chicken and egg" relationship between the Note that there is a "chicken and egg" relationship between the
manifest and the CRL for a given CA instance. If the EE certificate manifest and the CRL for a given CA instance. If the EE certificate
for the current manifest is revoked, i.e., it appears in the current for the current manifest is revoked, i.e., it appears in the current
CRL, then the CA or publication point manager has made a serious CRL, then the CA or publication point manager has made a serious
error. In this case all signed objects associated with the CA error. In this case the fetch has failed; proceed to Section 6.7.
instance MUST be ignored. Similarly, if the CRL is not listed on a Similarly, if the CRL is not listed on a valid, current manifest,
valid, current manifest, all signed objects associated with the CA acquired during a fetch, the fetch has failed; proceed to
instance MUST be ignored, because the CRL is considered missing. Section 6.7, because the CRL is considered missing.
Note that if a CA and its associated publication point are operating
properly, there will always be exactly one manifest and one
associated CRL at the publication point identified in the CA's SIA
(see below).
Austein, et al. Expires January 7, 2021 [Page 10]
Internet-Draft RPKI Manifests July 2020
6.1. Manifest Processing Overview 6.1. Manifest Processing Overview
For a given publication point, an RP MUST perform a series of tests For a given publication point, an RP MUST perform a series of tests
to determine which signed object files at the publication point are to determine which signed object files at the publication point are
acceptable. The tests described below are to be performed using acceptable. The tests described below (Section 6.2 to Section 6.6)
themanifest identified by the id-ad-rpkiManifest URI extracted from a are to be performed using the manifest identified by the id-ad-
CA certificate's SIA. _All_ of the files referenced by the manifest rpkiManifest URI extracted from a CA certificate's SIA. All of the
MUST be be located at the publication point specified by the id-ad- files referenced by the manifest MUST be be located at the
caRepositoryURI from the (same) certificate's SIA. The manifest and publication point specified by the id-ad-caRepository URI from the
the files it references MUST reside at the same publication point. (same) CA certificate's SIA. The manifest and the files it
An RP MUST ignore any files that appear on a manifest but do not references MUST reside at the same publication point. If an RP
reside as the same publication point as the manifest. encounters any files that appear on a manifest but do not reside at
the same publication point as the manifest the RP MUST treat the
fetch as failed, and a warning MUST be issued (see Section 6.7
below).
1. All of the files referenced by the manifest MUST be be located at A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be
the publication point specified by the id-ad-caRepository URI at the location specified in the CRLDP in the manifest's EE
from the (same) certificate's SIA. If the manifest and the files certificate. If more than one .crl file appears in the manifest, the
it references do not reside at the same publication point, an RP fetch has failed and the RP MUST proceed to Section 6.7; otherwise
MUST *???* proceed to Section 6.2.
2. A manifest SHOULD contain exactly one CRL (.crl) file and it MUST Note that, during CA key rollover [RFC6489], signed objects for two
be at the location specified in the CRLDP in the manifest's EE or more different CA instances will appear at the same publication
certificate. point. Manifest processing is to be performed separately for each CA
Austein, et al. Expires December 26, 2020 [Page 10]
Internet-Draft RPKI Manifests June 2020
3. If more than one .crl file appears in the manifest, only file
names matching the CRL specified by the CRLDP will be processed.
If more than one .crl entry appears in the manifest, and matches
the CRLDP, the first one encountered MUST be used. Any other
.crl files MUST be ignored and a warning MUST be issued.
4. Note that, during CA key rollover [RFC6489], signed objects for
two or more different CA instances will appear at the same
publication point.
5. Manifest processing is to be performed separately for each CA
instance, guided by the SIA id-ad-rpkiManifest URI in each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA
certificate. certificate.
6. Note also that the processing described here will be performed
using locally cached files if an RP does not detect newer
versions of the files in the RPKI repository system.
6.2. Acquiring a Manifest for a CA 6.2. Acquiring a Manifest for a CA
Acquire the manifest identified by the SIA id-ad-rpkiManifest URI in The RP MUST fetch the manifest identified by the SIA id-ad-
the CA certificate. If an RP cannot retrieve a manifest using this rpkiManifest URI in the CA certificate. If an RP cannot retrieve a
URI, or if the manifest is not valid (Section 4.4), an RP SHOULD manifest using this URI, or if the manifest is not valid
examine the most recent, cached manifest matching this URI. If that (Section 4.4), an RP MUST treat this as a failed fetch and, proceed
manifest is current (Section 4.4) proceed to Section 6.3. If the to Section 6.7; otherwise proceed to Section 6.3.
publication point does not contain a valid manifest, and the cached
manifest is not current, proceed to Section 6.7.
6.3. Detecting Stale and or Prematurely-issued Manifests 6.3. Detecting Stale and or Prematurely-issued Manifests
Check that the current time (translated to UTC) is between thisUpdate The RP MUST check that the current time (translated to UTC) is
and nextUpdate. If the current time lies within this interval, between thisUpdate and nextUpdate. If the current time lies within
proceed to Section 6.4. If the current time is earlier than this interval, proceed to Section 6.4. If the current time is
thisUpdate, the CA has made an error. If the RP cache contains a earlier than thisUpdate, the CA has made an error; this a failed
current manifest, use that manifest instead and issue a warning. If fetch and the RP MUST proceed to Section 6.7. If the current time is
an RP has no access to a current manifest, processing stops and a later than nextUpdate, then the manifest is stale; this is a failed
warning MUST be issued. If the current time is later than fetch and RP MUST proceed to Section 6.7; otherwise proceed to
nextUpdate, then the manifest is stale. If the RP cache contains a Section 6.4.
current manifest, use that manifest instead and issue a warning.If no
current manifest is available, proceed to Section 6.7.
Austein, et al. Expires January 7, 2021 [Page 11]
Internet-Draft RPKI Manifests July 2020
6.4. Acquiring Files Referenced by a Manifest 6.4. Acquiring Files Referenced by a Manifest
Acquire all files enumerated in the manifest (fileList) from the The RP MUST acquire all of the files enumerated in the manifest
publication point. This includes the CRL, each object containing an (fileList) from the publication point. This includes the CRL, each
EE certificate issued by the C, and all subordinate CA and EE object containing an EE certificate issued by the CA, and any
certificates. If there are files listed in the manifest that cannot subordinate CA and EE certificates. If there are files listed in the
be retrieved from the publication point, or if they fail the validity manifest that cannot be retrieved from the publication point, or if
they fail the validity tests specified in [RFC6488], the fetch has
failed and the RP MUST proceed to Section 6.7; otherwise, proceed to
Section 6.5.
Austein, et al. Expires December 26, 2020 [Page 11]
Internet-Draft RPKI Manifests June 2020
tests specified in [RFC6488], the RP SHOULD examine its cache to
determine if these files are available locally. If all of the
missing/invalid files are available from the RP's cache, i.e., each
file name matches the list extracted from the manifest, the RP SHOULD
use the cached files to replace those missing from the publication
point, and proceed to Section 6.5. However, if _any_ of the missing/
invalid files cannot be replaced in this fashion, then proceed to
Section 6.7.
6.5. Matching File Names and Hashes 6.5. Matching File Names and Hashes
Verify that the hash value of every file listed in the manifest The RP MUST verify that the hash value of each file listed in the
matches the value obtained by hashing the file acquired from the manifest matches the value obtained by hashing the file acquired from
publication point or local cache. If the computed hash value of a the publication point. If the computed hash value of a file listed
file listed on the manifest does not match the hash value contained on the manifest does not match the hash value contained in the
in the manifest, then an RP SHOULD examine its local cache to manifest, then the fetch has failed and the RP MUST proceed to
determine if the same file is available. The RP SHOULD use cached Section 6.7; otherwise proceed to Section 6.6.
files to replace any (damaged) downloaded files, so long as the hash
of the cached file matches the hash from the manifest. If any of the
files with hash mismatches cannot be replaced in this fashion,
proceed to 6.7. Otherwise proceed to Section 6.6.
6.6. Out of Scope Manifest Entries 6.6. Out of Scope Manifest Entries
If a current manifest contains entries for objects that are not If a current manifest contains entries for objects that are not
within the scope of the manifest (Section 2), then the out-of-scope within the scope of the manifest (Section 6.2), the fetch has failed
entries MUST be disregarded. and the RP proceed to Section 6.7; otherwise the fetch is deemed
successful and the RP will process the fetched objects.
6.7. Termination of Processing 6.7. Failed Fetches
If an RP cannot acquire a current, valid manifest, or acquire If an RP does not acquire a current valid manifest, or does not
current, valid instances of all of the objects enumerated in a acquire current valid instances of all of the objects enumerated in a
current valid manifest, then processing of the signed objects current valid manifest as a result of a fetch, then processing of the
associated with the CA has failed. The RP MUST issue a warning signed objects associated with the CA instance has failed for this
indicating the reason(s) for termination of processing with regard to fetch cycle. The RP MUST issue a warning indicating the reason(s)
this CA. for termination of processing with regard to this CA instance. It is
RECOMMENDED that a human operator be notified of this warning.
Termination or processing means that the RP SHOULD continue to use
cached versions of the objects associated with this CA instance,
until such time as they become stale or they can be replaced by
objects from a successful fetch. This implies that the RP MUST not
try to acquire and validate subordinate signed objects, e.g.,
subordinate CA certificates, until the next interval when the RP is
scheduled to fetch and process data for this CA instance.
Austein, et al. Expires January 7, 2021 [Page 12]
Internet-Draft RPKI Manifests July 2020
Termination or processing means that all of the ROAs and subordinate
certificates (CA and EE) MUST be considered invalid. This implies
that the RP MUST not try to acquire and validate _subordinate_ signed
objects, until the next interval when the RP is scheduled to process
data for this part of the RPKI repository system.
7. Publication Repositories 7. Publication Repositories
The RPKI publication system model requires that every publication The RPKI publication system model requires that every publication
point be associated with one or more CAs, and be non-empty. Upon point be associated with one or more CAs, and be non-empty. Upon
creation of the publication point associated with a CA, the CA MUST creation of the publication point associated with a CA, the CA MUST
Austein, et al. Expires December 26, 2020 [Page 12]
Internet-Draft RPKI Manifests June 2020
create and publish a manifest as well as a CRL. A CA's manifest will create and publish a manifest as well as a CRL. A CA's manifest will
always contain at least one entry, namely, the CRL issued by the CA always contain at least one entry, namely, the CRL issued by the CA
upon repository creation [RFC6481]. upon repository creation [RFC6481].
@ -717,19 +722,19 @@ Internet-Draft RPKI Manifests June 2020
Object" and three-letter filename extensions for "RPKI Repository Object" and three-letter filename extensions for "RPKI Repository
Name Schemes," no new action is requested of the IANA. Name Schemes," no new action is requested of the IANA.
Austein, et al. Expires January 7, 2021 [Page 13]
Internet-Draft RPKI Manifests July 2020
10. Acknowledgements 10. Acknowledgements
The authors would like to acknowledge the contributions from George The authors would like to acknowledge the contributions from George
Michelson and Randy Bush in the preparation of the manifest Michelson and Randy Bush in the preparation of the manifest
specification. Additionally, the authors would like to thank Mark specification. Additionally, the authors would like to thank Mark
Austein, et al. Expires December 26, 2020 [Page 13]
Internet-Draft RPKI Manifests June 2020
Reynolds and Christopher Small for assistance in clarifying manifest Reynolds and Christopher Small for assistance in clarifying manifest
validation and RP behavior. The authors also wish to thank Job validation and RP behavior. The authors also wish to thank Job
Snijders, Oleg Muravskiy, and Sean Turner for their helpful review of Snijders, Oleg Muravskiy, and Sean Turner for their helpful review of
@ -776,14 +781,9 @@ Internet-Draft RPKI Manifests June 2020
Austein, et al. Expires January 7, 2021 [Page 14]
Austein, et al. Expires December 26, 2020 [Page 14]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
[X.690] International International Telephone and Telegraph [X.690] International International Telephone and Telegraph
@ -837,9 +837,9 @@ Appendix A. ASN.1 Module
Austein, et al. Expires December 26, 2020 [Page 15] Austein, et al. Expires January 7, 2021 [Page 15]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549) RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
@ -893,9 +893,9 @@ Authors' Addresses
Austein, et al. Expires December 26, 2020 [Page 16] Austein, et al. Expires January 7, 2021 [Page 16]
Internet-Draft RPKI Manifests June 2020 Internet-Draft RPKI Manifests July 2020
Geoff Huston Geoff Huston
@ -949,4 +949,4 @@ Internet-Draft RPKI Manifests June 2020
Austein, et al. Expires December 26, 2020 [Page 17] Austein, et al. Expires January 7, 2021 [Page 17]