12.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 to detect faults and how to measure servers and end-user performance? 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.

12.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. PPSPP servers may therefore 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 limit 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].

12.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.

12.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.

12.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.

12.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 [RFC6972] (requirement PPSP.OAM.REQ-3).

12.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 13.7 describes a procedure for long-term exclusion.

13. Security Considerations

As any other network protocol, the 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.

13.1. Security of the Handshake Procedure

Borrowing from the analysis in [RFC5971], the PPSP peer protocol may be attacked with 3 types of denial-of-service attacks:

1. DOS amplification attack: attackers try to use a PPSPP peer to generate more traffic to a victim.
2. DOS flood attack: attackers try to deny service to other peers by allocating lots of state at a PPSPP peer.
3. Disrupt service to an individual peer: attackers send bogus e.g. REQUEST and HAVE messages appearing to come from victim peer A to the peers B1..Bn serving that peer. This causes 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] (Sec. 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 0s. 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 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 A sends may already contain heavy payload, i.e., a chunk. This next datagram to B will be prefixed with the chanB channel ID. When 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] (Sec. 5.1)).

A->B: chanB + HAVE + DATA + ...

13.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 B pretending to be A now need to intercept the message from B to A to get 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.

13.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 A included some HAVE messages, B may add a chunk availability map to A's state. In addition, B may request some chunks from A in the second datagram, and 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 SCTP [RFC4960] (Sec. 5.1) is quicker response time for the user. In the SCTP procedure, peer 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 shorter in PPSPP between starting the video stream and seeing the first images.

13.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 B assigned to A, chanB. Furthermore, attacker T would need to be able to spoof e.g. REQUEST and HAVE messages from A to cause B to send heavy DATA messages to A, or prevent 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.

13.2. Secure Peer Address Exchange

As described in Section 3.10, a peer A can send Peer-Exchange messages PEX_RES to a 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 anymore. 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,B2,...,BN and 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 A's behavior. E.g. when 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.

13.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 A can check the certificate for a valid signature, the right swarm and liveliness and only then consider contacting B. These swarm-membership certificates correspond to signed node descriptors in secure decentralized peer sampling services [SPS].

Several designs are possible for the security environment for these membership certificates. That is, there are different designs possible for who signs the membership certificates and how public keys are distributed. As an example, we describe a design where the PPSP tracker acts as certification authority.

13.2.2. Example: Tracker as Certification Authority

A 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 A.

Peer A then includes this certificate when it sends a PEX_REScert to peer B. Receiver B verifies it against the tracker public key. This tracker public key should be part of the swarm's metadata, which B received from a trusted source. Subsequently, peer B can send the member certificate of 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 T sends. To counter this, A SHOULD check a few of the certificates sent and discard the rest if they are defective.

The same membership certificates described above can be registered in a Distributed Hash Table that has been secured against the well-known DHT specific attacks [SECDHTS].

Note that this scheme does not work for peers behind a symmetric Network Address Translator, but neither does normal tracker registration.

13.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 B with the tracker, and many peers joining the swarm will contact 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 PPSP tracker protocol specification, 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 is 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, let 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, A can contact the tracker to find new candidates.

13.3. Support for Closed Swarms ([RFC6972] PPSP.SEC.REQ-1)

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 [I-D.gabrijelcic-ppsp-ecs].

13.4. Confidentiality of Streamed Content ([RFC6972] PPSP.SEC.REQ-1)

No extra mechanism is needed to support confidentiality in PPSPP. A content publisher wishing confidentiality should just distribute content in cyphertext / DRM-ed format. 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, or by DTLS [RFC6347] or 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], Sec. 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 DF-bit. Alternatively, the content publisher can decide to use smaller chunks and transmit multiple in the same datagram when the MTU allows.

13.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 sized 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.

13.6. Limit Potential Damage and Resource Exhaustion by Bad or Broken Peers ([RFC6972] PPSP.SEC.REQ-2)

In this section an analysis is given of the potential damage a malicious peer can do with each message in the protocol, and how it is prevented by the protocol (implementation).

13.6.1. HANDSHAKE

• Secured against DoS amplification attacks as described in Section 13.1.
• Threat HS.1: An Eclipse attack where peers T1..Tn fill all connection slots of A by initiating the connection to A.
  
  Solution: Peer A must not let other peers fill all its available connection slots, i.e., A must initiate connections itself too, to prevent isolation.

13.6.2. HAVE

• Threat HAVE.1: Malicious peer T can claim to have content which it hasn't. Subsequently T won't respond to requests.
  
  Solution: peer A will consider T to be a slow peer and not ask it again.
• 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.

13.6.3. DATA

• Threat DATA.1: peer T sending bogus chunks.
  
  Solution: The content integrity protection schemes defend against this.
• Threat DATA.2: peer T sends peer A unrequested chunks.
  
  To protect against this threat we need network-level DoS prevention.

13.6.4. ACK

• Threat ACK.1: peer T acknowledges wrong chunks.
  
  Solution: peer A will detect inconsistencies with the data it sent to T.
• Threat ACK.2: peer T modifies timestamp in ACK to peer A used for time-based congestion control.
  
  Solution: In theory, by decreasing the timestamp peer T could fake there is no congestion when in fact there is, causing 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.

13.6.5. INTEGRITY and SIGNED_INTEGRITY

• 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 A will stop asking T because of the atomic datagram principle and the content integrity protection. Subsequent unsolicited traffic from T will be ignored.
• 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 T will be ignored.

13.6.6. REQUEST

• Threat REQUEST.1: peer T could request lots from A, leaving 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.

13.6.7. CANCEL

• 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.

13.6.8. CHOKE

• Threat CHOKE.1: peer T sends REQUEST messages after peer A sent B a CHOKE message.
  
  Solution: peer A will just discard the unwanted REQUESTs and resend the CHOKE, assuming it got lost.

13.6.9. UNCHOKE

• 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.
• 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 T to be a slow peer and not ask it again.

13.6.10. PEX_RES

• Secured against amplification and Eclipse attacks as described in Section 13.2.

13.6.11. Unsolicited Messages in General

• Threat: peer T could send a spoofed PEX_REQ or REQUEST from peer B to peer A, causing A to send a PEX_RES/DATA to B.
  
  Solution: the message from peer T won't be accepted unless T does a handshake first, in which case the reply goes to T, not victim B.

13.7. Exclude Bad or Broken Peers ([RFC6972] PPSP.SEC.REQ-2)

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.

14. References

14.1. Normative References

14.2. Informative References

