针对P2P直播系统的Eclipse延迟攻击方法研究
韩心慧, 李晨, 肖祥全, 刘丙双, 叶佳奕    
北京大学 计算机科学技术研究所, 北京 100871
摘要:P2P直播系统在当今互联网上的应用越来越广泛, 相对于P2P文件共享系统, 其对数据传输的实时性要求更高, 因此对该类系统实时性的破坏, 即延迟攻击, 产生的危害极大。通过分析相关理论模型, 该文指出P2P直播系统在实时性方面存在安全脆弱性, 基于Eclipse攻击提出了No-Offer、Delay-Chunk和No-Chunk延迟攻击方法, 并提出了基于信誉机制的路由表清洗防御策略。在PlanetLab平台上基于PeerStreamer实施了真实的互联网实验, 证明了Eclipse延迟攻击对当前系统的危害和该文防御策略的有效性。
关键词Eclipse攻击    P2P    直播系统    延迟攻击    
Defense of P2P live video systems facing Eclipse-delay attack
HAN Xinhui, LI Chen, XIAO Xiangquan, LIU Bingshuang, YE Jiayi    
Institute of Computer Science&Technology, Peking University, Beijing 100871, China
Abstract: P2P live video systems are widely used in today's Internet. Compared with eMule/BitTorrent and other traditional P2P file-sharing systems, a P2P live video system has higher requirements on real-time data, which becomes vulnerable weakness. Delay attack, with strong concealment, is potentially lethal for large P2P video broadcasting systems. Theoretical security threats of popular P2P live video systems were analyzed to propose three types of delay attack based on Eclipse attack, No-Offer attack, Delay-Chunk attack, and No-Chunk attack, with a high-availability defense strategy against delay attack being developed. Experiments were made on PlanetLab based on PeerStreamer, which proves the impact of delay attack and the effectiveness of the developed defense strategy.
Key words: Eclipse attack    P2P    live video system    delay attack    

传统的视频直播以电视直播为主,成本高昂。随着Internet的飞速发展,利用网络廉价地进行视频直播已经从实验阶段走向了实用阶段。尤其是基于P2P的网络直播系统[1],已经得到了广泛的应用。近年来国内外研究机构提出了大量开源P2P直播系统,如OverCast[2]、 PALS[3]、 ZigZag[4]和SplitStream[5]等。此外PPLive[6, 7]和PPStream[8, 9]等商用系统也取得了巨大的成功,PPLive在高峰时段有超过800万人同时在线观看。对于用户量如此庞大的系统,如何在各种复杂的环境中保证稳定、高效的视频播放服务至关重要,因此该类系统的安全性受到了研究人员越来越多的关注。

P2P直播系统一方面延续了传统P2P系统的安全问题,例如Sybil攻击[10]、 Eclipse攻击[11, 12]、 内容污染[13]和搭便车(free-rider)[14, 15]等; 另一方面也有一些特有的安全问题[16],例如其对数据传输过程的实时性有更高的要求。针对实时性安全,存在一类特殊的攻击方法,即延迟攻击。在该类攻击中,恶意节点利用Eclipse攻击大量占据受害节点路由表,干扰受害节点正常数据接收过程,造成受害节点接收数据延迟加大。由于视频直播具有非常强的实时性,迟到的数据不具有任何意义,因此延迟攻击能直接影响播放效果,同时具有很强的隐蔽性,难以被受害节点发现。

本文重点研究P2P直播系统的实时性安全。通过建立一个通用的P2P直播系统模型,指出其在安全性方面存在安全脆弱性。基于Eclipse攻击提出了No-Offer、 Delay-Chunk和No-Chunk三种延迟攻击方法,并针对该类攻击的特点提出了基于信誉值机制的路由表清洗策略。最后在PlanetLab平台上基于PeerStreamer实施了真实的互联网实验,有效证明了上述攻击方法的危害和本文防御方法的有效性。

1 相关工作

自从第一个P2P直播系统OverCast[2]提出以来,国内外科研机构针对P2P直播系统的安全性展开了一系列研究工作, 主要集中在内容污染、搭便车和延迟攻击等方面。

