Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7574

Peer-to-Peer Streaming Peer Protocol (PPSPP)

Pages: 85
Proposed Standard
Errata
Part 4 of 4 – Pages 68 to 85
First   Prev   None

Top   ToC   RFC7574 - Page 68   prevText

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.
Top   ToC   RFC7574 - Page 69
   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
Top   ToC   RFC7574 - Page 70
   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.
Top   ToC   RFC7574 - Page 71

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].
Top   ToC   RFC7574 - Page 72
   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.
Top   ToC   RFC7574 - Page 73
   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].
Top   ToC   RFC7574 - Page 74

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).
Top   ToC   RFC7574 - Page 75

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.
Top   ToC   RFC7574 - Page 76
      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.
Top   ToC   RFC7574 - Page 77

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.
Top   ToC   RFC7574 - Page 78

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>.
Top   ToC   RFC7574 - Page 79
   [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.
Top   ToC   RFC7574 - Page 80
   [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.
Top   ToC   RFC7574 - Page 81
   [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.
Top   ToC   RFC7574 - Page 82
   [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>.
Top   ToC   RFC7574 - Page 83
   [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>.
Top   ToC   RFC7574 - Page 84
   [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.
Top   ToC   RFC7574 - Page 85

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