Appendix A. Revision History

-00 2011-12-19 Initial version.

-01 2012-01-30 Minor text revision:

• Changed heading to "A. Bakker"
• Changed title to *Peer* Protocol, and abbreviation PPSPP.
• Replaced swift with PPSPP.
• Removed Sec. 6.4. "HTTP (as PPSP)".
• Renamed Sec. 8.4. to "Chunk Picking Algorithms".
• Resolved Ticket #3: Removed sentence about random set of peers.
• Resolved Ticket #6: Added clarification to "Chunk Picking Algorithms" section.
• Resolved Ticket #11: Added Sec. 3.12 on Storage Independence
• Resolved Ticket #14: Added clarification to "Automatic Size Detection" section.
• Resolved Ticket #15: Operation section now states it shows example behaviour for a specific set of policies and schemes.
• Resolved Ticket #30: Explained why multiple REQUESTs in one datagram.
• Resolved Ticket #31: Renamed PEX_ADD message to PEX_RES.
• Resolved Ticket #32: Renamed Sec 3.8. to "Keep Alive Signaling", and updated explanation.
• Resolved Ticket #33: Explained NAT hole punching via only PPSPP messages.
• Resolved Ticket #34: Added section about limited overhead of the Merkle hash tree scheme.

-02 2012-04-17 Major revision

• Allow different chunk addressing and content integrity protection schemes (ticket #13):
• Added chunk ID, chunk specification, chunk addressing scheme, etc. to terminology.
• Created new Sections 4 and 5 discussing chunk addressing and content integrity protection schemes, respectively and moved relevant sections on bin numbering and Merkle hash trees there.
• Renamed Section 4 to "Merkle Hash Trees and The Automatic Detection of Content Size".
• Reformulated automatic size detection in terms of nodes, not bins.
• Extended HANDSHAKE message to carry protocol options and created Section 8 on Protocol options. VERSION and MSGTYPE_RCVD messages replaced with protocol options.
• Renamed HASH message to INTEGRITY.
• Renamed HINT to REQUEST.
• Added description of chunk addressing via (start,end) ranges.
• Resolved Ticket #26: Extended "Security Considerations" with section on the handshake procedure.
• Resolved Ticket #17: Defined recently as "in last 60 seconds" in PEX.
• Resolved Ticket #20: Extended "Security Considerations" with design to make Peer Address Exchange more secure.
• Resolved Ticket #38+39 / PPSP.SEC.REQ-2+3: Extended "Security Considerations" with a section on confidentiality of content.
• Resolved Ticket #40+42 / PPSP.SEC.REQ-4+6: Extended "Security Considerations" with a per-message analysis of threats and how PPSPP is protected from them.
• Progressed Ticket #41 / PPSP.SEC.REQ-5: Extended "Security Considerations" with a section on possible ways of excluding bad or broken peers from the system.
• Moved Rationale to Appendix.
• Resolved Ticket #43: Updated Live Streaming section to include "Sign All" content authentication, and reference to [SIGMCAST] following discussion with Fabio Picconi.
• Resolved Ticket #12: Added a CANCEL message to cancel REQUESTs for the same data that were sent to multiple peers at the same time in time-critical situations.

-03 2012-10-22 Major revision

• Updated Abstract and Introduction, removing download case.
• Resolved Ticket #4: Added explicit CHOKE/UNCHOKE messages.
• Removed directory lists unused in streaming.
• Resolved Ticket #22, #23, #28: Failure behaviour, error codes and dealing with peer crashes.
• Resolved Ticket #13: Chunk ranges are the default chunk addressing scheme that all peers MUST support.
• Added a section on compatibility between chunk addressing schemes.
• Expanded the explanation of Unified Merkle Trees as a method for content integrity protection for live streams.
• Added a section on forgetting chunks in live streaming.
• Added "End" option to protocol options and corrected bugs in UDP encapsulation, following Karl Knutsson's comments.
• Added SHA-2 support for Merkle Hash functions.
• Added content integrity protection methods for live streaming to the relevant protocol option.
• Added a Live Signature Algorithm protocol option.
• Resolved Ticket #24+27: The choice for UDP + LEDBAT as transport has now been reflected in the draft. TCP and RTP encapsulations have been removed.
• Superfluous parts of Section 10 on extensibility have been removed.
• Removed appendix with Rationale.
• Resolved Ticket #21+25: PPSPP currently uses LEDBAT and the DATA and ACK messages now contain the time fields it requires. Should other congestion control algorithms be supported in the future, a protocol option will be added.

-04 2012-11-07 Minor revision

• Corrected typos.
• Added empty protocol option list when HANDSHAKE is used for explicitly closing a channel in the UDP encapsulation.
• Corrected definition of a range chunk specification to be a single (start,end) pair. To send multiple disjunct ranges multiple messages should be used.
• Clarified that in a range chunk specification the end is inclusive. I.e., [start,end] not [start,end)
• Added PEX_REScert message to carry a membership certificate. Renamed PEX_RES to PEX_RESv4.
• Added a guideline about private and link-local addresses in PEX_RES messages.
• Defined the format of the public key that is used as swarm ID in live streaming.
• Clarified that a HANDSHAKE message must be the first message in a datagram.
• Clarified sending INTEGRITY messages ahead in a separate datagram if not all necessary hashes that still need to be sent and the chunk fit into a single datagram. Defined an order for the INTEGRITY messages.
• Clarified rare case of sending multiple DATA messages in one datagram.
• Clarified UDP datagrams carrying PPSPP should adhere to the network's MTU to avoid IP fragmentation.
• Defined value for version protocol option.
• Added small clarifications and corrected typos.
• Extended versioning scheme to Min/max versioning scheme defined in [RFC6709], Section 4.1, following Riccardo Bernardini's suggestion.
• Processed comments on unclear phrasing from Riccardo Bernardini.
• Added a guideline on when to declare a peer dead.
• Made sure all essential references are listed as Normative references following RFC3967.

-05 2013-01-23 Minor revision

• Corrected category to Standards Track.
• Clarified that swarm identifier is a required protocol option in an initiating HANDSHAKE in the UDP encapsulation.
• Added IANA considerations and tablised name spaces for registry definition.

-06 2013-02-11 Minor revision

• Updated "Overall Operation" to have more context (HTML5 video).
• Clarified wording on PEX_REQ.
• Clarified wording on SIGNED_INTEGRITY.
• Added a reference on how ALTO can be used with PPSPP.
• Added Manageability Consideration section following RFC5706.
• Clarified that implementations SHOULD implement the "Unified Merkle Tree" content integrity protection method for live, and MAY implement "Sign All".
• Made SHA1 hash function mandatory-to-implement as Merkle Tree Hash function and explained the security considerations.
• Made RSA/SHA1 mandatory-to-implement as Live Signature Algorithm for integrity protection while live streaming.
• Clarified that implementations MUST implement addressing via 32-bit chunk ranges.
• Made LEDBAT an Informational reference to prevent a so-called "down ref".
• Updated reference to PPSP problem statement and requirements document.
• Used kibibyte unit in formal sections.

-07 2013-06-19 Revision following AD Review

• Quoting the AD review by Martin Stiemerling: ***High-level issues:
• 1) Merkle Hash Trees I have found the document very confusing on whether Merkle Hash Trees (MHTs) and the for the MHT required bin numbering scheme are now optional or mandatory. Parts of the draft make the impression that either of them or both or optional (mainly in the beginning of the document), while Section 5 and later Sections are relying heavily on MHTs. My naive reading of the current draft is that you could rely on start-end ranges for chunk addressing and MHTs for content protection. However, I do know that this combination is not working. If MHTs are really optional, including the bin numbering, the document should really state this and make clear what the operations of the protocol are with the mandatory to implement (MTI) mechanisms. The MHT, bins, and all the protocol handling should go in an appendix. There is a call to make for the WG: I do know that MHTs were considered by some as burden and they have called for a leaner way, i.e., the start-end ranges. The call for the leaner way has been implemented in the document but not fully.
  • The text now states that MHTs SHOULD be used unless in benign environments and are mandatory-to-implement. It also states that only start-end chunk range is mandatory-to-implement, and bins are optional.

