Internet Engineering Task Force (IETF) W. George
Request for Comments: 8206 Neustar
Updates: 8205 S. Murphy
Category: Standards Track PARSONS, Inc.
ISSN: 2070-1721 September 2017
Internet Engineering Task Force (IETF) W. George
Request for Comments: 8206 Neustar
Updates: 8205 S. Murphy
Category: Standards Track PARSONS, Inc.
ISSN: 2070-1721 September 2017
BGPsec Considerations for Autonomous System (AS) Migration
自治系统（AS）迁移的BGPsec注意事项
Abstract
摘要
This document discusses considerations and methods for supporting and securing a common method for Autonomous System (AS) migration within the BGPsec protocol.
本文档讨论了在BGPsec协议内支持和保护自治系统（AS）迁移通用方法的注意事项和方法。
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 https://www.rfc-editor.org/info/rfc8206.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8206.
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 (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Documentation Note . . . . . . . . . . . . . . . . . . . 3
2. General Scenario . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Considerations . . . . . . . . . . . . . . . . . . . . . 3
3.1. Origin Validation . . . . . . . . . . . . . . . . . . . . 4
3.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Outbound Announcements (PE-->CE) . . . . . . . . . . 5
3.2.2. Inbound Announcements (CE-->PE) . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Outbound (PE-->CE) . . . . . . . . . . . . . . . . . . . 8
5.2. Inbound (CE-->PE) . . . . . . . . . . . . . . . . . . . . 8
5.3. Other Considerations . . . . . . . . . . . . . . . . . . 9
5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
1.2. Documentation Note . . . . . . . . . . . . . . . . . . . 3
2. General Scenario . . . . . . . . . . . . . . . . . . . . . . 3
3. RPKI Considerations . . . . . . . . . . . . . . . . . . . . . 3
3.1. Origin Validation . . . . . . . . . . . . . . . . . . . . 4
3.2. Path Validation . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Outbound Announcements (PE-->CE) . . . . . . . . . . 5
3.2.2. Inbound Announcements (CE-->PE) . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Outbound (PE-->CE) . . . . . . . . . . . . . . . . . . . 8
5.2. Inbound (CE-->PE) . . . . . . . . . . . . . . . . . . . . 8
5.3. Other Considerations . . . . . . . . . . . . . . . . . . 9
5.4. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
A method of managing a BGP Autonomous System Number (ASN) migration is described in RFC 7705 [RFC7705]. Since it concerns the handling of AS_PATH attributes, it is necessary to ensure that the process and features are properly supported in BGPsec [RFC8205] because BGPsec is explicitly designed to protect against changes in the BGP AS_PATH, whether by choice, by misconfiguration, or by malicious intent. It is critical that the BGPsec protocol framework be able to support this operationally necessary tool without creating an unacceptable security risk or exploit in the process.
RFC 7705[RFC7705]中描述了管理BGP自治系统号（ASN）迁移的方法。由于它涉及到AS_路径属性的处理，因此有必要确保BGPsec[RFC8205]中正确支持该流程和功能，因为BGPsec的明确设计旨在防止BGP AS_路径的更改，无论是出于选择、错误配置还是恶意目的。BGPsec协议框架必须能够支持这一操作上必要的工具，而不会在过程中产生不可接受的安全风险或漏洞。
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]所述进行解释。
This document uses ASNs from the range reserved for documentation as described in RFC 5398 [RFC5398]. In the examples used here, they are intended to represent Globally Unique ASNs, not ASNs reserved for private use as documented in Section 10 of RFC 1930 [RFC1930].
本文档使用RFC 5398[RFC5398]中所述文档保留范围内的ASN。在这里使用的示例中，它们旨在表示全球唯一的ASN，而不是RFC 1930[RFC1930]第10节中记录的专用ASN。
This document assumes that the reader has read and understood the ASN migration method discussed in RFC 7705 [RFC7705] including its examples (see Section 2 of the referenced document), as they will be heavily referenced here. The use case being discussed in RFC 7705 [RFC7705] is as follows: For whatever the reason, a provider is in the process of merging two or more ASes, where eventually one subsumes the other(s). BGP AS confederations [RFC5065] are not enabled between the ASes, but a mechanism is being used to modify BGP's default behavior and allow the migrating Provider Edge (PE) router to masquerade as the old ASN for the Provider-Edge-to-Customer-Edge (PE-CE) eBGP (external BGP) session, or to manipulate the AS_PATH, or both. While BGPsec [RFC8205] does have a method to handle standard confederation implementations, it is not applicable in this exact case. This migration requires a slightly different solution in BGPsec than for a standard confederation because unlike in a confederation, eBGP peers may not be peering with the "correct" external ASN, and the forward-signed updates are for a public ASN, rather than a private one; so, there is no expectation that the BGP speaker would strip the affected signatures before propagating the route to its eBGP neighbors.
本文档假设读者已阅读并理解RFC 7705[RFC7705]中讨论的ASN迁移方法，包括其示例（参见参考文档第2节），因为此处将大量引用这些示例。RFC 7705[RFC7705]中讨论的用例如下：无论出于何种原因，提供者正在合并两个或多个ASE，其中一个最终包含另一个。ASE之间未启用BGP AS联盟[RFC5065]，但正在使用一种机制来修改BGP的默认行为，并允许迁移提供商边缘（PE）路由器伪装为提供商边缘到客户边缘（PE-CE）eBGP（外部BGP）会话的旧ASN，或操纵AS_路径，或两者兼而有之。虽然BGPsec[RFC8205]确实有一种方法来处理标准联盟实现，但它不适用于这种情况。此迁移需要在BGPsec中使用与标准联盟稍有不同的解决方案，因为与联盟不同，eBGP对等方可能没有使用“正确”的外部ASN进行对等，并且前向签名更新是针对公共ASN的，而不是针对私有ASN的；因此，在将路由传播到其eBGP邻居之前，BGP说话人不会去除受影响的签名。
In the examples in Section 5.4, AS64510 is being subsumed by AS64500, and both ASNs represent a Service Provider (SP) network (see Figures 1 and 2 in RFC 7705 [RFC7705]). AS64496 and 64499 represent end-customer networks. References to PE, CE, and P routers mirror the diagrams and references in RFC 7705.
在第5.4节的示例中，AS64510被AS64500所包含，两个ASN都代表一个服务提供商（SP）网络（参见RFC 7705[RFC7705]中的图1和图2）。AS64496和64499代表终端客户网络。对PE、CE和P路由器的引用反映了RFC 7705中的图表和引用。
The methods and implementation discussed in RFC 7705 [RFC7705] are widely used during network integrations resulting from mergers and acquisitions, as well as network redesigns; therefore, it is necessary to support this capability on any BGPsec-enabled routers/ ASNs. What follows is a discussion of the potential issues to be considered regarding how ASN migration and BGPsec [RFC8205] validation might interact.
RFC 7705[RFC7705]中讨论的方法和实现在合并和收购以及网络重新设计导致的网络集成期间广泛使用；因此，有必要在任何支持BGPsec的路由器/ASN上支持此功能。以下是关于ASN迁移和BGPsec[RFC8205]验证如何相互作用的潜在问题的讨论。
One of the primary considerations for this document and migration is that service providers (SPs) rarely stop after one
本文档和迁移的主要考虑事项之一是，服务提供商（SP）很少在一次迁移后停止
merger/acquisition/divestiture; they end up accumulating several legacy ASNs over time. Since SPs are using migration methods that are transparent to customers and therefore do not require coordination with customers, they do not have as much control over the length of the transition period as they might with something completely under their administrative control (e.g., a key roll). Because they are not forcing a simultaneous migration (i.e., both ends switch to the new ASN at an agreed-upon time), there is no incentive for a given customer to complete the move from the old ASN to the new one. This leaves many SPs with multiple legacy ASNs that don't go away very quickly, if at all. As solutions were being proposed for Resource Public Key Infrastructure (RPKI) implementations to solve this transition case, the WG carefully considered operational complexity and hardware scaling issues associated with maintaining multiple legacy ASN keys on routers throughout the combined network. While SPs who choose to remain in this transition phase indefinitely invite added risks because of the operational complexity and scaling considerations associated with maintaining multiple legacy ASN keys on routers throughout the combined network, saying "don't do this" is of limited utility as a solution. As a result, this solution attempts to minimize the additional complexity during the transition period, on the assumption that it will likely be protracted. Note that while this document primarily discusses service provider considerations, it is not solely applicable to SPs, as enterprises often migrate between ASNs using the same functionality. What follows is a discussion of origin and path validation functions and how they interact with ASN migrations.
合并/收购/剥离；随着时间的推移，他们最终积累了几个遗留的ASN。由于SP使用的迁移方法对客户是透明的，因此不需要与客户协调，因此他们对过渡期长度的控制不如对完全由其管理控制的内容（例如，关键滚动）的控制。由于他们没有强制同时迁移（即，两端在约定的时间切换到新ASN），因此给定客户没有动力完成从旧ASN到新ASN的迁移。这使得许多SP都有多个传统ASN，即使有，也不会很快消失。由于正在为资源公钥基础设施（RPKI）实施提出解决方案以解决此过渡情况，工作组仔细考虑了与在整个组合网络的路由器上维护多个传统ASN密钥相关的操作复杂性和硬件扩展问题。由于在整个组合网络的路由器上维护多个传统ASN密钥的操作复杂性和可扩展性考虑因素，选择无限期停留在这一过渡阶段的SP会带来额外的风险，而说“不要这样做”作为解决方案的效用有限。因此，该解决方案试图将过渡期内的额外复杂性降至最低，前提是过渡期可能会延长。请注意，虽然本文档主要讨论服务提供商的注意事项，但它并不完全适用于SP，因为企业经常使用相同的功能在ASN之间迁移。下面将讨论源和路径验证函数以及它们如何与ASN迁移交互。
Route Origin Validation as defined by RFC 6480 [RFC6480] does not require modification to enable AS migration, as the existing protocol and procedure allow for a solution. In the scenario discussed in RFC 7705 [RFC7705], AS64510 is being replaced by AS64500. If there are any existing routes originated by AS64510 on the router being moved into the new ASN, new Route Origination Authorizations (ROAs) for the routes with the new ASN should be generated, and they should be treated as new routes to be added to AS64500. However, we also need to consider the situation where one or more other PEs are still in AS64510 and are originating one or more routes that may be distinct from any that the router under migration is originating. PE1 (which is now a part of AS64500 and instructed to use "Replace Old AS" as defined in [RFC7705] to remove AS64510 from the path) needs to be able to properly handle routes originated from AS64510. If the route now shows up as originating from AS64500, any downstream peers' validation check will fail unless a ROA is *also* available for AS64500 as the origin ASN. In addition to generating a ROA for 65400 for any prefixes originated by the router being moved, it may be
RFC 6480[RFC6480]定义的路由源验证不需要修改以启用as迁移，因为现有协议和过程允许解决方案。在RFC 7705[RFC7705]中讨论的场景中，AS64510被AS64500取代。如果在移动到新ASN的路由器上存在AS64510发起的任何现有路由，则应为具有新ASN的路由生成新路由发起授权（ROA），并将其视为新路由添加到AS64500。然而，我们还需要考虑一个或多个其他PES仍然在AS645 10中的情况，并且起源于一个或多个路由，该路由可能不同于正在迁移的路由器所起源的任何路由。PE1（现在是AS64500的一部分，指示使用[RFC7705]中定义的“替换旧AS”从路径中删除AS64510）需要能够正确处理源自AS64510的路由。如果路由现在显示为源于AS64500，则任何下游对等方的验证检查都将失败，除非ROA*也*可作为源ASN用于AS64500。除了为移动的路由器产生的任何前缀生成65400的ROA外，还可以
necessary to generate ROAs for 65400 for prefixes that are originating on routers still in 65410, since the AS replacement function will change the origin AS in some cases. This means that there will be multiple ROAs showing different ASes authorized to originate the same prefixes until all routers originating prefixes from AS64510 are migrated to AS64500. Multiple ROAs of this type are permissible per Section 3.2 of RFC 6480 [RFC6480] so managing origin validation during a migration like this is merely applying the defined case where a set of prefixes are originated from more than one ASN. Therefore, for each ROA that authorizes the old ASN (e.g., AS64510) to originate a prefix, a new ROA MUST also be created that authorizes the replacing ASN (e.g., AS64500) to originate the same prefix.
必须为65410路由器上的前缀生成65400的ROA，因为AS替换功能在某些情况下会更改原点。这意味着将有多个ROA显示不同的ASE被授权发起相同的前缀，直到所有从AS64510发起前缀的路由器迁移到AS64500。根据RFC 6480[RFC6480]第3.2节的规定，这种类型的多个ROA是允许的，因此在这样的迁移过程中管理源验证仅适用于定义的情况，即一组前缀源自多个ASN。因此，对于授权旧ASN（例如AS64510）发起前缀的每个ROA，还必须创建授权替换ASN（例如AS64500）发起相同前缀的新ROA。
BGPsec path validation requires that each router in the AS path cryptographically sign its update to assert that "every Autonomous System (AS) on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route to the subsequent AS in the path" (see Section 1 of RFC 8205 [RFC8205]). Since the referenced AS-migration technique explicitly modifies the AS_PATH between two eBGP peers who are not coordinating with one another (are not in the same administrative domain), no level of trust can be assumed; therefore, it may be difficult to identify legitimate manipulation of the AS_PATH for migration activities when compared to manipulation due to misconfiguration or malicious intent.
BGPsec路径验证要求AS路径中的每个路由器对其更新进行加密签名，以声明“更新消息中列出的ASE路径上的每个自治系统（AS）已明确授权向路径中的后续AS发布路由”（参见RFC 8205[RFC8205]第1节）。由于引用AS迁移技术明确修改了两个相互不协调（不在同一管理域中）的eBGP对等方之间的AS_路径，因此不能假设任何信任级别；因此，与由于错误配置或恶意意图而进行的操作相比，可能很难识别迁移活动对AS_路径的合法操作。
When PE1 is moved from AS64510 to AS64500, it will be provisioned with the appropriate keys for AS64500 to allow it to forward-sign routes using AS64500. However, there is no guidance in the BGPsec protocol specification [RFC8205] on whether or not the forward-signed ASN value is required to match the configured remote AS to validate properly. That is, if CE1's BGP session is configured as "remote AS 64510", the presence of "local AS 64510" on PE1 will ensure that there is no ASN mismatch on the BGP session itself, but if CE1 receives updates from its remote neighbor (PE1) forward-signed from AS64500, there is no guidance as to whether the BGPsec validator on CE1 still considers those valid by default. Section 6.3 of RFC 4271 [RFC4271] mentions this match between the ASN of the peer and the AS_PATH data, but it is listed as an optional validation, rather than a requirement. We cannot assume that this mismatch will be allowed by vendor implementations, so using it as a means to solve this migration case is likely to be problematic.
当PE1从AS64510移动到AS64500时，它将为AS64500提供适当的密钥，以允许它使用AS64500转发标志路由。但是，BGPsec协议规范[RFC8205]中没有关于是否需要前向签名ASN值来匹配配置的远程AS以正确验证的指导。也就是说，如果CE1的BGP会话配置为“远程as 64510”，PE1上的“本地as 64510”将确保BGP会话本身没有ASN不匹配，但是如果CE1从其远程邻居（PE1）接收到来自AS64500的前向签名更新，对于CE1上的BGPsec验证器是否仍默认认为这些有效，没有任何指导。RFC 4271[RFC4271]的第6.3节提到对等方的ASN和AS_路径数据之间的匹配，但它被列为可选验证，而不是要求。我们不能假设供应商的实现会允许这种不匹配，因此使用它作为解决这种迁移情况的手段可能会有问题。
Inbound is more complicated, because the CE doesn't know that PE1 has changed ASNs, so it is forward-signing all of its routes with AS64510, not AS64500. The BGPsec speaker cannot manipulate previous signatures and therefore cannot manipulate the previous AS path without causing a mismatch that will invalidate the route. If the updates are simply left intact, the ISP would still need to publish and maintain valid and active public keys for AS 64510 if it is to appear in the BGPsec_PATH signature so that receivers can validate that the BGPsec_PATH signature arrived intact/whole. However, if the updates are left intact, this will cause the AS path length to be increased, which is unacceptable as discussed in RFC 7705 [RFC7705].
入站更复杂，因为CE不知道PE1已经更改了ASN，所以它正在使用AS64510而不是AS64500对其所有路由进行前向签名。BGPsec演讲者无法操纵以前的签名，因此无法操纵以前的AS路径，而不会导致不匹配，从而使路由无效。如果更新保持不变，则如果AS 64510要出现在BGPsec_路径签名中，ISP仍需要发布和维护其有效和活动的公钥，以便接收方可以验证BGPsec_路径签名是否完整/完整到达。但是，如果更新保持不变，这将导致AS路径长度增加，如RFC 7705[RFC7705]中所述，这是不可接受的。
In order to be deployable, any solution to the described problem needs to consider the following requirements, listed in no particular order. BGPsec:
为了能够部署，对所描述的问题的任何解决方案需要考虑以下要求，不按特定顺序列出。BGPsec：
o MUST support AS migration for both inbound and outbound route announcements (see Sections 3.2.1 and 3.2.2), without reducing BGPsec's protections for route path.
o 必须支持入站和出站路由公告的AS迁移（见第3.2.1和3.2.2节），而不降低BGPsec对路由路径的保护。
o MUST NOT require any reconfiguration on the remote eBGP neighbor (CE).
o 不得要求在远程eBGP邻居（CE）上进行任何重新配置。
o SHOULD NOT require global (i.e., network-wide) configuration changes to support migration. The goal is to limit required configuration changes to the devices (PEs) being migrated.
o 不应要求更改全局（即网络范围）配置以支持迁移。目标是限制对正在迁移的设备（PE）所需的配置更改。
o MUST NOT lengthen the AS path during migration.
o 迁移期间不得延长AS路径。
o MUST operate within existing trust boundaries, e.g., can't expect remote side to accept pCount=0 (see Section 4.2 of RFC 8205 [RFC8205]) from untrusted/non-confederation neighbor.
o 必须在现有信任边界内运行，例如，不能期望远程端接受来自不受信任/非联盟邻居的pCount=0（参见RFC 8205[RFC8205]第4.2节）。
As noted in Section 4.2 of RFC 8205 [RFC8205], BGPsec already has a solution for hiding ASNs where increasing the AS path length is undesirable. So a simple solution would be to retain the keys for AS64510 on PE1 and forward-sign towards CE1 with AS64510 and pCount=0. However, this would mean passing a pCount=0 between two ASNs that are in different administrative and trust domains such that it could represent a significant attack vector to manipulate BGPsec-signed paths. The expectation for legitimate instances of pCount=0 (to make a route server that is not part of the transit path
如RFC 8205[RFC8205]第4.2节所述，BGPsec已经有了一个解决方案，可以在不需要增加As路径长度的情况下隐藏ASN。因此，一个简单的解决方案是在PE1上保留AS64510的密钥，并使用AS64510和pCount=0向CE1前进。然而，这意味着在不同的管理域和信任域之间传递两个ASN之间的pCube＝0，使得它可以代表一个重要的攻击向量来操纵BGPSEC签名的路径。pCount的合法实例的期望值=0（使路由服务器不是传输路径的一部分
invisible) is that there is some sort of existing trust relationship between the operators of the route server and the downstream peers such that the peers could be explicitly configured by policy to accept pCount=0 announcements only on the sessions where they are expected. For the same reason that things like "Local AS" [RFC7705] are used for ASN migration without end-customer coordination, it is unrealistic to assume any sort of coordination between the SP and the administrators of CE1 to ensure that they will by policy accept pCount=0 signatures during the transition period; therefore, this is not a workable solution.
不可见）是指路由服务器的操作员与下游对等方之间存在某种现有的信任关系，因此可以通过策略显式配置对等方，以便仅在预期的会话上接受pCount=0通知。由于“Local AS”[RFC7705]之类的东西用于ASN迁移而无需最终客户协调的原因，假设SP和CE1管理员之间进行任何形式的协调以确保他们在过渡期内根据策略接受pCount=0签名是不现实的；因此，这不是一个可行的解决办法。
A better solution presents itself when considering how to handle routes coming from the CE toward the PE, where the routes are forward-signed to AS64510, but will eventually need to show AS64500 in the outbound route announcement. Because both AS64500 and AS64510 are in the same administrative domain, a signature from AS64510 forward-signed to AS64500 with pCount=0 would be acceptable as it would be within the appropriate trust boundary so that each BGP speaker could be explicitly configured to accept pCount=0 where appropriate between the two ASNs. At the very simplest, this could potentially be used at the eBGP boundary between the two ASNs during migration. Since the AS_PATH manipulation described above usually happens at the PE router on a per-session basis and does not happen network-wide simultaneously, it is not generally appropriate to apply this AS-hiding technique across all routes exchanged between the two ASNs, as it may result in routing loops and other undesirable behavior. Therefore, the most appropriate place to implement this is on the local PE that still has eBGP sessions with peers expecting to peer with AS64510 (using the transition mechanisms detailed in RFC 7705 [RFC7705]). Since that PE has been moved to AS64500, it is not possible for it to forward-sign AS64510 with pCount=0 without some minor changes to the BGPsec behavior to address this use case.
在考虑如何处理从CE到PE的路由时，会出现一个更好的解决方案，在PE中，路由被转发到AS64510，但最终需要在出站路由公告中显示AS64500。因为AS64500和AS64510都在同一个管理域中，所以可以接受从AS64510向AS64500转发签名且pCount=0的签名，因为该签名将位于适当的信任边界内，因此每个BGP演讲者可以显式配置为在两个ASN之间适当地接受pCount=0。在最简单的情况下，这可能在迁移期间用于两个ASN之间的eBGP边界。由于上述AS_路径操作通常在PE路由器上以每会话为基础发生，并且不会在网络范围内同时发生，因此通常不适合在两个asn之间交换的所有路由上应用此AS隐藏技术，因为它可能导致路由循环和其他不良行为。因此，实现这一点最合适的地方是在本地PE上，该PE仍然与期望与AS64510对等的对等方进行eBGP会话（使用RFC 7705[RFC7705]中详述的转换机制）。由于该PE已被移动到AS64500，因此在不对BGPsec行为进行一些微小更改以解决此用例的情况下，它不可能转发pCount=0的AS64510。
AS migration is using AS_PATH and remote AS manipulation to act as if a PE under migration exists simultaneously in both ASNs even though it is only configured with one global ASN. This document describes applying a similar technique to the BGPsec signatures generated for routing updates processed through this migration machinery. Each routing update that is received from or destined to an eBGP neighbor that is still using the old ASN (64510) will be signed twice, once with the ASN to be hidden and once with the ASN that will remain visible. In essence, we are treating the update as if the PE had an internal BGP hop and the update was passed across an eBGP session between AS64500 and AS64510, configured to use and accept pCount=0, while eliminating the processing and storage overhead of creating an actual eBGP session between the two ASNs within the PE router. This will result in a properly secured AS path in the affected route updates, because the PE router will be provisioned with valid keys
AS迁移使用AS_路径和远程AS操作，就像迁移中的PE同时存在于两个ASN中一样，即使它只配置了一个全局ASN。本文档描述了将类似技术应用于为通过此迁移机制处理的路由更新而生成的BGPsec签名。从仍在使用旧ASN（64510）的eBGP邻居接收或发送到该邻居的每个路由更新将被签名两次，一次是要隐藏的ASN，一次是要保持可见的ASN。本质上，我们将更新视为PE具有内部BGP跃点，更新通过AS64500和AS64510之间的eBGP会话传递，配置为使用和接受pCount=0，同时消除了在PE路由器内的两个ASN之间创建实际eBGP会话的处理和存储开销。这将导致受影响路由更新中的AS路径得到正确保护，因为PE路由器将配置有效密钥
for both AS64500 and AS64510. An important distinction here is that while AS migration under standard BGP4 is manipulating the AS_PATH attribute, BGPsec uses an attribute called the "Secure_Path" (see Section 3.1 of RFC 8205 [RFC8205]) and BGPsec-capable neighbors do not exchange AS_PATH information in their route announcements. However, a BGPsec neighbor peering with a non-BGPsec-capable neighbor will use the information found in the Secure_Path to reconstruct a standard AS_PATH for updates sent to that neighbor. Unlike in the Secure_Path where the ASN to be hidden is still present but ignored when considering the AS path (due to pCount=0), when reconstructing an AS_PATH for a non-BGPsec neighbor, the pCount=0 ASNs will not appear in the AS_PATH at all (see Section 4.4 of RFC 8205 [RFC8205]). This document is not changing existing AS_PATH reconstruction behavior, merely highlighting it for clarity.
适用于AS64500和AS64510。这里一个重要的区别是，标准BGP4下的AS迁移操作AS_路径属性时，BGPsec使用一个称为“安全_路径”的属性（请参见RFC 8205[RFC8205]第3.1节），并且支持BGPsec的邻居不会在其路由公告中交换AS_路径信息。但是，与不支持BGPsec的邻居进行对等的BGPsec邻居将使用在安全_路径中找到的信息来重建标准AS_路径，以便向该邻居发送更新。在安全_路径中，要隐藏的ASN仍然存在，但在考虑AS路径时被忽略（由于pCount=0），与此不同，当为非BGPsec邻居重建AS_路径时，pCount=0 ASN将根本不会出现在AS_路径中（参见RFC 8205[RFC8205]第4.4节）。本文档并没有改变现有的AS_路径重建行为，只是为了清晰起见对其进行了强调。
The procedure to support AS migration in BGPsec is slightly different depending on whether the PE under migration is receiving the routes from one of its eBGP peers ("inbound" as in Section 3.2.2) or destined toward the eBGP peers ("outbound" as in Section 3.2.1).
BGPsec中支持AS迁移的程序略有不同，这取决于正在迁移的PE是从其一个eBGP对等方接收路由（“入站”如第3.2.2节所述）还是指向eBGP对等方（“出站”如第3.2.1节所述）。
When a PE router receives an update destined for an eBGP neighbor that is locally configured with AS-migration mechanisms as discussed in RFC 7705 [RFC7705], it MUST generate a valid BGPsec signature as defined in RFC 8205 [RFC8205] for _both_ configured ASNs. It MUST generate a signature from the new (global) ASN forward-signing to the old (local) ASN with pCount=0, and then it MUST generate a forward signature from the old (local) ASN to the target eBGP ASN with pCount=1 as normal.
当PE路由器接收到以本地配置为AS迁移机制的eBGP邻居（如RFC 7705[RFC7705]中所述）为目的地的更新时，它必须为两个配置的ASN生成RFC 8205[RFC8205]中定义的有效BGPsec签名。它必须生成从新（全局）ASN到旧（本地）ASN（pCount=0）的前向签名，然后它必须生成从旧（本地）ASN到目标eBGP ASN（pCount=1）的前向签名。
When a PE router receives an update from an eBGP neighbor that is locally configured with AS-migration mechanisms (i.e., the opposite direction of the previous route flow), it MUST generate a signature from the old (local) ASN forward-signing to the new (global) ASN with pCount=0. It is not necessary to generate the second signature from the new (global) ASN because the Autonomous System Border Router (ASBR) will generate that when it forward-signs towards its eBGP peers as defined in normal BGPsec operation. Note that a signature is not normally added when a routing update is sent across an iBGP (internal BGP) session. The requirement to sign updates in iBGP represents a change to the normal behavior for this specific AS-migration scenario only.
当PE路由器从本地配置了AS迁移机制的eBGP邻居接收到更新时（即，先前路由流的相反方向），它必须生成从旧（本地）ASN前向签名到新（全局）ASN的签名，pCount=0。无需从新（全局）ASN生成第二个签名，因为自治系统边界路由器（ASBR）将在向其eBGP对等方转发签名时生成该签名，如正常BGPsec操作中所定义。请注意，当通过iBGP（内部BGP）会话发送路由更新时，通常不会添加签名。在iBGP中对更新进行签名的要求仅代表对该特定AS迁移场景的正常行为的更改。
In the inbound case discussed in Section 5.2, the PE is adding BGPsec attributes to routes received from or destined to an iBGP neighbor and using pCount=0 to mask them. While this is not prohibited by BGPsec [RFC8205], BGPsec-capable routers that receive updates from BGPsec-enabled iBGP neighbors MUST accept updates with new (properly formed) BGPsec attributes, including the presence of pCount=0 on a previous signature, or they will interfere with this method. In a similar fashion, any BGPsec-capable route-reflectors in the path of these updates MUST reflect them transparently to their BGPsec-capable clients.
在第5.2节讨论的入站情况中，PE将BGPsec属性添加到从iBGP邻居接收或发送到iBGP邻居的路由中，并使用pCount=0来屏蔽它们。虽然BGPsec[RFC8205]并未禁止这一点，但从启用BGPsec的iBGP邻居接收更新的支持BGPsec的路由器必须接受具有新（正确格式）BGPsec属性的更新，包括先前签名中存在的pCount=0，否则它们将干扰此方法。以类似的方式，这些更新路径中的任何支持BGPsec的路由反射器必须向支持BGPsec的客户端透明地反映它们。
In order to secure this set of signatures, the PE router MUST be provisioned with valid keys for _both_ configured ASNs (old and new), and the key for the old ASN MUST be kept valid until all eBGP sessions are migrated to the new ASN. Downstream neighbors will see this as a valid BGPsec path, as they will simply trust that their upstream neighbor accepted pCount=0 because it was explicitly configured to do so based on a trust relationship and business relationship between the upstream and its neighbor (the old and new ASNs).
为了保护这组签名，PE路由器必须为配置的ASN（旧ASN和新ASN）提供有效密钥，并且旧ASN的密钥必须保持有效，直到所有eBGP会话迁移到新ASN。下游邻居会将此视为有效的BGPsec路径，因为他们只会信任其上游邻居接受pCount=0，因为它是根据上游与其邻居（旧ASN和新ASN）之间的信任关系和业务关系显式配置的。
Additionally, Section 4 of RFC 7705 [RFC7705] discusses methods in which AS migrations can be completed for iBGP peers such that a session between two routers will be treated as iBGP even if the neighbor ASN is not the same ASN on each peer's global configuration. As far as BGPsec is concerned, this requires the same procedure as when the routers migrating are applying AS-migration mechanisms to eBGP peers, but the router functioning as the "ASBR" between old and new ASN is different. In eBGP, the router being migrated has direct eBGP sessions to the old ASN and signs from old ASN to new with pCount=0 before passing the update along to additional routers in its global (new) ASN. In iBGP, the router being migrated is receiving updates (that may have originated either from eBGP neighbors or other iBGP neighbors) from its downstream neighbors in the old ASN and MUST sign those updates from old ASN to new with pCount=0 before sending them on to other peers.
此外，RFC 7705[RFC7705]的第4节讨论了可以为iBGP对等方完成AS迁移的方法，以便两个路由器之间的会话将被视为iBGP，即使相邻ASN与每个对等方的全局配置上的ASN不同。就BGPsec而言，这需要与迁移路由器作为迁移机制应用于eBGP对等点时相同的过程，但作为新旧ASN之间的“ASBR”的路由器是不同的。在eBGP中，正在迁移的路由器具有到旧ASN的直接eBGP会话，并在将更新传递到其全局（新）ASN中的其他路由器之前，以pCount=0从旧ASN签名到新ASN。在iBGP中，正在迁移的路由器正在从其旧ASN中的下游邻居接收更新（可能来自eBGP邻居或其他iBGP邻居），并且在将这些更新发送到其他对等方之前，必须使用pCount=0将这些更新从旧ASN签名为new。
The following example will illustrate the method being used above. As with previous examples, PE1 is the router being migrated, AS64510 is the old ASN, which is being subsumed by AS64500, the ASN to be permanently retained. 64505 is another external peer, used to demonstrate what the announcements will look like to a third-party peer that is not part of the migration. Some additional notation is used to delineate the details of each signature as follows:
下面的示例将说明上面使用的方法。与前面的示例一样，PE1是要迁移的路由器，AS64510是旧ASN，它被AS64500所包含，ASN将被永久保留。64505是另一个外部对等点，用于演示在不属于迁移一部分的第三方对等点看来公告是什么样子。使用一些附加符号来描述每个签名的细节，如下所示：
The origin BGPsec Signature Segment takes the form: sig(Target ASN, (pCount,...,Origin ASN), NLRI) key.
原始BGPsec签名段的形式为：sig（目标ASN，（pCount，…，原始ASN），NLRI）密钥。
Intermediate BGPsec Signature Segments take the form: sig(Target ASN,...,(pCount,...,Signer ASN),...,NLRI) key.
中间BGPsec签名段的形式为：sig（目标ASN，…（pCount，…，签名者ASN），…，NLRI）密钥。
(pCount,...,ASN) refers to the new Secure_Path Segment added to the BGPsec_PATH attribute by the ASN (Origin ASN or Signer ASN).
（pCount，…，ASN）指由ASN（原始ASN或签名者ASN）添加到BGPsec_路径属性的新安全_路径段。
"Equivalent AS_PATH" refers to what the AS_PATH would look like if it was reconstructed to be sent to a non-BGPsec peer, while the Securedpath shows the AS path as represented between BGPsec peers.
“等效AS_路径”是指如果AS_路径被重建为发送到非BGPsec对等方，则AS_路径的外观，而Securedpath显示BGPsec对等方之间表示的AS路径。
Note: The representation of Signature Segment generation is being simplified here somewhat for the sake of brevity; the actual details of the signing process are as described in Sections 4.1 and 4.2 of [RFC8205]. For example, what is covered by the signature also includes Flags, Algorithm Suite Identifier, NLRI length, etc. Also, the key is not carried in the update; instead, the Subject Key Identifier (SKI) is carried.
注意：为了简洁起见，这里对签名段生成的表示进行了一些简化；签署过程的实际细节如[RFC8205]第4.1节和第4.2节所述。例如，签名涵盖的内容还包括标志、算法套件标识符、NLRI长度等。此外，更新中未携带密钥；相反，携带主题密钥标识符（SKI）。
Before Merger
合并前
64505
|
ISP B ISP A
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
64505
|
ISP B ISP A
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH= (64510,64500,64499)
Securedpath=(64510,64500,64499)
length=sum(pCount)=3
PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(64510,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH= (64510,64500,64499)
Securedpath=(64510,64500,64499)
length=sum(pCount)=3
Migrating, route flow outbound PE-1 to CE-1
迁移，将出站PE-1路由到CE-1
64505
|
ISP A' ISP A'
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
64505
|
ISP A' ISP A'
CE-1 <--- PE-1 <------------------- PE-2 <--- CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
CE-2 to PE-2: sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64499)
Securedpath=(64499)
length=sum(pCount)=1
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64500,64499)
Securedpath=(64500,64499)
length=sum(pCount)=2
PE-2 to PE-1: sig(64500, (pCount=1,...,64499), N)K_64499-CE2 Equivalent AS_PATH=(64499) Securedpath=(64499) length=sum(pCount)=1 #PE-2 sends to PE-1 (in iBGP) the exact same update #as it received from AS64499.
PE-2到PE-1:sig（64500，（pCount=1，…，64499），N）K_64499-CE2等价于_PATH=（64499）Securedpath=（64499）length=sum（pCount）=1，PE-2向PE-1（在iBGP中）发送与从AS64499接收到的完全相同的更新。
PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(64510,...,(pCount=0,...,64500),...,N)K_64500-PE2 (*)
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64510,64499)
Securedpath=(64510, 64500 (pCount=0),64499)
length=sum(pCount)=2 (length is NOT 3)
#PE-1 adds the Secure_Path Segment in (*) acting as AS64500
#PE-1 accepts (*) with pCount=0 acting as AS64510,
#as it would if it received (*) from an eBGP peer
PE-1 to CE-1: sig(64496,...,(pCount=1,...,64510),...,N)K_64510-PE1
sig(64510,...,(pCount=0,...,64500),...,N)K_64500-PE2 (*)
sig(64500, (pCount=1,...,64499), N)K_64499-CE2
Equivalent AS_PATH=(64510,64499)
Securedpath=(64510, 64500 (pCount=0),64499)
length=sum(pCount)=2 (length is NOT 3)
#PE-1 adds the Secure_Path Segment in (*) acting as AS64500
#PE-1 accepts (*) with pCount=0 acting as AS64510,
#as it would if it received (*) from an eBGP peer
Migrating, route flow inbound CE-1 to PE-1
迁移，将入站CE-1路由到PE-1
64505
|
ISP A' ISP A'
CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
64505
|
ISP A' ISP A'
CE-1 ---> PE-1 -------------------> PE-2 ---> CE-2
64496 Old_ASN: 64510 Old_ASN: 64500 64499
New_ASN: 64500 New_ASN: 64500
CE-1 to PE-1: sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496)
Securedpath=(64496)
length=sum(pCount)=1
CE-1 to PE-1: sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496)
Securedpath=(64496)
length=sum(pCount)=1
PE-1 to PE-2: sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1 (**)
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496)
Securedpath=(64510 (pCount=0),64496)
length=sum(pCount)=1 (length is NOT 2)
#PE-1 adds the Secure_Path Segment in (**) acting as AS64510
#PE-1 accepts (**) with pCount=0 acting as AS64500,
#as it would if it received (**) from an eBGP peer
#PE-1, as AS64500, sends the update including (**) to PE-2 (in iBGP)
PE-1 to PE-2: sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1 (**)
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64496)
Securedpath=(64510 (pCount=0),64496)
length=sum(pCount)=1 (length is NOT 2)
#PE-1 adds the Secure_Path Segment in (**) acting as AS64510
#PE-1 accepts (**) with pCount=0 acting as AS64500,
#as it would if it received (**) from an eBGP peer
#PE-1, as AS64500, sends the update including (**) to PE-2 (in iBGP)
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496)
Securedpath=(64500,64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)
PE-2 to 64505: sig(64505,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496)
Securedpath=(64500,64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)
PE-2 to CE-2: sig(64499,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496)
Securedpath=(64500, 64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)
PE-2 to CE-2: sig(64499,...,(pCount=1,...,64500),...,N)K_64500-PE2
sig(64500,...,(pCount=0,...,64510),...,N)K_64510-PE1
sig(64510, (pCount=1,...,64496), N)K_64496-CE1
Equivalent AS_PATH=(64500,64496)
Securedpath=(64500, 64510 (pCount=0), 64496)
length=sum(pCount)=2 (length is NOT 3)
This document does not require any IANA actions.
本文件不要求IANA采取任何行动。
RFC 7705 [RFC7705] discusses a process by which one ASN is migrated into and subsumed by another. Because this process involves manipulating the AS_Path in a BGP route to make it deviate from the actual path that it took through the network, this migration process is attempting to do exactly what BGPsec is working to prevent. BGPsec MUST be able to manage this legitimate use of AS_Path manipulation without generating a vulnerability in the RPKI route security infrastructure, and this document was written to define the method by which the protocol can meet this need.
RFC7705[RFC7705]讨论了一个ASN迁移到另一个ASN并被另一个ASN包含的过程。由于此过程涉及操纵BGP路由中的AS_路径，使其偏离通过网络的实际路径，因此此迁移过程正试图执行BGPsec正努力阻止的操作。BGPsec必须能够管理AS_路径操纵的合法使用，而不会在RPKI路由安全基础设施中产生漏洞，编写本文档旨在定义协议满足这一需求的方法。
The solution discussed above is considered to be reasonably secure from exploitation by a malicious actor because it requires both signatures to be secured as if they were forward-signed between two eBGP neighbors. This requires any router using this solution to be provisioned with valid keys for both the migrated and subsumed ASN so that it can generate valid signatures for each of the two ASNs it is adding to the path. If the AS's keys are compromised, or zero-length keys are permitted, this does potentially enable an AS_PATH shortening attack, but these are existing security risks for BGPsec.
上面讨论的解决方案被认为是合理安全的，不会被恶意参与者利用，因为它要求两个签名都被保护，就像它们是在两个eBGP邻居之间进行前向签名一样。这要求使用此解决方案的任何路由器都为迁移和包含的ASN提供有效密钥，以便它可以为添加到路径的两个ASN中的每一个生成有效签名。如果AS的密钥被泄露，或者允许使用零长度密钥，这可能会导致AS_路径缩短攻击，但这些都是BGPsec存在的安全风险。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC7705] George, W. and S. Amante, "Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute", RFC 7705, DOI 10.17487/RFC7705, November 2015, <https://www.rfc-editor.org/info/rfc7705>.
[RFC7705]George，W.和S.Amante，“自主系统迁移机制及其对BGP AS_路径属性的影响”，RFC 7705，DOI 10.17487/RFC77052015年11月<https://www.rfc-editor.org/info/rfc7705>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8205] Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8205]Lepinski，M.，Ed.和K.Sriram，Ed.，“BGPsec协议规范”，RFC 8205，DOI 10.17487/RFC8205，2017年9月<https://www.rfc-editor.org/info/rfc8105>.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996, <https://www.rfc-editor.org/info/rfc1930>.
[RFC1930]霍金森，J.和T.贝茨，“自主系统（AS）的创建、选择和注册指南”，BCP 6，RFC 1930，DOI 10.17487/RFC1930，1996年3月<https://www.rfc-editor.org/info/rfc1930>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc4271>.
[RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 5065, DOI 10.17487/RFC5065, August 2007, <https://www.rfc-editor.org/info/rfc5065>.
[RFC5065]Traina，P.，McPherson，D.，和J.Scudder，“BGP自治系统联合会”，RFC 5065，DOI 10.17487/RFC5065，2007年8月<https://www.rfc-editor.org/info/rfc5065>.
[RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for Documentation Use", RFC 5398, DOI 10.17487/RFC5398, December 2008, <https://www.rfc-editor.org/info/rfc5398>.
[RFC5398]Huston，G.“文件使用的自主系统（AS）号码保留”，RFC 5398，DOI 10.17487/RFC5398，2008年12月<https://www.rfc-editor.org/info/rfc5398>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6480]Lepinski，M.和S.Kent，“支持安全互联网路由的基础设施”，RFC 6480，DOI 10.17487/RFC6480，2012年2月<https://www.rfc-editor.org/info/rfc6480>.
Acknowledgements
致谢
Thanks to Kotikalapudi Sriram, Shane Amante, Warren Kumari, Terry Manderson, Keyur Patel, Alia Atlas, and Alvaro Retana for their review comments.
感谢Kotikalapudi Sriram、Shane Amante、Warren Kumari、Terry Manderson、Keyur Patel、Alia Atlas和Alvaro Retana的评论。
The authors particularly wish to acknowledge Kotikalapudi Sriram, Oliver Borchert, and Michael Baer for their review and suggestions for the examples in Section 5.4, which made an important contribution to the quality of the text.
作者特别希望感谢Kotikalapudi Sriram、Oliver Borchert和Michael Baer对第5.4节示例的审查和建议，这对文本质量做出了重要贡献。
Additionally, the solution presented in this document is an amalgam of several Secure Inter-Domain Routing (SIDR) interim meeting discussions plus a discussion at IETF 85, collected and articulated thanks to Sandy Murphy.
此外，本文档中介绍的解决方案是几个安全域间路由（SIDR）临时会议讨论和IETF 85讨论的混合体，这些讨论是Sandy Murphy收集和阐述的。
Authors' Addresses
作者地址
Wesley George Neustar 45980 Center Oak Plaza Sterling, VA 20166 United States of America
威斯利乔治纽斯达45980中心奥克广场斯特林，弗吉尼亚州20166美利坚合众国
Email: wesgeorge@puck.nether.net
Email: wesgeorge@puck.nether.net
Sandy Murphy PARSONS, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 United States of America
桑迪·墨菲·帕森斯公司，美国马里兰州哥伦比亚塞缪尔·莫尔斯大道7110号，邮编：21046
Phone: +1 443-430-8000
Email: sandy@tislabs.com
Phone: +1 443-430-8000
Email: sandy@tislabs.com