Subject: [ppsp] Proposal to resolve Issue 17+20...

From: Arno Bakker <[email-masked]>
Date: Tue, 14 Feb 2012 08:31:44 +0100

Hi all

in this mail I propose a solution to the following issues:

17. How to formulate behaviour of Peer-Exchange messages? What is
recent? [Kiraly]

20. Evaluate security implications of PEX. [Bakker]

And also the use of Distributed Hash Tables (DHTs) with PPSPP.
This discussion has implications for the tracker as well.

Description
===========
In the current protocol a peer A can send a Peer-Exchange message 
PEX_RES to a peer B, which currently contains the IP address and port of 
other peers that are supposedly also in the current swarm.

The strength of this mechanism is that it allows decentralized tracking, 
after an initial bootstrap no central tracker is needed anymore. The 
vulnerability of this mechanism (and DHTs) is that
malicious peers can use it for an Amplification attack.
In particular, a malicious peer T could send a PEX_RES to well-behaved 
peer A containing a list of address B1,B2,...,BN and on receipt,
peer A could send a HANDSHAKE to all these peers. So in the worst
case, a single datagram results in N datagrams. The actual damage
depends on A's behaviour. E.g. when A already has sufficient connections
it may not connect to the offered ones at all, but if it is a fresh peer 
it may connect to all directly.

Note the impact of the attack is reduced by the secure handshake
(see my proposal to resolve Issue 26). Peer A only sends a small
HANDSHAKE to the peers Bx.

In addition, PEX can be used in Eclipse attacks where malicious peers 
try to isolate a particular peer such that it only interacts with 
malicious peers. Let us distinguish two specific attacks:

E1. Malicious peers try to eclipse the single injector in live streaming
E2. Malicious peers try to eclipse a specific consumer peer.

Attack E1 has the most impact on the system as it would disrupt all peers.

Protection against Amplification Attack
=======================================

The Amplification attack can partly be fended off by policies. For 
example, a peer could only select a few addresses (randomly) from each 
PEX_RES message. Or only use PEX when it needs new peers and has not 
been able to contact the tracker for a while, so just as a fallback.

Certification
-------------
A stronger protection can be provided by using public key cryptography 
and certification. The idea is a PEX message will carry membership 
certificates rather than IP+port. A membership certificate for peer B 
states that peer B at address ipB+portB is part of swarm S at time T
and is cryptographically signed. The receiver A can check the cert for a 
valid signature, the right swarm and liveliness and only then consider 
contacting B.

Several designs are possible for the security environment for these 
membership certificates. I'll describe two.

1. "Generic" Certification Authority
------------------------------------
First, we can assume there is a Certification Authority (CA) that
hands out what I'll call a basic public key certificate to a peer A 
wanting to use PPSPP. The basic certificate just says that A is a valid 
user and protects against Sybil attacks.

Now, when peer A wants to join swarm S, it creates a membership
certificate mA containing its basic certificate from the CA, its 
external IP and port, swarm ID S and a time stamp, which it signs with 
A's private key. Note this assumes A actually knows its external IP and 
port. When peer A establishes a connection with peer B, it will send mA 
as part of the handshake procedure, for example, in the third datagram 
(cert mA is not essential and takes up bytes, so sending it in the first 
is not required).

B then verifies the signature on the cert mA against the included basic 
certificate, and verifies the basic certificate against the root 
certificate of the Certification Authority. Subsequently, peer B can 
send cert mA to other peers in PEX_RES messages.

The timestamp in the membership certificate protects against replays, 
and peer A should regularly create new membership certs. Question is how 
regularly? The main goal of the membership certs is to prevent that 
malicious peer T can cause good peer A to contact *random* hosts.
The freshness of the timestamp just adds extra protection in addition to 
achieving that goal. It protects against malicious hosts causing a good 
peer A to contact hosts that *previously participated in the swarm*. So 
the attack amplification factor is considerably smaller. So slow 
refreshes may be acceptable.

2. Tracker as Certification Authority
-------------------------------------
Another approach is to let the tracker act as certification authority.
A peer A wanting to join swarm S sends a registration message to a 
tracker X. Upon receipt, the tracker creates a membership certificate 
from the request with swarm ID S, a timestamp T and the external IP + 
port it received the message from, signed with the tracker's private 
key. This certificate is returned to A, along with the peer addresses in 
the tracker response.