• 2) LEDBAT as congestion control vs. PPSPP The PPSP peer protocol is intended for the Standards Track and relies in a normative manner on LEDBAT (RFC 6817). LEDBAT as such is an **experimental** delay-based congestion control algorithm. A Standards Track protocol cannot normatively rely on an Experimental congestion control mechanism (or RFC in general). There are ways out of this situation: i) Do not use ledbat: this would call for another congestion control mechanism to be described in the PPSPP draft. ii) Work on an 'upgrade' of the LEDBAT specification to Standards Track: Possible, but a very long way. iii) Agree on having PPSPP also as Experimental protocol. I'm currently leaning towards option iii), but this is my pure personal opinion as an individual in the IETF.
  • A new paragraph has been added to Section 8.15 describing the widespread use of LEDBAT in current P2P systems. Hence, aim is a DOWNREF procedure.

• 3) No formal protocol message definition Section 7 and more specific Section 8 describe the protocol syntax of the protocol options and the messages, though Section 8 is talking about UDP encapsulation. Section 7 is hard to digest if someone should implement the options, see also later, but Section 8 is almost impossible to understand by somebody who has not been involved in the PPSP working group. See also further down for a more detailed review of the sections. To give an example out of Section 8.4: This section describes the HANDSHAKE message and gives examples how such a HANDSHAKE message could look like. But no formal definition of the message is given leaving a number of thins unclear, such as what the local channel number and what's the remote channel number is. This is implicitly defined, but that is not a good way of writing Standards Track drafts.
  • We added the usual bit-based ASCII art representations.

• 4) Implicit use of default values There are a number of places all over the draft where default values are defined. Many of those default values are used when there are no values explicitly signaled, e.g., the default chunk size of 1 Kbyte in Section 8.4 or Section Section 7.5. with the default for the Content Integrity Protection Method. I have the feeling that the protocol and the surroundings (e.g., what comes in via the 'tracker') are over-optimized, e.g., always providing the Content Integrity Protection Method as part of the Protocol options will not waste more than 2 bytes in a HANDSHAKE message. Further, I do not see the need to define a default chunk size in the base protocol specification, as this default can look very different, depending on who is deploying the protocol and in what context. This calls for a more dynamic way of handling the system chunk size, either as part of an external mechanisms (e.g. via the tracker) or in the HANDSHAKE message.
  • Removed implicit defaults from protocol options. Chunk size is part of the content's metadata and thus configurable. The default 1KiB has been turned into a recommendation.

• 5) Concept of channels The concept of channels is good but it is introduced too late in the draft, namely in Section 8.3, and it is introduced with very few words. Why isn't this introduced as part of Section 2 or Section 3, also in the relationship to the used transport protocol? I.e., the intention is to keep only one transport 'connection' between two distinct peers and to allow to run multiple swarm instances at the same time over the same transport. And how do swarms and channels correlate?
  • Concept now introduced in Section 3 with a figure.

• ***Technicals:
• - Section 2.1, 2nd paragraph, about the tracker: I haven't seen a single place where the interaction with a tracker is discussed or where the tracker less operation is discussed in contrast. It is further unclear what type of information is really required from a tracker. A tracker (or a resource directory) would need to provide more then IP address & port, e.g., the used transport protocol for the protocol exchange (given that other transports are allowed), used chunk size, chunk addressing scheme, etc
  • Interaction with tracking facilities in general is discussed in the Operations and Management section, Section 12.1.1. This also discusses swarm metadata and information required from tracking facility. Decentralized tracking in PPSPP is discussed in Section 3.10.1.

• - Section 2.3, the 1st paragraph, 'close-channel': This has been the first time where I stumbled over the channel without knowing the concept.
  • Rephrased.

• - Section 3.1: ordering of messages The 1st sentence implies that ordering of messages in a datagram matters a lot. This is outlined later in the document, but I would add this as part of 3., i.e., the messages are processed in the strict order or something along this line.
  • Phrase added.

• - Section 3.1, 1st paragraph, options to include I would not say anything about 'SHOULD include options' here, as this is anyhow described in Section 8.
  • Phrase removed.

• - Section 3.1, 2nd paragraph: "Datagrams exchanged MAY also contain some minor payload, e.g. HAVE messages to indicate the current progress of a peer or a REQUEST (see Section 3.7)." to be added, just to make it clear IMHO: ", but MUST NOT include any DATA message".
  • Added.

• - Section 3.2, 2nd paragraph: "In particular, whenever 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 interact with in the near future." This looks like a place where a lot of traffic can be send out of a peer, i.e., whenever a chunk arrives a HAVE message must be sent. I don't believe that this should be mandated by the protocol specification, but there should guidance on when to send this, e.g., peers might be also able to wait for a short period of time to gather more chunks to be reported in HAVE. Or should in this case a single UDP datagram contain multiple HAVEs?
  • Clarified that this is indeed controlled by a policy outside the peer protocol that can decide to piggyback onto other traffic or wait till multiple chunks are verified.

