Internet Engineering Task Force (IETF) D. Ma
Request for Comments: 8416 ZDNS
Category: Standards Track D. Mandelberg
ISSN: 2070-1721 Unaffiliated
T. Bruijnzeels
NLnet Labs
August 2018
Internet Engineering Task Force (IETF) D. Ma
Request for Comments: 8416 ZDNS
Category: Standards Track D. Mandelberg
ISSN: 2070-1721 Unaffiliated
T. Bruijnzeels
NLnet Labs
August 2018
Simplified Local Internet Number Resource Management with the RPKI (SLURM)
使用RPKI（SLURM）简化本地Internet号码资源管理
Abstract
摘要
The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. Network operators, e.g., Internet Service Providers (ISPs), can use the RPKI to validate BGP route origin assertions. ISPs can also use the RPKI to validate the path of a BGP route. However, ISPs may want to establish a local view of exceptions to the RPKI data in the form of local filters and additions. The mechanisms described in this document provide a simple way to enable INR holders to establish a local, customized view of the RPKI, overriding global RPKI repository data as needed.
资源公钥基础设施（RPKI）是一种全球授权基础设施，允许互联网号码资源（INR）持有者对这些资源做出可验证的声明。网络运营商，例如互联网服务提供商（ISP），可以使用RPKI验证BGP路由来源声明。ISP还可以使用RPKI验证BGP路由的路径。但是，ISP可能希望以本地过滤器和添加的形式建立RPKI数据异常的本地视图。本文档中描述的机制提供了一种简单的方法，使INR持有者能够建立RPKI的本地自定义视图，并根据需要覆盖全局RPKI存储库数据。
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/rfc8416.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8416.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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 ....................................................3
1.1. Terminology ................................................4
2. RP with SLURM ...................................................4
3. SLURM Files and Mechanisms ......................................5
3.1. Use of JSON ................................................5
3.2. SLURM File Overview ........................................5
3.3. Validation Output Filters ..................................6
3.3.1. Validated ROA Prefix Filters ........................6
3.3.2. BGPsec Assertion Filters ............................7
3.4. Locally Added Assertions ...................................9
3.4.1. ROA Prefix Assertions ...............................9
3.4.2. BGPsec Assertions ..................................10
3.5. Example of a SLURM File with Filters and Assertions .......11
4. SLURM File Configuration .......................................13
4.1. SLURM File Atomicity ......................................13
4.2. Multiple SLURM Files ......................................13
5. IANA Considerations ............................................14
6. Security Considerations ........................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................16
Acknowledgments ...................................................17
Authors' Addresses ................................................17
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. RP with SLURM ...................................................4
3. SLURM Files and Mechanisms ......................................5
3.1. Use of JSON ................................................5
3.2. SLURM File Overview ........................................5
3.3. Validation Output Filters ..................................6
3.3.1. Validated ROA Prefix Filters ........................6
3.3.2. BGPsec Assertion Filters ............................7
3.4. Locally Added Assertions ...................................9
3.4.1. ROA Prefix Assertions ...............................9
3.4.2. BGPsec Assertions ..................................10
3.5. Example of a SLURM File with Filters and Assertions .......11
4. SLURM File Configuration .......................................13
4.1. SLURM File Atomicity ......................................13
4.2. Multiple SLURM Files ......................................13
5. IANA Considerations ............................................14
6. Security Considerations ........................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................16
Acknowledgments ...................................................17
Authors' Addresses ................................................17
The Resource Public Key Infrastructure (RPKI) is a global authorization infrastructure that allows the holder of Internet Number Resources (INRs) to make verifiable statements about those resources. For example, the holder of a block of IP(v4 or v6) addresses can issue a Route Origin Authorization (ROA) [RFC6482] to authorize an Autonomous System (AS) to originate routes for that block. Internet Service Providers (ISPs) can then use the RPKI to validate BGP routes. (Validation of the origin of a route is described in [RFC6811], and validation of the path of a route is described in [RFC8205].)
资源公钥基础设施（RPKI）是一种全球授权基础设施，允许互联网号码资源（INR）持有者对这些资源做出可验证的声明。例如，IP（v4或v6）地址块的持有者可以发出路由起始授权（ROA）[RFC6482]来授权自治系统（AS）为该块起始路由。然后，Internet服务提供商（ISP）可以使用RPKI验证BGP路由。（路由原点的验证在[RFC6811]中描述，路由路径的验证在[RFC8205]中描述。）
However, an RPKI Relying Party (RP) may want to override some of the information expressed via configured Trust Anchors (TAs) and the certificates downloaded from the RPKI repository system. For instance, [RFC6491] recommends the creation of ROAs that would invalidate public routes for reserved and unallocated address space, yet some ISPs might like to use BGP and the RPKI with private address space (see [RFC1918], [RFC4193], and [RFC6598]) or private AS numbers (see [RFC1930] and [RFC6996]). Local use of private address space and/or AS numbers is consistent with the RFCs cited above, but such use cannot be verified by the global RPKI. This motivates creation of mechanisms that enable a network operator to publish, at its discretion, an exception to the RPKI in the form of filters and additions (for its own use and that of its customers). Additionally, a network operator might wish to make use of a local override capability to protect routes from adverse actions [RFC8211], until the results of such actions have been addressed. The mechanisms developed to provide this capability to network operators are hereby called "Simplified Local Internet Number Resource Management with the RPKI (SLURM)".
但是，RPKI依赖方（RP）可能希望覆盖通过配置的信任锚（TA）和从RPKI存储库系统下载的证书表示的一些信息。例如，[RFC6491]建议创建ROA，这将使保留和未分配地址空间的公共路由无效，但一些ISP可能希望使用BGP和RPKI，并使用专用地址空间（请参见[RFC1918]、[RFC4193]和[RFC6598]）或专用AS号码（请参见[RFC1930]和[RFC6996]）。专用地址空间和/或AS号码的本地使用与上述RFC一致，但这种使用无法由全局RPKI验证。这促使创建机制，使网络运营商能够自行决定以过滤和添加的形式发布RPKI的例外情况（供其自身和客户使用）。此外，网络运营商可能希望利用本地覆盖功能保护路由免受不利操作[RFC8211]，直到此类操作的结果得到解决。为向网络运营商提供此功能而开发的机制在此称为“使用RPKI（SLURM）的简化本地互联网号码资源管理”。
SLURM allows an operator to create a local view of the global RPKI by generating sets of assertions. For origin validation [RFC6811], an assertion is a tuple of {IP prefix, prefix length, maximum length, Autonomous System Number (ASN)} as used by the RPKI-Router protocol, version 0 [RFC6810] and version 1 [RFC8210]. For BGPsec [RFC8205], an assertion is a tuple of {ASN, subject key identifier, router public key} as used by version 1 of the RPKI-Router protocol. (For the remainder of this document, these assertions are called "ROA Prefix Assertions" and "BGPsec Assertions", respectively.)
SLURM允许操作员通过生成断言集来创建全局RPKI的本地视图。对于源验证[RFC6811]，断言是RPKI路由器协议版本0[RFC6810]和版本1[RFC8210]使用的{IP前缀、前缀长度、最大长度、自治系统号（ASN）}的元组。对于BGPsec[RFC8205]，断言是RPKI路由器协议版本1使用的{ASN，主题密钥标识符，路由器公钥}的元组。（对于本文档的其余部分，这些断言分别称为“ROA前缀断言”和“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]所述进行解释。
SLURM provides a simple way to enable an RP to establish a local, customized view of the RPKI, overriding RPKI repository data if needed. To that end, an RP with SLURM filters out (i.e., removes from consideration for routing decisions) any assertions in the RPKI that are overridden by local ROA Prefix Assertions and BGPsec Assertions.
SLURM提供了一种简单的方法，使RP能够建立RPKI的本地自定义视图，并在需要时覆盖RPKI存储库数据。为此，带有SLURM的RP过滤掉（即，从路由决策的考虑中删除）RPKI中被本地ROA前缀断言和BGPsec断言覆盖的任何断言。
In general, the primary output of an RP is the data it sends to routers over the RPKI-Router protocol [RFC8210]. The RPKI-Router protocol enables routers to query an RP for all assertions it knows about (Reset Query) or for an update of only the changes in assertions (Serial Query). The mechanisms specified in this document are to be applied to the result set for a Reset Query and to both the old and new sets that are compared for a Serial Query. RP software may modify other forms of output in comparable ways, but that is outside the scope of this document.
通常，RP的主要输出是通过RPKI路由器协议[RFC8210]发送到路由器的数据。RPKI路由器协议使路由器能够查询RP中它知道的所有断言（重置查询）或仅更新断言中的更改（串行查询）。本文档中指定的机制将应用于重置查询的结果集以及串行查询中比较的新旧集。RP软件可能以类似的方式修改其他形式的输出，但这不在本文件的范围内。
+--------------+ +---------------------------+ +------------+
| | | | | |
| Repositories +--->Local cache of RPKI objects+---> Validation |
| | | | | |
+--------------+ +---------------------------+ +-----+------+
|
+-------------------------------------------------+
|
+------v-------+ +------------+ +-----------+ +-------------+
| | | | | | | |
| SLURM +---> SLURM +--->RPKI-Router+---> BGP Speakers|
| Filters | | Assertions | | Protocol | | |
+--------------+ +------------+ +-----------+ +-------------+
+--------------+ +---------------------------+ +------------+
| | | | | |
| Repositories +--->Local cache of RPKI objects+---> Validation |
| | | | | |
+--------------+ +---------------------------+ +-----+------+
|
+-------------------------------------------------+
|
+------v-------+ +------------+ +-----------+ +-------------+
| | | | | | | |
| SLURM +---> SLURM +--->RPKI-Router+---> BGP Speakers|
| Filters | | Assertions | | Protocol | | |
+--------------+ +------------+ +-----------+ +-------------+
Figure 1: SLURM's Position in the RP Stack
图1:SLURM在RP堆栈中的位置
SLURM filters and assertions are specified in JSON format [RFC8259]. JSON members that are not defined here MUST NOT be used in SLURM files. An RP MUST consider any deviations from the specifications to be errors. Future additions to the specifications in this document MUST use an incremented value for the "slurmVersion" member.
SLURM筛选器和断言以JSON格式[RFC8259]指定。此处未定义的JSON成员不得在SLURM文件中使用。RP必须考虑任何偏离规格的错误。本文档中规范的未来添加必须使用“slurmVersion”成员的递增值。
A SLURM file consists of a single JSON object containing the following members:
SLURM文件由单个JSON对象组成，其中包含以下成员：
o A "slurmVersion" member that MUST be set to 1, encoded as a number
o 必须设置为1的“slurmVersion”成员，编码为数字
o A "validationOutputFilters" member (Section 3.3), whose value is an object. The object MUST contain exactly two members:
o “validationOutputFilters”成员（第3.3节），其值为对象。对象必须正好包含两个成员：
* A "prefixFilters" member, whose value is described in Section 3.3.1.
* “prefixFilters”成员，其值在第3.3.1节中描述。
* A "bgpsecFilters" member, whose value is described in Section 3.3.2.
* “bgpsecFilters”成员，其值在第3.3.2节中描述。
o A "locallyAddedAssertions" member (Section 3.4), whose value is an object. The object MUST contain exactly two members:
o “locallyAddedAssertions”成员（第3.4节），其值为对象。对象必须正好包含两个成员：
* A "prefixAssertions" member, whose value is described in Section 3.4.1.
* “prefixAssertions”成员，其值在第3.4.1节中描述。
* A "bgpsecAssertions" member, whose value is described in Section 3.4.2.
* “bgpsecAssertions”构件，其值见第3.4.2节。
In the envisioned typical use case, an RP uses both Validation Output Filters and Locally Added Assertions. In this case, the resulting assertions MUST be the same as if output filtering were performed before locally adding assertions; that is, Locally Added Assertions MUST NOT be removed by output filtering.
在设想的典型用例中，RP使用验证输出过滤器和本地添加的断言。在这种情况下，生成的断言必须与在本地添加断言之前执行输出过滤相同；也就是说，输出筛选不能删除本地添加的断言。
The following JSON structure with JSON members represents a SLURM file that has no filters or assertions:
以下包含JSON成员的JSON结构表示没有筛选器或断言的SLURM文件：
{
"slurmVersion": 1,
"validationOutputFilters": {
"prefixFilters": [],
"bgpsecFilters": []
},
"locallyAddedAssertions": {
"prefixAssertions": [],
"bgpsecAssertions": []
}
}
{
"slurmVersion": 1,
"validationOutputFilters": {
"prefixFilters": [],
"bgpsecFilters": []
},
"locallyAddedAssertions": {
"prefixAssertions": [],
"bgpsecAssertions": []
}
}
Figure 2: Empty SLURM File
图2：空SLURM文件
The RP can configure zero or more Validated ROA Prefix Filters ("Prefix Filters" for short). Each Prefix Filter can contain either an IPv4 or IPv6 prefix and/or an ASN. It is RECOMMENDED that an explanatory comment is included with each Prefix Filter so that it can be shown to users of the RP software.
RP可以配置零个或多个已验证的ROA前缀过滤器（简称“前缀过滤器”）。每个前缀筛选器可以包含IPv4或IPv6前缀和/或ASN。建议在每个前缀过滤器中包含解释性注释，以便向RP软件的用户显示。
The above is expressed as a value of the "prefixFilters" member, as an array of zero or more objects. Each object MUST contain either 1) one of the following members or 2) one of each of the following members.
上述内容表示为“prefixFilters”成员的值，表示为零个或多个对象的数组。每个对象必须包含1）以下成员之一或2）以下成员之一。
o A "prefix" member, whose value is a string representing either an IPv4 prefix (see Section 3.1 of [RFC4632]) or an IPv6 prefix (see [RFC5952]).
o “前缀”成员，其值是表示IPv4前缀（参见[RFC4632]第3.1节）或IPv6前缀（参见[RFC5952]）的字符串。
o An "asn" member, whose value is a number.
o “asn”成员，其值为数字。
In addition, each object MAY contain one optional "comment" member, whose value is a string.
此外，每个对象可能包含一个可选的“comment”成员，其值为字符串。
The following example JSON structure represents a "prefixFilters" member with an array of example objects for each use case listed above:
以下示例JSON结构表示一个“prefixFilters”成员，其中包含上面列出的每个用例的示例对象数组：
"prefixFilters": [
{
"prefix": "192.0.2.0/24",
"comment": "All VRPs encompassed by prefix"
},
{
"asn": 64496,
"comment": "All VRPs matching ASN"
},
{
"prefix": "198.51.100.0/24",
"asn": 64497,
"comment": "All VRPs encompassed by prefix, matching ASN"
}
]
"prefixFilters": [
{
"prefix": "192.0.2.0/24",
"comment": "All VRPs encompassed by prefix"
},
{
"asn": 64496,
"comment": "All VRPs matching ASN"
},
{
"prefix": "198.51.100.0/24",
"asn": 64497,
"comment": "All VRPs encompassed by prefix, matching ASN"
}
]
Figure 3: "prefixFilters" Examples
图3：“PrefixFilter”示例
Any Validated ROA Payload (VRP) [RFC6811] that matches any configured Prefix Filter MUST be removed from the RP's output.
必须从RP的输出中删除与任何配置的前缀过滤器匹配的任何已验证ROA有效负载（VRP）[RFC6811]。
A VRP is considered to match with a Prefix Filter if one of the following cases applies:
如果下列情况之一适用，则认为VRP与前缀过滤器匹配：
1. If the Prefix Filter only contains an IPv4 or IPv6 prefix, the VRP is considered to match the filter if the VRP prefix is equal to or covered by the Prefix Filter prefix.
1. 如果前缀筛选器仅包含IPv4或IPv6前缀，则如果VRP前缀等于前缀筛选器前缀或包含在前缀筛选器前缀中，则认为VRP与筛选器匹配。
2. If the Prefix Filter only contains an ASN, the VRP is considered to match the filter if the VRP ASN matches the Prefix Filter ASN.
2. 如果前缀过滤器仅包含ASN，则如果VRP ASN与前缀过滤器ASN匹配，则认为VRP与过滤器匹配。
3. If the Prefix Filter contains both an IPv4 or IPv6 prefix and an ASN, the VRP is considered to match if the VRP prefix is equal to or covered by the Prefix Filter prefix and the VRP ASN matches the Prefix Filter ASN.
3. 如果前缀筛选器同时包含IPv4或IPv6前缀和ASN，则如果VRP前缀等于前缀筛选器前缀或由前缀筛选器前缀覆盖，并且VRP ASN与前缀筛选器ASN匹配，则认为VRP匹配。
The RP can configure zero or more BGPsec Assertion Filters ("BGPsec Filters" for short). Each BGPsec Filter can contain an ASN and/or the Base64 [RFC4648] encoding of a Router Subject Key Identifier (SKI), as described in [RFC8209] and [RFC6487]. It is RECOMMENDED that an explanatory comment is also included with each BGPsec Filter, so that it can be shown to users of the RP software.
RP可以配置零个或多个BGPsec断言过滤器（简称“BGPsec过滤器”）。如[RFC8209]和[RFC6487]中所述，每个BGPsec过滤器可以包含路由器主体密钥标识符（SKI）的ASN和/或Base64[RFC4648]编码。建议在每个BGPsec过滤器中包含解释性注释，以便向RP软件的用户显示。
The above is expressed as a value of the "bgpsecFilters" member, as an array of zero or more objects. Each object MUST contain one of either, or one each of both following members:
上述内容表示为“bgpsecFilters”成员的值，表示为零个或多个对象的数组。每个对象必须包含以下任一或两个成员中的一个：
o An "asn" member, whose value is a number
o “asn”成员，其值为数字
o An "SKI" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as described in Section 4.8.2 of [RFC6487]. (This is the value of the ASN.1 OCTET STRING without the ASN.1 tag or length fields.)
o 一个“SKI”成员，其值为Base64编码，证书的主题密钥标识符不带尾随“=”（[RFC4648]第5节），如[RFC6487]第4.8.2节所述。（这是不带ASN.1标记或长度字段的ASN.1八位字符串的值。）
In addition, each object MAY contain one optional "comment" member, whose value is a string.
此外，每个对象可能包含一个可选的“comment”成员，其值为字符串。
The following example JSON structure represents a "bgpsecFilters" member with an array of example objects for each use case listed above:
下面的示例JSON结构表示“bgpsecFilters”成员，其中包含上面列出的每个用例的示例对象数组：
"bgpsecFilters": [
{
"asn": 64496,
"comment": "All keys for ASN"
},
{
"SKI": "<Base 64 of some SKI>",
"comment": "Key matching Router SKI"
},
{
"asn": 64497,
"SKI": "<Base 64 of some SKI>",
"comment": "Key for ASN 64497 matching Router SKI"
}
]
"bgpsecFilters": [
{
"asn": 64496,
"comment": "All keys for ASN"
},
{
"SKI": "<Base 64 of some SKI>",
"comment": "Key matching Router SKI"
},
{
"asn": 64497,
"SKI": "<Base 64 of some SKI>",
"comment": "Key for ASN 64497 matching Router SKI"
}
]
Figure 4: "bgpsecFilters" Examples
图4：“bgpsecFilters”示例
Any BGPsec Assertion that matches any configured BGPsec Filter MUST be removed from the RP's output. A BGPsec Assertion is considered to match with a BGPsec Filter if one of the following cases applies:
必须从RP的输出中删除与任何配置的BGPsec筛选器匹配的任何BGPsec断言。如果下列情况之一适用，则认为BGPsec断言与BGPsec筛选器匹配：
1. If the BGPsec Filter only contains an ASN, a BGPsec Assertion is considered to match if the Assertion ASN matches the Filter ASN.
1. 如果BGPsec筛选器仅包含ASN，则如果断言ASN与筛选器ASN匹配，则认为BGPsec断言匹配。
2. If the BGPsec Filter only contains an SKI, a BGPsec Assertion is considered to match if the Assertion Router SKI matches the Filter SKI.
2. 如果BGPsec筛选器仅包含SKI，则如果断言路由器SKI与筛选器SKI匹配，则BGPsec断言被视为匹配。
3. If the BGPsec Filter contains both an ASN and a Router SKI, then a BGPsec Assertion is considered to match if both the Assertion ASN matches the Filter ASN and the Assertion Router SKI matches the Filter SKI.
3. 如果BGPsec筛选器同时包含ASN和路由器SKI，则如果断言ASN与筛选器ASN匹配且断言路由器SKI与筛选器SKI匹配，则认为BGPsec断言匹配。
Each RP is locally configured with a (possibly empty) array of ROA Prefix Assertions ("Prefix Assertions" for short). Each ROA Prefix Assertion MUST contain an IPv4 or IPv6 prefix and an ASN. It MAY include a value for the maximum length. It is RECOMMENDED that an explanatory comment is also included with each so that it can be shown to users of the RP software.
每个RP都在本地配置了一个（可能为空）ROA前缀断言数组（简称“前缀断言”）。每个ROA前缀断言必须包含IPv4或IPv6前缀和ASN。它可能包括最大长度的值。建议每一条都包含一条解释性意见，以便向RP软件的用户展示。
The above is expressed as a value of the "prefixAssertions" member, as an array of zero or more objects. Each object MUST contain one of each of the following members:
上述内容表示为“prefixAssertions”成员的值，表示为零个或多个对象的数组。每个对象必须包含以下每个成员中的一个：
o A "prefix" member, whose value is a string representing either an IPv4 prefix (see Section 3.1 of [RFC4632]) or an IPv6 prefix (see [RFC5952]).
o “前缀”成员，其值是表示IPv4前缀（参见[RFC4632]第3.1节）或IPv6前缀（参见[RFC5952]）的字符串。
o An "asn" member, whose value is a number.
o “asn”成员，其值为数字。
In addition, each object MAY contain one of each of the following members:
此外，每个对象可能包含以下每个成员中的一个：
o A "maxPrefixLength" member, whose value is a number.
o “maxPrefixLength”成员，其值为数字。
o A "comment" member, whose value is a string.
o “comment”成员，其值为字符串。
The following example JSON structure represents a "prefixAssertions" member with an array of example objects for each use case listed above:
以下示例JSON结构表示一个“prefixAssertions”成员，其中包含上面列出的每个用例的示例对象数组：
"prefixAssertions": [
{
"asn": 64496,
"prefix": "198.51.100.0/24",
"comment": "My other important route"
},
{
"asn": 64496,
"prefix": "2001:DB8::/32",
"maxPrefixLength": 48,
"comment": "My other important de-aggregated routes"
}
]
"prefixAssertions": [
{
"asn": 64496,
"prefix": "198.51.100.0/24",
"comment": "My other important route"
},
{
"asn": 64496,
"prefix": "2001:DB8::/32",
"maxPrefixLength": 48,
"comment": "My other important de-aggregated routes"
}
]
Figure 5: "prefixAssertions" Examples
图5：“prefixAssertions”示例
Note that the combination of the prefix, ASN, and optional maximum length describes a VRP as described in [RFC6811]. The RP MUST add all Prefix Assertions found this way to the VRP found through RPKI validation and ensure that it sends the complete set of Protocol Data Units (PDUs), excluding duplicates when using the RPKI-Router protocol (see Sections 5.6 and 5.7 of [RFC8210]).
请注意，前缀、ASN和可选最大长度的组合描述了[RFC6811]中所述的VRP。RP必须将以这种方式找到的所有前缀断言添加到通过RPKI验证找到的VRP中，并确保其发送完整的协议数据单元（PDU），不包括使用RPKI路由器协议时的重复项（参见[RFC8210]第5.6节和第5.7节）。
Each RP is locally configured with a (possibly empty) array of BGPsec Assertions. Each BGPsec Assertion MUST contain an AS number, a Router SKI, and the router public key. It is RECOMMENDED that an explanatory comment is also included so that it can be shown to users of the RP software.
每个RP都在本地配置了一个BGPsec断言数组（可能为空）。每个BGPsec断言必须包含AS编号、路由器SKI和路由器公钥。建议还包括解释性注释，以便向RP软件的用户显示。
The above is expressed as a value of the "bgpsecAssertions" member, as an array of zero or more objects. Each object MUST contain one each of all of the following members:
上述内容表示为“bgpsecAssertions”成员的值，表示为零个或多个对象的数组。每个对象必须包含以下所有成员中的一个：
o An "asn" member, whose value is a number.
o “asn”成员，其值为数字。
o An "SKI" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject Key Identifier as described in Section 4.8.2 of [RFC6487] (This is the value of the ASN.1 OCTET STRING without the ASN.1 tag or length fields.)
o 一个“SKI”成员，其值为Base64编码，证书的主题密钥标识符不带尾随“=”（RFC4648的第5节），如[RFC6487]的第4.8.2节所述（这是不带ASN.1标记或长度字段的ASN.1八位字符串的值）
o A "routerPublicKey" member, whose value is the Base64 encoding without trailing '=' (Section 5 of [RFC4648]) of the equivalent to the subjectPublicKeyInfo value of the router certificate's public key, as described in [RFC8208]. This is the full ASN.1 DER encoding of the subjectPublicKeyInfo, including the ASN.1 tag and length values of the subjectPublicKeyInfo SEQUENCE.
o “routerPublicKey”成员，其值为Base64编码，不带“=”（[RFC4648]的第5节），其值等于路由器证书公钥的subjectPublicKeyInfo值，如[RFC8208]所述。这是subjectPublicKeyInfo的完整ASN.1顺序编码，包括subjectPublicKeyInfo序列的ASN.1标记和长度值。
The following example JSON structure represents a "bgpsecAssertions" member with one object as described above:
以下示例JSON结构表示具有一个对象的“bgpsecAssertions”成员，如上所述：
"bgpsecAssertions": [
{
"asn": 64496,
"SKI": "<some base64 SKI>",
"routerPublicKey": "<some base64 public key>",
"comment": "My known key for my important ASN"
}
]
"bgpsecAssertions": [
{
"asn": 64496,
"SKI": "<some base64 SKI>",
"routerPublicKey": "<some base64 public key>",
"comment": "My known key for my important ASN"
}
]
Figure 6: "bgpsecAssertions" Examples
图6：“bgpsecAssertions”示例
Note that a "bgpsecAssertions" member matches the syntax of the Router Key PDU described in Section 5.10 of [RFC8210]. Relying Parties MUST add any "bgpsecAssertions" member thus found to the set of Router Key PDUs, excluding duplicates, when using the RPKI-Router protocol [RFC8210].
请注意，“bgpsecAssertions”成员与[RFC8210]第5.10节中描述的路由器密钥PDU的语法相匹配。当使用RPKI路由器协议[RFC8210]时，依赖方必须将由此发现的任何“bgpsecAssertions”成员添加到路由器密钥PDU集中，不包括重复的成员。
The following JSON structure represents an example of a SLURM file that uses all the elements described in the previous sections:
以下JSON结构代表了一个SLURM文件的示例，该文件使用了前面几节中描述的所有元素：
{
"slurmVersion": 1,
"validationOutputFilters": {
"prefixFilters": [
{
"prefix": "192.0.2.0/24",
"comment": "All VRPs encompassed by prefix"
},
{
"asn": 64496,
"comment": "All VRPs matching ASN"
},
{
"prefix": "198.51.100.0/24",
"asn": 64497,
"comment": "All VRPs encompassed by prefix, matching ASN"
}
],
"bgpsecFilters": [
{
"asn": 64496,
"comment": "All keys for ASN"
},
{
"SKI": "Zm9v",
"comment": "Key matching Router SKI"
},
{
"asn": 64497,
"SKI": "YmFy",
"comment": "Key for ASN 64497 matching Router SKI"
}
]
},
"locallyAddedAssertions": {
"prefixAssertions": [
{
{
"slurmVersion": 1,
"validationOutputFilters": {
"prefixFilters": [
{
"prefix": "192.0.2.0/24",
"comment": "All VRPs encompassed by prefix"
},
{
"asn": 64496,
"comment": "All VRPs matching ASN"
},
{
"prefix": "198.51.100.0/24",
"asn": 64497,
"comment": "All VRPs encompassed by prefix, matching ASN"
}
],
"bgpsecFilters": [
{
"asn": 64496,
"comment": "All keys for ASN"
},
{
"SKI": "Zm9v",
"comment": "Key matching Router SKI"
},
{
"asn": 64497,
"SKI": "YmFy",
"comment": "Key for ASN 64497 matching Router SKI"
}
]
},
"locallyAddedAssertions": {
"prefixAssertions": [
{
"asn": 64496,
"prefix": "198.51.100.0/24",
"comment": "My other important route"
},
{
"asn": 64496,
"prefix": "2001:DB8::/32",
"maxPrefixLength": 48,
"comment": "My other important de-aggregated routes"
}
],
"bgpsecAssertions": [
{
"asn": 64496,
"comment" : "My known key for my important ASN",
"SKI": "<some base64 SKI>",
"routerPublicKey": "<some base64 public key>"
}
]
}
}
"asn": 64496,
"prefix": "198.51.100.0/24",
"comment": "My other important route"
},
{
"asn": 64496,
"prefix": "2001:DB8::/32",
"maxPrefixLength": 48,
"comment": "My other important de-aggregated routes"
}
],
"bgpsecAssertions": [
{
"asn": 64496,
"comment" : "My known key for my important ASN",
"SKI": "<some base64 SKI>",
"routerPublicKey": "<some base64 public key>"
}
]
}
}
Figure 7: Example of Full SLURM File
图7：完整SLURM文件的示例
To ensure local consistency, the effect of SLURM MUST be atomic. That is, the output of the RP either MUST be the same as if a SLURM file were not used or MUST reflect the entire SLURM configuration. For an example of why this is required, consider the case of two local routes for the same prefix but different origin ASNs. Both routes are configured with Locally Added Assertions. If neither addition occurs, then both routes could be in the NotFound state [RFC6811]. If both additions occur, then both routes would be in the Valid state. However, if one addition occurs and the other does not, then one could be Invalid while the other is Valid.
为了确保局部一致性，SLURM的效果必须是原子的。也就是说，RP的输出必须与未使用SLURM文件时相同，或者必须反映整个SLURM配置。对于这是为什么需要的一个例子，考虑两个本地路由的情况相同的前缀，但不同的起源ASNs。这两个路由都配置了本地添加的断言。如果两次添加都没有发生，则两条路由都可能处于NotFound状态[RFC6811]。如果两个添加都发生，则两个路由都将处于有效状态。但是，如果一个加法发生而另一个加法未发生，则一个加法无效，而另一个加法有效。
An implementation MAY support the concurrent use of multiple SLURM files. In this case, the resulting inputs to Validation Output Filters and Locally Added Assertions are the respective unions of the inputs from each file. The envisioned typical use case for multiple files is when the files have distinct scopes. For instance, operators of two distinct networks may resort to one RP system to frame routing decisions. As such, they probably deliver SLURM files to this RP independently. Before an RP configures SLURM files from different sources, it MUST make sure there is no internal conflict among the INR assertions in these SLURM files. To do so, the RP SHOULD check the entries of each SLURM file with regard to overlaps of the INR assertions and report errors to the sources that created the SLURM files in question. The RP gets multiple SLURM files as a set, and the whole set MUST be rejected in case of any overlaps among the SLURM files.
一个实现可以支持多个SLURM文件的并发使用。在这种情况下，验证输出过滤器和本地添加的断言的结果输入是来自每个文件的输入的各自联合。设想的多个文件的典型用例是当文件具有不同的作用域时。例如，两个不同网络的运营商可能求助于一个RP系统来制定路由决策。因此，他们可能会独立地将SLURM文件交付给该RP。RP在配置来自不同来源的SLURM文件之前，必须确保这些SLURM文件中的INR断言之间没有内部冲突。为此，RP应检查每个SLURM文件中与INR断言重叠相关的条目，并向创建相关SLURM文件的来源报告错误。RP将多个SLURM文件作为一个集合，如果SLURM文件之间存在任何重叠，则必须拒绝整个集合。
If a problem is detected with the INR assertions in these SLURM files, the RP MUST NOT use them and SHOULD issue a warning as error report in the following cases:
如果在这些SLURM文件中检测到INR断言存在问题，RP不得使用这些断言，并应在以下情况下发出警告作为错误报告：
1. There may be conflicting changes to ROA Prefix Assertions if an IP address X and distinct SLURM files Y and Z exist such that X is contained by any prefix in any "prefixAssertions" or "prefixFilters" in file Y and X is contained by any prefix in any "prefixAssertions" or "prefixFilters" in file Z.
1. 如果IP地址X和不同的SLURM文件Y和Z存在，使得X包含在文件Y的任何“prefixAssertions”或“prefixFilters”中的任何前缀中，而X包含在文件Z的任何“prefixAssertions”或“prefixFilters”中的任何前缀中，则对ROA前缀断言的更改可能存在冲突。
2. There may be conflicting changes to BGPsec Assertions if an ASN X and distinct SLURM files Y and Z exist such that X is used in any "bgpsecAssertions" or "bgpsecFilters" in file Y and X is used in any "bgpsecAssertions" or "bgpsecFilters" in file Z.
2. 如果ASN X和不同的SLURM文件Y和Z存在，使得X在文件Y中的任何“bgpsecAssertions”或“bgpsecFilters”中使用，而X在文件Z中的任何“bgpsecAssertions”或“bgpsecFilters”中使用，则对BGPsec断言的更改可能存在冲突。
This document has no IANA actions.
本文档没有IANA操作。
The mechanisms described in this document provide a network operator with additional ways to control use of RPKI data while preserving autonomy in address space and ASN management. These mechanisms are only applied locally; they do not influence how other network operators interpret RPKI data. Nonetheless, care should be taken in how these mechanisms are employed. Note that it also is possible to use SLURM to (locally) manipulate assertions about non-private INRs, e.g., allocated address space that is globally routed. For example, a SLURM file may be used to override RPKI data that a network operator believes has been corrupted by an adverse action. Network operators who elect to use SLURM in this fashion should use extreme caution.
本文档中描述的机制为网络运营商提供了控制RPKI数据使用的其他方法，同时保留了地址空间和ASN管理的自主权。这些机制只适用于局部；它们不会影响其他网络运营商解释RPKI数据的方式。尽管如此，应注意如何使用这些机制。注意，还可以使用SLURM（本地）操纵关于非私有INR的断言，例如，全局路由的分配地址空间。例如，SLURM文件可用于覆盖网络运营商认为已被不利操作破坏的RPKI数据。选择以这种方式使用SLURM的网络运营商应格外小心。
The goal of the mechanisms described in this document is to enable an RP to create its own view of the RPKI, which is intrinsically a security function. An RP using a SLURM file is trusting the assertions made in that file. Errors in the SLURM file used by an RP can undermine the security offered to that RP by the RPKI. A SLURM file could declare as invalid ROAs that would otherwise be valid, and vice versa. As a result, an RP MUST carefully consider the security implications of the SLURM file being used, especially if the file is provided by a third party.
本文档中描述的机制的目标是使RP能够创建自己的RPKI视图，这本质上是一种安全功能。使用SLURM文件的RP信任该文件中的断言。RP使用的SLURM文件中的错误可能会破坏RPKI为该RP提供的安全性。SLURM文件可以声明为无效的ROA，否则将是有效的，反之亦然。因此，RP必须仔细考虑所使用的SLURM文件的安全含义，特别是当文件由第三方提供时。
Additionally, each RP using SLURM MUST ensure the authenticity and integrity of any SLURM file that it uses. Initially, the SLURM file may be preconfigured out of band, but if the RP updates its SLURM file over the network, it MUST verify the authenticity and integrity of the updated SLURM file. The mechanism to update the SLURM file to guarantee authenticity and integrity is out of the scope of this document.
此外，每个使用SLURM的RP必须确保其使用的任何SLURM文件的真实性和完整性。最初，SLURM文件可以在带外预配置，但如果RP通过网络更新其SLURM文件，则必须验证更新的SLURM文件的真实性和完整性。更新SLURM文件以保证真实性和完整性的机制不在本文档的范围内。
[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>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，DOI 10.17487/RFC4632，2006年8月<https://www.rfc-editor.org/info/rfc4632>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<https://www.rfc-editor.org/info/rfc4648>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 5952，DOI 10.17487/RFC5952，2010年8月<https://www.rfc-editor.org/info/rfc5952>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.
[RFC6487]Huston，G.，Michaelson，G.，和R.Loomans，“X.509 PKIX资源证书的配置文件”，RFC 6487，DOI 10.17487/RFC6487，2012年2月<https://www.rfc-editor.org/info/rfc6487>.
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/info/rfc6811>.
[RFC6811]Mohapatra，P.，Scudder，J.，Ward，D.，Bush，R.，和R.Austein，“BGP前缀来源验证”，RFC 6811，DOI 10.17487/RFC6811，2013年1月<https://www.rfc-editor.org/info/rfc6811>.
[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/rfc8205>.
[RFC8205]Lepinski，M.，Ed.和K.Sriram，Ed.，“BGPsec协议规范”，RFC 8205，DOI 10.17487/RFC8205，2017年9月<https://www.rfc-editor.org/info/rfc8205>.
[RFC8208] Turner, S. and O. Borchert, "BGPsec Algorithms, Key Formats, and Signature Formats", RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>.
[RFC8208]Turner，S.和O.Borchert，“BGPsec算法、密钥格式和签名格式”，RFC 8208，DOI 10.17487/RFC8208，2017年9月<https://www.rfc-editor.org/info/rfc8208>.
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests", RFC 8209, DOI 10.17487/RFC8209, September 2017, <https://www.rfc-editor.org/info/rfc8209>.
[RFC8209]Reynolds，M.，Turner，S.和S.Kent，“BGPsec路由器证书、证书撤销列表和证书请求的配置文件”，RFC 8209，DOI 10.17487/RFC8209，2017年9月<https://www.rfc-editor.org/info/rfc8209>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，STD 90，RFC 8259，DOI 10.17487/RFC8259，2017年12月<https://www.rfc-editor.org/info/rfc8259>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，DOI 10.17487/RFC1918，1996年2月<https://www.rfc-editor.org/info/rfc1918>.
[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>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 4193，DOI 10.17487/RFC4193，2005年10月<https://www.rfc-editor.org/info/rfc4193>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012, <https://www.rfc-editor.org/info/rfc6482>.
[RFC6482]Lepinski，M.，Kent，S.，和D.Kong，“路线原产地授权（ROA）的概要”，RFC 6482，DOI 10.17487/RFC6482，2012年2月<https://www.rfc-editor.org/info/rfc6482>.
[RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, DOI 10.17487/RFC6491, February 2012, <https://www.rfc-editor.org/info/rfc6491>.
[RFC6491]Manderson，T.，Vegoda，L.，和S.Kent，“IANA发布的资源公钥基础设施（RPKI）对象”，RFC 6491，DOI 10.17487/RFC64912012年2月<https://www.rfc-editor.org/info/rfc6491>.
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 2012, <https://www.rfc-editor.org/info/rfc6598>.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，DOI 10.17487/RFC6598，2012年4月<https://www.rfc-editor.org/info/rfc6598>.
[RFC6810] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol", RFC 6810, DOI 10.17487/RFC6810, January 2013, <https://www.rfc-editor.org/info/rfc6810>.
[RFC6810]Bush，R.和R.Austein，“资源公钥基础设施（RPKI）到路由器协议”，RFC 6810，DOI 10.17487/RFC6810，2013年1月<https://www.rfc-editor.org/info/rfc6810>.
[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <https://www.rfc-editor.org/info/rfc6996>.
[RFC6996]Mitchell，J.，“供私人使用的自主系统（AS）预订”，BCP 6，RFC 6996，DOI 10.17487/RFC6996，2013年7月<https://www.rfc-editor.org/info/rfc6996>.
[RFC8210] Bush, R. and R. Austein, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1", RFC 8210, DOI 10.17487/RFC8210, September 2017, <https://www.rfc-editor.org/info/rfc8210>.
[RFC8210]Bush，R.和R.Austein，“资源公钥基础设施（RPKI）到路由器协议，版本1”，RFC 8210，DOI 10.17487/RFC8210，2017年9月<https://www.rfc-editor.org/info/rfc8210>.
[RFC8211] Kent, S. and D. Ma, "Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)", RFC 8211, DOI 10.17487/RFC8211, September 2017, <https://www.rfc-editor.org/info/rfc8211>.
[RFC8211]Kent，S.和D.Ma，“资源公钥基础设施（RPKI）中证书颁发机构（CA）或存储库经理的不利行为”，RFC 8211，DOI 10.17487/RFC8211，2017年9月<https://www.rfc-editor.org/info/rfc8211>.
Acknowledgments
致谢
The authors would like to thank Stephen Kent for his guidance and detailed reviews of this document. The authors would also like to thank Richard Hansen for his careful reviews and Hui Zou and Chunlin An for their editorial assistance.
作者感谢Stephen Kent对本文件的指导和详细审查。作者还要感谢理查德·汉森（Richard Hansen）的仔细评论，以及邹晖（Hui Zou）和安春林（Chunlin An）的编辑协助。
Authors' Addresses
作者地址
Di Ma ZDNS 4 South 4th St. Zhongguancun Haidian, Beijing 100190 China
中国北京海淀中关村南四街4号地马ZDNS 100190
Email: madi@zdns.cn
Email: madi@zdns.cn
David Mandelberg Unaffiliated
大卫·曼德尔伯格无关联
Email: david@mandelberg.org
URI: https://david.mandelberg.org
Email: david@mandelberg.org
URI: https://david.mandelberg.org
Tim Bruijnzeels NLnet Labs Science Park 400 Amsterdam 1098 XH The Netherlands
Tim Bruijnzeels NLnet实验室科技园400阿姆斯特丹1098 XH荷兰
Email: tim@nlnetlabs.nl
Email: tim@nlnetlabs.nl