前缀seo监测

ISSN1000-9825,CODENRUXUEWE-mail:jos@iscas.
ac.
cnJournalofSoftware,Vol.
21,No.
10,October2010,pp.
25842598http://www.
jos.
org.
cndoi:10.
3724/SP.
J.
1001.
2010.
03657Tel/Fax:+86-10-62562563byInstituteofSoftware,theChineseAcademyofSciences.
Allrightsreserved.
Co-Monitor:检测前缀劫持的协作监测机制刘欣1,2+,朱培栋1,彭宇行11(国防科学技术大学计算机学院,湖南长沙410073)2(中国联通湖南分公司,湖南长沙410014)Co-Monitor:CollaborativeMonitoringMechanismforDetectingPrefixHijacksLIUXin1,2+,ZHUPei-Dong1,PENGYu-Xing11(SchoolofComputer,NationalUniversityofDefenseTechnology,Changsha410073,China)2(Hu'nanBranchofChinaUnicom,Changsha410014,China)+Correspondingauthor:E-mail:xin.
liu@nudt.
edu.
cnLiuX,ZhuPD,PengYX.
Co-Monitor:Collaborativemonitoringmechanismfordetectingprefixhijacks.
JournalofSoftware,2010,21(10):25842598.
http://www.
jos.
org.
cn/1000-9825/3657.
htmAbstract:Intoday'sInternet,itisverydifficultfornetworkoperatorstodiscoverprefixhijacksintime.
ConsideringtheautonomouscharacteristicoftheInternetinter-domainroutingsystem,thispaperprovidestheideaofcollaborativemonitoringamongmultipleAutonomousSystems(ASes).
Thispaperalsoexaminesthedesignofanewmethod,namedCo-Monitorthatdetectsprefixhijacksinreal-time.
InCo-Monitor,everyparticipantASexchangesself-definedprefix-to-originmappinginformationwiththeothers,andtheymonitorlocalBGP(bordergatewayprotocol)updatesrespectively.
OncesomeparticipantdiscoversthattheoriginofinformationofaBGProuteisinconsistentwiththelearnedprefix-to-originmappinginformation,itnotifiesrelativeparticipantsimmediately;thereby,Co-Monitorcanhelpparticipantsdetectprefixhijacksquicklyandeffectively.
ThispaperpresentsthedetaileddesignofCo-Monitor,evaluatesitsdetectingcapabilities,andalsodiscussesseveralrelatedproblems.
TheexperimentalresultsshowthatCo-Monitor,withonlyselected60participants,isaccuratewith0%falsenegativeratioand0%falsepositiveratio.
Keywords:BGP;autonomoussystem;prefixhijacking;sourceverification;collaborativemonitoring摘要:在如今的互联网中,网络管理员要想及时地发现前缀劫持事件非常困难.
考虑到互联网域间路由系统中存在的自治特性,提出了在多个自治系统之间协作监测前缀的思想,并由此设计了一个实时检测前缀劫持的新方法——Co-Monitor机制.
在Co-Monitor中,每个参与者与其他参与者交换自定义的前缀-源自治系统映射信息,同时,利用所学到的前缀-源自治系统映射信息实时地监测本地BGP(bordergatewayprotocol)路由更新.
一旦某个参与者发现了不一致就立刻通知相关的参与者,从而可帮助参与者及时、有效地发现前缀劫持.
给出了Co-Monitor机制的详SupportedbytheNationalNaturalScienceFoundationofChinaGrantNos.
60873214,60433040(国家自然科学基金);theNationalHigh-TechResearchandDevelopmentPlanofChinaunderGrantNos.
2006AA01Z213,2006AA01Z332(国家高技术研究发展计划(863));theResearchFoundationforPh.
D.
CandidatesofNationalUniversityofDefenseTechnologyofChinaunderGrantNo.
B070603(国防科学技术大学博士研究生创新资助)Received2008-08-25;Accepted2009-05-05刘欣等:Co-Monitor:检测前缀劫持的协作监测机制2585细设计,评估了该机制的检测能力,并讨论了几个相关的问题.
实验结果表明,只需精心选择60个参与者,就可确保Co-Monitor系统检测前缀劫持的漏检率和误检率都为0%.
关键词:边界网关协议;自治系统;前缀劫持;宣告方验证;协作监测中图法分类号:TP393文献标识码:A互联网由许多相互连接的自治系统(autonomoussystem,简称AS)组成,这些自治系统使用边界网关协议(bordergatewayprotocol,简称BGP)交换各自的网络层可达信息[1].
每当一个自治系统向外宣告一条BGP路由,它就会把自己的自治系统号附加在该路由的AS_PATH属性的尾端,最初宣告该路由的自治系统被称为该路由的源自治系统(originAS),其自治系统号就位于该路由的AS_PATH属性的最右端.
BGP协议规定,BGP发言人必须无条件地相信其他发言人宣告或传递的路由.
因而,一个自治系统可随意地发布其他自治系统拥有的前缀,从而形成前缀劫持攻击.
这种路由攻击的关键特征是BGP路由中的前缀与源自治系统的对应关系(或称为前缀源信息(prefixorigins))不合法[2].
前缀劫持是当前BGP路由系统所面临的一个严重的安全威胁,轻则增加路由器负载,重则影响网络连通性.
实际观察表明,前缀劫持现象确实经常发生,许多大规模的网络瘫痪事故都与此相关[35].
值得注意的是,还有许多小型的前缀劫持(只涉及到几个前缀)很少被报道或是难以察觉,它们的安全威胁也不容忽视.
举例而言,2005年5月7日,Google中断了近1小时的网络服务,Google事后的解释是错误配置DNS服务器所致[6].
然而,Wan等人在研究后发现,网络运营商Cogent(AS174)在事故期间宣告了Google(AS15169)的前缀64.
233.
161.
0/24,他们进而推测Cogent对Google实施的前缀劫持攻击很可能是此次事故的真正原因[7].
另一个小型的前缀劫持事件更具有代表性,它就是曾在互联网上引起轩然大波的YouTube服务中断事件.
2008年2月24日,由于宗教冲突原因,巴基斯坦电信管理局(PakistanTelecomAuthority)命令巴基斯坦的网络运营商阻塞YouTube(AS36561)的前缀208.
65.
153.
0/24.
但是,巴基斯坦电信(AS17557)泄露了相关路由,并通过香港的电讯盈科(AS3491)在互联网上广为扩散,这次前缀劫持事件造成YouTube服务中断了两个多小时[8].
近年来,无论是工业界还是学术界都非常关注BGP路由系统中的前缀劫持问题.
然而,网络运营商要想及时地发现前缀劫持事件依然十分困难.
现有的检测方案要么不够实用,要么能力不足,详见本文第1节.
我们认为,实用而又有效的前缀劫持检测方案不应忽视BGP路由系统的自治特性:在保护各个自治系统的路由信息私密性的前提下,不仅要能帮助网络管理员便捷地获取其他自治系统的相关信息,还要能帮助其对外贡献本地路由域中的相关信息,使它们能够互利互惠地完成各自的前缀劫持检测任务.
由此,本文把每个自治系统对本地路由域的监测能力视为一种资源,提出了协作监测前缀的思想,进而设计了一种实时检测前缀劫持的新方法——Co-Monitor机制.
在Co-Monitor中,每个参与其中的自治系统需要与其他参与者交换自定义的前缀-源自治系统映射信息,同时利用所学到的全局的前缀-源自治系统映射信息实时监测本地BGP路由更新.
一旦某个参与者发现了不一致就立刻通知相关的参与者.
通过这种方式,Co-Monitor机制就可以帮助参与者及时地发现前缀劫持.
本文提出的Co-Monitor机制具有以下5个特点:1)位于互联网的应用层,除了需要通过哑iBGP会话采集BGP路由外,不需要对现有的互联网路由基础设施作任何改变,这便于实际应用与增量部署;2)利用宣告方验证前缀的思想获得了当前最实用、最准确的前缀劫持判断能力,这样就可保证检测前缀劫持的误检率(falsepositiveratio)低至0%;3)利用协作监测前缀的思想可显著扩展每个参与者的路由监测范围,从而极大地降低检测前缀劫持的漏检率(falsenegativeratio);4)每个参与者只需负责监测本地路由域中的BGP路由器,这种方式分摊了整个系统的监测开销,因而不存在现有BGP监测系统那样严峻的可扩展性问题;5)各个参与者交换的只是自定义的前缀-源自治系统映射信息,传递的消息中也只含有相关BGP路由的前缀源变化信息,都不涉及具体的BGP路由,因而不会泄漏任何自治系统的私密信息.
现有的前缀劫持检测方案都不同时具备这些优势,这使得它可以帮助网络管理员实时、有效地检测前缀劫持事件.
哑BGP会话是指只用于接收而不宣告路由更新的BGP会话.
通过这种会话可在采集BGP路由数据时不影响BGP路由系统.
2586JournalofSoftware软件学报Vol.
21,No.
10,October2010本文的工作不能取代完整的互联网域间路由安全方案.
我们没有考虑AS_PATH或其他BGP属性的验证问题.
特别地,Co-Monitor机制不能检测由于篡改AS_PATH属性而形成的类似于前缀劫持的路由攻击,该机制也不能主动地防范前缀劫持.
Co-Monitor机制仅面向自治系统的网络管理员,帮助他们快速响应前缀劫持事件.
本文第1节介绍相关工作.
第2节概述Co-Monitor机制检测前缀劫持的基本原理.
第3节详述Co-Monitor机制的设计方案,其中包括关键前缀、实体认证、消息定义、消息传递、成员管理、拓扑维护与消息抑制等内容.
第4节评估Co-Monitor机制检测前缀劫持的能力.
第5节讨论相关问题.
最后总结全文.
1相关工作从实施前缀劫持检测的位置来看,相关工作大致可归为两类:一类是在路由接收方实施的方案[917],另一类是在路由宣告方实施的方案[1823].
前一类方案是当前研究的主流,还可进一步细分为防范方案和推断方案.
防范方案多是扩展BGP协议的安全增强机制,比如S-BGP[9],soBGP[10]和psBGP[11]等,尽管它们在理论上可以较好地解决前缀劫持问题,但考虑到协议开销、协议扩展以及设备升级等现实问题,这类方案并不实用;而推断方案可增量部署且不必改动底层的路由设施,但推断结果的漏检率和误检率还有待降低[15,16].
第2类方案较少,但比较实用,多是当前正在运作的BGP监测系统,比如窥镜服务器(lookingglasses)[18]、RIPE的MyASN公共服务[20]以及Renesys公司的Gradus商业服务[21]等.
在日常的网络管理中,网络运营商主要使用这类工具诊断BGP路由的各种问题.
本文的Co-Monitor机制属于第2类方案,从提升网络运营商前缀监测能力的角度开展研究.
通常,网络运营商会自愿设立窥镜服务器,供他人受限地查询本地BGP路由[18].
这些数量庞大的窥镜服务器是网络管理员在诊断BGP路由时最常用的工具.
但是,网络运营商若要及时地发现前缀劫持,窥镜服务器的作用还很有限:首先,窥镜服务器提供的路由查询服务不是一种标准的服务,并且,由于担心内部路由信息泄露,许多网络运营商对窥镜服务器进行了限制,比如,只允许手工访问等;其次,选择窥镜服务器很有技巧,即使是有经验的网络管理员也需要主动地访问许多窥镜服务器才可能发现前缀劫持,这个过程会耗费大量的时间和精力;最后,正是由于前两个原因,人们往往只是在出现前缀劫持,并引起了网络连通性故障以后,才注意到问题的存在.
显然,这种"拉模式"的手工检测方式太过原始,难以帮助网络管理员快速地响应前缀劫持问题.
为减轻网络管理员的负担,业界开发了几个基于"推模式"的BGP监测系统,比如MyASN,Gradus和PHAS(prefixhijackalertsystem)[19]等.
现有的这些BGP监测系统的体系结构基本相似:它们都由第三方机构设立,都要求与多个自治系统的BGP路由器建立多跳步的哑eBGP会话,集中地采集、分析BGP路由更新,并提供集中式的路由监测服务.
这种集中式的体系结构主要存在3个缺陷:1)系统的监测能力严重地受制于系统的处理能力,导致在互联网上存在大片的监测盲区.
比如,RouteViews项目中最大的采集器目前也只与42个自治系统的49个BGP路由器建立了会话[22];欧洲Netlantis项目的采集器因接收到太多的BGP路由更新而被迫关闭[23].
2)为减少性能开销,系统通常采用分级方式采集BGP路由,这会导致采集的BGP路由缺乏路由多样性(routediversity).
3)系统要求各自治系统贡献自己的私有BGP路由数据,因而难以适应自治的互联网域间路由环境.
各个自治系统没有利益动机允许其他机构采集自己的BGP路由;相反地,为保护自身利益,它们更可能拒绝建立或仅提供被过滤的BGP会话.
本文的方案结合了宣告方验证前缀和协作监测前缀的思想,解决了现有BGP监测系统面临的这些问题.
2机制概述本节概述Co-Monitor机制.
首先介绍Co-Monitor机制检测前缀劫持的基本原理,即该机制中的两个基本思想:一是宣告方验证前缀的思想,它可确保检测前缀劫持的误检率低至0%;二是协作监测前缀的思想,它可显著降低参与自治系统检测前缀劫持的漏检率;然后给出Co-Monitor机制实时检测前缀劫持的基本过程.
2.
1宣告方验证前缀现有的绝大多数前缀劫持检测方案都要求在路由的接收方进行验证,然而Atkinson等人在研究后指出,这刘欣等:Co-Monitor:检测前缀劫持的协作监测机制2587些方案在实际应用中面临着一个难以克服的困难,即不存在完整、准确、真实的信息回答"哪个组织有权利宣告哪个前缀"这个基本问题[24].
另一方面,各网络运营商对自己的IP地址空间负责,他们通过各种方式关注自己宣告的前缀,共同维护着BGP系统的正常运作(本文称其为宣告方验证前缀).
我们还注意到,尽管现有BGP监测系统在前缀劫持的检测方面存在许多不足,但问题的关键不在于宣告方验证前缀思想本身,而在于现有监测系统的集中式体系结构.
更为重要的是,宣告方验证前缀的思想回避了在路由接收方验证路由所面临的困难,它能够提供当前最实用、最准确的前缀劫持判断能力.
基于这些认识,我们格外重视宣告方验证前缀的思想.
这里通过一个例子来说明Co-Monitor机制如何提供对宣告方验证前缀思想的支持.
如图1所示,图中的自治系统级网络拓扑由7个自治系统(A~G)组成,其中ASA,E和F使用Co-Monitor机制,ASA是前缀P的合法宣告者.
在前缀P没有被劫持之前,所有自治系统都学到ASA宣告的前缀,它们接收到路由的前缀源信息都相同,记作二元组(P,A);而在ASA内部,该路由的AS_PATH属性为空,其前缀源信息则被记作(P,),如图1(a)所示.
假若ASG劫持了ASA的前缀P并且ASE,D和F都接收到该劫持路由,这可能会导致它们观察到的前缀源信息由(P,A)变为(P,G),如图1(b)所示.
Co-Monitor机制要求参与者E和F把这样的事件立刻通知给参与者A,从而使得参与者A能够及时地发现本次前缀劫持事件.
由于Co-Monitor机制利用了参与者对自己宣告的前缀的辨别能力,因而判断前缀劫持的准确性能够得到保证.
(P,A)→(P,G)CGFEDABCFDBPPAP(P,G)GE(P,G)(P,G)(P,)(P,)(P,A)(P,A)(P,A)(P,A)(P,A)(P,A)(P,)(P,A)(P,A)(P,A)→(P,G)(a)BeforeprefixPwashijacked(b)AfterprefixPwashijacked(a)前缀P被劫持之前(b)前缀P被劫持之后Fig.
1IdeaofsourceprefixverificationinCo-Monitor图1Co-Monitor机制中宣告方验证前缀的思想在对宣告方验证前缀思想的支持方面,Co-Monitor机制与访问窥镜服务器的"拉模式"不同,而与PHAS系统和MyASN服务的"推模式"相似.
但与现有BGP监测系统不同的是,Co-Monitor机制不要求任何自治系统贡献自己的BGP路由,参与的自治系统也只是传递BGP路由的前缀源的变化信息,没有涉及到具体的BGP路由,因而不会泄露任何自治系统的私密路由信息.
2.
2协作监测前缀直观地,宣告方验证前缀的思想可以保证检测前缀劫持的误检率低至0%,但问题是,在自治的互联网路由环境中,Co-Monitor机制没有办法强制一个自治系统为其他自治系统无偿地提供监测服务.
比如,在没有得到收益的情况下,图1中的参与者E和F很可能不愿意为参与者A监测前缀P并提供通知消息,从而导致参与者A检测前缀劫持的漏检率相当高.
其实,这也正是当前网络运营商在检测前缀劫持时面临的主要困难.
在现实中,某自治系统的网络管理员需广泛了解其他自治系统拥有的相关路由信息,在综合分析以后,才能确定其宣告的前缀是否被劫持,而互联网域间路由系统的自治特性把不同自治系统的网络管理员局限在各自的管理域之内,使他们缺乏了解其他自治系统中BGP路由状况的能力,现有的BGP监测方案都没有很好地解决这个问题.
为走出这个困境,我们在Co-Monitor机制中引入了协作监测前缀的思想.
图2展示了这个简单却非常有效的思想,它与P2P计算所倡导的"我为人人,人人为我"的理念十分类似.
这里仍选择ASA,E和F使用Co-Monitor机制,它们分别是前缀P1,P2和P3的合法宣告者,如图2(a)所示.
由于自治系统对自己拥有的IP地址空间负责,2588JournalofSoftware软件学报Vol.
21,No.
10,October2010因而ASA会期望其他所有的自治系统(B~G)学到关于前缀P1的BGP路由都正常,因此正常路由的前缀源信息都应该为二元组(P1,A).
同样,对ASE和F也是如此,它们分别关心二元组(P2,E)和(P3,F).
Co-Monitor机制要求参与者E和F根据参与者A的需要,比如提供的映射关系(P1,A),在各自的路由域中实时监测前缀源信息;若发现不一致,比如,假若前缀源信息变为(P1,G),它们就立刻通知参与者A.
同样地,Co-Monitor机制还要求参与者A和E(或者,参与者A和F)也能根据参与者F(或者,参与者E)的需要,实时地监测各自路由域中的BGP路由更新.
从网络层的角度来看,这些参与者构成了一个层叠型的监测网络,如图2(b)所示.
CGFEDABP1P2P3CGFEDABP1P2P3(a)Beforeprefixeswerehijacked(b)Afterprefixeswerehijacked(a)前缀被劫持之前(b)前缀被劫持之后Fig.
2IdeaofcollaborativeprefixmonitoringinCo-Monitor图2Co-Monitor机制中协作监测前缀的思想这种协作监测前缀的思想特别适合自治的互联网域间路由环境.
Co-Monitor机制利用该思想激励自治系统加入系统,并为其他参与者提供本地的前缀监测服务.
自然地,每个参与者就都可以享受到其他参与者提供的前缀监测服务.
在Co-Monitor机制的帮助下,所有参与者可相互合作、完成各自的前缀监测任务.
2.
3前缀劫持检测在介绍了宣告方验证前缀和协作监测前缀的思想以后,下面给出网络运营商利用Co-Monitor机制实时检测前缀劫持的基本过程.
整个检测过程由以下5个关键步骤组成:1)每个参与者首先需要与其他参与者交换自定义的前缀-源自治系统映射表(记为L-table),表中记录了各自的网络管理员所关注的前缀与相应自治系统的对应信息.
当然,这个表中的映射信息不一定就是正确的,涉及到的前缀也不一定就是由该自治系统所宣告的,只要是网络管理员所关心的即可.
2)在交换自定义的映射信息以后,每个参与者都动态地维护着一个全局的前缀-源自治系统映射表(或简称为全局映射表,G-table).
3)与此同时,每个参与者通过哑iBGP会话实时地采集、处理本地路由域中的BGP路由更新报文,并检测每条BGP路由中的前缀源信息.
4)假若某个参与者发现某BGP路由中的前缀源信息与G-table中的某些表项不一致,它就会根据这些表项立刻向相关的参与者发出通知消息.
5)每个参与者在接收到来自其他参与者的通知消息以后,还可以根据本地的预警策略向网络管理员发出前缀劫持警报.
采用这种协作的前缀监测方式,各个网络运营商就都可以实时地检测前缀劫持事件.
3机制设计Co-Monitor机制涉及3类实体:网络管理员、BGP路由器和监测器(monitor),如图3所示.
网络管理员在本文中特指自治系统的管理员,而不是普通网络的管理员,他们维护自身路由域中的BGP路由器,并负责建立、配置和使用自己的监测器.
BGP路由器作为网络管理员选择的路由采集点,负责提供本地路由域中的BGP路由更新.
监测器则是自治系统级别的服务器,负责为网络管理员提供前缀监测服务,其职责包括:通过哑iBGP会话采集本地路由域的BGP路由、检测路由中的前缀源信息以及在监测器之间传递消息等.
为简化起见,我们没有在图2中标出相关的前缀源信息以及前缀源信息的变化.
刘欣等:Co-Monitor:检测前缀劫持的协作监测机制2589BGPupdatesAlarmsConfigurationConfigurationBGPRoutersASBASARMessagesBGPupdatesRRRRRRMonitorAAlarmsNetworkoperatorsMonitorBFig.
3ArchitectureoftheCo-Monitor图3Co-Monitor机制的体系结构在实际应用中,Co-Monitor机制有以下3个特点应予以注意:1)监测器是自治系统级别的服务器,每个自治系统只需设立一个,因而监测器的总数不会很多,不会超过当前自治系统的总数;2)监测器的存在相对会比较稳定,因为网络管理员不会要求其频繁地加入/退出系统;3)监测器由网络管理员设立,因而在网络中的位置可受到特别的考虑,比如,可确保拥有足够的网络带宽.
尽管如此,Co-Monitor机制还存在许多问题需要解决,这里主要讨论其中的3个重要问题:健壮性、安全性以及通信开销.
健壮性Co-Monitor机制的健壮性是指该机制本身减缓前缀劫持影响的能力.
这非常重要,因为前缀劫持可能中断监测器之间的IP层的网络连通性,这会使得监测器不能把通知消息通过IP层直接送到正确的目的地.
比如,在图4(a)中,监测器e和f在正常的情况下都可以利用IP层的网络连通性直接向监测器a传递通知消息.
如果攻击者ASG劫持了监测器a的IP地址所在的前缀P,并且ASF选择该劫持路由为最优路由,这时,即使监测器f检测到了前缀源信息的不一致,它也不能把通知消息送到监测器a;最终,这个通知消息被送往攻击者ASG,如图4(b)所示.
若能利用监测器构成的监测网络来传递通知消息,Co-Monitor机制就能够获得较好的健壮性.
如图4(c)所示,前缀P被劫持不会影响到监测器f与e以及e与a之间的IP层的网络连通性,监测器f可以通过监测器e间接地把消息送到监测器a.
因此,为了获得较好的健壮性,监测器之间需要对通知消息进行路由.
FGDCBEAPrefix:192.
168.
0.
0/16MonitoraIP:192.
168.
0.
1MonitoreMonitorf*FGDCBEAMonitoreMonitorf**Prefix192.
168.
0.
0/16AttackerASHijack*FGDCBEAMonitoreMonitorf**AttackerASHijackPrefix:192.
168.
0.
0/16MonitoraIP:192.
168.
0.
1Prefix:192.
168.
0.
0/16MonitoraIP:192.
168.
0.
1Prefix192.
168.
0.
0/16(a)Beforemonitorawashijacked(b)Aftermonitorawashijacked(c)Aftermonitorawashijackedwithfloodingwithoutflooding(a)监测器a被劫持之前(b)监测器a被劫持之后,无泛洪(c)监测器a被劫持之后,有泛洪Fig.
4InfluenceofprefixhijackingontherobustnessofCo-Monitor图4前缀劫持对Co-Monitor机制健壮性的影响2590JournalofSoftware软件学报Vol.
21,No.
10,October2010安全性Co-Monitor机制可能会受到来自外部攻击者的恶意攻击.
假若图4中的攻击者ASG不仅劫持了ASA的前缀P,而且还刻意伪造了监测器a,那么ASG伪造的监测器不仅可以假冒监测器a接收来自监测器f的通知消息,而且还可以主动地向其他监测器散发虚假的通知消息,这显然危及到了监测器a,甚至整个系统的安全性.
因此,Co-Monitor机制需要提供实体认证机制防范外部攻击者.
另一方面,Co-Monitor机制还可能会受到来自内部参与者的攻击.
假若某个参与者产生了过量的通信开销,或者就是DoS攻击,这会影响系统的性能,严重时甚至会使整个系统瘫痪.
如何防范来自参与者的攻击,从表面上看,这个问题似乎非常棘手,但实际上,对Co-Monitor机制的危害有限,我们在第5节会详细讨论该问题.
但在这里,我们需要明确,Co-Monitor机制应该提供消息抑制措施以减缓参与者的DoS攻击带来的影响.
通信开销Co-Monitor机制的健壮性、安全性和通信开销之间相互关联、相互约束,这使得Co-Monitor机制的设计变得复杂.
考虑到Co-Monitor机制工作在互联网的应用层,相对于健壮性和安全性而言,通信开销问题并不太重要.
因此,我们的设计原则是:首先确保具有较好的健壮性、安全性,在此基础上,尽可能地减少通信开销.
可以看到,在设计Co-Monitor机制时,我们会为了获得较好的健壮性和安全性,而牺牲一定的通信开销和计算能力.
我们认为,为达到上面的设计目标,这种牺牲不仅必要而且值得.
此外,Co-Monitor机制还需要利用其他措施进一步减少通信开销.
比如,Co-Monitor机制应要求监测器通过已经建立的TCP连接尽可能多地传递消息,而又要确保不会传递重复的消息.
下面,我们详细叙述Co-Monitor机制中的关键前缀、实体认证、消息定义、消息传递、成员管理、拓扑维护以及消息抑制等内容.
3.
1关键前缀在当前的互联网中,任何跨自治系统的IP网络应用都有可能受到前缀劫持的影响,Co-Monitor系统当然也不例外.
但值得注意的是,并不是所有的前缀劫持都会与某个IP网络应用相关.
就Co-Monitor机制而言,每个监测器的IP地址所属的前缀格外重要,如果这些前缀被劫持就极有可能影响监测器之间IP层的网络连通性,进而危害Co-Monitor系统的健壮性与安全性;而BGP路由系统中存在的其他前缀则不然,无论它们是否被劫持都不会对Co-Monitor机制产生任何影响.
对于采用Co-Monitor机制的某自治系统而言(比如ASA),如果ASA设立的监测器a的IP地址addr与ASA在BGP路由系统中宣告的前缀P满足条件addr∈P,则称前缀P为ASA的关键前缀(keyprefix).
显然,ASA宣告的关键前缀可能存在多个,这可被称为ASA的关键前缀集(keyprefixset).
然而,受实际网络运营的影响,比如前缀过滤或聚合等,从路由接收者的角度来看,在不同自治系统上观察到的ASA的关键前缀集合可能会不一样,而且它们与ASA宣告的关键前缀集合也可能会不一样.
为便于各个监测器的处理,Co-Monitor机制要求ASA宣告的关键前缀集与其在所有自治系统上的出现都一致.
为满足这个要求,这里对ASA在BGP路由系统中宣告的关键前缀集有3个规定:1)ASA的关键前缀集中含有且仅含有一个关键前缀P;2)ASA的关键前缀P要能够出现在BGP路由系统中的DFZ(defaultfreezone)区域中;3)不同自治系统的关键前缀不能相同.
由于我们要求自治系统的关键前缀集有且仅有一个关键前缀,为方便起见,在本文随后的叙述中对自治系统的关键前缀集与关键前缀这两个概念不加区别地使用.
3.
2实体认证我们设计了一个层次式的PKI帮助认证参与者,该PKI结构如图5所示.
参与者需要使用3类证书:1)用于认证各个RIR(regionalInternetregistry)(比如APNIC,ARIN和RIPE等)的区域互联网登记处公钥证书(RIRCert);2)用于认证自治系统的自治系统公钥证书(ASCert);3)用于认证监测器的监测器公钥证书(MonitorCert).
在该PKI中,各RIR都可以是认证中心(CAs),因而每个参与者必须信任RIR给自己签发的RIRCert证书.
RIR需要给自己分配的每一个自治系统号分别签发一个ASCert证书,该证书把自刘欣等:Co-Monitor:检测前缀劫持的协作监测机制2591治系统号与一个公钥加以绑定,而该公钥对应的私钥则被相应自治系统的网络管理员所持有.
参与者必须给自己设立的监测器签发一个MonitorCert证书,该证书把监测器的IP地址、相应的关键前缀与一个公钥进行绑定.
利用该PKI体系,每个参与者都可以获得可信的关键前缀与自治系统的映射信息,这可为Co-Monitor提供额外的安全保护.
MonitorCertnMonitorCert1ASN=iPublickey=kiSignedbyaRIR.
.
.
.
.
.
CAsRIRs(APNIC,RIPEorARINetc)ASN=1Publickey=k1ASCert1SignedbyaRIRASN=nPublickey=knASCertnSignedbyaRIRMonitorCertiIPaddress=addr1Keyprefix=p1Publickey=m1SignedusingPrivatekeyofk1.
.
.
.
.
.
ASCertiRIRCertIPaddress=addriKeyprefix=piPublickey=miSignedusingPrivatekeyofkiIPaddress=addrnKeyprefix=pnPublickey=mnSignedusingPrivatekeyofknFig.
5PKIstructureinCo-Monitor图5Co-Monitor机制中的PKI结构由于ASCert证书对应的私钥只被其所有者用于签发监测器的MonitorCert证书,因此该私钥不必保存在监测器上;而MonitorCert证书对应的私钥则必须存储在监测器上,该私钥被监测器用于与其他的监测器建立安全的TCP会话,以及对生成的消息进行签名等操作.
这种ASCert证书与MonitorCert证书相分离的设计能够提供额外的安全保护.
假若监测器被攻击者侵害,则只会泄露MonitorCert证书对应的私钥,而不会对ASCert证书及其对应的私钥有任何影响.
当然,在出现这种情况后,网络管理员需要撤消并重新签发MonitorCert证书.
至于对该PKI的管理,比如证书的分发和撤消等,可与普通PKI的管理相似.
由此,我们可以假设每个参与者都能够便捷地获得所有需要的公钥证书.
为确保系统的安全性,每个参与者的监测器都必须执行以下操作:1)每当一个监测器与另一个监测器建立TCP会话时,它们都需要验证对方的身份,如果验证失败则不能建立会话;2)每当一个监测器生成了一个消息,它都要对该消息进行数字签名;3)每当一个监测器接收到了一个消息,它都要对该消息的数字签名进行验证,如果失败则丢弃该消息.
3.
3消息定义在Co-Monitor机制中,我们一共定义了CONNECT_REQUEST,CONNECT_ACK,CONNECT_NAK,DISTRIBUTE,PUSH和HELLO这6种消息.
前3种消息用于维护监测器之间的TCP会话连接;后3种消息则用于监测器之间交换信息,与前3种消息不同,它们会被监测器中转传递.
由于Co-Monitor机制的语意只与后3种消息密切相关,下面仅对它们进行说明:1)DISTRIBUTE消息:每当监测器上的L-table表被修改,该监测器就要通过DISTRIBUTE消息向其他监测器宣告该表的变化情况,该消息的主要作用是分发自定义的前缀-源自治系统映射表内容;2)PUSH消息:每当监测器发现本地BGP路由中的前缀源信息与G-table表中的某些项不一致,该监测器就会立刻向相关的监测器发出PUSH消息,该消息的主要作用是通知前缀源信息的不一致事件;3)HELLO消息:每当监测器在规定的时间内没有产生任何DISTRIBUTE和PUSH消息,该监测器就会向其他监测器发送HELLO消息,以向其他监测器报告自己依然处于存活状态,该消息的主要作用是辅助成员管理.
为了能够确认消息来源的真实性,消息内容一旦被生成并签名以后,在传播的过程中不应该被改变;而为了控制消息的传播,消息本身又必须携带可被中转监测器修改的内容,比如TTL(timetolive)信息.
为满足这种看似2592JournalofSoftware软件学报Vol.
21,No.
10,October2010矛盾的需求,我们设计了可变化的消息头(header)和不可变的消息体(body)相结合的消息结构,如图6所示.
012301234567890123456789012345678901+|TTL|Length|+|Command|+|MessageID|+|||MessageData(variable)|||-+|||Signature(32octets)|||-+HeaderBodyFig.
6MessagestructuresofDISTRIBUTE,PUSHandHELLOinCo-Monitor图6Co-Monitor机制中DISTRIBUTE,PUSH和HELLO的消息结构消息头含有TTL和Length两个域:1)TTL域记录该消息还可被监测器转发的最大跳步数.
每当监测器向另一监测器传递消息,都要把该消息的TTL值减1;当TTL值为0时,该消息不再被转发.
2)Length域记录了该消息的消息体的大小,用于定位消息流中的不同消息.
消息体含有Command,MessageID,MessageData和Signature这4个域:1)Command域记录了该消息的类型(DISTRIBUTE,PUSH或HELLO).
2)MessageID域记录了标识该消息的ID号.
3)MessageData域的大小可变,具体的结构与消息类型相关.
应当注意,当消息类型是HELLO时,该域的大小为零字节.
4)Signature域用于记录该消息的创建者对Command,MessageID和MessageData这3个域中内容的数字签名.
3.
4消息传递监测器生成的DISTRIBUTE和HELLO消息需要传递到系统中的所有参与者,而PUSH消息只需要传递到系统中的相关参与者.
从消息的性质来看,DISTRIBUTE和HELLO消息在Co-Monitor机制中是广播消息,而PUSH消息则是单播消息.
为了保证具有较好的健壮性、安全性以及较低的通信开销,Co-Monitor系统自身会维护一个与底层物理网络拓扑相一致的应用层网络.
在该网络上,监测器采用标准的泛洪方式(flooding)传递DISTRIBUTE和HELLO消息.
至于PUSH消息,监测器采用伪泛洪方式(pseudo-flooding)传递,这种传递方式如图7所示.
MPUSH(toA)Yes!
APUSH(toA)MPUSH(toA)CanIreachmonitorAwithTCPconnectiondirectlyPUSH(toA)PUSH(toA)PUSH(toA)No!
Fig.
7DistributingofPUSHmessageinCo-Monitor图7Co-Monitor机制中PUSH消息的传递方式每当一个监测器,比如M,决定转发一个PUSH消息的时候,它首先会试图与该消息的目的地,比如A,建立TCP会话.
如果会话建立成功,监测器M则会直接把该PUSH消息送到目的监测器A,如图7(a)所示.
如果会话没TTLLengthCommandMessageIDMessagedate(variable)Signature(32octets)HeaderBody刘欣等:Co-Monitor:检测前缀劫持的协作监测机制2593有建立成功,监测器M就会把该PUSH消息传递给所有的邻居监测器,请求它们帮助转发,如图7(b)所示.
也就是说,只有在不能通过IP层的网络连通性直接送达PUSH消息的情况下,监测器才会利用Co-Monitor系统维护的应用层网络传递该PUSH消息.
3.
5成员管理实体认证可简化Co-Monitor机制中的成员管理工作.
当某自治系统决定加入Co-Monitor系统时,其网络管理员就可以通过PKI的管理体系把MonitorCert证书分发给所有的监测器,可以认为这步操作是成员加入(join);而当某自治系统决定退出Co-Monitor系统时,其网络管理员就可以把MonitorCert证书撤消,从而可以认为这步操作是成员退出(disjoin).
然而,某自治系统在分发MonitorCert证书以后,可能不会马上设立或者启动监测器;另一方面,某自治系统在关闭监测器后,也可能不会马上撤消MonitorCert证书.
因此,监测器还需要借助TMessage定时器和HELLO消息跟踪每个监测器的状态,以有效地管理成员.
监测器在启动后,首先要根据获得的所有MonitorCert公钥证书构造一张成员列表(Member-Table).
该成员列表中的每一项是一个五元组IPaddr,ASN,KeyPrefix,Status,Time对应着一个成员,其中IPaddr域为该成员的IP地址,ASN域为该成员的自治系统号,KeyPrefix域为该成员的关键前缀,Status域中记录着该成员的当前状态,Time域中记录着还剩多少时间TMessage定时器超时(默认为3分钟).
每个监测器都要记录Co-Monitor系统中每个参与者的存活状态,相应的状态转换图如图8所示.
Dead状态代表该成员处于退出系统的状态.
在Active(还是初始状态)或Neighboring状态下,只要在规定的时间内,监测器没有接收到源自该成员的任何消息,该成员的状态就转换为Dead状态.
Active和Neighboring状态都代表该成员处于系统中,如果要停留在这两个状态,监测器则必须在规定的时间内至少接收到源自该参与者的一个消息.
特别地,Neighboring状态指出了监测器与该参与者建立了邻居关系.
我们将在下一小节讨论如何选择处于Active状态的参与者为邻居.
Fig.
8LifestatetransferringgraphofparticipantsinCo-Monitor图8Co-Monitor机制中参与者的存活状态转换图3.
6拓扑维护在Co-Monitor机制中,所有监测器共同形成了一个位于互联网应用层的覆盖网络,该网络的拓扑结构不仅对Co-Monitor系统自身的健壮性有很大影响,而且也会影响系统给底层IP网络带来的通信开销.
理想情况下,监测网络的拓扑结构应与互联网的自治系统级拓扑结构相一致.
由于每个监测器都要实时采集本地路由域中的BGP路由更新,这有助于Co-Monitor机制达到上面的目标.
直观地,通过分析每条BGP路由中的AS_PATH属性信息,监测器就可以构造出互联网的自治系统级拓扑,再结合自身维护的成员列表,就都能选出临近的成员,从而使Co-Monitor系统构造的拓扑结构与互联网拓扑相一致.
我们注意到,整个Co-Monitor系统的拓扑结构在本质上应反映出所有监测器在IP层的互连结构,在此基础上,与互联网拓扑结构相一致才有意义.
基于这个认识,我们在选择监测器的邻居时仅仅使用含有关键前缀的BGP路由,因为非关键前缀的路由与监测器之间的IP层的网络连通性无关.
此外,考虑到自治系统级拓扑的相对稳定性,监测器并不需要根据BGP路由信息完全动态地选择邻居.
2594JournalofSoftware软件学报Vol.
21,No.
10,October2010我们把监测器的邻居选择任务划分为两个部分:1)维护关键前缀的AS_PATH信息;2)更新成员列表中成员的Neighboring状态.
在第1部分中,根据实时采集的关键前缀的路由,监测器动态地维护一个容器(aspath_pool),它专门管理AS_PATH信息.
比如,每当ASA的监测器a采集到含有关键前缀的BGP路由,就取出AS_PATH属性(记作aspath),然后把其放入该容器.
在第2部分中,监测器每隔一定时间执行find_neighbors算法找出邻居集,然后更新成员列表中相应成员的状态.
ASA的监测器a执行的find_neighbors算法如下:0)初始构造一个与aspath_pool同类型的临时容器,记作aspath_pool_tmp,以及一个用于存放AS号的临时容器,记作as_set;1)依次对aspath_pool中每个aspath进行第2步处理,其中aspath=(AS1,AS2,…,ASn)(n≥1);2)根据aspath中元素顺序生成一个新的AS_PATH,记作aspath_tmp(注意,aspath_tmp中每个AS都存在于监测器a的成员列表中,并且状态为Active),然后把aspath_tmp放入临时容器aspath_pool_tmp,返回第1步;3)依次对aspath_pool_tmp中每个aspath_tmp进行第4步处理,其中aspath_tmp=(AS1,…,ASm)(1≤m≤n);4)除AS1不能确定外,把aspath_tmp中所有非邻居元素AS2,…,ASm放入临时容器as_set,返回第3步;5)最后,将监测器a的成员列表中所有AS减去临时容器as_set中所有AS,就得到了监测器a的邻居集.
3.
7消息抑制监测器有可能无意或恶意地产生大量的转发消息,这会给整个Co-Monitor系统带来不利影响.
为缓解这种来自合法参与者的问题,Co-Monitor机制应采取必要措施惩罚那些生成过量转发消息的监测器.
我们的基本思路是:在某个时间段内,如果监测器a接收到源自监测器b的过量消息,监测器a就给予监测器b一段时间的惩罚,在这个时间内,监测器a不会再转发源自监测器b的任何消息.
为实现这个消息抑制措施,我们需要在成员列表中加入3个附加域,它们分别是时间记数器T、消息记数器C以及惩罚时间记数器R.
根据实际情况的不同,网络管理员可以给不同监测器的这3个记数器赋予不同的初值.
比如,监测器a的网络管理员可以给监测器b赋予的记数器初值分别为T=600(s),C=1000个,R=300(s).
至于监测器b在正常状态和惩罚状态之间的转换与动作细节,设计起来并不困难,这里不再赘述.
4实验与评估通常,人们通过误检率和漏检率这两个关键指标评估监测系统的检测能力.
在前面的讨论中,我们曾指出,由于Co-Monitor系统自身的特点使得其检测前缀劫持的误检率为0%;然而,对Co-Monitor系统检测前缀劫持漏检率的讨论却要复杂得多.
本节首先评估影响漏检率的关键因素——监测范围;然后再评估漏检率.
4.
1监测范围自治系统的网络管理员在互联网中所能达到的路由监测范围是能否检测出前缀劫持的关键因素.
在自治的互联网中,一个自治系统的网络管理员通常只能监测本地路由域,如图9所示.
这个特点对网络管理员监测前缀劫持极为不利,因为他们还需要广泛了解其他自治系统中的BGP路由状态才能发现自己的前缀是否被劫持.
好的监测方案要能帮助单个自治系统扩大在互联网上的监测范围.
可令INT代表互联网中自治系统的全集.
对于互联网中的任意一个自治系统而言,比如ASA,令其邻居自治系统集为SA.
在实际的网络运营中,自治系统在本地路由域中可监测到来自邻居宣告的BGP路由.
显然,一个自治系统的邻居越多,它的监测范围也就越广.
比如,图9中ASC的监测范围就要比ASA的监测范围大.
因此,在通常情况下,可用ASA的邻居数与其自治系统邻居数的比值来定义ASA的监测范围,记作VA,即EGFCDABFig.
9MonitoringboundaryofsingleAS图9单个自治系统的监测边界刘欣等:Co-Monitor:检测前缀劫持的协作监测机制2595||||AAINTSVSαα∈=∑,VA∈[0,1](1)在公式(1)中,当VA=0时,表示ASA不能监测互联网的任何部分,也就是说,ASA没有与互联网相连;而由于ASA不可能监测到整个互联网,因此,VA不能为1.
可令加入Co-Monitor系统的自治系统集合为COM.
当ASA不在集合COM中时,其监测范围满足公式(1);但是,当ASA在集合COM中时,由本文Co-Monitor机制的特点,COM集合中的所有自治系统都会分享各自的监测范围.
因此,ASA的监测范围会扩展到COM集合中的所有自治系统,即可得到如下公式:||||COMAINTSVSββαα∈∈=∑∑,VA∈[0,1](2)在公式(2)中,当VA=0时,表示COM集合中仅有ASA并且该AS没有与互联网相连;而与公式(1)不同的是,VA可以为1,因为当所有自治系统都属于COM集合时,ASA就可以监测整个互联网.
利用式(1)和式(2),我们使用RouteViews提供的BGP路由数据[22],具体选用路由表快照的时间点为2007年6月20日10时,对自治系统加入与不加入Co-Monitor系统所具有的监测范围进行评估.
为突出效果,我们把各自治系统按邻居数由大到小排序,并按1~28831的顺序依次赋予ID值.
图10(a)展示了互联网上的各自治系统在不加入Co-Monitor系统情况下,各自所具有的监测范围值;而图10(b)则展示了随着加入Co-Monitor系统的自治系统数目的增长(按ID值从小到大的顺序依次加入),各参与者所具有监测范围值的变化情况.
15000100001500020000250002883110-610-510-410-310-210-1ASIDMonitoringScope15000100001500020000250002883100.
20.
40.
60.
81NumberofParticipantsMonitoringScope(a)MonitoringscopewithoutCo-Monitor(b)MonitoringscopewithCo-Monitor(a)不加入Co-Monitor时的监测范围(b)加入Co-Monitor时的监测范围Fig.
10ComparisonofmonitoringscopeofASbetweenCo-Monitorandnon-Co-Mointor图10AS加入Co-Monitor与不加入Co-Mointor的监测范围比较对比图10(a)和图10(b)可以看到,当不加入Co-Monitor系统时,邻居数最多的自治系统(AS701,其ID=1)的监测范围为2.
2%,而绝大多数自治系统的监测范围非常小,几乎为0;当加入Co-Monitor系统时,单个自治系统的监测范围可随整个系统中参与者的增加而显著扩大.
特别地,只要最大的10个自治系统采用本文方案,系统中的每个自治系统就至少可监测到当前互联网的13%以上;为了监测到互联网范围的50%,也只需要900多个自治系统加入Co-Monitor系统即可,而这个数目还占不到当前自治系统总数的4%.
4.
2漏检率直观地,越多的自治系统加入Co-Monitor系统,系统中每个参与者的监测范围越大,检测前缀劫持的漏检率就会越小;另一方面,Co-Monitor系统是否能够检测到互联网中的前缀劫持事件,不仅与系统中参与者集合的增长方式有关(影响监测范围),还取决于前缀劫持发生的位置以及传播的途径等多方面因素.
本节主要评估Co-Monitor系统的漏检率与参与者集合增长方式之间的关系.
首先,为便于评估Co-Monitor系统的漏检率,我们需要对如下两个问题做出合理的假设:1)Co-Monitor系统101106Monitoringscope103104105102150001000015000100002500028831ASID150001000015000100002500028831Numberofparticipants1.
00Monitoringscope0.
60.
40.
20.
82596JournalofSoftware软件学报Vol.
21,No.
10,October2010如何增长即参与自治系统(监测点)的选取问题;2)前缀被劫持的路由如何在互联网上传播.
对于前一个问题,我们假设在BGP路由系统中,宣告越多前缀的自治系统就越会期望加入Co-Monitor系统,因为它们期望Co-Monitor系统为它们宣告的前缀提供实时的前缀监测服务.
基于这样的考虑,我们在选取监测点时,最优采取策略是:首先依次选取宣告前缀数目多的自治系统;在前缀数目相等的情况下,再依次选取邻居数目多的自治系统;而如果两个自治系统宣告的前缀数和邻居数都一样,则选取自治系统号小的那个自治系统.
文献[25]指出,在不考虑路由聚合和路由安全过滤的情况下,劫持路由和正常路由都是按相同的方式传播.
因此对于第2个问题,我们假设任何自治系统都可能劫持别人的某个前缀且概率均等,并且,任何合法的自治系统路径都有可能是劫持路由的传播途径且概率均等.
显然,基于这样宽泛的假设,我们评估的是检测前缀劫持的漏检率的上界.
可令BGP路由系统中所有的有效自治系统路径所构成的集合为PATHS(这里所说的有效路径是指满足自治系统商业互连关系的无谷底(novalley)路径[26]),而令PATHS集合中所有涉及Co-Monitor系统中参与者的路径集合为PATHSCOM(显然PATHSCOMPATHS).
由Co-Monitor系统检测前缀劫持的特点可知,在各参与者确保自定义的前缀-源自治系统映射表完整、正确的前提下,在PATHSCOM中任何一条路径上传播的劫持路由都可能被Co-Monitor系统发现,由此可得如下漏检率计算公式:||1||COMPATHPATHS(3)图11展示了Co-Monitor系统检测前缀劫持的漏检率随参与者数目增长而发生变化的情况.
实验数据来自RouteViews公布的2008年06月30日08时BGP路由表,其中共有28821个自治系统.
这里考虑了3种选取参与者的策略:1)前面所说的最优采取策略(optimizedselection);2)最糟糕的选取策略,也就是最优选取策略的逆过程(reverseoptimizedselection);3)随机选取策略(randomselection).
图11(a)给出了这3种选取策略下的漏检率变化情况.
可以看到,不同的选取策略对Co-Monitor系统检测前缀劫持的漏检率影响极大,特别是最优选取策略,几乎可以确保漏检率为0%.
为进一步了解在最优采取策略下漏检率的变化情况,图11(b)只给出了参与者数从1增长到100时漏检率的变化情况.
由图11(b)可以看到,当Co-Monitor系统中有20个参与者时,漏检率仅为15.
16%;当有40个参与者时,漏检率就可低至3.
32%;而只要有60个参与者时,漏检率几乎为0%.
1500010000150002000025000288310.
00.
20.
40.
60.
81.
0NumberofparticipantsFalsenegativeratioReverseoptimizedselectionRandomselectionOptimizedselection1204060801000.
00.
20.
40.
60.
81.
0NumberofparticipantsFalsenegativeratio(a)Falsenegativeratiounderdifferentselectionpolicies(b)Falsenegativeratiounderoptimizedselection(a)在不同选择策略下的漏检率变化情况(b)在最优采取策略下的漏检率变化情况Fig.
11Comparisonoffalsenegativeratiounderdifferentselectionpolicies图11不同选择策略下的漏检率变化情况比较5相关讨论本节讨论几个与Co-Monitor机制相关的问题.
(1)PKI结构的实用性问题.
S-BGP协议中需要两个PKI结构分别用于认证自治系统号和网络前缀的所有刘欣等:Co-Monitor:检测前缀劫持的协作监测机制2597权.
文献[11]指出,用于认证自治系统号的PKI规模不大,实际部署可行.
但是,用于认证网络前缀的PKI结构过于庞大,这是S-BGP协议难以被实际应用的重要原因之一.
本文不存在认证网络前缀的问题,而且与S-BGP协议中认证自治系统号的PKI结构相比,存在以下4个优势:1)以自治系统为签发对象而不是网络运营商,本文的PKI结构的稳定性更好;2)ASCert证书的签发方式与当前自治系统号码资源的管理模式相一致,并且本文的PKI结构忽略了ICANN,这样的PKI结构更为简单和实用;3)整个PKI结构涉及的证书数量不多,包括5个RIR的RIRCert证书、所有参与自治系统的ASCert证书以及相应的MonitorCert证书(总数为5+2*N,其中N为参与者数);4)由于Co-Monitor机制位于互联网的应用层,利用PKI对其进行安全保护不存在部署与应用上的困难.
(2)参与者的恶意攻击问题.
Co-Monitor机制通过实体认证可以有效防范来自系统之外的恶意攻击,但合法的参与者也有可能执行危害系统的行为.
比如,参与者可能恶意丢弃消息、发送虚假的消息或是DoS攻击等.
我们要阻止来自参与者的这些恶意攻击非常困难,因为它们都拥有合法的身份.
但是,这些恶意行为对Co-Monitor机制的影响不大,原因如下:①前缀被劫持的路由通常会被扩散到多个自治系统,这被多个参与者观察到的概率极大,少数恶意参与者丢弃消息或发送虚假的消息并不会影响到其他多数参与者发送真实的消息;②我们利用消息抑制措施可以缓解DoS攻击的影响,并且系统中的任何消息都经过签名,因而可知DoS攻击的确切来源.
(3)搭便车(freeriding)问题.
一般的P2P应用中都存在搭便车的问题,即某些对等体只愿享受别人提供的服务,自己却不愿为别人提供服务.
在Co-Monitor机制的实际应用中也可能出现类似的现象,即可能会有某些参与者只愿享受来自其他参与者提供的前缀监测服务,自己却不愿为其他参与者提供前缀监测服务.
具体做法是,这些自治系统的网络管理员不在监测器与本地路由域中的BGP路由器之间配置BGP会话.
但我们认为,搭便车问题在Co-Monitor机制中并不是一个问题:首先,Co-Monitor机制不会泄露参与者的私密路由信息,这在前面已经说明过;其次,参与者为其他参与者提供前缀监测服务,不仅对他人有益,而且对其自己也是有益的,因为这可以让他人帮助检查自己接收的路由;最后,如果参与者还是不愿意提供前缀监测服务,这也没有问题,只要其加入了Co-Monitor系统,它就会为成为覆盖网络的一部分,从而可增强系统的健壮性.
6结论及工作展望本文结合协作监测前缀和宣告方验证前缀的思想解决了现有BGP监测系统所面临的问题.
本文提出的Co-Monitor机制适应当前自治的互联网环境,可逐步地实际部署,不需要对BGP协议进行任何安全扩展,并且能够保护参与者的私密路由信息,这些特性使其可以有效地帮助网络管理员实时地检测前缀劫持事件.
我们将来的工作主要集中在Co-Monitor机制的实际应用与部署等方面.
另外,考虑利用Co-Monitor平台支持更丰富的自治系统协作工作也是我们着重要关注的问题.
致谢感谢审稿人对论文初稿提出的宝贵意见.
References:[1]RekhterY,LiT,HaresS.
Abordergatewayprotocol4(BGP-4).
RFC4271,IETF,2006.
[2]NordstrmO,DovrolisC.
BewareofBGPattacks.
ACMSIGCOMMComputerCommunicationsReview,2004,34(2):18.
[3]BonoVJ.
7007Explanationandapology.
1997.
http://www.
merit.
edu/mail.
archives/nanog/1997-04/msg00444.
html[4]PopescuAC,PremoreBJ,UnderwoodT.
Anatomyofaleak:AS9121.
2005.
http://www.
nanog.
org/mtg-0505/underwood.
html[5]FarrarJ.
C&Wroutinginstability.
2001.
http://www.
merit.
edu/mail.
archives/nanog/2001-04/msg00209.
htm[6]FergusonP.
GoogleDNSproblems.
2005.
http://www.
merit.
edu/mail.
archives/nanog/2005-05/msg00238.
html[7]WanT,OorschotPC.
AnalysisofBGPprefixoriginsduringGoogle'sMay2005outage.
In:Proc.
ofthe20thIEEEInt'lParallelandDistributedProcessingSymp.
(IPDPS2006).
Washington:IEEEComputerSocietyPress,2006.
http://ieeexplore.
ieee.
org/xpl/freeabs_all.
jsparnumber=1639679[8]PakistanhijacksYouTube.
2008.
http://www.
renesys.
com/blog/2008/02/pakistan_hijacks_youtube_1.
shtml[9]KentS,LynnC,SeoK.
Securebordergatewayprotocol(S-BGP).
IEEEJournalonSelectedAreasinCommunicationsSpecialIssueonNetworkSecurity,2000,18(4):582592.
2598JournalofSoftware软件学报Vol.
21,No.
10,October2010[10]WhiteR.
SecuringBGPthroughsecureoriginBGP.
InternetProtocolJournal,2003,6(3):1522.
[11]KranakisE,WanT,OorschotPC.
OninterdomainroutingsecurityandprettysecureBGP(psBGP).
ACMTrans.
onInformationandSystemSecurity,2007,10(3):141.
[12]XuK,XiongYQ,WuJP.
SecurityextensionofbordergatewayprotocolBGP-4.
ActaElectronicaSinica,2002,30(2):271273(inChinesewithEnglishabstract).
[13]LiuX,ZhuPD.
Arules-basedapproachtoanomalydetectionininter-domainroutingsystem.
JournalofNationalUniversityofDefenseTechnology,2006,28(3):7176(inChinesewithEnglishabstract).
[14]HuXJ,ZhuPD,GongZH.
SE-BGP:AnapproachforBGPsecurity.
JournalofSoftware,2008,19(1):167176(inChinesewithEnglishabstract).
http://www.
jos.
org.
cn/1000-9825/19/167.
htm[doi:10.
3724/SP.
J.
1001.
2008.
00167][15]KarlinJ,ForrestS,RexfordJ.
PrettygoodBGP:ImprovingBGPbycautiouslyadoptingroutes.
In:DavidL,ed.
Proc.
oftheIEEEInt'lConf.
onNetworkProtocols.
Washington:IEEEComputerSocietyPress,2006.
283292.
[16]ZhengCX,JiLS,PeiD,WangJ,FrancisP.
Alight-weightdistributedschemefordetectingIPprefixhijacksinreal-time.
In:Proc.
oftheACMSIGCOMM2007.
2007.
http://portal.
acm.
org/citation.
cfmid=1282412[17]LiuX,ZhuPD,PengYX.
Internetregistrymechanismforpreventingprefixhijacks.
JournalofSoftware,2009,20(3):620629(inChinesewithEnglishabstract).
http://www.
jos.
org.
cn/1000-9825/3221.
htm[doi:10.
3724/SP.
J.
1001.
2009.
03221][18]LookingGlasses.
2008.
http://www.
traceroute.
org[19]LadM,MasseyD,PeiD,WuYG,ZhangBC,ZhangLX.
PHAS:Aprefixhijackalertsystem.
In:Proc.
ofthe15thUSENIXSecuritySymp.
Berkeley:USENIXAssociation,2006.
153166.
http://www.
usenix.
org/events/sec06/tech/full_papers/lad/lad_html/[20]Ripemyasnsystem.
2008.
http://www.
ris.
ripe.
net/myasn.
html[21]Gradustool.
2008.
http://gradus.
renesys.
com[22]MeyerD.
Routeviewsproject.
2008.
http://www.
routeviews.
org[23]GloorP.
Netlantisproject.
2008.
http://www.
netlantis.
org[24]AtkinsonR,FloydS.
IABconcerns&recommendationsregardingInternetresearch&evolution.
RFC3869,IETF,2004.
[25]LadM,OliveiraR,ZhangBC,ZhangLX.
UnderstandingresiliencyofInternettopologyagainstprefixhijackattacks.
In:Proc.
ofthe37thAnnualIEEE/IFIPInt'lConf.
onDependableSystemsandNetworks.
Washington:IEEEComputerSociety,2007.
368377.
http://ieeexplore.
ieee.
org/xpl/freeabs_all.
jsparnumber=4272988[26]GaoLX.
OninferringautonomoussystemrelationshipsintheInternet.
IEEE/ACMTrans.
onNetworking,2001,9(6):733745.
[doi:10.
1109/90.
974527]附中文参考文献:[12]徐恪,熊勇强,吴建平.
边界网关协议BGP-4的安全扩展.
电子学报,2002,30(2):271273.
[13]刘欣,朱培栋.
基于规则的域间路由系统异常检测.
国防科学技术大学学报,2006,28(3):7176.
[14]胡湘江,朱培栋,龚正虎.
SE-BGP:一种BGP安全机制.
软件学报,2008,19(1):167176.
http://www.
jos.
org.
cn/1000-9825/19/167.
htm[doi:10.
3724/SP.
J.
1001.
2008.
00167][17]刘欣,朱培栋,彭宇行.
防范前缀劫持的互联网注册机制.
软件学报,2009,20(3):620629.
http://www.
jos.
org.
cn/1000-9825/3221.
htm[doi:10.
3724/SP.
J.
1001.
2009.
03221]刘欣(1978-),男,湖南常德人,博士,CCF高级会员,主要研究领域为互联网域间路由.
彭宇行(1963-),男,博士,教授,博士生导师,主要研究领域为并行与分布处理技术,计算机网络技术.
朱培栋(1971-),男,博士,副教授,CCF会员,主要研究领域为路由技术,移动网络,网络安全.