draft-ietf-sidr-bgpsec-ops-14.txt   draft-ietf-sidr-bgpsec-ops-15.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 5, 2017 Intended status: Best Current Practice January 5, 2017
Expires: July 9, 2017 Expires: July 9, 2017
BGPsec Operational Considerations BGPsec Operational Considerations
draft-ietf-sidr-bgpsec-ops-14 draft-ietf-sidr-bgpsec-ops-15
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 2, line 20 skipping to change at page 2, line 20
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. AS/Router Certificates . . . . . . . . . . . . . . . . . . . 3 4. AS/Router Certificates . . . . . . . . . . . . . . . . . . . 3
5. Within a Network . . . . . . . . . . . . . . . . . . . . . . 3 5. Within a Network . . . . . . . . . . . . . . . . . . . . . . 3
6. Considerations for Edge Sites . . . . . . . . . . . . . . . . 4 6. Considerations for Edge Sites . . . . . . . . . . . . . . . . 4
7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 4 7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . 5
8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
12.1. Normative References . . . . . . . . . . . . . . . . . . 7 12.1. Normative References . . . . . . . . . . . . . . . . . . 7
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 Origin Validation based on the Resource Public Key Infrastructure
operational considerations. It is expected to be deployed (RPKI), [RFC6811], is in its early phases. As BGPsec,
incrementally over a number of years. As core BGPsec-capable routers [I-D.ietf-sidr-bgpsec-protocol] may require larger memory and/or more
may require large memory and/or modern CPUs, origin validation based modern CPUs, it expected to be deployed incrementally over a longer
on the Resource Public Key Infrastructure (RPKI), [RFC6811], will time span. BGPsec is a new protocol with many operational
occur over some years and BGPsec will start to deploy after that. As considerations which this document attempts to describe. As with
with most operational practices, this document will likely evolve. 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 border
routers, and is designed so that it can be used to protect routers. It 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, see Section 6. 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-protocol], 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 The considerations for RPKI objects (Certificates, Certificate
Maintenance of [RFC7115] apply. Revocation Lists (CRLs), manifests, Ghostbusters Records [RFC6481]),
Trust Anchor Locators (TALs) [RFC6490], cache behaviours of
synchronisation and validation from the section on RPKI Distribution
and Maintenance of [RFC7115] apply. Specific considerations relating
to ROA objects do not apply to this document.
4. AS/Router Certificates 4. AS/Router Certificates
As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers As described in [I-D.ietf-sidr-rtr-keying] BGPsec-speaking routers
are either capable of generating their own public/private key-pairs are capable of generating their own public/private key-pairs and
and having their certificates signed and published in the RPKI by the having their certificates signed and published in the RPKI by the
RPKI CA system, and/or are given public/private key-pairs by the RPKI CA system, and/or are given public/private key-pairs by the
operator. operator.
A site/operator may use a single certificate/key in all their A site/operator may use a single certificate/key in all their
routers, one certificate/key per router, or any granularity in routers, one certificate/key per router, or any granularity in
between. between.
A large operator, concerned that a compromise of one router's key A large operator, concerned that a compromise of one router's key
would make other routers vulnerable, may deploy a more complex would make other routers vulnerable, may deploy a more complex
certificate/key distribution burden to reduce this exposure. certificate/key distribution burden to reduce this exposure.
At the other end of the spectrum, an edge site with one or two At the other end of the spectrum, an edge site with one or two
routers may choose to use a single certificate/key. routers may choose to use a single certificate/key.
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 an AS where edge routers speak BGPsec and therefore inject BGPsec In an AS where edge routers speak BGPsec and therefore inject BGPsec
paths into the iBGP, Route Reflectors MUST have BGPsec enabled if and paths into the iBGP, Route Reflectors MUST have BGPsec enabled if and
skipping to change at page 5, line 37 skipping to change at page 5, line 45
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 multi-exit discriminator (MED). Some may choose local-preference or multi-exit discriminator (MED). Some may choose
to use the large Local-Pref hammer. Others may choose to let AS-Path 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 rule and set their internal metric, which comes after AS-Path in the
BGP decision process. BGP decision process.
As the mildly stochastic timing of RPKI propagation may cause version As the mildly stochastic timing of RPKI propagation may cause version
skew across routers, an AS Path which does not validate at router R0 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 might validate at R1. Therefore, signed paths that are Not Valid and
yet propagated (because they are chosen as best path) should have yet propagated (because they are chosen as best path) MUST NOT have
their signatures left intact and MUST be signed if sent to external signatures stripped and MUST be signed if sent to external BGPsec
BGPsec speakers. 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 7, line 46 skipping to change at page 8, line 5
12.1. Normative References 12.1. Normative References
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPSEC Protocol Specification", draft-ietf- Lepinski, M., "BGPSEC Protocol Specification", draft-ietf-
sidr-bgpsec-protocol-07 (work in progress), February 2013. sidr-bgpsec-protocol-07 (work in progress), February 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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) [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, February 2012. Ghostbusters Record", RFC 6493, February 2012.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. [RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", RFC 6811, January Austein, "BGP Prefix Origin Validation", RFC 6811, January
2013. 2013.
[RFC7115] Bush, R., "Origin Validation Operation Based on the [RFC7115] Bush, R., "Origin Validation Operation Based on the
Resource Public Key Infrastructure (RPKI)", BCP 185, Resource Public Key Infrastructure (RPKI)", BCP 185,
RFC 7115, DOI 10.17487/RFC7115, January 2014, RFC 7115, DOI 10.17487/RFC7115, January 2014,
 End of changes. 9 change blocks. 
19 lines changed or deleted 27 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/