• - Section 3.4 on ACKs This section looks pretty weak, as ACKs may be sent but on the other hand MUST be sent if ledbat is used. I would simply say: - ACK MUST be sent if an unreliable transport protocol is used - ACK MAY be sent if a reliable transport protocol is used - keep clarification about ledbat.
  • DONE.

• - Section 3.5: Give text where INTEGERITY is described at least for the MTI scheme.
  • DONE.

• - Section 3.7, 2nd paragraph - all 'MAY' are actually not right here. Please remove or replace them with lower letters if appropriate. - It is not clear what the 'sequentially' means exactly. Is it in the received order?
  • Rephrased MAYs. "Sequentially" replaced with "received order".

• - Section 3.8: Please replace 'MAY' by can, as those are not normative behaviors but more the fact that peers can, for instance, request urgent data.
  • DONE.

• - Section 3.9 Same comment as for the Section 3.8 just above this comment.
  • DONE.

• - Section 3.9 waiting for responses OLD " When peer B receives a CHOKE message from A it MUST NOT send new REQUEST messages and SHOULD NOT expect answers to any outstanding ones." NEW " When peer B receives a CHOKE message from A it MUST NOT send new REQUEST messages and it cannot expect answers to any outstanding ones, as the transfer of chunks is choked."
  • DONE.

• - Section 3.10.2 This whole section about PEX hole punching reads very, very experimental. The STUN method is ok, but PEX isn't. First of all, the safe behavior for a peer when it receives unsolicited PEX messages, is to discard those messages. Second, this unsolicited PEX messages trigger some behavior which may open an attack vector. The best way, but this needs more discussion, is to include to some token in the messages that are exchanged in order to make avoid any blind attacks here. However, this will need more and detailed discussions of the purpose of this.
  • We moved parts of the security analysis of PEX up, such that all mechanisms are explained in the main text, and the analysis of what attacks there are and how these mechanisms prevent them is in the Sec. Considerations section.
  • The section about hole punching was removed, lacking a reference to the experiments we conducted with this exact variant of the mechanism.

• - Section 3.11 I don't see the 'MUST send keep-alive' as a mandatory requirement, as peers might have good reasons not to send any keep alive. Why not saying 'A peer can send a keep-alive' and it 'MUST use the simple datagram...' as already described. Though there is also no really need to say MUST.
  • Now Section 3.12. Rephrased and clarified the reason and consequences of sending keep-alive msgs.

• - Section 4 The syntax definition for each of the chunk addressing schemes is missing. This is not suitable for any specification that aims at interoperable implementations.
  • We added the usual bit-based ASCII art representations.

• - Section 4.3.2 PPSPP peers MUST use the ACK message if an unreliable transport protocol is used.
  • DONE.

• - Section 4.4 Has been tested in an implementation? I would like to understand the need for such a section, as in my understanding a peer implementation should chose one scheme and support this and there shouldn't be the need to convert between the different schemes.
  • Yes, the reference implementation translates from chunk ranges on the wire to bins internally. However, for simplicity we now state that all peers in a swarm MUST use the same method and the compatibility section has been removed.

• - Section 5 This reads that MHTs are mandatory to implement while the document makes the impression that MHTs are optional.
  • Rephrased, see High-level issues.

• - Section 5.3 " so each datagram SHOULD be processed separately and a loss of one datagram MUST NOT disrupt the flow" The MUST NOT is not a protocol specification requirement, but more an informative part saying that a lost message shouldn't impact the protocol machinery, but it can impact the overall operation. What is the flow here in that sentence?
  • Rephrased.

• - Section 5.6.2. An illustrative example explaining how the automatic size detection works is required here.
  • Added a paragraph with an example that follows the figure used during the explanation. A state diagram could also be added, but might be a bit redundant.

• - Section 6.1, 4th paragraph: Where do I find the 1 byte algorithm field in the swarm ID? The swarm ID is not really defined in a single place.
  • Expanded. Added a formal definition.

• - Section 7.3 The described min/max versioning relies on the fact that there are major and minor version numbers. I cannot find any major and minor version number scheme in the draft.
  • Actually, it does not. There is a single unstructured version number.

• - Section 7.4, Length field It is not clear what the 'Length' field is referring to. Further, it is not clear of the swam IDs are concatenated in one swarm ID option, of each swarm ID must be placed in a separate swam ID option.
  • Clarified.

• - Section 7.6 MHTs are mandatory to support though MHTs are optional?
  • Clarified.

• - Section 7.7 'key size ... derived from the swarm ID'. This relates to my high level comment no 4. on the use of implicit information. Either it is clearly specified how this information is derived or there is a protocol field/information about the size.
  • Key size derivation procedure added to description of SIGNED_INTEGRITY in UDP encapsulation.

• - Section 7.8 I would recommend to say that the default MUST be supported, but the peer must always signal what method it is supporting or at least using.
  • Corrected, see High-level issues 4.)

• - Section 7.10 I have not understood how the 'Lenght' field relates to the message bitmap and how long the message bitmap can grow. The figure looks like a maximum of 16 bits?
  • Clarified.

• - Section 8 I do not see the value of the text in the preface of Section 8. I would say that this text should say what is mandatory and what's not, i.e., MUST use UDP and MUST use LEDBAT. Potentially saying that future protocol versions can also run over other transport protocols.
  • Adjusted.

• - Section 8.1 about Maximum Transfer Unit (MTU) The text is discussing that a Ethernet can carry 1500 bytes. This is true, but the Ethernet payload is not the normative MTU across all of the Internet. For IPv6 the min MTU is 1280 bytes and for IPv4 it is 576 bytes, though for IPv4 it can be theoretically much lower at 64 bytes. It would move the definition of the default chunk size to a recommendation with text saying that this size has a high likelihood to travel end-to-end in the Internet without any fragmentation. Fragmentation might increase the loss of complete chunks, as one lost fragment will cause the loss of a complete chunk. One way of getting an informed decision on whether chunks can travel in their size is to use the Don't Fragment (DF) bit in IPv4 and also to watch for ICMP error messages. However, ICMP error messages are not a reliable indication, but they can be some indication.
  • 1 KiB chunk size has been made a recommendation.
  • Added a small paragraph discussing the optional integration of MTU path discovery.

• - Section 8.1 Definition of the default chunk size There is no need to define a default chunk size, if the chunk size would be always signaled per swarm. This is another default/implicit value places that is unnecessary.
  • The chunk size is always part of the content's metadata.