内容污染是指恶意节点通过在数据传输过程中将错误的视频数据发送给其他节点,从而破坏直播过程的一种攻击方法。对于内容污染问题,Prithula Dhungel等人[17]通过对PPLive的研究,指出在P2P网络中内容污染具有毁灭性的攻击能力,并提出了4种防御方法。此后,Meier等人[18]针对内容污染提出了一种轻量级的ALPS数据认证机制,Borges等人[19]提出了基于声誉系统的机制。Yang等人[20, 21]则对P2P直播系统中的内容污染进行了测量和建模,证明了采用基于哈希的签名方法防御效果最佳。Li等人[22]也针对内容污染问题进行了一系列建模、模拟和测量研究,并提出一种快速发现和防御恶意节点的方法。

搭便车是指恶意节点只接受数据但不发送数据,降低P2P网络整体服务能力的攻击方法。对于该问题,Feldman等人[15]提出了一种解决方案,所有新节点信誉值都为负数,只有做出实质贡献才能享受更多其他节点的服务,以此解决搭便车及以新身份上线的身份洗白问题。Li等人[23]对恶意否认拥有特定数据块的攻击方法进行了研究,并设计了一个可信赖的差异化服务机制和贡献评价算法缓解该类恶意节点的影响。

延迟攻击是指恶意节点延迟数据交换,破坏数据传输实时性的一种攻击方法。Seedorf等人在文[16]中描述了延迟攻击问题,指出P2P直播系统这类实时应用与文件共享等非实时应用最大的区别在于,除了要保证路由和查询效率,还要保证响应时间。文[24]中提到,P2P直播系统对网络质量的要求非常高,即使一个节点出现的延迟波动,都会影响周围节点的数据接收过程。

由于针对延迟攻击的相关研究工作较少,本文通过关注P2P直播系统运行的各个阶段,有针对性地提出3种基于Eclipse的延迟攻击方法,并提出了基于信誉机制的路由表清洗防御策略,可为后续的工作提供参考。

2 Eclipse延迟攻击模型

本节首先对现有P2P直播系统建模,分析其在实时性方面的安全脆弱性,然后提出3种Eclipse延迟攻击方法。

2.1 P2P直播系统模型

设网络中有N个节点,每个节点的路由表中最多储存t个邻居信息,包括节点ID、 IP地址和端口等。邻居关系是单向的,即A在B的路由表中,B不一定在A的路由表中。全网节点及邻居关系构成了一个有向图,每个顶点的出度约为t。

图1展示了一个N=7、 t=2的P2P直播系统模型示意图。

图1 一个理想状况下的P2P直播系统

直播源只将数据发送给节点1和3,由节点1和3将数据扩散到其他节点处。节点间箭头表示邻居关系,如节点6到节点3的箭头表示节点6的路由表中有节点3,其他节点路由表依此类推。

P2P直播系统中的节点主要参与执行如下两个过程:

1) 路由表维护过程;

2) 数据传输过程。

本文对这两个过程分别进行建模。

2.1.1 路由表维护过程

节点的路由表维护过程旨在将邻居节点数量稳定在t,过少会影响P2P组网效果,过多则会带来额外的存储和维护开销。路由表维护过程主要分为两个阶段。

1) 启动阶段: 向路由表中添加直播源节点,并向其请求第一批邻居节点。该过程一般被称为Bootstrap过程。

2) 运行阶段: 系统在运行过程中会动态地增删邻居,发现新节点时会根据特定选择策略决定是否将其加入路由表; 同时有些邻居会由于无法及时响应保活(keep alive)请求而被从路由表中剔除。

2.1.2 数据传输过程

在P2P直播系统中,直播源将媒体数据编码后分解为带序号的数据分块(Chunk),并将Chunk发送到网络中,数据分块经过多个节点的转发最终被收看者接收。

典型的邻居间数据交换过程如图2所示。

图2 邻居间数据交换过程示意图

数据交换过程可以分为如下3个阶段。

1) 信息交换阶段: 向邻居节点请求数据分块表(ChunkMap),以了解对方拥有哪些Chunk,以及需要哪些Chunk,对应图中步骤①和②;

2) 协商阶段: 节点根据算法,向部分邻居发出授权(Offer),声明自己愿意向其提供哪些Chunk,对应图中步骤③;

