stc-isp资源_部署RPKI之前需要考虑的事情-ISP的Internet资源认证

RPKI is a good tool for the Internet community. However, it is not a small topic to cover. I just want to summarize here what you should consider before deploying RPKI for your network. Especially for ISP networks.

RPKI是Internet社区的好工具。 但是，这不是一个小话题。 我只想在此总结在为网络部署RPKI之前应考虑的事项。 特别是对于ISP网络。

简称RPKI (RPKI in short)

Too much information about RPKI on the Internet. In short, I guess the sentence below clearly explains what RPKI is for:

Internet上有关RPKI的信息过多。 简而言之，我想下面的句子清楚地说明了RPKI的作用：

RPKI allows network operators to digitally encrypt and sign routing advertisements in Border Gateway Protocol (BGP) by using a system of private and public keys. Information can be encrypted and signed with a private key and can only be decrypted, or have its signature verified, using the matching public key. Digitally signing information provides assurance that routing advertisements seen in the routing system can be verified and are authentic. (from: APNIC )

RPKI允许网络运营商通过使用私钥和公钥系统对边界网关协议(BGP)中的路由广告进行数字加密和签名。 信息可以使用私钥进行加密和签名，并且只能使用匹配的公钥进行解密或验证其签名。 数字签名信息可确保在路由系统中看到的路由广告可以被验证并且是真实的 。 (来自： APNIC )

You can find pretty much all information about RPKI at Read the Docs maintained by NLnet Labs.

您可以在阅读文档中找到有关RPKI的几乎所有信息。 由...维护 NLnet实验室 。

RPKI是用于...的工具 (RPKI is a Tool for...)

What Internet Service Providers (ISP) want to achieve in their Autonomous System(AS) network is simply each node(router) in the network is able to perform Route Origin Validation(ROV) using RPKI to make proper BGP routing decisions based on one simple fact: a route is originated from an ASN.

Internet服务提供商(ISP)想要在其自治系统(AS)网络中实现的目标仅仅是网络中的每个节点(路由器)都能够使用RPKI执行路由源验证(ROV)，从而基于一个简单的步骤做出正确的 BGP路由决策实际上： 路由源自ASN 。

RPKI有什么用？ (What is RPKI useful for?)

It plays a role to prevent global routing issues caused by Route hijacking. RPKI is a tool that allows you to validate the legitimate origin of a route. Origin only. Not the whole AS path. You might think this is a limitation of RPKI. But I think this is more than enough if you believe the Internet has to be dynamic and free from a single point of governance. Route hijacking is out of topic here. Please check https://www.manrs.org/2020/04/not-just-another-bgp-hijack/ to get a taste of route hijacking.

它起着防止由路由劫持引起的全局路由问题的作用。 RPKI是一种工具，可用于验证路由的合法来源。 仅起源。 不是整个AS路径。 您可能会认为这是RPKI的局限性。 但是，我认为，如果您认为互联网必须是动态的并且不受单点治理的话，这已经绰绰有余。 路由劫持不在这里。 请检查https://www.manrs.org/2020/04/not-just-another-bgp-hijack/以了解路线劫持的情况。

如何生成有效的原始数据以及将有效数据保存在RPKI中的位置 (How valid origin data is generated and where the validated data is kept in RPKI)

It all starts from creating a Route Origin Authorization (ROA) of each IPv4/6 prefix by its number resource holder. The sentence below clearly explains what ROA is in short.

这一切都始于其号码资源持有者为每个IPv4 / 6前缀创建路由来源授权(ROA)。 下面的句子清楚地说明了ROA的简称。

A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. (from RFC 6482)

ROA是一种数字签名的对象，它提供一种方法来验证IP地址块所有者已授权自治系统(AS)发起到该地址块内一个或多个前缀的路由。 (来自RFC 6482 )

Technically a ROA is an object holding two key information: ASN authorized to originate routes within a Prefix Range. Below is an example showing a ROA object created/signed by its number resource holder who is Amazon (AS16509). In other words, this ROA says if anyone sees 2.59.128.0/22 originated from AS16509 on the Internet then you are safe to consider the origin of the prefix is valid. If the prefix is originated from other ASN, it is safer to disregard it right away as there is a 99.9% possibility that the prefix is hijacked. The only possible exceptional case I can think of is the number resource holder is a bit lazy to update the ROA on time.

