Internet Engineering Task Force (IETF)                         G. Huston
Request for Comments: 6483                                 G. Michaelson
Category: Informational                                            APNIC
ISSN: 2070-1721                                            February 2012
        
Internet Engineering Task Force (IETF)                         G. Huston
Request for Comments: 6483                                 G. Michaelson
Category: Informational                                            APNIC
ISSN: 2070-1721                                            February 2012
        

Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)

使用资源证书公钥基础设施(PKI)和路由来源授权(ROA)验证路由来源

Abstract

摘要

This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol.

本文档根据资源公钥基础设施应用程序的上下文定义路由来源授权(ROA)的语义,以验证边界网关协议中公布的路由来源。

Status of This Memo

关于下段备忘

This document is not an Internet Standards Track specification; it is published for informational purposes.

本文件不是互联网标准跟踪规范;它是为了提供信息而发布的。

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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

本文件是互联网工程任务组(IETF)的产品。它代表了IETF社区的共识。它已经接受了公众审查,并已被互联网工程指导小组(IESG)批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准;见RFC 5741第2节。

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

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

Copyright Notice

版权公告

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

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

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

Table of Contents

目录

   1. Introduction ....................................................2
   2. ROA Validation Outcomes for a Route .............................3
   3. Applying Validation Outcomes to Route Selection .................5
   4. Disavowal of Routing Origination ................................6
   5. Route Validation Lifetime .......................................6
   6. Security Considerations .........................................7
   7. Acknowledgements ................................................7
   8. References ......................................................8
      8.1. Normative References .......................................8
      8.2. Informative References .....................................8
        
   1. Introduction ....................................................2
   2. ROA Validation Outcomes for a Route .............................3
   3. Applying Validation Outcomes to Route Selection .................5
   4. Disavowal of Routing Origination ................................6
   5. Route Validation Lifetime .......................................6
   6. Security Considerations .........................................7
   7. Acknowledgements ................................................7
   8. References ......................................................8
      8.1. Normative References .......................................8
      8.2. Informative References .....................................8
        
1. Introduction
1. 介绍

This document defines the semantics of a Route Origin Authorization (ROA) in terms of the context of an application of the Resource Public Key Infrastructure (RPKI) [RFC6480] to validate the origination of routes advertised in the Border Gateway Protocol (BGP) [RFC4271].

本文件根据资源公钥基础设施(RPKI)[RFC6480]应用程序的上下文定义路由来源授权(ROA)的语义,以验证边界网关协议(BGP)[RFC4271]中公布的路由的来源。

The RPKI is based on a hierarchy of resource certificates that are aligned to the Internet Number Resource allocation structure. Resource certificates are X.509 certificates that conform to the PKIX profile [RFC5280], and to the extensions for IP addresses and AS identifiers [RFC3779]. A resource certificate describes an action by an issuer that binds a list of IP address blocks and Autonomous System (AS) numbers to the subject of a certificate, identified by the unique association of the subject's private key with the public key contained in the resource certificate. The RPKI is structured such that each current resource certificate matches a current resource allocation or assignment. This is further described in [RFC6480].

RPKI基于与Internet号码资源分配结构对齐的资源证书层次结构。资源证书是X.509证书,符合PKIX配置文件[RFC5280],以及IP地址和AS标识符的扩展[RFC3779]。资源证书描述了颁发者将IP地址块和自治系统(AS)号列表绑定到证书主题的操作,通过主题的私钥与资源证书中包含的公钥的唯一关联来标识。RPKI的结构使每个当前资源证书与当前资源分配或分配相匹配。[RFC6480]对此作了进一步说明。

ROAs are digitally signed objects that bind an address to an AS number, and are signed by the address holder. A ROA provides a means of verifying that an IP address block holder has authorized a particular AS to originate routes in the inter-domain routing environment for that address block. ROAs are described in [RFC6482]. ROAs are intended to fit within the requirements for adding security to inter-domain routing.

ROA是数字签名对象,将地址绑定到AS号码,并由地址持有者签名。ROA提供了一种验证IP地址块持有者是否已授权特定AS在域间路由环境中为该地址块发起路由的方法。[RFC6482]中描述了ROA。ROA旨在满足为域间路由添加安全性的要求。

