Internet Engineering Task Force R. Bernardini Internet-Draft R. Cesco Fabbro Expires: July 12, 2012 R. Rinaldo UniUD January 9, 2012 Peer-to-Peer Epi-Transport Protocol draft-bernardini-ppetp-03 Abstract This document describes PPETP (Peer-to-Peer Epi-Transport Protocol) a peer-to-peer distribution protocol suited for streaming applications over networks made of heterogeneous nodes. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 12, 2012. Copyright Notice Copyright (c) 2012 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 Bernardini, et al. Expires July 12, 2012 [Page 1] Internet-Draft PPETP January 2012 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 BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview of PPETP . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Applicative context . . . . . . . . . . . . . . . . . . 5 2.2. Network type . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Underneath transport protocol . . . . . . . . . . . . . 7 2.4. Plugin structure . . . . . . . . . . . . . . . . . . . . 7 2.4.1. Plugin parameters . . . . . . . . . . . . . . . . . 7 2.5. Reducing the upload data rate . . . . . . . . . . . . . 8 2.5.1. Reduction procedure . . . . . . . . . . . . . . . . 8 2.5.2. Data puncturing . . . . . . . . . . . . . . . . . . 11 2.6. Priority class . . . . . . . . . . . . . . . . . . . . . 11 3. Preliminary definitions . . . . . . . . . . . . . . . . . . . 12 3.1. Address and name of a PPETP session . . . . . . . . . . 12 3.1.1. Default name of a PPETP section . . . . . . . . . . 12 3.2. Upper peers, lower peers and peer ID . . . . . . . . . . 13 3.3. Packet source and packet sender . . . . . . . . . . . . 13 3.4. Source signature and sender signature . . . . . . . . . 13 3.5. Streams and packets . . . . . . . . . . . . . . . . . . 14 3.6. PPETP channels . . . . . . . . . . . . . . . . . . . . . 15 3.7. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Basic type formats . . . . . . . . . . . . . . . . . . . . . 16 4.1. Chain-encoding of 15-bit integers . . . . . . . . . . . 16 4.2. Channel mask . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Type-Length-Value format . . . . . . . . . . . . . . . . 17 4.4. Generalized addresses . . . . . . . . . . . . . . . . . 17 4.4.1. Generalized addresses format . . . . . . . . . . . . 18 4.4.2. IPv4 and IPv6 address classes . . . . . . . . . . . 19 Bernardini, et al. Expires July 12, 2012 [Page 2] Internet-Draft PPETP January 2012 4.4.3. ICE address classes (ice4 and ice6) . . . . . . . . 19 4.5. Peer reference . . . . . . . . . . . . . . . . . . . . . 20 5. PPETP packets . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Data packets . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Control packets . . . . . . . . . . . . . . . . . . . . 24 5.2.1. Control packet format . . . . . . . . . . . . . . . 24 5.2.2. Request types . . . . . . . . . . . . . . . . . . . 27 5.2.3. Signing Hello requests . . . . . . . . . . . . . . . 32 5.3. Routed control packets . . . . . . . . . . . . . . . . . 33 5.3.1. Structure of a routed packets . . . . . . . . . . . 34 5.3.2. Signing routed packet . . . . . . . . . . . . . . . 36 5.3.3. Embedded packets . . . . . . . . . . . . . . . . . . 36 6. Packet processing . . . . . . . . . . . . . . . . . . . . . . 37 6.1. Control packet transmission procedure . . . . . . . . . 37 6.2. Control packet acknowledgement procedure . . . . . . . . 38 6.3. Processing received packets . . . . . . . . . . . . . . 38 6.4. Routing and acknowledging routed packet . . . . . . . . 39 6.5. Congestion control . . . . . . . . . . . . . . . . . . . 41 7. PPETP Attributes . . . . . . . . . . . . . . . . . . . . . . 41 8. Peer handshaking procedure . . . . . . . . . . . . . . . . . 44 8.1. Peer status . . . . . . . . . . . . . . . . . . . . . . 45 9. Security Considerations . . . . . . . . . . . . . . . . . . . 46 9.1. Possible attacks and countermeasures . . . . . . . . . . 46 9.1.1. Poisoning attack . . . . . . . . . . . . . . . . . . 47 9.1.2. Defamatory attack . . . . . . . . . . . . . . . . . 48 9.2. Security model . . . . . . . . . . . . . . . . . . . . . 48 9.2.1. Node classes . . . . . . . . . . . . . . . . . . . . 49 10. PPETP configuration . . . . . . . . . . . . . . . . . . . . . 50 10.1. Bootstrap configuration protocol . . . . . . . . . . . . 50 10.1.1. Design goals . . . . . . . . . . . . . . . . . . . . 51 10.1.2. Protocol structure . . . . . . . . . . . . . . . . . 52 10.1.3. Query packet . . . . . . . . . . . . . . . . . . . . 52 10.1.4. Response packet . . . . . . . . . . . . . . . . . . 53 10.1.5. Attributes . . . . . . . . . . . . . . . . . . . . . 54 10.1.6. Packet signing . . . . . . . . . . . . . . . . . . . 57 10.2. Compact Configuration Format . . . . . . . . . . . . . . 59 10.3. Configuration defaults . . . . . . . . . . . . . . . . . 66 11. ICE-based Connection Establishment Procedure . . . . . . . . 66 11.1. HTTP/HTTPS-based exchange protocol . . . . . . . . . . . 67 11.1.1. Format of the private field in the generalized address . . . . . . . . . . . . . . . . . . . . . . 69 11.2. JSON format for ICE candidates . . . . . . . . . . . . . 70 11.2.1. Example . . . . . . . . . . . . . . . . . . . . . . 72 12. Identity-based signature . . . . . . . . . . . . . . . . . . 72 12.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 72 12.2. Algorithm . . . . . . . . . . . . . . . . . . . . . . . 73 12.3. Signature format . . . . . . . . . . . . . . . . . . . . 73 12.4. ID-based signature attributes . . . . . . . . . . . . . 74 Bernardini, et al. Expires July 12, 2012 [Page 3] Internet-Draft PPETP January 2012 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 13.1. Generic plugin definition . . . . . . . . . . . . . . . 75 13.2. Reduction procedure registry . . . . . . . . . . . . . . 76 13.2.1. How to define a reduction profile . . . . . . . . . 76 13.3. Sender signature procedure registry . . . . . . . . . . 76 13.3.1. Defining new sender signature profiles . . . . . . . 77 13.4. Source signature procedure registry . . . . . . . . . . 77 13.4.1. Defining new source signature plugins . . . . . . . 77 13.5. Hello signature procedure registry . . . . . . . . . . . 78 13.5.1. Defining new source signature plugins . . . . . . . 78 13.6. Address classes registry . . . . . . . . . . . . . . . . 78 13.7. Peer-local parameters registry . . . . . . . . . . . . . 79 13.8. Congestion control procedure registry . . . . . . . . . 80 13.8.1. Definition of a new congestion control procedure . . 80 13.9. Configuration protocol registry . . . . . . . . . . . . 80 13.9.1. Definition of a new configuration protocol . . . . . 81 13.10. SDP extensions . . . . . . . . . . . . . . . . . . . . . 81 13.10.1. Transport protocols ("proto") . . . . . . . . . . . 81 13.10.2. Attributes . . . . . . . . . . . . . . . . . . . . . 82 14. Built-in plugins . . . . . . . . . . . . . . . . . . . . . . 83 14.1. Sender signature profiles . . . . . . . . . . . . . . . 83 14.1.1. Shared key signature profile . . . . . . . . . . . . 83 14.1.2. Void signature profile . . . . . . . . . . . . . . . 84 14.2. Source signature profiles . . . . . . . . . . . . . . . 85 14.2.1. Rabin signature profile . . . . . . . . . . . . . . 85 14.2.2. Void signature profile . . . . . . . . . . . . . . . 86 14.3. Hello signature profiles . . . . . . . . . . . . . . . . 86 14.3.1. Void signature profile . . . . . . . . . . . . . . . 86 14.4. Configuration Protocols . . . . . . . . . . . . . . . . 87 14.4.1. Light-weight configuration protocol . . . . . . . . 87 14.4.2. Null configuration protocol . . . . . . . . . . . . 87 14.5. Reduction profiles . . . . . . . . . . . . . . . . . . . 87 14.5.1. Vandermonde reduction profile . . . . . . . . . . . 87 14.5.2. Basic reduction profile . . . . . . . . . . . . . . 90 14.6. Rate control procedures . . . . . . . . . . . . . . . . 91 14.6.1. Null procedure . . . . . . . . . . . . . . . . . . . 91 14.6.2. TFRC-based procedure . . . . . . . . . . . . . . . . 91 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 15.1. Normative References . . . . . . . . . . . . . . . . . . 92 15.2. Informative References . . . . . . . . . . . . . . . . . 94 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 95 A.1. Live media . . . . . . . . . . . . . . . . . . . . . . . 95 A.2. Remote lecturing . . . . . . . . . . . . . . . . . . . . 101 Appendix B. Rationale . . . . . . . . . . . . . . . . . . . . . 102 B.1. Plugin structure . . . . . . . . . . . . . . . . . . . . 103 B.2. Direct acknowledgement in routed packets . . . . . . . . 103 B.3. Shared key sender signature . . . . . . . . . . . . . . 104 Bernardini, et al. Expires July 12, 2012 [Page 4] Internet-Draft PPETP January 2012 B.4. Specifying the peer identiy . . . . . . . . . . . . . . 104 Appendix C. Ritagli -- Maybe obsolete . . . . . . . . . . . . . 104 C.1. Behavior of a PPETP node . . . . . . . . . . . . . . . . 106 C.1.1. Live streaming . . . . . . . . . . . . . . . . . . . 106 C.1.2. Conferencing . . . . . . . . . . . . . . . . . . . . 109 Bernardini, et al. Expires July 12, 2012 [Page 5] Internet-Draft PPETP January 2012 1. Introduction This document describes PPETP (Peer-to-Peer Epi-Transport Protocol), a chunkless peer-to-peer distribution protocol originally designed for data streaming over networks made of heterogeneous nodes. PPETP allows for an efficient usage of the upload characteristics of every node, including those with limited upload bandwidth. Differently from other peer-to-peer approaches, PPETP can be considered a "pure transport" protocol in the sense that it gives no tool for searching for new peers, nor it dictates any network structure, but it takes care only of the problem of propagating data among peers. Other aspects (i.e., network topology or peer search) are supposed to be handled by extra-PPETP means. This "separation" between transport and topology makes PPETP flexible enough to be used with several structures: from networks managed by a central node, to networks with a highly distributed control (see Appendix C.1.1 for an example). From the standpoint of an application writer, the overlay transport layer provided by PPETP looks like a multicast-like transport protocol, usable with an API similar to the well-known BSD socket API and able to transmit any type of data (e.g., audio, video, slides) encoded with any type of encoder (lossy, lossless, scalable or multiple description, even encripted). 1.1. Conventions 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]. 2. Overview of PPETP This section is non-normative. Its goal of this section is to give an informal description of the main characteristics of PPETP. 2.1. Applicative context PPETP is a protocol originally designed for live streaming applications. Live streaming over peer-to-peer (P2P) networks is a peculiar application, affected by several problems, such as Asymmetric bandwidth Residential users are typically connected to the Internet via an ADSL line. Depending on the type of the media stream, a residential user could have enough download bandwidth to receive it, but not enough upload bandwidth to retransmit it, making it not trivial to exploit the user upload capabilities. Bernardini, et al. Expires July 12, 2012 [Page 6] Internet-Draft PPETP January 2012 More in general, the network can include nodes with different upload capabilities and one would like to be able to exploit the bandwidth of each peer as much as possible, both for low-bandwidth and high-bandwidth nodes. Packet losses This is a potential problem with any type of media streaming, but it is especially important in the context of P2P networks, since a node can leave the network at any time, possibly leaving other nodes without data for a long time (until the "orphan" node finds a new peer). Security P2P networks have several security issues [IPTV], here we simply cite the "stream poisoning attack" where a node propagates incorrect packets which cause an incorrect decoding of the multimedia content and are propagated to the whole network by the peer-to-peer mechanism. PPETP is designed to counteract the problems above and to appear at the application developer as a multicast-like transmission protocol, in the sense that the API (Application Programming Interface) used for exchanging data over a PPETP network is not very different from the API that one would use for exchanging data over a multicast session. Note that PPETP takes care _only_ of the efficient transfer of stream data between different peers; other aspects of P2P (e.g., building the network) are supposed to be managed by extra-PPETP means. This separation between data transport and network management increases the flexibility of PPETP and allows for its use in several applicative contexts, for example, with networks managed by a central server or in a distributed manner, with only one media source (as in live streaming) or several (like in conferencing). 2.2. Network type A PPETP network can be considered as a network of _push_ type, since every peer sends data spontaneously to the other peers as soon as new data are received. The network structure in PPETP is relatively "stable", in the sense that two peers, in order to communicate, open a "connection" (see Section 8) that remains open until it is explicitely closed (for example, when one of the two nodes leaves the network). PPETP does not put any constraint on the network topology, leaving this choice to the specific application. Bernardini, et al. Expires July 12, 2012 [Page 7] Internet-Draft PPETP January 2012 2.3. Underneath transport protocol The prefix Epi- in "Epi-Transport" emphasizes the fact that PPETP is not a true transport protocol, but it relies on a "true" transport protocol. PPETP does not require that the used transport protocol be reliable. This document considers in detail the case where UDP is used as transport protocol, but other choices (e.g., DCCP [RFC4340]) can be added in the future. 2.4. Plugin structure PPETP makes use of several externally defined procedures; for example, it employs signature algorithms, key-exchange techniques, NAT traversal procedures and congestion control mechanisms. Since it can be expected that better techniques (say, better congestion-control algorithms) will be developed in the future, PPETP allows to be extended by the use of externally defined "plugins". With this approach, the inclusion of a new algorithm in PPETP would require only the specification of a new plugin and not an update of the whole protocol. Care has been exercised in order to make it possible to implement new plugins by means of modules dynamically loadable at run-time, without the need to re-compile the basic implementation. The definition of a new plugin requires an RFC. For every part implementable as a plugin this document specifies as the plugin is expected to behave and which IANA registers is supposed to update. In order to make this specification self-contained, for every pluggable part one or more built-in plugins are defined. These built-in plugins MUST be implemented by every implementation compatible with this document. 2.4.1. Plugin parameters Many PPETP plugins accepts parameters. For example, some signature plugin can accept the length of the generated signature as a parameter. Generically, plugin parameters can be partitioned into _global parameters_ and _peer-local parameters_. Global parameters are parameters whose value is shared among all the peers of a PPETP session. They are set at session configuration time. Bernardini, et al. Expires July 12, 2012 [Page 8] Internet-Draft PPETP January 2012 Peer-local parameters are parameters whose value depends on the specific peer. They are typically set at peer handshaking time. For example, the shared secret signature algorithm described in Section 14.1.1 has the length of the generated signature as global parameter, while the public Diffie-Hellman half-key of the remote peer is a peer-local parameter. 2.5. Reducing the upload data rate As explained above, PPETP aims to distribute content over nodes whose upload bandwidth can be smaller than the bandwidth required by the content. In order to reduce the upload bandwidth required to a node, PPETP provides two tools: reduction procedures and puncturing. 2.5.1. Reduction procedure A key characteristic of PPETP is the use of "reduction procedures" to reduce the data rate required to each node and, at the same time, solve the issues described in Section 2.1. PPETP assumes that the content to be distributed can be represented as a sequence of packets. Every node of the PPETP network processes every _content packet_ of the data stream with a so-called "reduction function". The output of the reduction function is a smaller packet, called _reduced packet_. The reduction is carried out in a way that allows for the reconstruction of the original packet from the knowledge of a suitable number of reduced versions. PPETP does not mandate a specific reduction procedure, but, faithful to the ideas described in Section 2.4, it allows to be extended by future reduction procedures. No special constraints are placed on future reduction procedures, but it is expected that they will enjoy the following propertis Size reduction The size of the reduced packet is a fraction of the size of the original content packet. Although it is not necessary that the ratio between the sizes of the content and the reduced packet is constant, in the following, for illustrative purposes we will suppose that the reduced packet is R times smaller than the content packet. We will call R the _reduction factor_ Parametrization The reduction procedure is parametrized by a set of reduction parameters. Using different reduction parameters gives rise to different reduced versions of the content packet. Bernardini, et al. Expires July 12, 2012 [Page 9] Internet-Draft PPETP January 2012 Reconstruction The content packet can be recovered from the knowledge of a suitable number of different reduced versions. In some reduction scheme (e.g., the Vandermonde profile described in Section 14.5.1) the number of required reduced versions is constant and equal to R, but this is not mandatory. For example, in an hypothetical reduction scheme based on digital fountains, the number of required reduced versions would be a random variable. 2.5.1.1. An example of reduction scheme The easiest way to create a reduction function is by using linear combinations in Galois fields. In order to clarify the ideas introduced above, it is worth to show an example based on Reed- Solomon codes. The scheme briefly described here is at the basis of the Vandermonde reduction scheme described in Section 14.5.1. Suppose the content to be trasmitted can be represented as an R-dimensional column vector C=[c1, c2, ..., cR]^t whose entries belong to a Galois field GF. Each node chooses an element b of GF and constructs the row vector r_b = [1, b, b^2, ..., b^(R-1)] In order to "reduce" C, the node multiplies it by r_b to obtain the scalar u_b = r_b*C reducing in this way the sequence C of R values to a single GF element u_b. In order to recover C a node contacts R peers, collects the values u_b1, u_b2, ... u_bR and solves the linear system | u_b1 | | 1 b1 b1^2 ... b1^(R-1) | | u_b2 | | 1 b2 b2^2 ... b2^(R-1) | | : | = | : : : : | * C | u_bR | | 1 bR bR^2 ... bR^(R-1) | Since the matrix above is a Vandermonde matrix, C can be recovered as long as all the b1, b2, ..., bR values are different. 2.5.1.2. Consequences of reduction scheme Employing reduction functions has several interesting consequences Bernardini, et al. Expires July 12, 2012 [Page 10] Internet-Draft PPETP January 2012 Bandwidth reduction The upload bandwidth can be easily adapted to the node capabilities. The bandwidth required to nodes with small upload bandwidth can be as small as 1/R of the content bandwidth (for nodes with even smaller bandwidth puncturing can be employed, see Section 2.5.2). Nodes with large upload bandwidth can be exploited by having them to serve several peers or by requesting them to produce more than a reduced version by applying the reduction procedure more then once, using different reduction parameters. (In the case described in Section 2.5.1.1 this would mean to use different vectors r_b with the same vector C). If a node produces more than one reduced version, it can send more than one reduced stream to the same peer. Reliability To counteract the risk of packet losses (due to network congestion, peer leaving or other reasons) the node can request data from N > R peers and it will be able to recover the content as long as it receives at least R reduced packets out of N. Counteracting poisoning To counteract the stream poisoning attack it suffices to receive data from N > R peers, recover the packet using R reduced packets and check that the remaining reduced packets are coherent with the reconstructed packet. It is possible to show that if the check is positive, the reconstructed packet is equal to the original packet even under a coordinated attack from at most N-R peers. 2.5.1.3. Reduction profiles The reduction procedure described above is not the only possible approach for data reduction. For example, other reduction procedures (e.g., based on digital fountains or the Chinese Remainder Theorem) could be used instead of the product by the Vandermonde matrix. In order to allow for future adoptions of different reduction procedures, PPETP does not mandate a specific reduction procedure, but demands such a description to side documents describing the so called "reduction profiles". (An approach like this is used, for example, in RTP [RFC3550].) At the time of writing of this document two reduction profiles are defined: the _Vandermonde_ profile (that uses the reduction procedure of [DCC08] described above) and the _Basic_ profile that does no reduction at all, that is, the reduced packet is equal to the content packet. The Basic profile is thought for streams with very low bandwidth requirements where the bandwidth saving is not worth the complexity of a "true" reduction profile. For example, the Basic profile could be used, in a single-server context, to distribute to the clients the RTCP packets produced by the server. Bernardini, et al. Expires July 12, 2012 [Page 11] Internet-Draft PPETP January 2012 2.5.2. Data puncturing It is clear that the reduction factor must be chosen on the basis of the total bandwdith required by the multimedia content and the minimum upload bandwidth available to the nodes. Depending on the applicative context, it could happen that the resulting reduction factor is too large. For example, if a high-quality content requires 4 Mbit/s and the lowest available upload bandwidth is 256 kbit/s, the minimum reduction factor is equal to 16. Using large reduction factors can give rise to some problems such as an increased computational cost (since RxR matrices are required) and a reduced efficiency due to the fact that for large reduction factors the overhead due to the headers can become non-negligible. In order to handle cases that would require too large reduction factors, PPETP can further reduce the required upload bandwidth by requiring to the node to puncture a data stream. PPETP introduces two types of puncturing Probabilistic puncturing Packets are randomly discarded with a given probability (specified at handshaking time). Deterministic puncturing The packet with sequence number N is transmitted only if N mod M belongs to { m1, m2, ..., mL}, where M and m1, ..., mL are specified at handshaking time. A different set of puncturing parameters can be specified for every triple (peer, channel, priority class). 2.6. Priority class In some applicative context one can have packets with different importance. For example, if a scalable codec is employed one has packets related to the base layer and packet related to the enhancement layers. Since no decoding is possible if the base layer is not received, it can be useful to give different priorities to packets relative to different layers. In order to allow for a different prioritization between data packets, PPETP allows to assign to each packet a _priority class_, represented by an 8-bit integer. PPETP does not define a specific meaning for the priority class value, the only constraint is that the packet priority must be a non-increasing function of the value of this field (that is, class 0 has the largest priority). The priority class value is used in the following contexts Bernardini, et al. Expires July 12, 2012 [Page 12] Internet-Draft PPETP January 2012 o It MAY be used by the reduction procedure (see Section 2.5) to adapt the reduction to the packet class. o Different puncturing probabilities (see Figure 11) can be assigned to different classes. o The congestion control procedure (see Section 6.5) MAY reduce the output rate by dropping packets on the basis of their priority. 3. Preliminary definitions This section defines some basic concepts used in the PPETP. 3.1. Address and name of a PPETP session Since a PPETP session is a distributed structure, it has not a "natural" concept of "address." Nevertheless, for compatibility with currently available protocols (e.g., SDP [RFC4566]) it is convenient to be able to refer to a PPETP session with an (host address, port) pair. Since a PPETP session is a complex object that needs to be configured, a natural choice for the IP address associated to a PPETP session is the address of a "configuration server" that the node must contact to join the PPETP session. The server is queried using a special light-weight protocol described in Section 10.1. The role of the port is played by the "PPETP session number" a 16-bit unsigned integer that together with the host address uniquely identifies the PPETP session. 3.1.1. Default name of a PPETP section In some context (see, for example, Section 11 and Section 12) it is useful to refer to a PPETP session with a "name". The session name can be set during the configuration phase, but if the session is identified by an address as described above, the default session name is obtained by concatenating o The pseudo-port, expressed with four hexadecimal digits (with possibly leading zeros) with lower-case letters, according to the ASCII encoding. o An octect with (decimal) value 64 (corresponding to ASCII "@") o The pseudo-address of the session [remark-unique-name] Bernardini, et al. Expires July 12, 2012 [Page 13] Internet-Draft PPETP January 2012 3.2. Upper peers, lower peers and peer ID If node A receives data from node B, we will say that A is a "lower peer" of B and that B is an "upper peer" of A. (This nomenclature is inspired to the typical picture where data flow from top to bottom). The set of upper and lower peers of a node is the "neighborhood" of the node. In a PPETP network every peer is identified by a non-null 32-bit peer ID. The peer ID has the same size of the RTP SSRC, so that in an application employing RTP the two identifiers can coincide (but this is not mandatory). 3.3. Packet source and packet sender For each packet received by a node we distinguish the packet _source_ from the packet _sender_ o The packet _sender_ is the peer that sent us the packet (in other words, it is the peer whose IP address is in the IP header). The packet sender is always a neighbor of the node. o The packet source is the peer that _produced_ the packet. For example, in a video streaming application the source of a video packet is the peer "connected to the camera". The difference between the two concepts will be important in the context of routed packets (see Section 5.3). We will occasionally use "originator" and "forwarder" as synonymous, respectively, of "source" and "sender". 3.4. Source signature and sender signature In order to counteract a number of possible security problems (see discussion in Section 9), PPETP introduces the possibility of signing a packet. Since a packet can have two different "origins" (its "source" and its "sender", see Section 3.3), two different types of signature are introduced: source and sender signature. The differences between Sender and Source signatures will be clear in the following, here we can anticipate that o The Source signature grants for the identity of the node that _created_ the packet, while the Sender signature grants for the identity of the node that _forwarded_ the packet. Bernardini, et al. Expires July 12, 2012 [Page 14] Internet-Draft PPETP January 2012 o The Sender signature depends on the identity of the forwarder and changes as the packet travels along the network, the Source signature depends only on the creator and it remains the same in every point of the network. o As it will be clear in Section 5.3, the number of packets that need a Sender signature is much larger than the number of packets that need a Source signature; therefore, the procedure to verify a Source signature can be slower than the procedure for checking a Sender signature. o It will be clear in the following (see Section 5.3) that the Sender signature needs to be checked _only_ by the recipient, while the the Source signature needs to be checked by _all_ the nodes that forward the packet. This implies that the Sender signature can be obtained from a secret shared between the sender and receiver, while the Source signature must employ asymmetric techniques. 3.5. Streams and packets A PPETP network carries a content made of one or more "streams"; each stream is a sequence of packets (called also "content packet" to distinguish them from "reduced packets") originated from a source. Each stream in a session is uniquely identified by its ID represented by a 8-bit integer value. For example, in an "Internet radio" application one has only one stream and one source, while in a conferencing application there is a stream for every participant and every participant is a source. Each content packet in a stream is uniquely identified by its "sequence number" that increases by one at each packet. Since a PPETP sequence number is a 24-bit integer, if the content packets are RTP packets, the 20-bit RTP sequence number can be used also as the PPETP sequence number (but this is not mandatory). It is worth emphasizing that different streams have different sequence number spaces, so that two packets belonging to different streams can share the same sequence number. Alternatively, one could say that a packet in a session is uniquely determined by the 32-bit number obtained by joining together the 8-bit stream ID and the 24- bit sequence number. Bernardini, et al. Expires July 12, 2012 [Page 15] Internet-Draft PPETP January 2012 3.6. PPETP channels A node in a PPETP network can produce several reduced versions of the same content packet by processing it several times, each time with a different set of reduction parameters. The stream of packets associated to a single set of reduction parameters is called a "channel". Each node can have at most 16 channels, identified by a 4-bit channel ID; every channel can be connected to any number of lower peers. The number of peers connected to the same channel is limited only by the node upload bandwidth. 3.7. Glossary Channel: A channel is a stream of reduced packets relative to the same set of reduction parameters. Content packet: A packet of the multimedia content to be distributed. See also Reduced packet. Lower peer: A node X is a lower peer of node Y if Y sends its reduced data to X. See also upper peer. Packet sender: The node that transmitted the packet. Compare with packet source. Packet source: The node that created the packet. It can be different from the node that sent the packet if the packet was routed over the PPETP network (see Section 5.3). Compare with packet sender. Peer ID The non-null 32-bit number that uniquely identifies a peer in a PPETP network. Reduced packet: A packet carrying the data obtained by applying a reduction procedure to a content packet. Reduction function: A procedure to process content packets to map them into smaller packets with the property that the original content packet can be recovered when enough reduced packets are available. Bernardini, et al. Expires July 12, 2012 [Page 16] Internet-Draft PPETP January 2012 Stream A sequence of content packets originated from a single node. Stream ID The 8-bit number that uniquely identifies a stream in a PPETP network. Upper peer: A node Y is an upper peer of node X if Y sends its reduced data to X. See also lower peer. 4. Basic type formats In PPETP there are some data types that are used in many places. For the sake of convenience, this section collects the binary formats used for those data types. 4.1. Chain-encoding of 15-bit integers In several places there is the need of encoding small integer values. Since the typical expected values are small, an 8-bit value should suffice for most cases, even if one cannot be granted that the need of encoding larger values will never arise. This would suggest to use two octects to encode the integer, but in most cases this could reduce the efficiency. In order to solve this problem, PPETP uses a special variable-length encoding (sometimes called "chain-encoding") that can represent numbers of at most 15 bits, but that uses only one octets if the value is not larger than 127. More precisely, the value is stored in one or two consecutive octets as follows. 1. Let 0 <= N < 32768 the value to be encoded. 2. If N < 128, only one octet is used and N is stored as it is in the octet 3. If N >= 128, two octets are used. More precisely, value 128 + (N mod 128) is stored in the first octet while value N/128 is stored in the second one. In other words, the most significant bit of firs octet is used as a flag: if it is zero, it means that N was smaller than 128 and only one octet was used; otherwise N was larger or equal than 128 and two octets were used. For example, the sequence of integers 112, 42, 260, 33 would be encoded in the sequence of octets Bernardini, et al. Expires July 12, 2012 [Page 17] Internet-Draft PPETP January 2012 112 42 132 2 33 Note that 132 = 128 + (260 mod 128) and 2 = 260/128. 4.2. Channel mask In PPETP every node can produce up to 16 different reduced streams, called channels. In order to specify a subset of the channels, PPETP uses a _channel mask_ represented by a 16-bit unisgned integer with the least significant bit corresponding to channel 0 (i.e., the coefficient of 2^n correspond to channel n) and each bit 1 means a selected channel. Although this is the opposite convention of the usual network order, it has been chosen since in some context (e.g., in the Compact Configuration Description Format of Section 10.2) makes the description of the most common case (where only the first few channels are used) more compact. 4.3. Type-Length-Value format In several places PPETP encode parameters in a TLV (Type, Length, Value) format as follows o The first octet encodes the type of the attribute. Note that the attribute class is not encoded since it is always implied by the context. o The successive one or two octets encode the length of the value of the attribute in the 15-bit format described in Section 4.1. o The successive Length octets encode the attribute value. The format depends on the specific attribute. 4.4. Generalized addresses In order to contact an host in Internet one needs the IP address of the node and the port the node is listening to. However, nowdays many nodes (especially residential users) are behind NATs and this makes their IP address (i.e., the IP address associated to their network interface) useless for hosts outside the NAT. In order to contact a node behind a NAT one needs to do some connection establishment procedures (CEP) and in order to do that one need a set of information different from the IP address and port of the target node. In order to unify the handling of connections, indipendently on the connection type employed, we introduce the concept of _generalized address_ that can be interpreted as a set of "instructions" that explain how to contact the node. Bernardini, et al. Expires July 12, 2012 [Page 18] Internet-Draft PPETP January 2012 Generalized addresses are partitioned into _address classes_. Addresses belongin to the same class require the same set of informations. Currently defined address classes are ipv4, ipv6 The node can be reached directly. The informations required are the IP address and the port of the remote node. ice4, ice6 The ICE-based CEP of Section 11 is used. The informations required are the address of a bridge node and the ID of the other peer (see Section 11 for details). +------+-------+---------------+ | Name | Value | Defined in | +------+-------+---------------+ | ipv4 | 0 | Section 4.4.2 | | ipv6 | 1 | Section 4.4.2 | | ice4 | 2 | Section 4.4.3 | | ice6 | 3 | Section 4.4.3 | +------+-------+---------------+ Table 1: Values for the address class of a generalized address It is supposed that every new class of generalized address will define a procedure that converts the generalized address in a pair (source socket address, target sockt address) to be used for the communication between the peers (here with "socket address" we mean a (port, IP address) pair). 4.4.1. Generalized addresses format Every time it is necessary to include a generalized address in a PPETP packet, the format described in this section (see also Section 4.4) is used. o The generalized address is in the TLV format described in Section 4.3, with the type field identifying the address class. This document define address classes _ipv4_ (class=0), _ipv6_ (class=1), _ice4_ (class=2) and _ice6_ (class=3). o The value is called the "core" of the address. The format of this field depends on the address class. Bernardini, et al. Expires July 12, 2012 [Page 19] Internet-Draft PPETP January 2012 4.4.2. IPv4 and IPv6 address classes The format for the two IP address classes is shown in Figure 1. The fields have the following meaning Protocol (bits 8-15) Transport protocol. This is the same value of the Protocol field in the IP header [RFC0791] Port (bits 16-31) If the transport protocol uses b-bit port numbers, with b <= 16, (e.g., UDP, DCCP [RFC4340], we will say that the protocol is _port based_) this field is set to the destination port number (possibly with the most significant bits set to zeros if b < 16); otherwise it is set to zero. Address This field contains the IP address of the remote host. Its size depends on the value of the class (if ipv6 or ipv4) and on protocol field. This document defines only the following cases restricted to protocol UDP IPv4 class The Address field is 32 bits long and contains the IPv4 address IPv6 class The Address field is 128 bits long and contains the IPv6 address 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Address : : (size depends on Version and Protocol) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Core of a generalized address of IP class 4.4.3. ICE address classes (ice4 and ice6) The format for the core of ice4 and ice6 address classes is shown in Figure 2. The difference between ice4 and ice6 is in the IP version of the bridge address. The fields have the following meaning EXCH Protocol (bits 8-15) The procedure used by the nodes to exchange ICE candidates. Currently only two protocols are defined Bernardini, et al. Expires July 12, 2012 [Page 20] Internet-Draft PPETP January 2012 Protocol 0 The HTTP-based procedure described in Section 11 Protocol 1 Like protocol 0, but using HTTPS instead of HTTP. Values 2-254 are undefined, value 255 is reserved for future extensions. Peer ID The 32 bit Peer ID of the remote peer Address This field contains the IP address of the bridge node. In the ice4 class it is 32 bits long and it stores the IPv4 address of the bridge; in the ice6 class it is 128 bits long and it stores the IPv6 address of the bridge. Other data This field can be used to store data that can be used by the exchange protocol and its format depends on the specific exchange protocol used. The format for protocols 0 and 1 is described in Section 11.1.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 +-+-+-+-+-+-+-+-+ : : : | EXCH Protocol | : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Bridge Address : : (size depends if ice4 or ice6) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Private data (size and format depend on EXCH Protocol) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Core of a generalized address of ICE class 4.5. Peer reference A "peer reference" is the concatenation of the peer ID with the generalized address of the peer. It is used in several places in PPETP. See Figure 3. Bernardini, et al. Expires July 12, 2012 [Page 21] Internet-Draft PPETP January 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Generalized Address : : (variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of a peer reference 5. PPETP packets The packets exchanged by PPETP nodes can be classified as data packets, control packets and routed packets. Data packets are the most common ones and carry as payload the outcome of the reduction procedure. Data packets have a sequence number, a stream ID (both inherited from the original content packet) and a channel number. Data packets are not acknowledged. Control packets are mainly used during session setup and for data flow control. Control packets require an acknowledge, the only exceptions to this rule are the Acknowledge control packet and the Feedback packet (see Section 5.2) that are never acknowledged and the routed packets that are acknowledged only by the target node . Routed packets are, actually, a special type of control packet. They are used to route control packets over the P2P network and can be useful when the target peer is behind a NAT and it is not reachable. See Section 5.3 for details. 5.1. Data packets Figure 4 shows a graphical representation of a data packet. The fields have the following meaning Version (V, bits 0-1): This field identifies the protocol version. This document describes V=00. Control (C, bit 2): This bit is used to distinguish control and data packets and it is always 1 in control packets. Padding (P, bit 3) Similarly to the RTP specification [RFC3550], if this bit is set, the packet *payload* contains one or more additional padding octets at the end. The last octet of the *payload* contains a count of how many padding octets should be ignored, including itself. Note that any signature field is added Bernardini, et al. Expires July 12, 2012 [Page 22] Internet-Draft PPETP January 2012 _after_ payload padding. Inline (I, bit 4) If this bit is 1, the reduction parameters used to compute this packet are included in the payload. The reason for including this bit is that even if a node does not receive enough reduced packets to recover the content packet, it can nevertheless propagate the information to its lower peers by "replaying" one of the received reduced packets. The problem in doing this is that the replayed packets could have been obtained by using reduction parameters different from the parameters chosen by the node. By setting this bit to 1, the node can temporally override the default reduction parameters declared at handshaking time. The format used to insert the reduction parameters in the payload is defined by the reduction profile. If the reduction profile does not need this bit, it can redefine it. Flags (F,G and H bits 5-7) Similarly to the Marker bit in RTP, The meaning of these bits is defined by the reduction profile. Timestamp (bits 8-23) The time the packet was sent, expressed as the number of milliseconds since 1/1/1970 modulo 2^16. This field can be used to estimate the traveling time (potentially useful for congestion control, see, for example, Section 6.5) by subtracting this value from the current time modulo 2^16 . Note that the modulo 2^16 introduces an ambiguity of approximately 65 seconds, but this should not be a problem. PPETP magic (bits 24-31): This octet helps in distinguishing PPETP packets from other packets that could be necessary to send/receive using the PPETP port (e.g., STUN packets that are used to do ICE or other NAT-traversal procedures). The value of this field can be changed during the configuration phase to adapt it to any "parallel protocol" used. If not changed, the value of this octet is (decimal) 95. Note that since in a STUN packet this octet is always a multiple of four, the default value allows to distinguish PPETP and STUN packets. Stream ID (bits 32-39) The stream ID of the original content packet (see Section 3.5). Stream ID=255 is reserved. Sequence number (bits 40-63) The sequence number of the original content packet. As said in Section 3.5, this is a 24-bit integer, so that the 20-bit RTP sequence number can be used if the content packets are RTP packets (but this is not mandatory). Similarly to the requirements in the RTP specification [RFC3550], it is suggested that the initial value of this field SHOULD be random (unpredictable) to make known-plain-text attacks on encryption more difficult. Bernardini, et al. Expires July 12, 2012 [Page 23] Internet-Draft PPETP January 2012 Class (bits 64-71) The value of this byte represents the "priority class" associated with the packet. PPETP does not define a specific meaning for this field; the only requirement is that the packet priority must be a non-increasing function of the value of this field. In other words, if the class of packet A is smaller than the class of packet B, then the priority of A is not smaller than the priority of B (but it can be equal). This value can be used by the reduction procedure in order to adapt reduction to the data importance; it can be used to change the puncturing probability and it could be used to drop less important packets to reduce the rate (e.g., if DCCP [RFC4340] is used as transport protocol). Class 254 is reserved for future extensions and class 255 is invalid. Channel (bits 72-75) The channel number. Reserved (bits 76-79) These bits are not used. They SHOULD be set to zero by the transmitter and MUST be ignored by the receiver. Rate Control Data (variable size) The first variable field after the fixed header is reserved to the rate control mechanism. In this field the sender can store any information required by the lower peer in order to implement the rate control procedure. For example, with the TFRC-based rate control procedure (see Section 14.6.2) this field stores the estimated round trip time. Payload (variable size) An opaque sequence of octets. The format of the payload is defined by the reduction profile. Sender signature (variable size) This is a variable size optional field with the sender signature. In order to avoid a defamatory attack (see Section 9.1.2), in PPETP a node can be requested to attach at the end of the packet its sender signature. The way the signature is created and stored in this field is defined by the sender signature profile employed (see Section 13.3.1). Bernardini, et al. Expires July 12, 2012 [Page 24] Internet-Draft PPETP January 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|C|P|I|F|G|H| Timestamp | PPETP Magic | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Stream ID | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class |Channel| Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Rate Control Data (variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Payload (variable size) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Sender Signature (variable size) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: PPETP data packet 5.2. Control packets In PPETP the connection between two peers is managed by means of control packets. Control packets are expected to be typically sent from the source node to the target node, but, in order to cope with some problems due to NATs, PPETP allows control packets to be routed along the peer-to-peer network. Control packets routed along the PPETP network are called "routed packets" and are described in details in Section 5.3. 5.2.1. Control packet format A graphical representation of a control packet is given in Figure Figure 5. The fields have the following meaning Version (V, bits 0-1): This field identifies the protocol version. This document describes V=00. Control (C, bit 2): This bit is used to distinguish control and data packets and it is always 1 in control packets. Padding (P, bit 3): See the corresponding description for the data packet. Bernardini, et al. Expires July 12, 2012 [Page 25] Internet-Draft PPETP January 2012 Request (bits 4-7): The actual request. Request values from 0 to 10 are defined in this document. Request value 15 is used to mark routed packets (see Section 5.3). Zero (bits 8-23) These two octets are unused and they SHOULD be set to zero by the transmitter and MUST be ignored by the receiver. PPETP magic (bits 24-31): This octet helps in distinguishing PPETP packets from other packets. See the description of the corresponding field in data packets for details. Sequence Number (bits 33-64): The sequence number in control packets serves two purposes: it allows the packet recipient to discard duplicate control packets and it is inserted in the Acknowledge packet sent back to the sender. Note that control and data packet have two different sequence number spaces; moreover, while the data packet number space is global to the whole network, each peer has its own control packet number space. The only constraints are (1) that the sequence number must be monotone increasing and (2) that the pair (sender, sequence number) identify uniquely the control packet (but see Section 6.1 for details about packet retransmission). Payload (variable size): Its meaning and format depends on the specific request. Sender signature (variable size) See the description of the corresponding field in data packets. Bernardini, et al. Expires July 12, 2012 [Page 26] Internet-Draft PPETP January 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|C|P|Request| Timestamp | PPETP Magic | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Payload (variable size) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Sender Signature (variable size) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PPETP control packet Figure 5: PPETP control packet 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Attribute List (variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Payload of Set_Parameter 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSN |0| Result | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Payload for the Acknowledge request Bernardini, et al. Expires July 12, 2012 [Page 27] Internet-Draft PPETP January 2012 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 mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Peer reference : : (variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Attribute List (variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Payload for the Start request 5.2.2. Request types The following requests are defined, the corresponding values for the Request field can be found in Table 2 Set_Parameter This request is sent by an upper peer during the handshaking phase to communicate to a new lower peer the set of reduction parameters chosen by the sender. The payload can be empty or it can contain the 32 bit Peer ID of the upper peer followed by a list of attributes in TLV format (see Table 6). If the payload is empty, this request is basically a no-op that just triggers an Acknowledge with error code 0 (OK) from the target node. Currently the only accepted attribute is REDUCTION_PARAMETER (see Section 7). Acknowledge This type of control packet is used to acknowledge the receipt of other control packets. The payload is 6 octects long and it is obtained by concatenating the 32-bit sequence number of the acknowledged packet, the SSN of the acknowledged packet (1 octect) and 1 octect with an error code. The specific meaning of the error code depends on the command acknowledged, but see Table 3 for an overview of the possible values. The zero value has always the meaning of "positive acknowledge" (i.e., no error occurred). Data Control Requests This group of requests is used to control the data stream between two nodes. With this command we can ask a node to send data to a new lower peer, to stop the data transmission toward another node, to redirect a data flow from a node to another or to start the hole punching procedure. It is not mandatory to control the data flow through this type of packets. Data flow can be controlled, for example, via a suitable API called in response to command received via an application level protocol. Having a suitable set of data control requests Bernardini, et al. Expires July 12, 2012 [Page 28] Internet-Draft PPETP January 2012 increases the flexibility of the protocol. Start Begin streaming to a peer, doing, if necessary, the handshaking procedure described in Section 8. The payload is obtained by concatenating the channel mask (2 octet, see Section 4.2), the Peer reference of the new peer (variable size, see Section 4.5) and a possibly empty list of attributes in TLV format (see Section 7). The following attributes are admitted PUNCTURING: In order to further lower the upload bandwidth requirements and allow a finer control of the upload bandwidth, it is possible to ask the node to operate a puncturing of the data sent to the lower peer. From the point of view of the recipient, this is almost equivalent to receiving data over a lossy channel. This document defines two modes of puncturing: "probabilistic puncturing", where the decision of sending the packet is taken randomly and "deterministic puncturing", where the decision of sending a packet is taken on the basis of its sequence number (see Section 7 for details). This attribute is used to set the puncturing rate and mode associated to the lower peer. ROUTING_PROBABILITY: Set the probability of sending a _routed packet_ to this lower peer (see Section 6.4 for details). Please note that this attribute is about the forwarding of routed packets, while PUNCTURING is relative to the propagation of data packets. The corresponding Acknowledge packet will have the Result field set as follows Result=0 (OK) The handshaking procedure completed successfully and the streaming toward the new lower peers has started. Result=1 (NO_Resource) The node has exhausted its share of upload bandwidth and it cannot satisfy the request. Result=2 (NO_Reply) The handshaking procedure did not complete successfully since the lower peer did not acknowledge the Set_Default request (see the handshaking procedure in Section 8). Bernardini, et al. Expires July 12, 2012 [Page 29] Internet-Draft PPETP January 2012 Stop Stop sending data to the target specified in the packet. The payload is obtained by concatenting the channel mask (2 octects, Section 4.2) and the Peer ID of the lower peer. The corresponding Acknowledge packet will have the Error field set as follows Result=0 (OK) No error, the streaming toward the lower peers has stopped. Result=3 (NO_Target) The target specified in the packet is not a lower peer of the node or it is not receiving data from the specified channel. Redirect This request is _almost_ equivalent to a Stop request followed by a Start request, with the difference that this action is atomic, so that it is granted that the node will always have enough upload bandwidth available. The payload is obtained by concatenating + The Peer ID of the old peer (4 octets) + The mask of channels to be stopped (2 octet) + The Peer reference of the new peer (variable size, Section 4.5) + The mask of channels to be started (2 octet) + A (possibly empty) list of attributes in TLV format (see Section 7). The accepted attributes are PUNCTURING and ROUTING_PROBABILITY and they are interpreted as for the Start command. The corresponding Acknowledge packet will have the Result field set as follows Result=0 (OK) No error, the streaming to the old lower peers has stopped and the streaming to the new peer has started. Result=2 (NO_Reply) The handshaking procedure did not complete successfully since the lower peer did not acknowledge the Set_Default request (see the handshaking procedure (Section 8)). The streaming to the old peer is nevertheless stopped. Bernardini, et al. Expires July 12, 2012 [Page 30] Internet-Draft PPETP January 2012 Result=3 (NO_Target) The old peer is not a lower peer of the node. No action is taken. Receive This command requires the recipient to contact a remote peer and send to it a Start request. The payload is obtained by concatenating + The Peer reference of the new peer (variable size, Section 4.5) + The mask of channels to be started (2 octets, Section 4.2) + A (possibly empty) list of attributes in TLV format (see Section 7). The accepted attributes are PUNCTURING and ROUTING_PROBABILITY and they are interpreted as for the Start command; alternatively, the attribute list can contain the single attributed EMBEDDED_PACKET whose value is to be interpreted as a routed packet to be sent to the new peer. If the EMBEDDED_PACKET is present, the attributes PUNCTURING and ROUTING_PROBABILITY should be absent, if they are present, they MUST be ignored. Moreover, If the EMBEDDED_PACKET is present the channel mask MUST be ignored and SHOULD be set to 0. The requests associated to the embedded packet MUST be Start or Redirect; if the embedded packet has a different request, the whole Receive request MUST be ignored. Closing This command is used to communicate to a lower peer that the peer is going to stop the transmission of one or more channels. The payload is obtained by concatenating the channel numbers of the channels that are to be closed. If the payload is empty, all the channels are to be closed and the peer is leaving the network. If no Acknowledge is received after a suitable timeout, the node sending this request MAY close the channels anyway (in contrast with the general principle that a node cannot suppose that a command was executed until it receives a positive Acknowledge). Hello This request is used during the introduction phase. The payload (shown in Figure 9) can carry a list of peer-local parameters (in TLV format) to be associated with the peer. The parameters defined in this document are all cryptography-related, but non-cryptography-related parameters can be defined in the future. Peer ID (bits 0-31) This is the only mandatory fields. It contains the ID of the peer associated with the credential. Bernardini, et al. Expires July 12, 2012 [Page 31] Internet-Draft PPETP January 2012 List of parameters This is a (possibly empty) list of parameters in TLV format. Plugin definitions can define new parameters. For example, peer parameters are defined by the source and sender signature procedures defined in this document. Type 0 is used for "certificate data" and its value is given, as an opaque bitstring, to the Hello signature verifier. Its format depends on the Hello signature procedure employed. This is the only request that is not signed with the sender signature, but with an alternate algorithm. This is due to the fact that when this packet is received the target peer does not know the credentials of the remote one. See Section 5.2.3 for details. Open This request requires the node to start a Connection Establishment Procedure toward a peer. The payload is the concatenation of the Peer ID of the new peer and its generalized address. Feedback This request is used by the lower peer to send feedback about the reception statistics to the upper peer. The upper peer will use this information to do congestion control. Feedback packets are not acknowledged. Shutdown This request is used to signal to the peer that the whole PPETP session is going to shutdown. +---------------+-------+ | Name | Value | +---------------+-------+ | Set_Default | 0 | | ACK | 1 | | Start | 2 | | Stop | 3 | | Redirect | 4 | | Receive | 5 | | Close | 6 | | Hello | 7 | | Open | 8 | | Feedback | 9 | | Shutdown | 10 | | Undefined | 11-14 | | Routed Packet | 15 | +---------------+-------+ Table 2: Values for the Request field of a control packet Bernardini, et al. Expires July 12, 2012 [Page 32] Internet-Draft PPETP January 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer ID : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : List of Credentials (possibly empty) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Payload of the HELLO packet +----------+-------+------------------------------------------------+ | Name | Value | Explanation | +----------+-------+------------------------------------------------+ | OK | 0 | The request was processed successfully | | NO | 1 | It was not possible to satisfy the request for | | Resource | | lack of resources (e.g., upload bandwidth) | | NO Reply | 2 | An handshaking procedure did not complete | | | | because no Acknowledge was received to a | | | | Set_Default request | | Bad | 3 | It was requested to stop the data streaming to | | Target | | a node that is not a lower peer. | +----------+-------+------------------------------------------------+ Table 3: Values for the Result field of the Acknowledge packet 5.2.3. Signing Hello requests Hello requests are used during the handshaking phase to communicate to the target peer the set of peer-local parameters chosen by the source peer. The set of peer-local parameters includes signature- related parameters such as the Diffie-Hellman half-key for the sender signature of Section 14.1.1 or the public key for the source signature of Section 14.2.1. Note that Hello requests are peculiar because when a node receives the request, it does not know yet the cryptographic information that would allow it to verify the sender signature (the Hello packet is actually used to exchange these cryptographic data). This implies that Hello packets should be sent without signature or, alternatively, they should be signed with a different algorithm. Note, however, that sending Hello packets without signature is not advisable since they are used to exchange cryptographic data, and sending them unsigned would make man-in-the-middle attacks feasible. This implies that Hello packets need to be signed by a third type of signature (called "hello signature"), different both from the source Bernardini, et al. Expires July 12, 2012 [Page 33] Internet-Draft PPETP January 2012 and the sender signature. Similarly to what is done for source and sender signature, even for Hello signatures PPETP uses the plugin approach and defines the following two built-in hello signature procedures void Hello packets are not signed. Given the importance of Hello packets for security, this procedure should be used only in well- controlled environments that pose no security threat. id-based Hello packets are signed by using the identity-based algorithm described in Section 12. Other values can be registered at IANA, see Section 13 for details. 5.3. Routed control packets As anticipated, routed packets are control packets that are not sent directly from the source to the target, but are routed along the P2P network. In order to understand why they are necessary, consider the following scenario: Alice and Bob are both behind a NAT, Alice already joined the network and Bob wants to join and have Alice as upper peer. Since Alice is behind a NAT, Alice and Bob must do a NAT traversal procedure. However, Alice does not know that Bob needs to communicate with her, so "someone" (say, the bridge node used in the ICE procedure of Section 11) must send to Alice an Open request. Unfortunately, since Alice is behind a NAT, she is unreachable by the bridge node too. In order to solve this impasse, the bridge can envelop the Open request in a routed packet that is sent together with the data packets over the P2P network. Since Alice is receiving data packets, we are granted that she will receive the routed packet too. Bernardini, et al. Expires July 12, 2012 [Page 34] Internet-Draft PPETP January 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=0|C|P| 15 | 0 | SSN | PPETP Magic | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target PEER ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source PEER ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ACK Target : : variable size, generalized address of class IP : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Payload, i.e., transported control packet : : (variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Source signature (variable size) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Sender Signature (variable size) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PPETP Routed packet Figure 10: PPETP routed packet 5.3.1. Structure of a routed packets The format of a routed packet is shown in Figure 10. The meaning of the fields is as follow Version (V, bits 0-1): This field identifies the protocol version. This document describes V=00. Control (C, bit 2): This bit is used to distinguish control and data packets and it is always 1 in routed packets. Padding (P, bit 3): See the corresponding description for the data packet. Bernardini, et al. Expires July 12, 2012 [Page 35] Internet-Draft PPETP January 2012 15 (bits 4-7): This field corresponds to the request field in control packets and it is fixed to 15 in embedded packets. Zero (bits 8-15) This octect MUST be zero. If it is different from zero, the receiver MUST discard the packet. (Values different from zero could be used in future extensions) Sub-sequence number (SSN, bits 16-23): According to Section 6.1, if a packet has not been acknoweldged within a timeout, a node can try to retransmit the same command, using the same Sequence Number so that the recipient can recognize if a packet is a copy of a previous packet. This simple mechanism could be used for a "flooding attack" with routed packets. It suffices for a malicious node to wait for a routed packet and send it again and again to its lower peers. The replicated packet is correctly signed, so the lower will propagate it to their lower peers, ... and so no. Note that lower peers cannot distinguish between a routed packet that was sent again by the source because the ACK did not arrive and a routed packet that was maliciously duplicated by some node. The SSN field has been introduced in order to avoid this attack. The source sets the SSN field to zero the first time a routed packet is sent and increments it every time a duplicated of the packet is sent. An intermediate node will discard a routed packet if the node already propagated a packet with the same _pair_ (Sequence Number, SSN). Note that a malicious node cannot artificially increase the SSN since this field is used to compute the source signature. PPETP magic (bits 24-31): This octet helps in distinguishing PPETP packets from other packets. See the description of the corresponding field in data packets for details. Sequence Number This is a copy of the sequence number of the control packet contained in the payload field. It is repeated here to make it easier to access it (the ACK Target field has a variable size, so one should parse it in order to find the position of the Sequence Number in the payload). Target ID It is the peer ID of the final recipient of the routed packet. If this field is 0, the packet is a _broadcast packet_ and it MUST be processed by all the peers. The only command that can be sent in broadcast mode is SHUTDOWN. Broadcast packet MUST NOT be acknowldeged. Every broadcast packet with request different from SHUTDOWN MUST be discarded. Bernardini, et al. Expires July 12, 2012 [Page 36] Internet-Draft PPETP January 2012 Source ID Is the peer ID of the source peer ACK Target This is the IP address of the node that will receive the ACK. It has the format of a generalized address of class IP. Payload This is the control packet that is actually routed. It must be equal to the complete control packet, header and magic number included. Its sequence number MUST be equal to the sequence number in the header field. If the two numbers are different, the packet is to be considered invalid and it SHOULD be discarded. Source Signature This is the source signature of the source peer. It covers the whole packet: header, payload and routing data. Sender Signature This is the signature of the forwarder peer. It covers the whole packet: header, routing, payload and source signature. A detailed description of how the routing is done can be found in Section 6.4. Here we just anticipate that each node that receives a routed packet for another peer, forwards it to its lower peers, taking into account the pruning probability associated with each lower peer. As described in Section 6.4, routed packets are not acknowledged by the intermediate peers, but only by the final recipient to the peer whose address is stored in the ACK Target field. 5.3.2. Signing routed packet Since the routing feature allows to send a packet to any node of the network, many applications would prefer to reserve this feature only to privileged nodes (e.g., servers). In order to avoid the possibility that a non-privileged node sends control packets to non- neighbors, a setup can request that the packet originator signs the routed control packet. The procedure to compute the source signature is specified by the source signature profile. Currently only the source signature profile "rabin" is defined (see Section 14.2.1), but other can be defined in the future. 5.3.3. Embedded packets The routing mechanism can be employed also with different routing mechanism. Consider the following situation: o We want to create a P2P network where the neighborhood relationships are decided by a central node, so that we can have a Bernardini, et al. Expires July 12, 2012 [Page 37] Internet-Draft PPETP January 2012 fine control of the amount of resources associated to a peer. o We want to lower the load of the central node by having the peers sending themselves the "Start" requests to their upper peers. o We want to enforce a security policy where only privileged nodes can send stream-control requests (i.e., Start, Stop, Redirect). The third requirement implies that the central node must send the Send request, but this is against the second requirement. The solution to this problem is that when a new node joins the network the central node chooses the upper peers of the new nodes, for every upper peer it creates and signs a routed packet with the Send request and gives the created routed packets to the new node by _embedding_ in the configuration data (for example). The node will send every embedded packet to the corresponding upper peer that will process it as an ordinary routed packet. The description above is just an example of use of the possibility of embedding routed packets into non-PPETP data. As another example of application, one can imagine a P2P network with a PPETP overlay for streaming data and a RELOAD overlay for other types of data. With this structure, PPETP commands can be sent to any peer by exploiting the RELOAD structure to send embedded packetes. Of course, the API of the software layer implementing PPETP must allow for passing embedded packets from the application level to the PPETP level. 6. Packet processing 6.1. Control packet transmission procedure All the control packets (with the exception of the Acknowledge, Feedback and Shutdown requests) require an Acknowledge. The procedure employed by a node that sends a control packet MUST conform to the following guidelines o The node MUST NOT assume that the control packet has been processed until it receives a positive acknowledge, the only exception to this rule is the Closing request, as explained in Section 5.2.2. o After sending the control packet the node sets a timeout for the reception of the Acknowledge. The following cases can happen 1. A _positive_ acknowledge is received before the timeout: the procedure terminates succesfully. Bernardini, et al. Expires July 12, 2012 [Page 38] Internet-Draft PPETP January 2012 2. A _negative_ acknowledge (i.e., an acknowledge that signals that an error occured) is received before the timeout: the procedure terminates with a failure. 3. No acknowledge is received before the timeout: the same control packet, with the same sequence number, is sent again to the recipient and a new timeout is set. If the number of retransmissions reachs a threshold fixed by the node, the procedure terminates with a failure. The retransmission timer must be computed according to [RFC2988]. 6.2. Control packet acknowledgement procedure From the control packet recipient side the following guidelines must be followed o The recipient MUST send the acknowledge only _after_ the successful processing of the packet. o If the recipient receives a packet with the same sequence number of an already acknowledged packet, it MUST send an Acknowledge again, but it MUST NOT process the request again. o Packets too old (in the sense that the difference between their sequence number and the most recent sequence number is larger than a threshold chosen by the node) or acknowledged too many times can be ignored by the recipient. The number of maximum acknowledgements is chosen by the implementation, but it should be at least 8. 6.3. Processing received packets The chosen format makes processing easy 1. The "PPETP magic" field is checked. If the check is positive, processing continues; otherwise the packet is handled by an extra-PPETP procedure (e.g., by a STUN library) 2. The Sender signature is checked. If the check is negative, the packet is discarded; otherwise, the procedure returns the packet with the signature stripped and the processing continues. 3. The Control bit is checked in order to find the type of the packet. If the packet is Bernardini, et al. Expires July 12, 2012 [Page 39] Internet-Draft PPETP January 2012 A data packet (Control=0): + The 64-bit header is parsed and stripped (so that only the rate-control data and the payload remain) + Any payload padding is removed + The packet is handled by the rate-control procedure that parses and strip the rate-control data field. Now only the payload remains. + The payload is given to the reduction-profile specific processing procedures. A control packet (Control=1, Request != 15): The padding (if present) is removed from the payload and the packet is processed. A routed packet (Control=1, Request=15): The packet is processed as described in Section 6.4. 6.4. Routing and acknowledging routed packet A node that receives a routed packet with valid sender signature, must 1. Check (if needed) the Source Signature. If it is invalid or if the source is not allowed to send routed packets, discard the packet 2. Check the sequence number and the SSN of the packet. If the triple (Source, Sequence Number, SSN) packet was already processed, discard the packet. 3. Check the Peer ID of the target and * If the Target ID is zero (broadcast packet) and the request is not Shutdown, discard the packet * If the target ID is zero or is equal to the node ID, the node processes the payload as if it was received from the network; if necessary, sends the Acknowledge to the address specified in the ACK Target field. * If the target ID is zero or is different from the node ID, the node, for every lower peer Bernardini, et al. Expires July 12, 2012 [Page 40] Internet-Draft PPETP January 2012 + Extract a random number between 0 and 1. + If the number is smaller than the ROUTING_PROBABILITY associated with the peer, forward the routed packet to the peer after signing it with the Sender Signature (if required). Note that a routed packet is acknowledged _only_ by the final target peer to the node whose address is specified in the ACK Target field and _not_ by the intermediate nodes that route the packet. See Appendix B.2 for a rationale for this type of Acknowledgement. The procedure above is actually a "flooding" of the PPETP network. One could suspect that this would cause an excessive load on the network. However, o It is expected that the rate of routed control packets will be much smaller than the rate of data packets, so that the increase in load is expected to be minimal. o The flooding is limited by the fact that if a node receives twice a packet with the same sequence number and same sub-sequence number, it ignores it and does not route it again. o Finally, if one desires to lower the bandwidth used by the routed control packets, PPETP allows to associate to each lower peer a "routing probability" that represents the probability of sending to a given lower peer a routed packet. Such a probability can be set by extra-PPETP means or by including parameter ROUTING_PROBABILITY in the Data_Control/Send command. By default the routing probability is 1. For example, a server could set some routing probability to zero in order to create a "routing network" that is a (connected) sub- graph of the actual PPETP network. Another example of usage could be the following: suppose N is the number of lower peers connected to a node; if one sets the routing probability for each lower peer to p, the probability that a packet is not routed to any lower peer is (1-p)^N. One could choose p such that (1-p)^N is smaller than a chosen threshold. The overall effect of this choice is an increase in the packet loss probability that is handled with the retransmission mechanism. (Of course, if a packet is retransmitted too many times, the final effect could be an increase of the network load). Bernardini, et al. Expires July 12, 2012 [Page 41] Internet-Draft PPETP January 2012 6.5. Congestion control According to RFC [RFC5405], protocols that use UDP as a transport protocol should do congestion control. Also for congestion control PPETP uses a plugin approach and defines two built-in congestion control procedures void No congestion control is done. This plugin is defined mainly for development and debugging purposes and its use is NOT RECOMENDED unless in those cases where it is absolutely certain that rate control is not necessary. See Section 14.6.1 for details. tfrc This plugine uses the TCP-friendly rate control procedure as described in [RFC5348]. It is the default rate control procedure for PPETP. See Section 14.6.2 for details. Congestion control plugins can use the reserved field in the Data packet and the payload of the Feedback packet to exchange the required data between upper and lower peer. The timestamp field in the data packet can be used to compute the round trip time. See Section 14.6 for details about defining a new rate control plugin. 7. PPETP Attributes For the sake of flexibility, the payload of some control packets store the parameters needed by the request as a sequence of attributes stored in the TLV format defined in Section 4.3. Currently defined PPETP attribute types are given in the following list, the numerical value associated to the attributes is shown in Table 6. PUNCTURING This attribute is used to set the puncturing rate and mode associated to a lower peer (see also the description of the Start command in Section 5.2.2). The payload is a sequence of _puncturing blocks_ whose format is shown in Figure 11. 1. The first octet determines the puncturing mode. As said in Section 5.2.2, two possible modes are defined + Probabilistic puncturing (mode=0) + Deterministic puncturing (mode=1) 2. The second and third octets are the channel mask (see Section 4.2). Since it does not make sense to puncture a channel that it is not active, the actual mask channel is the Bernardini, et al. Expires July 12, 2012 [Page 42] Internet-Draft PPETP January 2012 value of this field ANDed with the channel mask in the command packet. Note that with this convention, mask 0xFFFF applies the puncturing to all the active channels. 3. The fourth octet is the packet class to which the puncturing applies. 4. The following octets are to be interpreted as follows, depending on the puncturing mode Probabilistic puncturing (mode=0) The octet is interpreted as an unsigned 8-bit integer 0 <= Num <= 254 (value Num=255 is reserved). Every time the node is going to send a packet, it draws a random boolean with the probability of getting true equal to Num/254. If the result is true, the packet is sent; otherwise it is discarded. Deterministic puncturing (mode=1) The second octets is an 8-bit integer M < 255, the other octets are interpreted as 8-bit integers Val_1, Val_2, ..., Val_N, V_(N+1) with the last value of the sequence equal to M+1. With this mode a packet with sequence number S is sent if and only if S = Val_i (mod M+1) for some i=1, ..., N This is almost equivalent to transmitting the packets with a probability equal to N/(Mod+1). The method of determining the puncturing procedure to be applied to a packet of a given class is as follows 1. The puncturing mode is kept in a (conceptual) puncturing table, mapping each class to a puncturing method. For every (lower peer, channel) pair there is a specific puncturing table. 2. The PUNTCTURING attributes are processed in the order they are specified in the packet. 3. All the entries of the puncturing table are initialized with "no puncturing" (i.e., all packets are transmitted). 4. If a PUNCTURING attribute is specified for class C, the puncturing value is assigned to every class greater or equal than C. Note that specifying a method for class 0 assigns the method to all classes. Bernardini, et al. Expires July 12, 2012 [Page 43] Internet-Draft PPETP January 2012 ROUTING_PROBABILITY The payload is a single octet to be interpreted as a probability, as explained under "Probabilistic puncturing" above and represents the probability of sending a routed packet to a given lower peer. REDUCTION_PARAMETER This attribute is used to set the reduction parameter associated to each channel. Its value is a (possibly empty) list of parameter blocks constructed as follows * The first octect of the payload is the channel number * After the channel number there is 15-bit integer (encoded as described in Section 4.1) that gives the length of the actual parameter (in octets). * The value of the parameter follows. It is an opaque value of octets to be given as-it-is to the functions of the reduction profile. In other words, the parameter block has a TLV format, with the "type" representing the channel number. EMBEDDED_PACKET This attribute is used to include in a control packet a routed packet. This allows a node to send a signed control packet on behalf of another node. Currently this is used only in a Receive request and it is used to include Send or Redirect requests in the Receive command. +---------------------+------------+ | Attribute name | Type value | +---------------------+------------+ | PUNCTURING | 0 | | ROUTING_PROBABILITY | 1 | | REDUCTION_PARAMETER | 2 | | EMBEDDED_PACKET | 3 | +---------------------+------------+ Table 4: Type values for PPETP attributes Bernardini, et al. Expires July 12, 2012 [Page 44] Internet-Draft PPETP January 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) | Mode = 0 | Channel Mask | Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Num | +-+-+-+-+-+-+-+-+ 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (b) | Mode = 1 | Channel Mask | Class | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mod | Size | Val 1 | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Size-1 octects follow (a) Format for probabilistic puncturing (b) Format for deterministic puncturing Figure 11: Value of the PUNCTURING attribute 8. Peer handshaking procedure When two nodes want to open a connection (because of some request from the API level or because the reception of a Send/Open/Receive command), they do the following steps 1. If the generalized address of other node is not of IP class, it carries out the connection procedure in order to determine an IP address that can be used to contact the other node. 2. It sends to the other node an Hello packet with the credentials (if needed). 3. It waits for receiving the ACK to the sent Hello and the Hello of the remote node. 4. The upper peer sends to the lower peer a Set_Default request and, after receiving a positive ACK, begins streaming. Bernardini, et al. Expires July 12, 2012 [Page 45] Internet-Draft PPETP January 2012 +---------+-------------+----------+------------+---------+---------+ | Request | Unacq. | Connect. | Half-Intro | Intro | Stream. | +---------+-------------+----------+------------+---------+---------+ | Data | Ignore | Ignore | Ignore | Ignore | Process | | Param | Ignore | Ignore | Ignore | Process | Process | | ACK | | | | | | | Start | Connect/Sus | Suspend | Suspend | Process | Process | | Stop | Ignore | Ignore | Ignore | Process | Process | | Open | Connect | Ignore | Ignore | Ignore | ignore | | Closing | Ignore | Ignore | Ignore | Ignore | Process | | Hello | Ignore | Process | Ignore | Ignore | Ignore | | Fback | Ignore | Ignore | Ignore | Process | Process | +---------+-------------+----------+------------+---------+---------+ Table 5: Processing requests 8.1. Peer status During the handshaking procedure the relationship between two peers goes through different states. Unacquainted If peer B is unacquinted to peer A, peer A never heard of peer B. This is the default state. Connected Peer B is said to be connected to peer A if A, possibily as a consequence of connection establishment procedure, can send packets to B. Note that this relationship is not symmetric: if B is behind a NAT, but A is not, before the completion of a CEP A is connected to B, but B is not connected to A. Half-Introduced Peer B is said to be half-introduced to peer A if peer B received the Hello packet from A. Note that as soon as B is Half-Introduced, B can sign the Acknowledge packet to be sent to A. Note that A will be able to verify such a signature after receiving the Hello packet from B. If the Acknowledge to the Hello packet sent to A is received before the Hello packet from A, B is not able to verify its signature and "suspends" the processing of the Acknowledge packet. Introduced Peer B is said to be introduced to A if B is half- introduced to A and received the Acknowledge to a Hello command sent to A. Now both peers can sign the exchanged packets. Configuring The upper peer sent the command packets required to configure the connection and it is still waiting for the acknowledge to come back. Bernardini, et al. Expires July 12, 2012 [Page 46] Internet-Draft PPETP January 2012 Streaming The upper peer received the acknowledge and began sending data packets to the lower peer. The allowed state transitions are the following Unacquainted -> Connected This transaction happens when a peer is asked to contact another peer at a given generalized address. The request to contact another peer comes from one of the following inputs Data Control command The node receives a data control command that asks to send data to another peer. The data control command remains suspended until the nodes reach the Introduced state. Connection command The node receives a connection command. API function If both nodes have a public IP address, the connection establishment procedure is empty and the pair reachs immediately the Connected state. Connected -> Half-Introduced -> Introduced After reaching the Connected state, the two nodes exchange, if necessary, their cryptographic certificates. When each node receives the Acknowledge from the other node, the pair reach the Introduced state. The nodes remain in the Introduced state until the upper peer receives a command (from a Data Control packet or via an API function) to begin streaming data to the lower peer. Note that if no certificate exchange is necessary, this transition completes immediately and the pair reachs the Introduced state. Introduced -> Streaming This transition begins when the upper peer receives the request to stream to the lower peer. Note that if the transition to Connected was caused by a Data Control command, the upper peer begin the Configuring stage after getting into the Introduced state. The upper peer sends (if necessary) any Set_Parameter command to the lower peer. After receiving the ACK back, it starts streaming. 9. Security Considerations 9.1. Possible attacks and countermeasures Bernardini, et al. Expires July 12, 2012 [Page 47] Internet-Draft PPETP January 2012 9.1.1. Poisoning attack In a poisoning attack a node sends "bogus" packets that are not obtained by reducing content packets. These packets will cause an incorrect decoding of the multimedia content and will be propagated to other nodes by the peer-to-peer mechanism. As said in Section 2.5, this attack can be counteracted if the node has more upper peers than the minimum necessary by first recovering the content packet by using a subset of the received packets and then checking that the result is coherent with the remaining received reduced versions. The following cases can happen o No check fails. In this case all the received packets are correct. o One or more checks fail, but not all. This means that the packets corresponding to the failed checks were incorrect and the corresponding peers tried to pollute the stream. o All the checks fail. In this case it is probable that a corrupted packet was used in the reconstruction step. The node can try the reconstruction with a different set and do the check again. If the applicative context allows it, it should be considered the possibility of "punishing" the node that tried the poisoning attack, for example, by banning it from the network. Note, however, that this raises the possibility that one tries a poisoning attack by pretending to be another node, so that the other node is banned from the network. This type of attack is considered in Section 9.1.2 Although not checking for poisoning attacks does not preclude interoperability, nodes SHOULD nevertheless counteract poisoning attacks since a successful poisoning attack can have consequences on the whole P2P network. 9.1.1.1. Large bandwidth nodes A situation that could give rise to a successfully poisoning attack is when a node does a "full service" to a lower peer, i.e., when it sends to the lower peer enough reduced streams for recovering the original content stream (for example, at least R streams if the Vandermonde profile is used). In this case the node could send a "content" that is different from the original content. The victim could not detect the attack because the received data would be coherent. Moreover, the victim will propagate data that are not coherent with the true content, so that its lower peers will believe that the victim is trying a poisoning attacks (defamatory attack, see Section 9.1.2). Bernardini, et al. Expires July 12, 2012 [Page 48] Internet-Draft PPETP January 2012 In order to avoid this situation it is important that only trusted nodes are allowed to do a "full service". 9.1.1.2. Multiple stream session A different type of poisoning attack is when a node injects on the session packets belonging to a _different stream_. In this case the victim does not recognize the attack, since the packets arrives from a single source only. In order to avoid this attack it is important to specify in the security policies the ID of the allowed streams. 9.1.2. Defamatory attack As said in Section 9.1.1, if poisoning peers are punished, a possible type of attack is to try a poisoning attack while pretending to be another node, in order to have the other node punished. In order to avoid this type of attack it is possible to request, during the configuration phase, that each peer signs the transmitted packet by using a secret shared between the peer and the target lower peer. 9.2. Security model Some PPETP actions are sensitive and it makes sense to allow only authorized nodes to do them. Actions that are considered sensitive in PPETP are o Sending data-flow control commands (Start/Stop/Redirect) o Sending third-party data-flow control commands (Start/Stop/ Redirect). A third-party control packet is a packet sent by a peer that is not the target of the command. o Sending routed packets Associated with those actions, PPETP defines some capabilities, partitioned in classes o Self data-flow control class * SELF_START * SELF_STOP * SELF_REDIRECT o Third-party data-flow control class Bernardini, et al. Expires July 12, 2012 [Page 49] Internet-Draft PPETP January 2012 * 3RD_START * 3RD_STOP * 3RD_REDIRECT o Routing packets Each peer can be assigned zero, one or more of the above capabilities. The capabilities are assigned during the configuration phase. 9.2.1. Node classes As said above, in the default configuration only privileged nodes can do some actions (e.g., send routed packets, signing certificates, ...). In order to identify privileged nodes without explicitely define them, this section defines a set of "node classes". o An initial segment { 1, 2, ..., 2^L-1 } of Peer ID space is reserved to privileged node. Every Peer ID greater or equal to 2^L belongs to the non-privileged class. By default L=10, but this can be changed at configuration phase. o Each privileged ID is an L-bit non-null integer whose 5 most significant bits denotes the _peer class_ and the remaining L-5 bits identify a specific peer of the class. Note that this requires that L >= 5. o The meaning of the bits of the peer class have the following meaning * If bit 4 of the class value (the least significant bit) is 0, the node can send self-data control commands * If bit 3 of the class value (the least significant bit) is 0, the node can send third-party data control commands * If bit 2 of the class value (the least significant bit) is 0, the node can send routed packets. * Bits 0 and 1 of the class value (the two most significant bits) are reserved for future extensions. Note that peers of class 0 are the most privileged ones. o A node in a non-privileged class can only send non third-party Stop commands Bernardini, et al. Expires July 12, 2012 [Page 50] Internet-Draft PPETP January 2012 Clearly, the validity of, say, a routed packet does not rely on the claim that the originator was a privileged host, but on the signature attached to the packet that grants that the originator had a peer ID belonging to the right class. It is expected that the public keys required for the signature verification are long-term keys, so that, in some applicative context, nodes will be able to download the keys (suitably signed by some certification authority) and store them on their local disk. 10. PPETP configuration In order to join a PPETP session a node needs to know several pieces of information, such as the reduction profile to be used, any reduction parameter shared by the whole session (as the value of R in the Vandermonde profile) and so on. For several configuration parameters PPETP does not provide any protocol-specific method to set them and it supposes that they will be set by the application via a suitable API (maybe similar to the BSD-socket function setsockopt()). The following is a list of parameters that could need to be set during the configuration phase o The reduction profile used and any reduction parameters global to the whole session (e.g., the reduction factor R in the Vandermonde profile) o How many channels the node must open and any parameter associated to them (e.g., puncturing probability) o Security related information such as * The Sender signature algorithm and any associated parameters * The Source signature algorithm and any associated parameters * Who can send routed control packets * The credentials of other peers. Moreover, the node must know the addresses of its upper peers or it must be given enough information to find them (e.g., the address of a distributed hash table to be queried). 10.1. Bootstrap configuration protocol As said in Section 3.1, a PPETP session may be referred to by a pair (IP_address, session_ID) where the IP_address is the address of a host queried to get configuration data. This section describes the Bernardini, et al. Expires July 12, 2012 [Page 51] Internet-Draft PPETP January 2012 protocol used for the query. 10.1.1. Design goals The configuration query protocol was designed with the following objectives in mind o The protocol must allow for user authentication o The protocol must be light-weight and suitable to a stateless implementation of the server. o For complex configuration needs, the server should be able to redirect the user to an alternative configuration protocol (that is why it is called "Bootstrap configuration protocol"). The typical dialog between the node and the configuration server is expected to be similar to this 1. The client sends a query to the server with the session number 2. If the server requires client authentication, it sends a reply with an "Unauthorized" error code. 3. The client repeats the request, but this time it includes its credentials. 4. The server checks the credentials and, if satisfied, sends back the configuration information. The reply can assume two different forms A. In the simplest cases the configuration data can be included in the payload of the reply. B. In more complex cases (for example, if some negotiation is required), the reply will redirect the client to use a different server and/or a different configuration protocol. The main motivation behind this design is that a complex protocol that requires the allocation of resources to store the status of a transaction could be prone to Denial-of-Service (DoS) attacks. The light-weight protocol described here can be used as a filter to select only legitimate users and redirect them to the use of a more complex configuration protocols. Bernardini, et al. Expires July 12, 2012 [Page 52] Internet-Draft PPETP January 2012 10.1.2. Protocol structure The protocol has a "query-response" structure. The node that wants to join the PPETP network sends query packets to the configuration server and the server replies with response packets. Both query and response packets are composed of a 32-bit header and a (possibly empty) sequence of attributes in TLV format, more precisely o The first octect denotes the type. o The length value is a 15-bit integer encoded with one or two octets, as described in Section 4.1 o The successive length octets are the value of the attribute. 10.1.3. Query packet Figure 12 shows the structure of the header of a query packet. o The first 16 bits contain the ID of the desired PPETP session (that is, the "pseudo-port" in the PPETP "pseudo-address") o The bits from 16 to 23 (3rd octet) are a sequence number that uniquely identify the request. The configuration server will copy the Query_Number into the response packet, so that the client can match a response with the corresponding request. o The bits from 24 to 26 (part of the 4th octet) are the protocol version and it is equal to the minimum between the protocol version understood by the client and the protocol version understood by the server. If the server protocol version is unknown (because this is the first time that we contact the server), this field is equal to the client protocol version. o The bits from 27 to 31 are the magic number 3 (decimal). This field can be used to distingush between configuration packets, normal PPETP packets and ICE packets. (Similarly to what happens with ICE, query/response packets are sent/received from the same port used by PPETP.) o Bits from 32 to 63 are the Peer_ID that the node chose by itself. The configuration server can accept this choice or it can choose another ID to be communicated with the configuration data. Bernardini, et al. Expires July 12, 2012 [Page 53] Internet-Draft PPETP January 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session_ID | Query_Number | V | Magic | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Proposed Peer ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Header of a query packet Query packets are sent using the same port used for PPETP data and control packets, so that the remote server can learn the socket address used for the PPETP session (and if the node is behind a NAT or not, if the node add a SOCK_ADDR attribute to the request). Note the Magic field allows one to distinguish configuration packets from PPETP packets. By default query packets are sent to the port TBD of the configuration server, but this can be changed by suitable options (e.g., attribute ppetp-config-port in an SDP description, see Section 13.10). 10.1.4. Response packet In response to a query the configuration server replies with a response packet. The content of the response packet can be one of the following o A request for user authentication. This type of reply is sent both if the authentication part is missing or not acceptable by the server (e.g., because it uses a stale nonce). o A redirection request that asks the client to use a different protocol and/or a different host. o The required configuration data. Given the very basic nature of the protocol, it is expected that this case will happen only in the simplest applicative contexts. Figure 12 show the structure of the header of a response packet. The error code is stored in the first 16 bits, the third and the fourth octects are interpreted as in the request packets. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error_code | Query_Number | V | Magic | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Header of a response packet Bernardini, et al. Expires July 12, 2012 [Page 54] Internet-Draft PPETP January 2012 The Error_Code field can assume the following values 200 (OK) The request was processed succesfully and the configuration data are stored in the attribute CONTENT. The format of CONTENT is described in the attribute CONTENT-TYPE. 300 (Try alternate) The request was processed succesfully, but the configuration data must be obtained by using a different protocol (and maybe a different server). The protocol to be used is stored in the attribute PROTOCOL, the parameters for the query are stored in one or more attributes of type PARAMETER (whose meaning depends on the value of PROTOCOL). 400 (Bad Request) The request was malformed. The client SHOULD NOT retry the request without modification. A more detailed description of the reasons of why the request is malformed can be stored in the attribute REASON. 401 (Unauthorized) The request did not contain the correct authorization credentials. This reply can be sent both if the query had no credentials at all or if the credentials were uncorrect. The reply SHOULD include a REALM attribute and a USE- NONCE attribute. 406 (Not Acceptable) If this code is received it means that either attribute ACCEPTED-PROTOCOLS does not include a protocol acceptable to the server or attribute ACCEPTED-CONTENT does not include a content type generable by the server. The server SHOULD include in the reply attributes ACCEPTED-PROTOCOLS and ACCEPTED- CONTENT with the list of acceptable protocols and contents. 420 (Unknown attribute) The request included at least one attribute that the server was unable to understand. The unknown attribute type(s) can be found in the attribute UNKWOWN-ATTRIBUTES. 438 (Stale nonce) The nonce used by the client was no longer valid. The client should retry, using the nonce provided in the response in the USE-NONCE attribute. 500 (Internal server error) The server has suffered a temporary error. The client should try again. 10.1.5. Attributes This section lists the defined attributes. Numerical values for the attributes are given in Table 6. Bernardini, et al. Expires July 12, 2012 [Page 55] Internet-Draft PPETP January 2012 ACCEPTED-PROTOCOLS The value of this attribute is a list of 15-bit integers encoded as described in Section 4.1. Each integer identifies a configuration protocol implemented by the client. PROTOCOL The protocol that the client must use to get configuration data. It has the plugin attribute format described in Section 10.1.5.1. ACCEPTED-CONTENT The value of this attribute is a list of 15-bit integers encoded as described in Section 4.1. Each integer identifies a configuration descriprion format understood by the client. CONTENT The value of this attribute is the configuration description. It has the plugin attribute format described in Section 10.1.5.1. This field MUST be present if and only if the error code is 200. USERNAME This field identifies the username and password combination used to generate the signature. Its value MUST be UTF-8 [RFC3629] encoded sequence of less than 63 bytes, and MUST have been processed using SASLprep [RFC4013]. REALM This field matchs the grammar for "realm-value" as described in [RFC3261] but without the double quotes and surrounding whitespace. That is, it is an unquoted realm-value (and is therefore a sequence of qdtext or quoted-pair). It MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters, and MUST have been processed using SASLprep [RFC4013]. USE-NONCE This field is present when one part requires to the other to authenticate itself. This field will be copied in the REMOTE- NONCE and the whole packet signed (by adding a SIGNATURE attribute). This field contains a sequence of qdtext or quoted- pair, which are defined in [RFC3261]. Note that this means that the NONCE attribute will not contain actual quote characters. See [RFC2617], Section 4.3, for guidance on selection of nonce values in a server. REMOTE-NONCE This field is filled with a verbatim copy of the attribute USE-NONCE. LOCAL-NONCE When one of the parts wants to authenticate itself, it MAY add this attribute whose meaning and objective is similar to the "cnonce" field in [RFC2617] Bernardini, et al. Expires July 12, 2012 [Page 56] Internet-Draft PPETP January 2012 ACCEPTED-ALGORITHMS The value of this attribute is a list of 15-bit integers encoded as described in Section 4.1. Each integer identifies a signature computing algorithm that the node (client or server) can use. USE-ALGORITHM This specifies the algorithm to use in the computation of the value in the field SIGNATURE. It has the plugin attribute format described in Section 10.1.5.1. If this field is missing, algorithm HMAC described here is used. ALGORITHM This specifies the algorithm used to compute the value in the field SIGNATURE. It has the plugin attribute format described in Section 10.1.5.1 and, if the signature is added because of a server request it MUST be a verbatim copy of the received USE- ALGORITHM attribute. SIGNATURE This attribute, if present, MUST be the last one. A packet having this field in a different position MUST be discarded and if the packet is a query packet the server must reply with an error code 400. This field is computed by using the algorithm specified in the attribute ALGORITHM. REASON The reason phrase is meant for user consumption, and can be anything appropriate for the error code. The reason phrase MUST be a UTF-8 [RFC3629] encoded sequence of less than 128 characters (which can be as long as 763 bytes). UNKNOWN-ATTRIBUTES The UNKNOWN-ATTRIBUTES attribute is present only in an error response when the response code in the ERROR-CODE attribute is 420. The attribute contains a list of 16-bit values, each of which represents an attribute type that was not understood by the server. SOCK_ADDR The value of attribute SOCK_ADDR has the format of a generalized address of class IP and it is used by the client to send the (address, port) pair used to receive PPETP data. By comparing the address in SOCK_ADDR with the address found in the IP packet, the server can deduce if the node is behind a NAT or not. Bernardini, et al. Expires July 12, 2012 [Page 57] Internet-Draft PPETP January 2012 +---------------------+-------+ | Name | Value | +---------------------+-------+ | ACCEPTED_PROTOCOLS | 0 | | PROTOCOL | 1 | | ACCEPTED_CONTENTS | 2 | | CONTENT | 3 | | USERNAME | 4 | | REALM | 5 | | USE_NONCE | 6 | | LOCAL_NONCE | 7 | | REMOTE_NONCE | 8 | | ACCEPTED_ALGORITHMS | 9 | | ALGORITHM | 10 | | USE_ALGORITHM | 11 | | SIGNATURE | 12 | | REASON | 13 | | UNKNOWN_ATTRIBUTES | 14 | | SOCK_ADDR | 15 | +---------------------+-------+ Table 6: Values associated to attribute types 10.1.5.1. Plugin attributes The attributes that refer to possibly "pluggable" procedures all share the same format o The value begins with a 15-bit number that identifies the plugin to be used o The remaining part of the value is an opaque (possibly empty) string of octects used by the plugin as parameter. The format of this part of the value depends clearly on the specific plugin. 10.1.6. Packet signing This configuration protocol allows both actors (client and server) to request the authentication of the other. The client decides to send a signed query for the following reasons o A reply packet with the attribute USE-NONCE was received. Typically the error code associated to the reply packet will be Unauthorized (401) or Stale Nonce (438). o Spontaneously. This can happen, for example, if the client receives the nonce in an SDP attribute. Bernardini, et al. Expires July 12, 2012 [Page 58] Internet-Draft PPETP January 2012 The server signs a packet if o The request packet includes a USE-NONCE attribute AND o the request packet includes a valid user signature It is strongly suggested that, in order to make DoS attacks more unlikely, the server should not reply with signed replies to non- signed requests. The procedure to create a signed packet is the following 1. A packet signed by the client MUST contain at least the attribute USERNAME. 2. The value of USE-NONCE (if present) is copied in the attribute NONCE. The value of attribute REALM (if present) is copied in the packet. 3. Attribute LOCAL-NONCE is added. 4. Attributes ALGORITHM is set. 5. The packet, completed with any other attribute related with the query, is processed together the value of USERNAME and REALM to obtain a string of bits. The resulting string of bits is used as value of the attribute SIGNATURE. 10.1.6.1. HMAC signature This specification allows for the definition of future signature algorithms. However, in order to grant for the availability of at least one signature algorithm, this section describes an algorithm that MUST be implemented in every client and server. This algorithm supposes that the user and the server share a common secret that we will denote with S. The shared secret can be a long- term user password or it could be a temporary secret communicated to the user over a secure channel (e.g., in an SDP description transmitted over TLS). It is supposed that the shared secret can be found from the knowledge of USERNAME and REALM. The algorithm described here computes the signature with the procedure described in [RFC2104] and it is parametrized by the hash function to be used. 1. With reference to [RFC2104], the value of "text" is the whole packet to be signed, without the SIGNATURE attribute (that MUST Bernardini, et al. Expires July 12, 2012 [Page 59] Internet-Draft PPETP January 2012 be the last one) 2. Still with reference to [RFC2104], the value of key "K" is obtained from the shared secret S as follows K=H(S | NONCE) where H is the chosen hash function, NONCE is the value of the attribute USE-NONCE and "|" denote bitstring concatenation. 10.2. Compact Configuration Format The light-weight configuration protocol allows for different configuration formats to be added in the future. For the sake of completeness, this section describes a configuration description format designed to be especially compact. The format described here is inspired to SDP: it is line oriented, every line begins with a character that identifies the line type and the order of the line is rigid. The major differences with SDP are due to the objective to make the format as compact as possible. For example, no "=" is inserted after the first character of the line, lines end with only LF (not CRLF) and numbers are in hexadecimal. The line types that can be used in the CCDF are can be found in the following list o "a": attribute line(s) o "C": informations about the channels opened by the node o "c": connection line(s) o "E": embedded packet o "f": peer search method ("f" is for "find") o "H": hello signature settings o "N": sender signature settings (as in seNder) o "n": peer line(s) ("n" is for "node") o "o": session Option line o "P": security policies o "p": profile line Bernardini, et al. Expires July 12, 2012 [Page 60] Internet-Draft PPETP January 2012 o "r": rate control line o "S": source signature settings o "s": stream line o "X": Control puncturing lines o "x": Data puncturing lines o "Y": informations about the node itself ("Y" is for "Yourself") Figure 14 gives the ABNF specification of CCDF. ABNF rules and core rules are according to [RFC5234]. ccdf = profile-line [rate-ctl-line] [stream-line] [session-opt-line] [self-line] *channel-line [find-line] [src-signature] [snd-signature] [hello-signature] *policy-line *peer-block profile-line = %x70 plugin-spec ; 'p' rate-ctl-line = %x72 plugin-spec ; 'r' stream-line = %x73 stream-id-list EOL ; 's' stream-id-list = 1*byte session-opt-line = %x6F [session-name] [SP magic] EOL ; 'o' session-name = token magic = byte self-line = %x59 peer-id [SP self-stream-ids] EOL ; 'Y' peer-id = int32 / "*" self-stream-ids = 1*byte channel-line = %x43 parameter-block ; 'C' find-line = %x66 plugin-spec ; 'f' Bernardini, et al. Expires July 12, 2012 [Page 61] Internet-Draft PPETP January 2012 peer-block = %x7e node-type node-id SP channel-list EOL ; 'n' *attribute-line generalized-addr [embedded-pkt] *data-punct-line [ctl-punct-line] generalized-addr = %63 plugin-spec ; 'c' embedded-pkt = %45 embedded-data EOL ; 'E' node-type = %x6C / %x6f / %x75 ; 'l', 'o', 'u' ctl-punct-line = %x58 num EOL ; 'X' data-punct-line = (rand-punct / mod-punct) EOL rand-punct = %x78 %x52 class channel-list SP num ; 'xR' mod-punct = %x78 %x4D class channel-list SP mod 1*byte ; 'xM' num = byte mod = byte class = byte node-id = int32 policy-line = %x50 capability SP allowed-list ; 'P' capability = "self-send" / "self-stop" / "self-redir" / "3rd-send" / "3rd-stop" / "3rd-redir" / "routing" / "cert" allowed-list = "all" / "none" / group-list group-list = peer-group *(SP peer-group) peer-group = mask-id / node-id mask-id = mask ":" value mask = int32 value = int32 src-signature = %x53 plugin-spec ; 'S' snd-signature = %x4E plugin-spec ; 'N' hello-signature = %x48 plugin-spec ; 'H' plugin-spec = plugin-name parameter-block plugin-name = identifier parameter-block = *(SP parameter) EOL *attribute-line parameter = token attribute-line = %x61 attr-name "=" attr-value EOL ; 'a' attr-name = identifier attr-value = *%x20-7E channel-list = *4HEXDIGIT EOL = LF Bernardini, et al. Expires July 12, 2012 [Page 62] Internet-Draft PPETP January 2012 byte = 2HEXDIGIT int16 = 4HEXDIGIT int32 = 8HEXDIGIT integer = 1*HEXDIGIT identifier = ALPHA *id-char id-char = ALPHA / DIGIT / "-" / "_" token = 1*VCHAR embedded-data = base64-enc base64-enc = *base64-word base64-end base64-word = 4BASE64 base64-end = 4BASE64 / (3BASE64 "=") / (2BASE64 "==") BASE64 = ALPHA / DIGIT / "+" / "-" Figure 14: ABNF grammar for the CCDF The meaning of the lines is the following o Profile line ("p"). This is the only mandatory line and it specifies the reduction procedure to be used and any associated global parameters via the "plugin-spec" (see in the following for more details about "plugin-spec"). o Stream line ("s"). The parameters on this line are the ID of the streams that are allowed to circulate. If no parameter is present any ID is allowed, if this line is missing only ID=0 is allowed. Nodes MUST discard any packet whose stream ID does not belong to the set of admissible ones. o Session option line ("o"). This line is used to set the session name and/or the magic number to be used in the fourth octet of PPETP packets. Note that the session name can be any , that is, any sequence of "visible" characters. For example, the following line oab sets the session name to "ab" and uses the default value 95 for the magic number; the following line (note the space between "o" and "ab") o ab uses the default session name (see Section 3.1.1) and the value 0xab as magic number; finally, the following line omy-name ab uses "my-name" as session name and the value 0xab as magic number. o Self information ("Y"). The first parameter of this line is the ID assigned to the node or the character '*'; in the latter case, the node will choose the ID by itself. The following parameters are the streams ID that the node can produce, if no further parameter are present, the node cannot produce any stream. For Bernardini, et al. Expires July 12, 2012 [Page 63] Internet-Draft PPETP January 2012 example, the following line Y0123abcd afbcd6 assigns the peer ID 0x0123abcd to the node and allows the node to produce three streams with stream ID af, bc and d6. o Output channels ("C"): This type of line specifies the peer-local reduction parameters to be used for the channel to be opened by the node. The n-th C-line refers to the channel number n-1 (since channel numbers start from 0). The parameters can be specified, similarly to the profile line, as positional parameters or attributes. The meaning of the parameters is defined by the reduction profile. For example, the following description C aredundancy=4/3 C aredundancy=5/3 C aredundancy=1/1 assigns to channels 0, 1 and 2 a "redundancy" (a fictional parameter) equal respectively to 4/3, 5/3 and 1/1. o Peer searching ("f"). The list of the upper peers can be included in the description by the "n"-lines. Alternatively, it is possible to say to the node how to search for new peers by using an "f"-line. Similarly to the profile line, the search method and any associated parameters are specified by using a "plugin-spec". o Peer line ("n"). This line describes a peer of the node. * The first parameter is only one character long and it denotes the peer type: 'u' for upper, 'l' for lower and 'o' for other. The latter type includes those nodes that need to communicate with the node (e.g., the bridge node in the ICE-based NAT- transversal) without being neither upper nor lower peers. * The second parameter is the peer id of the remote node * An optional list of channels follows. This field is to be interpreted as follows + If the node type is 'o' no channel number must be given. + If the node type is 'u', the channel fiels is the set of channel to be required to the upper peer Bernardini, et al. Expires July 12, 2012 [Page 64] Internet-Draft PPETP January 2012 + If the node type is 'l', the channel fiels is the set of channel to be sent to the lower peer If node type is 'l' or 'u' and the channel list is empty, the mask 0x0001 (corresponding to channel 0) is used. * An optional list of s follows. Each attribute corresponds to a peer-local parameter. * The generalized address of the peer follows. This is given as a "plugin-spec" block where the "plugin-name" part is the class of the generalized address, while the following parameters, are, of course, defined by the address class. * An optional embedded packet can follow. Depending on the policy setting, it could be that only privileged nodes can send data-control requests. By using this field, the server can pass to the node a routed packet (base64 encoded according to [RFC4648]) to be sent to the lower peer. * If the peer is a lower peer, optional puncturing lines ('x' lines) can follow. This type of lines can be used to set the puncturing instructions. If is empty the default mask 0xFFFF is used. The processing of puncturing lines is done according to the procedure used for processing the puncturing attribute described in Section 7. For example, the following lines xR00 FE xR10 7F xR80 10 correspond to sending all the packets (since the probability of transmission is 0xFE/254=1) for the classes 0, 1, ..., 15; transmit with probability 0.5 (=0x7F/254) the packets belonging classes 16, ..., 127 and with probability 16/254 the packets belonging to classes 128, ... 255. This puncturing is applied to all the channels (since the channel list is empty). As another example, the lines xR001F 7F xR003E0 40 sends packets of channels 0, .., 4 (0x1f = 0xb1_1111) with probability 0.5, packets of channels 5, ..., 9 (0x3e0 = 0xb11_1110_0000) with probabily 1/4 (more precisely, 64/254) and the packets belonging to other channels with probability 1. This is done for every priority class, since, according to Bernardini, et al. Expires July 12, 2012 [Page 65] Internet-Draft PPETP January 2012 Section 7, the rules above are applied to all the classes >= 0. o Signature settings (lines "S", "N" and "H"). This type of lines is used to set the signature algorithms to be employed for the source signature ("S" line), the sender signature ("N" line) and the "Hello" signature ("H" line). The algorithms and its global parameters are specified by means of a block. o Security policies ("P" line). This line specifies who can do what. The first parameter is the name of a "capability" that identifies a specific action. Following the capabilities one finds the list of the peers that are authorized to do that action. The list of allowed peers is built as follow * To each capability C_i a list of pairs (Mask_{i,j}, Value_{i,j}) is assigned. * Capability C_i is assigned to the node with Peer_ID equal to ID if there is at least one j such that Mask_{i,j} & ID = Value_{i,j}, where "&" is bitwise AND. Beside giving the list of (mask, value) pairs, it is possible to specify single IDs (equivalent to Mask=0xFFFF_FFFF and Value=ID), or the keywords "all" (everyone can do the action, equivalent to Mask=0 and Value=0) and "none" (none can do the action, equivalent to Mask=0 and Value!=0). Other non terminals in the grammar that deserves some explanation are o This non terminal represent a set of channels. It can be an empty string or a 16-bit number in hexadecimal whose value is to be interpreted as channel mask (see Section 4.2. If it is empty, it assumes a default value that depends on the context. o This non terminal is used every time there is the need of specifying a plugin and its global parameter. The first element is mandatory and it is the name of the plugin (i.e., 'vandermonde', 'basic', 'dh-shared', ...) followed by a list of global parameters. The parameter values can be specified both in a positional way (by writing them after the plugin name) or by a nominal way (by using attribute lines). o Attribute ("a"). This line can be used to assign parameter values in a "nominal" way. The attribute name is separated by the value by an equal sign. The attribute value is represented by the string of characters between the '=' and the end of line. How this value is to be interpreted is defined by the attribute. Bernardini, et al. Expires July 12, 2012 [Page 66] Internet-Draft PPETP January 2012 10.3. Configuration defaults A full configuration of a PPETP session requires to specify many parameters (the reduction procedure, which nodes can send routed packets, which nodes can sign credential certificates and so on). In order to simplify the configuration step and minimize the amount of required data, this section defines some configuration defaults that can provide a good setup for most of the applicative contexts. The defaults are mostly related with security aspects. The default choices are o Data and control packets signed with sender signature Section 14.1.1 o Routed control packets require source signature. The source signature is done with the rabin procedure described in Section 14.2.1. o Only authorized nodes can send routed packets. o Only authorized nodes can sign credential certificates. o Only authorized nodes can send control packets of type ??? o The session carries only one stream with Stream_ID equal to 1 o Rate control is done via the TFRC procedure described in Section 14.6.2 11. ICE-based Connection Establishment Procedure This version of PPETP includes an ICE-based connection procedure. As explained in Section 4.4, the definition of a class of generalized addresses must also define a procedure to be used to convert the generalized address in an actual IP address. In the case of the ICE class the procedure makes use of a "bridge" node that plays a role similar to the role of the SIP server in [RFC5245] and allows the two peers to exchange candidate lists. Each peer collects its candidates, and sends them to the bridge by using the "exchange" protocol identified by the first octet of the generalized address (see Section 4.4.3 and Figure 2). The bridge node, after receiving both candidate lists, will send to each peer, still using the exchange protocol, the candidate list received from the other one. At the end of the dialogue with the bridge node the peers can begin the connectivity checks [RFC5245]. Bernardini, et al. Expires July 12, 2012 [Page 67] Internet-Draft PPETP January 2012 11.1. HTTP/HTTPS-based exchange protocol This specification describes an HTTP/HTTPS-based protocol for the dialogue between the peers and the bridge. Using HTTP(s) has the advantage that it allows one to reuse exisisting HTTP resources (servers, client libraries, authentication, use of TLS, ...). In a context where high performances are not required, it is even possible to implement the bridge node as a CGI script. More into details, the procedure associated with the ICE address class is the following 1. The ICE generalized address contains the address of the bridge node and the Peer ID of the peer to be contacted. 2. The node collects its ICE candidates and encode them (e.g., according to the JSON format in Section 11.2). 3. Each node sends to the bridge node an HTTP POST request formatted as follows Request-URI It is a relativeURI of [RFC2396] with the following format request-uri = prefix "?" parameter *(& parameter) prefix = abs_path parameter = source / dest / session / signature source = "from=" peer-id dest = "to=" peer-id session = "sess=" *sess-char signature = "sign=" base64url sess-char = unreserved | escaped | ":" | "@" | "$" peer-id = 1*DIGIT The meaning of the fields is as follows + The Peer ID of the peer that sent the POST request is the value associated to "from" + The Peer ID of the other peer is the value associated to "to" + The value "sess" identifies the session and it can be used by the bridge to distinguish between requests associated with different sessions. Its value is defined as follows - If the generalized address has the SESSION attribute, the value of the attribute is used. Bernardini, et al. Expires July 12, 2012 [Page 68] Internet-Draft PPETP January 2012 - If the generalized address has not the SESSION attribute, but the PPETP session has a name (see Section 3.1.1), the value of "sess" is the session name. - Otherwise, the value of "sess" is the empty string. + The value of the optional field "sign" is the base64url [RFC4648] encoding of the value of the SIGNATURE attribute of the ICE generalized address, if present. This field can be used to verify that the peer received the generalized address from an authorized source (e.g., a configuration server). Since this field is used only by the bridge and the configuration server, this document does not describe the format of the signature, nor how the signature is generated/verified. Note that this authentication mechanism is optional and it is not in alternative with the usual HTTP authentication mechanism. + The "prefix" is by default equal to "/connect", but it can be changed by defining it in the generalized address + Every field must be present once and only once. + Any Request-URI that does not satisfy the rules above is invalid. For example, suppose that peer number 42 wants to open a connection to peer 24. Suppose that the PPETP session has session ID 12346 (0x303A) and that the configuration server is config.example.com. The Request-URI sent with the POST request would be /connect?sess=303A@config.example.com&from=42&to=24 Header Content-type It is set coherently with the encoding used for the candidate lists. Body The body contains the candidate list. 4. The node receives the candidate list of the other peer in the body of the reply. Of course, the format used for the encoding the candidate list is set by the header Content-Type 5. Now the peers can start the connectivity checks, as described in [RFC5245]. At the end of the checks each peer will have a pair (source address, target address) that represents the result of this procedure. Bernardini, et al. Expires July 12, 2012 [Page 69] Internet-Draft PPETP January 2012 The behaviour of the bridge is expected to be equivalent to the following one 1. The bridge waits for a request 2. The bridge checks the validity of the received POST request (e.g., the value of "sess" is valid, the node was succesfully authenticated, ...). If the request is not valid, the bridge SHOULD reply with an error code 400 (Bad Request). 3. If the request is valid, the bridge checks if a matching offer has already been received. The bridge checks if two offers match by checking that the two "sess" are equal and the value of the "from" field in a request is equal to the value of the "to" field in the other. 1. If a matching offer exists, the bridge replies to each peer with a 200 code, including in the body the list of the other peer. 2. If a matching offer does not exist, the bridge sets apart the received offer. The bridge can set a timeout for the matching offer to arrive; if the timeout expires before the reception of the second offer, the bridge SHOULD reply with error code 404 (Not Found). Depending on the application setup, the bridge may signal to the "target" peer the request that the "from" wants to open a connection, so that the target peer will send its candidates to the bridge. For example, the bridge could have an Open request routed to the target peer. 11.1.1. Format of the private field in the generalized address The format of the private field for exchanges protocol 0 and 1 is an attribute list in TLV format (see Section 4.3). The recognized attributes are the following PORT The value is the port to be used to contact the bridge node, expressed as an unsigned 16-bit integer in network order. If this attribute is missing, the port defaults to the default port for HTTP or HTTPS, depending on the exchange protocol. PREFIX The value is the prefix value to be used to build the request. If this attribute is missing, the default value "/connect" is used. Bernardini, et al. Expires July 12, 2012 [Page 70] Internet-Draft PPETP January 2012 SESSION The value is the value of the "sess" attribute. If this attribute is missing, the session name is used. SIGNATURE The value of this attribute, encoded as base64url [RFC4648], is to be used as the value of the "sign" parameter in the request. The values for the type field of the above attributes are shown in Table 7. +-----------+-------+ | Name | Value | +-----------+-------+ | PORT | 0 | | PREFIX | 1 | | SESSION | 2 | | SIGNATURE | 3 | +-----------+-------+ Table 7: Types for attributes in an ICE generalized address 11.2. JSON format for ICE candidates The ICE document [RFC5245] introduces an SDP-based format for the exchange of candidates via a SIP server. In that context, embedding ICE candidates in an SDP description is quite natural, since it is expected that the two SIP nodes will exchange SDP descriptions anyway. In the context of PPETP, however, the usage of the SDP-based format of [RFC5245] would be quite unnatural. Because of this, this section defines a new JSON-based format [RFC4627] for ICE candidate list that does not require an embedding in an SDP description. The JSON Schema [json-schema] for ICE candidate list is as follows { "name" : "ICE_candidates", "type":"object", "properties":{ "lite":{ "type":"boolean" }, "ufrag":{ "type" : "string", "required" : "true", "minLength":4, "maxLength":256 }, "password":{ Bernardini, et al. Expires July 12, 2012 [Page 71] Internet-Draft PPETP January 2012 "type" : "string", "required" : "true", "minLength":22, "maxLength":256 }, "options":{ "type":"array", "items":{ "type":"string" } }, "candidates":{ "type":"array", "items": { "type":"object", "properties":{ "foundation": { "type" : "string", "required" : "true" }, "transport": { "type" : "string", "default" : "UDP" }, "priority": { "type":"integer", "minimum":0, "maximum":4294967295, "required" : "true" }, "candidate-type":{ "enum":["host", "srflx", "prflx", "relay"], "required" : "true" }, "addr": { "type" : "string", "required" : "true" }, "port": { "type" : "string", "required" : "true" }, "raddr": { "type" : "string" }, "rport": { "type" : "string" } Bernardini, et al. Expires July 12, 2012 [Page 72] Internet-Draft PPETP January 2012 } } } } The Media type for this format is TBD 11.2.1. Example The following is the description in JSON format of the candidate list used in the offer at page 83 of [RFC5245] { "ICE_Candidates" : { "ufrag" : "8hhY", "password" : "asd88fgpdd777uzjYhagZg", "candidates" : [ { "foundation" : "1", "priority" : "2130706431", "candidate-type" : "host", "addr" : "10.0.1.1", "port" : "8998" }, { "foundation" : "1", "priority" : "1694498815", "candidate-type" : "srflx", "addr" : "192.0.2.3", "port" : "45664", "raddr" : "10.0.1.1", "rport" : "8998" } ] } } 12. Identity-based signature 12.1. Motivation As explained in Section 5.2, HELLO packets cannot be signed with the usual sender signature since the target peer does not know the credentials of the remote one. Because of this, HELLO packets must be signed by using an alternative public-key scheme. This section defines an identity-based signature algorithm to be used to sign HELLO packets. The choice of using an identity-based signature rather than other public-key signature schemes is that in some Bernardini, et al. Expires July 12, 2012 [Page 73] Internet-Draft PPETP January 2012 applicative context no certificate is actually necessary and this helps in keeping the HELLO packet size below the MTU. 12.2. Algorithm To be written 12.3. Signature format In order to verify the signature attached to the HELLO packet, the target peer must know o The identity of the remote peer o The public key(s) of the key generator(s) o The parameters used by the signature algorithm (e.g., the hash functions and the elliptic curve employed) This document defines suitable defaults for those values, so that in most applicative cases no actual certificate will be required. More into detail, the parameters above can be specified as follows Peer Identity The peer identity can be specified * By including an IDENTITY attribute in the payload. * By including an IDENTITY_SUFFIX attribute in the payload. In this case the identity is represented by the bitstring obtained by concatenating the Peer ID with the value of this field. Alternatively, the "identity suffix" value can be specified by out-of-band means (e.g., by including it in the configuration data) * If neither IDENTITY nor IDENTITY_SUFFIX attributes are specified and the PPETP session has a name, the peer identity is obtained by concatenating the peer ID and the session name. * It is an error if neither IDENTITY nor IDENTITY_SUFFIX are specified and the PPETP session HAS NOT a name. In this case the signature must be considered invalid. See also Appendix B.4. Bernardini, et al. Expires July 12, 2012 [Page 74] Internet-Draft PPETP January 2012 Public key(s) of the key generator(s) Note that those keys cannot be specified directly in the HELLO packet, since otherwise an attacker could implement its own key generator that could be used to generate the private key for any possible identity. Because of this, in the HELLO packet we do not specify the public key, but the _identity_ of the key generator(s). The association between generators and corresponding keys is supposed to be done out-of- band. More precisely, the public keys of the key generators can be specified * By including KEY_GENERATORS attribute in the payload. The value of the attribute is a list of key generator identities. * By specifing the keys by means of a secure out-of-band method. For example, by including the keys in a signed configuration description. * Implicitely, for example by including them inside the software using PPETP. This would be the case, for example, for a player developed to watch the programs of a specific IPTV producer. Other parameters To be written 12.4. ID-based signature attributes Attributes belonging to this class are used inside the ID-based certificate optionally included in the HELLO packet. The following attributes are defined IDENTITY The value of this attribute is an opaque sequence of octets that is to be used as the peer identity in the signature verification algorithm. This attribute and the attribute IDENTITY_SUFFIX cannot be both present. IDENTITY_SUFFIX The value of this attribute is an opaque sequence of octets that is to be concatenated with the Peer ID to obtain a sequence of octets that represents the peer identity in the signature verification algorithm. This attribute and the attribute IDENTITY cannot be both present. KEY_GENERATORS The value of this attribute is the sequence of the peer IDs of the nodes that were used as key generators. The map between IDs and public keys is specified out-of-band, possibly by extra-PPETP means. Bernardini, et al. Expires July 12, 2012 [Page 75] Internet-Draft PPETP January 2012 +-----------------+-------+ | Name | Value | +-----------------+-------+ | IDENTITY | 0 | | IDENTTIY_SUFFIX | 1 | | KEY_GENERATORS | 2 | +-----------------+-------+ Table 8: Types of the attributes of ID-based class 13. IANA Considerations 13.1. Generic plugin definition This document defines several IANA registers for PPETP plugins. Since most of the plugins share the same requirements for their definitions, this section summarizes the common constraints for plugin definition. Other constraints can be specified in the IANA consideration sections associated with the plugin types. New plugins must be defined by means of an RFC. It is expected that the RFC that defines a new plugin will define also the plugin parameters and, for every parameter o If the parameter is global or local. o The name of the parameter that must an "identifier", i.e., it must satisfy the syntax shown in Figure 15. name = ALPHA *(ALPHA / DIGIT / "-" / "_") Figure 15: Syntax for parameter names o For local parameters, a parameter index that must uniquely identify the parameter among the whole set of parameters. In other words, the parameter index is not local to the specific plugin. For example, if a signature plugin defines a parameter with index 42, no other plugin can define a parameter with the same index. This index is used in the Hello packet to set peer- local parameters during the handshake phase (see Section 5.2.2). o The positional order for global and local parameters. This order is used in some configuration context that allows for a positional specification of parameters. Global and local parameters are ordered independently, that is,there is, for example, a first global parameter and first a local parameter. Bernardini, et al. Expires July 12, 2012 [Page 76] Internet-Draft PPETP January 2012 o How the parameter values are encoded in text form and/or in binary form (depending on the needs of the specific plugin type). 13.2. Reduction procedure registry This document defines a field "Reduction procedure" for which IANA is to create and mantain a new register named "PPETP Sender signature algorithms". Initial values are shown in Table 9. +-------------+----------------+ | Name | Defined in | +-------------+----------------+ | basic | Section 14.5.2 | | vandermonde | Section 14.5.1 | +-------------+----------------+ Table 9 13.2.1. How to define a reduction profile New reduction procedure must be defined with an RFC. The defining RFC MUST specify at least o The profile name and name and type of every profile parameter. o Which reduction parameters are "global" to the whole PPETP session and which are "local" to each peer. (For example, in the Vandermonde profile the value of R is the same for the whole network, while the reduction vector r_b is different for every peer.) o The algorithm to map a content packet to the data packet payload. o The format used to store the reduction parameters in the payload of the Set_Default request and in the payload of a data packet (if the flag Inline is true). o The meaning of the Flags field in the data packet. 13.3. Sender signature procedure registry This document defines a field "Sender signature" for which IANA is to create and mantain a new register named "PPETP Sender signature algorithms". Initial values are shown in Bernardini, et al. Expires July 12, 2012 [Page 77] Internet-Draft PPETP January 2012 +------------+-------+----------------+ | Name | Index | Defined in | +------------+-------+----------------+ | void | 0 | Section 14.1.2 | | shared-key | 1 | Section 14.1.1 | +------------+-------+----------------+ Table 10 13.3.1. Defining new sender signature profiles New entries for the register are to be defined with an RFC. The RFC defining the new entry must specify at least o The profile name and name and type of any required parameter. o Which parameters are "global" to the whole PPETP session and which are "local" to each peer. o Any needed peer parameter to be registered in the "PPETP peer parameters" registry. o The algorithm to obtain the source signature field from the packet. o The algorithm to verify the source signature field. 13.4. Source signature procedure registry This document defines a field "Source signature" for which IANA is to create and mantain a new register named "PPETP Source signature algorithms". Initial values are shown in Table 11. +-------+-------+----------------+ | Name | Index | Defined in | +-------+-------+----------------+ | void | 0 | Section 14.2.2 | | rabin | 1 | Section 14.2.1 | +-------+-------+----------------+ Table 11 13.4.1. Defining new source signature plugins The definition of a new entry for this register must be done with an RFC. The RFC defining the new entry must specify at least Bernardini, et al. Expires July 12, 2012 [Page 78] Internet-Draft PPETP January 2012 o The profile name and name and type of any required parameter. o Which parameters are "global" to the whole PPETP session and which are "local" to each peer. o The algorithm to obtain the source signature field from the packet. o The algorithm to verify the source signature. 13.5. Hello signature procedure registry This document defines a field "Source signature" for which IANA is to create and mantain a new register named "PPETP Source signature algorithms". Initial values are shown in Table 12. +----------+-------+----------------+ | Name | Index | Defined in | +----------+-------+----------------+ | void | 0 | Section 14.3.1 | | id-based | 1 | Section 12 | +----------+-------+----------------+ Table 12 13.5.1. Defining new source signature plugins The definition of a new entry for this register must be done with an RFC. The RFC defining the new entry must specify at least o The profile name and name and type of any required parameter. o Which parameters are "global" to the whole PPETP session and which are "local" to each peer. o The algorithm to obtain the signature field from the packet. o The algorithm to verify the signature. 13.6. Address classes registry It is expected that every class will be associated with an algorithm that from the parameters of the generalized address determines a set of parameters that can be used to contact the other node (typically, an IP address and a port). For example, the algorithm associated with the ice class takes the address of the bridge node (see Section 11) and determines an IP address, a port and, eventually, a local interface to be used to send data to the other peers. Bernardini, et al. Expires July 12, 2012 [Page 79] Internet-Draft PPETP January 2012 In order to define a new address class an RFC is required [RFC5226]. The RFC MUST specify o The name for the GA class and the corresponding index (to be used in the binary format). o The set of associated parameters. More precisely, for every parameter must be specified * Its name * Its syntax when described in text format * If it is mandatory and, eventually, its default value o The format of the binary description o The algorithm that converts the class parameters into data usable to connect with the other peer. 13.7. Peer-local parameters registry This document defines a 15-bit "Parameter index" field, for which IANA is to create and maintain a new registry named "PPETP peer-local parameters register" (PPETP-LOCAL). Assignment of unassigned values require an RFC. The RFC MUST specify o The use of the parameter o A name of the parameter that must satisfy the syntax for name shown in Figure 15. The name must be unique in the sense that there cannot be two parameters with the same name and different index. Names beginning with "x-" are reserved for experimental uses and must never be assigned in the register. o A binary format for the parameter. o A text format for the parameter Initial assignments are given in Table 13. Most of the listed parameters are defined in the sections shown in Table 13, the only parameter defined here is the parameter number 0 ("certificate"). Bernardini, et al. Expires July 12, 2012 [Page 80] Internet-Draft PPETP January 2012 Value PPETP-LOCAL Name Definition ----------- ---------------- ------------------ 0 dh-half-key See Section 14.1.1 1 rabin-public See Section 14.2.1 2-100 Unassigned 101-127 Experimental 128-65533 Unassigned 65534-65535 Reserved Table 13 13.8. Congestion control procedure registry This document defines a field "Congestion control procedure" for which IANA is to create and mantain a new register named "PPETP Concestion control procedure". Initial values are shown in Table 14. +------+----------------+ | Name | Defined in | +------+----------------+ | null | Section 14.6.1 | | tfrc | Section 14.6.2 | +------+----------------+ Table 14 13.8.1. Definition of a new congestion control procedure New congestion control procedures must be defined by means of an RFC. The defining RFC must specify at least o The format of the data packet field reserved to the congestion control procedure. o The format of the payload of the feedback packet. o An algorithm to determine the maximum allowable rate. 13.9. Configuration protocol registry This document defines a field "Configuration protocol" for which IANA is to create and mantain a new register named "PPETP configuration protocol". Initial values are shown in Table 15. Bernardini, et al. Expires July 12, 2012 [Page 81] Internet-Draft PPETP January 2012 +---------+----------------+ | Name | Defined in | +---------+----------------+ | null | Section 14.4.2 | | default | Section 14.4.1 | +---------+----------------+ Table 15 13.9.1. Definition of a new configuration protocol New congestion control procedures must be defined by means of an RFC. The defining RFC must specify at least, beside the protocol itself, o The name of the protocol. o The syntax of the parameter line to be used in an SDP description (see Section 13.10.2). 13.10. SDP extensions 13.10.1. Transport protocols ("proto") The following SDP "proto" [RFC4566] identifiers are proposed for registration: +-------+-------------------+-------------------+ | Type | SDP Name | Reference | +-------+-------------------+-------------------+ | proto | PPETP/RTP/AVP | See this document | | | PPETP-UDP/RTP/AVP | See this document | | | PPETP | See this document | | | PPETP-UDP | See this document | +-------+-------------------+-------------------+ The meaning of the above identifiers is as follows PPETP/RTP/AVP Like RTP/AVP in [RFC4566], but with the data transported over PPETP, with UDP as transport protocol used by PPETP. PPETP-UDP/RTP/AVP Equivalent to PPETP/RTP/AVP PPETP Like UDP in [RFC4566], but with the data transported over PPETP, with UDP as transport protocol used by PPETP. Bernardini, et al. Expires July 12, 2012 [Page 82] Internet-Draft PPETP January 2012 PPETP-UDP Equivalent to PPETP The new protocols inherit the "fmt" namespace of the corresponding protocols defined in [RFC4566]. 13.10.1.1. Meaning of the address in c= for PPETP-related proto fields If a PPETP-related protocol is used in the m= line, the conncetion data in the c= line and the port in the m= line are to be interpreted as follows o The in the c= line is the address of the session reference host. o The in the m= line is the PPETP session number. 13.10.2. Attributes The registration of the following PPETP-related attributes is required ppetp: Used to introduce PPETP options. The first identifier (defined as in the CCDF grammar) is the option name, the meaning of the rest of the line depends on the specific option. In some sense, this attribute can be interpreted as a namespace of options. The only option defined in this document is config-proto By default the session is configured by using the light-weight protocol described in Section 10.1 using by default the port TBD1. This attribute is used to change the configuration protocol. The first token after the option name is the name of the configuration protocol, the remaining of the line contains parameters for the configuration protocol. See Section 13.9.1 for what is needed for defining a new configuration protocol. The definition of new options to be used with this attribute follows the same rules of the definition of new SDP attributes. Some informations required by [RFC4566] for the definition of new attributes can be found in Table 16; the required contact informations are the equal to the contact informations of this document. Bernardini, et al. Expires July 12, 2012 [Page 83] Internet-Draft PPETP January 2012 +-------+-----------------+--------------------+---------+----------+ | Name | Long name | Type | Charset | Value | | | | | | spec | +-------+-----------------+--------------------+---------+----------+ | ppetp | PPETP option | session and media | No | ****** | | | setting | level | | | +-------+-----------------+--------------------+---------+----------+ Table 16: IANA informations for new SDP attributes 14. Built-in plugins PPETP demands some duties to several "plugins" (e.g., reduction and signature profiles, NAT traversal procedures) whose definition is not part of the PPETP "core". In order to make PPETP usable without waiting for the definition of all the necessary plugins, this section defines some built-in plugins thata MUST be implemented by any PPETP implementation. 14.1. Sender signature profiles 14.1.1. Shared key signature profile 14.1.1.1. Profile name and parameters The name of this profile is "shared-key". This profile employs an HMAC algorithm (such as the algorithm described in [RFC2104]) and the Diffie-Hellman key agreement schem of [RFC2631]. This profile requires the following global parameters o An HMAC algorithm. At least HMAC-SHA-256 of [RFC2104] MUST be supported. The name of this parameter is "hmac". The only value currently accepted for hash is "HMAC-SHA-256", but other values can be added in future. o A positive integer "mac-size" not larger than the number of octets required by the result of the HMAC function (e.g., not larger than 32 if HMAC-SHA-256 is employed). o Two parametrs ("dh-prime" and "dh-generator", called, respectively, "p" and "g" in [RFC2631]) used for the key agreement procedure. o An optional parameter "dh-aux-prime" (called "q" in [RFC2631]) that can be used to check the validity of the public key. and the following peer-local parameters Bernardini, et al. Expires July 12, 2012 [Page 84] Internet-Draft PPETP January 2012 dh-half-key This is the public key of the peer (called "ya" or "yb" in [RFC2631]). A summary of the parameters is given in Table 17. See also Appendix B.3 for some remarks about this profile. +--------------------+----------------+----------------+ | Parameter | Attribute name | Default value | +--------------------+----------------+----------------+ | Algorithm | "hmac" | "HMAC-SHA-256" | | MAC size in octets | "max-size" | 32 | | Prime in DH | "dh-prime" | No default | | Aux Prime in DH | "dh-aux-prime" | No default | | Generator in DH | "dh-generator" | No default | +--------------------+----------------+----------------+ Table 17: Configuration parameters for the shared key signature profile 14.1.1.2. Key agreement The two peers agree on the shared secret by using the algorithm described in [RFC2631], omitting the optional part "partyAInfo" and setting the algorithm field in KeySpecificInfo to the OID "1.2.840.113549.2.9" corresponding to the HMAC scheme HMAC-SHA-256 [RFC4231] [RFC2104]. 14.1.1.3. Payload construction The packet is processed using the HMAC algorithm specified by the "hmac" parameter using as key the shared secret compute as explained in Section 14.1.1.2. The first mac-size bits of the result of the HMAC function are the signature payload. Signature verification is done in the obvious way. 14.1.2. Void signature profile This profile does not add any signature to the packet. It is defined for those cases where signatures would be redundant. 14.1.2.1. Profile name and parameters The name of this profile is "void". This profile defines no parameters Bernardini, et al. Expires July 12, 2012 [Page 85] Internet-Draft PPETP January 2012 14.1.2.2. Creating the signature This profile does not create any signature. The payload is empty. 14.1.2.3. Verifying the signature The signature check is always positive. 14.2. Source signature profiles 14.2.1. Rabin signature profile This profile is based on the Rabin signature algorithm [RABIN] 14.2.1.1. Profile name and parameters The name of this profile is "rabin". This profile defines the following parameters o A parameter "sign-size" assuming positive values less or equal than 16. o A parameter "tail-size" assuming positive values less or equal than 8. 14.2.1.2. Creating the signature The procedure to compute the source signature is the following: 1. The procedure is parametrized by two positive integer values: s <= 16 and u <= 8. 2. At the beginning the node generates two 4*sign-size-bit prime numbers p and q (the node private key) and compute the sign-size- octets value n=p*q (the public key). 3. To sign a packet, the node concatenates the whole routed packet (including the routing data block, but not the signature) with a tail-size-octets random value U and process the result with SHA- 256. Let Y be the final value. 4. The node finds x such that Y = x^2 mod n. If such an x does not exist, the node draws a new U, goes back to the previous step and tries again. The expected number of trials is four. Note that the node can find efficiently x because it knows p and q. 5. The signature is given by the (sign-size+tail-size)-octets value 2^(8*tail-size)*x + U. Such a values is stored in the Source Bernardini, et al. Expires July 12, 2012 [Page 86] Internet-Draft PPETP January 2012 Signature field with any unused most significant bits set to zero. 14.2.1.3. Verifying the signature The procedure to verify the signature is the following 1. From the knowledge of the source ID, determine the source public key n. If no public key is associated to the source ID, the verification fails. 2. Extract values x and U from the Originator Signature field 3. Concatenate U with the packet and process the result with SHA-256 to obtain T. 4. Verify that T = x^2 mod n The association of the public keys with the corresponding peer ID is supposed to be done by extra-PPETP means. 14.2.2. Void signature profile This profile does not add any signature to the packet. It is defined for those cases where signatures would be redundant. 14.2.2.1. Profile name and parameters The name of this profile is "void". This profile defines no parameters 14.2.2.2. Creating the signature This profile does not create any signature. The payload is empty. 14.2.2.3. Verifying the signature The signature check is always positive. 14.3. Hello signature profiles 14.3.1. Void signature profile This profile does not add any signature to the packet. It is defined for those cases where signatures would be redundant. Bernardini, et al. Expires July 12, 2012 [Page 87] Internet-Draft PPETP January 2012 14.3.1.1. Profile name and parameters The name of this profile is "void". This profile defines no parameters 14.3.1.2. Creating the signature This profile does not create any signature. The payload is empty. 14.3.1.3. Verifying the signature The signature check is always positive. 14.4. Configuration Protocols 14.4.1. Light-weight configuration protocol 14.4.2. Null configuration protocol 14.5. Reduction profiles 14.5.1. Vandermonde reduction profile 14.5.1.1. Profile name and parameters The profile name is "vandermonde". This profile defines the following parameters. gf_size This parameter can assume the values 1, 2 and 4 and determines the size of the Galois field used. More precisely, gf_size is the size in octets of an element of the Galois field, therefore the Galois field relative to gf_size is GF(2^(8*gf_size)). reduction-factor This is (approximately) the ratio between the size of a content packet and its reduced version. This value was called R in Section 2.5. reduction-base This is the element of GF(2^(8*gf_size)) used to construct the reduction vector. This value was called b in Section 2.5. Parameters gf_size and reduction-factor are global for the whole PPETP session, value reduction-base is, of course, local to each node. Depending on the configuration, the value of reduction-base can be chosen autonoumisly by the peer or it can be imposed to the peer by some external entity. Bernardini, et al. Expires July 12, 2012 [Page 88] Internet-Draft PPETP January 2012 14.5.1.2. Payload construction The payload construction is based on the ideas of [DCC08]. The payload is constructed as follows 1. Define, for the sake of compactness, d=8*gf_size, B=reduction- base and R=reduction-factor. 2. Let the elements of GF(2^d) be represented as described in Section 14.5.1.2.1. 3. At startup the node constructs the row vector r = [1, B, B^2, ..., B^(R-1)] 4. The packet to be reduced is mapped in a matrix G with R rows and L/(gf_size*R) columns with entries in GF(2^d) as follows A. The packet is padded, as described in Section 14.5.1.2.2, to a length multiple of gf_size*R octets. Let L be the length, in octets, of the padded packet. B. Let b[n] be the n-th octet of the padded packet, with n=0 denoting the first octet. For every m=0, 1, ..., L/gf_size, interpret the sequence of gf_size octets b[gf_size*m], b[gf_size*m+1], ..., b[gf_size*(m+1)-1] as an element of GF(2^d) as described in Section 14.5.1.2.1. Let g[m] be the element of GF(2^d) associated to b[gf_size*m], b[gf_size*m+1], ..., b[gf_size*(m+1)-1]. C. Define G as the matrix whose element in row r and column c is g[r+ R*c], where r=0, 1, ..., R-1 and c=0, 1, ..., L/(R*gf_size)-1. 5. Matrix G is left-multiplied by vector r to obtain row vector U=r*G 6. Every element of U is mapped to gf_size octets (still according to the representation escribed in Section 14.5.1.2.2) to obtain a string of L/R octets that represents the payload of the data packet. 14.5.1.2.1. Galois field implementation If d=8, 16 or 32, let GF(2^d) be the field of polynomials with coefficients in GF(2) (i.e., the integers modulo 2) modulo the polynomials shown in Table 18. The element of GF(2^d) associated with Bernardini, et al. Expires July 12, 2012 [Page 89] Internet-Draft PPETP January 2012 c_{d-1} x^(d-1) + c_{d-2} x^(d-2) + ... c_1 x + c_0 (where each c_n = 0, 1) is represented by the d-bit unsigned integer C=2^(d-1) c_{d-1} + 2^(d-2) c_{d-2} + ... 2 c_1 + c_0 This integer can be represented as a sequence of octets b_0, b_1, b_{d/8-1} in little endian order, that is C = b_0 + 256 b_1 + 256^2 b_2 + ... +----+-----------------------------+ | d | Polynomial defining GF(2^d) | +----+-----------------------------+ | 8 | x^8+x^4+x^3+x^2+1 | | 16 | x^16+x^5+x^3+x^2+1 | | 32 | x^32+x^15+x^9+x^7+x^4+x^3+1 | +----+-----------------------------+ Table 18: Polynomials used to define GF(2^d) 14.5.1.2.2. Packet padding 1. Let length(P) be the size in octets of the content packet P to be padded and let the padding length L be L=(gf_size*R) - (length (P) mod (gf_size*R)) 2. Note that L+length(P) is always a multiple of R*gf_size. Note also that if length(P) is already a multiple of R*gf_size, the packet will be padded with L=R*gf_size bytes, although no padding would be necessary. It was chosen to add the padding also when length(P) is already a multiple of R*gf_size for the sake of simplicity, in order to not handle special cases. The overhead in bandwidth is expected to be negligible (an average of gf_size bytes every R*gf_size packets, that is, 1/R byte per packet) 3. A. Append L zeros to the packet. B. Decompose L as L = A*128 + B where 0 <= B < 128. C. If A=0 (that is, the padding length is less than 128), write B in the last octet of the padded packet D. If A > 0, write B+128 in the last octet of the padded packet and write A in the penultimate octet The algorithm above can be summarized by saying that the most significant bit of the last octet of the padding acts as a flag: if Bernardini, et al. Expires July 12, 2012 [Page 90] Internet-Draft PPETP January 2012 it is zero, we know that the padding length was less than 128 and that its value is in the last octet; if it is one, we know that the padding length was greater or equal than 128 and that its value is stored in the last two octets. Note that using only one octet would limit the padding size to 255 and that we cannot always use two octets because the padding size could be 1. 14.5.1.3. Profile-related definitions Data packet flags: Flags F, G and H are unused. Flag I has its default meaning of "Inline". Set_Default payload The payload of the Set_Default command is used to transfer the value chosen for reduction-base. Such a value is represented as a sequence of gf_size octet used as the payload of Set_Default. Payload with the Inline bit set If the Inline bit is set, the value of reduction-base, encoded as explained above, is prepended to sequence of octets resulting from the reduction procedure. The result is the payload of the data packet. Profile-specific request This profile defines no profile-specific request. 14.5.2. Basic reduction profile This is a very simple profile that just copies the content packet in the payload. It can be used to distribute streams with a low bit- rate (e.g., RTCP streams). 14.5.2.1. Profile name and parameters The profile name is "basic". This profile defines no parameters. 14.5.2.2. Payload construction The payload is a verbatim copy of the content packet. 14.5.2.3. Profile-related definitions Data packet flags: Flags F, G and H are unused. Set_Default payload: Set_Default carries no payload. Bernardini, et al. Expires July 12, 2012 [Page 91] Internet-Draft PPETP January 2012 Payload with the Inline bit set: Inline bit is unused. Profile-specific request: This profile defines no profile-specific request. 14.6. Rate control procedures 14.6.1. Null procedure This rate control procedure makes no rate control at all. Its use is NOT RECOMENDED unless in those cases where it is absolutely certain that rate control is not necessary. It is expeceted that its use will be mostly for experimental and/or debug purposes. This profile Name The name associated to this procedure is "void" and its index is 0. Data packet field definition The rate control field in the data packet is empty Feedback packet payload The payload of the feedback packet is empty. Allowable rate computation The allowable rate is fixed and determined by external means (e.g., the maximum rate allowed for the network connection or a rate chosen by the user via a GUI). 14.6.2. TFRC-based procedure This procedure is based on the TCP-friendly rate control procedure as described in [RFC5348]. It is the default rate control procedure for PPETP. Its profile definitions are as follows Name The name associated to this procedure is "tfrc" and its index is 1. Data packet field definition The rate control field in the data packet stores a 15-bit integer (see Section 4.1) representing the estimated round-trip-time (RTT) in ms. In the unlikely case that the RTT is larger than 2^15-1=32,767ms the transmiter MUST set its value to 2^15-1. Feedback packet payload The payload of the feedback packet is shown in Figure 16 and it includes the following values Bernardini, et al. Expires July 12, 2012 [Page 92] Internet-Draft PPETP January 2012 Received timestamp (bits 0-31) The timestamp of the last data packet received. This field is computed as the number of ms since 1/1/1970 modulo 2^32. Note that this field wraps around after approximately 49 days. Processing delay (bits 32-47) The amount of time (in ms) elapsed between the receipt of the last data packet and the generation of this feedback report. Reception rate (bits 48-57) The rate, in number of packets per round trip time, at which data were received in the previous round-trip time. The actual rate is equal to the value of this field divided by 4. The maximum rate is approximately 256 packets per round trip time. P_loss (bits 58-63) The receiver's current estimate of the loss event rate. The actual value is the value of this field divided by 64. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Received Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Processing Delay | Reception rate | Ploss | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Payload of the feedback request for the TFRC profile 15. References 15.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. Bernardini, et al. Expires July 12, 2012 [Page 93] Internet-Draft PPETP January 2012 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. [RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC- SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA- 512", RFC 4231, December 2005. [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Bernardini, et al. Expires July 12, 2012 [Page 94] Internet-Draft PPETP January 2012 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", RFC 5348, September 2008. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. 15.2. Informative References [DCC08] Bernardini, R., Rinaldo, R., and A. Vitali, "A Reliable Chunkless Peer-to-peer architecture for multimedia streaming", proc. Data Compression Conference, Snowbird, Utah pages 242-251, march 2008. [RABIN] Rabin, M., "DIGITALIZED SIGNATURES AND PUBLIC-KEY FUNCTIONS AS INTRACTABLE AS FACTORIZATION", 1979. [IPTV] Hei, X., Liu, Y., and K. Ross, "IPTV over P2P Streaming Networks: The Mesh-Pull Approach", IEEE Communications Magazine Vol 46, N. 2, 86-92, February 2008. [ppetp-ice] Bernardini, R., Cesco Fabbro, R., and R. Rinaldo, "ICE connection establishment for the Peer-to-Peer Epi- Transport Protocol", April 2010. [json-schema] Zip, K., "A JSON Media Type for Describing the Structure and Meaning of JSON Documents", November 2010. Editorial Comments [remark-unique-name] Maybe there is a problem with the unicity of the name: the idea is that if the pseudo- address was expressed as a FQDN, than the pseudo-address is the FQDN; if the pseudo- address was given in numeric form, then the value used in the name should be the pseuod- address suitably normalized. Bernardini, et al. Expires July 12, 2012 [Page 95] Internet-Draft PPETP January 2012 Appendix A. Examples This non-normative section contains some examples of possible applicative contexts for PPETP. Warning: The following examples suppose that some protocols (e.g., RTSP, SDP) have been extended to adapt them to PPETP. At the time of writing, those supposed extensions are only hypotetical and it could happen that they will never be added to the protocols, making the examples in this section not enterly correct. However, the goal of this section is not to be normative, but to show some examples of how PPETP _could_ be used in multimedia applications. A.1. Live media This example considers a live streaming application, with a single source and a possibly large number of users. Most of users are of the "residential" type and behind NATs. In this example we suppose that Alice (A) has an account with a streaming service provider and wants to receive a live concert streamed over PPETP. We also suppose that Bob (B) is already connected to the network. Both Alice and Bob are behind NATs. The network topology is managed by a central "network manager" belonging to the streaming service provider and denoted in the following with the letter N. The "starting point" of Alice is a web page at the web server (W) www.example.com; the web page contains a link to the media server (M) with the content description A->W: GET /sessions.html HTTP/1.1 HOST: www.example.com W->A: HTTP/1.1 200 OK Content-Type: text/html Best concert ever When Alice clicks on the link, the web browser launchs a "viewer" (an external program or a plugin) that contacts the RTSP server. Bernardini, et al. Expires July 12, 2012 [Page 96] Internet-Draft PPETP January 2012 A->M: DESCRIBE rtsps://live.example.com/concert RTSP/2.0 CSeq: 1 M->A: RTSP/2.0 200 OK CSeq: 1 Content-Type: application/sdp ... other headers ... v=0 ... other SDP lines ... c=IN IP4 ppetp.example.com ... other SDP lines ... m=video 12345 RTP/AVP/PPETP 34 a=control: rtsps://live.example.com/concert/video The SDP description of the streaming session shows that the video is streamed over PPETP (see the m= line). The configuration server is ppetp.example.com (see c= line) and the session ID is 12345 (see m= line). Alice's agent opens a local "PPETP socket" and configures it by calling a pseudo-connect() with the pseudo-address (ppetp.example.com, 12345) as a parameter. The pseudo-connect() sends a query packet (see Section 10.1) to configuration server (C) ppetp.example.com. B->C (12345, 0) C->B (401, 0 | USE-NONCE=98765, REALM=example) Here we represent a request packet with the pair (Session_ID, Query_Number) (we suppose the version number always equal to 0) followed, eventually, by "|" and the list of attributes. Similarly, a reply packet is represented with the pair (Error code, Query_Number) followed by the list of attributes. In this case we suppose that the configuration server is configured to require user authentication, so it replies with an error code 401 (Unauthorized) and adds a nonce to the attribute list. Alice's agent asks to Alice a username/password pair valid for realm "example" and reformulates the query to ppetp.example.com. B->C (12345, 1 | NONCE=98765, REALM=example, USERNAME=alice, USE-NONCE=88888, LOCAL-NONCE=11111, SIGNATURE=23xgajdav) Note that the values for NONCE and REALM are taken from the reply of the configuration server. Note also the increased request number. Alice also requests the server to authenticate itself by adding the Bernardini, et al. Expires July 12, 2012 [Page 97] Internet-Draft PPETP January 2012 USE-NONCE attribute. The server checks the signature and replies with an error code 300 (Try other) to redirect Alice to a different (fictional) configuration protocol based on HTTP. C->B (300, 1 | REALM=example, USERNAME=bob, NONCE=88888, LOCAL-NONCE=25252, PROTOCOL=https|netmanager.example.com/12345?q=da..23, SIGNATURE=daghj391) In the reply above the vertical bar "|" separates the alternative protocol name from its parameter. Alice sends a POST request to the network manager (N) using as URL the specifiedparameter B->N: POST 12345?q=da...c23 HTTP/1.1 Host: netmanager.example.com ... other headers ... N->B: HTTP/1.1 200 OK ... other headers ... Content-type: application/ppetp-ccdf pvandermonde agf-size=4 ared-fact=2 Nhmac amac-size=10 adh-prime=ce98df..23 adh-generator=ccf382..13 no00000002 arabin-key 123...ab nu12abcd09 3 cice4 bridge.example.com E...base64 string... nuabcd1234 cice4 bridge.example.com E...base64 string... nu01234567 5 cip4 192.10.1.4 E...base64 string... B->N: POST 12345?q=da...c23 HTTP/1.1 Host: netmanager.example.com ... other headers ... N->B: HTTP/1.1 200 OK ... other headers ... Bernardini, et al. Expires July 12, 2012 [Page 98] Internet-Draft PPETP January 2012 Content-type: application/ppetp-ccdf pvandermonde agf-size=4 ared-fact=2 Nhmac amac-size=10 adh-prime=ce98df..23 adh-generator=ccf382..13 no00000002 arabin-key 123...ab nu12abcd09 3 cice4 bridge.example.com E...base64 string... nuabcd1234 cice4 bridge.example.com E...base64 string... nu01234567 5 cip4 192.10.1.4 E...base64 string... The network manager, as a consequence of the POST request of Alice, assigns to Alice three upper peers with peer IDs 0x12abcd09, 0xabcd1234 and 0x01234567. In the example we suppose that the first two peers are behind a NA (so they have a generalized address of class "ice"), while the third peer has a public IP (and a generalized address of class "ip"). It is reasonable to expect that the network manager will use, for example, the type of subscription to decide how many upper peers to assign to Alice and that maybe the assignment is done in order to optimize some figure of merit such as locality. In the example, the configuration data is sent to Alice in the CCDF defined in Section 10.2. From the configuration data we can see that the reduction profile employed is vandermonde, the size of the Galois field is 2^32 and that the reduction factor is 2. Since Alice has three upper peers, she receives redundant data. Note that the server does not specify the "reduction-base" parameter, so Alice will choose one at random. Since a large Galois field is employed (2^32 elements), the probability that two nodes choose the same reduction- base is very small. Note that the configuration data above includes a fourth peer with peer ID equal to 2. Note that the peer is not an upper nor a lower peer, since its type is "o" (other). Since no special security policies are employed, this peer is authorized to send routed packets; the attribute "rabin-key" is the public key used to sign the routed packets. Bernardini, et al. Expires July 12, 2012 [Page 99] Internet-Draft PPETP January 2012 Since the HTTP transaction is done over a secure connection, Alice can trust the data received in the HTTP dialogue, in particular the public key of the peer with ID 2. Suppose that the first upper peer is Bobs's node. Since the address of Bob is of class "ice", Alice needs to carry out the ICE-based NAT traversal procedure described in [ppetp-ice], therefore (see also Figure 17) 1. Alice gathers her candidate addresses [RFC5245] and sends them the bridge by issuing over HTTPS (at the default port 443) a POST request with Request-URI /connect?from=54321&to=13109111&sess=303A@ppetp.example.com . 2. The bridge, after receiving Alice's request, sends to Bob a routed control packet Open with the generalized address of Alice. That address will be of class ICE and it will contain the address of the bridge and the peer ID of Alice. In an alternative setup, the Open request could be sent to Bob by the network manager, after having assigned Bob as upper peer to Alice. 3. Bob gathers his candidate addresses and sends them to the bridge host as body of a POST request with Request-URI /connect?from=13109111&to=54321&sess=303A@ppetp.example.com . 4. The bridge host, by matching the two Request-URI, finds that Alice requests matches Bob's. The bridge sends to Bob the body sent by Alice and vice versa. 5. Alice and Bob carry out the ICE procedure to find an address pair that works. At the end of this procedure both Alice and Bob reach the CONNECTED state. 6. When a working address pair is selected, Alice sends to Bob a Hello packet with her credential and Bob sends to Alice an Hello packet with his credentials. 7. Alice waits for the Hello packet of Bob and for the ACK to her Hello command. When both are received, Alice reachs the INTRODUCED state. A similar remark holds for Bob. 8. When both node reached the INTRODUCED state, Bob sends a Start command to Alice. If security policies do not allow not- privileged nodes to send data control commands, the network manager can send with its reply a representation of a routed packet signed by an authorized node. Bernardini, et al. Expires July 12, 2012 [Page 100] Internet-Draft PPETP January 2012 9. Alice sends in reply a Set_Parameter command and, after receiving the corresponding ACK, begins streaming data packets to Bob. Alice Bridge Bob | | | | POST (1) | | +-------------->| | | | OPEN (2) | | +--------------->| | | | | | POST (3) | | |<---------------+ | | | | (4a) | | | CANDIDATES | (4b) | |<--------------+ CANDIDATES | | (Bob's) +--------------->| | | (Alice's) | | | | | /----------------------------\ | |/ .. ... ... ... ... ... ... \| < ... ... ... ICE (5) ... ... . > |\ .. ... ... ... ... ... ... /| | \----------------------------/ | | | | | HELLO (6a) | |<-------------------------------+ | | | | HELLO (6b) | +------------------------------->| | | | | ACK (6c) | +------------------------------->| | | | | ACK (6d) | |<-------------------------------+ | | | | | ACK (7) | | |<---------------+ | | | SEND (8a) | +------------------------------->| | | | ACK (8b) | |<-------------------------------+ | | Bernardini, et al. Expires July 12, 2012 [Page 101] Internet-Draft PPETP January 2012 | Set_Parameter (9a) | |<-------------------------------+ | | | ACK (9b) | +------------------------------->| | | |/... ... ... ... ... ... ... .. | < ... ... Data Streaming ... .. | |\... ... ... ... ... ... ... .. | Figure 17: ICE procedure between Alice and Bob A.2. Remote lecturing This example is, in a sense, opposite to the example in Appendix A.1: there is a small number of nodes, most of them with a public IP (and trusted) and every node is also a source. Suppose that Alice is a teacher that wants to do lecturing over the Internet. All the students will be collected in a single conference, each student will be able to ask questions and the question will be heard by all the participants. Note that this a "weak form" of teleconference since there is one actor that talks most of the time (the teacher) and the other actors that talk every now and then. It can be expected that this poses less stringent constraints about the latence of the packets, so that we can afford longer paths between peers. Alice begins by doing some preliminary operations o She starts on her host (alice.example.com) a software that will play the role of network manager o She opens two PPETP sockets (one for RTP and the other for RTCP) on her host and configure them. Since the lecture will be video, she decides to use the Vandermonde reduction profile for the RTP socket, while she will use the basic profile for the RTCP socket (due to the low bandwidth requirements of RTCP). Moreover, since she knows her students and thrust them, she decides to use (on both sockets) the void profile for both sender and source signatures. Alice assigns ID 4242 to the RTP session and ID 4243 to the RTCP session. o She starts a software that reads her camera, encodes the video data, put them in RTP packets that are written to the PPETP socket. Moreover, the same software will also read the PPETP RTP Bernardini, et al. Expires July 12, 2012 [Page 102] Internet-Draft PPETP January 2012 socket, decode the received data and show them to Alice. Since in this case we have more than one source (Alice and her students), the software will distinguish the different sources on the basis of the SSRC in the RTP packets (showing, for example, each student in a small thumbnail). The same software will also take care of the RTCP packets sent to/received from the RTCP socket. Now Alice can invite her students. Alice sends to each student of her an INVITE SIP request carrying in the body an SDP description similar to the following v=0 ... other SDP lines ... c=IN IP4 alice.example.com ... other SDP lines ... m=video 4242 RTP/AVP/PPETP 34 The SDP description shows that the streaming will happen via RTP over PPETP. The convention for the session ID is equal to the convention used of RTP/RTCP ports: even ID 4242 is the ID of the RTP stream and the successive ID (4243) is the ID of the RTCP stream. Since the transport protocol in the m= line is PPETP, the same convention used for multicast addresses in SIP is used: everyone reads and writes from/to the same address. The program running on the host of the student will open two PPETP sockets and will configure them by "pseudo-connecting" them to the pseudo-ports 4242 and 4243 of alice.example.com. The network manager will also assign to the student a Stream ID and will take care that the topology of the resulting network of peers is such that a packet sent by a peer will be delivered to all the other peers. Note that this is different from the live streaming case since in that case there was a single source and the network could be an acyclic graph; in the case of the conference the graph must be strongly connected. After the configuration phase, the student host will read/write RTP (RTCP) packets from/to the RTP (RTCP) socket. Appendix B. Rationale Some choices done in the development of PPETP are not obvious and it could seem that alternative approaches were possible. This (informative) section gives a brief explanation for some of these non-obvious choices. Bernardini, et al. Expires July 12, 2012 [Page 103] Internet-Draft PPETP January 2012 B.1. Plugin structure The plugin idea was initially inspired by the RTP profiles [RFC3550]. B.2. Direct acknowledgement in routed packets As explained in Section 5.3 the Acknowledge of a routed packet is sent back directly to the source peer, without routing through the P2P network and requiring that the source peer has a public IP. An alternative approach could be routing the Acknowledge back to the Source peer, having each peer to propagate the Acknowledge back to the peers that sent it the original packet. However, this solution has been discarded for the following reasons o It is expected that this feature will be used mainly by servers (with public IP address) that need to send control packets to the nodes of the network. o If this feature is needed also by non-privileged nodes, one can setup a "reflector" node with a public IP address by using the following approach 1. A non-privileged peer that needs to route a control packet, sends the routed packet to the reflector. 2. The reflector checks the signatures and that the control packet is legitimate. If all the checks are positive, it re- sends the packet with the Source Peer ID set to its own Peer ID and adding its address in the ACK target field and its own source signature. 3. The Acknowledge of the command will come back to the reflector that will forward it (via routing) to the source of the original control packet. o If the back propagation of the Acknowledge packet was used, an intermediate node could change the result contained in the packet. Note that the Sender Signature is ineffective in counteracting this since it grants for the identity of the sender, but not for the packet content which is granted by the source signature. However, checking the source signature requires the knowledge of the public key of the source of the Acknowledge packet (that is a node of the network) and this could be not feasible in very large networks. Bernardini, et al. Expires July 12, 2012 [Page 104] Internet-Draft PPETP January 2012 B.3. Shared key sender signature Shortening the signature The possibility of having the MAC shorter than the hash allows to reduce the bandwidth required by the signature in those applications that do not need the strength of the full MAC. B.4. Specifying the peer identiy In Section 12.3 it is said that the identity to be used in the identity-based signature for Hello packets can be specified o Using an identity built from the Peer ID and the session name o Using the IDENTITY attribute The reason for having these two mechanisms is that they have complementary characteristics o If we use build the from the Peer ID and the session name, we can use a compact Hello packet. However, since the identity constructed in this way is ephimeral, the key generator must generate a new key every time the node joins a new session. o If we use the IDENTITY attribute, we need a larger Hello packet, but we can use a long-term identity (e.g., the user e-mail, possibly encrypted for privacy) and the key generator needs to create the user long-term private key only once. Appendix C. Ritagli -- Maybe obsolete Generic attribute. Its value is to be used as parameter of the configuration protocol given in PROTOCOL and its meaning depends on the specific protocol. More than one PARAMETER attribute can be present in the same reply. For example, if PROTOCOL refers to an HTTP-based protocol, the first parameter could be an URL to be queried for the configuration data. Other parameters could include, for example, some type of credential. The ID-based signature algorithm is parametrized by several values, e.g., the elliptic curve to be used, the hash functions to be used and so on. It is reasonable to assume that there will be some "standard" choices for this set of parameters. The value of this attribute is a single octet that identifies a pre-determined set of parameters. If one wants to use a set of parameters that does not coincide with a pre-determined set, it is possible to specify all the parameters by using the attribute PARAMETERS. Bernardini, et al. Expires July 12, 2012 [Page 105] Internet-Draft PPETP January 2012 The ID-signature algorithm uses two hash functions, an elliptic curve and an integer "security value". All these parameters can be specified by using this attribute. The format of the value is as follows o The first octet represents an hash function. o The second octet represents an hash function. o The following four octets are the security parameter. o The last part represents the elliptic curve to be used * If this section is one octet long, it is an elliptic curve index. * Otherwise, it specifies all the elliptic curve parameters Exponent of Round Trip Time (ERT, bits 44-45) Used together with the RTT field (bits 56-63) to determine the round trip time estimated by the upper peer. See explanantion of the RTT field. Round Trip Time (bits 56-63) The round trip time as estimated by the upper peer. (This is necessary for the congestion control algorithm.) The actual value T_rtt of the round trip time expressed in ms is computed from this field and the field ERT (bits 44-45) as follows T_rtt = t_offset + K * RTT where RTT is the value of the RTT field and t_offset and K are functions of the ERT field as shown in Table 19. This special enconding (similar to a floating point description) allows to encode round trip times up to 10,976 ms, with resolution of 1 ms for small time values. If the round trip time is larger than the maximum rapresentable value, the upper peer MUST set ERT=3 and RTT=255. +--------+--------+------------------+-----------+ | Bit 44 | Bit 45 | t_offset (in ms) | K (in ms) | +--------+--------+------------------+-----------+ | 0 | 0 | 0 | 1 | | 1 | 0 | 256 | 2 | | 0 | 1 | 256*3 = 768 | 8 | | 1 | 1 | 256*11 = 2816 | 32 | +--------+--------+------------------+-----------+ Table 19: Constants used in the interpretation of the RTT field Bernardini, et al. Expires July 12, 2012 [Page 106] Internet-Draft PPETP January 2012 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (Following length octets) Figure 18: TLV format of PPETP attributes 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| Cred. Type | Cred. Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Credential Value : : (variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: Format of a cryptographic credential 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| Cred. Type | Cred. Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Certificate : : (optional, variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: Format of a credential certificate C.1. Behavior of a PPETP node In order to make clearer the formal description of PPETP given in the following sections, it is worth to describe some possible typical uses of PPETP. Because of the introductury nature of this section, the examples given here will leave out many details. A much more detailed version of these examples can be found in Appendix A. C.1.1. Live streaming Suppose Alice wants to watch a concert that it is streamed over PPETP by a streaming provider. A possible sequence of actions is the following Bernardini, et al. Expires July 12, 2012 [Page 107] Internet-Draft PPETP January 2012 1. Alice goes to the web page of the streaming provider, finds a link related to the concert and clicks on it. 2. The href attribute of the link points to an RTSP server with the program description. The web browser launchs a "viewer" (an external program or a plugin) that queries the RTSP server and discovers that the program is streamed over PPETP. 3. The viewer opens a PPETP socket (using maybe a ppetp_socket() function, akin of the BSD socket() function) and binds it to an UDP port. 4. The viewer sends a SETUP request to the RTSP server, saying in the Transport: header that it is ready to receive data over PPETP. Since Alice has an account with the streaming provider, the viewer includes authentication data in the SETUP request. In this way the server knows who Alice is and the quality of service she is entitled to receive. 5. The RTSP server sends in the entity of the response to the SETUP request all the data required to configure the PPETP session (e.g., the reduction profile employed). If the RTSP exchange is done over "rtsps:", Alice can trust the correctness of received informations. 6. Alice's viewer uses the information received with the response to configure the PPETP socket (maybe with a function similar to the BSD setsockopt()). 7. Now Alice's viewer needs to contact some upper peers in order to receive the streamed data. This phase can be carried out in several different ways, all compatible with PPETP, since, as said, PPETP does not specify an algorithm to find the upper peer, but leaves this decision at the application level. For the sake of this example we will suppose that the streaming provider manages the PPETP network; therefore it chooses the upper peers of Alice and send them a request to begin the data streaming toward Alice. If an upper peer is behind a NAT, the request will include information necessary to start a suitable NAT traversal procedure. Although this centralized solution could seem to introduce a "single point of failure" and go against the spirit of peer- to-peer networks, it must be said that + In this case there is a single entity (the streaming provider) that is the source of data and that is interested in doing the streaming. If the provider host Bernardini, et al. Expires July 12, 2012 [Page 108] Internet-Draft PPETP January 2012 fails, the only data source fails and the whole system makes no sense. + Letting the server to assign the upper peers to Alice allows for a finer control of the quality of service assigned to Alice. For example, if Alice is subscribed to a "high-reliability" service the server will assign her more upper peers, in order to lower the packet loss probability experienced by Alice. Moreover, if desired, the upper peer assignament could be done in order to maximize some figure of merit (e.g., locality). Other possible solutions for peer assignament are discussed in Appendix C.1.1.1. 8. Alice's host begins receiving reduced data. As soon as enough data are received, the content packets are recovered and moved to the application level. Alice's viewer will read the recovered data via a suitable function of the PPETP API (something similar to the recv() function in the BSD socket API). The read data will be given to the decoder and shown to the user. 9. Suppose now that Bob joins the network and that the server assigns him Alice as an upper peer. The PPETP software on Alice's host will receive a request from the server that asks Alice to send data to Bob. 10. In response to the received request the PPETP software on Alice applies the reduction procedure to the recovered packets and forwards the result to Bob. 11. When Alice wants to stop to watch the concert, her software sends a TEARDOWN request to the RTSP server that in turn sends suitable requests to the upper peers of Alice, asking them to stop the transmission toward Alice and maybe redirecting their stream to the lower peers of Alice (that now would loose one upper peer). Note that if the lower peers of Alice have more upper peers than the minimun necessary, they will not notice the leaving of Alice since they will keep receiving enough data to recover the content packets. Alternatively, Alice herself can send suitable redirect commands to her upper peers, asking them to redirect their data stream to the lower peers of Alice. Bernardini, et al. Expires July 12, 2012 [Page 109] Internet-Draft PPETP January 2012 It is worth to emphasize that most of the P2P management (e.g., processing control packets, doing NAT transversal, handshaking with the new peer) is handled by the PPETP library and it does not arrive at the application level (this is similar to what happens with TCP where all the handshaking and packet retransmission stuff is handled by the TCP software and never reachs the application). The application just needs to open a PPETP socket, configure it with the information received from the server, read data from it and close it when done. C.1.1.1. Alternative setups In the example above we supposed a very centralized approach to the management of the PPETP network, where the server chooses the upper peers and send them the request to send data to the new node. This is not the only possible solution, for example, o The server could choose the upper peers of the new node, but let the new node to contact them. The server could send the upper peer list in the configuration data. o The server just takes a "handful" of upper peers and sends them to the new node. The new node will contact each peer and ask it for data. If the peer has no more upload bandwidth available, it refuses the request and the new node will try another peer. Note that with this setup it is difficult to make sure that the new node does not get more than its fair share of upper peers, but maybe in some applicative context (e.g., conferencing with a small number of partecipants) this could be not a problem. o A possible "strongly distributed" solution is the following: the nodes in the PPETP network are also organized as a Distributed Hash Table (DHT) where to each node is assigned a set of "keys" represented by b-bit integers. The new node receives in the configuration data the address of one or more "entry points" to the DHT. In order to find its upper peers the node randomly draws few keys, searchs for the corresponding nodes and asks them to send data. As in the previous approach, if a node has no more upload bandwidth available, it refuses the request and the new node will try another peer. C.1.2. Conferencing Most of the steps used in the live example in Appendix C.1.1 are also used in a confering context and will not be repeated here. We just would like to point out the differences Bernardini, et al. Expires July 12, 2012 [Page 110] Internet-Draft PPETP January 2012 o It is reasonable to expect that conference management will be done via SIP and not RTSP. o In a conference there is not a single source, but every node is a source of data. It is reasonable to expect that every node will "inject" its data on the PPETP network via a suitable function similar to the send() function of the BSD socket API. o The application will read from the PPETP socket the packets produced by all the other nodes. The problem of separating the packets according the source it is outside the scope of PPETP and it is left to the application. For example, if data is sent in RTP packets, the packet can be partitioned according to their SSRC field (similarly to what it is done when using RTP over UDP). Authors' Addresses Riccardo Bernardini University of Udine Via delle Scienze 208 Udine 33100 Italy Phone: +39-0432-55-8271 EMail: riccardo.bernardini@uniud.it Roberto Cesco Fabbro University of Udine Via delle Scienze 208 Udine 33100 Italy Phone: +39-0432-55-8271 EMail: roberto.cesco@uniud.it Roberto Rinaldo University of Udine Via delle Scienze 208 Udine 33100 Italy Phone: +39-0432-55-8288 EMail: roberto.rinaldo@uniud.it Bernardini, et al. Expires July 12, 2012 [Page 111]