Internet Engineering Task Force R. Bernardini Internet-Draft R. Cesco Fabbro Expires: January 10, 2012 R. Rinaldo UniUD July 9, 2011 Peer-to-Peer Epi-Transport Protocol draft-bernardini-ppetp-02 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 January 10, 2012. Copyright Notice Copyright (c) 2011 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 January 10, 2012 [Page 1] Internet-Draft PPETP July 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 2. Overview of PPETP . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Applicative context . . . . . . . . . . . . . . . . . . . 5 2.2. Network type . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Underneath transport protocol . . . . . . . . . . . . . . 6 2.4. Plugin structure . . . . . . . . . . . . . . . . . . . . . 6 2.5. Priority class . . . . . . . . . . . . . . . . . . . . . . 7 2.6. Reducing the upload data rate . . . . . . . . . . . . . . 7 2.6.1. Reduction procedure . . . . . . . . . . . . . . . . . 7 2.6.2. Data puncturing . . . . . . . . . . . . . . . . . . . 10 2.7. Behavior of a PPETP node . . . . . . . . . . . . . . . . . 11 2.7.1. Live streaming . . . . . . . . . . . . . . . . . . . . 11 2.7.2. Conferencing . . . . . . . . . . . . . . . . . . . . . 14 3. Preliminary definitions . . . . . . . . . . . . . . . . . . . 15 3.1. Address of a PPETP session . . . . . . . . . . . . . . . . 15 3.2. Upper peers, lower peers and peer ID . . . . . . . . . . . 15 3.3. Packet source and packet sender . . . . . . . . . . . . . 15 3.4. Source signature and sender signature . . . . . . . . . . 16 3.5. Streams and packets . . . . . . . . . . . . . . . . . . . 16 3.6. PPETP channels . . . . . . . . . . . . . . . . . . . . . . 17 3.7. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 17 4. Generalized addresses . . . . . . . . . . . . . . . . . . . . 18 4.1. Generalized addresses format . . . . . . . . . . . . . . . 19 4.2. IP address class . . . . . . . . . . . . . . . . . . . . . 20 4.3. ICE address class . . . . . . . . . . . . . . . . . . . . 21 5. PPETP packets . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Data packets . . . . . . . . . . . . . . . . . . . . . . . 22 Bernardini, et al. Expires January 10, 2012 [Page 2] Internet-Draft PPETP July 2011 5.2. Control packets . . . . . . . . . . . . . . . . . . . . . 25 5.2.1. Control packet format . . . . . . . . . . . . . . . . 26 5.2.2. Request types . . . . . . . . . . . . . . . . . . . . 29 5.2.3. Routed control packets . . . . . . . . . . . . . . . . 33 6. Packet processing . . . . . . . . . . . . . . . . . . . . . . 36 6.1. Control packet transmission procedure . . . . . . . . . . 36 6.2. Control packet acknowledgement procedure . . . . . . . . . 37 6.3. Processing received packets . . . . . . . . . . . . . . . 37 6.4. Routing and acknowledging routed packet . . . . . . . . . 38 6.5. Congestion control . . . . . . . . . . . . . . . . . . . . 39 7. PPETP Attributes . . . . . . . . . . . . . . . . . . . . . . . 39 8. Peer handshaking procedure . . . . . . . . . . . . . . . . . . 43 8.1. Peer status . . . . . . . . . . . . . . . . . . . . . . . 43 9. Security Considerations . . . . . . . . . . . . . . . . . . . 45 9.1. Possible attacks and countermeasures . . . . . . . . . . . 45 9.1.1. Poisoning attack . . . . . . . . . . . . . . . . . . . 45 9.1.2. Defamatory attack . . . . . . . . . . . . . . . . . . 46 9.2. Security model . . . . . . . . . . . . . . . . . . . . . . 46 9.2.1. Node classes . . . . . . . . . . . . . . . . . . . . . 47 10. PPETP configuration . . . . . . . . . . . . . . . . . . . . . 48 10.1. Bootstrap configuration protocol . . . . . . . . . . . . . 49 10.1.1. Design goals . . . . . . . . . . . . . . . . . . . . . 49 10.1.2. Protocol structure . . . . . . . . . . . . . . . . . . 50 10.1.3. Query packet . . . . . . . . . . . . . . . . . . . . . 50 10.1.4. Response packet . . . . . . . . . . . . . . . . . . . 51 10.1.5. Attributes . . . . . . . . . . . . . . . . . . . . . . 53 10.2. Compact Configuration Format . . . . . . . . . . . . . . . 58 10.3. Configuration defaults . . . . . . . . . . . . . . . . . . 64 11. ICE-based Connection Establishment Procedure . . . . . . . . . 65 11.1. Format of the private field in the generalized address . . 67 11.2. JSON format for ICE candidates . . . . . . . . . . . . . . 68 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 12.1. Address classes registry . . . . . . . . . . . . . . . . . 69 12.2. PPETP Cryptographic Objects registry . . . . . . . . . . . 70 12.3. SDP extensions . . . . . . . . . . . . . . . . . . . . . . 71 12.3.1. Transport protocols ("proto") . . . . . . . . . . . . 71 12.3.2. Attributes . . . . . . . . . . . . . . . . . . . . . . 72 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 13.1. Normative References . . . . . . . . . . . . . . . . . . . 73 13.2. Informative References . . . . . . . . . . . . . . . . . . 74 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . . . Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 75 A.1. Live media . . . . . . . . . . . . . . . . . . . . . . . . 75 A.2. Remote lecturing . . . . . . . . . . . . . . . . . . . . . 81 Appendix B. Builtin profiles . . . . . . . . . . . . . . . . . . 83 B.1. Sender signature profiles . . . . . . . . . . . . . . . . 83 B.1.1. How to define a sender signature profile . . . . . . . 83 B.1.2. Shared key signature profile . . . . . . . . . . . . . 83 Bernardini, et al. Expires January 10, 2012 [Page 3] Internet-Draft PPETP July 2011 B.1.3. Void signature profile . . . . . . . . . . . . . . . . 85 B.2. Source signature profiles . . . . . . . . . . . . . . . . 85 B.2.1. How to define a source signature profile . . . . . . . 85 B.2.2. Rabin signature profile . . . . . . . . . . . . . . . 86 B.3. Reduction profiles . . . . . . . . . . . . . . . . . . . . 87 B.3.1. How to define a reduction profile . . . . . . . . . . 87 B.3.2. Vandermonde reduction profile . . . . . . . . . . . . 87 B.3.3. Basic reduction profile . . . . . . . . . . . . . . . 90 Bernardini, et al. Expires January 10, 2012 [Page 4] Internet-Draft PPETP July 2011 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. The network coding procedures used to allow for the exploitation of even smal amounts of upload bandwidths have the interesting side effect to make the system robust with respect to packet losses (due to congestion or churn) and some threats such as tentatives of"poisoning" the data distribution system. 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 Section 2.7.1 for an example). The overlay transport layer provided by PPETP is designed to appear, from the standpoint of an application writer, like a multicast-like transport protocol with an API similar to the well-known BSD socket API. For example, a PPETP session is uniquely identified by a "PPETP pseudo-address" (made of a host and pseudo-port pair) that can be inserted, for example, in SDP descriptions. This multicast-like nature makes easier to reuse already available protocols such as RTSP, SIP and SDP. Another major difference with common peer-to-peer protocols is the fact that PPETP is _chunkless_, that is, it does not partition the content in chunks, but it operates at the packet level, handling each packet as an opaque sequence of bytes. This makes PPETP data format "transparent" in the sense that any "sequence of packets", independently of their format, can be transmitted with PPETP. This implies that any type of data (e.g., audio, video, slides) encoded with any type of encoder (lossy, lossless, scalable or multiple description) can be distributed over PPETP. Even encrypted data can be transmitted. PPETP integrates itself nicely with the connection establishment procedures of ICE [RFC5245]. Bernardini, et al. Expires January 10, 2012 [Page 5] Internet-Draft PPETP July 2011 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 The goal of this section is to give an informal (non-normative) description of the main characteristics of PPETP, in order to make the formal description given in the following sections more intuitive. 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 not trivial to exploit the user upload capabilities even. 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 over unreliable protocols, 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. Bernardini, et al. Expires January 10, 2012 [Page 6] Internet-Draft PPETP July 2011 We would like to repeat here 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, must open a "connection" by following an handshaking procedure. Moreover, the connection is expected to be explicitely closed 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. 2.3. Underneath transport protocol The prefix Epi- in "Epi-Transport" reminds us 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 "tools": besides the idea of reduction procedure described above, it employs two different signature algorithms (for the sender and source signature, see Section 3.4), key-exchange techniques and NAT traversal procedures. In order to make easier to keep PPETP up-to-date with future developments, this document does not specify directly how the procedures above must be done, but delegates their description to side documents. This document, however, for the sake of completeness, defines a minimal set of procedures. As with the reduction procedure, this "plugin structure" is obtained Bernardini, et al. Expires January 10, 2012 [Page 7] Internet-Draft PPETP July 2011 by treating as opaque strings of octets those parts of packets that need to be processed by the plugins above. The idea is that the PPETP software would extract the part reserved to the plugin, give it to the plugin and let the plugin interpret it. 2.5. 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 video can be decoded if the base layer data are not received, it can be interesting 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 o It MAY be used by the reduction procedure (see Section 2.6) to adapt the reduction to the packet class. o Different puncturing probabilities (see Figure 12) 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. 2.6. 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. (Of course, since by hypothesis a single node cannot upload the whole content, each node must receive data from more than one peer in order to recover the content). 2.6.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 1. Bernardini, et al. Expires January 10, 2012 [Page 8] Internet-Draft PPETP July 2011 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 the reconstruction of the original packet from the knowledge of a suitable number of reduced versions. The description above is quite vague. This is because that 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 reduction procedures 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. 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 Appendix B.3.2) 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.6.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 Appendix B.3.2. 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 Bernardini, et al. Expires January 10, 2012 [Page 9] Internet-Draft PPETP July 2011 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 scalar packets 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.6.1.2. Consequences of reduction scheme Employing reduction functions has several interesting consequences 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.6.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.6.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 to 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. Bernardini, et al. Expires January 10, 2012 [Page 10] Internet-Draft PPETP July 2011 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.6.1.3. Reduction profiles The reduction procedure described above is not the only possible approach for data reduction. For example, other coding 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 computational 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. In order to allow for profile-based definition of the reduction procedures, PPETP generalizes the Vandermonde procedure outlined above to an abstract "reduction procedure" with the following key characteristics 2.6.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. In order to cope with this case, PPETP allows to require a node to apply a puncturing to a data stream. PPETP introduces two types of puncturing Bernardini, et al. Expires January 10, 2012 [Page 11] Internet-Draft PPETP July 2011 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 pair (peer, channel). Moreover, a different puncturing probability can be specified for every priority class. 2.7. 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 few possible typical uses of PPETP. Since many finer details of PPETP will be explained in the following sections, the examples given here will leave out many details. A much more detailed version of these examples can be found in Appendix A. 2.7.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 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 Bernardini, et al. Expires January 10, 2012 [Page 12] Internet-Draft PPETP July 2011 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. (Actually, PPETP does not specify an algorithm to find the upper peer, but leaves this decision at the application level and limit itself only to provides a set of tools that can be used to implement several different solutions.) 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 (via suitable control packets) to begin the data streaming toward Alice. If an upper peer is behind a NAT, the control packet 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 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 Section 2.7.1.1. The server signs the control packets, so that the nodes will know that the packets are legitimate. The nodes receive the signing key of the server with the configuration data. Since the configuration is transmitted over a secure connection, the Bernardini, et al. Expires January 10, 2012 [Page 13] Internet-Draft PPETP July 2011 nodes know that the received key is the correct one. 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 control packet 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 control packets 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. 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. Bernardini, et al. Expires January 10, 2012 [Page 14] Internet-Draft PPETP July 2011 2.7.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, possibly with the command (pre-signed) to be sent to each new peer. o The server just takes a "handful" of upper peers and send 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. 2.7.2. Conferencing Most of the steps used in the live example in Section 2.7.1 are also used in a confering context and will not be repeated here. We just would like to point out the differences 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 Bernardini, et al. Expires January 10, 2012 [Page 15] Internet-Draft PPETP July 2011 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). 3. Preliminary definitions 3.1. Address 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 before a node can join it 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.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 representing a tree structured network 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 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 Bernardini, et al. Expires January 10, 2012 [Page 16] Internet-Draft PPETP July 2011 packet is the peer "connected to the camera". 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. 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.2.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.2.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 12-bit integer value. Bernardini, et al. Expires January 10, 2012 [Page 17] Internet-Draft PPETP July 2011 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 20-bit integer, if the content packets are RTP packets, the 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 12-bit stream ID and the 20- bit sequence number. 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. It is expected that a common format for a content packet be RTP, but this is not mandatory at all. 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. Bernardini, et al. Expires January 10, 2012 [Page 18] Internet-Draft PPETP July 2011 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.2.3). Compare with packet sender. Peer ID The 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. Stream A sequence of content packets originated from a single node. Stream ID The 12-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. 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. For example, in the case of the ICE-based procedure described in Section 11, a node to start the CEP needs to know the address of a bridge node and the peer ID 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. Generalized addresses are partitioned into _address classes_. Addresses belongin to the same class require the same set of informations. Currently defined address classes are Bernardini, et al. Expires January 10, 2012 [Page 19] Internet-Draft PPETP July 2011 ip The node can be reached directly. The informations required are the IP address and the port of the remote node. ice The ICE-based CEP of Section 11 must be used. The informations required are the address of a bridge node and the ID of the other peer. 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.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 Figure 1) is used. o The five most significative bits of the first octect denote the class of the generalized address, the meaning of the three least significant bits depends on the address class. This document define address classes _ip_ (class=0) and _ice_ (class=1). Classes 2 to 30 are undefined, class 31 is reserved for future extensions. o The last two octets are to be interpreted as an unsigned 16 bit integer in network order whose value is the length of the address, that is, the number of octets used by the whole structure, including the first octet and the two last ones (therefore, this value is never smaller than 3). The reason for including the length of the structure at the end is that this allows to read a generalized address starting from the end (this is necessary when processing routed control packets, see Section 6.4). o The intermediate octets are called the "core" of the address. The size and the format of this field depend on the address class. Bernardini, et al. Expires January 10, 2012 [Page 20] Internet-Draft PPETP July 2011 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Class | X | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Address Core : : (variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (16 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Generalized address binary format 4.2. IP address class The format for the IP address class is shown in Figure 2. The fields have the following meaning Address Class (bits 0-4) This field is set to 0, the class number for the IP format. Version (bits 5-6) IP version. The following values are defined * Version=0 corresponds to IPv4 * Version=1 corresponds to IPv6 * Other values are reserved for future use Unused (bit 7) This bit is unused and it MUST be set to zero. 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 Version field. This document defines only the following cases restricted to protocol UDP Version=4 (IPv4) The Address field is 32 bits long and contains the IPv4 address Bernardini, et al. Expires January 10, 2012 [Page 21] Internet-Draft PPETP July 2011 Version=6 (IPv6) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | V |0| Protocol | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Address : : (size depends on Version and Protocol) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Core of a generalized address of IP class 4.3. ICE address class The format for the ICE address class is shown in Figure 3. The fields have the following meaning Address Class (bits 0-4) This field is set to 1, the class number for the ICE format. Version (bits 5-6) IP version of the bridge address. The following values are defined * Version=0 corresponds to IPv4 * Version=1 corresponds to IPv6 * Other values are reserved for future use Unused (bit 7) This bit is unused and it MUST be set to zero. EXCH Protocol (bits 8-15) The procedure used by the nodes to exchange ICE candidates. Currently only two protocols are defined 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. Bernardini, et al. Expires January 10, 2012 [Page 22] Internet-Draft PPETP July 2011 Peer ID The 32 bit Peer ID of the remote peer Address This field contains the IP address of the bridge node. Its size depends on the value of the Version field (32 bits for IPv4 and 128 bits for IPv6). Other data This field can be used to store data that can be used by the candidate exchange protocol. The format of this field for protocols 0 and 1 is described in Section 11.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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : | 1 | V |0| EXCH Protocol | : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Bridge Address : : (size depends on Version) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Private data (size and format depend on EXCH Protocol) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Core of a generalized address of ICE class 5. PPETP packets The packets exchanged by PPETP nodes can be classified as data packet or control packet. 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 (see Section 5.2.3). 5.1. Data packets Figure 4 shows a graphical representation of a data packet. The fields have the following meaning Bernardini, et al. Expires January 10, 2012 [Page 23] Internet-Draft PPETP July 2011 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 _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 number of milliseconds since 1/1/1970 modulo 2^16. This field is used to estimate the traveling time, necessary to the TFRC (see Section 6.5). 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. Class (bits 32-39) 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 constraint imposed is that the packet priority must be a non-increasing function of the Bernardini, et al. Expires January 10, 2012 [Page 24] Internet-Draft PPETP July 2011 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 40-43) The channel number. 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. Reserved (bits 46-47) Unused bits. This field SHOULD be set to zero by the sender and MUST be ignored by the receiver. Stream ID (bits 48-55) The stream ID of the original content packet. Stream ID=255 is reserved. 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 1. 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. Sequence number (bits 56-79) 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 January 10, 2012 [Page 25] Internet-Draft PPETP July 2011 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 Appendix B.1.1). +--------+--------+------------------+-----------+ | 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 1: Constants used in the interpretation of the RTT field 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Class |Channel|ERT|Res| Stream ID | RTT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : 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. In the current version of PPETP control packets are used in peer handshaking (Set_Parameter packet), connection keep- alive (Hello packet) and data flow control (commands to start/stop/ Bernardini, et al. Expires January 10, 2012 [Page 26] Internet-Draft PPETP July 2011 redirect a data flow, and to start a connection establishment procedure). Control packets are expected to be sent from a peer to a neighboor of its, but data flow control packets can also be sent by a "network manager" host to peers. Control packet are expected to be typically sent from the source host to the target host, but, in order to cope with some problems posed by 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.2.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. Request (bits 4-7): The actual request. Request values from 0 to 3 are defined in this document; request value 12 is reserved to the reduction profile; request value 13 is reserved to the sender signature profile; request value 14 is reserved to the source signature profile. Other request values are unassigned and reserved for future use. Timestamp (bits 8-23) The number of milliseconds since 1/1/1970 modulo 2^16. This field is used to estimate the traveling time, necessary to the TFRC (see Section 6.5). 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. Bernardini, et al. Expires January 10, 2012 [Page 27] Internet-Draft PPETP July 2011 Routed packet (R, bit 32) This bit is set if the packet is routed, see Section 5.2.3 for details. Sub-sequence number (SSN, bits 33-39): According to Section 6.1, if a packet has not been acknoweldged within a timeout, a node can try to retransmit the same command. In order to allow the recipient to recognize that a packet is a copy of a previous packet, each control packet carries a Sequence Number. In some contexts (i.e., computation of retransmission timer Section 6.1 and packet routing in Section 5.2.3) it is useful to be able to distinguish between different retransmitted versions of the same control packet. In order to allow to say when a packet is a different retransmission, the SSN is set to zero when the packet is sent for the first time and it is increased each time the packet is retransmitted. Sequence Number (bits 40-71): 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 triple (sender, recipient, sequence number) identify uniquely the control packet (but see Section 6.1 for details about packet retransmission). In particular, each node can keep a single number space shared by all the control packets transmitted by the node or different number spaces for packets sent to different peers. Payload (variable size): Its meaning and format depends on the specific request. 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 Appendix B.1.1). Bernardini, et al. Expires January 10, 2012 [Page 28] Internet-Draft PPETP July 2011 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| SSN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Payload (variable size) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Routing data : : (variable size, only if bit R is set) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bernardini, et al. Expires January 10, 2012 [Page 29] Internet-Draft PPETP July 2011 Figure 7: Payload for the Acknowledge request 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ACK Target : : variable size, generalized address of class IP : : in reversed format : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target PEER ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source PEER ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : : Source signature (variable size) : : : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Routing data 5.2.2. Request types The followings values for the Request field are defined Set_Parameter (Request=0) 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 3). 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. A Set_Parameter with empty payload can be used to keep open a NAT hole or to check if a peer is still alive. Currently accepted attributes are * REDUCTION_PARAMETER Acknowledge (Request=1) 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 2 for an overview of the possible values. The zero value has always the meaning of "positive acknowledge" (i.e., no error occurred). Bernardini, et al. Expires January 10, 2012 [Page 30] Internet-Draft PPETP July 2011 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 increases the flexibility of the protocol. Start (Request=2) 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), the Peer ID of the new peer (4 octets), its generalized address (see Section 4) 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. [remark-routing-prob] 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. Bernardini, et al. Expires January 10, 2012 [Page 31] Internet-Draft PPETP July 2011 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). Stop (Request=3) Stop sending data to the target specified in the packet. The payload is obtained by concatenting the channel mask (2 octects) 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 (Request=4) 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 Peer ID of the new peer (4 octets) + The generalized address of the new peer (variable size) + The mask of channels to be stopped (2 octet) + 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. Bernardini, et al. Expires January 10, 2012 [Page 32] Internet-Draft PPETP July 2011 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. Result=3 (NO_Target) The old peer is not a lower peer of the node. No action is taken. Closing (Request=5) 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 in the due time, 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 (Request=6) This request is used during the introduction phase. The payload is a cryptographic certificate carrying informations necessary for creating and/or verifying the sender signature. This request is the only request that does not require a sender signature. The request is to be considered valid if the payload is a valid certificate. Open_Connection (Request=7) 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 (Request=8) 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. The payload for this request, shown in Figure 9, includes the following values 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. Bernardini, et al. Expires January 10, 2012 [Page 33] Internet-Draft PPETP July 2011 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. Feedback packets are not acknowledged. 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 9: Payload of the feedback request +----------+-------+------------------------------------------------+ | 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 2: Values for the Result field of the Acknowledge packet 5.2.3. Routed control packets Consider the following scenario: a P2P application where the P2P network is managed by a central server. Suppose that Alice is behind a NAT, that she she already joined the network and that Bob wants to 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 the server must send to Alice an Open request. Although it is Bernardini, et al. Expires January 10, 2012 [Page 34] Internet-Draft PPETP July 2011 reasonable to assume that when Alice joined the network she contacted the server and this caused the opening of a hole in the NAT, unless the server and Alice kept the NAT hole open, there is a chance that the hole is now closed and Alice is unreachable from the server too. The port could be kept open by sending Hello packets, but this solution could pose scalability problems. In order to to solve this and similar problems, PPETP allows to route the control packets over the P2P structure. In order to route a control packet, the source node sets the bit R in the control packet header and append to the control packet the data structure shown in Figure 8. The meaning of the fields is as follow 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, but in reversed form, that is, the octects are stored backward (e.g., the last octet is the class octet). This is done since it allows to process the field starting from the end. Target ID Is the peer ID of the final recipient of the routed packet Source ID Is the peer ID of the source peer Source Signature This is the source signature of the source peer. It covers the whole packet: header, payload and routing data. 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, forward 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.2.3.1. 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 Appendix B.2.2), but other can be defined in the future. Bernardini, et al. Expires January 10, 2012 [Page 35] Internet-Draft PPETP July 2011 5.2.3.2. Remarks Few remarks about the rationale of the proposed structure are in order Direct acknowledgement. Note that the Acknowledge is sent back directly to the source peer, without routing through the P2P network. This requires 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 * 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. * 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. * 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 January 10, 2012 [Page 36] Internet-Draft PPETP July 2011 SubSeq_Num field The SubSeq_Num field has been introduced in order to avoid a possible "flooding attack" where a node replicates repetitively a legitimate routed control packet. Since the control packet is legitimate, the source signature is valid and the packet cannot be discarded by the signature checking procedure. Since it is legitimate to send more than one time the same control packet (if no Acknowledge is received), we cannot ask the intermediate nodes to discard routed control packets with the same sequence number. The solution is to "extend" the sequence number with the SubSeq_Num field. Note that a node cannot artificially increase the SubSeq_Num since this field is used to compute the source signature. 6. Packet processing 6.1. Control packet transmission procedure All the control packets (with the exception of the Acknowledge packet) 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. 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. 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 and with the SSN field incremented by 1, 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]. The SSN field can be used to avoid the ambiguities of round-trip times associated to retransmitted packets. Bernardini, et al. Expires January 10, 2012 [Page 37] Internet-Draft PPETP July 2011 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 A data packet (Control=0): + The 64-bit header is parsed and stripped (so that only the payload remains) + Any payload padding is removed + The payload is given to the reduction-profile specific processing procedures. Bernardini, et al. Expires January 10, 2012 [Page 38] Internet-Draft PPETP July 2011 A control packet (Control=1, R=0): The padding (if present) is removed from the payload and the packet is processed by an appropriate request handling procedure. A routed packet (Control=1, R=1): 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 this packet was already processed, discard it. 3. Check the Peer ID of the target and * If the node ID is equal to the target 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 node ID is not equal to the target ID, the node, for every lower peer + 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. The procedure above is actually a "flooding" of the PPETP network and 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. Bernardini, et al. Expires January 10, 2012 [Page 39] Internet-Draft PPETP July 2011 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). 6.5. Congestion control According to RFC [RFC5405], protocols that use UDP as a transport protocol should do congestion control. In PPETP congestion control is done according using the TCP-Friendly Rate Control (TRFC) described in [RFC5348]. The values required by TFRC can be obtained from the fields of the Data packet and the Feedback packet. 7. PPETP Attributes In PPETP some control requests encode their parameters as attributes in the TLV format as follows (see also Figure 10) o The first octet encodes the type of the attribute. o The successive two octets encode the length of the value of the attribute. o The successive Length octets encode the attribute value. The format depends on the specific attribute. Bernardini, et al. Expires January 10, 2012 [Page 40] Internet-Draft PPETP July 2011 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 10: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer ID : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| Cred. Type | Cred. Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Credential Value : : (variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cert. Type(opt)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Certificate : : (optional, variable size) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Format of a credential certificate Currently defined PPETP attributes are PEER_CREDENTIAL (Type=0) This parameter is used to transmit the information that the upper peer needs in order to sign the packets for the new lower peer. The value of this attribute is a credential certificate whose format is shown in Figure 11. The meaning of the fields are as follows Peer ID (bits 0-31) The ID of the peer associated with the credential. Padding (bit 32) If this bit is 1, the credential value has been padded to make its lenght a multiple of 4. The number of padding octets is stored in the last octet of the credential value. This is necessary since the credential size is expressed as a multiple of 4. Bernardini, et al. Expires January 10, 2012 [Page 41] Internet-Draft PPETP July 2011 Credential Type (bits 33-39) This 7-bit field describes which type of "cryptographic object" is contained in the certificate. Currently defined types are Diffie-Hellman half keys to be used in the sender signature algorithm described in Appendix B.1.2 (Credential Type=0) and the public key for the Rabin-based source signature algorithm described in Appendix B.2.2 (Credential Type=1). Value 127 is reserved for future extensions, other values are undefined. New cryptographic objects can be registered at IANA, see Section 12 for details. Credential size (bits 40-47) This field is the length of the (possibly padded) Credential Value field, expressed as number of 32 bit words. Credential Value (variable size) The actual value of the credential, its interpretation depends on the value of Credential Type. Certificate Type (optional, 1 octet) The credential field can be followed by a certificate that links a public key to a user. The first octet specifies the certificate format. Currently only certificate type 0, associated to X.509 certificate encoded with DER, is defined. Value 255 is reserved for future extensions. Other values can be registered at IANA, see Section 12 for details. If the certificate field is present, the packet Hello that contains the PEER_CREDENTIAL attribute MUST be signed with the private key corresponding to the ceritificated public key. Certificate (variable size) This optional field (that MUST be present if and only if the field Certificate Type is present), is a certificate for the user public key. Its format depends on the value of Certificate Type field. PUNCTURING (Type=1) 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 format of the value is shown in Figure 12. The first octet determines the puncturing mode; the second octet is the packet class to which the puncturing applies. As said in Section 5.2.2, two possible modes are defined Probabilistic puncturing (mode=0) The following two octets are two unsigned 8-bit integers 0 <= Num <= 254, and 0 <= Den <= 255 (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+1)/(Den+1). If the result is true, the packet is sent; otherwise it is discarded. Bernardini, et al. Expires January 10, 2012 [Page 42] Internet-Draft PPETP July 2011 If Num >= Den, all the packets are sent. Deterministic puncturing (mode=1) The second octets is an 8-bit integer M, the other octets are interpreted as 8-bit integers Val_1, Val_2, ..., Val_N. With this mode a packet with sequence number S is sent if and only if S = Val_i (mod M+1) for some i. 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 3. 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. 4. The PUNTCTURING attributes are processed in the order they are specified in the packet. 5. All the entries of the puncturing table are initialized with "no puncturing" (i.e., all packets are transmitted). 6. 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. ROUTING_PROBABILITY (Type=2) The payload is a pair of octets 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 (Type=4) This attribute is used to set the reduction parameter associated to a channel.The first octect of the payload is the channel number, the remaining octets are to be interpreted as an opaque value to be given as-it-is to the functions of the reduction profile. Bernardini, et al. Expires January 10, 2012 [Page 43] Internet-Draft PPETP July 2011 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) |0 0 0 0 0 0 0 0| Class | Num | Den | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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) |0 0 0 0 0 0 0 1| Class | Mod | Val 1 ...Val N +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.... (a) Format for probabilistic puncturing (b) Format for deterministic puncturing Figure 12: 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. 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 Bernardini, et al. Expires January 10, 2012 [Page 44] Internet-Draft PPETP July 2011 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. 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 transiction 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 Bernardini, et al. Expires January 10, 2012 [Page 45] Internet-Draft PPETP July 2011 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 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.6, 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 Bernardini, et al. Expires January 10, 2012 [Page 46] Internet-Draft PPETP July 2011 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). 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. Bernardini, et al. Expires January 10, 2012 [Page 47] Internet-Draft PPETP July 2011 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 * 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 Bernardini, et al. Expires January 10, 2012 [Page 48] Internet-Draft PPETP July 2011 * 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 Some remarks are in order o 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) Bernardini, et al. Expires January 10, 2012 [Page 49] Internet-Draft PPETP July 2011 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 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 Bernardini, et al. Expires January 10, 2012 [Page 50] Internet-Draft PPETP July 2011 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. 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 10.1.5.2 o The successive length octets are the value of the attribute. 10.1.3. Query packet Figure 13 show 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 Bernardini, et al. Expires January 10, 2012 [Page 51] Internet-Draft PPETP July 2011 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.) 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: 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 12.3). 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 13 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. Bernardini, et al. Expires January 10, 2012 [Page 52] Internet-Draft PPETP July 2011 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 14: Header of a response packet 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. Bernardini, et al. Expires January 10, 2012 [Page 53] Internet-Draft PPETP July 2011 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 3. ACCEPTED-PROTOCOLS The value of this attribute is a list of 15-bit integers encoded as described in Section 10.1.5.2. Each integer identifies a configuration protocol implemented by the client. PROTOCOL The protocol that the client must use to get configuration data. It is a 15-bit integer encoded as described in Section 10.1.5.2. PARAMETER 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. ACCEPTED-CONTENT The value of this attribute is a list of 15-bit integers encoded as described in Section 10.1.5.2. Each integer identifies a configuration descriprion format understood by the client. CONTENT-TYPE This attribute is used when the configuration data is included in the reply. Its value is a 15-bit integer encoded as described in Section 10.1.5.2. This field MUST be present if and only if the error code is 200. CONTENT The value of this attribute is the configuration description. The format of this attribute depends on the value of CONTENT-TYPE. 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]. Bernardini, et al. Expires January 10, 2012 [Page 54] Internet-Draft PPETP July 2011 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] ACCEPTED-ALGORITHMS The value of this attribute is a list of 15-bit integers encoded as described in Section 10.1.5.2. Each integer identifies a signature computing algorithm that the node (client or server) can use. ALGORITHM This attribute is a a 15-bit integer encoded as described in Section 10.1.5.2 and specifies the algorithm used to compute the value in the field SIGNATURE. USE-ALGORITHM This attribute is a a 15-bit integer encoded as described in Section 10.1.5.2 and specifies the algorithm to use in the computation of the value in the field SIGNATURE. If this field is missing, algorithm HMAC described here is used. ACCEPTED-HASHES Many authentication algorithms make use of hash functions. The value of this attribute is a list of 15-bit integers encoded as described in Section 10.1.5.2. Each integer identifies a hash function that the node (client or server) can use. HASH This attribute is a a 15-bit integer encoded as described in Section 10.1.5.2 and specifies the hash function used. Bernardini, et al. Expires January 10, 2012 [Page 55] Internet-Draft PPETP July 2011 USE-HASH This attribute is a a 15-bit integer encoded as described in Section 10.1.5.2 and specifies the hash function to be used in the computation of the value in the field SIGNATURE. If this field is missing, algorithm MD5 is used. 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 January 10, 2012 [Page 56] Internet-Draft PPETP July 2011 +---------------------+-------+ | Name | Value | +---------------------+-------+ | ACCEPTED_PROTOCOLS | 0 | | PROTOCOL | 1 | | PARAMETER | 2 | | ACCEPTED_CONTENTS | 3 | | CONTENT_TYPE | 4 | | CONTENT | 5 | | USERNAME | 6 | | REALM | 7 | | USE_NONCE | 8 | | LOCAL_NONCE | 9 | | REMOTE_NONCE | 10 | | ACCEPTED_ALGORITHMS | 11 | | ALGORITHM | 12 | | USE_ALGORITHM | 13 | | ACCEPTED_HASHES | 14 | | HASH | 15 | | USE_HASH | 16 | | SIGNATURE | 17 | | REASON | 18 | | UNKNOWN_ATTRIBUTES | 19 | | SOCK_ADDR | 20 | +---------------------+-------+ Table 3: Values associated to attribute types 10.1.5.1. 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. 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 Bernardini, et al. Expires January 10, 2012 [Page 57] Internet-Draft PPETP July 2011 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. If necessary, attributes ALGORITHM and HASH are 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.5.1.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 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. Bernardini, et al. Expires January 10, 2012 [Page 58] Internet-Draft PPETP July 2011 10.1.5.2. 15-bit integers encoding Several attributes encode algorithms, formats and protocols as integer numbers that can use at most 15 bits. Since it is reasonable to expect that the number of protocol, algorithms or formats defined in the future will be much smaller than 100, it was decided to use a format that allows to store efficiently values up to 127, while allowing values up to 32767. The value is stored in one or two consecutive octets as follows. 1. Let b1 and b2 the two octets and let 0 <= N < 32768 the value to be encoded. 2. If N < 128, N is stored in b1 and b2 is unused 3. If N >= 128, value 128 + (N mod 128) is stored in b1 and value N/128 is stored in b2. In other words, the most significant bit of b1 is used as a flag: if it is zero, it means that N was smaller than 128 and only b1 is used; otherwise N was larger or equal than 128 and both b1 and b2 are used. For example, the sequence of integers 112, 42, 260, 33 would be encoded in the sequence of octets 112 42 132 2 33 Note that 132 = 128 + (260 mod 128) and 2 = 260/128. 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; the 3-character label between square brackets [...] has the following meaning: "*" marks the lines that are mandatory, "+" marks the lines that can appear more than once, "a" marks the lines that can be followed by any number of attribute lines Bernardini, et al. Expires January 10, 2012 [Page 59] Internet-Draft PPETP July 2011 o "s"[* ]: stream line o "p"[* a]: profile line o "Y"[ ]: informations about the node itself ("Y" is for "Yourself") o "C"[ +a]: informations about the channels opened by the node ("Y" is for "Yourself") o "c"[ +a]: connection line(s) o "a"[ + ]: attribute line(s) o "f"[ a]: peer search method ("f" is for "find") o "n"[ +a]: peer line(s) ("n" is for "node") o "k"[ +a]: security related data (e.g., public keys) o "P"[ +a]: security policies o "X"[ ]: Data puncturing lines o "x"[ ]: Routing puncturing lines ccdf = *1stream-line profile-line *1self-line *channel-line *connection-block (*1find-line / *peer-block) *policy-line stream-line = %x73 *1(stream-id *(SP stream-id)) EOL ; 's' stream-id = integer profile-line = %x70 profile-name *(SP parameter) EOL ; 'p' profile-name = identifier profile-parameter = token self-line = %x59 peer-id n-channels self-stream-ids EOL ; 'Y' peer-id = int32 / "*" n-channels = HEXDIGIT / "*" self-stream-ids = *(SP integer) *1others-id others-id = "*" *1integer Bernardini, et al. Expires January 10, 2012 [Page 60] Internet-Draft PPETP July 2011 channel-line = %x43 *1repeat *(SP parameter) *attribute-line repeat = "*" integer connection-block = %x63 connection-type *1("@" label) *(SP parameter) EOL ; 'c' *attribute-line connection-type = identifier label = identifier find-line = %x66 method *(SP parameter) EOL ; 'f' *attribute-line peer-block = %x7e node-type node-id *channels ; 'n' (connection-body EOL / EOL connection-block) *1data-punct-line *1ctl-punct-line *key-line connection-body = SP connection-type *(SP parameter) / "@" label node-type = %x65 / %x6f / %x75 ; 'l', 'o', 'u' node-id = int32 channels = HEXDIGIT *1("-" HEXDIGIT) data-punct-line = (rand-punct / mod-punct) EOL rand-punct = %x52 num den ; 'R' mod-punct = %x4D modulus 1*byte ; 'M' num = byte den = byte modulus = byte ctl-punct-line = %x78 num den EOL ; 'x' key-line = %x6b method *(SP parameter) EOL ; 'k' *attribute-line policy-line = %x50 capability ":" allowed *(SP allowed) *1(";" parameter *(SP parameter)); 'P' capability = identifier allowed = "all" / "none" / "neigh" / node-id attribute-line = %x61 attr-name "=" attr-value EOL ; 'a' attr-name = identifier attr-value = *%x20-7E Bernardini, et al. Expires January 10, 2012 [Page 61] Internet-Draft PPETP July 2011 parameter = token EOL = LF byte = HEXDIGIT HEXDIGIT int16 = 4*4HEXDIGIT int32 = 8*8HEXDIGIT integer = 1*HEXDIGIT identifier = ALPHA *id-char id-char = ALPHA / DIGIT / "-" / "_" token = 1*VCHAR no-lf-chars = %x00-%x09 / %x0b-%xff ABNF grammar for the CCDF The meaning of the lines is the following 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 or this line is missing, any ID is allowed. Nodes MUST discard any packet whose stream ID does not belong to the set of admissible ones. o Profile line ("p"). The first parameter on this line is the name of the reduction profile to be used, the meaning of any following parameter is defined by the profile. This line can be followed by any number of attribute lines. The admissible attributes and their meaning is defined by the profile. For example, with the vandermonde profile (defined in this document) the first parameter is the reduction factor (equivalent attribute: red-fact) and the second parameter is the number of bytes necessary to represent an element of the Galois field employed (that is, if n is the value of the second parameter, the size of the Galois field is 2^(8*n)). The attribute equivalent to the second parameter is gf-size. The basic profile defines no paramters. 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 second parameter is the number of output channels to be open by the node; if its value is '*' it means that the number of channels is the number of 'C' lines that follows. The following parameters are the stream ID that the node can produce and are to be interpreted as follows * If no further parameter are present, the node cannot produce any stream. * If a list of integers is present, each integer is the stream ID of a stream that the node can produce. Bernardini, et al. Expires January 10, 2012 [Page 62] Internet-Draft PPETP July 2011 * The line can end with a single asterisk or an asterisk followed by an integer. In the former case, the node is allowed to produce as many stream as it needs and the IDs will be chosen by the node itself; in the latter case, if n represents the value of the integer, the node is allow to produce n more stream and the IDs will be chosen by the node itself. For example, the following line Y0123abcd* af2 bc00 d6*2 assigns the peer ID 0x0123abcd to the node, asks to the node to open a number of channels equal to the number of 'C' lines that follows and allows the node to produce five streams: three streams have stream ID af2, bc00 and d6, the ID of the other two streams will be chosen by the node. o Output channels ("C"): This type of line specifies the 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. If the line begins with an asterisk followed by a number, the number represents the number of time that this line and the following attribute listmust be "virtually" repeated. For example, the following description C aredundancy=4/3 C*2 aredundancy=5/3 C aredundancy=1/1 requires the node to open four channels: channel #0 will have the (fictional) parameter "redundancy" set to 4/3, channels #1 and #2 will have the same parameter set to 5/3 and channel #3 will have a redundancy equal to 1/1. o Connection ("c"). This type of lines specifies a generalized address. This line can appear by itself or as part of a peer- block. If the line is stand-alone the "label" field (described in the following) is mandatory. The first parameter on this line identifies the address class. This document defines two classes (ice and ip), but more classes can be defined in the future. If the first character after the address type is a '@', then the identifier that follows is a label assigned to the address. The label can be used to refer again to the same address in the same description. The parameters necessary for the connection can be Bernardini, et al. Expires January 10, 2012 [Page 63] Internet-Draft PPETP July 2011 given both as positional parameters or as attributes. The parameters associated with a given address type are defined by the document describing the address type. 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 first parameter identifies the specific method and parameters for the method can be specified both on the same line or as attribute values. 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 channel numbers separated by comma follows. The range of channel between n and m can be abbreviated as "n-m". 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 + 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 no channel number is present, channel #0 is implied. * The generalized address of the peer can follow. This can be given as a connection-body or as a '@' followed by the label assigned to a previous 'c'-line. Alternatively, this field can be omitted and the generalized address be given as a 'c' line inside the peer block. A 'c' line can follow with the generalized address of the node. The 'c' line and the inline address specification are mutually exclusive. Finally, one or more 'k'-lines with cryptographic informations can follow. Bernardini, et al. Expires January 10, 2012 [Page 64] Internet-Draft PPETP July 2011 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. Each peer is identified by its peer ID. Moreover, the keywords "all" (everyone can do the action), "none" (noone can do the action) and "neigh" (only the "neighboors" of the node, i.e. lower and upper peers, can do the action) can be used. 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. o Security related data ("k" line). 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 Appendix B.1.2 o Routed control packets require source signature. The source signature is done with the rabin procedure described in Appendix B.2.2. 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 Bernardini, et al. Expires January 10, 2012 [Page 65] Internet-Draft PPETP July 2011 11. ICE-based Connection Establishment Procedure This version of PPETP includes an ICE-based connection procedure. As explained in Section 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 send them to the bridge in the body of an HTTP/HTTPS POST request. Although this document does not impose a specific method for encoding the candidate lists, it defines in Section 11.2 a JSON format [RFC4627] that MUST be implemented in every implementation conforming to this specs. Other encoding list formats may be defined in the future. The bridge node, after receiving both candidate lists, will send to each peer 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. 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 according to the JSON format in Section 11.2 or according to some future format. 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 Bernardini, et al. Expires January 10, 2012 [Page 66] Internet-Draft PPETP July 2011 request-uri = prefix "?" parameter *(& parameter) prefix = abs_path parameter = source / dest / session source = "from=" peer-id dest = "to=" peer-id session = "sess=" *sess-char 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. - If the generalized address has not the SESSION attribute, but the PPETP session is identified by a PPETP pseudo-address (see Section 3.1), its value is constructed as the host part of the pseudo address, followed by ":", followed by the PPETP session ID. - Otherwise, the value of "sess" is the empty string. + 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 12345 and that the configuration server is config.example.com. The Request-URI sent with the POST request would be /connect?sess=config.example.com:12345&from=42&to=24 Bernardini, et al. Expires January 10, 2012 [Page 67] Internet-Draft PPETP July 2011 Header Content-type It is set coherently with the encoding used for the candidate lists. Body The body contains the candidate list. 4. 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). 5. If the request is valid, the bridge waits for the request from the other peer. The bridge will check 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. The bridge MAY schedule a timeout for the arrival of a valid request from the remote peer. 6. If the second candidate list arrives before the timeout, the bridge replies to each peer with a 200 code, including in the body the list of the other peer. If the timeout expires before the reception of the second offer, the bridge SHOULD reply with error code 404 (Not Found). 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. Few comments are in order o Note that in a typical case the connection procedure is started by an "originator peer" that wants to contact a "target peer". In order for the procedure to work, it is necessary that the target peer knows that the originator wants to contact it, so that it can collect the candidates and its offer to the bridge. This can be achieved by sending an Open packet to the target peer (for example, the packet could be sent by the bridge via the routing mechanism) or by some extra-PPETP means. o The bridge can distinguish between the request from the originator and the request from the target by using, for example, a different prefix for the target request. 11.1. Format of the private field in the generalized address The format of the private field for exchanges protocol 0 and 1 is as follows Bernardini, et al. Expires January 10, 2012 [Page 68] Internet-Draft PPETP July 2011 o The first two octets are the port to be used to contact the bridge node, expressed as an unsigned 16-bit integer in network order. o The second value is the prefix value. The first octet is the length L of the prefix, followed by L octets that represent the prefix value. If L=0, the default value "/connect" is used. o The third value is the value of the "sess" attribute. The format used for this value is the same used for the prefix: the first octet gives the length L of the value and it is followed by L octets that represent the actual value. If L=0, the default value is used. 11.2. JSON format for ICE candidates 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":{ "type" : "string", "required" : "true", "minLength":22, "maxLength":256 }, "options":{ "type":"array", "items":{ "type":"string" } }, "candidates":{ "type":"array", "items": { "type":"object", "properties":{ "foundation": { Bernardini, et al. Expires January 10, 2012 [Page 69] Internet-Draft PPETP July 2011 "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" } } } } } 12. IANA Considerations 12.1. 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 January 10, 2012 [Page 70] Internet-Draft PPETP July 2011 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. 12.2. PPETP Cryptographic Objects registry This document defines a 16-bit "Credential Type" field (see Figure 11), for which IANA is to create and maintain a new registry named "PPETP Cryptographic Object" (PPETP-CRYPTO). Initial assignments are given below. [define-crypto] Assignment of unassigned values require an RFC. The RFC MUST specify o The use of the cryptographic object o A binary format for the object (to be used in the "Credential Value" field of xref target="credential-value-fig"/>). o A text name for the cryptographic object (to be used in text-based formats) o Its syntax when described in text format Bernardini, et al. Expires January 10, 2012 [Page 71] Internet-Draft PPETP July 2011 Value PPETP-CRYPTO Name Definition ----------- ----------------- ------------------ 0 dh-half-key See Appendix B.1.2 1 rabin-public See Appendix B.2.2 2-255 Unassigned 256-511 Experimental 512-65533 Unassigned 65534-65535 Reserved 12.3. SDP extensions 12.3.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-DCCP/RTP/AVP | See this document | | | PPETP | See this document | | | PPETP-UDP | See this document | | | PPETP-DCCP | 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-DCCP/RTP/AVP Like PPETP/RTP/AVP, but the transport protocol used by PPETP is DCCP instead of UDP. PPETP Like UDP in [RFC4566], but with the data transported over PPETP, with UDP as transport protocol used by PPETP. PPETP-UDP Equivalent to PPETP PPETP-DCCP Like PPETP, but the transport protocol used by PPETP is DCCP instead of UDP. The new protocols inherit the "fmt" namespace of the corresponding protocols defined in [RFC4566]. Bernardini, et al. Expires January 10, 2012 [Page 72] Internet-Draft PPETP July 2011 12.3.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. 12.3.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-port By default the port where configuration query are sent is TBD1 (see Section 10.1). This attribute is used to change this default and communicate to the node an alternative port number. 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 4; the required contact informations are the equal to the contact informations of this document. +-------+-----------------+--------------------+---------+----------+ | Name | Long name | Type | Charset | Value | | | | | | spec | +-------+-----------------+--------------------+---------+----------+ | ppetp | PPETP option | session and media | No | ****** | | | setting | level | | | +-------+-----------------+--------------------+---------+----------+ Table 4: IANA informations for new SDP attributes 13. References Bernardini, et al. Expires January 10, 2012 [Page 73] Internet-Draft PPETP July 2011 13.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. [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. [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. [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. Bernardini, et al. Expires January 10, 2012 [Page 74] Internet-Draft PPETP July 2011 [RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 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. 13.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-xml-config] Bernardini, R., Cesco Fabbro, R., and R. Rinaldo, "XML format for Peer-to-Peer Epi-Transport Protocol configuration description", April 2010. [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", Bernardini, et al. Expires January 10, 2012 [Page 75] Internet-Draft PPETP July 2011 November 2010. Editorial Comments [define-crypto] Define cryptographic objects in signature profiles. [remark-routing-prob] It should be moved elsewhere. This is a per- peer and not per-channel parameter. 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 Bob (B), that has an account with a streaming service provider, wants to receive a live concert streamed over PPETP. We suppose that Alice (A) is already connected to the network. Alice and Bob are (possibly) behind NATs and they implement the ICE-based NAT traversal profile described in [ppetp-ice]. The network topology is managed by a central server (belonging to the streaming service provider) denoted in the following with the letter N (as network manager). The "starting point" of Bob 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 Bernardini, et al. Expires January 10, 2012 [Page 76] Internet-Draft PPETP July 2011 B->W: GET /sessions.html HTTP/1.1 HOST: www.example.com W->B: HTTP/1.1 200 OK Content-Type: text/html Best concert ever When Bob clicks on the link Tthe web browser launchs a "viewer" (an external program or a plugin) that contacts the RTSP server. B->M: DESCRIBE rtsps://live.example.com/concert RTSP/2.0 CSeq: 1 M->B: 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). Because of this Bob's agent opens (via a suitable API) 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() will send 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) Bernardini, et al. Expires January 10, 2012 [Page 77] Internet-Draft PPETP July 2011 and adds a nonce to the attribute list. Bob's agent asks to Bob 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=bob, USE-NONCE=88888, LOCAL-NONCE=11111, SIGNATURE=23xgajdav) C->B (300, 1 | REALM=example, USERNAME=bob, NONCE=88888, LOCAL-NONCE=25252, PROTOCOL=https, PARAMETER=netmanager.example.com/12345?q=da...c23, SIGNATURE=daghj391) In this example Bob sends a new request (note the increased request number) adding to it the signature. Bob also requests the server to authenticate itself by adding the USE-NONCE attribute. The server checks the signature and replies with an error code 300 (Try other) to redirect Bob to a more complex configuration protocol based on HTTP. Bob sends a POST request to the network manager (N) specified in the PARAMETER attribute Bernardini, et al. Expires January 10, 2012 [Page 78] Internet-Draft PPETP July 2011 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-xml-config ... other upper peers ... Note that the configuration manager can communicate with the network manager via the request path. In this case the path is simply the session ID with an opaque query string that (one can suppose) encodes informations about Bob such as the type of subscription of Bob, the upload bandwidth that it can provide and so on. Bernardini, et al. Expires January 10, 2012 [Page 79] Internet-Draft PPETP July 2011 The network manager, as a consequence of the POST request of Bob, assigns to Bob a set of upper peers. 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 Bob 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 Bob in XML format with the syntax defined in [ppetp-xml-config]. The configuration data contains information such as the reduction profile employed, the signature profiles employed and the list of upper peers. (In a setup with a distributed peer search, the configuration data could include, for example, a list of addresses of bootstrap nodes for the peer search.) Note that the server does not specify the "reduction-base" parameter, so the node will choose one at random. Because of this, a large Galois field is employed (2^32 elements), in order to make the probability that two nodes choose the same reduction-base negligible. Note that because the HTTP transaction is done over a secure connection, Bob can trust the data received in the HTTP dialogue, in particular the public Diffie-Hellman keys of the server and of Alice. Moreover, the server is sure about the identity of Bob because Bob authenticates himself when doing the HTTP requests. Suppose that the first upper peer is Alice's node. Since Alice is behind a NAT, Bob does not receive the IP address of Alice, but the address of a "bridge node" used to carry out the ICE-based NAT traversal procedure described in [ppetp-ice]. As a consequence of this (see also Figure 15) 1. Bob gathers his 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=ppetp.example.com:12345 . 2. The network manager sends to Alice a routed control packet Open with the generalized address of Bob. That address will be of class ICE and it will contain the address of the bridge and the peer ID of Bob. Alternatively, the Open request could be sent to Alice by the bridge host, after receiving the request of Bob. 3. Alice gathers (if necessary) her candidate addresses and sends them to the bridge host as body of a POST request with Request- URI /connect?from=13109111&to=54321&sess=ppetp.example.com:12345 . Bernardini, et al. Expires January 10, 2012 [Page 80] Internet-Draft PPETP July 2011 4. The bridge host, by matching the two Requst-URI, finds that Alice request 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. 9. Alice sends in reply a Set_Parameter command and, after receiving the corresponding ACK, begins streaming data packets to Bob. Bob Bridge Alice Manager | | | | | POST (1) | | OPEN (2) | +-------------->| |<----------+ | | | | | | POST (3) | | | |<---------------+ | | | | | | (4a) | | | | CANDIDATES | (4b) | | |<--------------+ CANDIDATES | | | (Alice's) +--------------->| | | | (Bob's) | | | | | | /----------------------------\ | | |/ .. ... ... ... ... ... ... \| | < ... ... ... ICE (5) ... ... . > | |\ .. ... ... ... ... ... ... /| | | \----------------------------/ | | | | | | HELLO (6a) | | Bernardini, et al. Expires January 10, 2012 [Page 81] Internet-Draft PPETP July 2011 |<-------------------------------+ | | | | | HELLO (6b) | | +------------------------------->| | | | | | ACK (6c) | | +------------------------------->| | | | | | ACK (6d) | | |<-------------------------------+ | | | ACK(7) | | +---------->| | | | SEND (8a) | +------------------------------->| | | | ACK (8b) | |<-------------------------------+ | | | Set_Parameter (9a) | |<-------------------------------+ | | | ACK (9b) | +------------------------------->| | | |/... ... ... ... ... ... ... .. | < ... ... Data Streaming ... .. | |\... ... ... ... ... ... ... .. | Figure 15: 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. Bernardini, et al. Expires January 10, 2012 [Page 82] Internet-Draft PPETP July 2011 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 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 Bernardini, et al. Expires January 10, 2012 [Page 83] Internet-Draft PPETP July 2011 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. Builtin profiles 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 few basic reduction and signature plugins. B.1. Sender signature profiles B.1.1. How to define a sender signature profile A sender signature profile document 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 source signature field from the packet. o Any profile-specific request. B.1.2. Shared key signature profile B.1.2.1. Profile name and parameters The name of this profile is "shared-key". This profile requires the following parameters o An h-bit hash function H, at least SHA-256 MUST be supported. The name of this parameter is "hash". The only value currently accepted for hash is "SHA-256", but other values can be added in future. o A symmetric encryption algorithm C, at least AES-256 MUST be supported. The name of this parameter is "encription". The only value currently accepted for encription is "AES-256", but other values can be added in future. Bernardini, et al. Expires January 10, 2012 [Page 84] Internet-Draft PPETP July 2011 o Two positive integers "id-size" and "mac-size", both multiple of 8 and with mac-size <= h The nodes agree on these parameters via extra-PPETP means. A summary of the parameters together with the accepted values is given in Table 5. +---------------------+----------------+----------------------------+ | Parameter | Attribute name | Accepted values | +---------------------+----------------+----------------------------+ | Hash function | "hash" | "SHA-1" | | Encryption function | "encryption" | "AES-256" | | ID size in octets | "id-size" | non-negative integer <= 8 | | MAC size in octets | "max-size" | non-negative integer <= 16 | +---------------------+----------------+----------------------------+ Table 5: Configuration parameters for the shared key signature profile B.1.2.2. Payload construction This signature profile supposes that the sender and the receiver share a common secret K. The sender is identified by an ID represented a id-size-bit number. The signature of a packet is the pair (ID, MAC), where MAC is computed as follows 1. The whole packed is processed with hash function H 2. The result of the hash is encrypted with C using K as key 3. The first mac-size bits of the encrypted hash are the MAC The signature payload is obtained by concatenating the id-size-bit number representing the ID and the mac-size-bit number representing the MAC. Since both id-size and mac-size are multiple of 8, the signature will always take an integer number of octets. B.1.2.3. Remarks o This profile does not say how the two nodes agree on the common secret K, this is supposed to be done via extra-PPETP means. For example, if the two nodes are a server and a user, K could be a long-term password, while if the two nodes are two peers K could be the result of a Diffie-Hellman key agreement procedure. o In order to be sure that the packet was signed by a node A, it is necessary to be sure that both ID and K refer to A. This will typically require some form of authentication that must be done Bernardini, et al. Expires January 10, 2012 [Page 85] Internet-Draft PPETP July 2011 via extra-PPETP means. o In order to allow for an autonomous Diffie-Hellman key exchange between the nodes without involving a central server, a node can communicate its ID and its public Diffie-Hellman key in the PEER_CREDENTIAL attribute of the Data_Control/Start packet. o 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.1.3. Void signature profile This profile does not add any signature to the packet. It is defined for those cases where signatures would be redundant. B.1.3.1. Profile name and parameters The name of this profile is "void". This profile defines no parameters B.1.3.2. Creating the signature This profile does not create any signature. The payload is empty. B.1.3.3. Verifying the signature The signature check is always positive. B.2. Source signature profiles B.2.1. How to define a source signature profile A source signature profile document 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 source signature field from the packet. o Any profile-specific request. Bernardini, et al. Expires January 10, 2012 [Page 86] Internet-Draft PPETP July 2011 B.2.2. Rabin signature profile This profile is based on the Rabin signature algorithm [RABIN] B.2.2.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. B.2.2.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 Signature field with any unused most significant bits set to zero. B.2.2.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. Bernardini, et al. Expires January 10, 2012 [Page 87] Internet-Draft PPETP July 2011 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. B.3. Reduction profiles B.3.1. How to define a reduction profile A reduction profile definition 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. o Any reduction-profile specific request. B.3.2. Vandermonde reduction profile B.3.2.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)). Bernardini, et al. Expires January 10, 2012 [Page 88] Internet-Draft PPETP July 2011 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.6. 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.6. 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. B.3.2.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 Appendix B.3.2.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 Appendix B.3.2.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 Appendix B.3.2.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. Bernardini, et al. Expires January 10, 2012 [Page 89] Internet-Draft PPETP July 2011 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 Appendix B.3.2.2.2) to obtain a string of L/R octets that represents the payload of the data packet. B.3.2.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 6. The element of GF(2^d) associated with 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 6: Polynomials used to define GF(2^d) B.3.2.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) Bernardini, et al. Expires January 10, 2012 [Page 90] Internet-Draft PPETP July 2011 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 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. B.3.2.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. B.3.3. 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). Bernardini, et al. Expires January 10, 2012 [Page 91] Internet-Draft PPETP July 2011 B.3.3.1. Profile name and parameters The profile name is "basic". This profile defines no parameters. B.3.3.2. Payload construction The payload is a verbatim copy of the content packet. B.3.3.3. Profile-related definitions Data packet flags: Flags F, G and H are unused. Set_Default payload: Set_Default carries no payload. Payload with the Inline bit set: Inline bit is unused. Profile-specific request: This profile defines no profile-specific request. 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 Bernardini, et al. Expires January 10, 2012 [Page 92] Internet-Draft PPETP July 2011 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 January 10, 2012 [Page 93]