Peer A then includes this cert in the handshake, as above, and receiver 
B verifies it against the tracker public key. This tracker public key 
should be part of the swarm's metadata, which B received from a trusted 
source.

The registration procedure may have to be changed to a three-way 
handshake to disable the attack where malicious peers sends lots
of registeration messages to the tracker, causing it to do a lot of 
crypto. Presently, the procedure is already safe against Sybil
attacks, if we assume the attackers can spoof but not eavesdrop.
In those conditions, malicious peers may send registration messages with 
spoofed IP addresses, but they won't be able to receive the tracker's 
responses with the membership certificates.

Note that this procedure can also be delayed as it is not essential for 
operation and may add latency (especially with a 3-way handshake). So
a peer could contact the tracker to get some initial peers and try
to get content as soon as possible. After prebuffering is over, the
peer could contact the tracker again to obtain the membership cert and
be able to participate in PEX. The tracker could play the role of 
bootstrap service.

New attack: Amplication attack via membership certs
---------------------------------------------------
The membership certificate mechanism itself can be used for a kind of 
amplication attack. Malicious peer T can cause peer A to spend some CPU 
to verify the signatures on the membership certificates that T sends.
To counter this, A could just check a few of the certs sent and discard
the rest.

Distributed Hash Tables
-----------------------
The same membership certificates described above can be registered in a 
DHT that has been secured against the well-known DHT specific attacks.

In the IETF RELOAD base protocol 
(http://datatracker.ietf.org/doc/draft-ietf-p2psip-base) all data in 
stored in the DHT overlay is also signed by the peer. I can't find 
specifics on peer address storage.

Protection Against Eclipse Attacks
==================================
Before we can discuss Eclipse attacks we first need to establish the
security properties of the central tracker. A tracker is vulnerable to 
Amplification attacks too. A malicious peer T could register a victim B 
with the tracker, and many peers joining the swarm will contact B.
Trackers can also be used in Eclipse attacks. If many malicious peers 
register themselves at the tracker, the percentage of bad peers in the 
returned address list may become high. Leaving the protection of the 
tracker to the tracker protocol spec, we assume for the following 
discussion that it returns a true random sample of the actual swarm 
membership  (achieved via Sybil attack protection). This means that if 
50% of the peers is bad, you'll still get 50% good addresses from the 
tracker.

Attack E1 on PEX can be fended off by letting live injectors disable 
PEX. Or at least ensure that part of their connections are to peers 
whose addresses came from the trusted tracker.

The same measures defend against attack E2 on PEX. They can also be 
employed dynamically. When the current set of peers B that peer A is
connected to doesn't provide good quality of service, A can contact the 
tracker to find new candidates.

PuppetCast
==========
Even stronger protection mechanisms exists. In PuppetCast [PUPPETCAST]
a trusted bootstrap service assigns each peer a set of peers in the 
swarm that it can advertise to others. Cryptography prevents peers from 
sending a different set. PuppetCast ensures freshness of the peers in 
the set (i.e., deals with churn, the leaving and joining of peers) with 
just a light load on the bootstrap service.

PuppetCast protects against Amplification attacks and Eclipse attacks 
against PEX because the set of peers sent in PEX_RES messages consists 
of peers that are part of the swarm, and because the set cannot be 
changed by malicious peers.

Proposed Solution Issue 17
==========================
The current draft says about the addresses used in the PEX_RES message. 
"The addresses MUST be of peers it has recently exchanged messages with 
to guarantee liveliness." I propose to rewrite this to: "exchanged 
messages with in the last 60 seconds".

Note this value is largely independent of the expiry of membership 
certificates. A peer may be in a swarm longer than that it is connected 
to a single peer.

Proposed Solution Issue 20
==========================
In sum, there are four approaches to PEX and its potential for 
amplification attacks.

1. Do not allow the use of PEX.

2. Limit PEX use via policies. E.g. just use as a fallback.

3. Introduce membership certificates + true random sample from tracker.

4. Employ PuppetCast.

I propose solution 1 or 3 (with tracker as CA).

References
----------

[PUPPETCAST]  A. Bakker and M. van Steen. "PuppetCast: A Secure Peer
Sampling Protocol". Proceedings 4th Annual European Conference on
Computer Network Defense (EC2ND'08), pp. 3-10, Dublin, Ireland,
11-12 December 2008.