BGPsec技术要求 BGPsec协议

本文件定义了边界网关协议的扩展协议BGPsec,为BGPUPDATE消息传输提供安全的自治系统路径。BGPsec通过可选的BGP路径属性携带由每个AS生成的数字签名进而广播UPDATE消息。数字签名保证在UPDATE消息中列出的AS路径上的每一个AS是已经授权的路由通告。本文件适用于使用BGP协议的数据中心网络、运营商网络和内容服务商网络等场景。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。BGPsec协议规范(BGPseProtocolSpecification)BGPsec对自治系统(AS)BGPsec操作注意事项(BGPseeOperationalConsiderations)BGPse算法、密钥格式和签名格式(BGPseeAlgorithms,KeyFormats,andSignature3术语和定义本文件无术语定义下列缩略语适用于本文件。AFI地址族标识符BGP边界网关协议BGPsoc边界网关安全扩展协议EBGP外部边界网关协议ECDSA椭圆曲线数字签名算法HTTP超文本传输协议IANA互联网数字分配机构IBGP内部边界网关协议ROA路由起源授权RPKI资源公钥基础设施AddressFamilyldentifierBorderGmtewayProtoBorderGatewayProtocolExtemalBorderGatewayProtocolEllipticCurveDigialSignatureTheInternetAssignedNumbersAuthorityInternalBorderGatewResourcePublicKeyInfnastruc2SKI主体密钥标识符SubjoctKeyIdentife本文件定义了BGPsec,一种为BGP路由通告提供路径安全的的机制。即加密后的BGP发言人接收到有效的BGPsceUPDATE消息，通告的路由具有以下属性：UPDATE消息中列出的路径上的每个自治系统(AS)对于后续的AS都是经过授权的路由通告。本文件定义了可选的(非传递)BGP路径属性BGPsec_PATH,并且规定了兼容BGPsec的BGP发言人(以下称为BGPscc发言人)如何生成，传播，并验证包含BGPscc_PATH属性的BGPUPDATE消息。BGPsec旨在用于补充BGP源验证，与源验证一起使用时，可以防止多种针对BGP的路由劫持的攻BGPsec依赖于资源公钥基础架构(RPKI)证书对分配的AS号码和IP地址资源进行认证。任何BGPsec发言人向外部网关路由器发送包含BGPscc_PATH的BGPUPDATE消息，应拥有一个私钥，该私钥为与BGPscc发言人的AS号码对应的RPKI路由器证书。BGPsec发言人验证收到的包含BGPsec_PATH属性的UPDATE消息并不需要此证书。本文件定义了允许BGP发言人向邻居节点发送或接收BGPseUPDATE消息的BGP功能(即包含BGPsec_PATH属性的UPDATE消息)。该功能实现应遵循ETFRFC8205第2章的要求此功能具有功能代码7。此功能的功能长度应设置为3。图1中规定了3字节的功能格式。图1BGPsee功能格式第一个字节的前4位表示BGP发言人通告支持的BGPsec版木。本文件仅定义BGPsec版本0(所有4位设置为0)。其他BGPscc版本值可以在将来的文档中定义。BGPsec发言人可以通过在BGPOPEN消息中包括BGPsec功能的多个版本号来通告支持多个版本的BGPsec.第一个字节的第五位是方向(Dircction)位，表示BGP路由器是正在发送BGPse的UPDATE消息或是接收BGPsccUPDATE消息。BGP路由器将此位设置为将此位设置为1表示发送BGPseeUPDATE消息。第一个字节的剩余3位未分配并且将来也不会再分配。这些位由发送者设置为0,接收者可忽略这些位的值。3第二和第三个字节包含16位地址族标识符，表示BGPsc路由器通告支持BGPsce的地址族。此文档指定BGPsec使用IPv4和IPv6两个地址族，AFI值分别为1和2。BGPsec使用的其他地址族可能会在将来的为了表明BGP发言人可以发送BGPsceUPDATE消息(针对特定地址族),BGP发言人将Direction位(第一个字节的第五位)设置为1发送BGPscc功能。为了表示路由器可以接收包含BGPsec_PATH属性的BGPUPDATE消息(针对特定地址族),BGP发言人将Direction位设置为0发送BGPsec功能。为了表明可以发送和接收BGPsecUPDATE消息，BGP发言人发送两条BGPsec功能报文(一个Direction位设置为0.一个Direction位设置为1)。同样。如果BGP路由器希望在同一个BGP会话中使用两个不同地址族应用BGPsec功能(即IPv4和IPv6),路由器应在BGPOPEN消息中包括两个实例(每个地址族对应一个)。BGP路由器如果不支持BGP多协议扩展，则不应宣告支持BGPsec功能。另外，一个BGP路由器只有支持了AFI多协议扩展，才能宣告支持特定的AFI的BGPsec功能。在BGPsec会话中，某一对等体允许发送包含BGPsce_PATH属性的UPDATE消息，当且仅当： 某个对等体应将Direction位设为1,发送指定的BGPse版本号和地址族： 一个对等体(接收节点)应将Direction为设为0,发送相同的BGTPsec版本号和地址族。在这样的会话中，对指定的地址族协商使用了指定版本的BGPsec。不管BGPsec是否协商成功，传统的BGPUPDATE消息(即未签名，包含AS_PATH属性)都可以在会话中发送。但是，如果BGPsec未协商成功，则BGPUPDATE不得发送包含BGPsee_PATH属性的消息。本文档定义了在具体实施过程中BGPsec版本号0为唯一协商成功的版本。未来文档中如指定BGPsec其他版本，需要定义在支持多个版本协商的情况下的协商行为。如果路由器不支持4字节A8号，BGPsec无法提供有意义的安全保障。因此，任何宣告支持BGPsee功能的BGP发言人，还应宣告支持4字节AS号的功能。如果BGP路由器支持BGPsec功能但是不支持4字节AS号，那么BGPsec不能成功协商，并且包含BGPsee_PATH属性的UPDATE消息不得在会话中发送。BGPsePATH属性是可选的非传递BGP路径属性。BGPsee_PATH属性携带传输UPDATE消息通过的AS路径有关的安全信息，其中包括用于保护路径信息的数字签名。包含BGPsc_PATH属性的UPDATE消息被称为“BGPsceUPDATE消息”。在BGPsceUPDATE消息中，BGPsce_PATH属性应替代AS_PATH属性。即包含BGPsce_PATH属性的UPDATE消息不应包含AS_PATH属性，反之亦然。BGPsee_PATH属性由几个部分组成。图2中提供了关于BGPsee_PATH属性的整体结构。图3提供了BGPsee_PATH格式的规范属性Secure_Path包含BGPseUPDATE的AS路径信息，等同于包含在非BGPsecAS_PATH属性中的信息。Secure_Path的格式在7.2节中进行了描述。BGPsee_PATH属性将包含一个或两个Signature_Blocks,每个对应于不同的算法。Signature_Blocks将包含Secure_Path中每个AS号的签名段。一般情况下，BGPsee_PATH属性只包含一个Signature_Block。但是，为了实现在过渡期间从旧的算法到新的算法的转换。有必要包括两个Signature_Blocks(一个用4于旧算法和一个用于新算法)。(有关更多讨论，请参阅第10.1节算法转换。)Signature_Blocks的格式是如下面的7.3节所述。此处提供了BGPscc_PATH属性中的Sccure_Path的详细说明。图4和图FlagsX 图2BGPscc_PATH属性的架构图SecurgPathvariSequenceofoneortwoSignabure_Block图3BGPsce_PATH属性格式Secure_Path长度包含整个Secure_Path的长度(包括2个字节用于表示此字段长度)。如下所述，每个Secure_PathSegment为6个字节长，这意味着Secure_PathLength长度为6*Secure_PathSegment(即。路径中的AS号数量)+2字节。Secure_Path包含一个Secure_PathSegment(请参见图5),用于的每个AS的前级。(注意：重复的AS会使用pCount字段，如下所述。)5Comfed_Segmentflag(lbio|Unassigned(7bis)图5Secure_PathSegment格图5中的AS号是将此Secure_Path段添加到BGPscc_PATH属性的BGP发言人的AS号。(有关填充此字段的更多信息，请参见第8章。)pCount字段包含签名涵盖的AS号的重复次数。启用此字段，可以使BGPsec通告的AS_PATH中包含多个相同的AS号，而无需生成多个签名。AS_PATH属性中的“AS号数量”在路径选择过程中将使用其定义参见IETFRFC4271第节。该指标(AS号数量)与BGPsee中的AS路径长度相同，通过对BGPsee_PATH属性中的pCount值求和来计算。pCount字段也应用在管理路由服务器(见8.2节),AS联盟(见8.3节)和AS号迁移等场景。图5最左边的标志(即最高有效)位是Confed_Segmentflng。Confed_Segmentflag设置为1表示构造此Secure_PathSegment的BGPsee发言人正在给相同的AS联盟内的对等体发送UPDATE消息。(即，在BGPseeUPDATE消息中设置了连续的Confed_Segment标志，而在非BGPseeUPDATE消息中，AS_PATHsegment中类型为AS_CONFED_SEQUENCE的标志被设置。)在其他情况下，Confed_Segment标志设置Flags字段的其余7位未分配。发送方应将其设置为0,接收方应将其忽略。签名按照所有8位标志字段计算。如第6.2节所述，BGPsec路由要求每个AS都支持4字节的AS号。目前己分配的2字节的AS号码可以通过将高位2字节设为0的方式转换为4字节的AS号码。BGPseePATH属性中的SipgatureBlocks使用图6和7提供详细说明。图6中的Sigmature_BlockLength是Signature_Block的所有字节长度(包括用于表示长度字段的2个字AlgorithmSuiteldentifer是一个1字节的标识符，用于指定产生每个签名段中的数字签名的摘要算法和数字签名算法。AlgorithmSuiteldentifier的IANA注册表在BGPscc算法文档中进行定义。图7中的SubjectKeyIdentifier(SKI)字段包含RPKI路由器证书的SubjectKeyIdentifier的值，用于验证签名(请参阅第9节有关BGPsecUPDATE消息的有效性的详细信息)。SKI字段的固定大小为20个字节。参见10.2节关于SKI的大小。SignatureLength字段为Signature图7中的Signature字段包含一个数字签名，用于保护前级和BGPsec_PATH属性。8.1BGPseeUPDATE消息规范该节提供了有关创建BGPsecUPDATE消息的一般指导——即包含BGPsee_PATH属性的UPDATE受签名保护的BGPsceUPDATE消息中包括更新消息发送对象的AS号。因此，如果BGPsec发言人希望向多个路由器发送多条BGPsceUPDATE消息，它应对每个不同的AS生成一个单独BGPseUPDATEBGPseeUPDATE消息应仅向单个前缀播发路由。这是因为BGPscc发言人如果收到UPDATE消息中包含多个路由前级，将无法构造有效的包含以下内容子集的BGPsecUPDATE消息(即有效路径签名)如果BGPsec发言人希望通告到多个路由前级，则应为每个前级单独生成一个BGPsceUPDATE消息。此BGPsee_PATH属性和AS_PATH含AS_PATH属性。在AS_PATH属性中包含的内容在BGPsee_PATH属性的Sccure_Path部分中传输。为了使用给定的算法向BGPseeUPDATE消息创建或添加新签名，BGPsec为此算法生成签名的私钥。此外，此私钥应与RPKI终端实体证书中的公钥相对应，证书中其AS号资源扩展包括BGPsec发言人的AS号。当BGPsee发言人生成UPDATE消息发送给外部对等体时，新签名仅添加到BGPseeUPDATE消息中(即，当对等体的AS号不等于BGPsec发言人自己的AS号)。RPKI使IP地址前缀的合法持有者能够颁发一个签名的对象/称为ROA,该对象授权给定的AS向一组给定的前煅发起路由。预计多数依赖方(RP)将与源路由验证一起使用BGPsee。如果BGPsec路由器仅收到包含AS_PATH属性的非BGPseeUPDATE消息(而不是BGPse_PATH属相反，如果BGPsec路由器已从对等方接收到针对给定前缀的BGPsec更新消息(具有BGPsec_PATH属性),并选择传播该对等方针对该前缀的路由，则应将该路由作为包含BGPsec_PATH属性BGPsee删除BGPsec签名(例如广播没有BGPsec_PATH属性的路由通告)具有严重的安全风险。(请参见第12.2节)因此，当通过BGPsecUPDATE消息接收到路由通告时，不建议传播不带BGPse_PATH属性7的路由公告，除非将消息发送给宜告没有接收BGPseeUPDATE消息的能力的对等体(请参阅第8.4此外，请注意当BGPsc发言人宣告路由时带有BGPsec_PATH属性时，不能证明收到的UPDATE消息的验证状态。如果BGPsce发言人正在生成一条包含AS_SET的非BGPscc的UPDATE消息，则BGPscc发言人不应包括BGPscc_PATH属性。在这种情况下，BGPsec发言人应删除接收到的任何有BGPsce_PATH此前缀的路由通告，并生成传统的(非BGPsec)UPDATE消息。建议不要在BGPUPDATE消息的AS_PATH中使用AS_SET和AS_CONFED_SEBGPsec发言人将BGPseeUPDATE消息发送给iBGP(内部BGP)对等点非常简单。发起新的路由通告并将其发送到支持BGPsce的iBGP对等体时，BGPsee发言人会忽略BGPse_PATH属性。发起新路由通告并将其发送到非BGPseciBGP对等体时，BGPsec发言人在UPDATE消息中包括一个空的AS_PATH属性(空的AS_PATH属性其长度字段包含值0)。当BGPsec发言人选择将BGPseUPDATE消息转发给iBGP对等体时，除非对等方不支持BGPsee,否则不应删除BGPsec_PATH属性。如果iBGP对等体不支持BGPsec,则由BGPseeUPDATE消息应重建带有AS_PATH属性的BGPUPDATE消息然后转发(请参阅第8.4节)。尤其是转发到支持BGPsec的iBGP(或eBGP)对等体时，即使BGPseeUPDATE消息尚未成功验证，也不应删除BGPsee_PATH属性(有关验证的更多信息请参见第9章，有关刑除BGPsec签名的安全后果请参见第12章)。所有BGPseeUPDATE消息应符合BGP的最大消息长度。第8.2节指定BGPsec发言人如何生成包含在BGPseeUPDATE消息中的BGPse_PATH属性。第8.3节包含针对AS联盟成员的特殊处理说明。非联盟成员的BGPsee发言人不得在它发送的所有BGPseeUPDATE消息中设置Secure_PathSegment中的Confed_Segment志保留为默认值0)。第8.4节包含有关在BGPsec发言人收到带有BGPse_PATH属性的UPDATE消息，并希望向不支持BGPsec的路由器发送UPDATE消息的情况下，重建AS_PATH属性的说明当BGPsec发言人收到来自(内部或外部)对等方包含BGPsee_PATH属性(具有一个或多个签名)的BGPsecUPDATE消息时，它可以选择发送路由公告给其他(内部或外部)对等方。当将路由通告发送给内部BGPsec对等方时，BGPsec_PATH属性不得修改。当将路由通告发送给外部BGPsec对等方时，以下过程用于生成或更新BGPsee_PATH属性。要在发出的UPDATE消息上生成BGPstePATH属性，BGPscc发言人首先生成一个新的Secure_PathSegment。请注意如果BGPsec发言人不是原始AS并且已经有BGPsee_PATH属性，则BGPsec发言人会为其将新的Secure_PathSegment预先添加到(放在第一位)现有的Secure_PathSegment上。Secure_PathSegment中的AS号应与RPKI路由器证书的Subject字段中的AS号匹配，该证书将用于验证此BGPsec发言人构造的数字签名。Secure_PathSegment的pCount字段通常设置为1。但是，BGPsec发言人可以将pCoumt字段设置为大于1的值。将pCount字段设置为比1大的值，相当于在非BGPsec更新消息的AS_PATH中重复多次AS号码为防止在BGPsec签名验证中处理不必要的负载，一个BGPsec发言人不应产生多个具有相同AS号的连续Secure_Path段。这意味着实现将相同AS编号添加k次，BGPsec发言人应该产生一个Secure_PathSegment(pCount为k)和一个相应的SignatureSegment.参与BGP控制层但不作为数据层中转接AS的路由器，可以选择pCount设置为0。此选项使路由器可以参与BGPsec获得相应的安全保证而无需增加AS路径的长度。(BGPsec发言人通过BGPse_PATH属性中的pCount值求和来计算AS路径的长度，参见第9章。)但是，当路由器将pCount值设置为0时，仍需将AS号插入Secure_PathSegment,因为需要此信息来验证路由器添加的签名。8接下来，BGPsec发言人生成一个或两个Signature_Block。通常，BGPsec发言人仅使用单个算法仅在BGPscc_PATH中创建一个Signature_Block属性。但是，为了确保在向后兼容从“当前”算法套件到“新”算法的过渡时期算法套件，有必要发出UPDATE消息同时包含“当前”和“新”的Signature_Block算法套件(请参阅第6.1节)。如果收到的BGPsceUPDATE消息中包含两个Signature_Blocks并且BGPse发言人支持相应的两种UPDATE消息中包含两个Signature_Blocks,BGPsec发言人仅支持两个相应算法套件中的一种，则BGPsce发言者应删除它不了解的算法套件相对应的Signature_Block。如果BGPsec发言人不支持任何包含在收到的UPDATE消息中的Signature_Blocks中的算法套件，则BGPsec发言人不得使用BGPsee_PATH的公告属性传播路由。(也就是说，如果它选择传播此路线通告，应作为未签名的BGPUPDATE。)在BGPsec_PATH具有两个Signature_Blocks的情况下(对应于不同的算法套件),如果至少有一个支持的算法套件(以及相应的Signature_Block)视为有效，则验证算法将BGPsecUPDATE消息视为“有效”。这表示“有效”的BGPseUPDATE消息可能包含无效的Signature_Block(例如，包含BGPsee的签名无法成功验证)。尽管如此，这样的Signature_Blocks不应删除。对于BGPsec发言人支持的与算法套件相对应的每个Signature_Block,BGPsec发言人应添加新的签名段至SignatureBlock。此签名段是放在签名段列表的前面(放在第一个位置),以使签名段列表显示的顺序与Secure_Path相同。BGPsec发言人填充后续的此新签名段的字段。新段中的SubjectKeyldentifier字段用BGPsec发言人对应的RPKI路由器证书的SubjectKeyIdentifier扩展标识符进行填充。路由通告的接收方将使用此SubjectKeyldentifer来标识用于验证签名的适当证书。新分段中的Signature字段包含数字签名，该签名将前级和BGPsec_PATH属性绑定到相应BGPsec发言者的RPKI路由器证书。数字签名计算如下：为了清楚起见，我们为Secure_Path和对应的签名段从1到N进行编号，如下所示。让Secure_PathSegment1和SignatureSegment1由源AS产生的。令Secure_PathSegment2和SignatureSegment2为下一个AS添加的段。继续这个编号方法，并最终让Secure_PathSegmentN和SignatureSegmentN是当前AS正在添加的部分。当前的AS(第N个AS)正在签名并转发UPDATE消息到AS链中的下一个AS(即第(N+为了构造用于签名的SignatureSegmentN(当前生成的签名段AS),首先要构建如下图8中所示的字节序列的哈希。此字节序列包括所有第N个AS数据，通过第(N+1)个AS转发到BGPsec发言人的UPDATE消息中。SceurePathSegment:29图8待哈希的字节序列此序列中的元素应正确排序如图8所示。“TargetASNumber”是BGPsee发言人打算发送UPDATE消息的AS。(“TangetASNumber”是发送UPDATE消息的BGP会话中包含的OPEN消息里对等方通告的AS号。)Secure_Path和SignatureSegments(1到N-1)是从BGFamilyIdentifier(AFI),SubsequentAddressFammilyIdentifier(SAFI)和NLRI字段应从MP_REACH_NLRI属性中获得。此外，在NLRI字段中的Prefix字段中，构造此序列时所有尾随位应设置将摘要算法应用于此字节序列(参见图8)(用于此Signature_Block的算法套件)以获取摘要值。将签名算法应用于此摘要值(对于此Signature_Block的算法套件)以获取数字签名。然后使用数字签名填充Signature字段(参见图7)。使用Signature字段中的长度值填充SignatureLength字段(参见图7)。8.3联盟成员处理说明AS联盟的成员还应遵循本节中有关处理BGPsecUPDATE消息的说明。当AS联盟中的BGPse发言人从联盟外部的对等方接收到BGPsecUPDATE消息并选择在联盟内传播更新消息时，它首先添加签名给其自己的成员AS(即“TargctAS”编号是BGPscc发言人的Member-AS编号)。在这个内部修改的UPDATE消息中，新添加的Securc_Path段包含公共AS编号(即ConfederationIdentifier),该段的pCount值设置为0,并且Confed_Segment标志设置为1。在这种情况下设置pCount=0有助于确保AS路径长度没有不必要地增加。根据联盟的公共AS编号，新添加的签名使用对应的私钥生成。BGPsec发言人将修改后的UPDATE消息广播到其联盟内部的对等节点。在联盟内传播更新消息的上下文中，下面提到的任何BGPsec_PATH修改是对上述修改的补充。当BGPscc发言人向属于其自身成员AS的对等体发送BGPsceUPDATE消息时，联盟成员不得修改BGPsec_PATH属性。当BGPsec发言人向同一个联盟中但在其他Member-AS中的对等方发送BGPsceUPDATE消息时，BGPsec发言人将其Member-ASNumber添加到BGPsecUPDATE消息的Scure_Path段Confed_Segment标志位为1。进一步，使用与BGPscc发言人的成员Member-AS号相对应的私钥生成签名。(注意在本文档中，将intra-Mcmber-AS对等体视为iBGP,inter-Member-AS对等体被视为eBGP。后者也是称为confederation-cBGP在联盟内部，由联盟的其他成员添加BGPscc签名的验证是可选的。如果联盟选择不验证内部的数字签名，则BGPsec无法提供任何关于放置在Secure_PathSegment中的Member-AS号的完整性的保证，其中Secure_PathSegment中的Confed_Se联盟成员从联盟中的对等方接收到BGPseeUPDATE消息并将其传播到联盟外部时，需要删除所有由联盟成员添加的Secure_PathSegment以及相应的签名。为此，联盟成员广播至外部的路由执行以下操首先，从最近添加的Secure_PathSegment开始，删除所有Confed_Segment标志设置为1的连续的Secure_Path段。到达Confed_Segment标志设置为0的Secure_PathSegmeat则停止，记下删除的段数。其次，从最近添加的SignatureSegment开始，删除数量与上一步中删除的Secure_PathSegment数量最后，在AS字段中添加一个Secure_PathSegment,其中包含AS联盟标识符(联盟公开AS号)以及相应的SignatureSegment。注意应根据第8.2节填充除AS字段以外的所有其他字段最后，如上所述，AS联盟可以选择决定其成员将不验证由成员添加的数字签名。在这样的联盟中Confed_Segment标志是否设置为1。如果标志设置为1,则BGPscc发言人应跳过对相应签名的验证并立即移至下一个Scure_PathSegment。注意如第9.2节中所述，当BGPscc发言人接收到不在同一个AS联盟中的对等方发送的，包含Confed_Segment标志设置为1的BGPsceUPDATE消息时，应视为错误。BGPseeUPDATE消息不包含AS_PATH属性。但是，AS_PATH属性可以从BGPsec_PATH属性进行重构。通过BGPseUPDATE消息接收路由通告，然后通过非BGPseeUPDATE消息传播到对等方时(例如，因为后者不支持BGPsee),这种情况下重构是必需的。可能有其他实施情况需要执行该重构过程。尝试重建AS_PATH之前将未签名的(非BGPsee)UPDATE消息转发到的目的对等方，BGPsec发言人应执行9.2节中基本的完整性检查，以确保收到的BGPseeUPDATE消息格式正确可以从BGPsee_PATH构造AS_PATH属性。从空白的AS_PATH属性开始，从最远添加的到最新添加的顺序开始处理Secure_Path段。对于每个Secure_Path段，执行以下步骤；1.如果Secure_PathSegment的pCount=0,则不执行任何操作(即，继续处理下一个Secure_Path2.如果SecurePathSegment的pCount大于0,并且Confed_Segment标志设置为1,然后查看最近在AS_PATH中添加的segment。如果AS_PATH为空白或最近添加的segment的类型为AS_SEQUENCE,则添加(在AS_PATH之前)一个新的段类型为AS_CONFED_SEQUENCE的AS_PATH。此类型为AS_CONFED_SEQUENCE的段应包含与当前安全路径段中的pCount字段相等的多个元素。这些元素中的每一个都应为当前Secure_Path段中包含的AS编号。(即，如果pCount字段为X,则类型为AS_CONFED_SEQUENCE的段包含SecurePathSegment的ASNumber字段的X个副本。)如果最新添加的AS_PATH中的segment类型为AS_CONFED_SEQUENCE,则在当前Secure_Path段中添加(在段前添加)与pCount字段相等的元素数。这些元素值应为当前SecurePathSegment包含的AS号。(即如果pCount字段为X,则将Secure_PathSegment的ASNumber字段的X份副本添加到现有的3.如果Secure_Pah段的pCoumt大于0,并且Confed_Segment标志设置为0,则查看最近在AS_PATH中如果AS_PATH为空白或最近添加的段的类型为AS_CONFED_SEQUENCE,则添加(在AS_PATH之前)新的AS_PATH段类型AS_SEQUENCE。AS_SEQUENCE类型的该段应包含与当前Secure_Path段中的pCoumt字段相等的多个元素。每一个元素中部应为当前Secure_PathSegment中包含的AS号。(即，如果pCount字段是X,则类型为AS_SEQUENCE的段包含Secure_PathSegment的AS号字段的X个副本。)如果最新添加的AS_PATH中的段类型为AS_SEQUENCE.则在当前Secure_Path段中添加(在段前添加)与pCount字段相等的元素数。这些元素值应为当前Secure_PathSegment包含的AS号。(即，如果pCount字段为X,则将SecurePahSegment的ASNumber字段的X份剧本添加到现有的作为上述过程的一部分，执行以下附加操作以保证不超过ASSEQUENCE和AS_CONFED_SEQUENCE的长度限制。在将下一个Secure_Path段添加到正在组装的AS_PATH时，如果会导致AS_SEQUENCE(或AS_CONFED_SEQUENCE)超出每段255个AS号的限制，则BGPsec发言人应创建另一个相同类型的片段(AS_SEQUENCE或AS_CONFED_SEQUENCE)并继续填充，参见IETFRFC5065的建议。最后，重建AS_PATH的一种特殊情况是缺少BGPsec_PATH属性。如第8.1节所述，当BGPsec发言人发出前缀并将其发送到支持BGPscc的iBGP对等方时，并未附加BGPscc_PATH。因此，当从支持BGPsec_PATH属性。9处理收到的BGPseeUPDATE消息9.1整体流程UPDATE消息执行来源验证，但是这种验证独立于本节中描述的验证。第9.2节是BGPsce验证概述，9.3节提供了执行这种验证的特定算法。(只要验证的输入输出行为与第9.3节中的算法相同，具体实现不必遵循第9.3节中的特定算法。)在特殊情况下(例如BGPsee发言人一次接收到数量惊人的UPDATE消息),BGPsec发言人可以暂时推迟对传入的BGPseeUPDATE消息的验证。此类已推迟其验证的BGPseeUPDATE消息的处理是本地策略的问题。但是，实现应确保验证的延迟和延迟消息的状态对运营商可见。BGPsecUPDATE消息的有效性是当前RPKI状态的函数。当BGPsec发言人得知RPKI状态已更改时(例如，通过RPKI-路由器协议从RPKI验证缓存中获取),BGPsce发言人应对存储在其Adj-RIB-In中的所有受影响的UPDATE消息重新运行验证。例如，当给定的RPKI路由器证书不再有效(例如过期或被吊销)时，应重新评估所有包含特定签名(其SKI与给定证书中的SKI匹配)的UPDATE消息，以确定它们是否仍然有效。如果此重新评估确定UPDATE消息的有效性状态已更改，则根据本地策略，可能有必要重新运行最佳路径选择。BGPsceUPDATE消息不应包含AS_PATH属性。Secure_Path包含BGPsecUPDATE消息的AS路径信息。因此，BGPscc发言人应在所有情况下使用Secure_Path中的AS路径信息，否则将使用AS_PATH属性中的AS路径信息。该规则的唯一例外是当应更新AS路径信息以将路由传播到对等方时(在这种情况下，BGPsce发言人遵循第8章中的说明)。第8.4节提供了一种从BGPsec_PATH属性构造AS_PATH属性的算法。每当需要使用AS路径信息时(例如，环路检测或在最佳路径选择中使用AS路径长度),该实现的外部可见行为应与该实现已运行第4.4节中的算法并且使用生成的AS_PATH属性一致，如同对非BGPsec更新消息一样。BGPseeUPDATE消息的验证使用了RPKI路由器证书中的数据。特别是，接收方应具有从有效RPKI路由器证书中获得的以下数据的访问权限：每个有效RPKI路由器证书中的AS编号，公钥和主题密钥标识符。BGPsee发言人可以自行执行RPKI路由器证书的验证并提取所需的数据，或者它可以从受信任的缓存中接收相同的数据，该缓存代表(一组)BGPsee发言人执行RPKI验证。(例如，可信级存可以通过使用针对RPKI-路由协议的路由密钥协议数据单元(ProtocolDataUnit,PDU),将必要的有效性信息为了验证包含BGPsec_PATH属性的BGPseeUPDATE消息，接收方应执行9.3节中指定的验证步骤。验证过程结果应是以下两种状态之一：“有效”和“无效”验证过程的输出期望能用作BGP路由选择的输入。也就是说，BGP路由选择以及验证状态的处理是本地策略的问题，并且使用本地策略机制进行处理。实现方案应使运营商能够在每个会话的基础上设置此类本地策略。(也就是说，对于通过不同的BGP会话接收到的UPDATE消息，预计某些运营商会选择不同的方式对待BGPsee验证状态。)BGPsec验证仅需要在cBGP边缘执行。根据AS内的本地策略，可以通过iBGP以某种机制将BGP签名/未签名UPDATE消息的验证状态从入口边缘路由器传递到出口边缘路由器。如第8章中所述，当BGPsee发言人选择转发(从语法上正确)BGPseeUPDATE消息时，应保持其BGPsee_PATH属性完好地转发(无论UPDATE消息的验证状态如何)。完全基于本地策略，从自己的AS内接收BGPsceUPDATE消息的出口路由器可以选择执行其自身验证。本节具体说明一种用于验证BGPseeUPDATE消息的算法。一致的实现应包括一种该算法外部可见行为的BGPsee更新验证算法。首先，BGPseeUPDATE消息的接收方应执行检查以确保该消息格式正确，违规错误。当从外部BGPsee对等方收到BGPseeUPDATE消息时，以及在将这种UPDATE消息传给内部BGPsee对等方时，应存在BGPsee_PATH属性(请参见第8.2节)。应执行错误检查，错误检查的指定参见IETFRFC4271第6.3节，但是对于BGPsceUPDATE消则应对BGPsee_PATH属性执行以下检查：1.检查以确保整个BGPsee_PATH属性在语法上正确(符合本文档中的规范)。2.检查最近添加的Secure_Path段中的AS编号与BGPOPEN消息中指定的对等方的AS号是否相匹配。(注意；此检查仅在首次从对等方AS接收到UPDATE消息的入口BGPse路由器上执行。)3.检查BGPsee_PATH属性的SecurePath部分中的每个SecurePah段，每个SignatureBlock是否包含一个签名段。(注意，即使在完成对所有签名的密码验证之前验证过程可能会终止，也应检查每个Signature_Block的全部内容以确保其结4.检查UPDATE消息是否不包含AS_PATH属性5.如果从不是BGPsee发言人AS联盟成员的BGPsee对等方收到UPDATE消息，应检查以确保所有Secure_Path段均不包含Confed_Segment标志设置为1的Flags字段。6.如果从BGPsec发言人AS联盟成员的BGPsec对等方收到UPDATE消息，应检查以确保与该对等方相对应的SecurePath段包含一个Confed_Segment标志设置为1的标志字段。7.如果从不应设置pCouat-0的对等方接收到的UPDATE消息，则应检查以确保最新添加的SecurePath段中的pCount字段不等于0。8.在UPDATE消息中使用与Secure_Path对应的等效AS_PATH时，应检查本地AS号码是否在AS路径中不存在(即排除AS循环)。如果任何一项以上检查失败，则说明BGPsecPATH属性中存在错误。BGPsee发言人应使用定义的“撤回方式”处理BGPsec_PATH属性中的任何语法或协议错误(注意：由于透明路由服务器的AS编号确实出现在SecurePath中，且pCount-0,路由服务器可能会检查它的本地AS号码是否列在Secure_Pah中，并且此检查可能包含在上面列出的循环检查中)接下来，BGPsee发言人检查BGPsee_PATH属性中的Signature_Blocks。验证过程中不会考虑与BGPsec发言人不支持的算法套件相对应的Sigature_Block。如果没有与BGPsee发言人支持的算法套件相对应的Signature_Block,则为了在路由选择过程中考虑UPDATE消息，BGPsec发言人应剥离Signature_Block(s),从Secure_Path重构AS_PATH息。对于每个剩余的Signature_Block(对应于BGPsce发言人支持的算法套件),BGPsee发言人遍历Signature_Block中的签名段，从最近添加最多的段开始(并以最近最少添加的段结束)。BGPsec_PATH属性中的签名段和Secure_Path段之间存在一一对应的关系。以下步骤使用此对应关系：步骤1:令在接收的BGPscc_PATH属性中有K个AS跳数待验证。令AS(1),AS(2),..,AS名段N指与AS(N)对应的部分(其中N=1、2,.,K)。正在处理和验证BGPsee_PATH属性的BGPsee步骤2:找到验证签名所需的公钥(在当前签名段中)。为此，应查阅有效的RPKI路由证书数据，并查找所有其中AS与相应Secure_Path段中的AS编号匹配的三元组(AS编号，公钥，主题密钥标识步骤3:根据适当的数据计算摘要函数(对于给定的算法套件)。为了验证签名段N的数字签名，构造要计算哈希的八位字节序列，如图9所示(使用步骤1中定义的符号)。(此序列与创建签名段N的AS(N)使用的序列相同。)NLRI图9:签名验证所需的待哈希字节序列第一个段(最近添加的段(即N-K)假定Secure_1),BGPsee发言人验证UPDATE消息的AS编号。如果BGPsee发言人使用多个AS号(例如，BGPsec发言人是联盟的成员),这里使用的AS号应是接收BGPsecUPDATE消息的BGP会话中OPEN消息声对于每个其他签名段(N小于K),“目标AS编号”为AS(N+1),Secure_Path段中的AS编号Secure_Path和签名段应从BGPsec_PATH属性获得。AFI,SAFI和NLRI字段应从MP_REACH_NLRI属性获得。另外，在NLRI字段内的Prefix字段中，在构造此序列时，所有末尾位都应设置为0.步骤4:应使用签名验证算法(针对给定的算法套件)来验证当前段中的签名。即，在以下三个输入上调用签名验证算法：当前段中Signature字段的值，在上面的步骤3中计算的摘要值以及从前述步骤2中的有效RPKI数据获得的公钥。如果签名验证算法确定签名无效，则将整个Signature_Block标记为“无效”,然后继续下一个Signature_Block。如果签名验证算法确定签名有效，则继续处理签名段(在如果Signature_Block中的所有签名段都通过了验证(即，所有段都已处理且Signature_Block尚未标记为“无效”),则Signature_Block被标记为“如果至少一个Signature_Block标记为“有效”,则验证算法终止，并且BGPsceUPDATE消息应被视为“有效”。(也就是说，如果BGPsceUPDATE消息包含两个Signaturne_Block,则如果第一个Signature_Block标记为“有效”,或者第二个Signature_Block标记为“有效”,则UPDATE消息被视为10算法和可扩展性使用特定的(摘要和签名)算法套件时，当前没有BGPsee对等方之间的双边协商(使用BGP功能)的支持。因为BGPseeUPDATE消息的发送者使用的算法套件不仅应由直接向其发送消息的对等方对等方协商的本地问题，而应在整个互联网上进行协调。为此，IETFRFC8208指定了供所有BGPsec发言人强制使用的“当前”算法套件7和第8章指定了BGPsce_PATH属性如何同时包含两个算法套件的签名)。转换完成后，将不推荐使用旧的“当前”算法，而应使用“新”算法，并且可以将随后的“甚至更新的”算法套件根据生成密钥标识符的方法，RPKI路由器证书中SKI的大小可能会有所不同。BGPsce_PATH属性中的SKI字段具有20个(八位)字节的固定大小(请参见图7)。如果SKI的长度超过20个字节，则使用SKI的最左边的20个字节(不包括标签和长度)。如果SKI值短于20个字节，则应将SKI(不包括标签和长度)的右侧填充(最低有效字节),用值为“0”的字节填充。本节讨论BGPsee的潜在更改，这需要对BGPsce_PATH的处理进行实质性更改，因此需要新版本的BGPscc。此类更改的示例包括：1、一种新型的签名算法，可以生成可变长度的签名。2、一种新型的签名算法，其Signature_Block中的签名数3、更改受BGPsce签名保护的数据(例如。AS路径以外的属性)。如果认为对BGPsee进行这种更改是可取的，预期将创建后续版本的BGPscc,并且此版本的BGPsee将指定新的BGP路径属性，可将其称为“BGPse_PATH_Two”此时，将开始进行类似于10.1节中讨论的算法过渡转换的过程。在过渡期都应同时包括BGPscc_PATH属性和新的BGPsec_PATH_Two属性。转换完成后，便可以弃用BGPsec_PATH,此时BGPsee发言人仅应包括新的BGPse_PATH_Two属性。这样的过程可以以向后兼容的方式促进向新BGPsee语义的过渡。11操作和管理注意事项11.1能力协商失败第6.2节介绍了建立支持BGPsee的对等会话所需的协商。不仅应交换(并商定)BGPscc功能，而且还应交换相同AFI和4字节AS的BGP多协议扩展。如果由于缺少功能等原因造成无法正确协商BGPsee会话，可能仍会导致BGP(未签名)UPDATE消息的交换。建议实现记录未能正确协商BGPsee会话的故障。另外，如果配置为仅使用BGPsee,则实现应能够阻止BGP会话的建立。具有透明AS的Internet交换点(IXP)(即路由服务器)的对等方应在将UPDATE消息转发给对等Secure_Path段中设置pCount-0。这也意味着应对BGPsee发言人进行配置，以便允许来自IXP对等方的pCount-0。将pCount设置为0的另外两种情况是在AS联盟和AS迁移的上下文中。在这两种情况下，在同一AS中设置并接受pCount=0(尽管AS具有两个不同的身份)如果BGPsec发言人不希望对等方AS设置其pCount=0,并且从该对等方接收到的UPDATE消息违反了该要求，则应将UPDATE消息视为错误。有关pCount=0的安全注意事项的讨论，请参见第12.4节。11.3提前终止签名验证在验证BGPseeUPDATE消息期间，可以通过合并以下观察来实现路由处理器性能的提高。如果至少其中一个Signature_Blocks被标记为“有效”,则UPDATE消息被视为“有效”。因此，如果一条UPDATE消息包含两个Signature_Blocks,并且第一个已验证的消息为“有效”,则第二个Signature_Block不必进行验证。并且，如果UPDATE消息被选择为最佳路径，则BGPsce发言人将其签名(使用各自Signature_Blocks中至少一个签名无效，则BGPseeUPDATE消息将被视为“无效”。该原则还可用于节省路由处理器的工作量。即当遇到第一个无效签名时，Signature_Block的验证会提前终止。11.4非确定性签名算法许多签名算法是不确定的。也就是说，许多签名算法每次运行时都会产生不同的签名(即使它们使用相同的密钥对相同的数据签名)。因此，如果BGPsec路由器从对等方接收到BGPsceUPDATE消息。然后又从同一对等方接收到具有相同Secure_Path和SKIs的相同前缀的第二个BGPseeUPDATE消息，则第二个UPDATE消息的签名字段可能与第一个UPDATE消息不同(对于非确定性签名算法)。但是。如果发件人缓存并重用以前的签名，则两组签名字段将不会有所不同。对于确定性签名算法，这两个更新消息之间的签名字段应相同。基于这些观察，实现可以在更新验证处理中合并优化。ISP的存根客户可能使用私有AS号码。这样的存根客户不应在全球RPKI中为他们使用的专用AS号和前级发布ROA。此外，全球RPKI无法支持私有AS编号(即，在全球RPKI中不应向专用AS中的BGPsee发言人发出路由器证书)。对于存根客户(具有私用AS编号)和ISP之间的交互，可能出现以下两种情况：1.存根客户向ISP的AS发送未签名的BGPUPDATE消息作为前缀。ISPAS中的边缘BGPsee发言人可以选择将前鳗传播到其非BGPsee和BGPsee对等方。如果是这样，则ISP的边缘BGPse发言人应剥离带有私有AS编号的AS_PATH,然后(a)向其非BGPse对等方重新创建没有任何签名的前级，以及(b)向其BGPsee对等方重新发送包含其自身签名的前级。在这两种情况下。(即(a)和(b)),前缀应在全球RPKI中具有ROA,以授权ISP的2.ISP和存根客户可以使用本地RPKI资料库。然后，对于存根AS发起的前缰可以有一个ROA并且存根AS中的cBGP发言人可以是具有路由器证书的BGPsee发言人，尽管ROA和路由器证书仅在本地有效。通过这种安排，存根AS将签名的UPDATE消息作为前级发送给ISP的AS。ISPAS中的边缘BGPsce发言人使用基于本地RPKI视图的RPKI数据来验证UPDATE消息。此外，它可以选择将前级传播到其非BGPsee和BGPsee对等方。如果是这样，则ISP的边缘BGPsee发言者务必使用私有AS编号剥离从存根AS收到的Secure_Path和签名段(SignatureSegment),然后(a)向其非BGPse对等方重新发送没有任何签名的前级：(b)向其BGPsee对等方重新发送包含其自身签名的前级。在这两AS联盟中可能使用私有的AS编号，BGPsce协议要求，当BGPsceUPDATE消息通过联盟传播时将其转发给对等成员AS的每个Member-AS都应对UPDATE消息签名(请参阅第8.3节)。但是，全球RPKI无法支持专用AS号。为了使具有专用AS编号的Member-AS中的BGPsee发言人具有数字证书。联盟中应存在一种机制，该机制允许建立RPKI的本地定制视图，根据需要扩充全球RPKI存储库数据。由于此机制(用于扩充和维护RPKI数据的本地映像)在AS或AS联盟内本地运行，因此不强制要求使用基于标准的机制。为了防止暴露AS联盟的内部，导出到非成员的BGPsee发言人会删除所有联盟内部的Secure_Path段和签名(请参阅第8.3节)。11.6访问RPKI数据的鲁棒性注意事项IETFRFC8207等文档中描述了与全球RPKI数据(通过本地RPKI缓存)到达路由器有关的部署结构，技术和最佳做法。例如，基于序列号的增量更新机制用于有效传输自上次更新以来已更改的数据记录。信任方(RelyingParties,RPs)使用更新通知文件来发现全球RPKI存储库的状态和RP的缓存之间是否存在任何更改。该通知描述了(1)包含快照的文件和(2)增量，RP可以使用其与资料库同步。利用这些技术和最佳实践，从资料库到RPKI缓存再到路由器的RPKI数据流，就可以实现BGPsee路由器和RPKI缓存的鲁棒性，效率和更好的安全性。通过这些机制，可以认为攻击者无法将RPKI数据流与BGPseeRP(或路由器)操作有意义地关联起来，因此避免了可能试图通过RP和RPKI服务器之间的交互来确定与RP交互的AS集的攻击11.7平滑重启在平滑重启期间，重启和接收BGPsec发言人应分别按照指定的过程进行，具体流程参见IETFRFC4724第4章的内容。特别是，应保留Loc-RIB中路由的转发状态并将其标记为过时，并且在转发过程中不区分陈旧的路由信息和其他信息11.8ECDSA中秘密随机数的鲁棒性带有曲线P-256的椭圆曲线数字签名算法(ECDSA)用于在BGPsec中对UPDATE消息进行签名。对于ECDSA,应在生成每个数字签名之前生成一个新的秘密随机数“k”。应使用高熵随机位生成器(RBG)来生成“k”,并且应减轻“k”生成算法中的任何潜在偏差11.9增量/部分部署注意事项从BGP迁移到BGPsce的过程中，最初，一小组相邻的AS会执行BGPsec。全球互联网的不同地理区域中可能会有一个或多个这样的组。只有起源于每个组并在其边界内传播的路由才能获得加密AS路径保护的好处。随着BGPsec的采用率的增长，每个组的规模也随之增长，最终它们结合在一起，形成了更大的具有BGPsec功能的连续AS集合在部分部署期间，如果路径中的AS不支持BGPsec,则BGP返回传统模式，即BGPseeUPDATE消息在转发给该AS之前会转换为未签名的UPDATE消息(请参阅第8.4节)。此时，无法保证通过所列AS序列传播UPDATE消息。换句话说，从源AS开始到不支持BGPsce的AS之前的AS,仍然可以提供保证，但不应超过此保证。有关BGPsce协议支持自治系统迁移的方法应遵循IETFRFC8206第5章的规定。BGPsce部署过程中涉及到的RPKI分配和维护、证书管理等应遵循IETFRFC8207中的要求。BGPsee算法、算法参数、非对称密钥格式、非对称密钥大小和签名格式等应道循IETFRFC8208第2章至第6章的规定。12安全注意事项12.1安全保障有关BGPsee威胁模型和相关安全注意事项的讨论，请参阅IETFRFC7132第3章和第4章。与来源验证结合使用时，应为接收有效的BGPsecUPDATE消息(包含给定前级的路由公告)的BGPsec发言人提供以下安全保证：源AS编号对应于IP地址空间持有者在RPKI中授权的AS。对于路径中的每个AS,由AS号持有者授权的BGPsee发言人有意选择(根据本地策略)将路由公告传播到路径中的后续AS。也就是说，向有效BGPsecUPDATE消息的接收者保证，该UPDATE消息是通过BGPsce_PATH属性的Sccure_Path部分中列出的AS序列传播的。此外，接收者确保该路径终止于IP地址空间持有者授权的AS,该AS作为到给定前缓的流量的合法目的地。尽管BGPsce为AS提供了一种机制来验证收到的UPDATE消息具有某些安全属性，但是使用这种机制来影响路由选择完全是本地策略的问题。因此，BGPsee发言人无法对从外部BGPsec对等方接收到的路由的有效性做出任何假设。也就是说，兼容的BGPsce对等方可以(取决于对等方的本地策略)发送未通过第9节中的有效性测试的UPDATE消息。因此，一个BGPsce发言人应完全验证从外部对等方收到的所有BGPsceUPDATE消息。(验证来自内部对等方的UPDATE消息也是本地策略的问题请参阅第9节。)在某些情况下，BGPsee发言人认为同时包含“有效”和“无效”(按照9.2节中的验证算法)Signature_Block的BGPsecUPDATE消息“有效”,也就是说，UPDATE消息包含与两个算法套件相对应的两组签名，并且一组签名正确验证，而另一组签名无法验证。在这种情况下，协议规定，选择在这种UPDATE消息中传播路由公告的BGPsee发言人务必将其签名添加到每个Signature_Blocks中(请参见第8.2节)。因此，BGPsee发言人使用这两种算法套件来创建签名，并创建一个新的UPDATE消息。其中包含“有效”和“无效”签名集(从其自身的有利位置)要了解做出此类设计决定的原因，请考虑以下情况：BGPsec发言入收到的UPDATE消息中同时包含一组“有效”算法A签名和一组“无效”算法B签名。在这种情况下，某些BGPsec发言人的对等方(或BGP拓扑中更下游的其他实体)有可能(甚至有可能取决于算法转换的状态)不支持算法A。因此，如果BGPsec发言人要删除与算法B对应的“无效”签名集，则这些实体将把该消息视为未签名。通过包括在传播路由公告时使用的“无效”签名集，BGPsee发言人确保下游实体拥有尽可能多的信息。以对