Internet Engineering Task Force R. Bernardini
Internet-Draft R. Cesco Fabbro
Expires: July 5, 2011 R. Rinaldo
UniUD
January 5, 2011
Peer-to-Peer Epi-Transport Protocol
draft-bernardini-ppetp-01
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 in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 15, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bernardini, et al. Expires April 15, 2011 [Page 1]
Internet-Draft PPETP October 2010
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5
2. Informal overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Applicative context . . . . . . . . . . . . . . . . . . . 5
2.2. Reducing the upload bandwidth . . . . . . . . . . . . . . 6
2.2.1. Reduction profiles . . . . . . . . . . . . . . . . . . 7
2.3. Typical behavior of a PPETP node . . . . . . . . . . . . . 8
2.3.1. Live streaming . . . . . . . . . . . . . . . . . . . . 8
2.3.2. Conferencing . . . . . . . . . . . . . . . . . . . . . 11
3. Preliminary definitions . . . . . . . . . . . . . . . . . . . 12
3.1. Address of a PPETP session . . . . . . . . . . . . . . . . 12
3.2. Network type and topology . . . . . . . . . . . . . . . . 12
3.3. Packet source and packet sender . . . . . . . . . . . . . 13
3.4. Packet signature . . . . . . . . . . . . . . . . . . . . . 13
3.5. Streams and packets . . . . . . . . . . . . . . . . . . . 14
3.6. PPETP channels . . . . . . . . . . . . . . . . . . . . . . 14
3.7. Underneath transport protocol . . . . . . . . . . . . . . 15
3.8. Generalized address . . . . . . . . . . . . . . . . . . . 15
3.8.1. Binary format generalized addresses . . . . . . . . . 15
3.9. Plugin structure . . . . . . . . . . . . . . . . . . . . . 18
3.10. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 19
4. PPETP packets . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Data packets . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Control packets . . . . . . . . . . . . . . . . . . . . . 22
4.2.1. Control packet format . . . . . . . . . . . . . . . . 22
4.2.2. Request types . . . . . . . . . . . . . . . . . . . . 26
4.2.3. Control packet transmission procedure . . . . . . . . 28
4.2.4. Control packet acknowledgement procedure . . . . . . . 29
4.2.5. Data control subcommands . . . . . . . . . . . . . . . 29
4.2.6. Routed control packets . . . . . . . . . . . . . . . . 32
4.3. Packet processing . . . . . . . . . . . . . . . . . . . . 36
5. PPETP Attributes . . . . . . . . . . . . . . . . . . . . . . . 37
6. Peer handshaking procedure . . . . . . . . . . . . . . . . . . 39
7. PPETP configuration . . . . . . . . . . . . . . . . . . . . . 40
Bernardini, et al. Expires April 15, 2011 [Page 2]
Internet-Draft PPETP October 2010
7.1. Bootstrap configuration protocol . . . . . . . . . . . . . 40
7.1.1. Design goals . . . . . . . . . . . . . . . . . . . . . 41
7.1.2. Protocol structure . . . . . . . . . . . . . . . . . . 42
7.1.3. Compact Configuration Format . . . . . . . . . . . . . 49
8. ICE-based Connection Establishment Procedure . . . . . . . . . 55
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1.1. Determining ICE role . . . . . . . . . . . . . . . . . 56
8.2. Punch payload format . . . . . . . . . . . . . . . . . . . 57
8.3. ICE-related attributes . . . . . . . . . . . . . . . . . . 57
9. Security Considerations . . . . . . . . . . . . . . . . . . . 59
9.1. Poisoning attack . . . . . . . . . . . . . . . . . . . . . 59
9.1.1. Large bandwidth nodes . . . . . . . . . . . . . . . . 60
9.1.2. Multiple stream session . . . . . . . . . . . . . . . 60
9.2. Defamatory attack . . . . . . . . . . . . . . . . . . . . 61
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
10.1. Address classes registry . . . . . . . . . . . . . . . . . 61
10.2. NAT Traversal procedure registry . . . . . . . . . . . . . 61
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
11.1. Normative References . . . . . . . . . . . . . . . . . . . 62
11.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 63
A.1. Live media . . . . . . . . . . . . . . . . . . . . . . . . 64
A.2. Remote lecturing . . . . . . . . . . . . . . . . . . . . . 70
Appendix B. Extensions to other protocols . . . . . . . . . . . . 71
B.1. RTSP extensions . . . . . . . . . . . . . . . . . . . . . 71
B.2. SDP extensions . . . . . . . . . . . . . . . . . . . . . . 71
B.2.1. Transport protocols ("proto") . . . . . . . . . . . . 71
B.2.2. Attributes . . . . . . . . . . . . . . . . . . . . . . 72
Appendix C. Builtin profiles . . . . . . . . . . . . . . . . . . 73
C.1. Sender signature profiles . . . . . . . . . . . . . . . . 73
C.1.1. How to define a sender signature profile . . . . . . . 73
C.1.2. Shared key signature profile . . . . . . . . . . . . . 73
C.1.3. Void signature profile . . . . . . . . . . . . . . . . 75
C.2. Source signature profiles . . . . . . . . . . . . . . . . 75
C.2.1. How to define a source signature profile . . . . . . . 75
C.2.2. Rabin signature profile . . . . . . . . . . . . . . . 75
C.3. Reduction profiles . . . . . . . . . . . . . . . . . . . . 77
C.3.1. How to define a reduction profile . . . . . . . . . . 77
C.3.2. Vandermonde reduction profile . . . . . . . . . . . . 77
C.3.3. Basic reduction profile . . . . . . . . . . . . . . . 80
Bernardini, et al. Expires April 15, 2011 [Page 3]
Internet-Draft PPETP October 2010
1. Introduction
This document describes PPETP (Peer-to-Peer Epi-Transport Protocol),
a chunkless peer-to-peer distribution protocol originally designed
for data streaming over networks made of heterogeneous nodes. PPETP
allows for an efficient usage of the upload characteristics of every
node, including those with limited upload bandwidth. The network
coding procedures used to allow for the exploitation of even smal
amounts of upload bandwidths have the interesting side effect to make
the system robust with respect to packet losses (due to congestion or
churn) and some threats such as tentatives of"poisoning" the data
distribution system.
Differently from other peer-to-peer approaches, PPETP can be
considered a "pure transport" protocol in the sense that it gives no
tool for searching for new peers, nor it dictates any network
structure, but it takes care only of the problem of propagating data
among peers. Other aspects (i.e., network topology or peer search)
are supposed to be handled by extra-PPETP means. This "separation"
between transport and topology makes PPETP flexible enough to be used
with several structures: from networks managed by a central node, to
networks with a highly distributed control (see Section 2.3.1 for an
example).
The overlay transport layer provided by PPETP is designed to appear,
from the standpoint of an application writer, like a multicast-like
transport protocol with an API similar to the well-known BSD socket
API. For example, a PPETP session is uniquely identified by a "PPETP
pseudo-address" (made of a host and pseudo-port pair) that can be
inserted, for example, in SDP descriptions. This multicast-like
nature makes easier to reuse already available protocols such as
RTSP, SIP and SDP.
Another major difference with common peer-to-peer protocols is the
fact that PPETP is _chunkless_, that is, it does not partition the
content in chunks, but it operates at the packet level, handling each
packet as an opaque sequence of bytes. This makes PPETP data format
"transparent" in the sense that any "sequence of packets",
independently of their format, can be transmitted with PPETP. This
implies that any type of data (e.g., audio, video, slides) encoded
with any type of encoder (lossy, lossless, scalable or multiple
description) can be distributed over PPETP. Even encrypted data can
be transmitted.
PPETP integrates itself nicely with the connection establishment
procedures of ICE [RFC5245].
Bernardini, et al. Expires April 15, 2011 [Page 4]
Internet-Draft PPETP October 2010
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. Informal overview
The goal of this section is to give an informal (non-normative)
description of the main characteristics of PPETP, in order to make
the formal description given in the following sections more
intuitive.
2.1. Applicative context
PPETP is a protocol originally designed for live streaming
applications. Live streaming over peer-to-peer (P2P) networks is a
peculiar application, affected by several problems, such as
Asymmetric bandwidth Residential users are typically connected to
the Internet via an ADSL line. Depending on the type of the media
stream, a residential user could have enough download bandwidth to
receive it, but not enough upload bandwidth to retransmit it,
making not trivial to exploit the user upload capabilities even.
More in general, the network can include nodes with different
upload capabilities and one would like to be able to exploit the
bandwidth of each peer as much as possible, both for low-bandwidth
and high-bandwidth nodes.
Packet losses This is a potential problem with any type of media
streaming over unreliable protocols, but it is especially
important in the context of P2P networks, since a node can leave
the network at any time, possibly leaving other nodes without data
for a long time (until the "orphan" node finds a new peer).
Security P2P networks have several security issues [IPTV], here we
simply cite the "stream poisoning attack" where a node propagates
incorrect packets which cause an incorrect decoding of the
multimedia content and are propagated to the whole network by the
peer-to-peer mechanism.
PPETP is designed to counteract the problems above and to appear at
the application developer as a multicast-like transmission protocol,
in the sense that the API (Application Programming Interface) used
for exchanging data over a PPETP network is not very different from
the API that one would use for exchanging data over a multicast
session.
Bernardini, et al. Expires April 15, 2011 [Page 5]
Internet-Draft PPETP October 2010
We would like to repeat here that PPETP takes care _only_ of the
efficient transfer of stream data between different peers; other
aspects of P2P (e.g., building the network) are supposed to be
managed by extra-PPETP means. This separation between data transport
and network management increases the flexibility of PPETP and allows
for its use in several applicative contexts, for example, with
networks managed by a central server or in a distributed manner, with
only one media source (as in live streaming) or several (like in
conferencing).
2.2. Reducing the upload bandwidth
A key ingredient of PPETP, used to solve the problems outlined above,
is the "reduction" procedure. In PPETP every node of the P2P network
processes every content packet of the data stream with a "reduction
function" that maps the content packet in a reduced packet whose size
is (typically) a fraction of the size of the original packet. The
reduction is carried out in a way that allows the reconstruction of
the original packet from the knowledge of a suitable number of
reduced versions.
To make the idea of reduction function more concrete and make the
ideas above clearer, we briefly recall here the algorithm described
in [DCC08] that inspired the PPETP reduction approach and that is
used in the PPETP Vandermonde reduction profile (see Appendix C.3.2).
Let P denote a content packet and suppose one wants to reduce its
size by a factor R. In [DCC08] packet P is interpreted as a matrix
with R rows and a suitable number of columns whose entries are
elements of GF(2^d), the finite field with 2^d elements (this could
require some padding). Each node at start-up chooses an element b of
GF(2^d) and constructs the row vector
r_b = [1, b, b^2, ..., b^(R-1)]
The node obtains the reduced version of P by computing
u_b = r_b*P
and collecting the entries of u_b in a "reduced packet" to be sent to
other peers. Since u_b has the same number of columns as P, but only
one row, the size of the reduced packet is R times smaller than the
size of P; therefore, the requested upload bandwidth is R times
smaller than the download bandwidth.
In order to recover packet P a node contacts R peers, receives their
reduced packets u_b1, u_b2, ... u_bR and solves the linear system
| u_b1 | | 1 b1 b1^2 ... b1^(R-1) |
| u_b1 | | 1 b1 b1^2 ... b1^(R-1) |
| : | = | : : : : | * P
Bernardini, et al. Expires April 15, 2011 [Page 6]
Internet-Draft PPETP October 2010
| u_bR | | 1 bR bR^2 ... bR^(R-1) |
Since the matrix above is a Vandermonde matrix, packet P can be
recovered as long as all the b1, b2, ..., bR values are different.
Few comments about the just outlined reduction procedure are in order
o If a node has a large upload bandwidth, it can exploit it by
serving several peers. Alternatively, a node with a large upload
bandwidth could produce different reduced versions of P by
applying different vectors r_b to the same content packet P. A
node doing this can send more than one reduced version to the same
peer.
o To counteract the risk of packet losses (due to network
congestion, peer leaving or other) the node can request data to N
> R peers and it will be able to recover P as long as it receives
at least R reduced packets out of N.
o 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.2.1. Reduction profiles
The reduction procedure described above is not the only possible
approach for data reduction. For example, other network coding
procedures (e.g., digital fountains) could be used instead of the
product by the Vandermonde matrix. In order to allow for future
adoptions of different reduction procedures, this document does not
describe a specific reduction procedure, but demands such a
description to side documents describing the so called "reduction
profiles". The independence of PPETP from the reduction procedure is
achieved by introducing in PPETP packets fields that are considered
by PPETP as opaque sequences of octets whose meaning is defined by
the reduction profile documents. (An approach like this is used, for
example, in RTP [RFC3550].)
At the time of writing of this document two profiles are defined: the
_Vandermonde_ profile (that uses the reduction procedure of [DCC08]
described above) and the _Basic_ profile that does no reduction at
all, that is, the reduced packet is equal to the content packet. The
Basic profile is thought for streams with very low bandwidth
requirements where the bandwidth saving is not worth the
computational complexity of a "true" reduction profile. For example,
Bernardini, et al. Expires April 15, 2011 [Page 7]
Internet-Draft PPETP October 2010
the Basic profile could be used, in a single-server context, to
distribute to the clients the RTCP packets produced by the server.
In order to allow for profile-based definition of the reduction
procedures, PPETP generalizes the Vandermonde procedure outlined
above to an abstract "reduction procedure" with the following key
characteristics
Size reduction
The size of the reduced packet is a fraction of the size of the
original content packet and this allows for a reduced upload
bandwidth requirement.
Parametrization
The reduction procedure is parametrized by a set of reduction
parameters. Using different reduction parameters gives rise to
different reduced versions of the content packet.
Reconstruction
The content packet can be recovered from the knowledge of a
suitable number of different reduced versions. In the Vandermonde
profile the number of required reduced versions is always equal to
R, but this is not mandatory. For example, in an hypothetical
reduction profile based on digital fountains, the number of
required reduced versions would be a random variable.
2.3. Typical behavior of a PPETP node
In order to make clearer the formal description of PPETP given in the
following sections, it is worth to describe few possible typical uses
of PPETP. Since many finer details of PPETP will be explained in the
following sections, the examples given here will leave out many
details. A much more detailed version of these examples can be found
in Appendix A.
2.3.1. Live streaming
Suppose Alice wants to watch a concert that it is streamed over PPETP
by a streaming provider. A possible sequence of actions is the
following
1. Alice goes to the web page of the streaming provider, finds a
link related to the concert and clicks on it.
2. The href attribute of the link points to an RTSP server with the
program description. The web browser launchs a "viewer" (an
external program or a plugin) that queries the RTSP server and
discovers that the program is streamed over PPETP.
Bernardini, et al. Expires April 15, 2011 [Page 8]
Internet-Draft PPETP October 2010
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. (Actually,
PPETP does not specify an algorithm to find the upper peer, but
leaves this decision at the application level and limit itself
only to provides a set of tools that can be used to implement
several different solutions.)
For the sake of this example we will suppose that the streaming
provider manages the PPETP network; therefore it chooses the
upper peers of Alice and send them a request (via suitable
control packets) to begin the data streaming toward Alice. If
an upper peer is behind a NAT, the control packet will include
information necessary to start a suitable NAT traversal
procedure.
Although this centralized solution could seem to introduce a
"single point of failure" and go against the spirit of peer-
to-peer networks, it must be said that
+ In this case there is a single entity (the streaming
provider) that is the source of data and that is
interested in doing the streaming. If the provider host
fails, the only data source fails and the whole system
makes no sense.
+ Letting the server to assign the upper peers to Alice
allows for a finer control of the quality of service
Bernardini, et al. Expires April 15, 2011 [Page 9]
Internet-Draft PPETP October 2010
assigned to Alice. For example, if Alice is subscribed to
a "high-reliability" service the server will assign her
more upper peers, in order to lower the packet loss
probability experienced by Alice. Moreover, if desired,
the upper peer assignament could be done in order to
maximize some figure of merit (e.g., locality).
Other possible solutions for peer assignament are discussed
in Section 2.3.1.1.
The server signs the control packets, so that the nodes will
know that the packets are legitimate. The nodes receive the
signing key of the server with the configuration data. Since
the configuration is transmitted over a secure connection, the
nodes know that the received key is the correct one.
8. Alice's host begins receiving reduced data. As soon as enough
data are received, the content packets are recovered and moved
to the application level. Alice's viewer will read the
recovered data via a suitable function of the PPETP API
(something similar to the recv() function in the BSD socket
API). The read data will be given to the decoder and shown to
the user.
9. Suppose now that Bob joins the network and that the server
assigns him Alice as an upper peer. The PPETP software on
Alice's host will receive a control packet from the server that
asks Alice to send data to Bob.
10. In response to the received request the PPETP software on Alice
applies the reduction procedure to the recovered packets and
forwards the result to Bob.
11. When Alice wants to stop to watch the concert, her software
sends a TEARDOWN request to the RTSP server that in turn sends
suitable control packets to the upper peers of Alice, asking
them to stop the transmission toward Alice and maybe redirecting
their stream to the lower peers of Alice (that now would loose
one upper peer).
Note that if the lower peers of Alice have more upper peers
than the minimun necessary, they will not notice the leaving
of Alice since they will keep receiving enough data to
recover the content packets.
Alternatively, Alice herself can send suitable redirect commands
to her upper peers, asking them to redirect their data stream to
the lower peers of Alice.
Bernardini, et al. Expires April 15, 2011 [Page 10]
Internet-Draft PPETP October 2010
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.
2.3.1.1. Alternative setups
In the example above we supposed a very centralized approach to the
management of the PPETP network, where the server chooses the upper
peers and send them the request to send data to the new node. This
is not the only possible solution, for example,
o The server could choose the upper peers of the new node, but let
the new node to contact them. The server could send the upper
peer list in the configuration data, possibly with the command
(pre-signed) to be sent to each new peer.
o The server just takes a "handful" of upper peers and send them to
the new node. The new node will contact each peer and ask it for
data. If the peer has no more upload bandwidth available, it
refuses the request and the new node will try another peer. Note
that with this setup it is difficult to make sure that the new
node does not get more than its fair share of upper peers, but
maybe in some applicative context (e.g., conferencing with a small
number of partecipants) this could be not a problem.
o A possible "strongly distributed" solution is the following: the
nodes in the PPETP network are also organized as a Distributed
Hash Table (DHT) where to each node is assigned a set of "keys"
represented by b-bit integers. The new node receives in the
configuration data the address of one or more "entry points" to
the DHT. In order to find its upper peers the node randomly draws
few keys, searchs for the corresponding nodes and asks them to
send data. As in the previous approach, if a node has no more
upload bandwidth available, it refuses the request and the new
node will try another peer.
2.3.2. Conferencing
Most of the steps used in the live example in Section 2.3.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 April 15, 2011 [Page 11]
Internet-Draft PPETP October 2010
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).
3. Preliminary definitions
3.1. Address of a PPETP session
Since a PPETP session is a distributed structure, it has not a
"natural" concept of "address." Nevertheless, for compatibility with
currently available protocols (e.g., SDP [RFC4566]) it is convenient
to be able to refer to a PPETP session with an (host address, port)
pair. Since a PPETP session is a complex object that needs to be
configured before a node can join it a natural choice for the IP
address associated to a PPETP session is the address of a
"configuration server" that the node must contact to join the PPETP
session. The server is queried using a special light-weight protocol
described in Section 7.1.
The role of the port is played by the "PPETP session number" a 16-bit
unsigned integer that together with the host address uniquely
identifies the PPETP session.
3.2. Network type and topology
Since in a PPETP network each node streams autonomously its data to
other nodes (see Section 2.3), a PPETP network can be considered a
push network. Typically in a PPETP network each node receives/
streams data from/to a fairly stable set of nodes. As already said,
PPETP does not mandate any particular network topology.
If node A receives data from node B, we will say that A is a "lower
peer" of B and that B is an "upper peer" of A. (This nomenclature is
inspired to the typical picture representing a tree structured
network where data flow from top to bottom). The set of upper and
lower peers of a node is the "neighborhood" of the node.
Bernardini, et al. Expires April 15, 2011 [Page 12]
Internet-Draft PPETP October 2010
In a PPETP network every peer is identified by a 32-bit peer ID. The
peer ID has the same size of the RTP SSRC, so that in an application
employing RTP the two identifiers can coincide (but this is not
mandatory).
3.3. Packet source and packet sender
For each packet received by a node we distinguish the packet _source_
from the packet _sender_
o The packet _sender_ is the peer that sent us the packet (in other
words, it is the peer whose IP address is in the IP header). The
packet sender is always a neighbor of the node.
o The packet source is the peer that _produced_ the packet. For
example, in a video streaming application the source of a video
packet is the peer "connected to the camera".
We will occasionally use "originator" and "forwarder" as synonymous,
respectively, of "source" and "sender".
3.4. Packet signature
In order to counteract a number of possible security problems (see
discussion in Section 9), PPETP introduces the possibility of signing
a packet. Since a packet can have two different "origins" (its
"source" and its "sender", see Section 3.3), two different types of
signature are introduced: source and sender signature.
The differences between Sender and Source signatures will be clear in
the following, here we can anticipate that
o The Source signature grants for the identity of the node that
_created_ the packet, while the Sender signature grants for the
identity of the node that _forwarded_ the packet.
o The Sender signature depends on the identity of the forwarder and
changes as the packet travels along the network, the Source
signature depends only on the creator and it remains the same in
every point of the network.
o As it will be clear in Section 4.2.6, 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.
Bernardini, et al. Expires April 15, 2011 [Page 13]
Internet-Draft PPETP October 2010
o It will be clear in the following (see Section 4.2.6) that the
Sender signature needs to be checked _only_ by the recipient,
while the the Source signature needs to be checked by _all_ the
nodes that forward the packet. This implies that the Sender
signature can be obtained from a secret shared between the sender
and receiver, while the Source signature must employ asymmetric
techniques.
3.5. Streams and packets
A PPETP network carries a content made of one or more "streams"; each
stream is a sequence of packets (called also "content packet" to
distinguish them from "reduced packets") originated from a source.
Each stream in a session is uniquely identified by its ID represented
by a 12-bit integer value.
For example, in an "Internet radio" application one has only one
stream and one source, while in a conferencing application there
is a stream for every participant and every participant is a
source.
Each content packet in a stream is uniquely identified by its
"sequence number" that increases by one at each packet. Since a
PPETP sequence number is a 20-bit integer, if the content packets are
RTP packets, the RTP sequence number can be used also as the PPETP
sequence number (but this is not mandatory).
It is worth emphasizing that different streams have different
sequence number spaces, so that two packets belonging to different
streams can share the same sequence number. Alternatively, one could
say that a packet in a session is uniquely determined by the 32-bit
number obtained by joining together the 12-bit stream ID and the 20-
bit sequence number.
3.6. PPETP channels
A node in a PPETP network can produce several reduced versions of the
same content packet by processing it several times, each time with a
different set of reduction parameters. The stream of packets
associated to a single set of reduction parameters is called a
"channel". Each node can have at most 16 channels, identified by a
4-bit channel ID; every channel can be connected to any number of
lower peers. The number of peers connected to the same channel is
limited only by the node upload bandwidth.
Bernardini, et al. Expires April 15, 2011 [Page 14]
Internet-Draft PPETP October 2010
3.7. Underneath transport protocol
The prefix Epi- in "Epi-Transport" reminds us that PPETP is not a
true transport protocol, but it relies on a "true" transport
protocol. PPETP does not require that the used transport protocol be
reliable. This document considers in detail the case where UDP is
used as transport protocol, but other choices (e.g., DCCP [RFC4340])
can be added in the future.
3.8. Generalized address
In order to contact an host in Internet one needs the IP address of
the node and the port the node is listening to. However, nowdays
many nodes (especially residential users) are behind NATs and this
makes their IP address (i.e., the IP address associated to their
network interface) useless for hosts outside the NAT. In order to
contact a node behind a NAT one needs to do some connection
establishment procedures (CEP) and in order to do that one need a set
of information different from the IP address and port of the target
node. For example, in the case of the ICE-based procedure described
in ??????, a node to start the CEP needs to know the address of a
bridge node and the peer ID of the target node.
In order to unify the handling of connections, indipendently on the
connection type employed, we introduce the concept of _generalized
address_ that can be interpreted as a set of "instructions" that
explain how to contact the node.
Generalized addresses are partitioned into _address classes_.
Addresses belongin to the same class require the same set of
informations. Currently defined address classes are
ip
The node can be reached directly. The informations required are
the IP address and the port of the remote node.
ice
The ICE-based CEP of Section ????? must be used. The informations
required are the address of a bridge node and the ID of the other
peer.
3.8.1. Binary format generalized addresses
Every time it is necessary to include a generalized address in a
PPETP packet, the format described in this section is used. The
first octect has the format shown in Figure 1: the four most
significative bits denote the class of the generalized address, the
meaning of four least significant bits depends on the address class.
Bernardini, et al. Expires April 15, 2011 [Page 15]
Internet-Draft PPETP October 2010
The number and the meaning of the octets is defined by the address
class. This document define address classes _ip_ (class=0) and _ice_
(class=1). Classes 2 to 14 are undefined, class 15 is reserved for
future extensions.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Class | Extra |
+-+-+-+-+-+-+-+-+
Figure 1
3.8.1.1. IP address class
The format for the IP address class is shown in Figure 2. The fields
have the following meaning
Address Class (bits 0-3) This field is set to 0, the class number
for the IP format.
Version (bits 4-5) IP version. The following values are defined
* Version=0 corresponds to IPv4
* Version=1 corresponds to IPv6
* Other values are reserved for future use
FLAGS (bits 6-7) Two free bits that are available for use for
contexts that require a generalized address. For example, these
bits are used in the ICE-based CEP.
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]) this field is set to the
destination port number (possibly with the most significant bits
set to zeros if b < 16); otherwise it is set to zero.
Address This field contains the IP address of the remote host. Its
size depends on the value of the Version field. This document
defines only the following cases restricted to protocols UDP and
DCCP
Bernardini, et al. Expires April 15, 2011 [Page 16]
Internet-Draft PPETP October 2010
Version=4 (IPv4) The Address field is 32 bits long and contains
the IPv4 address
Version=6 (IPv6) The Address field is 128 bits long and contains
the IPv6 address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | V | F | Protocol | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Address :
: (size depends on Version and Protocol) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
3.8.1.2. ICE address class
The format for the ICE address class is shown in Figure 3. The
fields have the following meaning
Address Class (bits 0-3) This field is set to 1, the class number
for the ICE format.
Transaction ID give (bit 4) If this bit is set, then a 64-bit
transaction number to be used with the ICE-based CEP is present at
the end
Reserved bits (bits 5-7) These bits are reserved for future use and
MUST be set to zero.
Protocol (bits 8-15) The transport protocol to be used to contact
the bridge node. This is the same value of the Protocol field in
the IP header [RFC0791]. Currently only protocol UDP is used.
Port (bits 16-31) If the transport protocol uses b-bit port numbers,
with b <= 16, (e.g., UDP, DCCP [RFC4340]) this field is set to the
port number of the bridge node (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 bridge node. Its
size depends on the value of the Version field. This document
defines only the following cases restricted to protocols UDP and
DCCP
Bernardini, et al. Expires April 15, 2011 [Page 17]
Internet-Draft PPETP October 2010
Version=4 (IPv4) The Address field is 32 bits long and contains
the IPv4 address
Version=6 (IPv6) The Address field is 128 bits long and contains
the IPv6 address
Transaction ID The bridge node in the ICE-based CEP described in
?????? makes use of a transaction ID to match the candidate lists
of the two nodes. The transaction ID can be optionally included
in the generalized address, by setting bit T to 1 and appending
the transaction ID at the end of the address. The behaviour of
the node is expected to be the following
* If the transaction ID is given, the node collects its candidate
and send them to the bridge using the given transaction ID
* If the transaction ID is not given, the node sends a TRIGGER
packet to the bridge which in turn will send a COLLECT command
to both peers. The transaction ID will be included in the
COLLECT command.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |T| 0 | Protocol | Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Address :
: (size depends on Version and Protocol) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64-bit transaction ID (if bit T is set) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
3.9. Plugin structure
PPETP makes use of several "tools": besides the idea of reduction
procedure described above, it employs two different signature
algorithms (for the sender and source signature, see Section 3.4),
key-exchange techniques and NAT traversal procedures.
In order to make easier to keep PPETP up-to-date with future
developments, this document does not specify directly how the
procedures above must be done, but delegates their description to
side documents. This document, however, for the sake of
Bernardini, et al. Expires April 15, 2011 [Page 18]
Internet-Draft PPETP October 2010
completeness, defines a minimal set of procedures.
As with the reduction procedure, this "plugin structure" is obtained
by treating as opaque strings of octets those parts of packets that
need to be processed by the plugins above. The idea is that the
PPETP software would extract the part reserved to the plugin, give it
to the plugin and let the plugin interpret it.
3.10. Glossary
Channel:
A channel is a stream of reduced packets relative to the same set
of reduction parameters.
Content packet:
A packet of the multimedia content to be distributed. It is
expected that a common format for a content packet be RTP, but
this is not mandatory at all. See also Reduced packet.
Lower peer:
A node X is a lower peer of node Y if Y sends its reduced data to
X. See also upper peer.
Packet sender:
The node that transmitted the packet. Compare with packet source.
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 4.2.6). Compare with packet sender.
Peer ID The 32-bit number that uniquely identifies a peer in a PPETP
network.
Reduced packet:
A packet carrying the data obtained by applying a reduction
procedure to a content packet.
Reduction function:
A procedure to process content packets to map them into smaller
packets with the property that the original content packet can be
recovered when enough reduced packets are available.
Stream A sequence of content packets originated from a single node.
Bernardini, et al. Expires April 15, 2011 [Page 19]
Internet-Draft PPETP October 2010
Stream ID The 12-bit number that uniquely identifies a stream in a
PPETP network.
Upper peer:
A node Y is an upper peer of node X if Y sends its reduced data to
X. See also lower peer.
4. PPETP packets
The packets exchanged by PPETP nodes can be classified as data packet
or control packet.
Data packets are the most common ones and carry as payload the
outcome of the reduction procedure. Data packets have a sequence
number, a stream ID (both inherited from the original content
packet) and a channel number. Data packets are not acknowledged.
Control packets are mainly used during session setup and for data
flow control. Control packets require an acknowledge, the only
exceptions to this rule are the Acknowledge control packet (see
Section 4.2) and routed packets that are acknowledged only by the
target node (see Section 4.2.6).
4.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
_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
Bernardini, et al. Expires April 15, 2011 [Page 20]
Internet-Draft PPETP October 2010
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.
Channel (bits 8-11) The channel number.
Reserved (bits 12-23) Unused bits. This field SHOULD be set to zero
by the sender and MUST be ignored by the receiver.
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-43) The stream ID of the original content packet.
Stream ID=0 is reserved.
Sequence number (bits 44-63) The sequence number of the original
content packet. As said in Section 3.5, this is a 20-bit integer,
so that the RTP 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.
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.2), in PPETP a node can be requested to
attach at the end of the packet its sender signature. The way the
signature is created and stored in this field is defined by the
sender signature profile employed (see Appendix C.1.1).
Bernardini, et al. Expires April 15, 2011 [Page 21]
Internet-Draft PPETP October 2010
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|Channel| Reserved | PPETP Magic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Payload (variable size) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Sender Signature (variable size) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: PPETP data packet
4.2. Control packets
In PPETP the connection between two peers is managed by means of
control packets. In the current version of PPETP control packets are
used in peer handshaking (Set_Parameter packet), connection keep-
alive (Hello packet) and data flow control (commands to start/stop/
redirect a data flow, and to start a connection establishment
procedure). Control packets are expected to be sent from a peer to a
neighboor of its, but data flow control packets can also be sent by a
"network manager" host to peers.
Control packet are expected to be typically sent from the source host
to the target host, but, in order to cope with some problems posed by
NATs, PPETP allows control packets to be routed along the peer-to-
peer network. Control packets routed along the PPETP network are
called "routed packets" and are described in details in
Section 4.2.6.
4.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.
Bernardini, et al. Expires April 15, 2011 [Page 22]
Internet-Draft PPETP October 2010
Padding (P, bit 3): See the corresponding description for the data
packet.
Request (bits 4-7): The actual request. Request values from 0 to 3
are defined in this document; request value 12 is reserved to the
reduction profile; request value 13 is reserved to the sender
signature profile; request value 14 is reserved to the source
signature profile. Other request values are unassigned and
reserved for future use.
Extra : (bits 8-15): Its meaning depends on the value of Request.
If a request does not use this field, this field SHOULD be set to
0.
Routing Length (bits 16-23) If this is a routed packet (see
Section 4.2.6), this field contains the length in octets of the
Routing Header, otherwise this field MUST be zero.
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.
Sequence Number (bits 32-63): The packet sequence number. The
sequence in control packet 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 swarm, each peer has its own control packet number
space. The only constraints are (1) that the sequence number must
be monotone increasing and (2) that the triple (sender, recipient,
sequence number) identify uniquely the control packet (but see
Section 4.2.3 for details about packet retransmission). In
particular, each node can keep a single number space shared by all
the control packets transmitted by the node or different number
spaces for packets sent to different peers.
Sub-sequence number (SSN, bits 64-71): According to Section 4.2.3,
if a packet has not been acknoweldged within a timeout, a node can
try to retransmit the same command. In order to allow the
recipient to recognize that a packet is a copy of a previous
packet, each control packet carries a Sequence Number (described
Bernardini, et al. Expires April 15, 2011 [Page 23]
Internet-Draft PPETP October 2010
in the following). In some contexts (i.e., computation of
retransmission timeor Section 4.2.3 and packet routing in
Section 4.2.6) it is useful to be able to distinguish between
different retransmitted versions of the same control packet. In
order to allow to say when a packet is a different retransmission,
the SSN is set to zero when the packet is sent for the first time
and it is increased each time the packet is retransmitted.
Unused (bits 72-95) Unused bits, MUST be set to zero.
Routing header (variable size): Used in packet routing and present
only if RH Length is not zero. See Section 4.2.6 for details.
Payload (variable size): Its meaning and format depends on the
specific request.
Source signature (variable size) The signature of the source of this
packet. Used only with routed control packets; see Section 4.2.6
for details.
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.2), in PPETP a node can be requested to
attach at the end of the packet its sender signature. The way the
signature is created and stored in this field is defined by the
sender signature profile employed (see Appendix C.1.1).
Bernardini, et al. Expires April 15, 2011 [Page 24]
Internet-Draft PPETP October 2010
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| Extra | RH Length | PPETP Magic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSN | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Routing Header (variable size, only if bit R is set) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Payload (variable size) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Source signature (variable size, only if bit R is set) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Sender Signature (variable size) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPETP control packet
Figure 5: PPETP control packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Reduction parameters (variable size) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Payload of Set_Default
Bernardini, et al. Expires April 15, 2011 [Page 25]
Internet-Draft PPETP October 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subcommand | Parameter 1 | Parameter 2 | Parameter 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Subcommand parameters (variable size) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Data_Control payload
Figure 7
4.2.2. Request types
The followings values for the Request field are defined
Hello (Request=0) This request is basically a No-op and it has two
main usages
* Hello requests can be used by the peers to exchange parameters.
The parameters are stored in the payload section as a sequence
of PPETP attributes whose format is described in Section 5. In
this version the only attribute that can be sent with the Hello
request is PEER_CREDENTIAL (if required by the signature
profile).
* It can be sent from a peer to a neighboor to keep-alive
connections through NATs.
* The Extra field of the Acknowledge packet relative to an Hello
packet will always be 0 (OK).
Set_Default (Request=1) 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 is the
32 bit Peer ID of the upper peer followed by the reduction
parameters (see Figure 6). The format used for the reduction
parameters depends on the chosen reduction profile. The channel
number is stored in the Extra field. Depending on the configured
security policy, a Set_Default with an unknown Peer ID can be
discarded or it can be accepted and the new Peer ID added to the
list of the upper peers of the node.
Bernardini, et al. Expires April 15, 2011 [Page 26]
Internet-Draft PPETP October 2010
Acknowledge (Request=2) This type of control packet is used to
acknowledge the receipt of other control packets. The payload is
5 octects long and it is the 32-bit sequence number of the
acknowledged packet followed by the SSN of the acknowledged
packet. The extra meaning of Extra depends on the command
acknowledged, but see Table 1 for an overview of the possible
values. The zero value has always the meaning of "positive
acknowledge" (i.e., no error occurred).
Data_Control (Request=3) This request is used to control the data
stream between two nodes. This control packet can be sent,
depending on the configuration, by a peer to a neighboor or by a
network manager to any peer. 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. The actual
action is determined by the SC field, as described in
Section 4.2.5. The payload contains the following fields (see
Figure 7)
Sub-command (SC, bits 0-7) The actual "sub-command." The
currently defined subcommands are described in Section 4.2.5
Parameter 1 (bits 8-15) Used by some sub-command as parameter.
See the description of the individual sub-command. If unused,
it MUST be set to zero.
Parameter 2 (bits 16-23) Used by some sub-command as parameter.
See the description of the individual sub-command. If unused,
it MUST be set to zero.
Parameter 3 (bits 16-23) Used by some sub-command as parameter.
See the description of the individual sub-command. If unused,
it MUST be set to zero.
Parameters (optional, variable size) Everything after the first
32 bits can be used to send further command parameters. This
field is a sequence of attributes in the Type-Length-Value
format shown in Figure 10. Currently defined attribute types
are described in Section 5
It is not mandatory to control the data flow through this type of
packets. Data flow could be controlled, for example, via a
suitable API called in response to command received via an
application level protocol. Having a suitable set of data control
requests increases the flexibility of the protocol.
Bernardini, et al. Expires April 15, 2011 [Page 27]
Internet-Draft PPETP October 2010
+----------+-------+------------------------------------------------+
| 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 1: Values for the Extra field of the Acknowledge packet
4.2.3. Control packet transmission procedure
All the control packets (with the exception of the Acknowledge
packet) require an Acknowledge. The procedure employed by a node
that sends a control packet MUST conform to the following guidelines
o The node MUST NOT assume that the control packet has been
processed until it receives a positive acknowledge.
o After sending the control packet the node sets a timeout for the
reception of the Acknowledge. The following cases can happen
1. A _positive_ acknowledge is received before the timeout: the
procedure terminates succesfully.
2. A _negative_ acknowledge (i.e., an acknowledge that signals
that an error occured) is received before the timeout: the
procedure terminates with a failure.
3. No acknowledge is received before the timeout: the same
control packet, with the same sequence number and with the SSN
field incremented by 1, is sent again to the recipient and a
new timeout is set. If the number of retransmissions reachs a
threshold fixed by the node, the procedure terminates with a
failure. The retransmission timer must be computed according
to [RFC2988]. The SSN field can be used to avoid the
ambiguities of round-trip times associated to retransmitted
packets.
Bernardini, et al. Expires April 15, 2011 [Page 28]
Internet-Draft PPETP October 2010
4.2.4. 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.
4.2.5. Data control subcommands
As already anticipated, Data_Control packets are sent by peers or
network managers to manage the data flow between two peers. More
precisely, Data_Control packets allow to start, stop or redirect a
stream of reduced packet or to start a connection establishment
procedure, depending on the specific sub-command. Currently defined
sub-command for the Data_Control request are
Start (SC=0) Start the handshaking procedure described in Section 6.
The channel number is stored in Parameter_1. The address of the
new peer is stored in the NEW_PEER attribute in the Parameters
field. The Parameters field can also have the following
attributes (see Section 5 for details)
PEER_CREDENTIAL: This attribute carries any information necessary
to carry out the key-exchange procedure. The meaning of the
payload is defined by the key-exchange procedure.
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
Bernardini, et al. Expires April 15, 2011 [Page 29]
Internet-Draft PPETP October 2010
(see Section 5 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 4.2.6.3 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 Extra field set
as follows
Extra=0 (OK) The handshaking procedure completed successfully and
the streaming toward the new lower peers has started.
Extra=1 (NO_Resource) The node has exhausted its share of upload
bandwidth and it cannot satisfy the request.
Extra=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 6).
Stop (SC=1) Stop sending data to the target specified in the packet.
The channel number is stored in Parameter_1 and the address of the
old peer is stored in the OLD_PEER attribute in the Parameters
field. The corresponding Acknowledge packet will have the Flags
field set as follows
Extra=0 (OK) No error, the streaming toward the lower peers has
stopped.
Extra=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 (SC=2) 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 addresses of the new
and old peer are stored, respectively, in the NEW_PEER and
OLD_PEER attributes in the Parameters field. As for the Start
sub-command, the channel number is stored in Parameter_1 and the
following attributes can be present: PEER_CREDENTIAL, PUNCTURING
and ROUTING_PROBABILITY. The corresponding Acknowledge packet
will have the Extra field set as follows
Bernardini, et al. Expires April 15, 2011 [Page 30]
Internet-Draft PPETP October 2010
Extra=0 (OK) No error, the streaming to the old lower peers has
stopped and the streaming to the new peer has started.
Extra=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 6)). The streaming to the old peer is nevertheless
stopped.
Extra=3 (NO_Target) The old peer is not a lower peer of the node.
No action is taken.
Punch (SC=3) This request asks the node to start a NAT traversal
procedure. Field Parameter 1 is to be interpreted as follows:
* The six least significant bits are a 6-bit value NAT_Method
that specifies the type of NAT traversal procedure to be used.
Any parameters for the specific NAT traversal procedure can be
stored in Parameter_2 and/or in the payload in the
NAT_PARAMETER attribute.
This document does not assign any value for NAT_Method. Value
NAT_Method=0 is assigned by [ppetp-ice] to an ICE-based
procedure. Other values for NAT_Method can be defined in the
future.
* The remaining two bits specify the action to be done after a
succesfull PUNCH procedure and can assume the following values
0 (Nothing) No further action is required.
1 (Start Too) After the PUNCH procedure is completed, start
the handshaking procedure of Section 6. In this case the
number of the channel is stored in Parameter_3, while other
parameters in the payload are interpreted as in the case of
Start sub-command.
Note that the attribute list associated to this command can
depend on the NAT traversal procedure. For example, the
ICE-based procedure of [ppetp-ice] produces as a result the
address to be contacted, so that it is not necessary to add
a NEW_PEER attribute (that would be required by the Start
subcommand).
The Flag field of the Acknowledge packet is to be
interpreted as the Flag field of the Send sub-command.
2 (Redirect Too) After the PUNCH procedure is completed, do a
Redirect. In this case it is necessary to include an
OLD_PEER attribute in the payload. The comments done for
Start Too apply also in this case.
Bernardini, et al. Expires April 15, 2011 [Page 31]
Internet-Draft PPETP October 2010
The Flag field of the Acknowledge packet is to be
interpreted as the Flag field of the Redirect sub-command.
3 (Reserved) This value is reserved
It should be emphasized that the Data_Control request is provided as
a convenient tool for flow control and it is not mandatory to do flow
control by using PPETP control packets, but, depending on the
application, flow control could be done via a suitable API. However,
in order to call the function for, say, starting a data flow toward a
lower peer, the node must receive a connection request and, depending
on the application, this could be difficult to achieve. The
availability of the Data_Control request, with the possibility of
routing control packets over a data stream (see Section 4.2.6), can
be an easy solution to this problem.
4.2.6. Routed control 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target PEER ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: ACK Target :
: (variable size, same format of the NEW_PEER attribute) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Routing header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Source signature (variable size) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source PEER ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Routing trailer
4.2.6.1. Motivation
Consider the following scenario: a P2P application with a small
number of peers (e.g., a conference) where the P2P network is managed
by a central server.
Bernardini, et al. Expires April 15, 2011 [Page 32]
Internet-Draft PPETP October 2010
Suppose that Alice is behind a NAT and that she contacts the server
to join the network. In order to exchange some control packets, the
server and Alice carry out a NAT traversal procedure that opens a
port for the communication Server-Alice.
Suppose now that after some time Bob contacts the server and suppose
that the server assigns Alice as an upper peer of Bob. Since Alice is
behind a NAT, Alice and Bob must do a NAT traversal procedure.
However, Alice does not know that Bob needs to communicate with her,
so the server must send to Alice a Data_Control/Punch request.
However, unless the server and Alice kept the NAT hole open, there is
a chance that the hole is now closed and Alice is unreachable from
the server too. The port could be kept open by sending Hello
packets, but this solution could pose scalability problems.
In order to to solve this and similar problems, PPETP allows to route
the control packets over the P2P structure using the features
described in this section.
4.2.6.2. Creating routed packets
In order to use this feature a node that wants to send a control
packet to another node must
1. Set the SSN field in the control packet header to zero (see
Figure 5)
2. Add the Routing header (see Figure 8) suitably filled. The
fields of the Routing header are
Target peer ID
The peer ID of the recipient of the routed packet
ACK Target The port and IP address where to send the
Acknowledge. This field has the same format of the Value
field of the attribute NEW_PEER (see Figure 11).
3. Set the RH Length to the length of the Routing header
4. Append to the packet (if required by the configuration) its own
source signature, followed by its own peer ID.
5. Append to the packet (if required) its own sender signature and
send the packet to its lower peers.
Bernardini, et al. Expires April 15, 2011 [Page 33]
Internet-Draft PPETP October 2010
4.2.6.3. Routing and acknowledging routed packet
A node that receives a packet with the RH Length field non zero (and
a valid Sender signature) must
1. Check (if needed) the Source Signature. If it is invalid,
discard the packet
2. Check the sequence number and the SSN of the packet. If this
packet was already processed, discard it.
3. Check the Peer ID of the target and
* If the node ID is equal to the target ID, the node processes
the request and sends the Acknowledge to the address specified
in the ACK Target field.
* If the node ID is not equal to the target ID, the node sends
the packet to its lower peers (signing it with the Sender
Signature, if required)
Note that a routed packet is acknowledged _only_ by the final target
peer to the node whose address is specified in the ACK Target field
and _not_ by the intermediate nodes that route the packet.
The procedure above is actually a "flooding" of the PPETP network and
one could suspect that this would cause an excessive load on the
network. However,
o It is expected that the rate of routed control packets will be
much smaller than the rate of data packets, so that the increase
in load is expected to be minimal.
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
Bernardini, et al. Expires April 15, 2011 [Page 34]
Internet-Draft PPETP October 2010
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).
4.2.6.4. Signing routed packet
Since the routing feature allows to send a packet to any node of the
network, many applications would prefer to reserve this feature only
to privileged nodes (e.g., servers). In order to avoid the
possibility that a non-privileged node sends control packets to non-
neighbors, a setup can request that the packet originator signs the
routed control packet.
The procedure to compute the source signature is specified by the
source signature profile. Currently only the source signature
profile "rabin" is defined (see Appendix C.2.2), but other can be
defined in the future.
4.2.6.5. Remarks
Few remarks about the rationale of the proposed structure are in
order
Direct acknowledgement. Note that the Acknowledge is sent back
directly to the source peer, without routing through the P2P
network. This requires that the source peer has a public IP. An
alternative approach could be routing the Acknowledge back to the
Source peer, having each peer to propagate the Acknowledge back to
the peers that sent it the original packet. However, this
solution has been discarded for the following reasons
* It is expected that this feature will be used mainly by servers
(with public IP address) that need to send control packets to
the nodes of the network.
* If this feature is needed also by non-privileged nodes, one can
setup a "reflector" node with a public IP address by using the
following approach
1. A non-privileged peer that needs to route a control packet,
sends the routed packet to the reflector.
Bernardini, et al. Expires April 15, 2011 [Page 35]
Internet-Draft PPETP October 2010
2. The reflector checks the signatures and that the control
packet is legitimate. If all the checks are positive, it
re-sends the packet with the Source Peer ID set to its own
Peer ID and adding its address in the ACK target field and
its own source signature.
3. The Acknowledge of the command will come back to the
reflector that will forward it (via routing) to the source
of the original control packet.
* If the back propagation of the Acknowledge packet was used, an
intermediate node could change the result contained in the
packet. Note that the Sender Signature is ineffective in
counteracting this since it grants for the identity of the
sender, but not for the packet content which is granted by the
source signature. However, checking the source signature
requires the knowledge of the public key of the source of the
Acknowledge packet (that is a node of the network) and this
could be not feasible in very large networks.
SubSeq_Num field The SubSeq_Num field has been introduced in order
to avoid a possible "flooding attack" where a node replicates
repetitively a legitimate routed control packet. Since the
control packet is legitimate, the source signature is valid and
the packet cannot be discarded by the signature checking
procedure. Since it is legitimate to send more than one time the
same control packet (if no Acknowledge is received), we cannot ask
the intermediate nodes to discard routed control packets with the
same sequence number. The solution is to "extend" the sequence
number with the SubSeq_Num field. Note that a node cannot
artificially increase the SubSeq_Num since this field is used to
compute the source signature.
4.3. Packet processing
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 and the RH Length field are checked in order to
find the type of the packet. If the packet is
Bernardini, et al. Expires April 15, 2011 [Page 36]
Internet-Draft PPETP October 2010
A data packet (Control=0, RH Length ignored):
+ The 64-bit header is parsed and stripped (so that only the
payload remains)
+ Any payload padding is removed
+ The payload is given to the reduction-profile specific
processing procedures.
A routed packet (Control=1, RH Length > 0):
The packet is processed as described in Section 4.2.6.3.
A control packet (Control=1, RH Length=0):
The padding (if present) is removed from the payload and the
packet is processed by an appropriate request handling
procedure.
5. PPETP Attributes
In PPETP some control requests encode their parameters as attributes
in the TLV format as follows (see also Figure 10)
o The first octet encodes the type of the attribute.
o The successive two octets encode the length of the value of the
attribute.
o The successive Length octets encode the attribute value. The
format depends on the specific attribute.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (Following length octets)
Figure 10: TLV format of PPETP attributes
Currently defined PPETP attributes are
NEW_PEER (Type=0) This parameter is used to transmit the address of
the new lower peer in the Start and Redirect sub-commands of the
Data_Control request. The value, whose structure is shown in
Figure 11, has the following fields
Bernardini, et al. Expires April 15, 2011 [Page 37]
Internet-Draft PPETP October 2010
Peer generalized address (variable size) The first part is the
generalized address of the peer. This field has variable size
and the format described in Section 3.8.
Peer ID The 32 bit peer ID
OLD_PEER (Type=1) This parameter is used to transmit the address of
a current lower peer in the Stop and Redirect sub-commands of the
Data_Control request. The value of this attribute has the same
structure of the value for NEW_PEER.
PEER_CREDENTIAL (Type=2) This parameter is used to transmit the
information that the upper peer needs in order to sign the packets
for the new lower peer. Its format and size is defined by the
signature profile employed in the PPETP session. For example, the
signature profile defined in this document computes the signature
using a secret key, shared between the upper and lower peer,
obtained via Diffie-Hellman. In this case the PEER_CREDENTIAL
attribute contains the public key of the new lower peer.
PUNCTURING (Type=3)
This attribute is used to set the puncturing rate and mode
associated to a lower peer (see also the description of the Start
subcommand in Section 4.2.5). The format of the value is shown in
Figure 12. The first octet determines the puncturing mode. As
said in Section 4.2.5, two possible modes are defined
Probabilistic puncturing (mode=0) The following two octets are
two unsigned 8-bit integers 0 <= Num <= 254, and 0 <= Den <=
255 (value Num=255 is reserved). Every time the node is going
to send a packet, it draws a random boolean with the
probability of getting true equal to (Num+1)/(Den+1). If the
result is true, the packet is sent; otherwise it is discarded.
If Num >= Den, all the packets are sent.
Deterministic puncturing (mode=1) The second octets is an 8-bit
integer M, the other octets are interpreted as 8-bit integers
Val_1, Val_2, ..., Val_N. With this mode a packet with sequence
number S is sent if and only if S = Val_i (mod M+1) for some i.
This is almost equivalent to transmitting the packets with a
probability equal to N/(Mod+1).
NAT_PARAMETER (Type=3) The value is an opaque sequence of octets
that is passed as-it-is to the NAT traversal procedure.
Bernardini, et al. Expires April 15, 2011 [Page 38]
Internet-Draft PPETP October 2010
ROUTING_PROBABILITY (Type=4) The payload is a pair of octets to be
interpreted as a probability, as explained under "Probabilistic
puncturing" above and represents the probability of sending a
routed packet to a given lower peer.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Generalized Address :
: (variable size) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Value for NEW_PEER and OLD_PEER attributes
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) |0 0 0 0 0 0 0 0| Num | Den |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(b) |0 0 0 0 0 0 0 1| Mod | Val 1 | ...up to Val N
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a) Format for probabilistic puncturing (b) Format for deterministic
puncturing
Figure 12: Value of the PUNCTURING attribute
6. Peer handshaking procedure
A node that wants to start sending a reduced stream to a new lower
node will carry out the following handshaking procedure
1. Send a Set_Default command to the new lower peer and wait for an
Acknowledge (following the guidelines in Section 4.2.3)
2. If the Set_Default request is successfully concluded (i.e., a
positive acknowledge arrived), the handshaking is successfully
concluded and the streaming of data packets begins.
Bernardini, et al. Expires April 15, 2011 [Page 39]
Internet-Draft PPETP October 2010
3. If the Set_Default request failed (i.e., no acknowledge or a
negative one arrived), the handshaking terminates with a failure
and the streaming of data packets does not begin.
7. 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., by querying a
distributed hash table).
7.1. Bootstrap configuration protocol
As said in Section 3.1, a PPETP session may be referred to by a pair
(IP_address, session_ID) where the IP_address is the address of a
host queried to get configuration data. This section describes the
protocol used for the query.
Bernardini, et al. Expires April 15, 2011 [Page 40]
Internet-Draft PPETP October 2010
7.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.
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. The server's policies require that the client must authenticate
itself, so the server sends a reply with an error code that
requests an authentication. The reply includes a "nonce" used to
divert re-play attacks and an "authentication realm".
3. The client repeats the request, but this time it includes its
credential, the nonce and a signature.
4. The server checks the signature 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 (e.g., if the server needs to know the
upload bandwidth of the client or any public key used to sign
the packets), 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 April 15, 2011 [Page 41]
Internet-Draft PPETP October 2010
7.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 7.1.2.3.3
o The successive length octets are the value of the attribute.
7.1.2.1. Query packet
Figure 13 show the structure of the header of a query packet.
o The first 16 bits contain the ID of the desired PPETP session
(that is, the "pseudo-port" in the PPETP "pseudo-address")
o The bits from 16 to 23 (3rd octet) are a sequence number that
uniquely identify the request. The configuration server will copy
the Query_Number into the response packet, so that the client can
match a response with the corresponding request.
o The bits from 24 to 26 (part of the 4th octet) are the protocol
version and it is equal to the minimum between the protocol
version understood by the client and the protocol version
understood by the server. If the server protocol version is
unknown (because this is the first time that we contact the
server), this field is equal to the client protocol version.
o The bits from 27 to 31 are the magic number 3 (decimal). This
field can be used to distingush between configuration packets,
normal PPETP packets and ICE packets. (Similarly to what happens
with ICE, query/response packets are sent/received from the same
port used by PPETP.)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session_ID | Query_Number | V | Magic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Header of a query packet
Bernardini, et al. Expires April 15, 2011 [Page 42]
Internet-Draft PPETP October 2010
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
Appendix B.2).
7.1.2.2. Response packet
In response to a query the configuration server replies with a
response packet. The content of the response packet can be one of
the following
o A request for user authentication. This type of reply is sent
both if the authentication part is missing or not acceptable by
the server (e.g., because it uses a stale nonce).
o A redirection request that asks the client to use a different
protocol and/or a different host.
o The required configuration data. Given the very basic nature of
the protocol, it is expected that this case will happen only in
the simplest applicative contexts.
Figure 13 show the structure of the header of a response packet. The
error code is stored in the first 16 bits, the third and the fourth
octects are interpreted as in the request packets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error_code | Query_Number | V | Magic |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Header of a response packet
The Error_Code field can assume the following values
200 (OK) The request was processed succesfully and the configuration
data are stored in the attribute CONTENT. The format of CONTENT
is described in the attribute CONTENT-TYPE.
Bernardini, et al. Expires April 15, 2011 [Page 43]
Internet-Draft PPETP October 2010
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.
7.1.2.3. Attributes
This section lists the defined attributes. Numerical values for the
attributes are given in Table 2.
ACCEPTED-PROTOCOLS The value of this attribute is a list of 15-bit
integers encoded as described in Section 7.1.2.3.3. Each integer
identifies a configuration protocol implemented by the client.
Bernardini, et al. Expires April 15, 2011 [Page 44]
Internet-Draft PPETP October 2010
PROTOCOL The protocol that the client must use to get configuration
data. It is a 15-bit integer encoded as described in
Section 7.1.2.3.3.
PARAMETER Generic attribute. Its value is to be used as parameter
of the configuration protocol given in PROTOCOL and its meaning
depends on the specific protocol. More than one PARAMETER
attribute can be present in the same reply.
For example, if PROTOCOL refers to an HTTP-based protocol, the
first parameter could be an URL to be queried for the
configuration data. Other parameters could include, for example,
some type of credential.
ACCEPTED-CONTENT The value of this attribute is a list of 15-bit
integers encoded as described in Section 7.1.2.3.3. Each integer
identifies a configuration descriprion format understood by the
client.
CONTENT-TYPE This attribute is used when the configuration data is
included in the reply. Its value is a 15-bit integer encoded as
described in Section 7.1.2.3.3. This field MUST be present if and
only if the error code is 200.
CONTENT The value of this attribute is the configuration
description. The format of this attribute depends on the value of
CONTENT-TYPE. This field MUST be present if and only if the error
code is 200.
USERNAME This field identifies the username and password combination
used to generate the signature. Its value MUST be UTF-8 [RFC3629]
encoded sequence of less than 63 bytes, and MUST have been
processed using SASLprep [RFC4013].
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.
Bernardini, et al. Expires April 15, 2011 [Page 45]
Internet-Draft PPETP October 2010
REMOTE-NONCE This field is filled with a verbatim copy of the
attribute USE-NONCE.
LOCAL-NONCE When one of the parts wants to authenticate itself, it
MAY add this attribute whose meaning and objective is similar to
the "cnonce" field in [RFC2617]
ACCEPTED-ALGORITHMS The value of this attribute is a list of 15-bit
integers encoded as described in Section 7.1.2.3.3. Each integer
identifies a signature computing algorithm that the node (client
or server) can use.
ALGORITHM This attribute is a a 15-bit integer encoded as described
in Section 7.1.2.3.3 and specifies the algorithm used to compute
the value in the field SIGNATURE.
USE-ALGORITHM This attribute is a a 15-bit integer encoded as
described in Section 7.1.2.3.3 and specifies the algorithm to use
in the computation of the value in the field SIGNATURE. If this
field is missing, algorithm HMAC described here is used.
ACCEPTED-HASHES Many authentication algorithms make use of hash
functions. The value of this attribute is a list of 15-bit
integers encoded as described in Section 7.1.2.3.3. Each integer
identifies a hash function that the node (client or server) can
use.
HASH This attribute is a a 15-bit integer encoded as described in
Section 7.1.2.3.3 and specifies the hash function used.
USE-HASH This attribute is a a 15-bit integer encoded as described
in Section 7.1.2.3.3 and specifies the hash function to be used in
the computation of the value in the field SIGNATURE. If this
field is missing, algorithm MD5 is used.
SIGNATURE This attribute, if present, MUST be the last one. A
packet having this field in a different position MUST be discarded
and if the packet is a query packet the server must reply with an
error code 400. This field is computed by using the algorithm
specified in the attribute ALGORITHM.
REASON The reason phrase is meant for user consumption, and can be
anything appropriate for the error code. The reason phrase MUST
be a UTF-8 [RFC3629] encoded sequence of less than 128 characters
(which can be as long as 763 bytes).
Bernardini, et al. Expires April 15, 2011 [Page 46]
Internet-Draft PPETP October 2010
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 same format of
attribute NEW_PEER 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.
+---------------------+-------+
| Name | Value |
+---------------------+-------+
| ACCEPTED_PROTOCOLS | 0 |
| PROTOCOL | 1 |
| PARAMETER | 2 |
| ACCEPTED_CONTENTS | 3 |
| CONTENT_TYPE | 4 |
| CONTENT | 5 |
| USERNAME | 6 |
| REALM | 7 |
| USE_NONCE | 8 |
| LOCAL_NONCE | 9 |
| REMOTE_NONCE | 10 |
| ACCEPTED_ALGORITHMS | 11 |
| ALGORITHM | 12 |
| USE_ALGORITHM | 13 |
| ACCEPTED_HASHES | 14 |
| HASH | 15 |
| USE_HASH | 16 |
| SIGNATURE | 17 |
| REASON | 18 |
| UNKNOWN_ATTRIBUTES | 19 |
| SOCK_ADDR | 20 |
+---------------------+-------+
Table 2: Values associated to attribute types
7.1.2.3.1. Packet signing
This configuration protocol allows both actors (client and server) to
request the authentication of the other. The client decides to send
a signed query for the following reasons
o A reply packet with the attribute USE-NONCE was received.
Typically the error code associated to the reply packet will be
Bernardini, et al. Expires April 15, 2011 [Page 47]
Internet-Draft PPETP October 2010
Unauthorized (401) or Stale Nonce (438).
o Spontaneously. This can happen, for example, if the client
receives the nonce in an SDP attribute.
The server signs a packet if
o The request packet includes a USE-NONCE attribute AND
o the request packet includes a valid user signature
It is strongly suggested that, in order to make DoS attacks more
unlikely, the server should not reply with signed replies to non-
signed requests.
The procedure to create a signed packet is the following
1. A packet signed by the client MUST contain at least the attribute
USERNAME.
2. The value of USE-NONCE (if present) is copied in the attribute
NONCE. The value of attribute REALM (if present) is copied in
the packet.
3. Attribute LOCAL-NONCE is added.
4. If necessary, attributes ALGORITHM and HASH are set.
5. The packet, completed with any other attribute related with the
query, is processed together the value of USERNAME and REALM to
obtain a string of bits. The resulting string of bits is used as
value of the attribute SIGNATURE.
7.1.2.3.2. 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
Bernardini, et al. Expires April 15, 2011 [Page 48]
Internet-Draft PPETP October 2010
procedure described in [RFC2104] and it is parametrized by the hash
function to be used.
1. With reference to [RFC2104], the value of "text" is the whole
packet to be signed, without the SIGNATURE attribute (that MUST
be the last one)
2. Still with reference to [RFC2104], the value of key "K" is
obtained from the shared secret S as follows
K=H(S | NONCE)
where H is the chosen hash function, NONCE is the value of the
attribute USE-NONCE and "|" denote bitstring concatenation.
7.1.2.3.3. 15-bit integers encoding
Several attributes encode algorithms, formats and protocols as
integer numbers that can use at most 15 bits. Since it is reasonable
to expect that the number of protocol, algorithms or formats defined
in the future will be much smaller than 100, it was decided to use a
format that allows to store efficiently values up to 127, while
allowing values up to 32767.
The value is stored in one or two consecutive octets as follows.
1. Let b1 and b2 the two octets and let 0 <= N < 32768 the value to
be encoded.
2. If N < 128, N is stored in b1 and b2 is unused
3. If N >= 128, value 128 + (N mod 128) is stored in b1 and value
N/128 is stored in b2.
In other words, the most significant bit of b1 is used as a flag: if
it is zero, it means that N was smaller than 128 and only b1 is used;
otherwise N was larger or equal than 128 and both b1 and b2 are used.
For example, the sequence of integers 112, 42, 260, 33 would be
encoded in the sequence of octets
112 42 132 2 33
Note that 132 = 128 + (260 mod 128) and 2 = 260/128.
7.1.3. 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.
Bernardini, et al. Expires April 15, 2011 [Page 49]
Internet-Draft PPETP October 2010
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 much compact as possible.
For example, no "=" is inserted after the first character of the
line, lines end with only LF (not CRLF) and numbers are in
hexadecimal.
The line types that can be used in the CCDF are can be found in the
following list; the 3-character label between square brackets [...]
has the following meaning: "*" marks the lines that are mandatory,
"+" marks the lines that can appear more than once, "a" marks the
lines that can be followed by any number of attribute lines
o "s"[* ]: stream line
o "p"[* a]: profile line
o "Y"[ ]: informations about the node itself ("Y" is for "Yourself")
o "C"[ +a]: informations about the channels opened by the node ("Y"
is for "Yourself")
o "c"[ +a]: connection line(s)
o "a"[ + ]: attribute line(s)
o "f"[ a]: peer search method ("f" is for "find")
o "n"[ +a]: peer line(s) ("n" is for "node")
o "k"[ +a]: security related data (e.g., public keys)
o "P"[ +a]: security policies
o "X"[ ]: Data puncturing lines
o "x"[ ]: Routing puncturing lines
ccdf = *1stream-line
profile-line
*1self-line
*channel-line
*connection-block
(*1find-line / *peer-block)
*policy-line
Bernardini, et al. Expires April 15, 2011 [Page 50]
Internet-Draft PPETP October 2010
stream-line = %x73 *1(stream-id *(SP stream-id)) EOL ; 's'
stream-id = integer
profile-line = %x70 profile-name *(SP parameter) EOL ; 'p'
profile-name = identifier
profile-parameter = token
self-line = %x59 peer-id n-channels self-stream-ids EOL ; 'Y'
peer-id = int32 / "*"
n-channels = HEXDIGIT / "*"
self-stream-ids = *(SP integer) *1others-id
others-id = "*" *1integer
channel-line = %x43 *1repeat *(SP parameter)
*attribute-line
repeat = "*" integer
connection-block = %x63 connection-type *1("@" label)
*(SP parameter) EOL ; 'c'
*attribute-line
connection-type = identifier
label = identifier
find-line = %x66 method *(SP parameter) EOL ; 'f'
*attribute-line
peer-block = %x7e node-type node-id *channels ; 'n'
(connection-body EOL / EOL connection-block)
*1data-punct-line
*1ctl-punct-line
*key-line
connection-body = SP connection-type *(SP parameter) / "@" label
node-type = %x65 / %x6f / %x75 ; 'l', 'o', 'u'
node-id = int32
channels = HEXDIGIT *1("-" HEXDIGIT)
data-punct-line = (rand-punct / mod-punct) EOL
rand-punct = %x52 num den ; 'R'
mod-punct = %x4D modulus 1*byte ; 'M'
num = byte
den = byte
modulus = byte
ctl-punct-line = %x78 num den EOL ; 'x'
Bernardini, et al. Expires April 15, 2011 [Page 51]
Internet-Draft PPETP October 2010
key-line = %x6b method *(SP parameter) EOL ; 'k'
*attribute-line
policy-line = %x50 capability ":" allowed *(SP allowed)
*1(";" parameter *(SP parameter)); 'P'
capability = identifier
allowed = "all" / "none" / "neigh" / node-id
attribute-line = %x61 attr-name "=" attr-value EOL ; 'a'
attr-name = identifier
attr-value = *%x20-7E
parameter = token
EOL = LF
byte = HEXDIGIT HEXDIGIT
int16 = 4*4HEXDIGIT
int32 = 8*8HEXDIGIT
integer = 1*HEXDIGIT
identifier = ALPHA *id-char
id-char = ALPHA / DIGIT / "-" / "_"
token = 1*VCHAR
no-lf-chars = %x00-%x09 / %x0b-%xff
ABNF grammar for the CCDF
The meaning of the lines is the following
o Stream line ("s"). The parameters on this line are the ID of the
streams that are allowed to circulate. If no parameter is present
or this line is missing, any ID is allowed. Nodes should discard
any packet whose stream ID does not belong to the set of
admissible ones.
o Profile line ("p"). The first parameter on this line is the name
of the reduction profile to be used, the meaning of any following
parameter is defined by the profile. This line can be followed by
any number of attribute lines. The admissible attributes and
their meaning is defined by the profile. For example, with the
vandermonde profile (defined in this document) the first parameter
is the reduction factor (equivalent attribute: red-fact) and the
second parameter is the number of bytes necessary to represent an
element of the Galois field employed (that is, if n is the value
of the second parameter, the size of the Galois field is 2^(8*n)).
The attribute equivalent to the second parameter is gf-size. The
basic profile defines no paramters.
Bernardini, et al. Expires April 15, 2011 [Page 52]
Internet-Draft PPETP October 2010
o Self information ("Y"). The first parameter of this line is the
ID assigned to the node or the character '*'; in the latter case,
the node will choose the ID by itself. The second parameter is
the number of output channels to be open by the node; if its value
is '*' it means that the number of channels is the number of 'C'
lines that follows. The following parameters are the stream ID
that the node can produce and are to be interpreted as follows
* If no further parameter are present, the node cannot produce
any stream.
* If a list of integers is present, each integer is the stream ID
of a stream that the node can produce.
* The line can end with a single asterisk or an asterisk followed
by an integer. In the former case, the node is allowed to
produce as many stream as it needs and the IDs will be chosen
by the node itself; in the latter case, if n represents the
value of the integer, the node is allow to produce n more
stream and the IDs will be chosen by the node itself.
For example, the following line
Y0123abcd* af2 bc00 d6*2
assigns the peer ID 0x0123abcd to the node, asks to the node to
open a number of channels equal to the number of 'C' lines that
follows and allows the node to produce five streams: three streams
have stream ID af2, bc00 and d6, the ID of the other two streams
will be chosen by the node.
o Output channels ("C"): This type of line specifies the reduction
parameters to be used for the channel to be opened by the node.
The n-th C-line refers to the channel number n-1 (since channel
numbers start from 0). The parameters can be specified, similarly
to the profile line, as positional parameters or attributes. The
meaning of the parameters is defined by the reduction profile. If
the line begins with an asterisk followed by a number, the number
represents the number of time that this line and the following
attribute listmust be "virtually" repeated. For example, the
following description
C
aredundancy=4/3
C*2
aredundancy=5/3
C
aredundancy=1/1
Bernardini, et al. Expires April 15, 2011 [Page 53]
Internet-Draft PPETP October 2010
requires the node to open four channels: channel #0 will have the
(fictional) parameter "redundancy" set to 4/3, channels #1 and #2
will have the same parameter set to 5/3 and channel #3 will have a
redundancy equal to 1/1.
o Connection ("c"). This type of lines specifies a generalized
address. This line can appear by itself or as part of a peer-
block. If the line is stand-alone the "label" field (described in
the following) is mandatory. The first parameter on this line
identifies the address class. This document defines two classes
(ice and ip), but more classes can be defined in the future. If
the first character after the address type is a '@', then the
identifier that follows is a label assigned to the address. The
label can be used to refer again to the same address in the same
description. The parameters necessary for the connection can be
given both as positional parameters or as attributes. The
parameters associated with a given address type are defined by the
document describing the address type.
o Peer searching ("f"). The list of the upper peers can be included
in the description by the "n"-lines. Alternatively, it is
possible to say to the node how to search for new peers by using
an "f"-line. Similarly to the profile line, the first parameter
identifies the specific method and parameters for the method can
be specified both on the same line or as attribute values.
o Peer line ("n"). This line describes a peer of the node.
* The first parameter is only one character long and it denotes
the peer type: 'u' for upper, 'l' for lower and 'o' for other.
The latter type includes those nodes that need to communicate
with the node (e.g., the bridge node in the ICE-based NAT-
transversal) without being neither upper nor lower peers.
* The second parameter is the peer id of the remote node
* An optional list of channel numbers separated by comma follows.
The range of channel between n and m can be abbreviated as
"n-m". This field is to be interpreted as follows
+ If the node type is 'o' no channel number must be given.
+ If the node type is 'u', the channel fiels is the set of
channel to be required to the upper peer
+ If the node type is 'l', the channel fiels is the set of
channel to be sent to the lower peer
Bernardini, et al. Expires April 15, 2011 [Page 54]
Internet-Draft PPETP October 2010
If node type is 'l' or 'u' and no channel number is present,
channel #0 is implied.
* The generalized address of the peer can follow. This can be
given as a connection-body or as a '@' followed by the label
assigned to a previous 'c'-line. Alternatively, this field can
be omitted and the generalized address be given as a 'c' line
inside the peer block.
A 'c' line can follow with the generalized address of the node.
The 'c' line and the inline address specification are mutually
exclusive. Finally, one or more 'k'-lines with cryptographic
informations can follow.
o Security policies ("P" line). This line specifies who can do
what. The first parameter is the name of a "capability" that
identifies a specific action. Following the capabilities one
finds the list of the peers that are authorized to do that action.
Each peer is identified by its peer ID. Moreover, the keywords
"all" (everyone can do the action), "none" (noone can do the
action) and "neigh" (only the "neighboors" of the node, i.e. lower
and upper peers, can do the action) can be used.
o Attribute ("a"). This line can be used to assign parameter values
in a "nominal" way. The attribute name is separated by the value
by an equal sign. The attribute value is represented by the
string of characters between the '=' and the end of line. How
this value is to be interpreted is defined by the attribute.
o Security related data ("k" line).
8. ICE-based Connection Establishment Procedure
PPETP allow to incorporate connection establishment procedures (CEPs)
via the idea of _generalized address_ explained in Section 3.8. As
anticipated there, this document defines the _ip_ class of
generalized address and an _ice_ class that uses ICE [RFC5245] to
establish the connection between the nodes. This section explains in
the detail how the connection is established.
8.1. Overview
This NAT-traversal profile uses ICE [RFC5245] to achieve the
connectivity between two nodes. For the sake of clarity, it is worth
to give a (very brief) overview of ICE.
o In ICE a peer has one or more "candidate addresses" that can be
used to receive data. ICE partitions the possible candidates in
Bernardini, et al. Expires April 15, 2011 [Page 55]
Internet-Draft PPETP October 2010
HOST candidates (address associated to the network interface of
the node), SERVER and PEER REFLEXIVE candidates (roughly, the
address associated to the node by the most external NAT) and
RELAYED addresses (the address associated by a TURN server to the
node).
o Two nodes that want to establish a connection with ICE do the
following step
1. Each node gathers all its possible candidate addresses
2. The two nodes exchange the lists of candidates
3. The two nodes try all the possible pair of candidates to find
one that works
o The packets exchanged between the two nodes are STUN packets.
The description above is a very rough one, but it suffices for our
needs.
In the ICE implementation used in PPETP
o The nodes are triggered in collecting candidate addresses by the
reception of a suitable control packet. The packet will include a
transition ID, an optional address of a STUN/TURN server and the
address of a "bridge" server.
o Each node sends its candidates, together with the transaction ID,
to the bridge server. The data are sent in a Data_Control/Punch/
ICE PPETP packet.
o The bridge server checks the correctness of the transaction ID and
send to each node the candidates of the other (still using PPPETP
control packets).
o The reception of the packet with the candidate addresses trigger
the node to execute the ICE checks and find a suitable pair to
communicate
8.1.1. Determining ICE role
In the ICE procedure the two peers play asymmetric roles: one agent
is "controlling" and the other is "controlled". The ICE
specifications give rules to determine which agent is the controlling
one (see Section 5.2 of [RFC5245]). In some case the criterion used
to determine the controlling agent is that the agent that generated
the offer must take the controlling role. Since in the PPETP case it
Bernardini, et al. Expires April 15, 2011 [Page 56]
Internet-Draft PPETP October 2010
could not be clear who generated the offer, we replace the condition
of having generated the offer with the condition of being the lower
peer.
8.2. Punch payload format
The data necessary to the ICE procedure are carried in the attribute
NAT_PARAMETER in the payload of the Data_Control/Punch command. The
first octet determines the specific command, the other parameters are
given as a sequence of attributes in TLV format described in
Section 8.3. The following command are defined
COLLECT (Command=0) When a peer receives this command collects its
candidate addresses and send them to the bridge server. The
parameter list of this command MUST include at least a
BRIDGE_SERVER and a TRANSACTION_ID attribute; it can include a
ICE_SERVER attribute with the address of a STUN/TURN server that
can be used to collect the candidates. If the BRIDGE_SERVER acts
also as a STUN/TURN server, the address can be sent only once by
setting the appropriate flags in the XTR field in the server
address (see the description of the BRIDGE_SERVER attribute in
Section 8.3). The node will send the candidate list to the bridge
server by using a CANDIDATES command.
CANDIDATES (Command=1) This command can be sent from the bridge to
the peer or the other way around. Its parameter list includes
attribute TRANSACTION_ID and one or more CANDIDATE_ADDR. The
effect of this command depends on who receives it
* If the command is received by the bridge server, the server
checks the validity of the TRANSACTION_ID. If the check is
positive, stores the result until it has the candidate list of
both peers. When both lists have been received, the bridge
sends the candidate list of a peer to the other by using a
CANDIDATES command.
* If the command is received by the peer, the peer starts the
connection establishment procedure of ICE with the remote peer.
The result of the procedure will be a remote address to be used
to communicate with the remote peer.
8.3. ICE-related attributes
The following ICE-related attributes are defined
Bernardini, et al. Expires April 15, 2011 [Page 57]
Internet-Draft PPETP October 2010
TRANSACTION_ID (Type=0): The payload is an opaque 64-bit ID that
identifies a specific transaction. For the sake of security, the
ID should be unpredictable. The ID is expected to be generated by
some entity external to the network (e.g., a subscription server).
BRIDGE_SERVER (Type=1): The payload has the same format of the
NEW_PEER and OLD_PEER attributes (see Figure 11), but with the bit
of field EXT with the following meaning
Double_Role (bit 7) If this bit is set, the bridge server acts
also as a STUN/TURN server (depending on the value of bit STUN/
TURN). The port to be used for STUN/TURN operation is the
well-known STUN port 3478. If, for some reason, a different
port is needed an attribute STUN_TURN_SERVER must be used.
STUN/TURN (bit 8) If bit Double_Role is zero, this bit is
ignored; otherwise, if it determines if the bridge server acts
as a STUN (bit set to 0) or TURN (bit set to 1) server.
STUN_TURN_SERVER (Type=2) The payload has the same format of the
NEW_PEER and OLD_PEER attributes (see Figure 11) and it contains
the address of a STUN/TURN server. The type of server is
determined by the STUN/TURN flag in the EXT field, as described
for the BRIDGE_SERVER attribute.
CANDIDATE (Type=3) The payload of this command contains all the
necessary candidate informations. The structure of the payload is
as shown in Figure 15 The fields have the following meaning
Foundation (bits 0-15) A 16-bit value representing the address
foundation
Component (bits 16-23) A 8-bit value (interpreted as an integer
between 1 and 256, therefore the "all zer" value is to be
interpreted as 256) which identifies the component.
Component Type (CT, bits 24-26) The type of candidate address.
The following values are defined: CT=0 for an host candidate,
CT=1 for a server reflexive candidate, CT=2 for a peer
reflexive candidate and CT=3 for a relayed candidate; other
values are reserved for future extensions.
Priority (bits 31-63) A 32 bits value that represents the ICE
priority.
Bernardini, et al. Expires April 15, 2011 [Page 58]
Internet-Draft PPETP October 2010
Candidate Address (variable size) This field has the same format
(shown in Figure 11) of the NEW_PEER and OLD_PEER attributes.
Note that this field includes also port and transport.
Related Address (variable size) This field is present only for
non-host candidates (i.e., if and only if CT is not zero) and
represents the transport address related to the candidate,
according to [RFC5245].
CREDENTIALS (Type=4) The payload of this command is a 26-octet
string with the parameters ice-ufrag (first 4 octets) and ice-pwd
(remaing 22 octets) of [RFC5245]. Since ice-ufrag and ice-pwd can
be shorter than, respectively, 4 and 22 octets, any unused octet
is set to zero.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Foundation | Component | CT | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Candidate Address (variable size) :
: (64 bits with UDP over IP4, 160 bits with UDP over IP6) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Related Address (variable size, present if CT != 0) :
: (64 bits with UDP over IP4, 160 bits with UDP over IP6) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15
9. Security Considerations
9.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.2, 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
Bernardini, et al. Expires April 15, 2011 [Page 59]
Internet-Draft PPETP October 2010
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.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. 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.2).
In order to avoid this situation it is important that only trusted
nodes are allowed to do a "full service".
9.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 could 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.
Bernardini, et al. Expires April 15, 2011 [Page 60]
Internet-Draft PPETP October 2010
9.2. Defamatory attack
As said in Section 9.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.
10. IANA Considerations
10.1. Address classes registry
It is expected that every class will be associated with an algorithm
that from the parameters of the generalized address determines a set
of parameters that can be used to contact the other node (typically,
an IP address and a port). For example, the algorithm associated
with the ice class takes the address of the bridge node (see
Section 8) and determines an IP address, a port and, eventually, a
local interface to be used to send data to the other peers.
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.
10.2. NAT Traversal procedure registry
This document defines a 7-bit NAT_Method field, for which IANA is to
create and maintain a new registry named "PPETP NAT Traversal
Procedure Code" (PPETP-NTPC). Initial assignments are given below,
unassigned values are to be assigned by IETF Consensus.
Bernardini, et al. Expires April 15, 2011 [Page 61]
Internet-Draft PPETP October 2010
Value PPETP-NTPC Name Definition
------- --------------- ---------------
0 Reserved
1 ICE-based See [ppetp-ice]
2-123 Unassigned
124-126 Experimental
127 Reserved
11. References
11.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.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real
Time Streaming Protocol (RTSP)", RFC 2326,
April 1998.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J.,
Lawrence, S., Leach, P., Luotonen, A., and L.
Stewart, "HTTP Authentication: Basic and Digest
Access Authentication", RFC 2617, June 1999.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Retransmission Timer", RFC 2988, November 2000.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and
V. Jacobson, "RTP: A Transport Protocol for Real-
Time Applications", STD 64, RFC 3550, July 2003.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley,
M., and E. Schooler, "SIP: Session Initiation
Protocol", RFC 3261, June 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for
Bernardini, et al. Expires April 15, 2011 [Page 62]
Internet-Draft PPETP October 2010
User Names and Passwords", RFC 4013,
February 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
March 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP:
Session Description Protocol", RFC 4566,
July 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 5226, May 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity
Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal for Offer/
Answer Protocols", RFC 5245, April 2010.
11.2. Informative References
[DCC08] Bernardini, R., Rinaldo, R., and A. Vitali, "A
Reliable Chunkless Peer-to-peer architecture for
multimedia streaming", proc. Data Compression
Conference, Snowbird, Utah pages 242-251,
march 2008.
[RABIN] Rabin, M., "DIGITALIZED SIGNATURES AND PUBLIC-KEY
FUNCTIONS AS INTRACTABLE AS FACTORIZATION", 1979.
[IPTV] Hei, X., Liu, Y., and K. Ross, "IPTV over P2P
Streaming Networks: The Mesh-Pull Approach", IEEE
Communications Magazine Vol 46, N. 2, 86-92,
February 2008.
[ppetp-xml-config] Bernardini, R., Cesco Fabbro, R., and R. Rinaldo,
"XML format for Peer-to-Peer Epi-Transport
Protocol configuration description", April 2010.
[ppetp-ice] Bernardini, R., Cesco Fabbro, R., and R. Rinaldo,
"ICE connection establishment for the Peer-to-
Peer Epi-Transport Protocol", April 2010.
Appendix A. Examples
This non-normative section contains some examples of possible
applicative contexts for PPETP.
Bernardini, et al. Expires April 15, 2011 [Page 63]
Internet-Draft PPETP October 2010
Warning: The following examples suppose that some protocols (e.g.,
RTSP, SDP) have been extended to adapt them to PPETP. At the time
of writing, those supposed extensions are only hypotetical and it
could happen that they will never be added to the protocols,
making the examples in this section not enterly correct. However,
the goal of this section is not to be normative, but to show some
examples of how PPETP _could_ be used in multimedia applications.
A.1. Live media
This example considers a live streaming application, with a single
source and a possibly large number of users. Most of users are of
the "residential" type and behind NATs.
In this example we suppose that Bob (B), that has an account with a
streaming service provider, wants to receive a live concert streamed
over PPETP. We suppose that Alice (A) is already connected to the
network. Alice and Bob are (possibly) behind NATs and they implement
the ICE-based NAT traversal profile described in [ppetp-ice]. The
network topology is managed by a central server (belonging to the
streaming service provider) denoted in the following with the letter
N (as network manager).
The "starting point" of Bob is a web page at the web server (W)
www.example.com; the web page contains a link to the media server (M)
with the content description
B->W: GET /sessions.html HTTP/1.1
HOST: www.example.com
W->B: HTTP/1.1 200 OK
Content-Type: text/html
Best concert ever
When Bob clicks on the link Tthe web browser launchs a "viewer" (an
external program or a plugin) that contacts the RTSP server.
Bernardini, et al. Expires April 15, 2011 [Page 64]
Internet-Draft PPETP October 2010
B->M: DESCRIBE rtsps://live.example.com/concert RTSP/2.0
CSeq: 1
M->B: RTSP/2.0 200 OK
CSeq: 1
Content-Type: application/sdp
... other headers ...
v=0
... other SDP lines ...
c=IN IP4 ppetp.example.com
... other SDP lines ...
m=video 12345 RTP/AVP/PPETP 34
a=control: rtsps://live.example.com/concert/video
The SDP description of the streaming session shows that the video is
streamed over PPETP (see the m= line). The configuration server is
ppetp.example.com (see c= line) and the session ID is 12345 (see m=
line). Because of this Bob's agent opens (via a suitable API) a
local "PPETP socket" and configures it by calling a pseudo-connect()
with the pseudo-address (ppetp.example.com, 12345) as a parameter.
The pseudo-connect() will send a query packet (see Section 7.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.
Bob's agent asks to Bob a username/password pair valid for realm
"example" and reformulates the query to ppetp.example.com.
Bernardini, et al. Expires April 15, 2011 [Page 65]
Internet-Draft PPETP October 2010
B->C (12345, 1 | NONCE=98765, REALM=example,
USERNAME=bob, USE-NONCE=88888,
LOCAL-NONCE=11111, SIGNATURE=23xgajdav)
C->B (300, 1 | REALM=example, USERNAME=bob,
NONCE=88888, LOCAL-NONCE=25252,
PROTOCOL=https,
PARAMETER=netmanager.example.com/12345?q=da...c23,
SIGNATURE=daghj391)
In this example Bob sends a new request (note the increased request
number) adding to it the signature. Bob also requests the server to
authenticate itself by adding the USE-NONCE attribute. The server
checks the signature and replies with an error code 300 (Try other)
to redirect Bob to a more complex configuration protocol based on
HTTP.
Bob sends a POST request to the network manager (N) specified in the
PARAMETER attribute
Bernardini, et al. Expires April 15, 2011 [Page 66]
Internet-Draft PPETP October 2010
B->N: POST 12345?q=da...c23 HTTP/1.1
Host: netmanager.example.com
... other headers ...
N->B: HTTP/1.1 200 OK
... other headers ...
Content-type: application/ppetp-xml-config
dh/oakley4/GQ23n4ccx...
... other upper peers ...
Note that the configuration manager can communicate with the network
manager via the request path. In this case the path is simply the
session ID with an opaque query string that (one can suppose) encodes
Bernardini, et al. Expires April 15, 2011 [Page 67]
Internet-Draft PPETP October 2010
informations about Bob such as the type of subscription of Bob, the
upload bandwidth that it can provide and so on.
The network manager, as a consequence of the POST request of Bob,
assigns to Bob a set of upper peers. It is reasonable to expect that
the network manager will use, for example, the type of subscription
to decide how many upper peers to assign to Bob and that maybe the
assignment is done in order to optimize some figure of merit such as
locality.
In the example, the configuration data is sent to Bob in XML format
with the syntax defined in [ppetp-xml-config]. The configuration
data contains information such as the reduction profile employed, the
signature profiles employed and the list of upper peers. (In a setup
with a distributed peer search, the configuration data could include,
for example, a list of addresses of bootstrap nodes for the peer
search.) Note that the server does not specify the "reduction-base"
parameter, so the node will choose one at random. Because of this, a
large Galois field is employed (2^32 elements), in order to make the
probability that two nodes choose the same reduction-base negligible.
Note that because the HTTP transaction is done over a secure
connection, Bob can trust the data received in the HTTP dialogue, in
particular the public Diffie-Hellman keys of the server and of Alice.
Moreover, the server is sure about the identity of Bob because Bob
authenticates himself when doing the HTTP requests.
Suppose that the first upper peer is Alice's node. Since Alice is
behind a NAT, Bob does not receive the IP address of Alice, but the
address of a "bridge node" used to carry out the ICE-based NAT
traversal procedure described in [ppetp-ice]. As a consequence of
this (see also Figure 16)
1. Bob gathers his candidate addresses [RFC5245] and sends them to
the bridge node together with the transaction ID specified as
value of tr-id attribute.
2. The network manager (or another host, on the behalf of the
network manager) sends to Alice a routed control packet
Data_Control/Punch+Start/ICE with the address of the bridge host
and the same transaction ID given to Bob.
3. Alice gathers (if necessary) her candidate addresses and sends
them to the bridge host.
4. The bridge host matches the transaction ID, discovers that has
both the candidate sets and it sends to Bob the candidates of
Alice and vice versa.
Bernardini, et al. Expires April 15, 2011 [Page 68]
Internet-Draft PPETP October 2010
5. Alice and Bob carry out the ICE procedure to find an address pair
that works.
6. When a working address pair is selected, Alice starts the
handshaking procedure with Bob by sending him a Set_Default
packet.
7. After the conclusion of the handshaking phase, Alices sends the
Acknowledge for the Data_Control packet to the network manager.
Bob Bridge Alice Manager
| | | |
| CANDIDATES (1)| | PUNCH (2) |
+-------------->| |<----------+
| | | |
| | CANDIDATES (3) | |
| |<---------------+ |
| | | |
| (4a) | | |
| CANDIDATES | (4b) | |
|<--------------+ CANDIDATES | |
| (Alice's) +--------------->| |
| | (Bob's) | |
| | |
| /----------------------------\ | |
|/ .. ... ... ... ... ... ... \| |
< ... ... ... ICE (5) ... ... . > |
|\ .. ... ... ... ... ... ... /| |
| \----------------------------/ | |
| | |
| Set_Default (6a) | |
|<-------------------------------+ |
| | |
| | |
| ACK (6b) | |
+------------------------------->| |
| | ACK(7) |
| +---------->|
| | |
Figure 16: ICE procedure between Alice and Bob
Now Alice and Bob are connected and Alice begins sending reduced
packets to Bob.
Bernardini, et al. Expires April 15, 2011 [Page 69]
Internet-Draft PPETP October 2010
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
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
Bernardini, et al. Expires April 15, 2011 [Page 70]
Internet-Draft PPETP October 2010
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. Extensions to other protocols
This section proposes some extensions to RTSP and to SDP aimed to
introduce PPETP as a possible transport protocol.
B.1. RTSP extensions
The Transport header of RTSP (see 12.39 of [RFC2326]) is extended as
follows
o In the transport specifier the new lower-transport labels PPETP
and PPETP-UDP are added. The two labels are equivalent and denote
data transport over UDP-based PPETP.
B.2. SDP extensions
B.2.1. Transport protocols ("proto")
The following transport protocols (to be used in the "proto" subfield
of the "m=" field) are proposed for registration: "RTP/AVP/PPETP-UDP"
and "PPETP-UDP". They correspond, respectively, to "RTP/AVP" and
Bernardini, et al. Expires April 15, 2011 [Page 71]
Internet-Draft PPETP October 2010
"UDP", but with the data transported over UDP-based PPETP. In
particular, the new protocols inherit the "fmt" namespace of the
corresponding protocols defined in [RFC4566].
If a PPETP-related protocol is used in the m= line, the conncetion
data in the c= line and the port in the m= line are to be interpreted
as follows
o The in the c= line is the address of the
session reference host.
o The in the m= line is the PPETP session number.
B.2.2. Attributes
The following PPETP-related attribute is defined
ppetp:
Used to introduce PPETP options. The first identifier (defined as
in the CCDF grammar) is the option name, the meaning of the rest
of the line depends on the specific option. In some sense, this
attribute can be interpreted as a namespace of options. The only
option defined in this document is
config-port
By default the port where configuration query are sent is TBD1
(see Section 7.1). This attribute is used to change this
default and communicate to the node an alternative port number.
The definition of new options to be used with this attribute
follows the same rules of the definition of new SDP attributes.
Some informations required by [RFC4566] for the definition of new
attributes can be found in Table 3; the required contact informations
are the equal to the contact informations of this document.
+-------+-----------------+--------------------+---------+----------+
| Name | Long name | Type | Charset | Value |
| | | | | spec |
+-------+-----------------+--------------------+---------+----------+
| ppetp | PPETP option | session and media | No | ****** |
| | setting | level | | |
+-------+-----------------+--------------------+---------+----------+
Table 3: IANA informations for new SDP attributes
Bernardini, et al. Expires April 15, 2011 [Page 72]
Internet-Draft PPETP October 2010
Appendix C. Builtin profiles
PPETP demands some duties to several "plugins" (e.g., reduction and
signature profiles, NAT traversal procedures) whose definition is not
part of the PPETP "core". In order to make PPETP usable without
waiting for the definition of all the necessary plugins, this section
defines few basic reduction and signature plugins.
C.1. Sender signature profiles
C.1.1. How to define a sender signature profile
A sender signature profile document must specify at least
o The profile name and name and type of any required parameter.
o Which parameters are "global" to the whole PPETP session and which
are "local" to each peer.
o The algorithm to obtain the source signature field from the
packet.
o Any profile-specific request.
C.1.2. Shared key signature profile
C.1.2.1. Profile name and parameters
The name of this profile is "shared-key". This profile requires the
following parameters
o An h-bit hash function H, at least SHA-256 MUST be supported. The
name of this parameter is "hash". The only value currently
accepted for hash is "SHA-256", but other values can be added in
future.
o A symmetric encryption algorithm C, at least AES-256 MUST be
supported. The name of this parameter is "encription". The only
value currently accepted for encription is "AES-256", but other
values can be added in future.
o Two positive integers "id-size" and "mac-size", both multiple of 8
and with mac-size <= h
The nodes agree on these parameters via extra-PPETP means. A summary
of the parameters together with the accepted values is given in
Table 4.
Bernardini, et al. Expires April 15, 2011 [Page 73]
Internet-Draft PPETP October 2010
+---------------------+----------------+----------------------------+
| Parameter | Attribute name | Accepted values |
+---------------------+----------------+----------------------------+
| Hash function | "hash" | "SHA-1" |
| Encryption function | "encryption" | "AES-256" |
| ID size in octets | "id-size" | non-negative integer <= 8 |
| MAC size in octets | "max-size" | non-negative integer <= 16 |
+---------------------+----------------+----------------------------+
Table 4: Configuration parameters for the shared key signature
profile
C.1.2.2. Payload construction
This signature profile supposes that the sender and the receiver
share a common secret K. The sender is identified by an ID
represented a id-size-bit number. The signature of a packet is the
pair (ID, MAC), where MAC is computed as follows
1. The whole packed is processed with hash function H
2. The result of the hash is encrypted with C using K as key
3. The first mac-size bits of the encrypted hash are the MAC
The signature payload is obtained by concatenating the id-size-bit
number representing the ID and the mac-size-bit number representing
the MAC. Since both id-size and mac-size are multiple of 8, the
signature will always take an integer number of octets.
C.1.2.3. Remarks
o This profile does not say how the two nodes agree on the common
secret K, this is supposed to be done via extra-PPETP means. For
example, if the two nodes are a server and a user, K could be a
long-term password, while if the two nodes are two peers K could
be the result of a Diffie-Hellman key agreement procedure.
o In order to be sure that the packet was signed by a node A, it is
necessary to be sure that both ID and K refer to A. This will
typically require some form of authentication that must be done
via extra-PPETP means.
o In order to allow for an autonomous Diffie-Hellman key exchange
between the nodes without involving a central server, a node can
communicate its ID and its public Diffie-Hellman key in the
PEER_CREDENTIAL attribute of the Data_Control/Start packet.
Bernardini, et al. Expires April 15, 2011 [Page 74]
Internet-Draft PPETP October 2010
o The possibility of having the MAC shorter than the hash allows to
reduce the bandwidth required by the signature in those
applications that do not need the strength of the full MAC.
C.1.3. Void signature profile
This profile does not add any signature to the packet. It is defined
for those cases where signatures would be redundant.
C.1.3.1. Profile name and parameters
The name of this profile is "void". This profile defines no
parameters
C.1.3.2. Creating the signature
This profile does not create any signature. The payload is empty.
C.1.3.3. Verifying the signature
The signature check is always positive.
C.2. Source signature profiles
C.2.1. How to define a source signature profile
A source signature profile document must specify at least
o The profile name and name and type of any required parameter.
o Which parameters are "global" to the whole PPETP session and which
are "local" to each peer.
o The algorithm to obtain the source signature field from the
packet.
o Any profile-specific request.
C.2.2. Rabin signature profile
This profile is based on the Rabin signature algorithm [RABIN]
C.2.2.1. Profile name and parameters
The name of this profile is "rabin". This profile defines the
following parameters
Bernardini, et al. Expires April 15, 2011 [Page 75]
Internet-Draft PPETP October 2010
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.
C.2.2.2. Creating the signature
The procedure to compute the source signature is the following:
1. The procedure is parametrized by two positive integer values: s
<= 16 and u <= 8.
2. At the beginning the node generates two 4*sign-size-bit prime
numbers p and q (the node private key) and compute the sign-size-
octets value n=p*q (the public key).
3. To sign a packet, the node concatenates the whole routed packet
(including the routing data block, but not the signature) with a
tail-size-octets random value U and process the result with SHA-
256. Let Y be the final value.
4. The node finds x such that Y = x^2 mod n. If such an x does not
exist, the node draws a new U, goes back to the previous step and
tries again. The expected number of trials is four. Note that
the node can find efficiently x because it knows p and q.
5. The signature is given by the (sign-size+tail-size)-octets value
2^(8*tail-size)*x + U. Such a values is stored in the Source
Signature field with any unused most significant bits set to
zero.
C.2.2.3. Verifying the signature
The procedure to verify the signature is the following
1. From the knowledge of the source ID, determine the source public
key n. If no public key is associated to the source ID, the
verification fails.
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
Bernardini, et al. Expires April 15, 2011 [Page 76]
Internet-Draft PPETP October 2010
supposed to be done by extra-PPETP means.
C.3. Reduction profiles
C.3.1. How to define a reduction profile
A reduction profile definition MUST specify at least
o The profile name and name and type of every profile parameter.
o Which reduction parameters are "global" to the whole PPETP session
and which are "local" to each peer. (For example, in the
Vandermonde profile the value of R is the same for the whole
network, while the reduction vector r_b is different for every
peer.)
o The algorithm to map a content packet to the data packet payload.
o The format used to store the reduction parameters in the payload
of the Set_Default request and in the payload of a data packet (if
the flag Inline is true).
o The meaning of the Flags field in the data packet.
o Any reduction-profile specific request.
C.3.2. Vandermonde reduction profile
C.3.2.1. Profile name and parameters
The profile name is "vandermonde". This profile defines the
following parameters.
gf_size This parameter can assume the values 1, 2 and 4 and
determines the size of the Galois field used. More precisely,
gf_size is the size in octets of an element of the Galois field,
therefore the Galois field relative to gf_size is
GF(2^(8*gf_size)).
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.2.
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.2.
Parameters gf_size and reduction-factor are global for the whole
Bernardini, et al. Expires April 15, 2011 [Page 77]
Internet-Draft PPETP October 2010
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.
C.3.2.2. Payload construction
The payload construction is based on the ideas of [DCC08]. The
payload is constructed as follows
1. Define, for the sake of compactness, d=8*gf_size, B=reduction-
base and R=reduction-factor.
2. Let the elements of GF(2^d) be represented as described in
Appendix C.3.2.2.1.
3. At startup the node constructs the row vector
r = [1, B, B^2, ..., B^(R-1)]
4. The packet to be reduced is mapped in a matrix G with R rows and
L/(gf_size*R) columns with entries in GF(2^d) as follows
A. The packet is padded, as described in Appendix C.3.2.2.2, to
a length multiple of gf_size*R octets. Let L be the length,
in octets, of the padded packet.
B. Let b[n] be the n-th octet of the padded packet, with n=0
denoting the first octet. For every m=0, 1, ..., L/gf_size,
interpret the sequence of gf_size octets b[gf_size*m],
b[gf_size*m+1], ..., b[gf_size*(m+1)-1] as an element of
GF(2^d) as described in Appendix C.3.2.2.1. Let g[m] be the
element of GF(2^d) associated to b[gf_size*m],
b[gf_size*m+1], ..., b[gf_size*(m+1)-1].
C. Define G as the matrix whose element in row r and column c is
g[r+ R*c], where r=0, 1, ..., R-1 and c=0, 1, ...,
L/(R*gf_size)-1.
5. Matrix G is left-multiplied by vector r to obtain row vector
U=r*G
6. Every element of U is mapped to gf_size octets (still according
to the representation escribed in Appendix C.3.2.2.2) to obtain a
string of L/R octets that represents the payload of the data
packet.
Bernardini, et al. Expires April 15, 2011 [Page 78]
Internet-Draft PPETP October 2010
C.3.2.2.1. Galois field implementation
If d=8, 16 or 32, let GF(2^d) be the field of polynomials with
coefficients in GF(2) (i.e., the integers modulo 2) modulo the
polynomials shown in Table 5.
The element of GF(2^d) associated with
c_{d-1} x^(d-1) + c_{d-2} x^(d-2) + ... c_1 x + c_0
(where each c_n = 0, 1) is represented by the d-bit unsigned integer
C=2^(d-1) c_{d-1} + 2^(d-2) c_{d-2} + ... 2 c_1 + c_0
This integer can be represented as a sequence of octets b_0, b_1,
b_{d/8-1} in little endian order, that is
C = b_0 + 256 b_1 + 256^2 b_2 + ...
+----+-----------------------------+
| d | Polynomial defining GF(2^d) |
+----+-----------------------------+
| 8 | x^8+x^4+x^3+x^2+1 |
| 16 | x^16+x^5+x^3+x^2+1 |
| 32 | x^32+x^15+x^9+x^7+x^4+x^3+1 |
+----+-----------------------------+
Table 5: Polynomials used to define GF(2^d)
C.3.2.2.2. Packet padding
1. Let length(P) be the size in octets of the content packet P to be
padded and let
L=(gf_size*R) * ceil (length (P) / (gf_size*R))
be the smallest multiple of gf_size*R not smaller than length(P).
2. If L=length(P), then the length of the packet is already a
multiple of R*gf_size and no padding is necessary. Set flag F to
0 and leave the packet as it is.
3. If L > length(P),
A. Set flag F to 1 and append L-length(P) zeros to the packet.
B. Decompose L-length(P) as
L-length(P) = 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 and return.
D. If A > 0, write B+128 in the last octet of the padded packet,
write A in the penultimate octet and return
Bernardini, et al. Expires April 15, 2011 [Page 79]
Internet-Draft PPETP October 2010
The algorithm above can be summarized by saying that the most
significant bit of the last octet of the padding acts as a flag: if
it is zero, we know that the padding length was less than 128 and
that its value is in the last octet; if it is one, we know that the
padding length was greater or equal than 128 and that its value is
stored in the last two octets. Note that using only one octet would
limit the padding size to 255 and that we cannot always use two
octets because the padding size could be 1.
C.3.2.3. Profile-related definitions
Data packet flags: Flag F is set to 1 if and only if the content
packet was padded according to the algorithm of
Appendix C.3.2.2.2. Flags 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.
C.3.3. Basic reduction profile
This is a very simple profile that just copies the content packet in
the payload. It can be used to distribute streams with a low bit-
rate (e.g., RTCP streams).
C.3.3.1. Profile name and parameters
The profile name is "basic". This profile defines no parameters.
C.3.3.2. Payload construction
The payload is a verbatim copy of the content packet.
C.3.3.3. Profile-related definitions
Bernardini, et al. Expires April 15, 2011 [Page 80]
Internet-Draft PPETP October 2010
Data packet flags: Flags F, G and H are unused.
Set_Default payload: Set_Default carries no payload.
Payload with the Inline bit set: Inline bit is unused.
Profile-specific request: This profile defines no profile-specific
request.
Authors' Addresses
Riccardo Bernardini
University of Udine
Via delle Scienze 208
Udine 33100
Italy
Phone: +39-0432-55-8271
EMail: riccardo.bernardini@uniud.it
Roberto Cesco Fabbro
University of Udine
Via delle Scienze 208
Udine 33100
Italy
Phone: +39-0432-55-8271
EMail: roberto.cesco@uniud.it
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 April 15, 2011 [Page 81]