[ppsp] One more ticket for Peer protocol security requirement issues

Hi all,
    Arno proposed some new issues derived from PPSP requirements as below. It would be great that some experts would look at the mail and say if you agree with the changes 
Arno wants to make to the peer protocol text.
    Ticket #4：Review the following proposals and say if you agree with the changes.
      If nobody expressed any concern or alternative proposal regarding security issues (with the same deadline as ticket #1， May 26th）, we propose to move on and would ask Arno to proceeds with the changes in the peer protocol draft.

BR
Yunfei

zhangyunfei

From: Arno Bakker
Date: 2012-02-14 21:24
To: ppsp
Subject: [ppsp] New issues derived from PPSP requirements...
Hi

I've gone over the requirements list in draft-ietf-ppsp-reqs-05
and identified some issues (mostly security related) that need to be 
discussed in the WG:

> * "PPSP.REQ-8: The tracker and peer protocol together MUST facilitate
>   acceptable QoS (e.g. low startup delay, low channel/content switching
>   time and minimal end-to-end delay) for both on-demand and live
>   streaming, even for very popular content.  The tracker and peer
>   protocol do not include the algorithm required for scalable
>   streaming.  However, the tracker and peer protocol SHALL NOT restrict
>   or place limits on any such algorithm.
>
>   There are basic QoS requirements for streaming system.  Setup time to
>   receive a new streaming channel or to switch between channels should
>   be reasonable small.  End to end delay (time between content
>   generation, e.g. camera and content consumption, e.g. user side
>   monitor) will become critical in case of live streaming.  Especially
>   in provisioning of sports events, end to end delay of 1 minute and
>   more are not acceptable.
>
>   For instance, the tracker and peer protocols can support carrying QoS
>   related parameters (e.g. video quality, delay requirements) together
>   with the priorities of these parameters, and QoS situation (e.g.
>   performance, available uplink bandwidth) of content providing peers.
>
>   There are also some other possible mechanisms, e.g. addition of super
>   peers, in-network storage, request of alternative peer addresses, and
>   the usage of QoS information for an advanced peer selection."

The current protocol has been designed for short-time-till-playback,
unless limited by security considerations (cf. Issue #26 security of
handshakes). Otherwise it operates in a best effort mode.

But perhaps more is needed, as indicated in the description. Also
relevant is issue 12 (=Support for UNHINT), as that helps in making
requesting chunks from multiple peers at the same time efficient,
as you can cancel the duplicates when you receive an answer.
You may need double requests when some peers are slow and strong QoS
is needed.

I'd like to raise this as Issue #35.

>   * PPSP.PP.REQ-3: The streaming content availability request message
>    SHOULD allow the peer to solicit an additional list of peers to that
>    received from the tracker - with the same swarm ID.  The reply
>    message MUST contain swarm-membership information of the peers that
>    have explicitly indicated they are part of the swarm, verifiable by
>    the receiver.  This additional list of peers MUST only contain peers
>    which have been checked to be valid and online recently (e.g. prevent
>    hearsay and DoS).
>
>    It is possible that a peer may need additional peers for certain
>    streaming content.  Therefore, it is allowed that the peer
>    communicates with the peers in the current peer list to obtain an
>    additional list of peers in the same swarm.

The draft uses PEX_* messages for this, hence I propose to rephrase this 
requirement, or declare PEX as sufficient to satisfy this requirement.

>    * PPSP.PP.REQ-6: The peer status report/update SHOULD be advertised
>    among the peers to reflect the status of the peer.
>
>    Peer status information should be advertised among the peers via the
>    peer status report/update message.  For example, peer status can be
>    online time, physical link status including DSL/WIFI/etc, battery
>    status, processing capability, and other capabilities of the peer.
>    With this information, a peer can select more appropriate peers for
>    streaming.

I'd like to raise this as Issue #36.

>    * PPSP.SEC.REQ-1: PPSP MUST support closed swarms, where the peers are
>    authenticated.
>
>    This ensures that only the authenticated users can access the
>    original media in the P2P streaming system.  This can be achieved by
>    security mechanisms such as user authentication and/or key management
>    scheme.

I'd like to raise this as Issue #37.

In addition, I propose the following solution: The Closed Swarms 
[CLOSED] and Enchanced Closed Swarms [ENHCLOSED] mechanisms developed in 
the P2P-Next project provide swarm-level access control.
The basic idea is that a peer cannot download from another peer unless 
it shows a Proof-of-Access. Enhanced Closed Swarms improve on the 
original Closed Swarms by adding on-the-wire encryption against 
man-in-the-middle attacks and more flexible access control rules.

I propose to describe Enhanced Closed Swarms as one of the mechanisms 
(please put forward others if you know about them) to satisfy the 
requirement and include it as a Section in the WG draft.

>   * PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP
>    SHOULD be supported and the corresponding key management scheme
>    SHOULD scale well in P2P streaming system.
>

No extra mechanism is needed in to support confidentiality in PPSPP. A
content publisher wishing confidentiality should just distribute content 
in cyphertext / DRM-ed format. I assume a higher layer handles key 
management out-of-band. Alternatively, the swarm access control will 
point-to-point encrypt content.

I'd like to raise this as Issue #38, and propose to add a paragraph to
Section 7 of the draft with the explanation I just gave.

>   * PPSP.SEC.REQ-3: PPSP MUST provide an option to encrypt the data
>    exchange among the PPSP entities.
>

If this requirement means that all PPSPP messages should be encrypted 
(as opposed to just content in SEC.REQ-2), IPsec or DTLS is the obvious 
solution.

I'd like to raise this as Issue #39, and propose to add a paragraph to
Section 7 of the draft with the explanation I just gave. Furthermore,
a key distribution scheme would have to be added.

>    * PPSP.SEC.REQ-4: PPSP MUST have mechanisms to limit potential damage
>    caused by malfunctioning and badly behaving peers in the P2P
>    streaming system.
>
>    Such an attack will degrade the quality of the rendered media at the
>    receiver.  For example, in a P2P live video streaming system a
>    polluter can introduce corrupted chunks.  Each receiver integrates
>    into its playback stream the polluted chunks it receives from its
>    other neighbors.  Since the peers forwards chunks to other peers, the
>    polluted content can potentially spread through much of the P2P
>    streaming network.

Content integrity protection helps here. I'd like to raise this as Issue 
#40 and will provide a per-message analysis of issues later.

>    * PPSP.SEC.REQ-5: PPSP SHOULD support identifying badly behaving peers,
>    and exclude or reject them from the P2P streaming system.

Quoting WG draft 6.3.2.3: "The Merkle tree hashing scheme allows a 
receiving peer to detect a malicious or faulty sender, which it can 
subsequently ignore. Spreading this knowledge to other peers such that 
they know about this bad behavior is hearsay."

So we can provide protection, but to actually oust bad peers permanently 
from the system, access control and a reliable accusation system is 
needed that is itself protected against malicious peers reporting about 
good peers. Such a system is complex.
I'd like to raise this as Issue #41, and propose to add a paragraph to
Section 7 of the draft with the explanation I just gave.

>   * PPSP.SEC.REQ-6: PPSP MUST prevent peers from DoS attacks which will
>    exhaust the P2P streaming system's available resource.
>
>    Given the prevalence of DoS attacks in the Internet, it is important
>    to realize that a similar threat could exist in a large-scale
>    streaming system where attackers are capable of consuming a lot of
>    resources with just a small amount of effort.

Quoting WG draft 6.3.2.3: "A risk in peer-to-peer streaming systems is 
that malicious peers launch an Eclipse [ECLIPSE] attack on the initial
injectors of the content (in particular in live streaming). The attack
tries to let the injector upload to just malicious peers which then do
not forward the content to others, thus stopping the distribution. An
Eclipse attack could also be launched on an individual peer. Letting
these injectors only use trusted trackers that provide true random
samples of the population or using a secure peer sampling service
[PUPPETCAST] can help negate such an attack."

So we need PEX protection as discussed in the mail "Proposal to resolve 
Issue 17+20..." of Feb 14th. In addition, a peer A must not
let other peers T1..TN fill all its available connection slots, i.e.,
A must initiate connections itself too, to prevent isolation.

Furthermore, to prevent malicious peers consuming all upload bandwidth 
of a peer, there should be a limit on the upload capacity a single peer
can consume, e.g. via a limit on the number of requests as in 
SecureStream [SECSTREAM]. A natural upper limit of this upload quotum is 
the bitrate of the content.

Protection against amplifcation attacks such as mentioned in the mail 
"Proposal to solve Issue #26" of Jan 25th also help to satisfy this 
requirement.

If you know any other resource exhaustion attacks possible, please 
submit them with proposals on how to solve them.

I'd like to raise this as Issue #42, and propose to add paragraphs to
Section 7 of the draft with the explanation I just gave.

>    * PPSP.SEC.REQ-7: PPSP SHOULD be robust, i.e., when centralized tracker
>    fails the P2P streaming system SHOULD still work by supporting
>    distributed trackers.

We need PEX protection as discussed in the mail "Proposal to resolve 
Issue 17+20..." of Feb 14th. I propose to update Issue 20 to indicate 
that this requirement is related.

>    * PPSP.SEC.REQ-9: Integrity of the streaming content in PPSP MUST be
>    supported to provide a peer with the possibility to identify
>    inauthentic media content (undesirable modified by other entities
>    rather than its genuine source).  The corresponding checksum
>    distribution and verification scheme SHOULD scale well in P2P
>    streaming system and be robust against distrustful trackers/peers.

The Merkle hash trees mechanism provides content integrity protection
and is already explained in the draft. Merkle hash trees can also be 
used for live streaming. In that context we should quote [DIGSIGFLOW], 
the signature amortization scheme that also uses Merkle trees.

I'd like to raise adding the reference as Issue #43. Support for 
multiple content integrity schemes will be added when we reach concensus 
on Issue #10+13 (see my mail dd. Jan 18th).

What do you think?

CU,
     Arno

References
----------
[CLOSED] N. Borch, K. Michell, I. Arntzen, and D. Gabrijelcic: "Access
control to BitTorrent swarms using closed swarms". In Proceedings
of the 2010 ACM workshop on Advanced video streaming techniques
for peer-to-peer networks and social networking (AVSTP2P '10).
ACM, New York, NY, USA, 25-30.
http://doi.acm.org/10.1145/1877891.1877898

[ENHCLOSED] V. Jovanovikj, D. Gabrijelčič and T. Klobučar. "Access 
Control in BitTorrent P2P Networks Using the Enhanced Closed Swarms
Protocol". In Proceedings of the Fifth International Conference on 
Emerging Security Information, Systems and Technologies (SECURWARE
2011), pp. 97-102, Nice, France, August 2011.

[SECSTREAM] Maya Haridasan and Robbert van Renesse. "SecureStream: An 
Intrusion-Tolerant Protocol for Live-Streaming Dissemination". The 
Journal of Computer Communication's Special issue on Foundation of 
Peer-to-Peer Computing. Volume 31 Number 2, Elsevier, 2008.

[DIGSIGFLOW] Chung Kei Wong and Simon S. Lam. "Digital Signatures for 
Flows and Multicasts". IEEE/ACM Transactions on Networking,
Volume 7,  Issue 4, pp. 502-513, Aug 1999.
http://dx.doi.org/10.1109/90.793005
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp