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