diff options
Diffstat (limited to 'doc/rfc/rfc7574.txt')
| -rw-r--r-- | doc/rfc/rfc7574.txt | 4763 |
1 files changed, 4763 insertions, 0 deletions
diff --git a/doc/rfc/rfc7574.txt b/doc/rfc/rfc7574.txt new file mode 100644 index 0000000..33d66a1 --- /dev/null +++ b/doc/rfc/rfc7574.txt @@ -0,0 +1,4763 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Bakker +Request for Comments: 7574 Vrije Universiteit Amsterdam +Category: Standards Track R. Petrocco +ISSN: 2070-1721 V. Grishchenko + Technische Universiteit Delft + July 2015 + + + Peer-to-Peer Streaming Peer Protocol (PPSPP) + +Abstract + + The Peer-to-Peer Streaming Peer Protocol (PPSPP) is a protocol for + disseminating the same content to a group of interested parties in a + streaming fashion. PPSPP supports streaming of both prerecorded (on- + demand) and live audio/video content. It is based on the peer-to- + peer paradigm, where clients consuming the content are put on equal + footing with the servers initially providing the content, to create a + system where everyone can potentially provide upload bandwidth. It + has been designed to provide short time-till-playback for the end + user and to prevent disruption of the streams by malicious peers. + PPSPP has also been designed to be flexible and extensible. It can + use different mechanisms to optimize peer uploading, prevent + freeriding, and work with different peer discovery schemes + (centralized trackers or Distributed Hash Tables). It supports + multiple methods for content integrity protection and chunk + addressing. Designed as a generic protocol that can run on top of + various transport protocols, it currently runs on top of UDP using + Low Extra Delay Background Transport (LEDBAT) for congestion control. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7574. + + + + + + + + +Bakker, et al. Standards Track [Page 1] + +RFC 7574 PPSPP July 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................5 + 1.1. Purpose ....................................................5 + 1.2. Requirements Language ......................................6 + 1.3. Terminology ................................................6 + 2. Overall Operation ...............................................9 + 2.1. Example: Joining a Swarm ...................................9 + 2.2. Example: Exchanging Chunks ................................10 + 2.3. Example: Leaving a Swarm ..................................10 + 3. Messages .......................................................11 + 3.1. HANDSHAKE .................................................11 + 3.1.1. Handshake Procedure ................................12 + 3.2. HAVE ......................................................14 + 3.3. DATA ......................................................15 + 3.4. ACK .......................................................15 + 3.5. INTEGRITY .................................................15 + 3.6. SIGNED_INTEGRITY ..........................................16 + 3.7. REQUEST ...................................................16 + 3.8. CANCEL ....................................................16 + 3.9. CHOKE and UNCHOKE .........................................17 + 3.10. Peer Address Exchange ....................................17 + 3.10.1. PEX_REQ and PEX_RES Messages ......................17 + 3.11. Channels .................................................19 + 3.12. Keep Alive Signaling .....................................20 + 4. Chunk Addressing Schemes .......................................21 + 4.1. Start-End Ranges ..........................................21 + 4.1.1. Chunk Ranges .......................................21 + 4.1.2. Byte Ranges ........................................21 + 4.2. Bin Numbers ...............................................22 + 4.3. In Messages ...............................................23 + 4.3.1. In HAVE Messages ...................................23 + 4.3.2. In ACK Messages ....................................24 + + + +Bakker, et al. Standards Track [Page 2] + +RFC 7574 PPSPP July 2015 + + + 5. Content Integrity Protection ...................................24 + 5.1. Merkle Hash Tree Scheme ...................................25 + 5.2. Content Integrity Verification ............................26 + 5.3. The Atomic Datagram Principle .............................27 + 5.4. INTEGRITY Messages ........................................28 + 5.5. Discussion and Overhead ...................................28 + 5.6. Automatic Detection of Content Size .......................29 + 5.6.1. Peak Hashes ........................................29 + 5.6.2. Procedure ..........................................31 + 6. Live Streaming .................................................32 + 6.1. Content Authentication ....................................32 + 6.1.1. Sign All ...........................................33 + 6.1.2. Unified Merkle Tree ................................33 + 6.1.2.1. Signed Munro Hashes .......................34 + 6.1.2.2. Munro Signature Calculation ...............36 + 6.1.2.3. Procedure .................................37 + 6.1.2.4. Secure Tune In ............................37 + 6.2. Forgetting Chunks .........................................38 + 7. Protocol Options ...............................................38 + 7.1. End Option ................................................39 + 7.2. Version ...................................................39 + 7.3. Minimum Version ...........................................40 + 7.4. Swarm Identifier ..........................................40 + 7.5. Content Integrity Protection Method .......................41 + 7.6. Merkle Tree Hash Function .................................41 + 7.7. Live Signature Algorithm ..................................42 + 7.8. Chunk Addressing Method ...................................42 + 7.9. Live Discard Window .......................................43 + 7.10. Supported Messages .......................................44 + 7.11. Chunk Size ...............................................44 + 8. UDP Encapsulation ..............................................45 + 8.1. Chunk Size ................................................45 + 8.2. Datagrams and Messages ....................................46 + 8.3. Channels ..................................................47 + 8.4. HANDSHAKE .................................................47 + 8.5. HAVE ......................................................48 + 8.6. DATA ......................................................48 + 8.7. ACK .......................................................49 + 8.8. INTEGRITY .................................................50 + 8.9. SIGNED_INTEGRITY ..........................................51 + 8.10. REQUEST ..................................................52 + 8.11. CANCEL ...................................................52 + 8.12. CHOKE and UNCHOKE ........................................53 + 8.13. PEX_REQ, PEX_RESv4, PEX_RESv6, and PEX_REScert ...........53 + 8.14. KEEPALIVE ................................................55 + 8.15. Flow and Congestion Control ..............................56 + 8.16. Example of Operation .....................................57 + 9. Extensibility ..................................................61 + + + +Bakker, et al. Standards Track [Page 3] + +RFC 7574 PPSPP July 2015 + + + 9.1. Chunk Picking Algorithms ..................................61 + 9.2. Reciprocity Algorithms ....................................62 + 10. IANA Considerations ...........................................62 + 10.1. PPSPP Message Type Registry ..............................62 + 10.2. PPSPP Option Registry ....................................62 + 10.3. PPSPP Version Number Registry ............................62 + 10.4. PPSPP Content Integrity Protection Method Registry .......62 + 10.5. PPSPP Merkle Hash Tree Function Registry .................63 + 10.6. PPSPP Chunk Addressing Method Registry ...................63 + 11. Manageability Considerations ..................................63 + 11.1. Operations ...............................................63 + 11.1.1. Installation and Initial Setup ....................63 + 11.1.2. Migration Path ....................................64 + 11.1.3. Requirements on Other Protocols and + Functional Components .............................64 + 11.1.4. Impact on Network Operation .......................64 + 11.1.5. Verifying Correct Operation .......................65 + 11.1.6. Configuration .....................................65 + 11.2. Management Considerations ................................66 + 11.2.1. Management Interoperability and Information .......67 + 11.2.2. Fault Management ..................................67 + 11.2.3. Configuration Management ..........................67 + 11.2.4. Accounting Management .............................68 + 11.2.5. Performance Management ............................68 + 11.2.6. Security Management ...............................68 + 12. Security Considerations .......................................68 + 12.1. Security of the Handshake Procedure ......................68 + 12.1.1. Protection against Attack 1 .......................69 + 12.1.2. Protection against Attack 2 .......................70 + 12.1.3. Protection against Attack 3 .......................70 + 12.2. Secure Peer Address Exchange .............................71 + 12.2.1. Protection against the Amplification Attack .......71 + 12.2.2. Example: Tracker as Certification Authority .......72 + 12.2.3. Protection against Eclipse Attacks ................73 + 12.3. Support for Closed Swarms ................................73 + 12.4. Confidentiality of Streamed Content ......................74 + 12.5. Strength of the Hash Function for Merkle Hash Trees ......74 + 12.6. Limit Potential Damage and Resource Exhaustion by + Bad or Broken Peers ......................................74 + 12.6.1. HANDSHAKE .........................................75 + 12.6.2. HAVE ..............................................75 + 12.6.3. DATA ..............................................75 + 12.6.4. ACK ...............................................75 + 12.6.5. INTEGRITY and SIGNED_INTEGRITY ....................76 + 12.6.6. REQUEST ...........................................76 + 12.6.7. CANCEL ............................................76 + 12.6.8. CHOKE .............................................77 + 12.6.9. UNCHOKE ...........................................77 + + + +Bakker, et al. Standards Track [Page 4] + +RFC 7574 PPSPP July 2015 + + + 12.6.10. PEX_RES ..........................................77 + 12.6.11. Unsolicited Messages in General ..................77 + 12.7. Exclude Bad or Broken Peers ..............................77 + 13. References ....................................................78 + 13.1. Normative References .....................................78 + 13.2. Informative References ...................................79 + Acknowledgements ..................................................84 + Authors' Addresses ................................................85 + +1. Introduction + +1.1. Purpose + + This document describes the Peer-to-Peer Streaming Peer Protocol + (PPSPP), designed for disseminating the same content to a group of + interested parties in a streaming fashion. PPSPP supports streaming + of both prerecorded (on-demand) and live audio/video content. It is + based on the peer-to-peer paradigm where clients consuming the + content are put on equal footing with the servers initially providing + the content, to create a system where everyone can potentially + provide upload bandwidth. + + PPSPP has been designed to provide short time-till-playback for the + end user and to prevent disruption of the streams by malicious peers. + Central in this design is a simple method of identifying content + based on self-certification. In particular, content in PPSPP is + identified by a single cryptographic hash that is the root hash in a + Merkle hash tree calculated recursively from the content [MERKLE] + [ABMRKL]. This self-certifying hash tree allows every peer to + directly detect when a malicious peer tries to distribute fake + content. The tree can be used for both static and live content. + Moreover, it ensures only a small amount of information is needed to + start a download and to verify incoming chunks of content, thus + ensuring short start-up times. + + PPSPP has also been designed to be extensible for different + transports and use cases. Hence, PPSPP is a generic protocol that + can run directly on top of UDP, TCP, or other protocols. As such, + PPSPP defines a common set of messages that make up the protocol, + which can have different representations on the wire depending on the + lower-level protocol used. When the lower-level transport allows, + PPSPP can also use different congestion control algorithms. + + At present, PPSPP is set to run on top of UDP using LEDBAT for + congestion control [RFC6817]. Using LEDBAT enables PPSPP to serve + the content after playback (seeding) without disrupting the user who + may have moved to different tasks that use its network connection. + + + + +Bakker, et al. Standards Track [Page 5] + +RFC 7574 PPSPP July 2015 + + + PPSPP is also flexible and extensible in the mechanisms it uses to + promote client contribution and prevent freeriding, that is, how to + deal with peers that only download content but never upload to + others. It also allows different schemes for chunk addressing and + content integrity protection, if the defaults are not fit for a + particular use case. In addition, it can work with different peer + discovery schemes, such as centralized trackers or fast Distributed + Hash Tables [JIM11]. Finally, in this default setup, PPSPP maintains + only a small amount of state per peer. A reference implementation of + PPSPP over UDP is available [SWIFTIMPL]. + + The protocol defined in this document assumes that a peer has already + discovered a list of (initial) peers using, for example, a + centralized tracker [PPSP-TP]. Once a peer has this list of peers, + PPSPP allows the peer to connect to other peers, request chunks of + content, and discover other peers disseminating the same content. + + The design of PPSPP is based on our research into making BitTorrent + [BITTORRENT] suitable for streaming content [P2PWIKI]. Most PPSPP + messages have corresponding BitTorrent messages and vice versa. + However, PPSPP is specifically targeted towards streaming audio/video + content and optimizes time-till-playback. It was also designed to be + more flexible and extensible. + +1.2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +1.3. Terminology + + message + The basic unit of PPSPP communication. A message will have + different representations on the wire depending on the transport + protocol used. Messages are typically multiplexed into a + datagram for transmission. + + datagram + A sequence of messages that is offered as a unit to the + underlying transport protocol (UDP, etc.). The datagram is + PPSPP's Protocol Data Unit (PDU). + + content + Either a live transmission or a prerecorded multimedia file. + + + + + + +Bakker, et al. Standards Track [Page 6] + +RFC 7574 PPSPP July 2015 + + + chunk + The basic unit in which the content is divided. For example, a + block of N kilobytes. A chunk may be of variable size. + + chunk ID + Unique identifier for a chunk of content (e.g., an integer). Its + type depends on the chunk addressing scheme used. + + chunk specification + An expression that denotes one or more chunk IDs. + + chunk addressing scheme + Scheme for identifying chunks and expressing the chunk + availability map of a peer in a compact fashion. + + chunk availability map + The set of chunks a peer has successfully downloaded and checked + the integrity of. + + bin + A number denoting a specific binary interval of the content + (i.e., one or more consecutive chunks) in the bin numbers chunk + addressing scheme (see Section 4). + + content integrity protection scheme + Scheme for protecting the integrity of the content while it is + being distributed via the peer-to-peer network. That is, methods + for receiving peers to detect whether a requested chunk has been + modified, either maliciously by the sending peer or accidentally + in transit. + + hash + The result of applying a cryptographic hash function, more + specifically a Modification Detection Code (MDC) [HAC01], such as + SHA-256 [FIPS180-4], to a piece of data. + + Merkle hash tree + A tree of hashes whose base is formed by the hashes of the chunks + of content, and its higher nodes are calculated by recursively + computing the hash of the concatenation of the two child hashes + (see Section 5.1). + + root hash + The root in a Merkle hash tree calculated recursively from the + content (see Section 5.1). + + + + + + +Bakker, et al. Standards Track [Page 7] + +RFC 7574 PPSPP July 2015 + + + munro hash + The hash of a subtree that is the unit of signing in the Unified + Merkle Tree content authentication scheme for live streaming (see + Section 6.1.2.1). + + swarm + A group of peers participating in the distribution of the same + content. + + swarm ID + Unique identifier for a swarm of peers, in PPSPP a sequence of + bytes. For video on demand with content integrity protection + enabled, the identifier is the so-called root hash of a Merkle + hash tree over the content. For live streaming, the swarm ID is + a public key. + + tracker + An entity that records the addresses of peers participating in a + swarm, usually for a set of swarms, and makes this membership + information available to other peers on request. + + choking + When Peer A is choking Peer B, it means that A is currently not + willing to accept requests for content from B. + + seeding + Peer A is said to be seeding when A has downloaded a static + content file completely and is now offering it for others to + download. + + leeching + Peer A is said to be leeching when A has not completely + downloaded a static content file yet or is not offering to upload + it to others. + + channel + A logical connection between two peers. The channel concept + allows peers to use the same transport address for communicating + with different peers. + + channel ID + Unique, randomly chosen identifier for a channel, local to each + peer. So the two peers logically connected by a channel each + have a different channel ID for that channel. + + heavy payload + A datagram has a heavy payload when it contains DATA messages, + SIGNED_INTEGRITY messages, or a large number of smaller messages. + + + +Bakker, et al. Standards Track [Page 8] + +RFC 7574 PPSPP July 2015 + + + In this document the prefixes kilo-, mega-, etc., denote base 1024. + +2. Overall Operation + + The basic unit of communication in PPSPP is the message. Multiple + messages are multiplexed into a single datagram for transmission. A + datagram (and hence the messages it contains) will have different + representations on the wire depending on the transport protocol used + (see Section 8). + + The overall operation of PPSPP is illustrated in the following + examples. The examples assume that the content distributed is + static, UDP is used for transport, the Merkle Hash Tree scheme is + used for content integrity protection, and that a specific policy is + used for selecting which chunks to download. + +2.1. Example: Joining a Swarm + + Consider a user who wants to watch a video. To play the video, the + user clicks on the play button of a HTML5 <video> element shown in + his PPSPP-enabled browser. Imagine this element has a PPSPP URL (to + be defined elsewhere) identifying the video as its source. The + browser passes this URL to its peer-to-peer streaming protocol + handler. Let's call this protocol handler Peer A. Peer A parses the + URL to retrieve the transport address of a peer-to-peer streaming + protocol tracker and swarm metadata of the content. The tracker + address may be optional in the presence of a decentralized tracking + mechanism. The mechanisms for tracking peers are outside of the + scope of this document. + + Peer A now registers with the tracker following the peer-to-peer + streaming protocol tracker specification [PPSP-TP] and receives the + IP address and port of peers already in the swarm, say, Peers B, C, + and D. At this point, the PPSPP starts operating. Peer A now sends + a datagram containing a PPSPP HANDSHAKE message to Peers B, C, and D. + This message conveys protocol options. In particular, Peer A + includes the ID of the swarm (part of the swarm metadata) as a + protocol option because the destination peers can listen for multiple + swarms on the same transport address. + + Peers B and C respond with datagrams containing a PPSPP HANDSHAKE + message and one or more HAVE messages. A HAVE message conveys (part + of) the chunk availability of a peer; thus, it contains a chunk + specification that denotes what chunks of the content Peers B and C + have, respectively. Peer D sends a datagram with a HANDSHAKE and + HAVE messages, but also with a CHOKE message. The latter indicates + that Peer D is not willing to upload chunks to Peer A at present. + + + + +Bakker, et al. Standards Track [Page 9] + +RFC 7574 PPSPP July 2015 + + +2.2. Example: Exchanging Chunks + + In response to Peers B and C, Peer A sends new datagrams to Peers B + and C containing REQUEST messages. A REQUEST message indicates the + chunks that a peer wants to download; thus, it contains a chunk + specification. The REQUEST messages to Peers B and C refer to + disjoint sets of chunks. Peers B and C respond with datagrams + containing HAVE, DATA, and, in this example, INTEGRITY messages. In + the Merkle hash tree content protection scheme (see Section 5.1), the + INTEGRITY messages contain all cryptographic hashes that Peer A needs + to verify the integrity of the content chunk sent in the DATA + message. Using these hashes, Peer A verifies that the chunks + received from Peers B and C are correct against the trusted swarm ID. + Peer A also updates the chunk availability of Peers B and C using the + information in the received HAVE messages. In addition, it passes + the chunks of video to the user's browser for rendering. + + After processing, Peer A sends a datagram containing HAVE messages + for the chunks it just received to all its peers. In the datagram to + Peers B and C, it includes an ACK message acknowledging the receipt + of the chunks and adds REQUEST messages for new chunks. ACK messages + are not used when a reliable transport protocol is used. When, for + example, Peer C finds that Peer A obtained a chunk (from Peer B) that + Peer C did not yet have, Peer C's next datagram includes a REQUEST + for that chunk. + + Peer D also sends HAVE messages to Peer A when it downloads chunks + from other peers. When Peer D is willing to accept REQUESTs from + Peer A, Peer D sends a datagram with an UNCHOKE message to inform + Peer A. If Peer B or C decides to choke Peer A, they send a CHOKE + message and Peer A should then re-request from other peers. Peers B + and C may continue to send HAVE, REQUEST, or periodic keep-alive + messages such that Peer A keeps sending them HAVE messages. + + Once Peer A has received all content (video-on-demand use case), it + stops sending messages to all other peers that have all content + (a.k.a. seeders). Peer A can also contact the tracker or another + source again to obtain more peer addresses. + +2.3. Example: Leaving a Swarm + + To leave a swarm in a graceful way, Peer A sends a specific HANDSHAKE + message to all its peers (see Section 8.4) and deregisters from the + tracker following the tracker specification [PPSP-TP]. Peers + receiving the datagram should remove Peer A from their current peer + list. If Peer A crashes ungracefully, peers should remove Peer A + from their peer list when they detect it no longer sends messages + (see Section 3.12). + + + +Bakker, et al. Standards Track [Page 10] + +RFC 7574 PPSPP July 2015 + + +3. Messages + + No error codes or responses are used in the protocol; absence of any + response indicates an error. Invalid messages are discarded, and + further communication with the peer SHOULD be stopped. The rationale + is that it is sufficient to classify peers as either good or bad and + only use the good ones. A good peer is a peer that responds with + chunks; a peer that does not respond, or does not respond in time is + classified as bad. The idea is that, in PPSPP, the content is + available from multiple sources (unlike HTTP), so a peer should not + invest too much effort in trying to obtain it from a particular + source. This classification in good or bad allows a peer to deal + with slow, crashed, and (silent) malicious peers. + + Multiple messages MUST be multiplexed into a single datagram for + transmission. Messages in a single datagram MUST be processed in the + strict order in which they appear in the datagram. If an invalid + message is found in a datagram, the remaining messages MUST be + discarded. + + For the sake of simplicity, one swarm of peers deals with one content + file or stream only. There is a single division of the content into + chunks that all peers in the swarm adhere to, determined by the + content publisher. Distribution of a collection of files can be done + either by using multiple swarms or by using an external storage + mapping from the linear byte space of a single swarm to different + files, transparent to the protocol. In other words, the audio/video + container format used is outside the scope of this document. + +3.1. HANDSHAKE + + For Peer P to establish communication with Peer Q in Swarm S, the + peers must first exchange HANDSHAKE messages by means of a handshake + procedure. The initiating Peer P needs to know the metadata of Swarm + S, which consists of: + + (a) the swarm ID of the content (see Sections 5.1 and 6), + + (b) the chunk size used, + + (c) the chunk addressing method used, + + (d) the content integrity protection method used, and + + (e) the Merkle hash tree function used (if applicable). + + + + + + +Bakker, et al. Standards Track [Page 11] + +RFC 7574 PPSPP July 2015 + + + (f) If automatic content size detection (see Section 5.6) is not + used, the content length is also part of the metadata (for + static content.) + + This document assumes the swarm metadata is obtained from a trusted + source. In addition, Peer P needs to know a transport address for + Peer Q, obtained from a peer discovery/tracking protocol. + + The payload of the HANDSHAKE message contains a sequence of protocol + options. The protocol options encode the swarm metadata just + described to enable an end-to-end check to see whether the peers are + in the right swarm. Additionally, the options encode a number of + per-peer configuration parameters. The complete set of protocol + options are specified in Section 7. The HANDSHAKE message also + contains a channel ID for multiplexing communication and security + (see Sections 3.11 and 12.1). A HANDSHAKE message MUST always be the + first message in a datagram. + +3.1.1. Handshake Procedure + + The handshake procedure for a peer, Peer P, to start communication + with another peer, Peer Q, in Swarm S is now as follows. + + 1. The first datagram the initiating Peer P sends to Peer Q MUST + start with a HANDSHAKE message. This HANDSHAKE message MUST + contain: + + * A channel ID, chanP, randomly chosen as specified in + Section 12.1. + + * The metadata of Swarm S, encoded as protocol options, as + specified in Section 7. In particular, the initiating Peer P + MUST include the swarm ID. + + * The capabilities of Peer P, in particular, its supported + protocol versions, "Live Discard Window" (in case of a live + swarm) and "Supported Messages", encoded as protocol options. + + This first datagram MUST be prefixed with the (destination) + channel ID 0; see Section 3.11. Hence, the datagram contains two + channel IDs: the destination channel ID prefixed to the datagram + and the channel ID chanP included in the HANDSHAKE message inside + the datagram. This datagram MAY also contain some minor + additional payload, e.g., HAVE messages to indicate Peer P's + current progress, but it MUST NOT include any heavy payload + (defined in Section 1.3), such as a DATA message. Allowing minor + + + + + +Bakker, et al. Standards Track [Page 12] + +RFC 7574 PPSPP July 2015 + + + payload minimizes the number of initialization round trips, thus + improving time-till-playback. Forbidding heavy payload prevents + an amplification attack (see Section 12.1). + + 2. The receiving Peer Q checks the HANDSHAKE message from Peer P. + If any check by Peer Q fails, or if Peers P and Q are not in the + same swarm, Peer Q MUST NOT send a HANDSHAKE (or any other) + message back, as the message from Peer P may have been spoofed + (see Section 12.1). Otherwise, if Peer Q is interested in + communicating with Peer P, Peer Q MUST send a datagram to Peer P + that starts with a HANDSHAKE message. This reply HANDSHAKE MUST + contain: + + * A channel ID, chanQ, randomly chosen as specified in + Section 12.1. + + * The metadata of Swarm S, encoded as protocol options, as + specified in Section 7. In particular, the responding Peer Q + MAY include the swarm ID. + + * The capabilities of Peer Q, in particular, its supported + protocol versions, its "Live Discard Window" (in case of a + live swarm) and "Supported Messages", encoded as protocol + options. + + This reply datagram MUST be prefixed with the channel ID chanP + sent by Peer P in the first HANDSHAKE message (see Section 3.11). + This reply datagram MAY also contain some minor additional + payload, e.g., HAVE messages to indicate Peer Q's current + progress, or REQUEST messages (see Section 3.7), but it MUST NOT + include any heavy payload. + + 3. The initiating Peer P checks the reply datagram from Peer Q. If + the reply datagram is not prefixed with (destination) channel ID + chanP, Peer P MUST discard the datagram. Peer P SHOULD continue + to process datagrams from Peer Q that do meet this requirement. + This check prevents interference by spoofing, see Section 12.1. + If Peer P's channel ID is echoed correctly, the initiator Peer P + knows that the addressed Peer Q really responds. + + 4. Next, Peer P checks the HANDSHAKE message in the datagram from + Peer Q. If any check by Peer P fails, or Peer P is no longer + interested in communicating with Peer Q, Peer P MAY send a + HANDSHAKE message to inform Peer Q it will cease communication. + This closing HANDSHAKE message MUST contain an all zeros channel + ID and a list of protocol options. The list MUST either be empty + or contain the maximum version number Peer P supports, following + the min/max versioning scheme defined in [RFC6709], Section 4.1. + + + +Bakker, et al. Standards Track [Page 13] + +RFC 7574 PPSPP July 2015 + + + The datagram containing this closing HANDSHAKE message MUST be + prefixed with the (destination) channel ID chanQ. Peer P MAY + also simply cease communication. + + 5. If the addressed peer, Peer Q, does not respond to initiating + Peer P's first datagram, Peer P MAY resend that datagram until + Peer Q is considered dead, according to the rules specified in + Section 3.12. + + 6. If the reply datagram by Peer Q does pass the checks by Peer P, + and Peer P wants to continue interacting with Peer Q, Peer P can + now send REQUEST, PEX_REQ, and other messages to Peer Q. + Datagrams carrying these messages MUST be prefixed with the + channel ID chanQ sent by Peer Q. More specifically, because Peer + P knows that Peer Q really responds, Peer P MAY start sending + Peer Q messages with heavy payload. That means that Peer P MAY + start responding to any REQUEST messages that Peer Q may have + sent in this first reply datagram with DATA messages. Hence, + transfer of chunks can start soon in PPSPP. + + 7. If Peer Q receives any datagram (apparently) from Peer P that + does not contain channel ID chanQ, Peer Q MUST discard the + datagram but SHOULD continue to process datagrams from Peer P + that do meet this requirement. Once Peer Q receives a datagram + from Peer P that does contain the channel ID chanQ, Peer Q knows + that Peer P really received its reply datagram, and the three-way + handshake and channel establishment is complete. Peer Q MAY now + also start sending messages with heavy payload to Peer P. + + 8. If Peer P decides it no longer wants to communicate with Peer Q, + or vice versa, the peer SHOULD send a closing HANDSHAKE message + to the other, as described above. + +3.2. HAVE + + The HAVE message is used to convey which chunks a peer has available + for download. The set of chunks it has available may be expressed + using different chunk addressing and availability map compression + schemes, described in Section 4. HAVE messages can be used both for + sending a complete overview of a peer's chunk availability as well as + for updates to that set. + + In particular, whenever a receiving Peer P has successfully checked + the integrity of a chunk, or interval of chunks, it MUST send a HAVE + message to all peers Q1..Qn it wants to allow to download those + chunks. A policy in Peer P determines when the HAVE is sent. Peer P + may send it directly, or Peer P may wait either until it has other + data to send to Peer Qi or until it has received and checked multiple + + + +Bakker, et al. Standards Track [Page 14] + +RFC 7574 PPSPP July 2015 + + + chunks. The policy will depend on how urgent it is to distribute + this information to the other peers. This urgency is generally + determined in turn by the chunk picking policy (see Section 9.1). In + general, the HAVE messages can be piggybacked onto other messages. + Peers that do not receive HAVE messages are effectively prevented + from downloading the newly available chunks; hence, the HAVE message + can be used as a method of choking. + + The HAVE message MUST contain the chunk specification of the received + and verified chunks. A receiving peer MUST NOT send a HAVE message + to peers for which the handshake procedure is still incomplete, see + Section 12.1. A peer SHOULD NOT send a HAVE message to peers that + have the complete content already (e.g., in video-on-demand + scenarios). + +3.3. DATA + + The DATA message is used to transfer chunks of content. The DATA + message MUST contain the chunk ID of the chunk and chunk itself. A + peer MAY send the DATA messages for multiple chunks in the same + datagram. The DATA message MAY contain additional information if + needed by the specific congestion control mechanism used. At + present, PPSPP uses LEDBAT [RFC6817] for congestion control, which + requires the current system time to be sent along with the DATA + message, so the current system time MUST be included. + +3.4. ACK + + ACK messages MUST be sent to acknowledge received chunks if PPSPP is + run over an unreliable transport protocol. ACK messages MAY be sent + if a reliable transport protocol is used. In the former case, a + receiving peer that has successfully checked the integrity of a + chunk, or interval of chunks C, MUST send an ACK message containing a + chunk specification for C. As LEDBAT is used, an ACK message MUST + contain the one-way delay, computed from the peer's current system + time received in the DATA message. A peer MAY delay sending ACK + messages as defined in the LEDBAT specification [RFC6817]. + +3.5. INTEGRITY + + The INTEGRITY message carries information required by the receiver to + verify the integrity of a chunk. Its payload depends on the content + integrity protection scheme used. When the Merkle Hash Tree scheme + is used, an INTEGRITY message MUST contain a cryptographic hash of a + subtree of the Merkle hash tree and the chunk specification that + identifies the subtree. + + + + + +Bakker, et al. Standards Track [Page 15] + +RFC 7574 PPSPP July 2015 + + + As a typical example, when a peer wants to send a chunk and Merkle + hash trees are used, it creates a datagram that consists of several + INTEGRITY messages containing the hashes the receiver needs to verify + the chunk and the actual chunk itself encoded in a DATA message. + What are the necessary hashes and the exact rules for encoding them + into datagrams is specified in Sections 5.3, and 5.4, respectively. + +3.6. SIGNED_INTEGRITY + + The SIGNED_INTEGRITY message carries digitally signed information + required by the receiver to verify the integrity of a chunk in live + streaming. It logically contains a chunk specification, a timestamp, + and a digital signature. Its exact payload depends on the live + content integrity protection scheme used, see Section 6.1. + +3.7. REQUEST + + While bulk download protocols normally do explicit requests for + certain ranges of data (i.e., use a pull model, for example, + BitTorrent [BITTORRENT]), live streaming protocols quite often use a + push model without requests to save round trips. PPSPP supports both + models of operation. + + The REQUEST message is used to request one or more chunks from + another peer. A REQUEST message MUST contain the specification of + the chunks the requester wants to download. A peer receiving a + REQUEST message MAY send out the requested chunks (by means of DATA + messages). When Peer Q receives multiple REQUESTs from the same Peer + P, Peer Q SHOULD process the REQUESTs in the order received. + Multiple REQUEST messages MAY be sent in one datagram, for example, + when a peer wants to request several rare chunks at once. + + When live streaming via a push model, a peer receiving REQUESTs also + MAY send some other chunks in case it runs out of requests or for + some other reason. In that case, the only purpose of REQUEST + messages is to provide hints and coordinate peers to avoid + unnecessary data retransmission. + +3.8. CANCEL + + When downloading on-demand or live streaming content, a peer can + request urgent data from multiple peers to increase the probability + of it being delivered on time. In particular, when the specific + chunk picking algorithm (see Section 9.1), detects that a request for + urgent data might not be served on time, a request for the same data + can be sent to a different peer. When a Peer P decides to request + urgent data from a Peer Q, Peer P SHOULD send a CANCEL message to all + the peers to which the data has been previously requested. The + + + +Bakker, et al. Standards Track [Page 16] + +RFC 7574 PPSPP July 2015 + + + CANCEL message contains the specification of the chunks Peer P no + longer wants to request. In addition, when Peer Q receives a HAVE + message for the urgent data from Peer P, Peer Q MUST also cancel the + previous REQUEST(s) from Peer P. In other words, the HAVE message + acts as an implicit CANCEL. + +3.9. CHOKE and UNCHOKE + + Peer A can send a CHOKE message to Peer B to signal it will no longer + be responding to REQUEST messages from Peer B, for example, because + Peer A's upload capacity is exhausted. Peer A MAY send a subsequent + UNCHOKE message to signal that it will respond to new REQUESTs from + Peer B again (Peer A SHOULD discard old requests). When Peer B + receives a CHOKE message from Peer A, it MUST NOT send new REQUEST + messages and it cannot expect answers to any outstanding ones, as the + transfer of chunks is choked. When Peer B is choked but receives a + HAVE message from Peer A, it is not automatically unchoked and MUST + NOT send any new REQUEST messages. The CHOKE and UNCHOKE messages + are informational as responding to REQUESTs is OPTIONAL, see + Section 3.7. + +3.10. Peer Address Exchange + +3.10.1. PEX_REQ and PEX_RES Messages + + Peer Exchange (PEX) messages are common in many peer-to-peer + protocols. They allow peers to exchange the transport addresses of + the peers they are currently interacting with, thereby reducing the + need to contact a central tracker (or Distributed Hash Table) to + discovery new peers. The strength of this mechanism is therefore + that it enables decentralized peer discovery: after an initial + bootstrap, a central tracker is no longer needed. Its weakness is + that it enables a number of attacks, so it should not be used on the + Internet unless extra security measures are in place. + + PPSPP supports peer-address exchange on the Internet and in benign + private networks as an OPTIONAL feature (not mandatory to implement) + under certain conditions. The general mechanism works as follows. + To obtain some peer addresses, a Peer A MAY send a PEX_REQ message to + Peer B. Peer B MAY respond with one or more PEX_REScert messages. + Logically, a PEX_REScert reply message contains the address of a + single peer Ci. Peer B MUST have exchanged messages with Peer Ci in + the last 60 seconds to guarantee liveliness. Upon receipt, Peer A + may contact any or none of the returned peers Ci. Alternatively, + peers MAY ignore PEX_REQ and PEX_REScert messages if uninterested in + obtaining new peers or because of security considerations (rate + limiting) or any other reason. The PEX messages can be used to + construct a dedicated tracker peer. + + + +Bakker, et al. Standards Track [Page 17] + +RFC 7574 PPSPP July 2015 + + + To use PEX in PPSPP on the Internet, two conditions must be met: + + 1. Peer transport addresses must be relatively stable. + + 2. A peer must not obtain all its peer addresses through PEX. + + The full security analysis for PEX messages can be found in + Section 12.2. Physically, a PEX_REScert message carries a swarm- + membership certificate rather than an IP address and port. A + membership certificate for Peer C states that Peer C at address + (ipC,portC) is part of Swarm S at Time T and is cryptographically + signed by an issuer. The receiver Peer A can check the certificate + for a valid signature by a trusted issuer, the right swarm, and + liveliness and only then consider contacting C. 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. Section 12.2.2 describes an example where a + central tracker acts as the Certification Authority. + + In a hostile environment, such as the Internet, peers must also + ensure that they do not end up interacting only with malicious peers + when using the peer-address exchange feature. To this extent, peers + MUST ensure that part of their connections are to peers whose + addresses came from a trusted and secured tracker (see + Section 12.2.3). + + In addition to the PEX_REScert, there are two other PEX reply + messages. The PEX_RESv4 message contains a single IPv4 address and + port. The PEX_RESv6 message contains a single IPv6 address and port. + They MUST only be used in a benign environment, such as a private + network, as they provide no guarantees that the host addressed + actually participates in a PPSPP swarm. + + Once a PPSPP implementation has obtained a list of peers (either via + PEX, from a central tracker, or via a Distributed Hash Table (DHT)), + it has to determine which peers to actually contact. In this + process, a PPSPP implementation can benefit from information by + network or content providers to help improve network usage and boost + PPSPP performance. How a peer-to-peer (P2P) system like PPSPP can + perform these optimizations using the Application-Layer Traffic + Optimization (ALTO) protocol is described in detail in [RFC7285], + Section 7. + + + + + +Bakker, et al. Standards Track [Page 18] + +RFC 7574 PPSPP July 2015 + + +3.11. Channels + + It is increasingly complex for peers to enable communication between + each other due to NATs and firewalls. Therefore, PPSPP uses a + multiplexing scheme, called channels, to allow multiple swarms to use + the same transport address. Channels loosely correspond to TCP + connections and each channel belongs to a single swarm, as + illustrated in Figure 1. As with TCP connections, a channel is + identified by a unique identifier local to the peer at each end of + the connection (cf. TCP port), which MUST be randomly chosen. In + other words, the two peers connected by a channel use different IDs + to denote the same channel. The IDs are different and random for + security reasons, see Section 12.1. + + In the PPSP-over-UDP encapsulation (Section 8.3), when a Channel C + has been established between Peer A and Peer B, the datagrams + containing messages from Peer A to Peer B are prefixed with the four- + byte channel ID allocated by Peer B, and vice versa for datagrams + from Peer B to A. The channel IDs used are exchanged as part of the + handshake procedure, see Section 8.4. In that procedure, the channel + ID with value 0 is used for the datagram that initiates the + handshake. PPSPP can be used in combination with Session Traversal + Utilities for NAT (STUN) [RFC5389]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Bakker, et al. Standards Track [Page 19] + +RFC 7574 PPSPP July 2015 + + + _________ _________ _________ + | | | | | | + | Swarm | | Swarm | | Swarm | + | Mgr | | A | | B | + |_______| |_______| |_______| + | | / \ + | | / \ + ____|____ ____|____ ______/__ _\_______ + | | | | | | | | + | Chan | | Chan | | Chan | | Chan | + | 0 | | 481 | | 836 | | 372 | + |_______| |_______| |_______| |_______| + | | | | + | | | | + ____|____________|____________|____________|____ + | | + | UDP | + | port 6778 | + |______________________________________________| + + + Network stack of a PPSPP peer that is reachable on UDP port 6778 and + is connected via channel 481 to one peer in Swarm A and two peers in + Swarm B via channels 836 and 372, respectively. Channel ID 0 is + special and is used for handshaking. + + Figure 1 + +3.12. Keep Alive Signaling + + A peer SHOULD send a "keep alive" message periodically to each peer + it is interested in, but has no other messages to send to them at + present. The goal of the keep alives is to keep a signaling channel + open to peers that are of interest. Which peers those are is + determined by a policy that decides which peers are of interest now + and in the near future. This document does not prescribe a policy, + but examples of interesting peers are (a) peers that have chunks on + offer that this client needs or (b) peers that currently do not have + interesting chunks on offer (because they are still downloading + themselves, or in live streaming) but gave good performance in the + past. When these peers have new chunks to offer, the peer that kept + a signaling channel open can use them again. Periodically sending + "keep alive" messages prevents other peers declaring the peer dead. + A guideline for declaring a peer dead when using UDP consists of a + three minute delay since that last packet has been received from that + peer and at least three datagrams having been sent to that peer + during the same period. When a peer is declared dead, the channel to + it is closed, no more messages will be sent to that peer and the + + + +Bakker, et al. Standards Track [Page 20] + +RFC 7574 PPSPP July 2015 + + + local administration about the peer is discarded. Busy servers can + force idle clients to disconnect by not sending keep alives. PPSPP + does not define an explicit message type for "keep alive" messages. + In the PPSP-over-UDP encapsulation they are implemented as simple + datagrams consisting of a four-byte channel ID only, see Sections 8.3 + and 8.4. + +4. Chunk Addressing Schemes + + PPSPP can use different methods of chunk addressing, that is, support + different ways of identifying chunks and different ways of expressing + the chunk availability map of a peer in a compact fashion. + + All peers in a swarm MUST use the same chunk addressing method. + +4.1. Start-End Ranges + + A chunk specification consists of a single (start specification,end + specification) pair that identifies a range of chunks (end + inclusive). The start and end specifications can use one of multiple + addressing schemes. Two schemes are currently defined: chunk ranges + and byte ranges. + +4.1.1. Chunk Ranges + + The start and end specification are both chunk identifiers. Chunk + identifiers are 32-bit or 64-bit unsigned integers. A PPSPP peer + MUST support this scheme. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Start chunk (32 or 64) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ End chunk (32 or 64) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.1.2. Byte Ranges + + The start and end specification are 64-bit byte offsets in the + content. The support for this scheme is OPTIONAL. + + + + + + + + + + +Bakker, et al. Standards Track [Page 21] + +RFC 7574 PPSPP July 2015 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Start byte offset (64) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | End byte offset (64) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.2. Bin Numbers + + PPSPP introduces a novel method of addressing chunks of content + called "bin numbers" (or "bins" for short). Bin numbers allow the + addressing of a binary interval of data using a single integer. This + reduces the amount of state that needs to be recorded per peer and + the space needed to denote intervals on the wire, making the protocol + lightweight. In general, this numbering system allows PPSPP to work + with simpler data structures, e.g., to use arrays instead of binary + trees, thus reducing complexity. The support for this scheme is + OPTIONAL. + + In bin addressing, the smallest binary interval is a single chunk + (e.g., a block of bytes that may be of variable size), the largest + interval is a complete range of 2**63 chunks. In a novel addition to + the classical scheme, these intervals are numbered in a way that lays + them out into a vector nicely, which is called bin numbering, as + follows. Consider a chunk interval of width W. To derive the bin + numbers of the complete interval and the subintervals, a minimal + balanced binary tree is built that is at least W chunks wide at the + base. The leaves from left-to-right correspond to the chunks 0..W-1 + in the interval, and have bin number I*2 where I is the index of the + chunk (counting beyond W-1 to balance the tree). The bin number of + higher-level node P in the tree is calculated as follows: + + binP = (binL + binR) / 2 + + where binL is the bin of node P's left-hand child and binR is the bin + of node P's right-hand child. Given that each node in the tree + represents a subinterval of the original interval, each such + subinterval now is addressable by a bin number, a single integer. + The bin number tree of an interval of width W=8 looks like this: + + + + + + + +Bakker, et al. Standards Track [Page 22] + +RFC 7574 PPSPP July 2015 + + + 7 + / \ + / \ + / \ + / \ + 3 11 + / \ / \ + / \ / \ + / \ / \ + 1 5 9 13 + / \ / \ / \ / \ + 0 2 4 6 8 10 12 14 + + C0 C1 C2 C3 C4 C5 C6 C7 + + The bin number tree of an interval of width W=8 + + Figure 2 + + So bin 7 represents the complete interval, bin 3 represents the + interval of chunk C0..C3, bin 1 represents the interval of chunks C0 + and C1, and bin 2 represents chunk C1. The special numbers + 0xFFFFFFFF (32-bit) or 0xFFFFFFFFFFFFFFFF (64-bit) stands for an + empty interval, and 0x7FFF...FFF stands for "everything". + + When bin numbering is used, the ID of a chunk is its corresponding + (leaf) bin number in the tree, and the chunk specification in HAVE + and ACK messages is equal to a single bin number (32-bit or 64-bit), + as follows. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Bin number (32 or 64) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +4.3. In Messages + +4.3.1. In HAVE Messages + + When a receiving peer has successfully checked the integrity of a + chunk or interval of chunks, it MUST send a HAVE message to all peers + it wants to allow download of those chunk(s) from. The ability to + withhold HAVE messages allows them to be used as a method of choking. + The HAVE message MUST contain the chunk specification of the biggest + complete interval of all chunks the receiver has received and checked + so far that fully includes the interval of chunks just received. So + + + + +Bakker, et al. Standards Track [Page 23] + +RFC 7574 PPSPP July 2015 + + + the chunk specification MUST denote at least the interval received, + but the receiver is supposed to aggregate and acknowledge bigger + intervals, when possible. + + As a result, every single chunk is acknowledged a logarithmic number + of times. That provides some necessary redundancy of + acknowledgements and sufficiently compensates for unreliable + transport protocols. + + Implementation note: + + To record which chunks a peer has in the state that an + implementation keeps for each peer, an implementation MAY use the + efficient "binmap" data structure, which is a hybrid of a bitmap + and a binary tree, discussed in detail in [BINMAP]. + +4.3.2. In ACK Messages + + PPSPP peers MUST use ACK messages to acknowledge received chunks if + an unreliable transport protocol is used. When a receiving peer has + successfully checked the integrity of a chunk or interval of chunks + C, it MUST send an ACK message containing the chunk specification of + its biggest, complete interval covering C to the sending peer (see + HAVE). + +5. Content Integrity Protection + + PPSPP can use different methods for protecting the integrity of the + content while it is being distributed via the peer-to-peer network. + More specifically, PPSPP can use different methods for receiving + peers to detect whether a requested chunk has been maliciously + modified by the sending peer. In benign environments, content + integrity protection can be disabled. + + For static content, PPSPP currently defines one method for protecting + integrity, called the Merkle Hash Tree scheme. If PPSPP operates + over the Internet, this scheme MUST be used. If PPSPP operates in a + benign environment, this scheme MAY be used. So the scheme is + mandatory to implement, to satisfy the requirement of strong security + for an IETF protocol [RFC3365]. An extended version of the scheme is + used to efficiently protect dynamically generated content (live + streams), as explained below and in Section 6.1. + + The Merkle Hash Tree scheme can work with different chunk addressing + schemes. All it requires is the ability to address a range of + chunks. In the following description abstract node IDs are used to + identify nodes in the tree. On the wire, these are translated to the + corresponding range of chunks in the chosen chunk addressing scheme. + + + +Bakker, et al. Standards Track [Page 24] + +RFC 7574 PPSPP July 2015 + + +5.1. Merkle Hash Tree Scheme + + PPSPP uses a method of naming content based on self-certification. + In particular, content in PPSPP is identified by a single + cryptographic hash that is the root hash in a Merkle hash tree + calculated recursively from the content [ABMRKL]. This self- + certifying hash tree allows every peer to directly detect when a + malicious peer tries to distribute fake content. It also ensures + only a small the amount of information is needed to start a download + (the root hash and some peer addresses). For live streaming, a + dynamic tree and a public key are used, see below. + + The Merkle hash tree of a content file that is divided into N chunks + is constructed as follows. Note the construction does not assume + chunks of content to be of a fixed size. Given a cryptographic hash + function, more specifically an MDC [HAC01], such as SHA-256, the + hashes of all the chunks of the content are calculated. Next, a + binary tree of sufficient height is created. Sufficient height means + that the lowest level in the tree has enough nodes to hold all chunk + hashes in the set, as with bin numbering. The figure below shows the + tree for a content file consisting of 7 chunks. As with the content + addressing scheme, the leaves of the tree correspond to a chunk and, + in this case, are assigned the hash of that chunk, starting at the + leftmost leaf. As the base of the tree may be wider than the number + of chunks, any remaining leaves in the tree are assigned an empty + hash value of all zeros. Finally, the hash values of the higher + levels in the tree are calculated, by concatenating the hash values + of the two children (again left to right) and computing the hash of + that aggregate. If the two children are empty hashes, the parent is + an empty all-zeros hash as well (to save computation). This process + ends in a hash value for the root node, which is called the "root + hash". Note the root hash only depends on the content and any + modification of the content will result in a different root hash. + + + + + + + + + + + + + + + + + + +Bakker, et al. Standards Track [Page 25] + +RFC 7574 PPSPP July 2015 + + + 7 = root hash + / \ + / \ + / \ + / \ + 3* 11 + / \ / \ + / \ / \ + / \ / \ + 1 5 9 13* = uncle hash + / \ / \ / \ / \ + 0 2 4 6 8 10* 12 14 + + C0 C1 C2 C3 C4 C5 C6 E + =chunk index ^^ = empty hash + + Merkle hash tree of a content file with N=7 chunks + + Figure 3 + +5.2. Content Integrity Verification + + Assuming a peer receives the root hash of the content it wants to + download from a trusted source, it can check the integrity of any + chunk of that content it receives as follows. It first calculates + the hash of the chunk it received, for example, chunk C4 in the + previous figure. Along with this chunk, it MUST receive the hashes + required to check the integrity of that chunk. In principle, these + are the hash of the chunk's sibling (C5) and that of its "uncles". A + chunk's uncles are the sibling Y of its parent X, and the uncle of + that Y, recursively until the root is reached. For chunk C4, the + uncles are nodes 13 and 3 and the sibling is 10; all marked with a * + in the figure. Using this information, the peer recalculates the + root hash of the tree and compares it to the root hash it received + from the trusted source. If they match, the chunk of content has + been positively verified to be the requested part of the content. + Otherwise, the sending peer sent either the wrong content or the + wrong sibling or uncle hashes. For simplicity, the set of sibling + and uncle hashes is collectively referred to as the "uncle hashes". + + In the case of live streaming, the tree of chunks grows dynamically + and the root hash is undefined or, more precisely, transient, as long + as new data is generated by the live source. Section 6.1.2 defines a + method for content integrity verification for live streams that works + with such a dynamic tree. Although the tree is dynamic, content + verification works the same for both live and predefined content, + resulting in a unified method for both types of streaming. + + + + +Bakker, et al. Standards Track [Page 26] + +RFC 7574 PPSPP July 2015 + + +5.3. The Atomic Datagram Principle + + As explained above, a datagram consists of a sequence of messages. + Ideally, every datagram sent must be independent of other datagrams: + each datagram SHOULD be processed separately, and a loss of one + datagram must not disrupt the flow of datagrams between two peers. + Thus, as a datagram carries zero or more messages, both messages and + message interdependencies SHOULD NOT span over multiple datagrams. + + This principle implies that as any chunk is verified using its uncle + hashes, the necessary hashes SHOULD be put into the same datagram as + the chunk's data. If this is not possible because of a limitation on + datagram size, the necessary hashes MUST be sent first in one or more + datagrams. As a general rule, if some additional data is still + missing to process a message within a datagram, the message SHOULD be + dropped. + + The hashes necessary to verify a chunk are, in principle, its + sibling's hash and all its uncle hashes, but the set of hashes to + send can be optimized. Before sending a packet of data to the + receiver, the sender inspects the receiver's previous + acknowledgements (HAVE or ACK) to derive which hashes the receiver + already has for sure. Suppose the receiver had acknowledged chunks + C0 and C1 (the first two chunks of the file), then it must already + have uncle hashes 5, 11, and so on. That is because those hashes are + necessary to check C0 and C1 against the root hash. Then, hashes 3, + 7, and so on must also be known as they are calculated in the process + of checking the uncle hash chain. Hence, to send chunk C7, the + sender needs to include just the hashes for nodes 14 and 9, which let + the data be checked against hash 11, which is already known to the + receiver. + + The sender MAY optimistically skip hashes that were sent out in + previous, still-unacknowledged datagrams. It is an optimization + trade-off between redundant hash transmission and the possibility of + collateral data loss in the case in which some necessary hashes were + lost in the network so some delivered data cannot be verified and + thus had to be dropped. In either case, the receiver builds the + Merkle hash tree on-demand, incrementally, starting from the root + hash, and uses it for data validation. + + In short, the sender MUST put into the datagram the hashes he + believes are necessary for the receiver to verify the chunk. The + receiver MUST remember all the hashes it needs to verify missing + chunks that it still wants to download. Note that the latter implies + that a hardware-limited receiver MAY forget some hashes if it does + not plan to announce possession of these chunks to others (i.e., does + not plan to send HAVE messages.) + + + +Bakker, et al. Standards Track [Page 27] + +RFC 7574 PPSPP July 2015 + + +5.4. INTEGRITY Messages + + Concretely, a peer that wants to send a chunk of content creates a + datagram that MUST consist of a list of INTEGRITY messages followed + by a DATA message. If the INTEGRITY messages and DATA message cannot + be put into a single datagram because of a limitation on datagram + size, the INTEGRITY messages MUST be sent first in one or more + datagrams. The list of INTEGRITY messages sent MUST contain an + INTEGRITY message for each hash the receiver misses for integrity + checking. An INTEGRITY message for a hash MUST contain the chunk + specification corresponding to the node ID of the hash and the hash + data itself. The chunk specification corresponding to a node ID is + defined as the range of chunks formed by the leaves of the subtree + rooted at the node. For example, node 3 in Figure 3 denotes chunks + 0, 2, 4, and 6, so the chunk specification should denote that + interval. The list of INTEGRITY messages MUST be sorted in order of + the tree height of the nodes, descending (the leaves are at height + 0). The DATA message MUST contain the chunk specification of the + chunk and the chunk itself. A peer MAY send the required messages + for multiple chunks in the same datagram, depending on the + encapsulation. + +5.5. Discussion and Overhead + + The current method for protecting content integrity in BitTorrent + [BITTORRENT] is not suited for streaming. It involves providing + clients with the hashes of the content's chunks before the download + commences by means of metadata files (called .torrent files in + BitTorrent.) However, when chunks are small, as in the current UDP + encapsulation of PPSPP, this implies having to download a large + number of hashes before content download can begin. This, in turn, + increases time-till-playback for end users, making this method + unsuited for streaming. + + The overhead of using Merkle hash trees is limited. The size of the + hash tree expressed as the total number of nodes depends on the + number of chunks the content is divided (and hence the size of + chunks) following this formula: + + nnodes = math.pow(2,math.log(nchunks,2)+1) + + In principle, the hash values of all these nodes will have to be sent + to a peer once for it to verify all of the chunks. Hence, the + maximum on-the-wire overhead is hashsize * nnodes. However, the + actual number of hashes transmitted can be optimized as described in + Section 5.3. + + + + + +Bakker, et al. Standards Track [Page 28] + +RFC 7574 PPSPP July 2015 + + + To see a peer can verify all chunks whilst receiving not all hashes, + consider the example tree in Section 5.1. In the case of a simple + progressive download, of chunks 0, 2, 4, 6, etc., the sending peer + will send the following hashes: + + +-------+---------------------------------------------+ + | Chunk | Node IDs of hashes sent | + +-------+---------------------------------------------+ + | 0 | 2,5,11 | + | 2 | - (receiver already knows all) | + | 4 | 6 | + | 6 | - | + | 8 | 10,13 (hash 3 can be calculated from 0,2,5) | + | 10 | - | + | 12 | 14 | + | 14 | - | + | Total | # hashes 7 | + +-------+---------------------------------------------+ + + Table 1: Overhead for the Example Tree + + So the number of hashes sent in total (7) is less than the total + number of hashes in the tree (16), as a peer does not need to send + hashes that are calculated and verified as part of earlier chunks. + +5.6. Automatic Detection of Content Size + + In PPSPP, the size of a static content file, such as a video file, + can be reliably and automatically derived from information received + from the network when fixed-size chunks are used. As a result, it is + not necessary to include the size of the content file as the metadata + of the content for such files. Implementations of PPSPP MAY use this + automatic detection feature. Note this feature is the only feature + of PPSPP that requires that a fixed-size chunk is used. This feature + builds on the Merkle hash tree and the trusted root hash as swarm ID + as follows. + +5.6.1. Peak Hashes + + The ability for a newcomer peer to detect the size of the content + depends heavily on the concept of peak hashes. The concept of peak + hashes depends on the concepts of filled and incomplete nodes. + Recall that when constructing the binary trees for content + verification and addressing the base of the tree may have more leaves + than the number of chunks in the content. In the Merkle hash tree, + these leaves were assigned empty all-zero hashes to be able to + calculate the higher-level hashes. A filled node is now defined as a + node that corresponds to an interval of leaves that consists only of + + + +Bakker, et al. Standards Track [Page 29] + +RFC 7574 PPSPP July 2015 + + + hashes of content chunks, not empty hashes. Reversely, an incomplete + (not filled) node corresponds to an interval that also contains empty + hashes, typically, an interval that extends past the end of the file. + In the following figure, nodes 7, 11, 13, and 14 are incomplete: the + rest is filled. + + Formally, a peak hash is the hash of a filled node in the Merkle hash + tree, whose sibling is an incomplete node. Practically, suppose a + file is 7162 bytes long and a chunk is 1 kilobyte. That file fits + into 7 chunks, the tail chunk being 1018 bytes long. The Merkle hash + tree for that file is shown in Figure 4. Following the definition, + the peak hashes of this file are in nodes 3, 9, and 12, denoted with + an *. E denotes an empty hash. + + 7 + / \ + / \ + / \ + / \ + 3* 11 + / \ / \ + / \ / \ + / \ / \ + 1 5 9* 13 + / \ / \ / \ / \ + 0 2 4 6 8 10 12* 14 + + C0 C1 C2 C3 C4 C5 C6 E + = 1018 bytes + + Peak hashes in a Merkle hash tree + + Figure 4 + + Peak hashes can be explained by the binary representation of the + number of chunks the file occupies. The binary representation for 7 + is 111. Every "1" in binary representation of the file's packet + length corresponds to a peak hash. For this particular file, there + are indeed three peaks: nodes 3, 9, and 12. Therefore, the number of + peak hashes for a file is also, at most, logarithmic with its size. + + A peer knowing which nodes contain the peak hashes for the file can + therefore calculate the number of chunks it consists of; thus, it + gets an estimate of the file size (given all chunks but the last are + of a fixed size). Which nodes are the peaks can be securely + communicated from one (untrusted) peer, Peer A, to another peer, Peer + B, by letting Peer A send the peak hashes and their node IDs to Peer + + + + +Bakker, et al. Standards Track [Page 30] + +RFC 7574 PPSPP July 2015 + + + B. It can be shown that the root hash that Peer B obtained from a + trusted source is sufficient to verify that these are indeed the + right peak hashes, as follows. + + Lemma: Peak hashes can be checked against the root hash. + + Proof: (a) Any peak hash is always the left sibling. Otherwise, if + it is the right sibling, its left neighbor/sibling must also be a + filled node, because of the way chunks are laid out in the leaves, + which contradicts the definition of a peak hash. (b) For the + rightmost peak hash, its right sibling is zero. (c) For any peak + hash, the right sibling might be calculated using peak hashes to the + left and zeros for empty nodes. (d) Once the right sibling of the + leftmost peak hash is calculated, its parent might be calculated. (e) + Once that parent is calculated, we might trivially get to the root + hash by concatenating the hash with zeros and hashing it repeatedly. + + Informally, the Lemma might be expressed as follows: peak hashes + cover all data, so the remaining hashes are either trivial (zeros) or + might be calculated from peak hashes and zero hashes. + + Finally, once Peer B has obtained the number of chunks in the + content, it can determine the exact file size as follows. Given that + all chunks except the last are of a fixed size, Peer B just needs to + know the size of the last chunk. Knowing the number of chunks, Peer + B can calculate the node ID of the last chunk and download it. As + always, Peer B verifies the integrity of this chunk against the + trusted root hash. As there is only one chunk of data that leads to + a successful verification, the size of this chunk must be correct. + Peer B can then determine the exact file size as: + + (number of chunks -1) * fixed chunk size + size of last chunk + +5.6.2. Procedure + + A PPSPP implementation that wants to use automatic size detection + MUST operate as follows. When Peer A sends a DATA message for the + first time to Peer B, Peer A MUST first send all the peak hashes for + the content, in INTEGRITY messages, unless Peer B has already + signaled that it knows the peak hashes by having acknowledged any + chunk. If they are needed, the peak hashes MUST be sent as an extra + list of uncle hashes for the chunk, before the list of actual uncle + hashes of the chunk as described in Section 5.3. The receiver, Peer + B, MUST check the peak hashes against the root hash to determine the + approximate content size. To obtain the definite content size, Peer + B MUST download the last chunk of the content from any peer that + offers it. + + + + +Bakker, et al. Standards Track [Page 31] + +RFC 7574 PPSPP July 2015 + + + As an example, let's consider a 7162-byte file, which fits in 7 + chunks of 1 kilobyte, distributed by Peer A. Figure 4 shows the + relevant Merkle hash tree. Peer B, which only knows the root hash of + the file after successfully connecting to Peer A, requests the first + chunk of data, C0 in Figure 4. Peer A replies to Peer B by including + in the datagram the following messages in this specific order: first, + the three peak hashes of this particular file, the hashes of nodes 3, + 9, and 12; second, the uncle hashes of C0, followed by the DATA + message containing the actual content of C0. Upon receiving the peak + hashes, Peer B checks them against the root hash determining that the + file is 7 chunks long. To establish the exact size of the file, Peer + B needs to request and retrieve the last chunk containing data, C6 in + Figure 4. Once the last chunk has been retrieved and verified, Peer + B concludes that it is 1018 bytes long, hence determining that the + file is exactly 7162 bytes long. + +6. Live Streaming + + The set of messages defined above can be used for live streaming as + well. In a pull-based model, a live streaming injector can announce + the chunks it generates via HAVE messages, and peers can retrieve + them via REQUEST messages. Areas that need special attention are + content authentication and chunk addressing (to achieve an infinite + stream of chunks). + +6.1. Content Authentication + + For live streaming, PPSPP supports two methods for a peer to + authenticate the content it receives from another peer, called "Sign + All" and "Unified Merkle Tree". + + In the "Sign All" method, the live injector signs each chunk of + content using a private key. Upon receiving the chunk, peers check + the signature using the corresponding public key obtained from a + trusted source. Support for this method is OPTIONAL. + + In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash + Tree scheme for static content with signatures to unify the video-on- + demand and live streaming scenarios. The use of Merkle hash trees + reduces the number of signing and verification operations, hence + providing a similar signature amortization to the approach described + in [SIGMCAST]. If PPSPP operates over the Internet, the "Unified + Merkle Tree" method MUST be used. If the protocol operates in a + benign environment, the "Unified Merkle Tree" method MAY be used. So + this method is mandatory to implement. + + In both methods, the swarm ID consists of a public key encoded as in + a DNSSEC DNSKEY resource record without Base64 encoding [RFC4034]. + + + +Bakker, et al. Standards Track [Page 32] + +RFC 7574 PPSPP July 2015 + + + In particular, the swarm ID consists of a 1-byte Algorithm field that + identifies the public key's cryptographic algorithm and determines + the format of the Public Key field that follows. The value of this + Algorithm field is one of the values in the "Domain Name System + Security (DNSSEC) Algorithm Numbers" registry [IANADNSSECALGNUM]. + The RSASHA1 [RFC4034], RSASHA256 [RFC5702], ECDSAP256SHA256 and + ECDSAP384SHA384 [RFC6605] algorithms are mandatory to implement. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Algo Number(8)| ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ DNSSEC Public Key (variable) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +6.1.1. Sign All + + In the "Sign All" method, the live injector signs each chunk of + content using a private key and peers, upon receiving the chunk, + check the signature using the corresponding public key obtained from + a trusted source. In particular, in PPSPP, the swarm ID of the live + stream is that public key. + + A peer that wants to send a chunk of content creates a datagram that + MUST contain a SIGNED_INTEGRITY message with the chunk's signature, + followed by a DATA message with the actual chunk. If the + SIGNED_INTEGRITY message and DATA message cannot be contained into a + single datagram, because of a limitation on datagram size, the + SIGNED_INTEGRITY message MUST be sent first in a separate datagram. + The SIGNED_INTEGRITY message consists of the chunk specification, the + timestamp, and the digital signature. + + The digital signature algorithm that is used, is determined by the + Live Signature Algorithm protocol option, see Section 7.7. The + signature is computed over a concatenation of the on-the-wire + representation of the chunk specification, a 64-bit timestamp in NTP + Timestamp format [RFC5905], and the chunk, in that order. The + timestamp is the time signature that was made at the injector in UTC. + +6.1.2. Unified Merkle Tree + + In this method, the chunks of content are used as the basis for a + Merkle hash tree as for static content. However, because chunks are + continuously generated, this tree is not static, but dynamic. As a + result, the tree does not have a root hash, or, more precisely, it + has a transient root hash. Therefore, a public key serves as swarm + + + + +Bakker, et al. Standards Track [Page 33] + +RFC 7574 PPSPP July 2015 + + + ID of the content. It is used to digitally sign updates to the tree + allowing peers to expand it based on trusted information using the + following process. + +6.1.2.1. Signed Munro Hashes + + The live injector generates a number of chunks, denoted + NCHUNKS_PER_SIG, corresponding to fixed power of 2 + (NCHUNKS_PER_SIG>=2), which are added as new leaves to the existing + hash tree. As a result of this expansion, the hash tree contains a + new subtree that is NCHUNKS_PER_SIG chunks wide at the base. The + root of this new subtree is referred to as the munro of that subtree, + and its hash as the munro hash of the subtree, illustrated in + Figure 5. In this figure, node 5 is the new munro, labeled with a $ + sign. + + 3 + / \ + / \ + / \ + 1 5$ + / \ / \ + 0 2 4 6 + + Expanded live tree. With NCHUNKS_PER_SIG=2, node 5 is the munro for + the new subtree spanning 4 and 6. Node 1 is the munro for the + subtree spanning chunks 0 and 2, created in the previous iteration. + + Figure 5 + + Informally, the process now proceeds as follows. The injector signs + only the munro hash of the new subtree using its private key. Next, + the injector announces the existence of the new subtree to its peers + using HAVE messages. When a peer, in response to the HAVE messages, + requests a chunk from the new subtree, the injector first sends the + signed munro hash corresponding to the requested chunk. Afterwards, + similar to static content, the injector sends the uncle hashes + necessary to verify that chunk, as in Section 5.1. In particular, + the injector sends the uncle hashes necessary to verify the requested + chunk against the munro hash. This differs from static content, + where the verification takes places against the root hash. Finally, + the injector sends the actual chunk. + + + + + + + + + +Bakker, et al. Standards Track [Page 34] + +RFC 7574 PPSPP July 2015 + + + The receiving peer verifies the signature on the signed munro using + the swarm ID (a public key) and updates its hash tree. As the peer + now knows the munro hash is trusted, it can verify all chunks in the + subtree against this munro hash, using the accompanying uncle hashes + as in Section 5.1. + + To illustrate this procedure, lets consider the next iteration in the + process. The injector has generated the current tree shown in + Figure 5, and it is connected to several peers that currently have + the same tree and all posses chunks 0, 2, 4, and 6. When the + injector generates two new chunks, NCHUNKS_PER_SIG=2, the hash tree + expands as shown in Figure 6. The two new chunks, 8 and 10, extend + the tree on the right side, and to accommodate them, a new root is + created: node 7. As this tree is wider at the base than the actual + number of chunks, there are currently two empty leaves. The munro + node for the new subtree is 9, labeled with a $ sign. + + 7 + / \ + / \ + / \ + / \ + 3 11 + / \ / \ + / \ / \ + / \ / \ + 1 5 9$ 13 + / \ / \ / \ / \ + 0 2 4 6 8 10 E E + + Expanded live tree. With NCHUNKS_PER_SIG=2, node 9 is the munro of + the newly added subtree spanning chunks 8 and 10. + + Figure 6 + + The injector now needs to inform its peers of the updated tree, + communicating the addition of the new munro hash 9. Hence, it sends + a HAVE message with a chunk specification for nodes 8 + 10 to its + peers. As a response, Peer P requests the newly created chunk, e.g., + chunk 8, from the injector by sending a REQUEST message. In reply, + the injector sends the signed munro hash of node 9 as an INTEGRITY + message with the hash of node 9, and a SIGNED_INTEGRITY message with + the signature of the hash of node 9. These messages are followed by + an INTEGRITY message with the hash of node 10 and a DATA message with + chunk 8. + + + + + + +Bakker, et al. Standards Track [Page 35] + +RFC 7574 PPSPP July 2015 + + + Upon receipt, Peer P verifies the signature of the munro and expands + its view of the tree. Next, the peer computes the hash of chunk 8 + and combines it with the received hash of node 10, computing the + expected hash of node 9. He can then verify the content of chunk 8 + by comparing the computed hash of node 9 with the munro hash of the + same node he just received; hence, Peer P has successfully verified + the integrity of chunk 8. + + This procedure requires just one signing operation for every + NCHUNKS_PER_SIG chunks created, and one verification operation for + every NCHUNKS_PER_SIG received, making it much cheaper than "Sign + All". A receiving peer does additionally need to check one or more + hashes per chunk via the Merkle Hash Tree scheme, but this has less + hardware requirements than a signature verification for every chunk. + This approach is similar to signature amortization via Merkle Tree + Chaining [SIGMCAST]. The downside of this scheme is in an increased + latency. A peer cannot download the new chunks until the injector + has computed the signature and announced the subtree. A peer MUST + check the signature before forwarding the chunks to other peers + [POLLIVE]. + + The number of chunks per signature NCHUNKS_PER_SIG MUST be a fixed + power of 2 for simplicity. NCHUNKS_PER_SIG MUST be larger than 1 for + performance reasons. There are two related factors to consider when + choosing a value for NCHUNKS_PER_SIG. First, the allowed CPU load on + clients due to signature verifications, given the expected bitrate of + the stream. To achieve a low CPU load in a high bitrate stream, + NCHUNKS_PER_SIG should be high. Second, the effect on latency, which + increases when NCHUNKS_PER_SIG gets higher, as just discussed. Note + how the procedure does not preclude the use of variable-size chunks. + + This method of integrity verification provides an additional benefit. + If the system includes some peers that saved the complete broadcast, + as soon as the broadcast ends, the content is available as a video- + on-demand download using the now stabilized tree and the final root + hash as swarm identifier. Peers that saved all the chunks, can now + announce the root hash to the tracking infrastructure and instantly + seed the content. + +6.1.2.2. Munro Signature Calculation + + The digital signature algorithm used is determined by the Live + Signature Algorithm protocol option, see Section 7.7. The signature + is computed over a concatenation of the on-the-wire representation of + the chunk specification of the munro node (see Section 6.1.2.1), a + timestamp in 64-bit NTP Timestamp format [RFC5905], and the hash + associated with the munro node, in that order. The timestamp is the + time signature that was made at the injector in UTC. + + + +Bakker, et al. Standards Track [Page 36] + +RFC 7574 PPSPP July 2015 + + +6.1.2.3. Procedure + + Formally, the injector MUST NOT send a HAVE message for chunks in the + new subtree until it has computed the signed munro hash for that + subtree. + + When Peer B requests a chunk C from Peer A (either the injector or + another peer), and Peer A decides to reply, it must do so as follows. + First, Peer A MUST send an INTEGRITY message with the chunk + specification for the munro of chunk C and the munro's hash, followed + by a SIGNED_INTEGRITY message with the chunk specification for the + munro, timestamp, and its signature in a single datagram, unless Peer + B indicated earlier in the exchange that it already possess a chunk + with the same corresponding munro (by means of HAVE or ACK messages). + Following these two messages (if any), Peer A MUST send the necessary + missing uncles hashes needed for verifying the chunk against its + munro hash, and the chunk itself, as described in Section 5.4, + sharing datagrams if possible. + +6.1.2.4. Secure Tune In + + When a peer tunes in to a live stream, it has to determine what is + the last chunk the injector has generated. To facilitate this + process in the Unified Merkle Tree scheme, each peer shares its + knowledge about the injector's chunks with the others by exchanging + their latest signed munro hashes, as follows. + + Recall that, in PPSPP, when Peer A initiates a channel with Peer B, + Peer A sends a first datagram with a HANDSHAKE message, and Peer B + responds with a second datagram also containing a HANDSHAKE message + (see Section 3.1). When Peer A sends a third datagram to Peer B, and + it is received by Peer B, both peers know that the other is listening + on its stated transport address. Peer B is then allowed to send + heavy payload like DATA messages in the fourth datagram. Peer A can + already safely do that in the third datagram. + + In the Unified Merkle Tree scheme, Peer A MUST send its rightmost + signed munro hash to Peer B in the third datagram, and in any + subsequent datagrams to Peer B, until Peer B indicates that it + possess a chunk with the same corresponding munro or a more recent + munro (by means of a HAVE or ACK message). Peer B may already have + indicated this fact by means of HAVE messages in the second datagram. + Conversely, when Peer B sends the fourth datagram or any subsequent + datagram to Peer A, Peer B MUST send its rightmost signed munro hash, + unless Peer A indicated knowledge of it or more recent munros. The + rightmost signed munro hash of a peer is defined as the munro hash + signed by the injector of the rightmost subtree of width + NCHUNKS_PER_SIG chunks in the peer's Merkle hash tree. Peer A MUST + + + +Bakker, et al. Standards Track [Page 37] + +RFC 7574 PPSPP July 2015 + + + NOT send the signed munro hash in the first datagram of the HANDSHAKE + procedure and Peer B MUST NOT send it in the second datagram as it is + considered heavy payload. + + When a peer receives a SIGNED_INTEGRITY message with a signed munro + hash but the timestamp is too old, the peer MUST discard the message. + Otherwise, it SHOULD use the signed munro to update its hash tree and + pick a tune-in in the live stream. A peer may use the information + from multiple peers to pick the tune-in point. + +6.2. Forgetting Chunks + + As a live broadcast progresses, a peer may want to discard the chunks + that it already played out. Ideally, other peers should be aware of + this fact so that they will not try to request these chunks from this + peer. This could happen in scenarios where live streams may be + paused by viewers, or viewers are allowed to start late in a live + broadcast (e.g., start watching a broadcast at 20:35 when it actually + began at 20:30). + + PPSPP provides a simple solution for peers to stay up to date with + the chunk availability of a discarding peer. A discarding peer in a + live stream MUST enable the Live Discard Window protocol option, + specifying how many chunks/bytes it caches before the last chunk/byte + it advertised as being available (see Section 7.9). Its peers SHOULD + apply this number as a sliding window filter over the peer's chunk + availability as conveyed via its HAVE messages. + + Three factors are important when deciding for an appropriate value + for this option: the desired amount of playback buffer for peers, the + bitrate of the stream, and the available resources of the peer. + Consider the case of a fresh peer joining the stream. The size of + the discard window of the peers it connects to influences how much + data it can directly download to establish its prebuffer. If the + window is smaller than the desired buffer, the fresh peer has to wait + until the peers downloaded more of the stream before it can start + playback. As media buffers are generally specified in terms of a + number of seconds, the size of the discard window is also related to + the (average) bitrate of the stream. Finally, if a peer has few + resources to store chunks and metadata, it should choose a small + discard window. + +7. Protocol Options + + The HANDSHAKE message in PPSPP can contain the following protocol + options. Unless stated otherwise, a protocol option consists of an + 8-bit code followed by an 8-bit value. Larger values are all encoded + + + + +Bakker, et al. Standards Track [Page 38] + +RFC 7574 PPSPP July 2015 + + + big-endian. Each protocol option is explained in the following + subsections. The list of protocol options MUST be sorted on code + value (ascending) in a HANDSHAKE message. + + +--------+-------------------------------------+ + | Code | Description | + +--------+-------------------------------------+ + | 0 | Version | + | 1 | Minimum Version | + | 2 | Swarm Identifier | + | 3 | Content Integrity Protection Method | + | 4 | Merkle Hash Tree Function | + | 5 | Live Signature Algorithm | + | 6 | Chunk Addressing Method | + | 7 | Live Discard Window | + | 8 | Supported Messages | + | 9 | Chunk Size | + | 10-254 | Unassigned | + | 255 | End Option | + +--------+-------------------------------------+ + + Table 2: PPSPP Options + +7.1. End Option + + A peer MUST conclude the list of protocol options with the end + option. Subsequent octets should be considered protocol messages. + The code for the end option is 255, and unlike others, it has no + value octet, so the option's length is 1 octet. + + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |1 1 1 1 1 1 1 1| + +-+-+-+-+-+-+-+-+ + +7.2. Version + + A peer MUST include the maximum version of the PPSPP it supports as + the first protocol option in the list. The code for this option is + 0. Defined values are listed in Table 3. + + + + + + + + + + + +Bakker, et al. Standards Track [Page 39] + +RFC 7574 PPSPP July 2015 + + + +---------+----------------------------------------+ + | Version | Description | + +---------+----------------------------------------+ + | 0 | Reserved | + | 1 | Protocol as described in this document | + | 2-255 | Unassigned | + +---------+----------------------------------------+ + + Table 3: PPSPP Version Numbers + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0| Version (8) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +7.3. Minimum Version + + When a peer initiates the handshake, it MUST include the minimum + version of the PPSPP it supports in the list of protocol options, + following the min/max versioning scheme defined in [RFC6709], + Section 4.1, strategy 5. The code for this option is 1. Defined + values are listed in Table 3. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 1| Min. Ver. (8) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +7.4. Swarm Identifier + + When a peer initiates the handshake, it MUST include a single swarm + identifier option. If the peer is not the initiator, it MAY include + a swarm identifier option, as an end-to-end check. This option has + the following structure: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 1 0| Swarm ID Length (16) | ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Swarm Identifier (variable) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The Swarm ID Length field contains the length of the single Swarm + Identifier that follows in bytes. The Length field is 16 bits wide + to allow for large public keys as identifiers in live streaming. + + + +Bakker, et al. Standards Track [Page 40] + +RFC 7574 PPSPP July 2015 + + + Each PPSPP peer knows the IDs of the swarms it joins, so this + information can be immediately verified upon receipt. + +7.5. Content Integrity Protection Method + + A peer MUST include the content integrity method used by a swarm. + The code for this option is 3. Defined values are listed in Table 4. + + +--------+-------------------------+ + | Method | Description | + +--------+-------------------------+ + | 0 | No integrity protection | + | 1 | Merkle Hash Tree | + | 2 | Sign All | + | 3 | Unified Merkle Tree | + | 4-255 | Unassigned | + +--------+-------------------------+ + + Table 4: PPSPP Content Integrity Protection Methods + + The "Merkle Hash Tree" method is the default for static content, see + Section 5.1. "Sign All", and "Unified Merkle Tree" are for live + content, see Section 6.1, with "Unified Merkle Tree" being the + default. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 1 1| CIPM (8) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +7.6. Merkle Tree Hash Function + + When the content integrity protection method is "Merkle Hash Tree", + this option defining which hash function is used for the tree MUST be + included. The code for this option is 4. Defined values are listed + in Table 5 (see [FIPS180-4] for the function semantics). + + + + + + + + + + + + + + +Bakker, et al. Standards Track [Page 41] + +RFC 7574 PPSPP July 2015 + + + +----------+-------------+ + | Function | Description | + +----------+-------------+ + | 0 | SHA-1 | + | 1 | SHA-224 | + | 2 | SHA-256 | + | 3 | SHA-384 | + | 4 | SHA-512 | + | 5-255 | Unassigned | + +----------+-------------+ + + Table 5: PPSPP Merkle Hash Functions + + Implementations MUST support SHA-1 (see Section 12.5) and SHA-256. + SHA-256 is the default. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 0 0| MHF (8) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +7.7. Live Signature Algorithm + + When the content integrity protection method is "Sign All" or + "Unified Merkle Tree", this option MUST be defined. The code for + this option is 5. The 8-bit value of this option is one of the + values listed in the "Domain Name System Security (DNSSEC) Algorithm + Numbers" registry [IANADNSSECALGNUM]. The RSASHA1 [RFC4034], + RSASHA256 [RFC5702], ECDSAP256SHA256 and ECDSAP384SHA384 [RFC6605] + algorithms are mandatory to implement. Default is ECDSAP256SHA256. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 0 1| LSA (8) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +7.8. Chunk Addressing Method + + A peer MUST include the chunk addressing method it uses. The code + for this option is 6. Defined values are listed in Table 6. + + + + + + + + + +Bakker, et al. Standards Track [Page 42] + +RFC 7574 PPSPP July 2015 + + + +--------+---------------------+ + | Method | Description | + +--------+---------------------+ + | 0 | 32-bit bins | + | 1 | 64-bit byte ranges | + | 2 | 32-bit chunk ranges | + | 3 | 64-bit bins | + | 4 | 64-bit chunk ranges | + | 5-255 | Unassigned | + +--------+---------------------+ + + Table 6: PPSPP Chunk Addressing Methods + + Implementations MUST support "32-bit chunk ranges" and "64-bit chunk + ranges". Default is "32-bit chunk ranges". + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 1 0| CAM (8) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +7.9. Live Discard Window + + A peer in a live swarm MUST include the discard window it uses. The + code for this option is 7. The unit of the discard window depends on + the chunk addressing method used, see Table 6. For bins and chunk + ranges, it is a number of chunks; for byte ranges, it is a number of + bytes. Its data type is the same as for a bin, or one value in a + range specification. In other words, its value is a 32-bit or 64-bit + integer in big-endian format. If this option is used, the Chunk + Addressing Method MUST appear before it in the list. This option has + the following structure: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 1 1| Live Discard Window (32 or 64) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + A peer that does not, under normal circumstances, discard chunks MUST + set this option to the special value 0xFFFFFFFF (32-bit) or + 0xFFFFFFFFFFFFFFFF (64-bit). For example, peers that record a + complete broadcast to offer it directly as a static file after the + broadcast ends use these values (see Section 6.1.2). Section 6.2 + explains how to determine a value for this option. + + + +Bakker, et al. Standards Track [Page 43] + +RFC 7574 PPSPP July 2015 + + +7.10. Supported Messages + + Peers may support just a subset of the PPSPP messages. For example, + peers running over TCP may not accept ACK messages or peers used with + a centralized tracking infrastructure may not accept PEX messages. + For these reasons, peers who support only a proper subset of the + PPSPP messages MUST signal which subset they support by means of this + protocol option. The code for this option is 8. The value of this + option is a length octet (SupMsgLen) indicating the length, in bytes, + of the compressed bitmap that follows. + + The set of messages supported can be derived from the compressed + bitmap by padding it with bytes of value 0 until it is 256 bits in + length. Then, a 1 bit in the resulting bitmap at position X + (numbering left to right) corresponds to support for message type X, + see Table 7. In other words, to construct the compressed bitmap, + create a bitmap with a 1 for each message type supported and a 0 for + a message type that is not, store it as an array of bytes, and + truncate it to the last non-zero byte. An example of the first 16 + bits of the compressed bitmap for a peer supporting every message + except ACKs and PEXs is 11011001 11110000. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 0 0 0| SupMsgLen (8) | ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ Supported Messages Bitmap (variable, max 256) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +7.11. Chunk Size + + A peer in a swarm MUST include the chunk size the swarm uses. The + code for this option is 9. Its value is a 32-bit integer denoting + the size of the chunks in bytes in big-endian format. When variable + chunk sizes are used, this option MUST be set to the special value + 0xFFFFFFFF. Section 8.1 explains how content publishers can + determine a value for this option. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 0 0 1| Chunk Size (32) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ | + +-+-+-+-+-+-+-+-+ + + + + + +Bakker, et al. Standards Track [Page 44] + +RFC 7574 PPSPP July 2015 + + +8. UDP Encapsulation + + PPSPP implementations MUST use UDP as transport protocol and MUST use + LEDBAT for congestion control [RFC6817]. Using LEDBAT enables PPSPP + to serve the content after playback (seeding) without disrupting the + user who may have moved to different tasks that use its network + connection. Future PPSPP versions can also run over other transport + protocols or use different congestion control algorithms. + +8.1. Chunk Size + + In general, a UDP datagram containing PPSPP messages SHOULD fit + inside a single IP packet, so its maximum size depends on the MTU of + the network. If the UDP datagram does not fit, its chance of getting + lost in the network increases as the loss of a single fragment of the + datagram causes the loss of the complete datagram. + + The largest message in a PPSPP datagram is the DATA message carrying + a chunk of content. So the (maximum) size of a chunk to choose for a + particular swarm depends primarily on the expected MTU. The chunk + size should be chosen such that a chunk and its required INTEGRITY + messages can generally be carried inside a single datagram, following + the Atomic Datagram Principle (Section 5.3). Other considerations + are the hardware capabilities of the peers. Having large chunks and + therefore less chunks per megabyte of content reduces processing + costs. The chunk addressing schemes can all work with different + chunk sizes, see Section 4. + + The RECOMMENDED approach is to use fixed-size chunks of 1024 bytes, + as this size has a high likelihood of traveling end-to-end across the + Internet without any fragmentation. In particular, with this size, a + UDP datagram with a DATA message can be transmitted as a single IP + packet over an Ethernet network with 1500-byte frames. + + A PPSPP implementation MAY use a variant of the Packetization Layer + Path MTU Discovery (PLPMTUD), described in [RFC4821], for discovering + the optimal MTU between sender and destination. As in PLPMTUD, + progressively larger probing packets are used to detect the optimal + MTU for a given path. However, in PPSPP, probe packets SHOULD + contain actual messages, in particular, multiple DATA messages. By + using actual DATA messages as probe packets, the returning ACK + messages will confirm the probe delivery, effectively updating the + MTU estimate on both ends of the link. To be able to scale up probe + packets with sensible increments, a minimum chunk size of 512 bytes + SHOULD be used. Smaller chunk sizes lead to an inefficient protocol. + An implication is that PPSPP supports datagrams over IPv4 of 576 + bytes or more only. This variant is not mandatory to implement. + + + + +Bakker, et al. Standards Track [Page 45] + +RFC 7574 PPSPP July 2015 + + + The chunk size used for a particular swarm, or the fact that it is + variable, MUST be part of the swarm's metadata (which then minimally + consists of the swarm ID and the chunk nature and size). + +8.2. Datagrams and Messages + + When using UDP, the abstract datagram described above corresponds + directly to a UDP datagram. Most messages within a datagram have a + fixed length, which generally depends on the type of the message. + The first byte of a message denotes its type. The currently defined + types are: + + +----------+------------------+ + | Msg Type | Description | + +----------+------------------+ + | 0 | HANDSHAKE | + | 1 | DATA | + | 2 | ACK | + | 3 | HAVE | + | 4 | INTEGRITY | + | 5 | PEX_RESv4 | + | 6 | PEX_REQ | + | 7 | SIGNED_INTEGRITY | + | 8 | REQUEST | + | 9 | CANCEL | + | 10 | CHOKE | + | 11 | UNCHOKE | + | 12 | PEX_RESv6 | + | 13 | PEX_REScert | + | 14-254 | Unassigned | + | 255 | Reserved | + +----------+------------------+ + + Table 7: PPSPP Message Types + + Furthermore, integers are serialized in network (big-endian) byte + order. So, consider the example of a HAVE message (Section 3.2) + using bin chunk addressing. It has a message type of 0x03 and a + payload of a bin number, a 4-byte integer (say, 1); hence, its on- + the-wire representation for UDP can be written in hex as + "0300000001". + + All messages are idempotent or recognizable as duplicates. + Idempotent means that processing a message more than once does not + lead to a different state from if it was processed just once. In + particular, a peer MAY resend DATA, ACK, HAVE, INTEGRITY, PEX_*, + SIGNED_INTEGRITY, REQUEST, CANCEL, CHOKE, and UNCHOKE messages + without problems when loss is suspected. When a peer resends a + + + +Bakker, et al. Standards Track [Page 46] + +RFC 7574 PPSPP July 2015 + + + HANDSHAKE message, it can be recognized as duplicate by the receiver, + because it already recorded the first connection attempt, and be + dealt with. + +8.3. Channels + + As described in Section 3.11, PPSPP uses a multiplexing scheme, + called channels, to allow multiple swarms to use the same UDP port. + In the UDP encapsulation, each datagram from Peer A to Peer B is + prefixed with the channel ID allocated by Peer B. The peers learn + about each other's channel ID during the handshake as explained in + Section 3.1.1. A channel ID consists of 4 bytes and MUST be + generated following the requirements in [RFC4960] (Section 5.1.3). + +8.4. HANDSHAKE + + A channel is established with a handshake. To start a handshake, the + initiating peer needs to know the swarm metadata, defined in + Section 3.1 and the IP address and UDP port of a peer. A datagram + containing a HANDSHAKE message then looks as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination Channel ID (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0| Source Channel ID (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Protocol Options ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where: + + Destination Channel ID: + + If the datagram is sent by the initiating peer, then it MUST be + an all-zeros channel ID. + + If the datagram is sent by the responding peer, then it MUST + consist of the Source Channel ID from the sender's HANDSHAKE + message. + + The octet 0x00: The HANDSHAKE message type + + + + +Bakker, et al. Standards Track [Page 47] + +RFC 7574 PPSPP July 2015 + + + Source Channel ID: A locally unused channel ID + + Protocol Options: A list of protocol options encoding the swarm's + metadata, as defined in Section 7. + + A peer SHOULD explicitly close a channel by sending a HANDSHAKE + message that MUST contain an all zeros Source Channel ID and a list + of protocol options. The list MUST either be empty or contain the + maximum version number the sender supports, following the min/max + versioning scheme defined in [RFC6709], Section 4.1. + +8.5. HAVE + + A HAVE message (type 0x03) consists of a single chunk specification + that states that the sending peer has those chunks and successfully + checked their integrity. The single chunk specification represents a + consecutive range of verified chunks. A bin consists of a single + integer, and a chunk or byte range of two integers, of the width + specified by the Chunk Addressing protocol options, encoded big- + endian. + + A HAVE message using 32-bit chunk ranges as Chunk Addressing method: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 1 1| Start chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | End chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+ + + where the first octet is the HAVE message (0x03) followed by the + start chunk and the end chunk describing the chunk range. Note this + diagram shows a message and not a datagram, so it is not prefixed by + the destination Channel ID. This holds for all subsequent message + diagrams. + +8.6. DATA + + A DATA message (type 0x01) consists of a chunk specification, a + timestamp, and the actual chunk. In case a datagram contains one + DATA message, a sender MUST always put the DATA message in the tail + of the datagram. A datagram MAY contain multiple DATA messages when + the chunk size is fixed and when none of the DATA messages carry the + last chunk, if that is smaller than the chunk size. As LEDBAT + congestion control is used, a sender MUST include a timestamp, in + + + +Bakker, et al. Standards Track [Page 48] + +RFC 7574 PPSPP July 2015 + + + particular, a 64-bit integer representing the current system time + with microsecond accuracy. The timestamp MUST be included between + chunk specification and the actual chunk. + + A DATA message using 32-bit chunk ranges as Chunk Addressing method: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 1| Start chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | End chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp (64) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where the first octet is the DATA message (0x01) followed by the + start chunk and the end chunk describing the single chunk, the + timestamp, and the actual data. + +8.7. ACK + + An ACK message (type 0x02) acknowledges data that was received from + its addressee; to comply with the LEDBAT delay-based congestion + control, an ACK message consists of a chunk specification and a + timestamp representing a one-way delay sample. The one-way delay + sample is a 64-bit integer with microsecond accuracy, and it is + computed from the timestamp received from the previous DATA message + containing the chunk being acknowledged following the LEDBAT + specification. + + + + + + + + + + + + + +Bakker, et al. Standards Track [Page 49] + +RFC 7574 PPSPP July 2015 + + + An ACK message using 32-bit chunk ranges as Chunk Addressing method: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 1 0| Start chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | End chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | One-way delay sample (64) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+ + + where the first octet is the ACK message (0x02) followed by the start + chunk and the end chunk describing the chunk range and the one-way + delay sample. + +8.8. INTEGRITY + + An INTEGRITY message (type 0x04) consists of a chunk specification + and the cryptographic hash for the specified chunk or node. The type + and format of the hash depends on the protocol options. + + An INTEGRITY message using 32-bit chunk ranges as Chunk Addressing + method and a SHA-256 hash: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 0 0| Start chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | End chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Hash (256) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+ + + + + + + + +Bakker, et al. Standards Track [Page 50] + +RFC 7574 PPSPP July 2015 + + + where the first octet is the INTEGRITY message (0x04) followed by the + start chunk and the end chunk describing the chunk range and the + hash. + +8.9. SIGNED_INTEGRITY + + A SIGNED_INTEGRITY message (type 0x07) consists of a chunk + specification, a 64-bit timestamp in NTP Timestamp format [RFC5905] + and a digital signature encoded as a Signature field would be in an + RRSIG record in DNSSEC without the Base64 encoding [RFC4034]. The + signature algorithm is defined by the Live Signature Algorithm + protocol option, see Section 7.7. The plaintext over which the + signature is taken depends on the content integrity protection method + used, see Section 6.1. + + A SIGNED_INTEGRITY message using 32-bit chunk ranges as Chunk + Addressing method: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 1 1| Start chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | End chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Timestamp (64) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Signature ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where the first octet is the SIGNED_INTEGRITY message (0x07) followed + by the start chunk and the end chunk describing the chunk range, the + timestamp, and the Signature. + + The length of the digital signature can be derived from the Live + Signature Algorithm protocol option and the swarm ID as follows. The + first mandatory algorithms are RSASHA1 and RSASHA256. For those + algorithms, the swarm ID consists of a 1-byte Algorithm field + followed by an RSA public key stored as a tuple (exponent length, + exponent, modulus) [RFC3110]. Given the exponent length and the + length of the public key tuple in the swarm ID, the length of the + modulus in bytes can be calculated. This yields the length of the + + + +Bakker, et al. Standards Track [Page 51] + +RFC 7574 PPSPP July 2015 + + + signature, as in RSA this is the length of the modulus [HAC01]. The + other mandatory algorithms are ECDSAP256SHA256 and ECDSAP384SHA384 + [RFC6605]. For these algorithms, the length of the digital signature + is 64 and 96 bytes, respectively. + +8.10. REQUEST + + A REQUEST message (type 0x08) consists of a chunk specification for + the chunks the requester wants to download. + + A REQUEST message using 32-bit chunk ranges as Chunk Addressing + method: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 0 0 0| Start chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | End chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+ + + where the first octet is the REQUEST message (0x08) followed by the + start chunk and the end chunk describing the chunk range. + +8.11. CANCEL + + A CANCEL message (type 0x09) consists of a chunk specification for + the chunks the requester no longer is interested in. + + A CANCEL message using 32-bit chunk ranges as Chunk Addressing + method: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 0 0 1| Start chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | End chunk (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+ + + where the first octet is the CANCEL message (0x09) followed by the + start chunk and the end chunk describing the chunk range. + + + + + +Bakker, et al. Standards Track [Page 52] + +RFC 7574 PPSPP July 2015 + + +8.12. CHOKE and UNCHOKE + + Both CHOKE and UNCHOKE messages (types 0x0a and 0x0b, respectively) + carry no payload. + + A CHOKE message: + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |0 0 0 0 1 0 1 0| + +-+-+-+-+-+-+-+-+ + + where the first octet is the CHOKE message (0x0a). + + An UNCHOKE message: + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |0 0 0 0 1 0 1 1| + +-+-+-+-+-+-+-+-+ + + where the first octet is the UNCHOKE message (0x0b). + +8.13. PEX_REQ, PEX_RESv4, PEX_RESv6, and PEX_REScert + + A PEX_REQ (0x06) message has no payload. A PEX_RESv4 (0x05) message + consists of an IPv4 address in big-endian format followed by a UDP + port number in big-endian format. A PEX_RESv6 (0x0c) message + contains a 128-bit IPv6 address instead of an IPv4 one. If a PEX_REQ + message does not originate from a private, unique-local, link-local, + or multicast address [RFC1918] [RFC4193] [RFC4291], then the PEX_RES* + messages sent in reply MUST NOT contain such addresses. This is to + prevent leaking of internal addresses to external peers. + + A PEX_REQ message: + + 0 + 0 1 2 3 4 5 6 7 + +-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 1 0| + +-+-+-+-+-+-+-+-+ + + where the first octet is the PEX_REQ message (0x06). + + + + + + +Bakker, et al. Standards Track [Page 53] + +RFC 7574 PPSPP July 2015 + + + A PEX_RESv4 message: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 1 0 1| IPv4 Address (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Port (16) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where the first octet is the PEX_RESv4 message (0x05) followed by the + IPv4 address and the port number. + + A PEX_RESv6 message: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 1 0 0| | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Address (128) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | Port (16) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where the first octet is the PEX_RESv6 message (0x0c), followed by + the IPv6 address and the port number. + + A PEX_REScert (0x0d) message consists of a 16-bit integer in big- + endian specifying the size of the membership certificate that + follows, see Section 12.2.1. This membership certificate states that + Peer P at Time T is a member of Swarm S and is a X.509v3 certificate + [RFC5280] that is encoded using the ASN.1 distinguished encoding + rules (DER) [CCITT.X690.2002]. The certificate MUST contain a + "Subject Alternative Name" extension, marked as critical, of type + uniformResourceIdentifier. + + + + + + + + + + + +Bakker, et al. Standards Track [Page 54] + +RFC 7574 PPSPP July 2015 + + + A PEX_REScert message: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 1 0 1| Size of Memb. Cert. (16) | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Membership Certificate ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + where the first octet is the PEX_REScert message (0x0d) followed by + the size of the membership certificate and the membership + certificate. + + The URL contained in the name extension MUST follow the generic + syntax for URLs [RFC3986], where its scheme component is "file", the + host in the authority component is the DNS name or IP address of Peer + P, the port in the authority component is the port of Peer P, and the + path contains the swarm identifier for Swarm S, in hexadecimal form. + In particular, the preferred form of the swarm identifier is + xxyyzz..., where the 'x's, 'y's, and 'z's are 2 hexadecimal digits of + the 8-bit pieces of the identifier. The validity time of the + certificate is set with notBefore UTCTime set to T and notAfter + UTCTime set to T plus some expiry time defined by the issuer. An + example URL: + + file://192.0.2.0:6778/e5a12c7ad2d8fab33c699d1e198d66f79fa610c3 + +8.14. KEEPALIVE + + Keep alives do not have a message type on UDP. They are just simple + datagrams consisting of the 4-byte channel ID of the destination + only. + + A keep-alive datagram: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Channel ID (32) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + +Bakker, et al. Standards Track [Page 55] + +RFC 7574 PPSPP July 2015 + + +8.15. Flow and Congestion Control + + Explicit flow control is not required for PPSPP over UDP. In the + case of video on demand, the receiver explicitly requests the content + from peers, and is therefore in control of how much data is coming + towards it. In the case of live streaming, where a push model may be + used, the amount of data incoming is limited to the stream bitrate, + which the receiver must be able to process for a continuous playback. + Should, for any reason, the receiver get saturated with data, the + congestion control at the sender side will detect the situation and + adjust the sending rate accordingly. + + PPSPP over UDP can support different congestion control algorithms. + At present, it uses the LEDBAT congestion control algorithm + [RFC6817]. LEDBAT is a delay-based congestion control algorithm that + is used every day by millions of users as part of the uTP + transmission protocol of BitTorrent [LBT] [LCOMPL] and is suitable + for P2P streaming [PPSPPERF]. + + LEDBAT monitors the delay of the packets on the data path. It uses + the one-way delay variations to react early and limit the congestion + that the stream may induce in the network [RFC6817]. Using LEDBAT + enables PPSPP to serve the content to other interested peers after + the playback has finished (seeding), without disrupting the user. + After the playback, the user might move to different tasks that use + its network link, which are prioritized over PPSPP traffic. Hence, + the user does not notice the background PPSPP traffic, which in turn + increases the chances of seeding the content for a longer period of + time. + + The property of reacting early is not a problem in a peer-to-peer + system where multiple sources offer the content. Considering the + case of congestion near the sender, LEDBAT's early reaction impacts + the transmission of chunks to the receiver. However, for the + receiver, it is actually beneficial to learn early that the + transmission from a particular source is impacted. The receiver can + then choose to download time-critical chunks from other sources + during its chunk picking phase. + + If the bottleneck is near the receiver, the receiver is indeed + unlucky that transmissions from any source that runs through this + bottleneck will back off quite fast due to LEDBAT. However, for the + rest of the network (and the network operator), this is beneficial as + the video-streaming system will back off early enough and not + contribute too much to the congestion. + + + + + + +Bakker, et al. Standards Track [Page 56] + +RFC 7574 PPSPP July 2015 + + + The power of LEDBAT is that its behavior can be configured. In the + case of live streaming, a PPSPP deployer may want a more aggressive + behavior to ensure quality of service. In that case, LEDBAT can be + configured to be more aggressive. In particular, LEDBAT's queuing + target delay value (TARGET in [RFC6817]) and other parameters can be + adjusted such that it acts as aggressive as TCP (or even more). + Hence, LEDBAT is an algorithm that works for many scenarios in a + peer-to-peer context. + +8.16. Example of Operation + + We present a small example of communication between a leecher and a + seeder. The example presents the transmission of the file "Hello + World!", which fits within a 1024-byte chunk. For an easy + understanding, we use the message description names, as listed in + Table 7, and the protocol option names as listed in Table 2, rather + than the actual binary value. + + To do the handshake, the initiating peer sends a datagram that MUST + start with an all-zeros channel ID (0x00000000); followed by a + HANDSHAKE message, whose payload is a locally unused; a random + channel ID (in this case 0x00000001); and a list of protocol options. + Channel IDs MUST be randomly chosen, as described in Section 12.1. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 1| Version |0 0 0 0 0 0 0 1| Min Version | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 1| Swarm ID |0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 1 0 0 0 1 1 1 1 0 1 0 0 0 0 0 0 0 0 1 0 0 1 1 1 1 1 0 0 1 1 0| + ~ ..... ~ + |1 0 0 0 0 1 1 0 1 0 1 0 1 0 1 0 1 0 1 1 0 0 0 0 0 0 1 1 1 0 1 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cont. Int. |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Chunk Add. |0 0 0 0 0 0 1 0| Chunk Size |0 0 0 0 0 0 0 0~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| End | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + +Bakker, et al. Standards Track [Page 57] + +RFC 7574 PPSPP July 2015 + + + The protocol options are: + + Version: 1 + + Minimum supported Version: 1 + + Swarm Identifier: A 32-byte root hash (47a0...b03b) identifying + the content + + Content Integrity Protection Method: Merkle Hash Tree + + Merkle Tree Hash Function: SHA-256 + + Chunk Addressing Method: 32-bit chunk ranges + + Chunk Size: 1024 + + The receiving peer MAY respond, in which case the returned datagram + MUST consist of the channel ID from the sender's HANDSHAKE message + (0x00000001); a HANDSHAKE message, whose payload is a locally unused; + a random channel ID (0x00000008); and a list of protocol options; + followed by any other messages it wants to send. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 1 0 0 0| Version |0 0 0 0 0 0 0 1| Cont. Int. | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 1| Mer.H.Tree F. |0 0 0 0 0 0 1 0| Chunk Add. | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 1 0| Chunk Size |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0| End | HAVE | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + With the protocol options, the receiving peer agrees on speaking + protocol version 1, on using the Merkle Hash Tree as the Content + Integrity Protection Method, SHA-256 hash as the Merkle Tree Hash + Function, 32-bit chunk ranges as the Chunk Addressing Method, and + + + + +Bakker, et al. Standards Track [Page 58] + +RFC 7574 PPSPP July 2015 + + + Chunk Size 1024. Furthermore, it sends a HAVE message within the + same datagram, announcing that it has locally available the first + chunk of content. + + At this point, the initiator knows that the peer really responds; for + that purpose, channel IDs MUST be random enough to prevent easy + guessing. So, the third datagram of a handshake MAY already contain + some heavy payload. To minimize the number of initialization round + trips, the first two datagrams MAY also contain some minor payload, + e.g., the HAVE message. + + The initiating peer MAY send a request for the chunks of content it + wants to retrieve from the receiving peer, e.g., the first chunk + announced during the handshake. It always precedes the message with + the channel ID of the peer it is communicating with (0x00000008 in + our example), as described in Section 3.11. Furthermore, it MAY add + additional messages such as a PEX_REQ. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | REQUEST |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0| PEX_REQ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + When receiving the third datagram, both peers have proof that they + really talk to each other; the three-way handshake is complete. The + receiving peer responds to the request by sending a DATA message + containing the requested content. + + + + + + + + + + + + + + + + + +Bakker, et al. Standards Track [Page 59] + +RFC 7574 PPSPP July 2015 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DATA |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 1 1 0 1 0 0 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 1 0 0 0 0 0 1 1 0 0 0 0 0 0 0 1 0 1 1 0 1 1 1 1 1 0 1 1 0 1 1| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 1 0 0 0 1 0 0|0 1 0 0 1 0 0 0 0 1 1 0 0 1 0 1 0 1 1 0 1 1 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ..... ~ + |0 1 1 0 1 1 0 0 0 1 1 0 0 1 0 0 0 0 1 0 0 0 0 1 0 0 0 0 1 0 1 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The DATA message consists of: + + The 32-bit chunk range: 0,0 (the first chunk) + + The timestamp value: 0004e94180b7db44 + + The data: 48656c6c6f20776f726c6421 (the "Hello world!" file) + + Note that the above datagram does not include the INTEGRITY message, + as the entire content can fit into a single message; hence, the + initiating peer is able to verify it against the root hash. Also, in + this example, the peer does not respond to the PEX_REQ as it does not + know any third peer participating in the swarm. + + Upon receiving the requested data, the initiating peer responds with + an ACK message for the first chunk, containing a one-way delay sample + (100 ms). Furthermore, it also adds a HAVE message for the chunk. + + + + + + + + + + + + + + + +Bakker, et al. Standards Track [Page 60] + +RFC 7574 PPSPP July 2015 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACK |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 1 1 0 0 1 0 0| HAVE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + At this point, the initiating peer has successfully retrieved the + entire file. Then, it explicitly closes the connection by sending a + HANDSHAKE message that contains an all-zeros Source Channel ID. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | HANDSHAKE |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |0 0 0 0 0 0 0 0| End | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +9. Extensibility + +9.1. Chunk Picking Algorithms + + Chunk (or piece) picking entirely depends on the receiving peer. The + sending peer is made aware of preferred chunks by the means of + REQUEST messages. In some (live) scenarios, it may be beneficial to + allow the sender to ignore those hints and send unrequested data. + + The chunk picking algorithm is external to the PPSPP and will + generally be a pluggable policy that uses the mechanisms provided by + PPSPP. The algorithm will handle the choices made by the user + + + + + +Bakker, et al. Standards Track [Page 61] + +RFC 7574 PPSPP July 2015 + + + consuming the content, such as seeking or switching audio tracks or + subtitles. Example policies for P2P streaming can be found in + [BITOS], and [EPLIVEPERF]. + +9.2. Reciprocity Algorithms + + The role of reciprocity algorithms in peer-to-peer systems is to + promote client contribution and prevent freeriding. A peer is said + to be freeriding if it only downloads content but never uploads to + others. Examples of reciprocity algorithms are tit-for-tat as used + in BitTorrent [TIT4TAT] and Give-to-Get [GIVE2GET]. In PPSPP, + reciprocity enforcement is the sole responsibility of the sending + peer. + +10. IANA Considerations + + IANA has created a new top-level registry called "Peer-to-Peer + Streaming Peer Protocol (PPSPP)", which hosts the six new sub- + registries defined below for the extensibility of the protocol. For + all registries, assignments consist of a name and its associated + value. Also, for all registries, the "Unassigned" ranges designated + are governed by the policy "IETF Review" as described in [RFC5226]. + +10.1. PPSPP Message Type Registry + + The registry name is "PPSPP Message Type Registry". Values are + integers in the range 0-255, with initial assignments and + reservations given in Table 7. + +10.2. PPSPP Option Registry + + The registry name is "PPSPP Option Registry". Values are integers in + the range 0-255, with initial assignments and reservations given in + Table 2. + +10.3. PPSPP Version Number Registry + + The registry name is "PPSPP Version Number Registry". Values are + integers in the range 0-255, with initial assignments and + reservations given in Table 3. + +10.4. PPSPP Content Integrity Protection Method Registry + + The registry name is "PPSPP Content Integrity Protection Method + Registry". Values are integers in the range 0-255, with initial + assignments and reservations given in Table 4. + + + + + +Bakker, et al. Standards Track [Page 62] + +RFC 7574 PPSPP July 2015 + + +10.5. PPSPP Merkle Hash Tree Function Registry + + The registry name is "PPSPP Merkle Hash Tree Function Registry". + Values are integers in the range 0-255, with initial assignments and + reservations given in Table 5. + +10.6. PPSPP Chunk Addressing Method Registry + + The registry name is "PPSPP Chunk Addressing Method Registry". + Values are integers in the range 0-255, with initial assignments and + reservations given in Table 6. + +11. Manageability Considerations + + This section presents operations and management considerations + following the checklist in [RFC5706], Appendix A. + + In this section, "PPSPP client" is defined as a PPSPP peer acting on + behalf of an end user which may not yet have a copy of the content, + and "PPSPP server" as a PPSPP peer that provides the initial copies + of the content to the swarm on behalf of a content provider. + +11.1. Operations + +11.1.1. Installation and Initial Setup + + A content provider wishing to use PPSPP to distribute content should + set up at least one PPSPP server. PPSPP servers need to have access + to either some static content or some live audio/video sources. To + provide flexibility for implementors, this configuration process is + not standardized. The output of this process will be a list of + metadata records, one for each swarm. A metadata record consists of + the swarm ID, the chunk size used, the chunk addressing method used, + the content integrity protection method used, and the Merkle hash + tree function used (if applicable). If automatic content size + detection (see Section 5.6) is not used, the content length is also + part of the metadata record for static content. Note the swarm ID + already contains the Live Signature Algorithm used, in case of a live + stream. + + In addition, a content provider should set up a tracking facility for + the content by configuring, for example, a peer-to-peer streaming + protocol tracker [PPSP-TP] or a Distributed Hash Table. The output + of the latter process is a list of transport addresses for the + tracking facility. + + + + + + +Bakker, et al. Standards Track [Page 63] + +RFC 7574 PPSPP July 2015 + + + The list of metadata records of available content, and transport + address for the tracking facility, can be distributed to users in + various ways. Typically, they will be published on a website as + links. When a user clicks such a link, the PPSPP client is launched, + either as a standalone application or by invoking the browser's + internal PPSPP protocol handler, as exemplified in Section 2. The + clients use the tracking facility to obtain the transport address of + the PPSPP server(s) and other peers from the swarm, executing the + peer protocol to retrieve and redistribute the content. The format + of the PPSPP URLs should be defined in an extension document. The + default protocol options should be exploited to keep the URLs small. + + The minimal information a tracking facility must return when queried + for a list of peers for a swarm is as follows. Assuming the + communication between tracking facility and requester is protected, + the facility must at least return for each peer in the list its IP + address, transport protocol identifier (i.e., UDP), and transport + protocol port number. + +11.1.2. Migration Path + + This document does not detail a migration path since there is no + previous standard protocol providing similar functionality. + +11.1.3. Requirements on Other Protocols and Functional Components + + When using the peer-to-peer streaming protocol tracker, PPSPP + requires a specific behavior from this protocol for security reasons, + as detailed in Section 12.2. + +11.1.4. Impact on Network Operation + + PPSPP is a peer-to-peer protocol that takes advantage of the fact + that content is available from multiple sources to improve + robustness, scalability, and performance. At the same time, poor + choices in determining which exact sources to use can lead to bad + experience for the end user and high costs for network operators. + Hence, PPSPP can benefit from the ALTO protocol to steer peer + selection, as described in Section 3.10.1. + + + + + + + + + + + + +Bakker, et al. Standards Track [Page 64] + +RFC 7574 PPSPP July 2015 + + +11.1.5. Verifying Correct Operation + + PPSPP is operating correctly when all peers obtain the desired + content on time. Therefore, the PPSPP client is the ideal location + to verify the protocol's correct operation. However, it is not + feasible to mandate logging the behavior of PPSPP peers in all + implementations and deployments, for example, due to privacy reasons. + There are two alternative options: + + o Monitoring the PPSPP servers initially providing the content, + using standard metrics such as bandwidth usage, peer connections, + and activity, can help identify trouble, see next section and + [RFC2564]. + + o The tracker protocol [PPSP-TP] may be used to gather information + about all peers in a swarm, to obtain a global view of operation, + according to PPSP.OAM.REQ-3 in [RFC6972]. + + Basic operation of the protocol can be easily verified when a tracker + and swarm metadata are known by starting a PPSPP download. Deep + packet inspection for DATA and ACK messages help to establish that + actual content transfer is happening and that the chunk availability + signaling and integrity checking are working. + +11.1.6. Configuration + + Table 8 shows the PPSPP parameters, their defaults, and where the + parameter is defined. For parameters that have no default, the table + row contains the word "var" and refers to the section discussing the + considerations to make when choosing a value. + + + + + + + + + + + + + + + + + + + + + +Bakker, et al. Standards Track [Page 65] + +RFC 7574 PPSPP July 2015 + + + +-------------------------+-----------------------+-----------------+ + | Name | Default | Definition | + +-------------------------+-----------------------+-----------------+ + | Chunk Size | var, 1024 bytes | Section 8.1 | + | | recommended | | + | | | | + | Static Content | 1 (Merkle Hash Tree) | Section 7.5 | + | Integrity Protection | | | + | Method | | | + | | | | + | Live Content Integrity | 3 (Unified Merkle | Section 7.5 | + | Protection Method | Tree) | | + | | | | + | Merkle Hash Tree | 2 (SHA-256) | Section 7.6 | + | Function | | | + | | | | + | Live Signature | 13 (ECDSAP256SHA256) | Section 7.7 | + | Algorithm | | | + | | | | + | Chunk Addressing Method | 2 (32-bit chunk | Section 7.8 | + | | ranges) | | + | | | | + | Live Discard Window | var | Section 6.2, | + | | | Section 7.9 | + | | | | + | NCHUNKS_PER_SIG | var | Section 6.1.2.1 | + | | | | + | Dead peer detection | No reply in 3 minutes | Section 3.12 | + | | + 3 datagrams | | + +-------------------------+-----------------------+-----------------+ + + Table 8: PPSPP Defaults + +11.2. Management Considerations + + The management considerations for PPSPP are very similar to other + protocols that are used for large-scale content distribution, in + particular HTTP. How does one manage large numbers of servers? How + does one push new content out to a server farm and allows staged + releases? How are faults detected and how are servers and end-user + performance measured? As standard solutions to these challenges are + still being developed, this section cannot provide a definitive + recommendation on how PPSPP should be managed. Hence, it describes + the standard solutions available at this time and assumes a future + extension document will provide more complete guidelines. + + + + + + +Bakker, et al. Standards Track [Page 66] + +RFC 7574 PPSPP July 2015 + + +11.2.1. Management Interoperability and Information + + As just stated, PPSPP servers providing initial copies of the content + are akin to WWW and FTP servers. They can also be deployed in large + numbers and thus can benefit from standard management facilities. + Therefore, PPSPP servers may implement an SNMP management interface + based on the APPLICATION-MIB [RFC2564], where the file object can be + used to report on swarms. + + What is missing is the ability to remove or rate limit specific PPSPP + swarms on a server. This corresponds to removing or limiting + specific virtual servers on a web server. In other words, as + multiple pieces of content (swarms, virtual WWW servers) are + multiplexed onto a single server process, more fine-grained + management of that process is required. This functionality is + currently missing. + + Logging is an important functionality for PPSPP servers and, + depending on the deployment, PPSPP clients. Logging should be done + via syslog [RFC5424]. + +11.2.2. Fault Management + + The facilities for verifying correct operation and server management + (just discussed) appear sufficient for PPSPP fault monitoring. This + can be supplemented with host resource [RFC2790] and UDP/IP network + monitoring [RFC4113], as PPSPP server failures can generally be + attributed directly to conditions on the host or network. + + Since PPSPP has been designed to work in a hostile environment, many + benign faults will be handled by the mechanisms used for managing + attacks. For example, when a malfunctioning peer starts sending the + wrong chunks, this is detected by the content integrity protection + mechanism and another source is sought. + +11.2.3. Configuration Management + + Large-scale deployments may benefit from a standard way of + replicating a new piece of content on a set of initial PPSPP servers. + This functionality may need to include controlled releasing, such + that content becomes available only at a specific point in time + (e.g., the release of a movie trailer). This functionality could be + provided via NETCONF [RFC6241], to enable atomic configuration + updates over a set of servers. Uploading the new content could be + one configuration change, making the content available for download + by the public another. + + + + + +Bakker, et al. Standards Track [Page 67] + +RFC 7574 PPSPP July 2015 + + +11.2.4. Accounting Management + + Content providers may offer PPSPP hosting for different customers and + will want to bill these customers, for example, based on bandwidth + usage. This situation is a common accounting scenario, similar to + billing per virtual server for web servers. PPSPP can therefore + benefit from general standardization efforts in this area [RFC2975] + when they come to fruition. + +11.2.5. Performance Management + + Depending on the deployment scenarios, the application performance + measurement facilities of [RFC3729] and associated [RFC4150] can be + used with PPSPP. + + In addition, when the PPSPP tracker protocol is used, it provides a + built-in, application-level, performance measurement infrastructure + for different metrics. See PPSP.OAM.REQ-3 in [RFC6972]. + +11.2.6. Security Management + + Malicious peers should ideally be locked out long term. This is + primarily for performance reasons, as the protocol is robust against + attacks (see next section). Section 12.7 describes a procedure for + long-term exclusion. + +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. + + + + + +Bakker, et al. Standards Track [Page 68] + +RFC 7574 PPSPP July 2015 + + + 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 + + + + +Bakker, et al. Standards Track [Page 69] + +RFC 7574 PPSPP July 2015 + + + 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. + + + + +Bakker, et al. Standards Track [Page 70] + +RFC 7574 PPSPP July 2015 + + +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]. + + + + + + + +Bakker, et al. Standards Track [Page 71] + +RFC 7574 PPSPP July 2015 + + + 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. + + + +Bakker, et al. Standards Track [Page 72] + +RFC 7574 PPSPP July 2015 + + + 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]. + + + + + + +Bakker, et al. Standards Track [Page 73] + +RFC 7574 PPSPP July 2015 + + +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). + + + + +Bakker, et al. Standards Track [Page 74] + +RFC 7574 PPSPP July 2015 + + +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. + + + + +Bakker, et al. Standards Track [Page 75] + +RFC 7574 PPSPP July 2015 + + + 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. + + + + + +Bakker, et al. Standards Track [Page 76] + +RFC 7574 PPSPP July 2015 + + +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. + + + +Bakker, et al. Standards Track [Page 77] + +RFC 7574 PPSPP July 2015 + + +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>. + + + + + + +Bakker, et al. Standards Track [Page 78] + +RFC 7574 PPSPP July 2015 + + + [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. + + + + + + +Bakker, et al. Standards Track [Page 79] + +RFC 7574 PPSPP July 2015 + + + [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. + + + + + + + +Bakker, et al. Standards Track [Page 80] + +RFC 7574 PPSPP July 2015 + + + [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. + + + + + + + + +Bakker, et al. Standards Track [Page 81] + +RFC 7574 PPSPP July 2015 + + + [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>. + + + + + +Bakker, et al. Standards Track [Page 82] + +RFC 7574 PPSPP July 2015 + + + [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>. + + + + + +Bakker, et al. Standards Track [Page 83] + +RFC 7574 PPSPP July 2015 + + + [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. + + + + + + +Bakker, et al. Standards Track [Page 84] + +RFC 7574 PPSPP July 2015 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + +Bakker, et al. Standards Track [Page 85] + |