• - Section 8.3: see also my comment no 3. The concept of channels is introduced very late and with few words. A figure to explain the concept will help a lot and also more formal text on what a channel is and how they are identified. Also what the init channel is.
  • Concept now introduced in Section 3.11.

• - Section 8 in general: There is no formal definition of the messages, just bit pattern examples.
  • We added the usual bit-based ASCII art representations.

• - Section 8.4 (as example for the other Sections in 8.x): i) What is the '(CHANNEL' paramter? Is it actually a parameter? ii) it is implicit that the first channel no (0000000) is the remote peer's channel and that the second channel no (00000011) is the local peer's channel, right? This isn't clear from the text, but my guess.
  • We added the usual bit-based ASCII art representations.

• - Section 8.5 Can HAVE messages multiple bin specs in one message or do I have to make a HAVE message for each bin?
  • Clarified.

• - Section 8.6 What is the formal defintion of a DATA message? That's completely missing or I have not understood it.
  • We added the usual bit-based ASCII art representations.

• - Section 8.7 looks just underspecified, especially as this is the link to LEDBAT.
  • Implementors will unfortunately need to read the full LEDBAT specification.

• - Section 8.11 How are the chunks specified here? The formal syntax definition or reference to one is missing.
  • We added the usual bit-based ASCII art representations.

• - Section 8.13 I'm lost on this section, as I haven't fully understood the concept of the PEX in this document. Especially not why there is the PEX_REScert.
  • We moved parts of the security analysis of PEX up into 3.10, such that all mechanisms are explained in the main text, and the analysis of what attacks there are and how these mechanisms prevent them is in the Sec. Considerations section.

• - Section 11 The RFC required for protocol extensions of a standards track protocol looks odd. This must be at least IETF Review or Standards Action.
  • Policy changed to "IETF Review" and the section was extended with information about data types and required information.

• ***Editorials:
• - Abstract (and probably also other places), 1st sentence of, PPSPP is not a transport protocol, just a protocol
  • DONE.

• - Section 1.1, 4th paragraph: I would remove the reference to rmcat, as it is not yet clear what the outcome of the rmcat wg will be
  • DONE.

• - Section 1.3, on page 8, about seeding/leeching: I would break it in to sub-bullets.
  • DONE.

• - Section 2.1 and following: These are examples, isn'it? If so, this should be mentioned or clarified.
  • DONE. All subsections now labeled "Example:".

• - Section 2.1: What is the PPSP Url?
  • Reformulated in terms of "Imagine there is a PPSP URL".

• - Section 2.3, the 1st paragraph, detection of dead peers: It would be good to say where this detection is described in the remainder of the draft. Just for completeness.
  • DONE. Dead peer detection is now a separate section and referenced here.

• - Section 2.2, the very last paragraph, 'Peer A MAY also': This 'MAY' is not useful here. I would just write 'Peer A can also', as there is nothing normative described here.
  • DONE.

• - Section 3.2, last paragraph: What is the latter confinement? This is not clear to me.
  • Rephrased.

• - Section 3.9, last sentence I am not sure to what the reference to Section 3.7 is pointing in this respect.
  • Rephrased.

• - Section 3.10.1 about PEX messages The text says 'PPSPP optionally features...'. I have not understood if this optionally refers to mandatory to implement but optionally to use, or if the PEX messages are optionally to implement.
  • Made it clear that is OPTIONAL and not mandatory-to-implement.

• - Section 3.12 I'm not sure what this section is telling exactly. Isn't just saying that PPSPP as such does not care how chunks are stored locally, as this is implementation dependent?
  • Yes. Removed.

• - Section 4.2, page 15, 1st paragraph: OLD 'A PPSPP peer MAY support' NEW 'The support for this scheme is OPTIONAL'
  • DONE, for byte ranges as well.

• - Section 6.1.1 This section is not describing sign-all, but rather a justification why it may still work. This doesn't help at all.
• - Section 7, 1st paragraph Why is there a reference to RFC 2132?
  • Removed, just similarity in format.

• - Section 7 in general i) It is common to give bit positions in the figures where the syntax of options is described. This allows to count how many bits are used for a protocol field more easily and also way more reliable. ii) Please add also Figure labels to the syntax definitions of the options. This makes it easier to reference them later on if needed.
• - Section 8.1 1 kibibyte is 1 kbyte?
  • Mentioned base 1024 in Terminology. Changed to 1024 bytes where appropriate.

• - Section 8.2, last paragraph i ) "All messages are idempotent" in what respect? ii) "or recognizable as duplicates" but how are the recognized as duplicates?
  • Idempotent means that processing a message twice does not lead to a different state than processing them once. Resent handshakes can be recognized as duplicates because a peer already recorded the first connection attempt in its state. Updated text.

• - Section 8.5, last sentence in brackets: What is this last sentence about?
  • Was explanation of the on-the-wire bytes shown.

• - Section 8.13 " If sender of the PEX_REQ message does not have a private or link-local address, then the PEX_RES* messages MUST NOT contain such addresses [RFC1918][RFC4291]." What is this text saying? Do not include what you do not have anyway?
  • Rephrased. It tries to say that internal addresses must not be leaked to external peers.

• - Section 8.14 There is no single place where all the constants are collected and also documented what the default values or the recommended values. For instance in this Section 8.14 where the dead peer time out is set to 3 minutes and also the number of datagrams that should have sent. I would make a section or subsection to discuss dead peers and how they are detected and just link to the keep-alive mechanism in Section 8.14.
  • The Section 12.1.6 section was rewritten for this in the Ops & Mgmt part.

• - Section 11 This section needs to be overhauled once the document is ready for the IESG. The section is not wrong but can be improved to help IANA.
  • The section was extended with information about data types and required information.

-08 2013-08-8 Continued Revision following AD Review

• Please see the -07 entry for our responses to the comments.
• Added ECDSAP256SHA256 and ECDSAP384SHA384 as mandatory-to-implement live signature algorithms, as they provide small swarm IDs.
• Added line that a peer SHOULD NOT send HAVEs to peers that already have the complete content (e.g. in video-on-demand scenarios).
• In response to a remark at WG meeting at IETF 87 we added a paragraph on OPTIONAL MTU discovery using PPSPP messages to Section 8.1.

-09 2014-04-4 Nits fixed

• Nits about e.g. newer references fixed.

-10 2014-06-17 DOWNREF restored

• Reference to LEDBAT was not in Normative references as it should have been.

