Internet Engineering Task Force (IETF)                          J. Mauch
Request for Comments: 8212                                        Akamai
Updates: 4271                                                J. Snijders
Category: Standards Track                                            NTT
ISSN: 2070-1721                                               G. Hankins
                                                                   Nokia
                                                               July 2017
        
Internet Engineering Task Force (IETF)                          J. Mauch
Request for Comments: 8212                                        Akamai
Updates: 4271                                                J. Snijders
Category: Standards Track                                            NTT
ISSN: 2070-1721                                               G. Hankins
                                                                   Nokia
                                                               July 2017
        

Default External BGP (EBGP) Route Propagation Behavior without Policies

没有策略的默认外部BGP(EBGP)路由传播行为

Abstract

摘要

This document updates RFC 4271 by defining the default behavior of a BGP speaker when there is no Import or Export Policy associated with an External BGP session.

当没有与外部BGP会话关联的导入或导出策略时,本文档通过定义BGP扬声器的默认行为来更新RFC 4271。

Status of This Memo

关于下段备忘

This is an Internet Standards Track document.

这是一份互联网标准跟踪文件。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。有关互联网标准的更多信息,请参见RFC 7841第2节。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8212.

有关本文件当前状态、任何勘误表以及如何提供反馈的信息,请访问http://www.rfc-editor.org/info/rfc8212.

Copyright Notice

版权公告

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.

版权所有(c)2017 IETF信托基金和确定为文件作者的人员。版权所有。

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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本,并提供简化BSD许可证中所述的无担保。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Changes to RFC 4271 . . . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Transition Considerations for BGP Implementers . . .   6
     A.1.  "N+1 N+2" Release Strategy  . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   3.  Changes to RFC 4271 . . . . . . . . . . . . . . . . . . . . .   3
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Transition Considerations for BGP Implementers . . .   6
     A.1.  "N+1 N+2" Release Strategy  . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7
        
1. Introduction
1. 介绍

BGP routing security issues need to be addressed in order to make the Internet more stable. Route leaks [RFC7908] are part of the problem, but software defects or operator misconfiguration can also contribute. This document updates [RFC4271] so that routes are neither imported nor exported unless specifically enabled by configuration. This change reduces the consequences of these problems and improves the default level of Internet routing security.

为了使互联网更加稳定,需要解决BGP路由安全问题。路由泄漏[RFC7908]是问题的一部分,但软件缺陷或操作员配置错误也可能是原因之一。本文档对[RFC4271]进行了更新,因此,除非通过配置专门启用,否则不会导入或导出路由。此更改减少了这些问题的后果,并提高了Internet路由安全的默认级别。

Many deployed BGP speakers send and accept any and all route announcements between their BGP neighbors by default. This practice dates back to the early days of the Internet, where operators were permissive in sending routing information to allow all networks to reach each other. As the Internet has become more densely interconnected, the risk of a misbehaving BGP speaker poses significant risks to Internet routing.

默认情况下,许多已部署的BGP扬声器在其BGP邻居之间发送和接受任何和所有路由通知。这种做法可以追溯到互联网的早期,当时运营商允许发送路由信息,以允许所有网络相互联系。随着互联网的互联越来越紧密,BGP演讲者行为不端的风险对互联网路由造成了重大风险。

This specification intends to improve this situation by requiring the explicit configuration of both BGP Import and Export Policies for any External BGP (EBGP) session such as customers, peers, or confederation boundaries for all enabled address families. Through codification of the aforementioned requirement, operators will benefit from consistent behavior across different BGP implementations.

本规范旨在通过要求为任何外部BGP(EBGP)会话(如所有启用的地址族的客户、对等方或联盟边界)显式配置BGP导入和导出策略来改善这种情况。通过对上述要求的编码,运营商将受益于不同BGP实现的一致行为。

BGP speakers following this specification do not use or send routes on EBGP sessions, unless specifically configured to do so.

遵循此规范的BGP扬声器不在EBGP会话上使用或发送路由,除非专门配置为这样做。

2. Terminology
2. 术语

[RFC4271] describes a Policy Information Base (PIB) that contains local policies that can be applied to the information in the Routing Information Base (RIB). This document distinguishes the type of a policy based on its application.

[RFC4271]描述一个策略信息库(PIB),其中包含可应用于路由信息库(RIB)中信息的本地策略。本文档根据应用程序区分策略的类型。

Import Policy: a local policy to be applied to the information contained in the Adj-RIBs-In. As described in Section 3.2 [RFC4271], the Adj-RIBs-In contain information learned from other BGP speakers, and the application of the Import Policy results in the routes that will be considered in the Decision Process by the local BGP speaker.

