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

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