-11 2014-06-18 IANA not OK

• In the 2nd Last Call IANA posed two questions:
• " QUESTION: Are the authors intended to have one single top-level registry to host these six new registries defined in this draft? Please see http://www.iana.org/assignments/ancp as an example, that the ANCP registry hosts multiple sub-registries."
  • Yes. We updated the IANA Considerations section with IANA's Pearl Liang proposed text to request this.

• "QUESTION: Section 11.3 specifies that the values are integers in the range 0-255. However value 0 is not included in the above table. Section 7.2 (Version) does not clearly explain value 0."
  • 0 defined as reserved.

• Text cleanup
  • Terminology: states chunks may be variable size explicitly also here.
  • Figure 3 label improved.
  • 5.4 Explicitly state that leaves have tree height 0.
  • 5.5 Repaired split paragraph.
  • 5.6 Rephrased start to be consistent with minimally required metadata.
  • 5.6.1 Removed remark about peak hashes role in static/live download unification as that is no longer the case.
  • 5.6.2 Explicitly stated that peak hashes are transported in INTEGRITY messages.
  • 6.1.2.1 Changed "computing the computed" to "comparing the computed"
  • 6.2 Changed sentence to "*is* related to bitrate"
  • 8.4 Explicitly stated that the *Source* Channel ID is all 0-zeros in closing HANDSHAKE.
  • 8.5 Removed spurious line.
  • 8.6 Explicitly stated that the chunk specification in a DATA message denotes a single chunk.
  • 8.8 Changed copy+paste from ACK to INTEGRITY message.
  • 8.12 Renamed PEX_RES to PEX_RESv4 where needed.
  • 8.17 Explicitly stated that the *Source* Channel ID is all 0-zeros in closing HANDSHAKE.
  • 12.1.5 Changed to read that a swarm's operation can easily verified when swarm metadata and tracker info is available.
  • 13.2.1 "cert" -> "certificate"
  • Added refs to RFC6972 where required.

• ========================================================================= IESG telechat DISCUSSES =========================================================================
• **Alissa Cooper:**
• "I'm a little surprised about the choice of LEDBAT for congestion control of live streams. It seems like LEDBAT is not what the receiver would want the sender to use for live-streamed content, because if a bottleneck is encountered on the path, the live stream will yield early, and the recipient's perception of quality will degrade. If the bottleneck is near the recipient, then every sender sending chunks will yield early, and there may be no senders available to stream at an acceptable level of quality. I'm assuming the WG discussed this -- it would be helpful to understand why a more aggressive congestion control was not selected for live streaming."
  • Updated 8.16 to discuss why LEDBAT is good in a peer-to-peer context (can be friendly to network as a whole and has configurable aggressiveness)

• --------------------------------------------------------------
• **Stephen Farrell:**
• "(1) 3.10: What is a "benign" environment? I actually do understand what is meant, but how could a program evaluate that in order to decicde whether or not to send a PES_RESv4? You then refer to a "potentially hostile environment" which could presumably be anywhere, so are you really saying that PES_REScert is the "right thing" to do, but you know it won't be done so these are weasel words around that awkward fact? (Apologies if I'm wrong on that, but that's the impression I got when reading this, but maybe that's just my paranoia:-)"
  • Rephrased to show PEX_REScert is the only option on the Internet.

• "(2) 6.1.2.2: What exactly are the "munro" bytes that are the first input to the signature? Where are those defined? (Sorry if I missed/skipped over that;-)"
  • Added to Terminology and added an explicit reference in this section.

• "(3) 7.6 and 13.5: SHA1 as the MTI is wrong. Why is that ok, given the collision resistance is less that designed for? 7.7 also calls for SHA256 being implemented in any case. The run-time argument in 13.5 does not convince me. Attacks only ever get worse, so the collision resistance property which this protocol needs ought lead to selection of an as-far-as-known good hash function. Today that means SHA256 and not SHA1."
  • SHA-256 is now the default. SHA-1 is still MTI to give content providers a trade-off between performance and security, as the on-the-wire overhead is 37.5% smaller.

• "(4) 7.7: Why RSASHA1 and not RSA with SHA256?"
  • RSA256 is now also MTI, but RSASHA1 is also required, as argued in the previous point.

• "(5) 7.10: The message number is wrong in the figure."
  • Fixed.

• "(6) 8.4: I don't see the swarm's metadata record in the ascii art diagram and you just say "look at section 7" so two questions: a) where is the "chunk size used" option in section 7? and b) do all the swarm metadata options have to be sent each time with no limit on ordering except as given in section 7 (which had one such order sensitive limit I think)?"
  • (a) We once envisioned that a peer could start with just a swarm ID+chunk size as metadata and obtain all protocol options (chunk addressing, integrity protection, etc.) from a peer. As this turned out to be too complex to secure (peers may lie about the options), we decided to make the options all part of the swarm metadata after the AD review. This renders the protocol options in the HANDSHAKE to an end-to-end test really. Chunk size was never part of that negotiation because writing code that would handle bad input on that parameter was definitely too complicated. Chunk size has now been added as a protocol option.
  • (b) The HANDSHAKE message and hence protocol options are sent only in the first datagram. After that this information is part of the context of the channel that has been established. We added a limit on ordering (sort on code value, ascending) as a simplification.

• "(7) 8.13: Don't you need to register the ppsp URI scheme? In case its useful, which I doubt, if you have code: RFC6920 URIs could be used for this if you wanted and would save you adding ppsp to the IANA URI scheme registry (and having to deal with the URI police:-)"
  • Not sure. The problem is we need to denote a peer in a swarm here. This means we need to encode the swarm ID and the peer address. IMHO, this means we cannot use the ni: RFC6920 scheme here, because only the hash determines identity. If we would encode the swarm ID there (SHA-256 hash of the swarm ID), we need a place for the peer address and the authority part does not make the URL unique. The ni: URL will still only identify the swarm. Encoding the peer address in OtherNames instead of uniformResourceIdentifier is troublesome too. We could find no single object type to denote a transport address (IP+port) that supports both IPv4 and IPv6 (udpDomain is IPv4 only). Using SAN ipAddress for the address and a separate OtherName for the port number (e.g. udpEndpointLocalPort from [RFC4113]) is not ideal, as the port number by itself is not a name for the subject. Hence, we replaced the ppsp: scheme with the file: scheme, which has an authority part where we can naturally encode the peer address in.

