doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc7115.txt b/doc/rfc/rfc7115.txt
new file mode 100644
index 0000000..b8148e0
--- /dev/null
+++ b/doc/rfc/rfc7115.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           R. Bush
+Request for Comments: 7115                     Internet Initiative Japan
+BCP: 185                                                    January 2014
+Category: Best Current Practice
+ISSN: 2070-1721
+
+
+                      Origin Validation Operation
+         Based on the Resource Public Key Infrastructure (RPKI)
+
+Abstract
+
+   Deployment of BGP origin validation that is based on the Resource
+   Public Key Infrastructure (RPKI) has many operational considerations.
+   This document attempts to collect and present those that are most
+   critical.  It is expected to evolve as RPKI-based origin validation
+   continues to be deployed and the dynamics are better understood.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It has been approved for publication by the Internet
+   Engineering Steering Group (IESG).  Further information on BCPs is
+   available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7115.
+
+Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+Bush                      Best Current Practice                 [Page 1]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
+     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
+   2.  Suggested Reading . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  RPKI Distribution and Maintenance . . . . . . . . . . . . . .   3
+   4.  Within a Network  . . . . . . . . . . . . . . . . . . . . . .   6
+   5.  Routing Policy  . . . . . . . . . . . . . . . . . . . . . . .   6
+   6.  Notes and Recommendations . . . . . . . . . . . . . . . . . .   8
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
+   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  10
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
+     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
+
+1.  Introduction
+
+   RPKI-based origin validation relies on widespread deployment of the
+   Resource Public Key Infrastructure (RPKI) [RFC6480].  How the RPKI is
+   distributed and maintained globally is a serious concern from many
+   aspects.
+
+   While the global RPKI is in the early stages of deployment, there is
+   no single root trust anchor, initial testing is being done by the
+   Regional Internet Registries (RIRs), and there are technical
+   testbeds.  It is thought that origin validation based on the RPKI
+   will continue to be deployed incrementally over the next few years.
+   It is assumed that eventually there must be a single root trust
+   anchor for the public address space, see [IAB].
+
+   Origin validation needs to be done only by an AS's border routers and
+   is designed so that it can be used to protect announcements that are
+   originated by any network participating in Internet BGP routing:
+   large providers, upstream and downstream routers, and by edge
+   networks (e.g., small stub or enterprise networks).
+
+   Origin validation has been designed to be deployed on current routers
+   without significant hardware upgrades.  It should be used in border
+   routers by operators from large backbones to small stub/enterprise/
+   edge networks.
+
+   RPKI-based origin validation has been designed so that, with prudent
+   local routing policies, there is little risk that what is seen as
+   today's normal Internet routing is threatened by imprudent deployment
+   of the global RPKI; see Section 5.
+
+
+
+
+
+
+Bush                      Best Current Practice                 [Page 2]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
+   be interpreted as described in RFC 2119 [RFC2119] only when they
+   appear in all upper case.  They may also appear in lower or mixed
+   case as English words, without normative meaning.
+
+2.  Suggested Reading
+
+   It is assumed that the reader understands BGP [RFC4271], the RPKI
+   [RFC6480], the RPKI Repository Structure [RFC6481], Route Origin
+   Authorizations (ROAs) [RFC6482], the RPKI to Router Protocol
+   [RFC6810], RPKI-based Prefix Validation [RFC6811], and Ghostbusters
+   Records [RFC6493].
+
+3.  RPKI Distribution and Maintenance
+
+   The RPKI is a distributed database containing certificates,
+   Certificate Revocation Lists (CRLs), manifests, ROAs, and
+   Ghostbusters Records as described in [RFC6481].  Policies and
+   considerations for RPKI object generation and maintenance are
+   discussed elsewhere.
+
+   The RPKI repository design [RFC6481] anticipated a hierarchic
+   organization of repositories, as this seriously improves the
+   performance of relying parties that gather data over a non-hierarchic
+   organization.  Publishing parties MUST implement hierarchic directory
+   structures.
+
+   A local relying party's valid cache containing all RPKI data may be
+   gathered from the global distributed database using the rsync
+   protocol [RFC5781] and a validation tool such as rcynic [rcynic].
+
+   A validated cache contains all RPKI objects that the RP has verified
+   to be valid according to the rules for validation RPKI certificates
+   and signed objects; see [RFC6487] and [RFC6488].  Entities that trust
+   the cache can use these RPKI objects without further validation.
+
+   Validated caches may also be created and maintained from other
+   validated caches.  Network operators SHOULD take maximum advantage of
+   this feature to minimize load on the global distributed RPKI
+   database.  Of course, the recipient relying parties should
+   re-validate the data.
+
+   As Trust Anchor Locators (TALs) [RFC6490] are critical to the RPKI
+   trust model, operators should be very careful in their initial
+   selection and vigilant in their maintenance.
+
+
+
+Bush                      Best Current Practice                 [Page 3]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+   Timing of inter-cache synchronization, and synchronization between
+   caches and the global RPKI, is outside the scope of this document,
+   and depends on things such as how often routers feed from the caches,
+   how often the operator feels the global RPKI changes significantly,
+   etc.
+
+   As inter-cache synchronization within an operator's network does not
+   impact global RPKI resources, an operator may choose to synchronize
+   quite frequently.
+
+   To relieve routers of the load of performing certificate validation,
+   cryptographic operations, etc., the RPKI-Router protocol [RFC6810]
+   does not provide object-based security to the router.  That is, the
+   router cannot validate the data cryptographically from a well-known
+   trust anchor.  The router trusts the cache to provide correct data
+   and relies on transport-based security for the data received from the
+   cache.  Therefore, the authenticity and integrity of the data from
+   the cache should be well protected; see Section 7 of [RFC6810].
+
+   As RPKI-based origin validation relies on the availability of RPKI
+   data, operators SHOULD locate RPKI caches close to routers that
+   require these data and services in order to minimize the impact of
+   likely failures in local routing, intermediate devices, long
+   circuits, etc.  One should also consider trust boundaries, routing
+   bootstrap reachability, etc.
+
+   For example, a router should bootstrap from a cache that is reachable
+   with minimal reliance on other infrastructure such as DNS or routing
+   protocols.  If a router needs its BGP and/or IGP to converge for the
+   router to reach a cache, once a cache is reachable, the router will
+   then have to reevaluate prefixes already learned via BGP.  Such
+   configurations should be avoided if reasonably possible.
+
+   If insecure transports are used between an operator's cache and their
+   router(s), the Transport Security recommendations in [RFC6810] SHOULD
+   be followed.  In particular, operators MUST NOT use insecure
+   transports between their routers and RPKI caches located in other
+   Autonomous Systems.
+
+   For redundancy, a router should peer with more than one cache at the
+   same time.  Peering with two or more, at least one local and others
+   remote, is recommended.
+
+   If an operator trusts upstreams to carry their traffic, they may also
+   trust the RPKI data those upstreams cache and SHOULD peer with caches
+   made available to them by those upstreams.  Note that this places an
+
+
+
+
+
+Bush                      Best Current Practice                 [Page 4]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+   obligation on those upstreams to maintain fresh and reliable caches
+   and to make them available to their customers.  And, as usual, the
+   recipient SHOULD re-validate the data.
+
+   A transit provider or a network with peers SHOULD validate origins in
+   announcements made by upstreams, downstreams, and peers.  They still
+   should trust the caches provided by their upstreams.
+
+   Before issuing a ROA for a super-block, an operator MUST ensure that
+   all sub-allocations from that block that are announced by other ASes,
+   e.g., customers, have correct ROAs in the RPKI.  Otherwise, issuing a
+   ROA for the super-block will cause the announcements of sub-
+   allocations with no ROAs to be viewed as Invalid; see [RFC6811].
+   While waiting for all recipients of sub-allocations to register ROAs,
+   the owner of the super-block may use live BGP data to populate ROAs
+   as a proxy, and then safely issue a ROA for the super-block.
+
+   Use of RPKI-based origin validation removes any need to inject more
+   specifics into BGP to protect against mis-origination of a less
+   specific prefix.  Having a ROA for the covering prefix will protect
+   it.
+
+   To aid translation of ROAs into efficient search algorithms in
+   routers, ROAs should be as precise as possible, i.e., match prefixes
+   as announced in BGP.  For example, software and operators SHOULD
+   avoid use of excessive max length values in ROAs unless they are
+   operationally necessary.
+
+   One advantage of minimal ROA length is that the forged origin attack
+   does not work for sub-prefixes that are not covered by overly long
+   max length.  For example, if, instead of 10.0.0.0/16-24, one issues
+   10.0.0.0/16 and 10.0.42.0/24, a forged origin attack cannot succeed
+   against 10.0.666.0/24.  They must attack the whole /16, which is more
+   likely to be noticed because of its size.
+
+   Therefore, ROA generation software MUST use the prefix length as the
+   max length if the user does not specify a max length.
+
+   Operators should be conservative in use of max length in ROAs.  For
+   example, if a prefix will have only a few sub-prefixes announced,
+   multiple ROAs for the specific announcements should be used as
+   opposed to one ROA with a long max length.
+
+   Operators owning prefix P should issue ROAs for all ASes that may
+   announce P.  If a prefix is legitimately announced by more than one
+   AS, ROAs for all of the ASes SHOULD be issued so that all are
+   considered Valid.
+
+
+
+
+Bush                      Best Current Practice                 [Page 5]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+   In an environment where private address space is announced in
+   External BGP (eBGP), the operator may have private RPKI objects that
+   cover these private spaces.  This will require a trust anchor created
+   and owned by that environment; see [LTA-USE].
+
+   Operators issuing ROAs may have customers that announce their own
+   prefixes and ASes into global eBGP, but who do not wish to go though
+   the work to manage the relevant certificates and ROAs.  Operators
+   SHOULD offer to provision the RPKI data for these customers just as
+   they provision many other things for them.
+
+   An operator using RPKI data MAY choose any polling frequency they
+   wish for ensuring they have a fresh RPKI cache.  However, if they use
+   RPKI data as an input to operational routing decisions, they SHOULD
+   ensure local caches inside their AS are synchronized with each other
+   at least every four to six hours.
+
+   Operators should use tools that warn them of any impending ROA or
+   certificate expiry that could affect the validity of their own data.
+   Ghostbusters Records [RFC6493] can be used to facilitate contact with
+   upstream Certification Authorities (CAs) to effect repair.
+
+4.  Within a Network
+
+   Origin validation need only be done by edge routers in a network,
+   those which border other networks or ASes.
+
+   A validating router will use the result of origin validation to
+   influence local policy within its network; see Section 5.  In
+   deployment, this policy should fit into the AS's existing policy,
+   preferences, etc.  This allows a network to incrementally deploy
+   validation-capable border routers.
+
+   The operator should be aware that RPKI-based origin validation, as
+   any other policy change, can cause traffic shifts in their network.
+   And, as with normal policy shift practice, a prudent operator has
+   tools and methods to predict, measure, modify, etc.
+
+5.  Routing Policy
+
+   Origin validation based on the RPKI marks a received announcement as
+   having an origin that is Valid, NotFound, or Invalid; see [RFC6811].
+   How this is used in routing should be specified by the operator's
+   local policy.
+
+   Local policy using relative preference is suggested to manage the
+   uncertainty associated with a system in early deployment; local
+   policy can be applied to eliminate the threat of unreachability of
+
+
+
+Bush                      Best Current Practice                 [Page 6]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+   prefixes due to ill-advised certification policies and/or incorrect
+   certification data.  For example, until the community feels
+   comfortable relying on RPKI data, routing on Invalid origin validity,
+   though at a low preference, MAY occur.
+
+   Operators should be aware that accepting Invalid announcements, no
+   matter how de-preferenced, will often be the equivalent of treating
+   them as fully Valid.  Consider having a ROA for AS 42 for prefix
+   10.0.0.0/16-24.  A BGP announcement for 10.0.666.0/24 from AS 666
+   would be Invalid.  But if policy is not configured to discard it,
+   then longest-match forwarding will send packets toward AS 666, no
+   matter the value of local preference.
+
+   As origin validation will be rolled out incrementally, coverage will
+   be incomplete for a long time.  Therefore, routing on NotFound
+   validity state SHOULD be done for a long time.  As the transition
+   moves forward, the number of BGP announcements with validation state
+   NotFound should decrease.  Hence, an operator's policy should not be
+   overly strict and should prefer Valid announcements; it should attach
+   a lower preference to, but still use, NotFound announcements, and
+   drop or give a very low preference to Invalid announcements.  Merely
+   de-preferencing Invalid announcements is ill-advised; see previous
+   paragraph.
+
+   Some providers may choose to set Local-Preference based on the RPKI
+   validation result.  Other providers may not want the RPKI validation
+   result to be more important than AS_PATH length -- these providers
+   would need to map the RPKI validation result to some BGP attribute
+   that is evaluated in BGP's path selection process after the AS_PATH
+   is evaluated.  Routers implementing RPKI-based origin validation MUST
+   provide such options to operators.
+
+   Local-Preference may be used to carry both the validity state of a
+   prefix along with its traffic engineering (TE) characteristic(s).  It
+   is likely that an operator already using Local-Preference will have
+   to change policy so they can encode these two separate
+   characteristics in the same BGP attribute without negative impact or
+   opening privilege escalation attacks.  For example, do not encode
+   validation state in higher bits than used for TE.
+
+   When using a metric that is also influenced by other local policy, an
+   operator should be careful not to create privilege-upgrade
+   vulnerabilities.  For example, if Local Pref is set depending on
+   validity state, peer community signaling SHOULD NOT upgrade an
+   Invalid announcement to Valid or better.
+
+   Announcements with Valid origins should be preferred over those with
+   NotFound or Invalid origins, if Invalid origins are accepted at all.
+
+
+
+Bush                      Best Current Practice                 [Page 7]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+   Announcements with NotFound origins should be preferred over those
+   with Invalid origins.
+
+   Announcements with Invalid origins SHOULD NOT be used, but may be
+   used to meet special operational needs.  In such circumstances, the
+   announcement should have a lower preference than that given to Valid
+   or NotFound.
+
+   When first deploying origin validation, it may be prudent not to drop
+   announcements with Invalid origins until inspection of logs, SNMP, or
+   other data indicates that the correct result would be obtained.
+
+   Validity state signaling SHOULD NOT be accepted from a neighbor AS.
+   The validity state of a received announcement has only local scope
+   due to issues such as scope of trust, RPKI synchrony, and management
+   of local trust anchors [LTA-USE].
+
+6.  Notes and Recommendations
+
+   Like the DNS, the global RPKI presents only a loosely consistent
+   view, depending on timing, updating, fetching, etc.  Thus, one cache
+   or router may have different data about a particular prefix than
+   another cache or router.  There is no 'fix' for this, it is the
+   nature of distributed data with distributed caches.
+
+   Operators should beware that RPKI caches are loosely synchronized,
+   even within a single AS.  Thus, changes to the validity state of
+   prefixes could be different within an operator's network.  In
+   addition, there is no guaranteed interval from when an RPKI cache is
+   updated to when that new information may be pushed or pulled into a
+   set of routers via this protocol.  This may result in sudden shifts
+   of traffic in the operator's network, until all of the routers in the
+   AS have reached equilibrium with the validity state of prefixes
+   reflected in all of the RPKI caches.
+
+   It is hoped that testing and deployment will produce advice on cache
+   loading and timing for relying parties.
+
+   There is some uncertainty about the origin AS of aggregates and what,
+   if any, ROA can be used.  The long-range solution to this is the
+   deprecation of AS_SETs; see [RFC6472].
+
+   As reliable access to the global RPKI and an operator's caches (and
+   possibly other hosts, e.g., DNS root servers) is important, an
+   operator should take advantage of relying-party tools that report
+   changes in BGP or RPKI data that would negatively affect validation
+   of such prefixes.
+
+
+
+
+Bush                      Best Current Practice                 [Page 8]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+   Operators should be aware that there is a trade-off in placement of
+   an RPKI repository in address space for which the repository's
+   content is authoritative.  On one hand, an operator will wish to
+   maximize control over the repository.  On the other hand, if there
+   are reachability problems to the address space, changes in the
+   repository to correct them may not be easily accessed by others.
+
+   Operators who manage certificates should associate RPKI Ghostbusters
+   Records (see [RFC6493]) with each publication point they control.
+   These are publication points holding the CRL, ROAs, and other signed
+   objects issued by the operator, and made available to other ASes in
+   support of routing on the public Internet.
+
+   Routers that perform RPKI-based origin validation must support Four-
+   octet AS Numbers (see [RFC6793]), as, among other things, it is not
+   reasonable to generate ROAs for AS 23456.
+
+   Software that produces filter lists or other control forms for
+   routers where the target router does not support Four-octet AS
+   Numbers (see [RFC6793]) must be prepared to accept four-octet AS
+   Numbers and generate the appropriate two-octet output.
+
+   As a router must evaluate certificates and ROAs that are time
+   dependent, routers' clocks MUST be correct to a tolerance of
+   approximately an hour.
+
+   Servers should provide time service, such as NTPv4 [RFC5905], to
+   client routers.
+
+7.  Security Considerations
+
+   As the BGP origin AS of an update is not signed, origin validation is
+   open to malicious spoofing.  Therefore, RPKI-based origin validation
+   is expected to deal only with inadvertent mis-advertisement.
+
+   Origin validation does not address the problem of AS_PATH validation.
+   Therefore, paths are open to manipulation, either malicious or
+   accidental.
+
+   As BGP does not ensure that traffic will flow via the paths it
+   advertises, the data plane may not follow the control plane.
+
+   Be aware of the class of privilege escalation issues discussed in
+   Section 5 above.
+
+
+
+
+
+
+
+Bush                      Best Current Practice                 [Page 9]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+8.  Acknowledgments
+
+   The author wishes to thank Shane Amante, Rob Austein, Steve Bellovin,
+   Jay Borkenhagen, Wes George, Seiichi Kawamura, Steve Kent, Pradosh
+   Mohapatra, Chris Morrow, Sandy Murphy, Eric Osterweil, Keyur Patel,
+   Heather and Jason Schiller, John Scudder, Kotikalapudi Sriram,
+   Maureen Stillman, and Dave Ward.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC6490]  Huston, G., Weiler, S., Michaelson, G., and S. Kent,
+              "Resource Public Key Infrastructure (RPKI) Trust Anchor
+              Locator", RFC 6490, February 2012.
+
+   [RFC6493]  Bush, R., "The Resource Public Key Infrastructure (RPKI)
+              Ghostbusters Record", RFC 6493, February 2012.
+
+   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
+              Autonomous System (AS) Number Space", RFC 6793, December
+              2012.
+
+   [RFC6810]  Bush, R. and R. Austein, "The Resource Public Key
+              Infrastructure (RPKI) to Router Protocol", RFC 6810,
+              January 2013.
+
+   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
+              Austein, "BGP Prefix Origin Validation", RFC 6811, January
+              2013.
+
+9.2.  Informative References
+
+   [LTA-USE]  Bush, R., "RPKI Local Trust Anchor Use Cases", Work in
+              Progress, September 2013.
+
+   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+              Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+
+
+Bush                      Best Current Practice                [Page 10]
+
+RFC 7115             RPKI-Based Origin Validation Op        January 2014
+
+
+   [RFC5781]  Weiler, S., Ward, D., and R. Housley, "The rsync URI
+              Scheme", RFC 5781, February 2010.
+
+   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
+              Time Protocol Version 4: Protocol and Algorithms
+              Specification", RFC 5905, June 2010.
+
+   [RFC6472]  Kumari, W. and K. Sriram, "Recommendation for Not Using
+              AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472,
+              December 2011.
+
+   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
+              Secure Internet Routing", RFC 6480, 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.
+
+   [IAB]      IAB, "IAB statement on the RPKI", January 2010,
+              <http://www.iab.org/documents/
+              correspondence-reports-documents/docs2010/
+              iab-statement-on-the-rpki/>.
+
+   [rcynic]   "rcynic RPKI validator", November 2013,
+              <http://rpki.net/rcynic>.
+
+Author's Address
+
+   Randy Bush
+   Internet Initiative Japan
+   5147 Crystal Springs
+   Bainbridge Island, Washington  98110
+   US
+
+   EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+Bush                      Best Current Practice                [Page 11]
+