导入策略:应用于中的调整框中包含的信息的本地策略。如第3.2节[RFC4271]所述,中的Adj肋骨包含从其他BGP演讲者那里学到的信息,并且进口政策的应用将导致本地BGP演讲者在决策过程中考虑的路线。

Export Policy: a local policy to be applied in selecting the information contained in the Adj-RIBs-Out. As described in Section 3.2 [RFC4271], the Adj-RIBs-Out contain information that has been selected for advertisement to other BGP speakers.

导出策略:在选择Adj输出中包含的信息时应用的本地策略。如第3.2节[RFC4271]所述,调整肋包含已选择用于向其他BGP扬声器进行广告的信息。

2.1. Requirements Language
2.1. 需求语言

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时(如图所示)应按照BCP 14[RFC2119][RFC8174]所述进行解释。

3. Changes to RFC 4271
3. 对RFC 4271的更改

This section updates [RFC4271] to specify the default behavior of a BGP speaker when there are no Import or Export Policies associated with a particular EBGP session. A BGP speaker MAY provide a configuration option to deviate from the following updated behaviors.

本节更新[RFC4271]以指定在没有与特定EBGP会话关联的导入或导出策略时BGP扬声器的默认行为。BGP扬声器可提供一个配置选项,以偏离以下更新的行为。

The following paragraph is added to Section 9.1 (Decision Process) after the fifth paragraph, which ends in "route aggregation and route information reduction":

在第五段之后的第9.1节(决策过程)中增加了以下段落,该段落以“路线汇总和路线信息缩减”结尾:

Routes contained in an Adj-RIB-In associated with an EBGP peer SHALL NOT be considered eligible in the Decision Process if no explicit Import Policy has been applied.

如果未应用明确的进口政策,则与EBGP对等方相关的Adj RIB中包含的路线在决策过程中不应被视为合格。

The following paragraph is added to Section 9.1.3 (Phase 3: Route Dissemination) after the third paragraph, which ends in "by means of an UPDATE message (see 9.2).":

在第三段之后的第9.1.3节(第3阶段:路线传播)中增加了以下段落,该段落以“通过更新消息(见9.2)”结尾:

Routes SHALL NOT be added to an Adj-RIB-Out associated with an EBGP peer if no explicit Export Policy has been applied.

如果未应用明确的出口政策,则不得将路线添加到与EBGP对等点相关的Adj肋骨。

4. Security Considerations
4. 安全考虑

Permissive default routing policies can result in inadvertent effects such as route leaks [RFC7908], in general resulting in routing of traffic through an unexpected path. While it is possible for an operator to use monitoring to detect unexpected flows, there is no general framework that can be applied. These policies also have the potential to expose software defects or misconfiguration that could have unforeseen technical and business impacting effects.

允许的默认路由策略可能会导致意外影响,例如路由泄漏[RFC7908],通常会导致通过意外路径的流量路由。虽然操作员可以使用监控来检测意外流,但没有可应用的通用框架。这些策略还可能暴露软件缺陷或错误配置,这些缺陷或配置可能会产生不可预见的技术和业务影响。

The update to [RFC4271] specified in this document is intended to eliminate those inadvertent effects. Operators must explicitly configure Import and Export Policies to achieve their expected goals. There is of course no protection against a malicious or incorrect explicit configuration.

本文件中规定的[RFC4271]更新旨在消除这些意外影响。操作员必须明确配置导入和导出策略以实现其预期目标。当然,没有针对恶意或不正确的显式配置的保护。

The security considerations described in [RFC4271] and the vulnerability analysis discussed in [RFC4272] also apply to this document.

[RFC4271]中描述的安全注意事项和[RFC4272]中讨论的漏洞分析也适用于本文档。

5. IANA Considerations
5. IANA考虑

This document does not require any IANA actions.

本文件不要求IANA采取任何行动。

6. References
6. 工具书类
6.1. Normative References
6.1. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119]Bradner,S.,“RFC中用于表示需求水平的关键词”,BCP 14,RFC 2119,DOI 10.17487/RFC2119,1997年3月<http://www.rfc-editor.org/info/rfc2119>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4271]Rekhter,Y.,Ed.,Li,T.,Ed.,和S.Hares,Ed.,“边境网关协议4(BGP-4)”,RFC 4271,DOI 10.17487/RFC4271,2006年1月<http://www.rfc-editor.org/info/rfc4271>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.

[RFC8174]Leiba,B.,“RFC 2119关键词中大写与小写的歧义”,BCP 14,RFC 8174,DOI 10.17487/RFC8174,2017年5月<http://www.rfc-editor.org/info/rfc8174>.

6.2. Informative References
6.2. 资料性引用

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.

[RFC4272]Murphy,S.,“BGP安全漏洞分析”,RFC 4272,DOI 10.17487/RFC4272,2006年1月<http://www.rfc-editor.org/info/rfc4272>.