• "(8) 13.4: Wouldn't DTLS change the chunk size considerations and also influence how messages map to datagrams? Isn't more specification needed to say how to really use DTLS here? Just saying "use DTLS or IPsec or higher layer crypto" doesn't really seem sufficient. And doing the DTLS bits right shouldn't be very hard either."
  • According to RFC6347, for "DTLS over UDP, the upper layer protocol SHOULD be allowed to obtain the PMTU estimate maintained in the IP layer" (Sec. 4.1.1.1). So we know beforehand how much payload we can send in a datagram without fragmentation. If PMTU changes and the chunk size becomes too large, we can choose to allow fragmentation ("the upper layer protocol SHOULD be allowed to set the state of the DF bit (in IPv4) or prohibit local fragmentation (in IPv6)."). Alternatively, the content publisher can decide to use smaller chunks and transmit multiple in the same datagram when the MTU allows. We added an explanatory paragraph to Section 13.4.

• **Other DISCUSSes: TODO.**

-12 2014-11-16 Other DISCUSSes and reviews

• ========================================================================= IESG telechat DISCUSSES (continued) =========================================================================
• **Richard Barnes:**
• "My DISCUSS here is based mainly on the readability of the document, which seems bad enough to be an impediment to interoperability. As far as I can tell, this document does not define a protocol, in the sense of a set of actions required to achieve a given objective. Instead, it presents a pile of piece parts with a couple of combinations, and notes that these combinations could be used to achieve, e.g., live streaming. (In the language of patents, it has not been "reduced to practice".) What are the steps an implementation follows to join a swarm? To connect to a new peer and request chunks? The pieces seem to be here, but the big picture is completely absent."
  • Clarified the DISCUSS via email. In response, we made the distinction between tracker protocol and peer protocol more clear in the Introduction and Section 2.
  • We also rewrote the section on the HANDSHAKE message to include an explicit handshake procedure in the format suggested.

• --------------------------------------------------------------
• **Kathleen Moriarty:**
• "I am still reading this draft, but don't see any response to the SecDir review that raised some very important points for discussion: http://www.ietf.org/mail-archive/web/secdir/current/msg04879.html I'll amend this when I get further into my review and would appreciate a response to the SecDir review."
  • Please see our responses to the SecDir review via email: http://www.ietf.org/mail-archive/web/secdir/current/msg04914.html and below.

• --------------------------------------------------------------
• **OpsDir review** by Tina TSOU (replied to by email, July 9th, 2014):
• "You probably want to mention SHA-256 rater than SHA-1 [...]"
  • SHA-256 made default. See reply to Farrell.

  "Section 8.13: You should also include ULAs"

  • Added.

  "Section 8.16: This doesn't seem like a good justification for not having flow control. Could you please elaborate on why flow control is not needed for this case?"

  • Explained in email reply.

  "Section 8.17, page 53: The channel ID values employed might give the reader the impression that they are non-random."

  • Stated explicitly they must be random with a reference to why.

  Nits

  • Processed

• --------------------------------------------------------------
• **GenArt review** by Christer Holmberg (replied to by email, July 9th, 2014)
• "Q1: The sending of keep alives is a SHOULD, and there are no procedures on how to act if keep alives are not received. There isn't even a mechanism to negotiate the sending of keep alives.
  • Rewrote Section 3.12 to explain what happens when no keep alives are received. In particular, given certain conditions the peer is declared dead and no more messages are sent to it, and the local administration about that peer is discarded. The exact conditions were specified in Sec. 8.15 but are now defined in 3.12 at Christer's suggestion in his follow-up to our reply. Section 8.15 removed.

  "Q2: As the sending of keep alives is a SHOULD, are there example cases when keep alives would NOT be sent?"

  • Added example of busy server garbage collecting idle clients by not sending keep alives.

  "Q3: The text saying "to each peer it wants to interact with in the future" sounds a little strange to me. How does a peer know with whom it wants to interact in the future? Perhaps the text instead should talk about peers with whom one wants to maintain a signaling channel, or something like that?"

  • Rephrased in Sec. 3.12 to "interesting peers" and explain there is a policy that determines which peers are of interest. E.g. peers that have chunks that the downloader is still missing.

• --------------------------------------------------------------
• **SecDir review** by David Harrington (replied to by email, July 10th, 2014)
• Editorials:
  • Incorporated.

  "6) tech: I feel uncomfortable with section 2 containing examples that describe the overall flow. Examples are non-normative text, usually contained in a non-normative appendix. These examples describe the order of messages, and it is "

  • Please see our actions taken on Richard Barnes' DISCUSS.

  "7) in example 2.2, the integrity hash is provided by the peer that is providing the (potentially maliciously modified) content. Isn't that like asking the fox to verify that the henhouse is safe?"

  • Added that the hashes can be verified against the trusted swarm ID using the Merkle tree content integrity protection scheme, defined later in the document.

  "9) in 3, paragraph 1, it says "this behavior", but I'm not sure which behavior it is referencing. It is unclear whether not sending error messages, or discarding messages, or stopping communication, or classifying peers is the behavior that allows a peer to deal with slow, crashed, or silent peers. I don't understand HOW any of the behaviors mentioned would allow a peer to deal with slow, crashed, or silent peers. I do not understand on what basis peers are judged "good" or "bad"."

  • Added explanation how in a peer-to-peer system with multiple sources to obtain the content from, the classification in good and bad can be used to deal with malfunctioning peers.

  "11) in 3, paragraph 3, the second sentence seems to contradict the first sentence, and since neither is written using RFC2119 keywords, it seems to really leave the whole question open to implementer interpretation."

  • Added that the video container format used is outside the scope of this document.

  ``"A SIGNED_INTEGRITY message (type 0x07) consists of a chunk specification, a 64-bit NTP timestamp [RFC5905] and a digital signature encoded as a Signature field in a RRSIG record in DNSSEC without the BASE-64 encoding [RFC4034]." Can this work in an implementation with no NTP support?''

  • Yes. It is sufficient for the injector's and receivers' clocks to be roughly synchronized. Rephrased to "64-bit timestamp in NTP Timestamp format".

  "8.14 describes a keep alive message format, but no processing instructions."

  • Please see our actions following the GenArt review.

  "Multiple messages are multiplexed in a datagram. How are the messages delimited? If there is any corruption in one message, how does the receiver find the end of the message and the start of the next message? If I understand correctly, invalid messages are discarded and no error code is sent. If one of the messages are found to be invalid, are all messages in that datagram discarded? or are all subsequent messages in that datagram discarded? or is it valid to process the remaining messages in the datagram after an invalid message is detected? If so, would that conflict with the rule that all messages must be processed in order?"

  • Messages are fixed size, or contain size fields. Made it more clear in Section 3 that when an invalid message is encountered in a datagram, the remaining messages MUST be discarded.