This document describes the semantic interpretation of a ROA, with particular reference to application in inter-domain routing relating to the origination of routes, and the intended scope of the authority that is conveyed in the ROA.

本文件描述了ROA的语义解释,特别是与路由发起相关的域间路由应用,以及ROA中传达的权限的预期范围。

2. ROA Validation Outcomes for a Route
2. 路线的ROA验证结果

A "route" is unit of information that associates a set of destinations described by an IP address prefix with a set of attributes of a path to those destinations, as defined in Section 1.1 of [RFC4271].

“路由”是将IP地址前缀描述的一组目的地与[RFC4271]第1.1节中定义的这些目的地的路径属性集相关联的信息单元。

A route's "origin AS" is defined as follows: If the final path segment of the AS_PATH is of type AS_SEQUENCE, the origin AS is the first element of the sequence (i.e., the AS in the rightmost position with respect to the position of octets in the protocol message). If the AS_PATH contains a path segment of type AS_SET, indicating that the route is an aggregate, then the origin AS cannot be determined. In terms of validation of a route in the context of a routing environment, the address prefix value and the origin AS are used in the ROA validation operation.

路由的“起始AS”定义如下:如果AS_路径的最终路径段类型为AS_序列,则起始AS为序列的第一个元素(即,AS位于协议消息中八位字节位置的最右侧位置)。如果AS_路径包含AS_SET类型的路径段,表示路由是聚合,则无法确定原点AS。就在路由环境的上下文中对路由进行验证而言,在ROA验证操作中使用地址前缀值和源AS。

It is assumed here that a relying party (RP) has access to a local cache of the complete set of valid ROAs when performing validation of a route. (Valid ROAs are defined as ROAs that are determined to be syntactically correct and are signed using a signature that can be verified using the RPKI, as described in [RFC6482].) The RP needs to match a route to one or more valid candidate ROAs in order to determine a validation outcome, which, in turn, can be used to determine the appropriate local actions to perform on the route.

这里假设,当执行路由验证时,依赖方(RP)可以访问完整有效ROA集的本地缓存。(如[RFC6482]所述,有效ROA被定义为语法正确的ROA,并使用可使用RPKI验证的签名进行签名)。RP需要将路由与一个或多个有效候选ROA匹配,以确定验证结果,这反过来,可用于确定要在路线上执行的适当本地操作。

This approach to route origination validation uses a generic model of "positive" attestation that has an associated inference that routes that cannot be validated within the RPKI framework would conventionally be interpreted by an RP as "invalid". However, the considerations of accommodating environments of partial adoption of the use of ROAs, where only a subset of validly advertised address prefixes have associated published ROAs within the structure of the RPKI, imply some modification to this model of positive attestation. In the context of route validation, it is assumed that once an address prefix is described in a ROA, then this ROA specifically encompasses all address prefixes that are more specific than that described in the ROA. Thus, any route for a more specific address prefix than that described by any valid ROA that does not itself have a matching valid ROA can be considered "invalid". However, routes for address prefixes that are not fully described by any single ROA (i.e., those routes whose address prefixes may be an aggregate of address prefixes described in a valid ROA, or have address prefixes where there is no intersection with any valid ROA), and are not matched by any valid ROA and do not have an address prefix that is a more specific address prefix described in any valid ROA, cannot be reliably classified as "invalid" in a partial deployment scenario. Such routes have a validation outcome of "unknown".

这种路由发起验证方法使用一种“肯定”认证的通用模型,该模型有一个关联的推论,即在RPKI框架内无法验证的路由通常会被RP解释为“无效”。然而,考虑到适应部分采用ROA的环境,其中只有一部分有效公布的地址前缀与RPKI结构内已发布的ROA相关联,这意味着对这种正面证明模型进行了一些修改。在路由验证的上下文中,假设一旦在ROA中描述了地址前缀,则该ROA具体地包括比在ROA中描述的地址前缀更具体的所有地址前缀。因此,对于比任何有效ROA所描述的更具体的地址前缀的任何路由,如果其本身没有匹配的有效ROA,则可将其视为“无效”。但是,地址前缀未被任何单个ROA完全描述的路由(即,其地址前缀可能是有效ROA中描述的地址前缀的集合,或具有与任何有效ROA不相交的地址前缀的路由),和未与任何有效ROA匹配,并且没有地址前缀,该地址前缀是任何有效ROA中描述的更具体的地址前缀,在部分部署场景中无法可靠地归类为“无效”。此类路线的验证结果为“未知”。

