tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7574

 
 
 

Peer-to-Peer Streaming Peer Protocol (PPSPP)

Part 4 of 4, p. 68 to 85
Prev RFC Part

 


prevText      Top      Up      ToC       Page 68 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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