3) Chunk传输阶段: 邻居节点之间完成实际Chunk数据的传输,对应图中步骤④和⑤。Chunk传输一般采取时间邻近优先策略,即优先选择媒体流中播放时间邻近的数据块,以避免时间已到而数据未到造成的播放延迟。

2.2 敌手模型

延迟攻击的目标是尽可能使受害节点的播放延迟增大,故本文针对其运行过程中的各个阶段设计了几种阻断或延迟数据传输过程的敌手模型。

Eclipse攻击[11]是指攻击者控制大量攻击节点侵占受害节点路由表,将足够多的攻击节点添加到其邻居节点集合中,从而将受害节点隔离在正常网络之外的攻击方法,又被称为路由表毒化攻击。它是延迟攻击的基础,这里首先引入Eclipse攻击模型。

图3所示,攻击节点向受害节点发起Eclipse攻击,将受害节点分割为两个较小的网络。图中凡是有攻击节点参与的边为攻击边(虚线),其余为普通边(实线)。两个受害节点集合之间要正常传递数据,必须经由普通节点转发,即通过普通边。然而攻击者一般会创建大量攻击边,尽可能降低普通边在所有连接关系中的比例,导致其被选择的概率远低于攻击边。

图3 Eclipse攻击模型示意图

该模型假设: 攻击者发起攻击时,刻意以较高的速率与受害节点通信,主动请求加入其路由表。攻击节点之间不发生同谋,每一个攻击节点都独立地向受害节点发送请求。模型中的非攻击节点严格遵守系统协议规范,同时不知道攻击节点的存在; 每个攻击节点都有其他攻击节点信息,可以不遵守系统规则。

攻击节点发起Eclipse攻击后,受害节点发送的消息大概率被其截获,进而可以实施No-Offer、 Delay-Chunk和No-Chunk三种延迟攻击。

2.2.1 No-Offer攻击

No-Offer攻击是指在信息交换阶段,攻击节点延迟或拒绝与受害节点进行ChunkMap交换; 或者在协商阶段,延迟或拒绝向受害节点发送Offer。它发生在图2所示数据交换过程中步骤②或③。

对于受害节点,如果没有节点向它提供Chunk,它只能等待(延迟播放),直到某一个邻居获得了Chunk并愿意向其提供为止。这就达到了延迟攻击的目的。

该攻击方法操作简单,带宽消耗低而攻击效果好,即费效比较高。但无回复的行为很容易被发现,隐蔽性较差,容易被受害节点屏蔽。

2.2.2 Delay-Chunk攻击

Delay-Chunk攻击是指在Chunk传输阶段故意延迟发送Chunk数据。它发生在图2所示数据传输过程的步骤⑤。这种延迟行为会降低在播放时刻之前收到媒体数据的概率,最终降低受害节点的收看效果。同时由于网络传输延迟是一种很普遍的现象,故Delay-Chunk攻击非常隐蔽。

2.2.3 No-Chunk攻击

No-Chunk攻击是指不发送Chunk,或者延迟大于超时阈值的时间后再发送Chunk。该方法是Delay-Chunk攻击的延伸,同样发生在图2所示数据传输过程中的步骤⑤。它最大化地利用了Chunk传输的超时阈值,效果要好于Delay-Chunk攻击。在不发送Chunk数据的情况下,其缺点与No-Offer攻击类似,容易被受害节点发现并屏蔽。

2.3 攻击效果分析

正常情况下,节点路由表中的t个邻居是完全随机的,其中攻击节点比例与其在全网中的比例一致,假设为p。但在Eclipse攻击中,攻击节点主动请求加入受害节点路由表,受害节点路由表中攻击节点占比会明显高于p。

攻击节点没有受害节点的列表,只能根据节点特征识别受害节点。假设全网节点总数为N,攻击节点能接触到总量为n的随机节点,攻击节点比例为p,受害节点比例为q; 则攻击节点总数为Np,攻击节点接触到的受害节点总数为nq。假设攻击节点总是能够进入到受害节点的路由表中,则攻击节点在全网受害节点路由表中的出现次数为freqattacker,可参见式(1)。

freqattacker=Np×nq. (1)

进一步可计算出攻击节点在受害节点路由表中占比为ratioattacker,参见式(2)。

