draft-ietf-sidr-bgpsec-ops-12.txt   draft-ietf-sidr-bgpsec-ops-13.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 December 6, 2016 Intended status: Best Current Practice January 4, 2017
Expires: June 9, 2017 Expires: July 8, 2017
BGPsec Operational Considerations BGPsec Operational Considerations
draft-ietf-sidr-bgpsec-ops-12 draft-ietf-sidr-bgpsec-ops-13
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 June 9, 2017. This Internet-Draft will expire on July 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 2, line 35 skipping to change at page 2, line 35
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 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, it is thought that may require large memory and/or modern CPUs, origin validation based
origin validation based on the RPKI, [RFC6811], will occur over some on the Resource Public Key Infrastructure (RPKI), [RFC6811], will
years and that BGPsec will start to deploy after that. occur over some years and that BGPsec will start to deploy after
that.
BGPsec relies on widespread propagation of the Resource Public Key BGPsec relies on widespread propagation of the RPKI [RFC6480]. How
Infrastructure (RPKI) [RFC6480]. How the RPKI is distributed and the RPKI is distributed and maintained globally and within an
maintained globally and within an operator's infrastructure may be operator's infrastructure may be different for BGPsec than for origin
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.
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-overview], the RPKI, see [RFC6480], the RPKI
Repository Structure, see [RFC6481], and ROAs, see [RFC6482]. Repository Structure, see [RFC6481], and Route Origin Authorizations
(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
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 either capable of generating their own public/private key-pairs
and having their certificates signed and published in the RPKI by the and 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 accept 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.
On the other extreme, an edge site with one or two routers may choose At the other end of the spectrum, an edge site with one or two
to use a single certificate/key. routers may choose to use a single certificate/key.
In anticipation of possible key compromise, a prudent operator will 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 a fully BGPsec enabled AS, Route Reflectors MUST have BGPsec
enabled if and only if there are eBGP speakers in their client cone, enabled if and only if there are eBGP speakers in their client cone,
skipping to change at page 4, line 13 skipping to change at page 4, line 13
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
announcements and validating received announcements should be announcements and validating received announcements should be
considered in partial deployment. considered in partial deployment.
The operator should be aware that BGPsec, as any other policy change, An operator should be aware that BGPsec, as any other policy change,
can cause traffic shifts in their network. And, as with normal can cause traffic shifts in their network. And, as with normal
policy shift practice, a prudent operator has tools and methods to policy shift practice, a prudent operator has tools and methods to
predict, measure, modify, etc. predict, measure, modify, etc.
On the other hand, an operator wanting to monitor router loading, On the other hand, an operator wanting to monitor router loading,
shifts in traffic, etc. might deploy incrementally while watching shifts in traffic, etc. might deploy incrementally while watching
those and similar effects. those and similar effects.
BGPsec does not sign over communities, so they are not formally BGPsec does not sign over communities, so they are not formally
trustable. Additionally, outsourcing verification is not prudent trustable. Additionally, outsourcing verification is not prudent
security practice. Therefore an eBGP listener SHOULD NOT strongly security practice. Therefore an eBGP listener SHOULD NOT strongly
trust unsigned security signaling, such as communities, received trust unsigned security signaling, such as communities, received
across a trust boundary. across a trust boundary.
6. Considerations for Edge Sites 6. Considerations for Edge Sites
An edge site which does not provide transit and trusts its An edge site which does not provide transit and trusts its
upstream(s) SHOULD only originate a signed prefix announcement and upstream(s) may only originate a signed prefix announcement and not
need not validate received announcements. validate received announcements.
Operators might need to use hardware with limited resources. In such An Operator might need to use hardware with limited resources. In
cases, BGPsec protocol capability negotiation allows for a resource such cases, BGPsec protocol capability negotiation allows for a
constrained edge router to hold only its own signing key(s) and sign resource constrained edge router to hold only its own signing key(s)
its announcements, but not receive signed announcements. Therefore, and sign its announcements, but not receive signed announcements.
the router would not have to deal with the majority of the RPKI, Therefore, the router would not have to deal with the majority of the
potentially saving the need for additional hardware. RPKI, potentially saving the need for additional hardware.
As the vast majority (84%) of ASs are stubs, and they announce the As the vast majority of ASs are stubs, and they announce the majority
majority of prefixes, this allows for simpler and less expensive of prefixes, this allows for simpler and less expensive incremental
incremental deployment. It may also mean that edge sites concerned deployment. It may also mean that edge sites concerned with routing
with routing security will be attracted to upstreams which support security will be attracted to upstreams which support BGPsec.
BGPsec.
7. Routing Policy 7. Routing Policy
Unlike origin validation based on the RPKI, BGPsec marks a received Unlike origin validation based on the RPKI, BGPsec marks a received
announcement as Valid or Not Valid, there is no explicit NotFound announcement as Valid or Not Valid, there is no explicit NotFound
state. In some sense, an unsigned BGP4 path is the equivalent of state. In some sense, an unsigned BGP4 path is the equivalent of
NotFound. How this is used in routing is up to the operator's local NotFound. How this is used in routing is up to the operator's local
policy, similar to origin validation as in [RFC6811]. policy, similar to origin validation as in [RFC6811].
As BGPsec will be rolled out over years and does not allow for As BGPsec will be rolled out over years and does not allow for
skipping to change at page 5, line 43 skipping to change at page 5, line 41
metric, which comes after AS-Path in the BGP decision process. metric, which comes after AS-Path in the BGP decision process.
Because of possible RPKI version skew, an AS Path which does not Because of possible RPKI version skew, an AS Path which does not
validate at router R0 might validate at R1. Therefore, signed paths validate at router R0 might validate at R1. Therefore, signed paths
that are Not Valid and yet propagated (because they are chosen as that are Not Valid and yet propagated (because they are chosen as
best path) should have their signatures left intact and MUST be best path) should have their signatures left intact and MUST be
signed if sent to external BGPsec speakers. 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.
A BGPsec speaker receiving a path SHOULD perform origin validation A BGPsec speaker receiving a path SHOULD perform origin validation
per [RFC6811] and [RFC7115]. per [RFC6811] and [RFC7115].
A route server is usually 'transparent', i.e. does not insert an AS A route server is usually 'transparent', i.e. does not insert an AS
skipping to change at page 7, line 28 skipping to change at page 7, line 25
This document describes operational considerations for the deployment This document describes operational considerations for the deployment
of BGPsec. The security considerations for BGPsec are described in of BGPsec. The security considerations for BGPsec are described in
[I-D.ietf-sidr-bgpsec-protocol]. [I-D.ietf-sidr-bgpsec-protocol].
10. IANA Considerations 10. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
11. Acknowledgments 11. Acknowledgments
The author wishes to thank the BGPsec design group, Thomas King, The author wishes to thank Thomas King, Arnold Nipper, and Alvaro
Arnold Nipper, and Alvaro Retana. Retana, and the BGPsec design group.
12. References 12. References
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
skipping to change at page 8, line 9 skipping to change at page 8, line 9
[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,
<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-05 (work in Migration", draft-ietf-sidr-as-migration-06 (work in
progress), April 2016. progress), December 2016.
[I-D.ietf-sidr-bgpsec-overview] [I-D.ietf-sidr-bgpsec-overview]
Lepinski, M. and S. Turner, "An Overview of BGPSEC", Lepinski, M. and S. Turner, "An Overview of BGPSEC",
draft-ietf-sidr-bgpsec-overview-02 (work in progress), May draft-ietf-sidr-bgpsec-overview-02 (work in progress), May
2012. 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.
 End of changes. 19 change blocks. 
38 lines changed or deleted 39 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/