[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E., and B. Dickson, "Problem Definition and Classification of BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June 2016, <http://www.rfc-editor.org/info/rfc7908>.

[RFC7908]英国斯利拉姆、蒙哥马利、麦克弗森、奥斯特维尔和B.迪克森,“BGP路线泄漏的问题定义和分类”,RFC 7908,DOI 10.17487/RFC7908,2016年6月<http://www.rfc-editor.org/info/rfc7908>.

Appendix A. Transition Considerations for BGP Implementers
附录A.BGP实施者的过渡注意事项

This appendix is not normative.

本附录不规范。

For an implementer, transitioning to a compliant BGP implementation may require a process that can take several years.

对于实施者来说,过渡到兼容的BGP实施可能需要几年的时间。

It is understood and acknowledged that operators who are taking advantage of an undefined behavior will always be surprised by changes to said behavior.

众所周知,利用未定义行为的操作员总是会对所述行为的变化感到惊讶。

A.1. "N+1 N+2" Release Strategy
A.1. “N+1 N+2”发布策略

An implementer could leverage an approach described as the "N+1 and N+2" release strategy. In release N+1, the implementer introduces a new default configuration parameter to indicate that the BGP speaker is operating in "ebgp insecure-mode". In addition to the introduction of the new parameter, an implementer could begin to display informational warnings to the operator that certain parts of the configuration are incomplete. In release N+1, operators of the BGP implementation become aware that a configurable default exists in the implementation, and can prepare accordingly. In release N+2 or later, the inverse of the previous default configuration parameter that was introduced in release N+1 becomes the new default.

实现者可以利用一种称为“N+1和N+2”发布策略的方法。在N+1版中,实现者引入了一个新的默认配置参数,以指示BGP扬声器正在“ebgp不安全模式”下工作。除了引入新参数外,实施者还可以开始向操作员显示信息性警告,说明配置的某些部分不完整。在N+1版中,BGP实现的操作员意识到实现中存在可配置的默认值,并可以相应地进行准备。在N+2版或更高版本中,与N+1版中引入的先前默认配置参数相反的参数将成为新的默认值。

As a result, any new installation of release N+2 will adhere to this document. Installations upgraded from version release N+1 will adhere to the previous insecure behavior, if no modification was made to the "ebgp insecure-mode" configuration parameter.

因此,版本N+2的任何新安装都将遵守本文档。如果未修改“ebgp不安全模式”配置参数,则从版本N+1升级的安装将遵循以前的不安全行为。

Acknowledgments

致谢

The authors would like to thank the following people for their comments, support and review: Shane Amante, Christopher Morrow, Robert Raszuk, Greg Skinner, Adam Chappell, Sriram Kotikalapudi, Brian Dickson, Jeffrey Haas, John Heasley, Ignas Bagdonas, Donald Smith, Alvaro Retana, John Scudder, and Dale Worley.

作者要感谢以下人士的评论、支持和评论:谢恩·阿曼特、克里斯托弗·莫罗、罗伯特·拉祖克、格雷格·斯金纳、亚当·查佩尔、斯里拉姆·科蒂卡拉普迪、布赖恩·迪克森、杰弗里·哈斯、约翰·希斯利、伊格纳斯·巴格多纳斯、唐纳德·史密斯、阿尔瓦罗·雷塔纳、约翰·斯卡德尔和戴尔·沃利。

Contributors

贡献者

The following people contributed to successful deployment of the solution described in this document:

以下人员促成了本文档中所述解决方案的成功部署:

Jakob Heitz Cisco

雅各布海茨思科

   Email: jheitz@cisco.com
        
   Email: jheitz@cisco.com
        

Ondrej Filip CZ.NIC

Ondrej Filip CZ.NIC

   Email: ondrej.filip@nic.cz
        
   Email: ondrej.filip@nic.cz
        

Authors' Addresses

作者地址

Jared Mauch Akamai Technologies 8285 Reese Lane Ann Arbor Michigan 48103 United States of America

Jared Mauch Akamai Technologies 8285 Reese Lane Ann Arbor密歇根48103美利坚合众国

   Email: jared@akamai.com
        
   Email: jared@akamai.com
        

Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ The Netherlands

Job Snijders NTT Communications Theodorus Majofskistraat 100阿姆斯特丹1065 SZ荷兰

   Email: job@ntt.net
        
   Email: job@ntt.net
        

Greg Hankins Nokia 777 E. Middlefield Road Mountain View, CA 94043 United States of America

Greg Hankins诺基亚777美国加利福尼亚州米德尔菲尔德路山景大道东94043号

   Email: greg.hankins@nokia.com
        
   Email: greg.hankins@nokia.com