ratioattacker=$\frac{{Np \times nq}}{{Nq}} \times \frac{1}{t} = \frac{{np}}{t}$ (2)

可见对于路由表容量t,Eclipse攻击的效果主要由攻击节点比例和每个攻击节点所能控制的范围决定,攻击节点比例越高,攻击节点控制范围越大,则攻击效果越好。

在No-Offer攻击中,攻击节点延迟或拒绝提供ChunkMap与Offer信息,造成受害节点判定Chunk数据来源的过程执行速度变慢; 而Chunk数据必须在协商结束后才能请求,故No-Offer攻击利用了ChunkMap与Offer信息交换的两个等待时间窗口,可增加受害节点的数据延迟。

在Delay-Chunk攻击中,主要利用了受害节点等待Chunk数据到来的时间窗口来达到延迟攻击效果。该时间窗口至少应与数据包在网络上的传输延时相当,即达到秒级。设时间窗口为w,假设正常情况下邻居发出的Chunk等概率地分布在w时间内,那么平均到达延时为 $\frac{2}{w}$ 。在此基础上,攻击节点引入的延迟会直接累加在 $\frac{2}{w}$ 上,成为受害节点的额外延迟。同时由于P2P网络基于节点间高度协作,攻击节点不协作会造成受害节点难以及时接收到数据,与受害节点联系的普通节点也会受到牵连,依此类推,这种雪崩效应将影响到全网的性能。

相对于Delay-Chunk来讲,虽然No-Chunk攻击更容易被识别,但其100%利用了受害节点等待Chunk数据到来的时间窗口,攻击效果更好。

3 Eclipse延迟攻击实验

在P2P直播系统模型和理论分析的基础上,本节将在PlanetLab平台上基于PeerStreamer设计真实互联网实验,验证这些攻击方法的有效性。

3.1 实验设计

本实验中使用NAPA WINE研究计划[25]的PeerStreamer开源项目(版本号1.2.0),将其部署到PlanetLab的1 000个节点上,其中20%为攻击节点,20%为受害节点,其余为普通节点。在实验中记录每个节点的两个关键数据:

1) 路由表状态,即节点路由表中的邻居列表;

2) 播放率,即每s所需的媒体数据在播放时刻到达的比例。如某1 s的媒体数据共分为100个数据包,节点在播放时刻只收到70个,则播放率为70%,即0.7。该指标可以反映数据延迟情况,同时可反映节点的播放效果。

为了便于对比,本文同时设置了标准组实验,其中所有节点都是正常节点,没有攻击节点。

No-Offer攻击作用于send_offer过程,攻击节点在发送Offer之前先根据对方节点特征判断是否为攻击目标。如果是攻击目标,就不发送ChunkMap及Offer消息。

Delay-Chunk攻击作用于send_chunk过程,攻击节点在发送chunk数据之前,先判断对方是否是攻击目标。若是,则将chunk数据延迟一定时间发送。在实验过程中,初始延迟量设定为1 s,每隔300 s延迟量增加1 s。

No-Chunk攻击同样作用于send_chunk过程,攻击节点在发送chunk数据之前,先判断对方是否是攻击目标。如果是,就不发送chunk数据。

3.2 实验结果分析

图4给出了攻击节点发起Eclipse攻击后,普通节点与受害节点路由表中平均恶意节点数量随系统启动时间变化情况。PeerStreamer节点的路由表中最多储存30个邻居节点信息。

图4 普通和受害节点路由表中恶意节点数量变化情况

当PeerStreamer节点播放率降低,即不能及时收到数据时,该节点会降低画面质量。因此这里使用播放率作为衡量延迟攻击效果的指标。

图5给出了No-Offer攻击中普通节点和受害节点播放率随系统启动时间的变化情况。

图5 No-Offer攻击中普通和受害节点播放率变化情况

图5表明攻击节点的加入使全网性能受到影响,普通节点的播放率水平从标准组实验的0.85左右下降至低于0.8,而受害节点的播放率显著下降至0.6左右,即约40%的视频数据无法在预定时间内被接收。同时,受害节点从播放启动到播放率稳定的时间间隔从40 s被延长到60 s左右。

