RFC 7574
Peer-to-Peer Streaming Peer Protocol (PPSPP)
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
it requested.
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]
(Section 5.1)).
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 attacks: E1. Malicious peers try to eclipse the single injector in live streaming. E2. Malicious peers try to eclipse a specific consumer peer. Attack E1 has the most impact on the system as it would disrupt all peers.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 services [SPS].
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 authority.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 A. 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 messages. 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 swarm. 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 defective.
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 registration.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 the tracker. 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 tracker. 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 control rules. 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 IPsec [RFC4301]. 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 4.1.1.1). 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 collisions.12.6. Limit Potential Damage and Resource Exhaustion by Bad or Broken Peers
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 (implementation).
12.6.1. HANDSHAKE
o Secured against DoS Amplification attacks as described in Section 12.1. 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.12.6.2. HAVE
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.12.6.3. DATA
o Threat DATA.1: Peer T sending bogus chunks. Solution: The content integrity protection schemes defend against this. o Threat DATA.2: Peer T sends Peer A unrequested chunks. To protect against this threat we need network-level DoS prevention.12.6.4. ACK
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
ignored.
12.6.6. REQUEST
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.
12.6.7. CANCEL
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.
12.6.8. CHOKE
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.12.6.9. UNCHOKE
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.12.6.10. PEX_RES
o Secured against amplification and Eclipse attacks as described in Section 12.2.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.
13. References
13.1. Normative References
[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002. [FIPS180-4] National Institute of Standards and Technology, Information Technology Laboratory, "Federal Information Processing Standards: Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012. [IANADNSSECALGNUM] IANA, "Domain Name System Security (DNSSEC) Algorithm Numbers", March 2014, <http://www.iana.org/assignments/dns-sec-alg-numbers>. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, DOI 10.17487/RFC3110, May 2001, <http://www.rfc-editor.org/info/rfc3110>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>. [RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, DOI 10.17487/RFC5702, October 2009, <http://www.rfc-editor.org/info/rfc5702>. [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>. [RFC6605] Hoffman, P. and W. Wijngaards, "Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC", RFC 6605, DOI 10.17487/RFC6605, April 2012, <http://www.rfc-editor.org/info/rfc6605>. [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, DOI 10.17487/RFC6817, December 2012, <http://www.rfc-editor.org/info/rfc6817>.13.2. Informative References
[ABMRKL] Bakker, A., "Merkle hash torrent extension", BitTorrent Enhancement Proposal 30, March 2009, <http://bittorrent.org/beps/bep_0030.html>. [BINMAP] Grishchenko, V. and J. Pouwelse, "Binmaps: Hybridizing Bitmaps and Binary Trees", Delft University of Technology Parallel and Distributed Systems Report Series, Report number PDS-2011-005, ISSN 1387-2109, April 2009. [BITOS] Vlavianos, A., Iliofotou, M., Mathieu, F., and M. Faloutsos, "BiToS: Enhancing BitTorrent for Supporting Streaming Applications", IEEE INFOCOM Global Internet Symposium, Barcelona, Spain, April 2006.
[BITTORRENT] Cohen, B., "The BitTorrent Protocol Specification", BitTorrent Enhancement Proposal 3, February 2008, <http://bittorrent.org/beps/bep_0003.html>. [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, <http://doi.acm.org/10.1145/1877891.1877898>. [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. [ECS-protocol] Gabrijelcic, D., "Enhanced Closed Swarm protocol", Work in Progress, draft-ppsp-gabrijelcic-ecs-01, June 2013. [EPLIVEPERF] 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 2011. [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.
[RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. Saperia, "Application Management MIB", RFC 2564, DOI 10.17487/RFC2564, May 1999, <http://www.rfc-editor.org/info/rfc2564>. [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, DOI 10.17487/RFC2790, March 2000, <http://www.rfc-editor.org/info/rfc2790>. [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, DOI 10.17487/RFC2975, October 2000, <http://www.rfc-editor.org/info/rfc2975>. [RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, DOI 10.17487/RFC3365, August 2002, <http://www.rfc-editor.org/info/rfc3365>. [RFC3729] Waldbusser, S., "Application Performance Measurement MIB", RFC 3729, DOI 10.17487/RFC3729, March 2004, <http://www.rfc-editor.org/info/rfc3729>. [RFC4113] Fenner, B. and J. Flick, "Management Information Base for the User Datagram Protocol (UDP)", RFC 4113, DOI 10.17487/RFC4113, June 2005, <http://www.rfc-editor.org/info/rfc4113>. [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics MIB", RFC 4150, DOI 10.17487/RFC4150, August 2005, <http://www.rfc-editor.org/info/rfc4150>. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>. [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <http://www.rfc-editor.org/info/rfc4960>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>. [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet Signalling Transport", RFC 5971, DOI 10.17487/RFC5971, October 2010, <http://www.rfc-editor.org/info/rfc5971>. [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, <http://www.rfc-editor.org/info/rfc6194>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>. [RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>. [RFC6972] Zhang, Y. and N. Zong, "Problem Statement and Requirements of the Peer-to-Peer Streaming Protocol (PPSP)", RFC 6972, DOI 10.17487/RFC6972, July 2013, <http://www.rfc-editor.org/info/rfc6972>.
[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, <http://www.rfc-editor.org/info/rfc7285>. [SECDHTS] Urdaneta, G., Pierre, G., and M. van Steen, "A Survey of DHT Security Techniques", ACM Computing Surveys, vol. 43(2), January 2011. [SIGMCAST] 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. [SWIFTIMPL] Grishchenko, V., Paananen, J., Pronchenkov, A., Bakker, A., and R. Petrocco, "Swift reference implementation", 2015, <https://github.com/libswift/libswift>. [TIT4TAT] Cohen, B., "Incentives Build Robustness in BitTorrent", 1st Workshop on Economics of Peer-to-Peer Systems, Berkeley, CA, USA, May 2003.Acknowledgements
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.
Authors' Addresses
Arno Bakker Vrije Universiteit Amsterdam De Boelelaan 1081 Amsterdam 1081HV The Netherlands Email: arno@cs.vu.nl Riccardo Petrocco Technische Universiteit Delft Mekelweg 4 Delft 2628CD The Netherlands Email: r.petrocco@gmail.com Victor Grishchenko Technische Universiteit Delft Mekelweg 4 Delft 2628CD The Netherlands Email: victor.grishchenko@gmail.com