draft-ietf-sidr-origin-ops-21.txt   draft-ietf-sidr-origin-ops-22.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: Best Current Practice September 06, 2013 Intended status: Best Current Practice October 07, 2013
Expires: March 10, 2014 Expires: April 10, 2014
RPKI-Based Origin Validation Operation RPKI-Based Origin Validation Operation
draft-ietf-sidr-origin-ops-21 draft-ietf-sidr-origin-ops-22
Abstract Abstract
Deployment of RPKI-based BGP origin validation has many operational Deployment of RPKI-based BGP origin validation has many operational
considerations. This document attempts to collect and present those considerations. This document attempts to collect and present those
which are most critical. It is expected to evolve as RPKI-based which are most critical. It is expected to evolve as RPKI-based
origin validation continues to be deployed and the dynamics are origin validation continues to be deployed and the dynamics are
better understood. better understood.
Requirements Language Requirements Language
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
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 March 10, 2014. This Internet-Draft will expire on April 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3 2. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3 3. RPKI Distribution and Maintenance . . . . . . . . . . . . . . 3
4. Within a Network . . . . . . . . . . . . . . . . . . . . . . 6 4. Within a Network . . . . . . . . . . . . . . . . . . . . . . 6
5. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 6 5. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 7
6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
RPKI-based origin validation relies on widespread deployment of the RPKI-based origin validation relies on widespread deployment of the
Resource Public Key Infrastructure (RPKI) [RFC6480]. How the RPKI is Resource Public Key Infrastructure (RPKI) [RFC6480]. How the RPKI is
distributed and maintained globally is a serious concern from many distributed and maintained globally is a serious concern from many
aspects. aspects.
While the global RPKI is in the early stages of deployment, there is While the global RPKI is in the early stages of deployment, there is
skipping to change at page 4, line 15 skipping to change at page 4, line 15
Timing of inter-cache synchronization, and synchronization between Timing of inter-cache synchronization, and synchronization between
caches and the global RPKI, is outside the scope of this document, 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, and depends on things such as how often routers feed from the caches,
how often the operator feels the global RPKI changes significantly, how often the operator feels the global RPKI changes significantly,
etc. etc.
As inter-cache synchronization within an operator's network does not As inter-cache synchronization within an operator's network does not
impact global RPKI resources, an operator MAY choose to synchronize impact global RPKI resources, an operator MAY choose to synchronize
quite frequently. 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. I.e. the
router can not 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 As RPKI-based origin validation relies on the availability of RPKI
data, operators SHOULD locate caches close to routers that require data, operators SHOULD locate RPKI caches close to routers that
these data and services. 'Close' is, of course, complex. One should require these data and services in order to minimize the impact of
consider trust boundaries, routing bootstrap reachability, latency, likely failures in local routing, intermediate devices, long
etc. circuits, etc. One should also consider trust boundaries, routing
bootstrap reachability, etc.
For example, a router should bootstrap from a chache which 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 If insecure transports are used between an operator's cache and their
router(s), the Transport Security recommendations in [RFC6810] SHOULD router(s), the Transport Security recommendations in [RFC6810] SHOULD
be followed. In particular, operators MUST NOT use insecure be followed. In particular, operators MUST NOT use insecure
transports between their routers and RPKI caches located in other transports between their routers and RPKI caches located in other
Autonomous Systems. Autonomous Systems.
For redundancy, a router SHOULD peer with more than one cache at the 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 same time. Peering with two or more, at least one local and others
remote, is recommended. remote, is recommended.
 End of changes. 7 change blocks. 
14 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/