图6给出了Delay-Chunk攻击中普通节点和受害节点播放率的变化情况。实验设置如3.1节所述,初始延迟量为1 s,启动900~1 200 s时延迟增加到4 s。

图6 Delay-Chunk攻击中普通和受害节点播放率变化情况

可以看到由于延迟量随着系统启动时间递增,普通节点及受害节点的播放率都渐次降低,全网性能下降。受害节点播放率最终稳定在0.5左右,说明4 s的延迟量基本达到了受害节点等待Chunk数据的时间窗口上限w

图7展示了No-Chunk攻击中普通节点和受害节点播放率的变化情况。

图7 No-Chunk攻击对受害节点播放率影响情况

该结果与Delay-Chunk攻击时的最优效果基本一致,符合上文的分析,即No-Chunk攻击可以充分利用受害节点等待Chunk数据到来的时间窗口上限w

以上实验结果表明,延迟攻击不但使受害节点的播放率下降到0.5至0.6,同时能够在一定程度上降低其他普通节点的播放率,进而引起全网性能下降,对用户收看效果产生显著的影响。

4 Eclipse延迟攻击的防御策略研究 4.1 防御策略设计与实现

针对Eclipse延迟攻击的特点,本文提出了基于信誉机制的路由表清洗策略。通过不断评估路由表中邻居节点的信用,清除潜在的攻击节点; 并为路由表引入有益的扰动,进而增加找到优质邻居节点的概率。

目前P2P系统中通常采用信誉机制作为辨别邻居节点可信度的方法[26, 27, 28]。在该类方法中,对于没有正常应答的节点累计失效计数(failure count),如果失效计数超过阈值,就将其从路由表中删除。本文借鉴该信誉值的思想,针对P2P直播系统的特点,提出了一个基于信誉机制的路由表清洗策略。

该策略主要包括如下3个方面。

1) 双计数淘汰机制。

节点为路由表中的每一个邻居节点维护两个失效计数: 连续失效计数和累计失效计数。针对No-Offer攻击和No-Chunk攻击这类不进行应答的攻击行为,两个失效计数都会在对方节点没有正常回应时递增; 收到正常应答时,只将连续失效计数清零,累积失效计数不清零。每隔一段时间对所有邻居节点进行评估,淘汰连续失效计数超过阈值的节点; 若没有符合条件的节点,则优先淘汰累计失效次数与在线时间比值大的节点。在该机制下,实施No-Offer和No-Chunk的攻击节点会优先被淘汰。

2) 延时罚分机制。

针对Delay-Chunk攻击这种有应答但延迟明显增加的攻击行为,受害节点可以通过为每个回复消息计算罚分来进行甄别。对于越慢的应答给予越高的罚分,从而保留优质邻居,淘汰包括Delay-Chunk攻击节点在内的劣质邻居。假设Chunk数据的超时时间为chunk_time,则对回复按照式(3)计算罚分(超过1分的按1分计算)。

penalty=min$\left( {1,\frac{{response}}{{chun{k_{time}}}}} \right)$ (3)

计算罚分后,将罚分计入节点的累计失效次数。如超时时间为5 s,1 s的应答延迟记作0.2次失效,4 s的应答延迟记作0.8次失效,5 s或者超过5 s的应答延迟记作1次失效,与双计数淘汰机制平滑衔接。

3) 主动替换机制。

通常向优质节点请求邻居能得到更多优质邻居节点。根据失效计数从低到高排序时,攻击节点大多集中在列表的底端,通过向列表顶端的优质节点请求邻居,使用获得的潜在优质邻居随机替换列表底端的劣质邻居。

在该机制下,每次只替换信誉值较低的节点,不会影响对视频数据传输起到关键作用的优质节点,故不会对P2P直播数据的交换产生不利的影响。

4.2 防御策略的实验与分析

本文实现了上述基于信誉机制的路由表清洗策略,并在实际环境中进行了相关实验。该实验与攻击实验类似,以PeerStreamer为对象,在PlanetLab上以相同的网络规模和网络环境进行。在占全网总节点数20%的受害节点中,一半采用防御措施,本文把这类节点称为安全增强节点。