An abstract attribute of a route can be determined as the outcome of this validation procedure, namely a "validity state" [BGP-PFX]. The validity state of a route, with a prefix and an origin AS as defined above, when using single ROA for determining this validity state, is summarized in the following table:

路由的抽象属性可以确定为该验证过程的结果,即“有效状态”[BGP-PFX]。当使用单个ROA确定该有效状态时,具有如上定义的前缀和原点的路由的有效状态总结如下表所示:

           Route    matching  non-matching
      Prefix   AS->   AS         AS
       V           +---------+---------+
      Non-         | unknown | unknown |
      Intersecting |         |         |
                   +---------+---------+
      Covering     | unknown | unknown |
      Aggregate    |         |         |
                   +---------+---------+
      match ROA    | valid   | invalid |
      prefix       |         |         |
                   +---------+---------+
      More         |         |         |
      Specific     | invalid | invalid |
      than ROA     |         |         |
                   +---------+---------+
        
           Route    matching  non-matching
      Prefix   AS->   AS         AS
       V           +---------+---------+
      Non-         | unknown | unknown |
      Intersecting |         |         |
                   +---------+---------+
      Covering     | unknown | unknown |
      Aggregate    |         |         |
                   +---------+---------+
      match ROA    | valid   | invalid |
      prefix       |         |         |
                   +---------+---------+
      More         |         |         |
      Specific     | invalid | invalid |
      than ROA     |         |         |
                   +---------+---------+
        

Route's Validity State

路由的有效状态

In an environment of a collection of valid ROAs, a route's validity state is considered to be "valid" if any ROA provides a "valid" outcome. It's validity state is considered to be "invalid" if one (or more) ROAs provide an "invalid" outcome and no ROAs provide a "valid" outcome. Its validity state is considered to be "unknown" (or, synonymously, "not found" [BGP-PFX]) when no valid ROA can produce either a "valid" or an "invalid" validity state outcome.

在有效ROA集合的环境中,如果任何ROA提供“有效”结果,则路由的有效状态被视为“有效”。如果一个(或多个)ROA提供“无效”结果,并且没有ROA提供“有效”结果,则其有效性状态被视为“无效”。当没有有效的ROA可以产生“有效”或“无效”有效状态结果时,其有效状态被视为“未知”(或同义词“未找到”[BGP-PFX])。

A route validity state is defined by the following procedure:

路由有效状态由以下程序定义:

1. Select all valid ROAs that include a ROAIPAddress value that either matches, or is a covering aggregate of, the address prefix in the route. This selection forms the set of "candidate ROAs".

1. 选择包含ROAIPAddress值的所有有效ROA,该值与路由中的地址前缀匹配或是其覆盖聚合。该选择形成了“候选ROA”集。

2. If the set of candidate ROAs is empty, then the procedure stops with an outcome of "unknown" (or, synonymously, "not found", as used in [BGP-PFX]).

2. 如果候选ROA集为空,则过程停止,结果为“未知”(或同义词为“未找到”,如[BGP-PFX]中所用)。