从技术上讲，ROA是持有两个关键信息的对象：被授权在前缀范围内发起路由的ASN 。 以下示例显示了ROA对象，该对象由其编号资源所有者(亚马逊(AS16509))创建/签名。 换句话说，该ROA表示，如果有人在互联网上看到2.59.128.0/22源自AS16509，则可以安全地认为前缀的来源有效。 如果该前缀源自其他ASN，则立即忽略它会更安全，因为存在99.9％的前缀被劫持的可能性。 我能想到的唯一可能的例外情况是，数字资源持有者有点懒于按时更新ROA。

There is another field called Trust Anchors in the above table. A Trust Anchor (TA) is a Public Key Infrastructure (PKI) terminology and you just consider it as a root certificate issuer. (PKI is not a topic here so I don’t want to go further about that.) Simply speaking, The owner of prefix 2.59.128.0/22 created and validated the ROA above in RIPE NCC PRKI, one of top root certificate issuers on Internet number resources, and the ROA is kept in a repository managed by the RIPE NCC PRKI.

上表中还有另一个字段，称为“ 信任锚 ”。 信任锚(TA)是公钥基础结构(PKI)术语，您只是将其视为根证书颁发者。 (这里不是PKI的主题，因此，我不想进一步介绍它。)简单地说，前缀2.59.128.0/22的所有者在RIPE NCC PRKI中创建并验证了上面的ROA，RIPE NCC PRKI是该站点上顶级根证书颁发者之一Internet号码资源，并且ROA保留在RIPE NCC PRKI管理的存储库中。

Technically it is not that simple to understand because it is based on Public Key Infrastructure (PKI). However, conceptually it is quite straight forward as you see. No rocket science at all.

从技术上讲，它不是那么简单，因为它基于公钥基础结构(PKI)。 但是，从概念上讲，这很简单。 根本没有火箭科学。

We now know a valid route origin data is generated and where that data is kept. The next question is, then, how I can get the whole list of ROAs from repositories managed by Trust Anchors. More specifically. Where are those repositories anyway? What is the protocol to communicate with those repositories?

现在我们知道将生成有效的路线起点数据并将其保存在何处。 那么，下一个问题是，如何从Trust Anchors管理的存储库中获取全部ROA列表。 进一步来说。 这些存储库在哪里？ 与那些存储库通信的协议是什么？

如何将有效的原始数据提供给路由器 (How valid origin data is served to routers)

There is a component called a Relying Party(RP) in the RPKI system. A Relying Party is commonly called as an RPKI validator. An RPKI validator in RPKI system (1)gathers ROA data from the distributed RPKI repositories from each Trust Anchors(TA) using either rsync or RRDP protocole, (2)validates each entry’s signature against TA to build a Validated Cache, and then (3)serves routers with validated route origins through The Resource Public Key Infrastructure (RPKI) to Router Protocol (RFC 8210) — or RTR Protocol for short. Simply speaking, an RPKI validator plays an interface role in an RPKI system providing route validation (RV) record (a simplified version of ROAs) to routers connected to the Internet. Routers get their RV record database updated periodically from RPKI validators using RTR protocol.

RPKI系统中有一个称为依赖方(RP)的组件。 依赖方通常称为RPKI验证器 。 RPKI系统中的RPKI验证器(1)使用rsync或RRDP协议从每个Trust Anchors(TA)收集来自每个Trust Anchors(TA)的分布式RPKI存储库中的ROA数据，(2)针对TA验证每个条目的签名以构建Validated Cache，然后(3 )通过资源公共密钥基础结构(RPKI)到路由器协议 ( RFC 8210 )或简称为RTR协议为具有经过验证的路由起源的路由器提供服务。 简而言之，RPKI验证器在RPKI系统中扮演接口角色，向连接到Internet的路由器提供路由验证(RV)记录 (ROA的简化版本)。 路由器使用RTR协议定期从RPKI验证器获取其RV记录数据库。

