draft-ietf-sidr-bgpsec-ops-04.txt   draft-ietf-sidr-bgpsec-ops-05.txt 
Network Working Group R. Bush Network Working Group R. Bush
Internet-Draft Internet Initiative Japan Internet-Draft Internet Initiative Japan
Intended status: BCP March 13, 2012 Intended status: BCP May 24, 2012
Expires: September 14, 2012 Expires: November 25, 2012
BGPsec Operational Considerations BGPsec Operational Considerations
draft-ietf-sidr-bgpsec-ops-04 draft-ietf-sidr-bgpsec-ops-05
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 them. It is expected to evolve as BGPsec is formalized and present them. It is expected to evolve as BGPsec is formalized and
initially deployed. initially deployed.
Requirements Language Requirements Language
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 14, 2012. This Internet-Draft will expire on November 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . . . . . . 4 5. Within a Network . . . . . . . . . . . . . . . . . . . . . . . 4
6. Considerations for Edge Sites . . . . . . . . . . . . . . . . . 4 6. Considerations for Edge Sites . . . . . . . . . . . . . . . . . 5
7. Routing Policy . . . . . . . . . . . . . . . . . . . . . . . . 5 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
11.2. Informative References . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
BGPsec is a new protocol with many operational considerations. It is BGPsec is a new protocol with many operational considerations. It is
expected to be deployed incrementally over a number of years. As expected to be deployed incrementally over a number of years. As
core BGPsec-capable routers may require large memory and/or modern core BGPsec-capable routers may require large memory and/or modern
CPUs, it is thought that origin validation based on the RPKI will CPUs, it is thought that origin validation based on the RPKI will
occur over the next one to three years and that BGPsec will start to occur over the next one to three years and that BGPsec will start to
deploy late in that window. deploy late in that window.
skipping to change at page 3, line 40 skipping to change at page 3, line 40
[I-D.lepinski-bgpsec-overview], the RPKI, see [RFC6480], the RPKI [I-D.lepinski-bgpsec-overview], the RPKI, see [RFC6480], the RPKI
Repository Structure, see [RFC6481], and ROAs, see [RFC6482]. Repository Structure, see [RFC6481], and 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 [I-D.ietf-sidr-origin-ops] apply. Maintenance of [I-D.ietf-sidr-origin-ops] apply.
4. AS/Router Certificates 4. AS/Router Certificates
As described in [I-D.ymbk-bgpsec-rtr-rekeying] routers MAY be capable As described in [I-D.ietf-sidr-rtr-keying] routers MAY be capable of
of generating their own public/private key-pairs and having their generating their own public/private key-pairs and having their
certificates signed and published in the RPKI by the RPKI CA system, certificates signed and published in the RPKI by the RPKI CA system,
and/or MAY be given public/private key-pairs by the operator. and/or MAY be given public/private key-pairs by the 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 accept 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 use a On the other extreme, an edge site with one or two routers MAY use a
single certificate/key. single certificate/key.
A prudent operator will pre-provision each router's 'next' key in the
RPKI so that, in case of compromise of the current key, there is no
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,
i.e. an RR client or the transitive closure of their customers' i.e. an RR client or the transitive closure of their customers'
customers' customers' .... customers' customers' ....
skipping to change at page 4, line 31 skipping to change at page 4, line 35
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 capable border This allows a network to incrementally deploy BGPsec capable 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 the earliest deployment. Both securing one's own be candidates for the earliest 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,
can cause traffic shifts in their network. And, as with normal
policy shift practice, a prudent operator has tools and methods to
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. will want to deploy incrementally while shifts in traffic, etc. will want to deploy incrementally while
watching those and similar effects. watching those and similar effects.
As they are not signed, an eBGP listener SHOULD NOT strongly trust As they are not signed, an eBGP listener SHOULD NOT strongly trust
unsigned markings such as communities received across a trust unsigned markings such as communities received across a trust
boundary. boundary.
6. Considerations for Edge Sites 6. Considerations for Edge Sites
skipping to change at page 5, line 26 skipping to change at page 5, line 38
announcement as Valid or Invalid, there is no NotFound state. How announcement as Valid or Invalid, there is no NotFound state. How
this is used in routing is up to the operator's local policy. See this is used in routing is up to the operator's local policy. See
[I-D.ietf-sidr-pfx-validate]. [I-D.ietf-sidr-pfx-validate].
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
intermediate non-signing edge routers, coverage will be spotty for a intermediate non-signing edge routers, coverage will be spotty for a
long time. Hence a normal operator's policy SHOULD NOT be overly long time. Hence a normal operator's policy SHOULD NOT be overly
strict, perhaps preferring valid announcements and giving very low strict, perhaps preferring valid announcements and giving very low
preference, but still using, invalid announcements. preference, but still using, invalid announcements.
Operators should be aware that accepting Invalid announcements, no
matter how de-preffed, will often be the equivalent of treating them
as fully Valid. Consider having a Valid announcement from neighbor V
for prefix 10.0.0.0/16 and an Invalid announcement for 10.0.666.0/24
from neighbor I. If local policy on the router is not configured to
discard the Invalid announcement from I, then longest match
forwarding will send packets to neighbor I no matter the value of
local preference.
A BGPsec speaker validates signed paths at the eBGP edge. A BGPsec speaker validates signed paths 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, or modifying a metric value such as local-preference a BGP community, or modifying a metric value such as local-preference
or MED. Some MAY choose to use the large Local-Pref hammer. Others 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 MAY choose to let AS-Path rule and set their internal metric, which
comes after AS-Path in the BGP decision process. 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
skipping to change at page 7, line 20 skipping to change at page 7, line 39
10. IANA Considerations 10. IANA Considerations
This document has no IANA Considerations. This document has no IANA Considerations.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-sidr-bgpsec-protocol] [I-D.ietf-sidr-bgpsec-protocol]
Lepinski, M., "BGPSEC Protocol Specification", Lepinski, M., "BGPSEC Protocol Specification",
draft-ietf-sidr-bgpsec-protocol-01 (work in progress), draft-ietf-sidr-bgpsec-protocol-03 (work in progress),
October 2011. May 2012.
[I-D.ietf-sidr-ghostbusters] [I-D.ietf-sidr-ghostbusters]
Bush, R., "The RPKI Ghostbusters Record", Bush, R., "The RPKI Ghostbusters Record",
draft-ietf-sidr-ghostbusters-16 (work in progress), draft-ietf-sidr-ghostbusters-16 (work in progress),
December 2011. December 2011.
[I-D.ietf-sidr-origin-ops] [I-D.ietf-sidr-origin-ops]
Bush, R., "RPKI-Based Origin Validation Operation", Bush, R., "RPKI-Based Origin Validation Operation",
draft-ietf-sidr-origin-ops-15 (work in progress), draft-ietf-sidr-origin-ops-15 (work in progress),
March 2012. March 2012.
skipping to change at page 8, line 15 skipping to change at page 8, line 35
11.2. Informative References 11.2. Informative References
[I-D.ietf-sidr-algorithm-agility] [I-D.ietf-sidr-algorithm-agility]
Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
Procedure for RPKI.", draft-ietf-sidr-algorithm-agility-05 Procedure for RPKI.", draft-ietf-sidr-algorithm-agility-05
(work in progress), January 2012. (work in progress), January 2012.
[I-D.ietf-sidr-pfx-validate] [I-D.ietf-sidr-pfx-validate]
Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
Austein, "BGP Prefix Origin Validation", Austein, "BGP Prefix Origin Validation",
draft-ietf-sidr-pfx-validate-03 (work in progress), draft-ietf-sidr-pfx-validate-05 (work in progress),
October 2011. April 2012.
[I-D.ietf-sidr-rtr-keying]
Turner, S., Patel, K., and R. Bush, "Router Keying for
BGPsec", draft-ietf-sidr-rtr-keying-00 (work in progress),
May 2012.
[I-D.rogaglia-sidr-bgpsec-rollover] [I-D.rogaglia-sidr-bgpsec-rollover]
Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key Gagliano, R., Patel, K., and B. Weis, "BGPSEC router key
roll-over as an alternative to beaconing", roll-over as an alternative to beaconing",
draft-rogaglia-sidr-bgpsec-rollover-00 (work in progress), draft-rogaglia-sidr-bgpsec-rollover-00 (work in progress),
March 2012. March 2012.
[I-D.ymbk-bgpsec-rtr-rekeying]
Turner, S., Patel, K., and R. Bush, "Router Keying for
BGPsec", draft-ymbk-bgpsec-rtr-rekeying-00 (work in
progress), March 2012.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous
System Confederations for BGP", RFC 5065, August 2007. System Confederations for BGP", RFC 5065, August 2007.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010.
 End of changes. 12 change blocks. 
17 lines changed or deleted 35 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/