Subject: [ppsp] SEC.REQ-4 Analysis

From: Arno Bakker <[email-masked]>
Date: Wed, 15 Feb 2012 10:09:40 +0100

Hi

please find below an analysis of threats of malicious peers. I'll go 
over each of the message types currently defined and describe how they 
could be exploited by malicious peers and how to stop that. Please add
to the analysis if you identified new threats.

>    * 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.

HANDSHAKE
=========
- Secured against DoS amplification attacks as proposed in mail dd. Jan
   25th.
- Threat 1.1: Eclipse attack where peers T1..TN fill all connection
   slots of A by initiating the connection to A.

   Solution: Don't accept all incoming connections, initiate e.g. 50%
   yourself (see also SEC.REQ-6 discussion in previous mail).

HAVE
====
- Threat 2.1: Malicious peer T can claim to have content which it
   hasn't. Subsequently T won't correspond to requests.

   Solution: peer A will consider T to be a slow peer and not ask it
   again.

- Threat 2.2: Malicious peer T can claim not to have content. Hence it
   won't contribute.

   Solution: Peer+chunk selection policies external to the protocol will
   implement fairness and provide sharing incentives. Perhaps we should
   add CHOKE/UNCHOKE messages (Issue #4) as an extra mechanism for these
   policies to use.

ACK
===
- Threat 3.1: peer T acks wrong chunks.

   Solution: peer A will detect inconsistencies with what it sent.

- Threat 3.2: peer T modifies timestamp in ACK to peer A used for
   time-based congestion control.

   Solution: TODO. Could peer T use it to fake there is no congestion
   when in fact there is, causing A to send more data than it should?

DATA
====
- Threat 4.1: peer T sending bogus chunks.

   Solution: The content integrity protection scheme defends against
   this.

- Threat 4.2: peer T sends peer A unrequested chunks.

   To protect against this threat we would need network-level DoS
   prevention.

HASH
====
- Threat 5.1: Amplifcation attack: peer T sends HASHes, peer A checks
   hashes, spending CPU.

   Solution: If the hashes don't check out A will stop asking T because
   of the atomic datagram principle and the content integrity protection.

HINT
====
- Threat 6.1: peer T could request lots from A, leaving A without
   resources for others.

   Solution: Limit upload bandwidth per peer (see also SEC.REQ-6
   discussion in previous mail).

PEX_RES
=======
- See mail dd. Feb 14th on how we can defend against amplication and
   Eclipse attacks.

VERSION
=======
- No threats identified.

Unsollicited requests in general
================================
- Threat: peer T could send a spoofed PEX_REQ or HINT from peer B to
   peer A, causing A to send a PEX_RES/DATA to B.

   Solution: the message from peer T won't be accepted unless T does a
   handshake first (see mail dd. Jan 25th.), in which case the reply
   goes to T, not victim B.

CU,
    Arno