Now you know you need RPKI validators when you want to apply RPKI to your ASN. Where are RPKI validators then? Should we deploy our own RPKI validators on our premises? Is there any public one for the benefit of all Internet community? Let’s dig into these questions more.

现在，当您要将RPKI应用于ASN时，就需要RPKI验证器。 RPKI验证器在哪里？ 我们是否应该在自己的场所中部署自己的RPKI验证器？ 有没有一个公共网站可以使整个互联网社区受益？ 让我们进一步探讨这些问题。

部署委托的RPKI系统 (Deploying Delegated RPKI system)

You could run our own whole RPKI system but this is not the option that you probably want to go with. Running your own Certificate Authority(CA) for a small ISP can take up too much unnecessary operation resources.

您可以运行我们自己的整个RPKI系统，但这不是您可能想要的选择。 为小型ISP运行自己的证书颁发机构(CA)可能会占用过多不必要的操作资源。

Here’s a recommendation saying avoiding running your own Delegated RPKI system.

建议您避免运行自己的Delegated RPKI系统。

The five RIRs provide a Hosted RPKI system, so why would I want to run a Delegated RPKI system myself instead?

这五个RIR提供了一个托管RPKI系统，为什么我要自己运行一个委托的RPKI系统呢？

The RPKI system was designed to be a distributed system, allowing each organisation to run their own CA and publish the certificate and ROAs themselves. The hosted RIR systems are in place to offer a low entry barrier into the system, allowing operators to gain operational experience before deciding if they want to run their own CA.

RPKI系统设计为分布式系统，允许每个组织运行自己的CA并自己发布证书和ROA。 托管的RIR系统到位以降低进入系统的门槛，使运营商可以在决定是否要运行自己的CA之前获得操作经验。