图8展示了安全增强节点在遭到Eclipse攻击时的防御效果。结果显示,安全增强节点路由表中的攻击节点数量平均为3个左右,明显低于其他未采用防御措施的受害节点,并且安全增强节点路由表中有90%的邻居是正常节点,可以保证路由效率。说明该策略对于Eclipse攻击具有良好防御效果。

图8 部署防御策略后节点路由表中攻击节点数量对比
4.2.1 对No-Offer攻击的防御效果

图9展示了部署防御策略后,No-Offer攻击过程中节点播放率变化情况。结果显示,安全增强节点的播放率回升到0.8左右,与普通节点持平,高于受害节点0.6的播放率。说明由于采用该防御策略,节点通过不断淘汰攻击节点并留下优质节点,成功防御了No-Offer攻击。

图9 部署防御策略后No-Offer攻击中节点播放率对比
4.2.2 对Delay-Chunk攻击的防御效果

图10给出了部署防御策略后,Delay-Chunk攻击过程中节点播放率对比情况。结果表明,安全增强节点的播放率在大多数情况下明显高于未采用防御策略的受害节点,与未受攻击的普通节点持平。本文的防御策略尽可能保留优质节点,同时最大程度清洗攻击节点,能够有效防御Delay-Chunk攻击。

图10 部署防御策略后Delay-Chunk攻击中节点播放率对比
4.2.3 对No-Chunk攻击的防御效果

图11给出了部署防御策略后,No-Chunk攻击过程中节点播放率对比情况。与前两种攻击的结果类似,安全增强节点的播放率与未受攻击的普通节点持平,保持在0.7左右,而受害节点的播放率在0.5左右,表明该策略对于No-Chunk攻击同样具有良好的防御效果。

图11 部署防御策略后No-Chunk攻击中节点播放率对比
5 结束语

本文构建了一个P2P直播系统的典型模型,指出其在实时性方面存在安全脆弱性,尤其是容易遭受基于Eclipse的延迟攻击。继而提出了基于Eclipse攻击的3种延迟攻击方案,即No-Offer攻击、 Delay-Chunk攻击和No-Chunk攻击,从理论上对这些攻击可能产生的危害进行了分析预测,并在真实互联网上用实验证明了这些攻击方法的有效性。

为了应对P2P网络直播系统中的Eclipse延迟攻击,本文进一步提出了基于信誉机制的路由表清洗策略,并在实验环境下进行了防御效果评估。结果表明该策略能够在一定程度上缓解延迟攻击带来的影响。

下一步工作将主要集中在完善测量指标、对真实商用系统进行延迟攻击脆弱性分析、寻找其他延迟攻击及防御方法等方面。