3. If the route's origin AS can be determined and any of the set of candidate ROAs has an asID value that matches the origin AS in the route, and the route's address prefix matches a ROAIPAddress in the ROA (where "match" is defined as where the

3. 如果可以确定路由的起始地址,并且任何候选ROA集合具有与路由中的起始地址匹配的asID值,并且路由的地址前缀与ROA中的ROAIPAddress匹配(其中“匹配”定义为

route's address precisely matches the ROAIPAddress, or where the ROAIPAddress includes a maxLength element, and the route's address prefix is a more specific prefix of the ROAIPAddress, and the route's address prefix length value is less than or equal to the ROAIPAddress maxLength value), then the procedure halts with an outcome of "valid".

路由的地址与ROAIPAddress精确匹配,或者如果ROAIPAddress包含maxLength元素,并且路由的地址前缀是ROAIPAddress的更具体的前缀,并且路由的地址前缀长度值小于或等于ROAIPAddress maxLength值),则该过程将以“有效”的结果停止。

4. Otherwise, the procedure halts with an outcome of "invalid".

4. 否则,程序停止,结果为“无效”。

3. Applying Validation Outcomes to Route Selection
3. 将验证结果应用于路线选择

Within the framework of the abstract model of the operation of inter-domain routing using BGP [RFC4271], a received prefix announcement from a routing peer is compared to all announcements for this prefix received from other routing peers, and a route selection procedure is used to select the "best" route from this candidate set.

在使用BGP[RFC4271]的域间路由操作的抽象模型框架内,将从路由对等方接收的前缀通知与从其他路由对等方接收的该前缀的所有通知进行比较,并使用路由选择过程从该候选集中选择“最佳”路由。

The route's validity state, described in Section 2, of "valid", "invalid", or "unknown" may be used as part of the determination of the local degree of preference, in which case the local order of preference is as follows:

第2节中描述的路线有效状态“有效”、“无效”或“未知”可作为确定局部偏好程度的一部分,在这种情况下,局部偏好顺序如下:

"valid" is to be preferred over "unknown", which is to be preferred over "invalid".

“有效”优先于“未知”,而“未知”优先于“无效”。

It is a matter of local routing policy as to the actions to be undertaken by a routing entity in processing those routes with "unknown" validity states. Due to considerations of partial use of ROAs in heterogeneous environments, such as in the public Internet, it is advised that local policy settings should not result in "unknown" validity state outcomes being considered as sufficient grounds to reject a route outright from further consideration as a local best route.

对于路由实体在处理具有“未知”有效状态的路由时要采取的操作,这是本地路由策略的问题。由于考虑到在异构环境中(如在公共互联网中)部分使用ROA,建议本地策略设置不应导致“未知”有效性状态结果被视为完全拒绝作为本地最佳路由进一步考虑的充分理由。

It is a matter of local routing policy as to whether routes with an "invalid" validity state are considered to be ineligible for further consideration in a route selection process. Potential circular dependence is a consideration here: if the authoritative publication point of the repository of ROAs, or that of any certificate used in relation to an address prefix, is located at an address that lies within the address prefix described in a ROA, then the repository can only be accessed by the RP once a route for the prefix has been accepted by the RP's local routing domain. It is also noted that the propagation time of RPKI objects may be different to the propagation time of routes, and that routes may be learned by an RP's routing system before the RP's local RPKI repository cache picks up the

在路由选择过程中,具有“无效”有效状态的路由是否被认为不符合进一步考虑的条件是本地路由策略的问题。这里需要考虑潜在的循环依赖性:如果ROA存储库的权威发布点或与地址前缀相关的任何证书的权威发布点位于ROA中描述的地址前缀内的地址,然后,RP只能在RP的本地路由域接受前缀的路由后访问存储库。还应注意,RPKI对象的传播时间可能不同于路由的传播时间,并且在RP的本地RPKI存储库缓存拾取路由之前,RP的路由系统可以学习路由

associated ROAs and recognizes them as having a validity state of "valid" within the RPKI.

关联的ROA,并在RPKI中将其识别为有效状态为“有效”。

4. Disavowal of Routing Origination
4. 否认路由起源

A ROA is a positive attestation that a prefix holder has authorized an AS to originate a route for this prefix into the inter-domain routing system. It is possible for a prefix holder to construct an authorization where no valid AS has been granted any such authority to originate a route for an address prefix. This is achieved by using a ROA where the ROA's subject AS is one that must not be used in any routing context. Specifically, AS 0 is reserved by the IANA such that it may be used to identify non-routed networks [IANA-AS].

ROA是前缀持有者已授权AS为该前缀发起进入域间路由系统的路由的肯定证明。前缀持有者可以在没有被授予任何有效授权的情况下构造授权来发起地址前缀的路由。这是通过使用ROA来实现的,其中ROA的主题AS不得在任何路由上下文中使用。具体而言,由于0由IANA保留,因此它可用于识别非路由网络[IANA-AS]。

A ROA with a subject of AS 0 (AS 0 ROA) is an attestation by the holder of a prefix that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context.

主题为AS 0(AS 0 ROA)的ROA是前缀持有人的证明,证明ROA中描述的前缀以及任何更具体的前缀不应在路由上下文中使用。

The route validation procedure, described in Section 2, will provide a "valid" outcome if any ROA matches the address prefix and origin AS, even if other valid ROAs would provide an "invalid" validation outcome if used in isolation. Consequently, an AS 0 ROA has a lower relative preference than any other ROA that has a routable AS as its subject. This allows a prefix holder to use an AS 0 ROA to declare a default condition that any route that is equal to or more specific than the prefix to be considered "invalid", while also allowing other concurrently issued ROAs to describe valid origination authorizations for more specific prefixes.

如果任何ROA与地址前缀和来源AS匹配,则第2节中描述的路由验证程序将提供“有效”结果,即使其他有效ROA单独使用时将提供“无效”验证结果。因此,AS 0 ROA的相对偏好低于任何其他具有可路由AS主题的ROA。这允许前缀持有者使用AS 0 ROA声明默认条件,即任何等于或比前缀更具体的路由都将被视为“无效”,同时还允许其他同时颁发的ROA描述更具体前缀的有效发起授权。

By convention, an AS 0 ROA should have a maxLength value of 32 for IPv4 addresses and a maxlength value of 128 for IPv6 addresses; although, in terms of route validation, the same outcome would be achieved with any valid maxLength value, or even if the maxLength element were to be omitted from the ROA.

按照约定,对于IPv4地址,AS 0 ROA的maxLength值应为32,对于IPv6地址,其maxLength值应为128;尽管在路由验证方面,使用任何有效的maxLength值,或者即使从ROA中省略maxLength元素,也可以获得相同的结果。

Also by convention, an AS 0 ROA should be the only ROA issued for a given address prefix; although again, this is not a strict requirement. An AS 0 ROA may coexist with ROAs that have different subject AS values; although in such cases, the presence or lack of presence of the AS 0 ROA does not alter the route's validity state in any way.

根据惯例,AS 0 ROA应该是为给定地址前缀颁发的唯一ROA;尽管如此,这并不是一个严格的要求。AS 0 ROA可能与具有不同主题AS值的ROA共存;尽管在这种情况下,AS 0 ROA的存在或不存在不会以任何方式改变路由的有效状态。

5. Route Validation Lifetime
5. 路由验证生存期

The "lifetime" of a validation outcome refers to the time period during which the original validation outcome can be still applied. The implicit assumption here is that when the validation lifetime "expires", the route should be re-tested for validity.

验证结果的“生存期”是指原始验证结果仍可应用的时间段。这里隐含的假设是,当验证生命周期“到期”时,应该重新测试路由的有效性。

The validation lifetime for a ROA is controlled by the Valid times specified in the end-entity (EE) certificate used to sign the ROA, and the valid times of those certificates in the certification path used to validate the EE certificate. A ROA validation expires at the notAfter field of the signing EE certificate, or at such a time when there is no certification path that can validate the ROA. A ROA issuer may elect to prematurely invalidate a ROA by revoking the EE certificate that was used to sign the ROA.

ROA的验证生存期由用于签署ROA的最终实体(EE)证书中指定的有效时间以及用于验证EE证书的证书路径中这些证书的有效时间控制。ROA验证在签名EE证书的notAfter字段处过期,或者在没有可以验证ROA的证书路径时过期。居留权签发人可选择撤销用于签署居留权的EE证书,从而提前使居留权无效。

6. Security Considerations
6. 安全考虑

ROA issuers should be aware of the validation implication in issuing a ROA, in that a ROA implicitly invalidates all routes that have more specific prefixes with a prefix length greater than maxLength, and all originating AS's other than the AS listed in the collection of ROAs for this prefix.

ROA颁发者应了解颁发ROA时的验证含义,因为ROA隐式地使所有具有更具体前缀且前缀长度大于maxLength的路由以及除此前缀的ROA集合中列出的AS之外的所有原始AS无效。

A conservative operational practice would be to ensure the issuing of ROAs for all more specific prefixes with distinct origination ASes prior to the issuing of ROAs for larger encompassing address blocks, in order to avoid inadvertent invalidation of valid routes during ROA generation.

一种保守的操作实践是,在为较大的包含地址块颁发ROA之前,确保为所有具有不同起始ASE的更具体前缀颁发ROA,以避免在ROA生成期间有效路由的意外失效。

ROA issuers should also be aware that if they generate a ROA for one origin AS, then if the address prefix holder authorizes multiple ASes to originate routes for a given address prefix, then is necessary for a ROA be generated for every such authorized AS.

ROA发行人还应意识到,如果他们为一个来源AS生成ROA,那么如果地址前缀持有人授权多个ASE为给定地址前缀发起路由,则有必要为每个此类授权AS生成ROA。

7. Acknowledgements
7. 致谢

The authors would like to acknowledge the helpful contributions of John Scudder and Stephen Kent in preparing this document, and also the contributions of many members of the SIDR working group in response to presentations of this material in SIDR WG sessions. The authors also acknowledge prior work undertaken by Tony Bates, Randy Bush, Tony Li, and Yakov Rekhter as the validation outcomes described here reflect the authentication outcomes and semantics of origin AS verification described in [NLRI-ORIG]. A number of validation concepts relating to a route's validity state presented in [BGP-PFX], edited by Pradosh Mohapatra, et al., have be used in this document.

作者要感谢John Scudder和Stephen Kent在编写本文件过程中所作的有益贡献,以及SIDR工作组许多成员在SIDR工作组会议上对本材料的介绍所作的贡献。作者还承认Tony Bates、Randy Bush、Tony Li和Yakov Rekhter之前所做的工作,因为此处所述的验证结果反映了[NLRI-ORIG]中所述的验证结果和来源语义。本文件使用了由Pradosh Mohapatra等人编辑的[BGP-PFX]中提出的与路线有效性状态相关的许多验证概念。

8. References
8. 工具书类
8.1. Normative References
8.1. 规范性引用文件

[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.

[RFC3779]Lynn,C.,Kent,S.,和K.Seo,“IP地址和AS标识符的X.509扩展”,RFC 3779,2004年6月。

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

[RFC4271]Rekhter,Y.,Ed.,Li,T.,Ed.,和S.Hares,Ed.,“边境网关协议4(BGP-4)”,RFC 42712006年1月。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.

[RFC5280]Cooper,D.,Santesson,S.,Farrell,S.,Boeyen,S.,Housley,R.,和W.Polk,“Internet X.509公钥基础设施证书和证书撤销列表(CRL)配置文件”,RFC 52802008年5月。

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.

[RFC6480]Lepinski,M.和S.Kent,“支持安全互联网路由的基础设施”,RFC 6480,2012年2月。

[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.

[RFC6482]Lepinski,M.,Kent,S.,和D.Kong,“路线原产地授权(ROA)的配置文件”,RFC 64822012年2月。

8.2. Informative References
8.2. 资料性引用

[BGP-PFX] Mohapatra, P., Ed., Scudder, J., Ed., Ward, D., Ed., Bush, R., Ed., and R. Austein, Ed., "BGP Prefix Origin Validation", Work in Progress, October 2011.

[BGP-PFX]Mohapatra,P.,Ed.,Scudder,J.,Ed.,Ward,D.,Ed.,Bush,R.,Ed.,和R.Austein,Ed.,“BGP前缀原产地验证”,正在进行的工作,2011年10月。

   [IANA-AS]  IANA, "Autonomous System (AS) Numbers",
               http://http://www.iana.org/assignments/as-numbers
        
   [IANA-AS]  IANA, "Autonomous System (AS) Numbers",
               http://http://www.iana.org/assignments/as-numbers
        

[NLRI-ORIG] Bates, T., Bush, R., Li, T., and Y. Rekhter, "DNS-based NLRI origin AS verification in BGP", Work in Progress, January 1998.

[NLRI-ORIG]Bates,T.,Bush,R.,Li,T.,和Y.Rekhter,“BGP中基于DNS的NLRI来源验证”,正在进行的工作,1998年1月。

Authors' Addresses

作者地址

Geoff Huston APNIC

杰夫·休斯顿呼吸暂停

   EMail: gih@apnic.net
        
   EMail: gih@apnic.net
        

George Michaelson APNIC

乔治·迈克尔森呼吸暂停综合征

   EMail: ggm@apnic.net
        
   EMail: ggm@apnic.net