12. Security Considerations
As any other network protocol, PPSPP faces a common set of security
challenges. An implementation must consider the possibility of
buffer overruns, DoS attacks and manipulation (i.e., reflection
attacks). Any guarantee of privacy seems unlikely, as the user is
exposing its IP address to the peers. A probable exception is the
case of the user being hidden behind a public NAT or proxy. This
section discusses the protocol's security considerations in detail.
12.1. Security of the Handshake Procedure
Borrowing from the analysis in [RFC5971], the PPSPP may be attacked
with three types of denial-of-service attacks:
1. DoS amplification attack: attackers try to use a PPSPP peer to
generate more traffic to a victim.
2. DoS flood attack: attackers try to deny service to other peers by
allocating lots of state at a PPSPP peer.
3. Disrupt service to an individual peer: attackers send bogus,
e.g., REQUEST and HAVE messages appearing to come from victim
Peer A to the Peers B1..Bn serving that peer. This causes Peer A
to receive chunks it did not request or to not receive the chunks
The basic scheme to protect against these attacks is the use of a
secure handshake procedure. In the UDP encapsulation, the handshake
procedure is secured by the use of randomly chosen channel IDs as
follows. The channel IDs must be generated following the
requirements in [RFC4960] (Section 5.1.3).
When UDP is used, all datagrams carrying PPSPP messages are prefixed
with a 4-byte channel ID. These channel IDs are random numbers,
established during the handshake phase as follows. Peer A initiates
an exchange with Peer B by sending a datagram containing a HANDSHAKE
message prefixed with the channel ID consisting of all zeros. Peer
A's HANDSHAKE contains a randomly chosen channel ID, chanA:
A->B: chan0 + HANDSHAKE(chanA) + ...
When Peer B receives this datagram, it creates some state for Peer A,
that at least contains the channel ID chanA. Next, Peer B sends a
response to Peer A, consisting of a datagram containing a HANDSHAKE
message prefixed with the chanA channel ID. Peer B's HANDSHAKE
contains a randomly chosen channel ID, chanB.
B->A: chanA + HANDSHAKE(chanB) + ...
Peer A now knows that Peer B really responds, as it echoed chanA. So
the next datagram that Peer A sends may already contain heavy
payload, i.e., a chunk. This next datagram to Peer B will be
prefixed with the chanB channel ID. When Peer B receives this
datagram, both peers have the proof they are really talking to each
other, the three-way handshake is complete. In other words, the
randomly chosen channel IDs act as tags (cf. [RFC4960]
A->B: chanB + HAVE + DATA + ...
12.1.1. Protection against Attack 1
In short, PPSPP does a so-called return routability check before
heavy payload is sent. This means that attack 1 is fended off: PPSPP
does not send back much more data than it received, unless it knows
it is talking to a live peer. Attackers sending a spoofed HANDSHAKE
to Peer B pretending to be Peer A now need to intercept the message
from Peer B to Peer A to get Peer B to send heavy payload, and ensure
that that heavy payload goes to the victim, something assumed too
hard to be a practical attack.
Note the rule is that no heavy payload may be sent until the third
datagram. This has implications for PPSPP implementations that use
chunk addressing schemes that are verbose. If a PPSPP implementation
uses large bitmaps to convey chunk availability, these may not be
sent by Peer B in the second datagram.
12.1.2. Protection against Attack 2
On receiving the first datagram Peer B will record some state about
Peer A. At present, this state consists of the chanA channel ID, and
the results of processing the other messages in the first datagram.
In particular, if Peer A included some HAVE messages, Peer B may add
a chunk availability map to Peer A's state. In addition, Peer B may
request some chunks from Peer A in the second datagram, and Peer B
will maintain state about these outgoing requests.
So presently, PPSPP is somewhat vulnerable to attack 2. An attacker
could send many datagrams with HANDSHAKEs and HAVEs and thus allocate
state at the PPSPP peer. Therefore, Peer A MUST respond immediately
to the second datagram, if it is still interested in Peer B.
The reason for using this slightly vulnerable three-way handshake
instead of the safer handshake procedure of Stream Control
Transmission Protocol (SCTP) [RFC4960] (Section 5.1) is quicker
response time for the user. In the SCTP procedure, Peers A and B
cannot request chunks until datagrams 3 and 4 respectively, as
opposed to 2 and 1 in the proposed procedure. This means that the
user has to wait less time in PPSPP between starting the video stream
and seeing the first images.
12.1.3. Protection against Attack 3
In general, channel IDs serve to authenticate a peer. Hence, to
attack, a malicious Peer T would need to be able to eavesdrop on
conversations between victim A and a benign Peer B to obtain the
channel ID Peer B assigned to Peer A, chanB. Furthermore, attacker
Peer T would need to be able to spoof, e.g., REQUEST and HAVE
messages from Peer A to cause Peer B to send heavy DATA messages to
Peer A, or prevent Peer B from sending them, respectively.
The capability to eavesdrop is not common, so the protection afforded
by channel IDs will be sufficient in most cases. If not, point-to-
point encryption of traffic should be used, see below.
12.2. Secure Peer Address Exchange
As described in Section 3.10, Peer A can send Peer-Exchange messages
PEX_RES to Peer B, which contain the IP address and port of other
peers that are supposedly also in the current swarm. The strength of
this mechanism is that it allows decentralized tracking: after an
initial bootstrap, no central tracker is needed. The vulnerability
of this mechanism (and DHTs) is that malicious peers can use it for
an Amplification attack.
In particular, a malicious Peer T could send PEX_RES messages to
well-behaved Peer A with addresses of Peers B1..Bn; on receipt, Peer
A could send a HANDSHAKE to all these peers. So, in the worst case,
a single datagram results in N datagrams. The actual damage depends
on Peer A's behavior. For example, when Peer A already has
sufficient connections, it may not connect to the offered ones at
all; but if it is a fresh peer, it may connect to all directly.
In addition, PEX can be used in Eclipse attacks [ECLIPSE] where
malicious peers try to isolate a particular peer such that it only
interacts with malicious peers. Let us distinguish two specific
E1. Malicious peers try to eclipse the single injector in live
E2. Malicious peers try to eclipse a specific consumer peer.
Attack E1 has the most impact on the system as it would disrupt all
12.2.1. Protection against the Amplification Attack
If peer addresses are relatively stable, strong protection against
the attack can be provided by using public key cryptography and
certification. In particular, a PEX_REScert message will carry
swarm-membership certificates rather than IP address and port. A
membership certificate for Peer B states that Peer B at address
(ipB,portB) is part of Swarm S at Time T and is cryptographically
signed. The receiver Peer A can check the certificate for a valid
signature, the right swarm and liveliness, and only then consider
contacting Peer B. These swarm-membership certificates correspond to
signed node descriptors in secure decentralized peer sampling
Several designs are possible for the security environment for these
membership certificates. That is, there are different designs
possible for who signs the membership certificates and how public
keys are distributed. As an example, we describe a design where the
peer-to-peer streaming protocol tracker acts as certification
12.2.2. Example: Tracker as Certification Authority
Peer A wanting to join Swarm S sends a certificate request message to
a Tracker X for that swarm. Upon receipt, the tracker creates a
membership certificate from the request with Swarm ID S, a Timestamp
T, and the external IP and port it received the message from, signed
with the tracker's private key. This certificate is returned to Peer
Peer A then includes this certificate when it sends a PEX_REScert to
Peer B. Receiver Peer B verifies it against the tracker public key.
This tracker public key should be part of the swarm's metadata, which
Peer B received from a trusted source. Subsequently, Peer B can send
the member certificate of Peer A to other peers in PEX_REScert
Peer A can send the certification request when it first contacts the
tracker or at a later time. Furthermore, the responses the tracker
sends could contain membership certificates instead of plain
addresses, such that they can be gossiped securely as well.
We assume the tracker is protected against attacks and does a return
routability check. The latter ensures that malicious peers cannot
obtain a certificate for a random host, just for hosts where they can
eavesdrop on incoming traffic.
The load generated on the tracker depends on churn and the lifetime
of a certificate. Certificates can be fairly long lived, given that
the main goal of the membership certificates is to prevent that
malicious Peer T can cause good Peer A to contact *random* hosts.
The freshness of the timestamp just adds extra protection in addition
to achieving that goal. It protects against malicious hosts causing
a good Peer A to contact hosts that previously participated in the
The membership certificate mechanism itself can be used for a kind of
amplification attack against good peers. Malicious Peer T can cause
Peer A to spend some CPU to verify the signatures on the membership
certificates that Peer T sends. To counter this, Peer A SHOULD check
a few of the certificates sent and discard the rest if they are
The same membership certificates described above can be registered in
a Distributed Hash Table that has been secured against the well-known
DHT specific attacks [SECDHTS].
Note that this scheme does not work for peers behind a symmetric
Network Address Translator, but neither does normal tracker
12.2.3. Protection against Eclipse Attacks
Before we can discuss Eclipse attacks, we first need to establish the
security properties of the central tracker. A tracker is vulnerable
to Amplification attacks, too. A malicious Peer T could register a
victim Peer B with the tracker, and many peers joining the swarm will
contact Peer B. Trackers can also be used in Eclipse attacks. If
many malicious peers register themselves at the tracker, the
percentage of bad peers in the returned address list may become high.
Leaving the protection of the tracker to the peer-to-peer streaming
protocol tracker specification [PPSP-TP], we assume for the following
discussion that it returns a true random sample of the actual swarm
membership (achieved via Sybil attack protection). This means that
if 50% of the peers are bad, you'll still get 50% good addresses from
Attack E1 on PEX can be fended off by letting live injectors disable
PEX -- or at least, letting live injectors ensure that part of their
connections are to peers whose addresses came from the trusted
The same measures defend against attack E2 on PEX. They can also be
employed dynamically. When the current set of Peers B that Peer A is
connected to doesn't provide good quality of service, Peer A can
contact the tracker to find new candidates.
12.3. Support for Closed Swarms
Regarding PPSP.SEC.REQ-1 in [RFC6972], the Closed Swarms [CLOSED] and
Enhanced Closed Swarms [ECS] mechanisms provide swarm-level access
control. The basic idea is that a peer cannot download from another
peer unless it shows a Proof-of-Access. Enhanced Closed Swarms
improve on the original Closed Swarms by adding on-the-wire
encryption against man-in-the-middle attacks and more flexible access
The exact mapping of ECS to PPSPP is defined in [ECS-protocol].
12.4. Confidentiality of Streamed Content
Regarding PPSP.SEC.REQ-1 in [RFC6972], no extra mechanism is needed
to support confidentiality in PPSPP. A content publisher wishing
confidentiality should just distribute content in ciphertext and/or
in a format to which Digital Rights Management (DRM) techniques have
been applied. In that case, it is assumed a higher layer handles key
management out-of-band. Alternatively, pure point-to-point
encryption of content and traffic can be provided by the proposed
Closed Swarms access control mechanism, by DTLS [RFC6347], or by
When transmitting over DTLS, PPSPP can obtain the PMTU estimate
maintained by the IP layer to determine how much payload can be put
in a single datagram without fragmentation ([RFC6347],
Section 18.104.22.168). If PMTU changes and the chunk size becomes too
large to fit into a single datagram, PPSPP can choose to allow
fragmentation by clearing the Don't Fragment (DF) bit.
Alternatively, the content publisher can decide to use smaller chunks
and transmit multiple in the same datagram when the MTU allows.
12.5. Strength of the Hash Function for Merkle Hash Trees
Implementations MUST support SHA-1 as the hash function for content
integrity protection via Merkle hash trees. SHA-1 may be preferred
over stronger hash functions by content providers because it reduces
on-the-wire overhead. As such, it presents a trade-off between
performance and security. The security considerations for SHA-1 are
discussed in [RFC6194].
In general, note that the hash function is used in a hash tree, which
makes it more complex to create collisions. In particular, if
attackers manage to find a collision for a hash, it can replace just
one chunk, so the impact is limited. If fixed-size chunks are used,
the collision even has to be of the same size as the original chunk.
For hashes higher up in the hash tree, a collision must be a
concatenation of two hashes. In sum, finding collisions that fit
with the hash tree are generally harder to find than regular
12.6. Limit Potential Damage and Resource Exhaustion by Bad or Broken
Regarding PPSP.SEC.REQ-2 in [RFC6972], this section provides an
analysis of the potential damage a malicious peer can do with each
message in the protocol, and how it is prevented by the protocol
o Secured against DoS Amplification attacks as described in
o Threat HS.1: An Eclipse attack where Peers T1..Tn fill all
connection slots of Peer A by initiating the connection to Peer A.
Solution: Peer A must not let other peers fill all its available
connection slots, i.e., Peer A must initiate connections itself
too, to prevent isolation.
o Threat HAVE.1: Malicious Peer T can claim to have content that it
does not. Subsequently, Peer T won't respond to requests.
Solution: Peer A will consider Peer T to be a slow peer and not
ask it again.
o Threat HAVE.2: Malicious Peer T can claim not to have content.
Hence, it won't contribute.
Solution: Peer and chunk selection algorithms external to the
protocol will implement fairness and provide sharing incentives.
o Threat DATA.1: Peer T sending bogus chunks.
Solution: The content integrity protection schemes defend against
o Threat DATA.2: Peer T sends Peer A unrequested chunks.
To protect against this threat we need network-level DoS
o Threat ACK.1: Peer T acknowledges wrong chunks.
Solution: Peer A will detect inconsistencies with the data it sent
to Peer T.
o Threat ACK.2: Peer T modifies timestamp in ACK to Peer A used for
time-based congestion control.
Solution: In theory, by decreasing the timestamp, Peer T could
fake that there is no congestion when in fact there is, causing
Peer A to send more data than it should. [RFC6817] does not list
this as a security consideration. Possibly, this attack can be
detected by the large resulting asymmetry between round-trip time
and measured one-way delay.
12.6.5. INTEGRITY and SIGNED_INTEGRITY
o Threat INTEGRITY.1: An amplification attack where Peer T sends
bogus INTEGRITY or SIGNED_INTEGRITY messages, causing Peer A to
checks hashes or signatures, thus spending CPU unnecessarily.
Solution: If the hashes/signatures don't check out, Peer A will
stop asking Peer T because of the atomic datagram principle and
the content integrity protection. Subsequent unsolicited traffic
from Peer T will be ignored.
o Threat INTEGRITY.2: An attack where Peer T sends old
SIGNED_INTEGRITY messages in the Unified Merkle Tree scheme,
trying to make Peer A tune in at a past point in the live stream.
Solution: The timestamp in the SIGNED_INTEGRITY message protects
against such replays. Subsequent traffic from Peer T will be
o Threat REQUEST.1: Peer T could request lots from Peer A, leaving
Peer A without resources for others.
Solution: A limit is imposed on the upload capacity a single peer
can consume, for example, by using an upload bandwidth scheduler
that takes into account the need of multiple peers. A natural
upper limit of this upload quotum is the bitrate of the content,
taking into account that this may be variable.
o Threat CANCEL.1: Peer T sends CANCEL messages for content it never
requested to Peer A.
Solution: Peer A will detect the inconsistency of the messages and
ignore them. Note that CANCEL messages may be received
unexpectedly when a transport is used where REQUEST messages may
be lost or reordered with respect to the subsequent CANCELs.
o Threat CHOKE.1: Peer T sends REQUEST messages after Peer A sent
Peer B a CHOKE message.
Solution: Peer A will just discard the unwanted REQUESTs and
resend the CHOKE, assuming it got lost.
o Threat UNCHOKE.1: Peer T sends an UNCHOKE message to Peer A
without having sent a CHOKE message before.
Solution: Peer A can easily detect this violation of protocol
state, and ignore it. Note this can also happen due to loss of a
CHOKE message sent by a benign peer.
o Threat UNCHOKE.2: Peer T sends an UNCHOKE message to Peer A, but
subsequently does not respond to its REQUESTs.
Solution: Peer A will consider Peer T to be a slow peer and not
ask it again.
o Secured against amplification and Eclipse attacks as described in
12.6.11. Unsolicited Messages in General
o Threat: Peer T could send a spoofed PEX_REQ or REQUEST from Peer B
to Peer A, causing Peer A to send a PEX_RES/DATA to Peer B.
Solution: the message from Peer T won't be accepted unless Peer T
does a handshake first, in which case the reply goes to Peer T,
not victim Peer B.
12.7. Exclude Bad or Broken Peers
This section is regarding PPSP.SEC.REQ-2 in [RFC6972]. A receiving
peer can detect malicious or faulty senders as just described, which
it can then subsequently ignore. However, excluding such a bad peer
from the system completely is complex. Random monitoring by trusted
peers that would blacklist bad peers as described in [DETMAL] is one
option. This mechanism does require extra capacity to run such
trusted peers, which must be indistinguishable from regular peers,
and requires a solution for the timely distribution of this blacklist
to peers in a scalable manner.
Cohen, B., "The BitTorrent Protocol Specification",
BitTorrent Enhancement Proposal 3, February 2008,
[CLOSED] Borch, N., Mitchell, K., Arntzen, I., and D. Gabrijelcic,
"Access Control to BitTorrent Swarms Using Closed Swarms",
ACM workshop on Advanced Video Streaming Techniques for
Peer-to-Peer Networks and Social Networking (AVSTP2P '10),
Florence, Italy, October 2010,
[DETMAL] Shetty, S., Galdames, P., Tavanapong, W., and Ying. Cai,
"Detecting Malicious Peers in Overlay Multicast
Streaming", IEEE Conference on Local Computer Networks,
(LCN'06), Tampa, FL, USA, November 2006.
[ECLIPSE] Sit, E. and R. Morris, "Security Considerations for Peer-
to-Peer Distributed Hash Tables", IPTPS '01: Revised
Papers from the First International Workshop on Peer-to-
Peer Systems, pp. 261-269, Springer-Verlag, 2002.
[ECS] Jovanovikj, V., Gabrijelcic, D., and T. Klobucar, "Access
Control in BitTorrent P2P Networks Using the Enhanced
Closed Swarms Protocol", International Conference on
Emerging Security Information, Systems and Technologies
(SECURWARE 2011), pp. 97-102, Nice, France, August 2011.
Gabrijelcic, D., "Enhanced Closed Swarm protocol", Work in
Progress, draft-ppsp-gabrijelcic-ecs-01, June 2013.
Bonald, T., Massoulie, L., Mathieu, F., Perino, D., and A.
Twigg, "Epidemic live streaming: optimal performance
trade-offs", Proceedings of the 2008 ACM SIGMETRICS
International Conference on Measurement and Modeling of
Computer Systems, Annapolis, MD, USA, June 2008.
[GIVE2GET] Mol, J., Pouwelse, J., Meulpolder, M., Epema, D., and H.
Sips, "Give-to-Get: Free-riding-resilient Video-on-Demand
in P2P Systems", Proceedings Multimedia Computing and
Networking conference (Proceedings of SPIE, Vol. 6818),
San Jose, CA, USA, January 2008.
[HAC01] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", CRC Press, (Fifth Printing,
August 2001), October 1996.
[JIM11] Jimenez, R., Osmani, F., and B. Knutsson, "Sub-Second
Lookups on a Large-Scale Kademlia-Based Overlay", IEEE
International Conference on Peer-to-Peer Computing
(P2P'11), Kyoto, Japan, August 2011.
[LBT] Rossi, D., Testa, C., Valenti, S., and L. Muscariello,
"LEDBAT: the new BitTorrent congestion control protocol",
Computer Communications and Networks (ICCCN), Zurich,
Switzerland, August 2010.
[LCOMPL] Testa, C. and D. Rossi, "On the impact of uTP on
BitTorrent completion time", IEEE International Conference
on Peer-to-Peer Computing (P2P'11), Kyoto, Japan, August
[MERKLE] Merkle, R., "Secrecy, Authentication, and Public Key
Systems", Ph.D. thesis, Dept. of Electrical Engineering,
Stanford University, CA, USA, pp 40-45, 1979.
[P2PWIKI] Bakker, A., Petrocco, R., Dale, M., Gerber, J.,
Grishchenko, V., Rabaioli, D., and J. Pouwelse, "Online
video using BitTorrent and HTML5 applied to Wikipedia",
IEEE International Conference on Peer-to-Peer Computing
(P2P'10), Delft, The Netherlands, August 2010.
[POLLIVE] Dhungel, P., Hei, Xiaojun., Ross, K., and N. Saxena,
"Pollution in P2P Live Video Streaming", International
Journal of Computer Networks & Communications (IJCNC) Vol.
1, No. 2, Jul 2009.
[PPSP-TP] Cruz, R., Nunes, M., Yingjie, G., Xia, J., Huang, R.,
Taveira, J., and D. Lingli, "PPSP Tracker Protocol-Base
Protocol (PPSP-TP/1.0)", Work in Progress,
draft-ietf-ppsp-base-tracker-protocol-09, March 2015.
[PPSPPERF] Petrocco, R., Pouwelse, J., and D. Epema, "Performance
Analysis of the Libswift P2P Streaming Protocol", IEEE
International Conference on Peer-to-Peer Computing
(P2P'12), Tarragona, Spain, September 2012.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
[SECDHTS] Urdaneta, G., Pierre, G., and M. van Steen, "A Survey of
DHT Security Techniques", ACM Computing Surveys,
vol. 43(2), January 2011.
Wong, C. and S. Lam, "Digital Signatures for Flows and
Multicasts", IEEE/ACM Transactions on Networking 7(4),
pp. 502-513, August 1999.
[SPS] Jesi, G., Montresor, A., and M. van Steen, "Secure Peer
Sampling", Computer Networks vol. 54(12), pp. 2086-2098,
Elsevier, August 2010.
Grishchenko, V., Paananen, J., Pronchenkov, A., Bakker,
A., and R. Petrocco, "Swift reference implementation",
[TIT4TAT] Cohen, B., "Incentives Build Robustness in BitTorrent",
1st Workshop on Economics of Peer-to-Peer Systems,
Berkeley, CA, USA, May 2003.
Arno Bakker, Riccardo Petrocco, and Victor Grishchenko are partially
supported by the P2P-Next project <http://www.p2p-next.org/>, a
research project supported by the European Community under its 7th
Framework Programme (grant agreement no. 216217). The views and
conclusions contained herein are those of the authors and should not
be interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the P2P-Next project or
the European Commission.
PPSPP was designed by Victor Grishchenko at Technische Universiteit
Delft under supervision of Johan Pouwelse. The authors would like to
thank the following people for their contributions to this document:
the chairs (Martin Stiemerling, Yunfei Zhang, Stefano Previdi, and
Ning Zong) and members of the IETF PPSP working group, and Mihai
Capota, Raul Jimenez, Flutra Osmani, and Raynor Vliegendhart.