For many operators, the hosted system will be good enough, also in the long term. However, organisations who for example don’t want to be dependent on a web interface for management, who manage address space across multiple RIR regions, or have BGP automation in place that they would like to integrate with ROA management, can all choose to run a CA on their own systems. (from: https://nlnetlabs.nl/projects/rpki/faq/)

对于许多运营商而言，从长远来看，托管系统将足够好。 但是，例如那些不想依赖于Web界面进行管理的组织，不想管理多个RIR区域中的地址空间，或者希望将其与ROA管理集成在一起的BGP自动化的组织都可以选择运行在自己系统上的CA。 (摘自： https : //nlnetlabs.nl/projects/rpki/faq/ )

In other words, the deployment of our own RPKI Validators is more than enough.

换句话说，部署我们自己的RPKI验证程序已绰绰有余。

部署内部ROA验证程序还是仅使用公共验证程序？ (Deploy in-house ROA validators or simply use public one?)

You can’t rely on public validators at this time of writing this article. If the service went down, your nodes are no longer able to validate route origins anymore. For example, InternetNZ seems running an open RPKI validator for the internet community as shown on their website:

在撰写本文时，您不能依赖公共验证器。 如果服务中断，您的节点将不再能够验证路由来源。 例如，InternetNZ似乎在其网站上显示了针对Internet社区运行的开放式RPKI验证器：

The registry provides a free and openly available RPKI Validator for Internet operators to use. validator.rpki.net.nz contains all the RIR trust anchors and provides an interface to discover the status of ROAs. It uses open source software written by RIPE NCC (from https://registry.internetnz.nz/services/rpki/)

But the validator(validator.rpki.net.nz) is not accessible from our test router:

但是验证器( validator.rpki.net.nz )无法从我们的测试路由器访问：

seungisp01@lab-re0:isp01# run show validation sessionSession                                  State   Flaps     Uptime #IPv4/IPv6 records103.254.156.144                          Connect     0            0/0

Here’s another thought on this(from: https://nlnetlabs.nl/projects/rpki/faq/)

这是对此的另一种想法(来自： https : //nlnetlabs.nl/projects/rpki/faq/ )

Should I run a validator myself, when I can use an external data source I found on the Internet?

当我可以使用在Internet上找到的外部数据源时，是否应该自己运行验证程序？

The value of signing the authoritative statements about routing intent by the resource holder comes from being able to validate that the data is authentic and has not been tampered with in any way.

由资源持有者签署有关路由意图的权威性声明的价值在于能够验证数据是真实的并且没有以任何方式被篡改。

When you outsource the validation to a third party, you lose the certainty of data accuracy and authenticity. Conceptually, this is similar to DNSSEC validation, which is best done by a local trusted resolver.

当您将验证外包给第三方时，您将失去数据准确性和真实性的确定性。 从概念上讲，这类似于DNSSEC验证，最好由本地受信任的解析程序完成。

Section 3 of RFC 7115 has an extensive section on this specific topic.

RFC 7115的第3节对这个特定主题有一个广泛的部分。

I agree with this point to some extent until we get a local trusted RPKI validator service. Deploying your own validator is probably the only option because there are no reliable RPKI validator service providers at the moment.

在获得本地信任的RPKI验证器服务之前，我在某种程度上同意这一点。 部署您自己的验证器可能是唯一的选择，因为目前没有可靠的RPKI验证器服务提供者。

您在ROA验证程序部署上有哪些软件选项？ (What software options do you have on ROA Validator deployment?)

Thanks to the Internet community, there is open-source software. You don’t need to write your own codes. Here are some options below that are well known and being used.

多亏了Internet社区，才有了开源软件。 您无需编写自己的代码。 以下是一些众所周知的和正在使用的选项。

• Very Active: https://github.com/RIPE-NCC/rpki-validator-3

  非常活跃： https ： //github.com/RIPE-NCC/rpki-validator-3

• Very Active: https://github.com/NLnetLabs/routinator

  非常活跃： https ： //github.com/NLnetLabs/routinator

• Active: https://github.com/NICMx/FORT-validator

  活动： https ： //github.com/NICMx/FORT-validator

• Not Active: https://github.com/cloudflare/cfrpki

  无效： https ： //github.com/cloudflare/cfrpki

• Not Active: https://github.com/dragonresearch/rpki.net/

  无效： https ： //github.com/dragonresearch/rpki.net/

• etc…
  等等…

You can try one of each and make your final decision on which software is good for your environment. If you ask my opinion on that, I would say Cloudflare RPKI toolkit could be a good choice. It seems only one contributor from Cloudflare has been updating the code. For this reason, I would say the project is inactive. However, some points attract me. First, Cloudflare & NTT is using the software for its global BB network to validate route origins. In other words, the code has been field-proven at least for over one year for a global anycast network and a Tier-1 IP network. Second, the architecture of Cloudflare RPKI toolkit separates the validator into two parts: validation process(called OctoRPKI), and RTR communication handling process(called GoRTR).

您可以尝试其中一种，并最终决定哪种软件适合您的环境。 如果您对此提出意见，我会说Cloudflare RPKI工具包可能是一个不错的选择。 似乎只有Cloudflare的一名贡献者正在更新代码。 因此，我要说这个项目是不活跃的。 但是，有些观点吸引了我。 首先，Cloudflare＆NTT正在使用其全球BB网络的软件来验证路线起点。 换句话说， 该代码已针对全球任播网络和Tier-1 IP网络进行了至少一年的现场验证 。 其次，Cloudflare RPKI工具包的体系结构将验证器分为两部分：验证过程(称为OctoRPKI)和RTR通信处理过程(称为GoRTR)。

OctoRPKI does not embed a RTR server. Since generating list of ROAs takes a lot of compute time, it was designed separate the distribution of files from the cryptographic operations (from: https://github.com/cloudflare/cfrpki)

OctoRPKI不嵌入RTR服务器。 由于生成ROA列表需要大量的计算时间，因此它被设计为将文件的分发与加密操作分开(来自： https : //github.com/cloudflare/cfrpki )

Thanks to the separation of validation from RTR handling, you could have the flexibility of deployment. For example, you might just deploy two OctoRPKI instances for redundancy purposes in one region. Independently from the region of OctoRPKI, you could deploy as many as GoRTRs in other regions where your routers are. Your operational burden can be minimized. Lastly, Go programming language is used which is one of the widely used software languages recently. This means you or someone could easily contribute to the open-source and modify some parts if required to meet your own taste.

由于将验证与RTR处理分开，因此您可以灵活地进行部署。 例如，出于冗余目的，您可能只在一个区域中部署两个OctoRPKI实例。 与OctoRPKI区域无关，您可以在路由器所在的其他区域中部署多达GoRTR。 您的运营负担可以最小化。 最后，使用Go编程语言 ，它是最近被广泛使用的软件语言之一。 这意味着您或某人可以根据自己的喜好轻松地为开源做出贡献并修改某些部分。

Now you know how to deploy your own RPKI validators to meet your requirement. Then now what. Your routers…

现在，您知道如何部署自己的RPKI验证器来满足您的要求。 那现在呢 您的路由器...

如何使用有效的路由来源更新ASN中的每个节点？ (How to get each node in ASN updated with valid route origins?)

Technically every single router in an ASN needs to get route validation (RV) entries updated regularly either by (1) communicating directly with an RPKI Validator or through (2) the BGP community attribute from iBGP peers that have a direct session with an RPKI validator. Which way is better? Either way seems okay but you need to consider some factors before making a final decision on this.

从技术上讲，ASN中的每个路由器都需要通过以下方式定期更新路由验证( RV)条目：(1)直接与RPKI验证器通信，或者通过(2)来自与RPKI验证器有直接会话的iBGP对等体的BGP团体属性。 哪种方法更好？ 两种方法都可以，但是您需要对此进行最后决定之前要考虑一些因素。

在将RPKI应用于骨干之前要考虑的事项 (Things to Consider before Applying RPKI to Your Backbone)

验证缓存中的ROA数量 (Number of ROAs in Validated Cache)

The number of valid ROAs from an Octorpki process can be different from the number of valid ROAs from other open-source RPKI validators. There could be two reasons for this: each RPKI validator keeps different numbers of repositories and an issue with accessing repositories while syncing ROAs. This does not mean the current ROAs in the cache is not valid. However, you need to be aware of this situation when applying RPKI to your BB. If your team has engineers who have software skills then you could find a way to fetch all valid ROAs from all repositories from all Trusted Anchors to keep all nodes in ASN with up-to-date valid RV data.

来自Octorpki进程的有效ROA的数量可以不同于来自其他开源RPKI验证器的有效ROA的数量。 可能有两个原因：每个RPKI验证器保留不同数量的存储库，以及在同步ROA时访问存储库的问题。 这并不意味着高速缓存中的当前ROA无效。 但是，将RPKI应用于BB时，您需要注意这种情况。 如果您的团队拥有具备软件技能的工程师，那么您可以找到一种从所有受信任的锚从所有存储库中获取所有有效ROA的方法，以使所有节点都具有最新的有效RV数据保持在ASN中。

ROA过期 (Expired ROAs)

A registered ROA needs to get renewed when it expires.

注册的ROA到期时需要更新。

Once a ROA expires, it becomes invalid ROA at an RPKI validator and removed from the RPKI validator’s cache. This means routers in ASN do not receive the expired ROA anymore at the next sync. Of course, the validation state of the prefix changes from valid to unknow in your router after the sync cycle.

ROA过期后，它将在RPKI验证器上变为无效的ROA，并从RPKI验证器的缓存中删除。 这意味着ASN中的路由器在下一次同步时不再收到过期的ROA。 当然，同步周期后，路由器中前缀的验证状态将从有效更改为未知 。

If a ROA is cryptographically invalid, will it make my route invalid?

如果ROA在密码上无效，是否会使我的路由无效？

An invalid ROA means that the object did not pass cryptographic validation and is therefore discarded. The statement about routing that was made within the ROA is simply not taken into consideration. An invalid route on the other hand, is the result of a valid ROA, specifically one that had the outcome that a prefix is announced from an unauthorised AS or the announcement is more specific than is allowed by the maximum length set in a ROA that matches the prefix and AS (from https://nlnetlabs.nl/projects/rpki/faq/)

无效的ROA意味着该对象未通过密码验证，因此被丢弃 。 根本没有考虑在ROA中做出的有关路由的声明。 另一方面，无效路由是有效ROA的结果，特别是导致未经授权的AS宣布前缀或该声明比ROA中设置的最大长度匹配所允许的更具体的结果前缀和AS(来自https://nlnetlabs.nl/projects/rpki/faq/ )

Some of Trust Anchors renew expired ROAs automatically as you can see the table below at this time of writing.

您可以在撰写本文时看到下表，其中一些信任锚自动更新过期的ROA。

验证状态：有效，无效和未知 (Validation State: Valid, Invalid, and Unknown)

You need to understand the meaning of each state. Especially Invalid state.

您需要了解每种状态的含义。 尤其是无效状态。

• Valid: The route announcement is covered by at least one ROA
  有效：路线公告至少包含一个ROA

• Invalid: The prefix is announced from an (1) unauthorized AS or the announcement is (2) more specific than is allowed by the maximum length set in a ROA that matches the prefix and AS

  无效 ：前缀是从(1) 未经授权的自治系统宣布的，或者该公告的定义(2) 比与前缀和自治系统匹配的ROA中设置的最大长度所允许的范围大

• NotFound: The prefix in this announcement is not covered (or only partially covered) by an existing ROA
  NotFound：现有ROA不覆盖(或仅部分覆盖)此公告中的前缀

You need to note that Invalid state covers “more specific than is allowed by the maximum length set in a ROA that matches the prefix and AS” as well. This means that a prefix received from a peer can have an invalid state when the received prefix matching the prefix and AS is longer than the maximum length covered by a registered ROA.

您需要注意，无效状态还包括“ 比 ROA中设置的与前缀和AS匹配的最大长度所允许的更具体的状态”。 这意味着，当接收到的与前缀和AS相匹配的前缀比已注册的ROA覆盖的最大长度长时，从对等体收到的前缀可能会处于无效状态。

For example, a ROA is registered to authorize 202.9.112.0/22 (with max length 22) originated from AS23918 at APNIC TA. 202.9.112.0/23 will be invalid when a peer advertises 202.9.112.0/23 because the max length of the ROA covering the prefix is 22.

例如，ROA已注册以授权源自APNIC TA的AS23918的202.9.112.0/22( 最大长度为22 )。 当对端发布202.9.112.0/ 23时，202.9.112.0/ 23将无效，因为覆盖前缀的ROA的最大长度为22。

Because of this reason, ISPs make sure that their customers should register ROAs covering all prefixes that are to be advertised.

由于这个原因，ISP确保其客户应注册ROA，以涵盖要宣传的所有前缀。

RPKI验证程序不可用时 (When RPKI Validator becomes unavailable)

When RPKI Validator becomes unavailable, all the validation state of valid prefixes become unknown.

当RPKI验证程序不可用时，所有有效前缀的验证状态将变为unknown 。

For example, in Junos validation-state of 1.34.0.0/16 changes from

例如，在1.34.0.0/16的Junos验证状态下，

1.34.0.0/16        *[BGP/170] 1w1d 04:57:39, localpref 100AS path: 23918 2914 3462 I, validation-state: valid> to 202.9.112.62 via ge-4/0/9.0

to

至

1.34.0.0/16        *[BGP/170] 1w1d 04:57:03, localpref 100AS path: 23918 2914 3462 I, validation-state: unknown> to 202.9.112.62 via ge-4/0/9.0

if the session to an RPKI validator goes down and remains down for the record-lifetime (seconds).

如果到RPKI验证器的会话中断，并且在记录生存期 (秒)内保持断开状态。

For this reason, a redundant RPKI validator is required in case when the primary validator went down. Otherwise, the validation state of all BGP routes could become unknown all at once and it could affect your BGP policies and services.

因此，如果主验证器发生故障，则需要冗余的RPKI验证器。 否则，所有BGP路由的验证状态都可能立即变为未知，并且可能影响您的BGP策略和服务。

路由器重启，通过iBGP进行前缀交换，然后获取有效ROA。 (Router Reboot, Prefix Exchange via iBGP, and then Valid ROAs fetched in.)

Using BGP communities to exchange route validity with iBGP peers can cause an issue in your backbone network. There is a case when a router fails to exchange validation-state of prefixes. Think about a situation: A router with an RPKI session reboots for some reason and finishes prefix exchange with iBGP peers before valid ROAs are fetched in. All prefixes exchanged will have an unknown validation state.

使用BGP社区与iBGP对等体交换路由有效性可能会在骨干网中引起问题。 在某些情况下，路由器无法交换前缀的验证状态 。 考虑以下情况：具有RPKI会话的路由器出于某种原因重新启动，并在获取有效ROA之前完成与iBGP对等方的前缀交换。所有交换的前缀将具有未知的验证状态。

BAD IDEA: You can use a community attribute to announce and receive the validation state of a prefix between external BGP (EBGP) and internal BGP (iBGP) peers.

错误的想法：您可以使用团体属性来宣布和接收外部BGP(EBGP)与内部BGP(iBGP)对等之间的前缀的验证状态。

from https://www.juniper.net/documentation/en_US/junos/topics/topic-map/bgp_origin_validation.html#id-example-configuring-origin-validation-for-bgp

来自https://www.juniper.net/documentation/zh_CN/junos/topics/topic-map/bgp_origin_validation.html#id-example-configuring-origin-validation-for-bgp

考虑万物...我认为你需要 (Considering All Things... I think You need)

• At least two validators (servicing in a different network from each other, if possible) for redundancy.
  至少两个验证器(如果可能，在彼此不同的网络中服务)以实现冗余。
• Each node in your ASN makes sessions to primary/secondary validators instead of using BGP communities.
  ASN中的每个节点都与主要/辅助验证者进行会话，而不是使用BGP社区。

Make sense?

合理？

最后，一个好的路由决策可能是 (Lastly, A good Routing Decision might be)

Simply rejecting all invalid routes can affect customers. Some invalid prefixes could be valid in some situations.

仅仅拒绝所有无效路线会影响客户。 一些无效的前缀在某些情况下可能是有效的。

• A customer may need to temporarily or urgently advertise a prefix which is more specific than is allowed by the maximum length set in a ROA. For example, to trigger RTBH service against an IPv4 /32.

  客户可能需要临时或紧急地发布比 ROA中设置的最大长度所允许的更具体的前缀。 例如，针对IPv4 / 32触发RTBH服务。

• What else?
  还有什么？

For this reason, you might want to consider Ignore Filters or/and Whitelist explained at RIPE RPKI information page below:

因此，您可能需要考虑忽略过滤器或/和白名单 ，这些信息在下面的RIPE RPKI信息页面中进行了说明：

Ignore Filters

忽略过滤器

Because you are always in complete control of your routing decisions, you have the option to override the ROA dataset with your local controls. The first option you have is to apply an ignore filter. By adding an entry, the Validator will ignore any RPKI prefixes that overlap with the filter’s prefix. It will be as if a ROA never existed for this particular prefix.

由于您始终可以完全控制路由决策，因此可以选择使用本地控件覆盖ROA数据集。 您的第一个选择是应用忽略过滤器。 通过添加条目，验证器将忽略与过滤器前缀重叠的任何RPKI前缀。 就好像该特定前缀从未存在过ROA。

Whitelist

白名单

By adding a white list entry, you can manually authorize an ASN to originate a prefix in addition to validated ROAs from the repository. Please note that white list entries may invalidate announcements for this prefix from other ASNs, just like ROAs. Please use this feature with caution and check the side effects that may result from your white list entry.

通过添加白名单条目，除了可以从存储库中验证ROA之外，还可以手动授权ASN生成前缀。 请注意，白名单条目可能会使其他ASN发出的此前缀公告无效，就像ROA一样。 请谨慎使用此功能，并检查白名单条目可能产生的副作用。

(from: https://www.ripe.net/manage-ips-and-asns/resource-management/certification/using-published-rpki-data)

(摘自： https : //www.ripe.net/manage-ips-and-asns/resource-management/certification/using-published-rpki-data )

Like prefix filtering, RPKI is a tool you need to introduce into your IP backbone to keep the Internet healthy for people!

像前缀过滤一样， RPKI是您需要引入IP主干中的工具，以确保人们的互联网健康！