• --------------------------------------------------------------
• ** COMMENTS by Spencer Dawkins, July 8th 2014**
• "3. Messages In general, no error codes or responses are used in the protocol; absence of any response indicates an error. Is there accurate qualifier more narrow than "in general" that you could substitute?"
  • Qualifier removed.

  "3.1. HANDSHAKE [heavy/minor confusing]"

  • Heavy payload has been explicitly defined in Terminology. Please see our response to Richard Barnes' DISCUSS for a rephrased definition of the handshake procedure.

  "3.2. HAVE In particular, whenever a receiving peer P has successfully checked the integrity of a chunk, or interval of chunks, it SHOULD send a ^^^^^^ HAVE message to all peers Q1..Qn it wants to interact with in the near future. A policy in peer P determines when the HAVE is sent. P may sent it directly, or peer P may wait until either it has other data to sent to Qi, or until it has received and checked multiple chunks. This wasn't clear to me. I'm not understanding why a SHOULD is appropriate, but I suspect I shouldn't be askig a 2119 question, because this is tangled between "send a HAVE to the peers you want to interact with in the near future" and "if you don't want to interact with a specific peer in the near future, you can wait to send a HAVE". Is that even close? "

  • Yes. Changed to a MUST and rephrased that the HAVE is sent only to the peers the sender wants to allow download of those chunks from.

  "3.4. ACK [unreliable/reliable discussion in WG]"

  • The swift protocol on which this draft is based had been designed from the start to be transport-agnostic. We tried to preserve that as much as possible.

  "5.3. The Atomic Datagram Principle [...] With that many SHOULDs, I'd be worried that implementations using PPSPP can't count on much. If I receive a message that spans multiple datagrams (even though it shouldn't), that don't include the necessary hashes (even though it should), and I don't drop a message with missing data (even though I should), is that all fine?"

  • Yes. Unfortunately, there are some exceptional cases that have to be dealt with. E.g. because of reordering you may want to hang on to a datagram with a DATA message that cannot yet be verified because the datagram with the required hashes was delayed. In general, there will be multiple sources to obtain the content from, so a peer/implementor may choose to get the chunks from a different source with a better path.

  "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. Is this assuming that the path between peers will never reorder packets?"

  • No. Hence, the many SHOULDs in the previous Section. This facilitates processing in the normal case.

• --------------------------------------------------------------
• **COMMENT by Jari Arkko, July 8th 2014**
  • Please see responses to GenArt review.

• --------------------------------------------------------------
• **COMMENTs by Barry Leiba, July 9th 2014**
• "General question on the chunking: Is it the case that a given piece of content is chunked in a specific way, with known chunk IDs, such that every peer that's serving that content up (at least in the same swarm) uses the same chunks with the same chunk IDs? One can guess that from the way things work, but shouldn't the document say that? Or does it, and I missed it?"
  • Explicitly stated this in Section 3.

  "-- Section 3.7 -- When peer Q receives multiple REQUESTs from the same peer P, peer Q SHOULD process the REQUESTs in the order received. What happens if it doesn't? Is there an interoperability issue here? A performance issue? Or what? (That is, why is this a 2119 SHOULD?)"

  • Consider the case where peer P is operating near the playback deadline, i.e., the last chunk it has needs to be given to the video player very soon or it will stall (i.e., P has nearly run out of buffer). In that case it is important that the chunks P requests arrive in order (and it will be requesting a range of chunks at a time to get a pipeline going). So the SHOULD is there to help prevent a performance problem.

  "-- Section 5.3 -- Thus, as a datagram carries zero or more messages, neither messages nor message interdependencies SHOULD span over multiple datagrams. The negatives in this sentence really make the SHOULD a hidden SHOULD NOT, and its meaning is unclear. I think it would be clearer if it were worded that way:"

  • Replaced with suggested wording.

• --------------------------------------------------------------
• **COMMENTs by Alia Atlas, July 9th 2014**
• • Requested modifications made.

  "Sec 8.1: The paragraph on PLPMTUD is a bit confusing. Presumably this is between two peers - but the chunk sizes used by the swarm would be specified by the initial seeder. Thus I can see the PLPMTUD variant being useful to decide upon the PPSPP datagram size, but not the chunk size. Could you please clarify either what I'm missing?"

  • This section discussed considerations for choosing a chunk size. Deployments can use PLPMTUD, but in that case they should partition the content using a small chunk size, such that the datagram can be scaled up or down depending on the actual network properties.

• --------------------------------------------------------------
• **COMMENTs by Stephen Farrell, July 10th 2014**.
• For DISCUSSes, please see above at revision -11.
• "- The elephant is in the room, but not the intro:-) Surely some comparison with BT is needed in the intro?"
  • Paragraph added.

  "- 1.1: I really dislike the term self-certification as its quite misleading."

  • AFAIK the term was quite common for this type of mechanism, see e.g. http://en.wikipedia.org/wiki/Self-certifying_File_System

  "- 1.3, 'content': s/asset/file/ would be better I think and less capitalist;-)"

  • Done. We had commercial partners in our research project ;-)

  "- 3: I don't get what is meant by this "an external storage mapping from the linear byte space of a single swarm to different files" I can sorta see what's meant, but am not sure. Maybe try clarify?"

  • In other words, we do not prescribe the video container format. Added to the paragraph.

  "- 5.3, last para: Is the 1st MUST there really implementable in general? I think the MUST might be to include those hashes that the sender thinks the receiver needs."

  • Clarified

  "- 6.1 - this defines two methods yet says "If the protocol operates in a benign environment the method MAY be used." Which is meant here?"

  • Clarified.

  "- 6.1.2.1: what if different folks think NCHUNKS_PER_SIG has different values? How do we all agree on a value? (BTW, the last sentence of this section is a cool thing.)"

  • This value is set by the content publisher, and is then derived from the chunk specification of the signed munro hash by all peers.

  "- 7.4: "In other cases a peer MAY include a swarm identifier option, as an end-to-end check." That's not clear to me, what other cases?"

  • Rephrased.

  "- 7.8: The width of the figure seems wrong."

  • Corrected.

  "- 7.10: An example compressed encoding would be useful."

  • Added a small example.

  "- 8.16: "perfectly detected" - huh? what does that mean?"

  • Rephrased in revision -11.

• --------------------------------------------------------------

Authors' Addresses