参考文献
[1] Deshpande H, Bawa M, Garcia-Molina H. Streaming live media over a peer-to-peer network [R]. 2001.
[2] Jannotti J, Gifford D K, Johnson K L, et al. Overcast: Reliable multicasting with on overlay network [C]//Proceedings of the 4th Conference on Symposium on Operating System Design & Implementation—Volume 4. Berkeley: USENIX Association, 2000: 14-14.
[3] Rejaie R, Ortega A. PALS: Peer-to-peer adaptive layered streaming [C]//Proceedings of the 13th International Workshop on Network and Operating Systems Support for Digital Audio and Video. New York: ACM, 2003: 153-161.
[4] Tran D A, Hua K A, Do T. Zigzag: An efficient peer-to-peer scheme for media streaming [C]//INFOCOM 2003. Twenty-Second Annual Joint Conference of the IEEE Computer and Communications. Piscataway: IEEE Societies, 2003, 2: 1283-1292.
[5] Castro M, Druschel P, Kermarrec A M, et al. SplitStream: High-bandwidth multicast in cooperative environments [J]. ACM SIGOPS Operating Systems Review, 2003, 37(5): 298-313.
[6] Horvath A, Telek M, Rossi D, et al. Dissecting pplive, sopcast, tvants [J]. submitted to ACM Conext, 2008.
[7] Vu L, Gupta I, Liang J, et al. Mapping the PPLive network: Studying the impacts of media streaming on P2P overlays [Z]. 2006.
[8] Jia J, Li C, Chen C. Characterizing PPStream across internet [C]//Network and Parallel Computing Workshops, IFIP International Conference on. Piscataway: IEEE, 2007: 413-418.
[9] Su X, Chang L. A measurement study of PPStream [C]//Communications and Networking in China, Third International Conference on. Piscataway: IEEE, 2008: 1162-1166.
[10] Douceur J R. The sybil attack [M]//Peer-to-Peer Systems. Springer Berlin Heidelberg, 2002: 251-260.
[11] Singh A. Eclipse attacks on overlay networks: Threats and defenses [C]//IEEE INFOCOM. Piscataway: IEEE, 2006.
[12] 邹维, 张缘, 张建宇, 等. DHT 网络 eclipse 攻击 [J]. 清华大学学报: 自然科学版, 2011, 51(10): 1306-1311.ZOU Wei, ZHANG Yuan, ZHANG Jianyu, et al. Survey of eclipse attacks on DHT networks [J]. J Tsinghua Univ: Sci & Technol, 2011, 51(10): 1306-1311. (in Chinese)
[13] Liang J, Kumar R, Xi Y, et al. Pollution in P2P file sharing systems [C]//INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Piscataway: IEEE, 2005, 2: 1174-1185.
[14] Adar E, Huberman B A. Free riding on Gnutella[J/OL]. First Monday, 2000, 5(10): http://firstmonday.org/ojs/index.php/fm/article/view/792/701<%3B/Hu96.
[15] Feldman M, Papadimitriou C, Chuang J, et al. Free-riding and whitewashing in peer-to-peer systems [J]. Selected Areas in Communications, IEEE Journal on, 2006, 24(5): 1010-1019.
[16] Seedorf J. Security issues for p2p-based voice-and video-streaming applications [M]//iNetSec 2009–Open Research Problems in Network Security. Springer Berlin Heidelberg, 2009: 95-110.
[17] Dhungel P, Hei X, Ross K W, et al. The pollution attack in P2P live video streaming: Measurement results and defenses [C]//Proceedings of the 2007 Workshop on Peer-to-Peer Streaming and IP-TV. New York: ACM, 2007: 323-328.
[18] Meier R, Wattenhofer R. ALPS: Authenticating live peer-to-peer live streams [C]//Reliable Distributed Systems, IEEE Symposium on. Piscataway: IEEE, 2008: 45-52.
[19] Borges A, Almeida J, Campos S. Fighting pollution in p2p live streaming systems [C]//Multimedia and Expo, IEEE International Conference on. Piscataway: IEEE, 2008: 481-484.
[20] Yang S, Jin H, Li B, et al. The content pollution in peer-to-peer live streaming systems: Analysis and implications [C]//Parallel Processing, 37th International Conference on. Piscataway: IEEE, 2008: 652-659.
[21] Yang S, Jin H, Li B, et al. A modeling framework of content pollution in Peer-to-Peer video streaming systems [J]. Computer Networks, 2009, 53(15): 2703-2715.
[22] Li Y, Lui J. Stochastic analysis of a randomized detection algorithm for pollution attack in P2P live streaming systems [J]. Performance Evaluation, 2010, 67(11): 1273-1288.
[23] Li D, Wu J, Cui Y. Defending against buffer map cheating in DONet-like P2P streaming [J]. Multimedia, IEEE Transactions on, 2009, 11(3): 535-542.
[24] Gheorghe G, Cigno R L, Montresor A. Security and privacy issues in P2P streaming systems: A survey [J]. Peer-to-Peer Networking and Applications, 2011, 4(2): 75-91.
[25] Conrotto E, Leonardi E. NAPA-WINE Project[EB/OL]. (2014). http://www.napa-wine.eu.
[26] Kamvar S D, Schlosser M T, Garcia-Molina H. The eigentrust algorithm for reputation management in p2p networks [C]//Proceedings of the 12th International Conference on World Wide Web. New York: ACM, 2003: 640-651.
[27] Xiong L, Liu L. Peertrust: Supporting reputation-based trust for peer-to-peer electronic communities [J]. Knowledge and Data Engineering, IEEE Transactions on, 2004, 16(7): 843-857.
[28] Damiani E, di Vimercati D C, Paraboschi S, et al. A reputation-based approach for choosing reliable resources in peer-to-peer networks [C]//Proceedings of the 9th ACM Conference on Computer and Communications Security. New York: ACM, 2002: 207-216.