--- 1/draft-ietf-sidr-bgpsec-ops-13.txt 2017-01-04 09:13:17.389281067 -0800 +++ 2/draft-ietf-sidr-bgpsec-ops-14.txt 2017-01-04 09:13:17.409281606 -0800 @@ -1,18 +1,18 @@ Network Working Group R. Bush Internet-Draft Internet Initiative Japan -Intended status: Best Current Practice January 4, 2017 -Expires: July 8, 2017 +Intended status: Best Current Practice January 5, 2017 +Expires: July 9, 2017 BGPsec Operational Considerations - draft-ietf-sidr-bgpsec-ops-13 + draft-ietf-sidr-bgpsec-ops-14 Abstract Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present the most critical and universal. It is expected to evolve as BGPsec is formalized and initially deployed. Requirements Language @@ -30,21 +30,21 @@ 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 July 8, 2017. + This Internet-Draft will expire on July 9, 2017. Copyright Notice Copyright (c) 2017 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 @@ -72,40 +72,40 @@ 12.2. Informative References . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction BGPsec, [I-D.ietf-sidr-bgpsec-protocol], is a new protocol with many operational considerations. It is expected to be deployed incrementally over a number of years. As core BGPsec-capable routers may require large memory and/or modern CPUs, origin validation based on the Resource Public Key Infrastructure (RPKI), [RFC6811], will - occur over some years and that BGPsec will start to deploy after - that. + occur over some years and BGPsec will start to deploy after that. As + with most operational practices, this document will likely evolve. BGPsec relies on widespread propagation of the RPKI [RFC6480]. How the RPKI is distributed and maintained globally and within an operator's infrastructure may be different for BGPsec than for origin validation. BGPsec needs to be spoken only by an AS's eBGP-speaking, AKA border, routers, and is designed so that it can be used to protect announcements which are originated by resource constrained edge - routers. This has special operational considerations. + routers. This has special operational considerations, see Section 6. Different prefixes may have different timing and replay protection considerations. 2. Suggested Reading It is assumed that the reader understands BGP, see [RFC4271], BGPsec, - [I-D.ietf-sidr-bgpsec-overview], the RPKI, see [RFC6480], the RPKI + [I-D.ietf-sidr-bgpsec-protocol], the RPKI, see [RFC6480], the RPKI Repository Structure, see [RFC6481], and Route Origin Authorizations (ROAs), see [RFC6482]. 3. RPKI Distribution and Maintenance All non-ROA considerations in the section on RPKI Distribution and Maintenance of [RFC7115] apply. 4. AS/Router Certificates @@ -128,24 +128,24 @@ In anticipation of possible key compromise, a prudent operator should pre-provision each router's 'next' key in the RPKI so there is no propagation delay for provisioning the new key. 5. Within a Network BGPsec is spoken by edge routers in a network, those which border other networks/ASs. - In a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec - enabled if and only if there are eBGP speakers in their client cone, - i.e. an RR client or the transitive closure of a client's customers' - customers' customers' etc. + In an AS where edge routers speak BGPsec and therefore inject BGPsec + paths into the iBGP, Route Reflectors MUST have BGPsec enabled if and + only if there are eBGP speakers in their client cone, i.e. an RR + client or the transitive closure of a client's customers. A BGPsec capable router MAY use the data it receives to influence local policy within its network, see Section 7. In deployment this policy should fit into the AS's existing policy, preferences, etc. This allows a network to incrementally deploy BGPsec enabled border routers. eBGP speakers which face more critical peers or up/downstreams would be candidates for early deployment. Both securing one's own @@ -210,29 +210,31 @@ 10.0.666.0/24 from neighbor I. If local policy on the router is not configured to discard the Not Valid announcement from I, then longest match forwarding will send packets to neighbor I no matter the value of local preference. Validation of signed paths is usually deployed at the eBGP edge. Local policy on the eBGP edge MAY convey the validation state of a BGP signed path through normal local policy mechanisms, e.g. setting a BGP community for internal use, or modifying a metric value such as - local-preference or MED. Some may choose to use the large Local-Pref - hammer. Others may choose to let AS-Path rule and set their internal - metric, which comes after AS-Path in the BGP decision process. + local-preference or multi-exit discriminator (MED). Some may choose + to use the large Local-Pref hammer. Others may choose to let AS-Path + rule and set their internal metric, which comes after AS-Path in the + BGP decision process. - Because of possible RPKI version skew, an AS Path which does not - validate at router R0 might validate at R1. Therefore, signed paths - that are Not Valid and yet propagated (because they are chosen as - best path) should have their signatures left intact and MUST be - signed if sent to external BGPsec speakers. + As the mildly stochastic timing of RPKI propagation may cause version + skew across routers, an AS Path which does not validate at router R0 + might validate at R1. Therefore, signed paths that are Not Valid and + yet propagated (because they are chosen as best path) should have + their signatures left intact and MUST be signed if sent to external + BGPsec speakers. This implies that updates which a speaker judges to be Not Valid MAY be propagated to iBGP peers. Therefore, unless local policy ensures otherwise, a signed path learned via iBGP may be Not Valid. If needed, the validation state should be signaled by normal local policy mechanisms such as communities or metrics. On the other hand, local policy on the eBGP edge might preclude iBGP or eBGP announcement of signed AS Paths which are Not Valid. @@ -265,20 +267,23 @@ confederation will not cause external confusion even if non-unique private ASs are used. 8. Notes For protection from attacks replaying BGP data on the order of a day or longer old, re-keying routers with new keys (previously) provisioned in the RPKI is sufficient. For one approach, see [I-D.ietf-sidr-bgpsec-rollover] + A router that once negotiated (and/or sent) BGPsec should not be + expected to always do so. + 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 or router than another cache or router. There is no 'fix' for this, it is the nature of distributed data with distributed caches. Operators who manage certificates SHOULD have RPKI GhostBuster Records (see [RFC6493]), signed indirectly by End Entity certificates, for those certificates on which others' routing depends for certificate and/or ROA validation. @@ -336,25 +341,20 @@ RFC 7115, DOI 10.17487/RFC7115, January 2014, . 12.2. Informative References [I-D.ietf-sidr-as-migration] George, W. and S. Murphy, "BGPSec Considerations for AS Migration", draft-ietf-sidr-as-migration-06 (work in progress), December 2016. - [I-D.ietf-sidr-bgpsec-overview] - Lepinski, M. and S. Turner, "An Overview of BGPSEC", - draft-ietf-sidr-bgpsec-overview-02 (work in progress), May - 2012. - [I-D.ietf-sidr-bgpsec-rollover] Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key rollover as an alternative to beaconing", draft-ietf-sidr- bgpsec-rollover-01 (work in progress), October 2012. [I-D.ietf-sidr-rtr-keying] Turner, S., Patel, K., and R. Bush, "Router Keying for BGPsec", draft-ietf-sidr-rtr-keying-01 (work in progress), February 2013.