计算机系统应用http://www.c-s-a.org.cn

2016年第25卷第8期16专论·综述SpecialIssueRPKI中CA资源分配风险及防护技术①刘晓伟1,2,延志伟2,耿光刚2,李晓东1,21(中国科学院大学计算机网络信息中心,北京100190)2(中国互联网络信息中心互联网域名管理技术国家工程实验室,北京100190)摘要:边界网关协议在安全方面存在严重的缺陷,容易导致路由劫持这一互联网安全威胁.
为此,国际互联网工程任务组提出了资源公钥基础设施(ResourcePublicKeyInfrastructure,RPKI)以防止路由劫持的发生.
然而随着RPKI技术的发展及其在全球范围内的部署,与RPKI中认证权威相关的安全问题逐渐突显,并受到广泛关注.
对RPKI中认证权威的资源分配过程进行研究分析,通过实验测试,验证了认证权威在资源分配的过程中资源重复分配和未获授权资源分配两种潜在的安全风险,并分析了两种风险对资源持有者可能造成的不良影响.
此外,针对这两种安全风险,提出并实现了一种用于保证RPKI中认证权威资源分配安全性和准确性的"事前控制"机制,该机制可以有效地防止资源重复分配和未获授权资源分配两种操作风险的发生,减少了由于认证权威的错误操作所导致的故障恢复等待时间.
最后,通过进一步的实验测试,验证、分析了这种"事前控制"机制的有效性和可行性.
关键词:资源公钥基础设施;认证权威;资源重复分配;未获授权资源分配;事前控制ResourceAllocationRisksbyCAsinRPKIandFeasibleSolutionsLIUXiao-Wei1,2,YANZhi-Wei2,GENGGuang-Gang2,LIXiao-Dong1,21(ComputerNetworkInformationCenter,UniversityofChineseAcademyofSciences,Beijing100190,China)2(NationalEngineeringLaboratoryforNamingandAddressing,ChinaInternetNetworkInformationCenter,Beijing100190,China)Abstract:ThereareserioussecurityvulnerabilitiesinBGP(BorderGatewayProtocol)whichmayleadtoroutehijacking.
InordertoovercometheseBGPsecuritydefects,RPKI(ResourcePublicKeyInfrastructure)wasproposedbyIETF(InternetEngineeringTaskForce).
However,withthedevelopmentandglobaldeploymentofRPKI,alotofconcernsaboutthesecurityofcertificateauthorityinRPKIhavebeenraised.
Inthispaper,itcarriesoutexperimentsabouttwoscenarios(resourcereassignmentandunauthorizedresourceassignment)onourRPKItestbed,andanalyzesthesecurityproblemstheymayleadto,basedonourresearchandanalysisoftheprocessofresourceallocation.
Besides,forthesetwokindsofsecurityrisks,thispaperpresentsandimplementsapre-controlmechanism.
Finally,itconductsfurtherexperimentsonourtestbedtoprovethatthepre-controlmechanismwepresentedisfeasibleandeffectivetoavoidthetimelimitforrecoveringfromthefailurecausedbycertificateauthority'soperationalmistakesduringtheprocessofresourceallocation.
Keywords:RPKI;certificateauthority;resourcereassignment;unauthorizedresourceassignment;pre-control互联网被划分为许多较小的自治系统(AutonomousSystem,AS),目前,自治系统之间的路由选择协议是BGP(BorderGatewayProtocol)协议[1],BGP协议在安全方面的设计存在较大的不足:BGP协议默认接受AS通告的任何路由,因此,即使一个AS向外通告不属于自己的IP前缀,该路由通告也会被对端接受并继续传播[2].
BGP的这一安全缺陷容易导致一种典型的互联网安全威胁——路由劫持.
现已发生的典型的路由劫持事件[3]包括:1997年4月的AS7007事件、2004年12月的土耳其电信集团劫持互联网事①基金资助项目:国家自然科学基金(61272433)收稿时间:2015-12-15;收到修改稿时间:2016-01-28[doi:10.
15888/j.
cnki.
csa.
005313]2016年第25卷第8期http://www.
c-s-a.
org.
cn计算机系统应用SpecialIssue专论·综述17件、2008年2月的巴基斯坦劫持YouTube事件,以及2014年2月的加拿大流量劫持事件等.
路由劫持对互联网的正常运行影响非常大,可能会导致路由黑洞、流量窃听以及拒绝服务攻击等[4].
RPKI(ResourcePublicKeyInfrastructure)的提出正是为了解决路由劫持,目前,与RPKI相关的技术标准在IETFSIDR(SecureInter-DomainRouting)工作组中得到了迅速的发展和积极的推进,并且,RPKI在全球的部署范围也正在逐步地扩大,尤其是在南美洲和欧洲,以及全球多个国家和地区都已经开始或完成了RPKI的实际部署工作.
针对域间路由系统存在的安全问题,RPKI通过构建一个公钥证书体系来完成对互联网码号资源(InternetNumberResource,INR,包括IP前缀和AS号)的所有权(分配关系)和使用权(路由源授权)的认证,并以此"认证信息"来指导BGP中边界路由器的路由决策,帮助其检验BGP报文中路由源信息的合法性和真实性,从而有效地防止路由劫持的发生.
1资源公钥基础设施RPKIRPKI依附于INR的分配过程[5]:在INR的分配层次中,最上层的是互联网号码分配机构(InternetAssignedNumbersAuthority,IANA),IANA将INR分配给5个区域性互联网注册机构(RegionalInternetRegistry,RIR),RIR又可以将自己的资源向其下级节点如本地互联网注册机构(LocalInternetRegistry,LIR)、国家级互联网注册机构(NationalInternetRegistry,NIR)和互联网服务提供商(InternetServiceProvider,ISP)分配,然后下级节点再依次逐级向下分配.
为了实现INR所有权和使用权的可认证,在RPKI中要求每一层在向下层进行资源分配时,必须签发相应的证书,RPKI中的证书主要包括两种[6]:认证权威(CertificateAuthority,CA)证书和端实体(EndEntity,EE)证书.
CA证书用于实现INR所有权的认证,EE证书主要用于对路由源授权(RouteOriginAuthorization,ROA)的认证.
RPKI路由起源认证中最重要的对象就是ROA[7],它用于表明资源持有者授权哪个(或哪些)AS,针对特定的IP前缀发起路由起源通告.
RPKI的体系架构如图1所示,RPKI包括CA、资料库(Repository)和依赖方(RelyingParty,RP)三个基本功能模块.
三个功能模块通过签发、存储、验证RPKI中的各种数字签名对象来相互协作,并进行必要的数据通信,共同完成RPKI的路由起源认证功能[8].
图1RPKI体系架构①CA包括IANA、RIR、NIR、ISP等资源分配机构,在进行资源分配时,CA通过签发CA证书来表示INR的分配关系,通过签发ROA来授权某个AS针对自己的一部分IP前缀发起路由起源通告.
②资料库[9]用于存储CA发布的各种包含INR分配信息和授权信息的CA证书和ROA等数字签名对象,并提供给全球的RP进行同步和验证.
③RP通过rsync[10]或RRDP[11]协议从资料库中同步RPKI的数字签名对象,并使用rcynic[12]等工具对这些数字签名对象进行验证[13],将其处理成IP前缀与AS号的合法授权关系,最后将该授权关系通过rpki-rtr协议[14]提供给BGP边界路由器,用于指导其路由决策.
2CA资源分配风险分析IETFSIDR工作组密切关注RPKI中由于CA错误操作所导致的各种安全风险[15],CA的错误操作可能会导致严重的安全问题,例如,增加一个新的ROA[16]可能会导致一个合法的路由被判定为无效(Invalid);删除合法的CA证书[17]意味着资源的撤销,会导致合法的资源持有者在网络中被迫下线.
更为严重的是,一个CA节点的错误操作影响的不仅仅是该节点本身,还包括该节点以下的各个节点.
因此,发生错误操作的CA在RPKI层次结构中的位置越靠上,则该CA造成的影响也可能越大.
例如,如果发生错误操作的CA是一个处于低层次的ISP,那么这种错误只会限制在该ISP的局部范围内;但如果发生错误操作的CA是RIR或NIR,那么这种错误会对该区域内所有相关节点(也包括这些节点的下级节点)造成严重影响.
BGPBorderRouterIANARepositoryAPNICRepositoryLIR/NIRRepositoryRIPENCCRepository.
.
.
LIR/NIRRepositoryRelyingPartyRPKI‐RTRProtocol.
.
.
计算机系统应用http://www.
c-s-a.
org.
cn2016年第25卷第8期18专论·综述SpecialIssue在RPKI中CA的主要操作包括资源分配过程中CA证书的签发、ROA等数字签名对象的签发、资料库的维护等,这些操作依附于资源分配,只有上级节点分配资源、下级节点获得资源后,才有资源的再次分配以及各种数字签名对象签发、资料库的维护等操作.
因此,CA资源分配操作的安全性、准确性是RPKI正确实现其路由起源认证功能的重要保证.
本文针对在RPKI中CA向其下级节点进行资源分配的过程中两种潜在的操作风险:资源重复分配和未获授权资源分配,通过实验测试,验证两种操作风险是确实存在的,并针对这两种操作风险提出了一种可行的应对方案.
资源重复分配指的是同一资源被分配多次到不同的下级节点.
例如在图2中,假设APNIC已经将ASN65540-65550和IP前缀203.
0.
113.
128/26分配给了JPNIC.
在APNIC对CNNIC进行资源分配时,APNIC由于误操作或恶意操作将已经分配给JPNIC的ASN65540和IP前缀203.
0.
113.
128/26重复分配给了CNNIC.
这样在CNNIC和JPNIC实际使用这些资源时,就会出现资源冲突、资源不可用等问题.
图2资源重复分配未获授权资源分配指的是进行资源再分配的节点并不是该资源的合法持有者.
例如在图3中,APNIC并不是ASN65551和IP前缀192.
0.
3.
128/26的合法持有者,APNIC在向下级节点TWNIC进行资源分配时,由于误操作或恶意操作将该资源分配给TWNIC,这样TWNIC在使用这部分资源时,也会出现资源不可用等问题.
图3未获授权资源分配3CA资源分配风险实验验证由rpki.
net提供的RPKI-CA[18]和RPKI-RP[12]工具包,是目前支持功能最为完整的开源RPKI软件,本文所进行的测试场景均在该实验工具下完成.
本节按照第2节中资源重复分配和未获授权资源分配两种场景,分别进行实验测试,并分析两种风险可能导致的不良影响.
3.
1资源重复分配实验验证通过RPKI-CA工具,按照图2中的CA节点层次结构,配置各节点间的父子关系,并进行相应的资料库配置,完成实验环境中各级CA节点的搭建.
在所搭建的实验环境中,对资源重复分配这一场景进行实验测试和验证.
在本次实验测试中,假设资源的重复分配发生在APNIC对CNNIC进行资源分配的过程中.
首先是APNIC对JPNIC进行资源分配,将ASN65540-65550以及IP前缀203.
0.
113.
128/26分配给JPNIC.
在APNIC对CNNIC进行资源分配时,将ASN64498-64505,65540以及IP前缀192.
0.
2.
128/26,198.
51.
100.
128/26,203.
0.
113.
128/26分配给CNNIC.
在两次资源分配的过程中,对ASN65540和IP前缀203.
0.
113.
128/26而言,就存在重复分配的问题.
在APNIC节点上,通过show_child_resources命令来查看APNIC分配给其子节点的资源,通过show_published_objects命令来查看APNIC在资源分配过程中生成的证书等数字签名对象,如图4所示.
从图4中我们能够看到ASN65540和IP前缀203.
0.
113.
128/26被重复分配给了CNNIC和JPNIC节点,并且用于表示本次资源分配的CA证书_O2UcMSIANAAPNICCNNICASNs:0‐4294967295IPPrefixes:0.
0.
0.
0/0ASNs:64497‐64510,65537‐65550IPPrefixes:192.
0.
2.
128/25,198.
51.
100.
128/25,203.
0.
113.
128/25ASNs:64498‐64505,65540IPPrefixes:192.
0.
2.
128/26,198.
51.
100.
128/26,203.
0.
113.
128/26JPNICASNs:65540‐65550IPPrefixes:203.
0.
113.
128/26IANAAPNICCNNICASNs:0‐4294967295IPPrefixes:0.
0.
0.
0/0ASNs:64497‐64510,65537‐65550IPPrefixes:192.
0.
2.
128/25,198.
51.
100.
128/25,203.
0.
113.
128/25ASNs:64498‐64505IPPrefixes:192.
0.
2.
128/26,198.
51.
100.
128/26JPNICASNs:65540‐65550IPPrefixes:203.
0.
113.
128/26TWNICASNs:64497,65551IPPrefixes:192.
0.
3.
128/262016年第25卷第8期http://www.
c-s-a.
org.
cn计算机系统应用SpecialIssue专论·综述19CjwRKP6ed4Thxmcb9SPM.
cer和BvLK0ynrzTYPK7GoeXsVEy6SHuA.
cer被自动生成,并被发布在APNIC的资料库中.
我们可以通过openssl命令查看两个证书的内容(仅列出所分配的资源部分),如图5,图6所示.
图4查看APNIC资源分配和数字签名对象签发结果图5查看APNIC向CNNIC资源分配的CA证书图6查看APNIC向JPNIC资源分配的CA证书从图5和图6中我们也能够验证资源ASN65540和IP前缀203.
0.
113.
128/26被重复分配给了CNNIC和JPNIC节点.
对于CNNIC和JPNIC节点,我们可以通过show_received_resources命令来查看他们从APNIC节点接收到的资源,如图7所示.
图7查看CNNIC和JPNIC从APNIC收到的资源从图7中我们可以看到ASN65540和IP前缀203.
0.
113.
128/26都被CNNIC和JPNIC节点接收到了,这样在CNNIC和JPNIC实际使用这些资源时,就会出现资源冲突、资源不可用等问题.
3.
2未获授权资源分配实验验证通过RPKI-CA工具,按照图3中的CA节点层次结构,配置各节点间的父子关系,并进行相应的资料库配置,完成实验环境中各级CA节点的搭建.
在所搭建的实验环境中,对未获授权资源分配这一场景进行实验测试和验证.
在本次实验测试中,假设未获授权资源分配发生在APNIC对TWNIC进行资源分配的过程中.
APNIC不是ASN65551和IP前缀192.
0.
3.
128/26的合法持有者,但在APNIC向下级节点TWNIC进行资源分配时,将这些未获授权的资源分配给了TWNIC.
在APNIC节点上,通过show_child_resou-rces命令来查看分配给其下级节点的资源,如图8所示.
图8查看APNIC分配给下级节点的资源从图8中我们能够看到,对于APNIC节点而言,显示已经将ASN65551和IP前缀192.
0.
3.
128/26成功地分配给了其下级节点TWNIC.
同样,对于TWNIC节点,我们可以通过show_received_resources命令来查看其从APNIC节点接收到的资源,如图9所示.
图9查看TWNIC从APNIC收到的资源从图9中我们能够看到ASN65551和IP前缀192.
0.
3.
128/26并没有被TWNIC节点接收到,但APNIC认为这些资源已经被分配给了TWNIC,因此会导致TWNIC无法实际使用这些资源的问题.
计算机系统应用http://www.
c-s-a.
org.
cn2016年第25卷第8期20专论·综述SpecialIssue4解决方案(事前控制机制)如前所述,在RPKI中RP可以用于对各级CA产生的数字签名对象进行验证[12],那么使用RP能否检测出资源的重复分配和未获授权资源分配两种错误操作如果通过现有的RP工具能够检测出资源的重复分配和未获授权资源分配两种错误操作,那么我们可以在将RPKI的各种数字签名对象发布到资料库之前就使用RP工具来对其进行验证,只有通过验证的数字签名对象才允许发布到资料库中,这样就可以防止两种错误操作对资源持有者造成的不良影响.
本文通过由rpki.
net提供的RPKI-RP验证工具,对资源的重复分配和未获授权资源分配两种场景进行验证.
对于APNIC节点而言,其资料库位于/usr/share/rpki/publication/iana/apnic目录,RP验证后的结果存放在/var/rcynic/data/authenticated/localhost/rpki/iana/apnic目录下.
通过查看两个目录下的文件及文件的内容,如图10所示,我们可以得出APNIC节点的资料库中所有的CA证书及其他数字签名对象都被认证为合法(通过RP验证为合法的数字签名对象才会被存放在/var/rcynic/data/authenticated/目录中).
图10对比APNIC资料库与RP验证后的结果由此得知,使用现有的RP并不能检测出资源重复分配和未获授权资源分配两种错误操作.
因此,我们需要对现有的RP进行改进,或提出新的解决方案用于实现对这些问题的检测和防范.
S.
Kent等人提出可以通过完善和改进现有RP的功能,使其对于可能是由于CA的错误操作导致的证书签发(包括本文所提出的资源重复分配和未获授权资源分配两种场景)、证书撤销等情况,进行滞后(hysteresis)操作[15],这样RP在进行本次验证时,允许RP在一定的时间间隔[15]内仍然采用上次被验证为有效的对象,忽略本次验证时增加或减少的对象.
此外,对于在RP看来可能是错误操作但确实是CA需要完成的操作时,允许资源持有者通过一种独立于RPKI体系外的确认(confirmation)机制来通知RP使本次更新立即生效.
对于上述的滞后操作和独立确认机制可以在一定程度上(需要RP能够识别出这两种错误操作),减少资源重复分配和未获授权资源分配两种错误操作带来的不良影响.
这种解决方案属于一种"事后检验"的机制,也就是在CA已经产生了错误的操作之后,利用改进后的RP对资料库中的所有数字签名对象进行验证,如果验证不通过,则向该CA发出相应的错误通知,使其能够进行及时的错误恢复.
这种机制存在以下几个问题:①滞后操作延迟时间的确定比较困难:延迟时间既要足够长,从而确保受影响的CA能够从相应的错误操作中恢复过来;但又要尽可能的短,避免该CA的合法更新操作被滞后过长时间,从而防止由于某些已经被撤销的签名对象继续有效或某些新增加的对象无法及时生效,而对BGP的路由决策造成的干扰.
②CA要保证独立确认机制本身尽可能地安全和独立,这增加了CA的负担和操作复杂性.
本文提出一种"事前控制"机制,可以在资源分配的过程中,CA证书签发之前进行控制,避免由于CA的错误操作导致非法资源证书的生成,从而防止资源重复分配和未获授权资源分配两种错误操作的发生.
这种事前控制机制主要体现在,一个正确的资源分配和证书签发过程,应该满足如下两个条件:①向下级节点进行分配的所有资源,必须全部从属于要进行资源分配的CA节点本身(防止未获授权资源分配)②满足条件1的任何资源,不能被重复分配到不同的下级节点(防止资源的重复分配)本文提出的事前控制机制是在证书签发之前必须(只有满足事前控制机制的两个条件,才能进行后续的资源分配和证书签发操作)进行的操作,从而可以确保该机制对资源的重复分配和未获授权资源分配两种操作风险的检测和规避,并保证CA资源分配、证书签发的安全性和准确性.
本文对这一事前控制机制进行了初步的实现,流程如图11所示.
采用该机制后,在进行资源分配的过程中就会对要进行分配的资源进行检查,防止资源的重复分配和未获授权资源分配的发生:首先是对条件1(未获授权2016年第25卷第8期http://www.
c-s-a.
org.
cn计算机系统应用SpecialIssue专论·综述21资源分配)的检查,如图12所示(以图3中的未获授权资源分配作为测试场景),如果在资源分配文件(.
csv文件)中存在不属于当前CA节点的资源,则发出"UnauthorizedResourcesFound"警告,显示检测到的不属于该节点的资源,并提示对资源分配文件进行修改.
如果条件1满足,则进行条件2(资源的重复分配)的检查,如图13所示(以图2中的资源重复分配作为测试场景),如果在资源分配文件中存在某一部分资源被重复分配到不同的下级节点,则发出"ResourcesRe-AllocationFound"警告,显示被重复分配的资源,并提示修改资源分配文件.
图11事前控制实现流程图图12采用事前控制,防止未获授权资源的分配图13采用事前控制,防止资源的重复分配当资源分配文件满足事前控制的两个条件之后,才能够完成资源的正确分配和证书的签发,如图14所示.
图14满足事前控制两个条件的资源分配此时在APNIC节点上,再次通过show_child_re-sources命令来查看已经分配给其下级节点的资源,如图15所示,我们可以看出,采用本文提出的事前控制机制,能够在证书签发之前就有效地检测到资源重复分配和未获授权资源分配两种错误操作,从而防止错误的资源证书的生成.
此外,这种事前控制机制能够尽可能地减少不必要的滞后操作,省去了由于错误的证书签发、RP的验证以及错误恢复导致的时间延迟.
图15再次查看APNIC分配给下级节点的资源需要说明的是,对于事前控制中的条件2,有一种特殊情况:在资源迁移[19]的过程中,允许某个中间状态,从属于多个不同CA节点的CA证书中包含有同一块资源(对应于资源重复分配场景).
但资源迁移的最终结果是,资源迁移的发起者必须签发新的资源证书,且新的资源证书中不能包含已经被迁移到接收者的那些资源[19].
因此对于资源迁移过程中的事前控制,应该做特殊处理,允许处于该过程中的资源被多个不同的CA节点共同所有.
资源迁移的相关技术标准目前在IETFSIDR工作组中尚处于个人草案阶段,针对这一特殊场景的一种可行的解决方案是:只允许TAO[20]对象中ipAddrBlocks和asIdentifiers两个字段所指定的资源被重复分配到不同的资源持有者,而其他的资源仍然需要满足前述的资源分配和证书签发的两个条件.
这样,事前控制机制能够兼容资源迁移这种特殊场景,并有效地防止CA的错误操作.
5结语本文针对CA在资源分配过程中,资源重复分配和未获授权资源分配两种潜在的安全风险,通过实验测试,验证并分析了两种风险及可能导致的后果、提出并实现了一种事前控制机制,最后通过实验测试,获取输入参数:资源分配CA节点、CSV文件CSV文件给定Y从配置文件rpki.
conf中handle字段获取CA节点NNY开始CA节点给定从注册数据库获取当前CA节点持有的资源CSV文件中未获授权资源的检测通过不通过未获授权资源分配错误提示CSV文件中资源重复分配的检测通过资源重复分配错误提示不通过资源分配、证书签发程序异常退出程序正常退出错误提示计算机系统应用http://www.
c-s-a.
org.
cn2016年第25卷第8期22专论·综述SpecialIssue验证了该机制的可行性.
本文提出的事前控制机制,可以有效地防止资源重复分配和未获授权资源分配两种操作风险的发生,减少了由于两种操作导致的错误恢复等待时间,加强了CA在资源分配过程中操作的安全性,并为RPKI正确实现其路由起源认证功能提供了重要的安全保障.
参考文献1RekhterY,LiT,HaresS.
Abordergatewayprotocol4(BGP-4).
IETFRFC4271,January2006.
2黎松,诸葛建伟,李星.
BGP安全研究.
软件学报,2013,24(1):121–138.
3IPhijacking.
https://en.
wikipedia.
org/wiki/IP_hijacking.
4BallaniH,FrancisP,ZhangX.
AstudyofprefixHijackingandinterceptionintheinternet.
ACMSIGCOMM,2007.
5HustonG,MichaelsonG.
Validationofrouteoriginationusingtheresourcecertificatepublickeyinfrastructure(PKI)androuteoriginauthorizations(ROAs).
IETFRFC6483,February2012.
6LepinskiM,KentS.
Aninfrastructuretosupportsecureinternetrouting.
IETFRFC6480,February2012.
7LepinskiM,KentS,KongD.
Aprofileforrouteoriginauthorizations(ROAs).
IETFRFC6482,February2012.
8BushR.
Originvalidationoperationbasedontheresourcepublickeyinfrastructure(RPKI).
IETFRFC7115,January2014.
9HustonG,LoomansR,MichaelsonG.
Aprofileforresourcecertficaterepositorystructure.
IETFRFC6481,Feb2012.
10WeilerS,WardD,HousleyR.
ThersyncURIscheme.
IETFRFC5781,February2010.
11BruijnzeelsT,MuravskiyO,WeberB,AusteinR,MandelbergD.
RPKIRepositoryDeltaProtocol.
draft-ietf-sidr-delta-protocol-01,October2015.
12RPKIRelyingPartyTools.
http://trac.
rpki.
net/wiki/doc/RPKI/RP.
13HustonG,MichaelsonG,LoomansR.
AprofileforX.
509PKIXresourcecertificates.
IETFRFC6487,February2012.
14BushR,AusteinR.
Theresourcepublickeyinfrastructure(RPKI)torouterprotocol.
IETFRFC6810,January2013.
15KentS,MaD.
Adverseactionsbyacertificationauthority(CA)orrepositorymanagerintheresourcepublickeyinfrastructure(RPKI).
draft-kent-sidr-adverse-actions-01,October2015.
16CooperD,HeilmanE,BrogleyK,ReyzinL,GoldbergS.
OntheriskofmisbehavingRPKIauthorities.
ACMHotnets,November2013.
17LiuXW,YanZW,GengGG,LeeXD,TsengSS,KuCH.
RPKIdeployment:Risksandalternativesolutions.
GeneticandEvolutionaryComputing,2015.
18RPKICAEngine.
http://rpki.
net/wiki/doc/RPKI/CA.
19AusteinR,BushR,HustonG,MichaelsonG.
Resourcetransferintheresourcepublickeyinfrastructure.
draft-ymbk-sidr-transfer-01,July2015.
20BarnesE.
Resourcepublickeyinfrastructure(RPKI)resourcetransferprotocolandtransferauthorizationobject(TAO).
draft-barnes-sidr-tao-00,February