The Case for Network-Layer, Peer-to-Peer Anonymization Michael J. Freedman Emil Sit, Josh Cates,...

transcript

The Case for Network-Layer,Peer-to-Peer Anonymization

Michael J. Freedman

Emil Sit, Josh Cates, Robert Morris

MIT Lab for Computer Science

IPTPS’02 March 7, 2002

http://pdos.lcs.mit.edu/tarzan/

March 7, 2002 The Case for Network-Layer, Peer-to-Peer Anonymization Page 2

• Participant can communicate anonymously with non-participant

• User can talk to CNN.com

• Nobody knows who user is

The Grail of Anonymization

Our Vision for Anonymization

• Millions of nodes participate• Bounce traffic off one another

• Mechanism to organize nodes: peer-to-peer• All applications can use: IP layer

Alternative 1: Proxy Approach

• Intermediate node to proxy traffic

• Completely trust the proxy

Anonymizer.com

User Proxy

Realistic Threat Model

• Corrupt proxy– Adversary runs proxy– Adversary targets proxy and compromises

• Limited, localized network sniffing

• Global passive observer? • Adaptive active adversary?

Use cover network: a different paper

Failures of Proxy Approach

User ProxyProxy

• Traffic analysis is easy

• Proxy reveals identity

Failures of Proxy Approach

User Proxy XX

• CNN blocks connections from proxy

• Traffic analysis is easy

• Adversary blocks access to proxy (DoS)

• Proxy reveals identity

Alternative 2: Centralized Mixnet

User Relay Relay Relay

• MIX encoding creates encrypted tunnel of relays

– Individual malicious relays cannot reveal identity

• Packet forwarding through tunnel

Onion Routing, Freedom

Small-scale, static network, not general-purpose

Failures of Centralized Mixnet

Relay Relay Relay

• CNN blocks core routers

Relay Relay

• Adversary targets core routers

RelayRelay

Relay Relay

• Adversary targets core routers

• Allows network-edge analysis

Tarzan: Me Relay, You Relay

• Millions of nodes participate

• Build tunnel over random set of nodes

Crowds:

small-scale, not self-organizing, not a mixnet

Benefits of Peer-to-Peer Design

• No network edge to analyze:

First hop does not know he’s first

? ?? ?

• CNN cannot block everybody

• Adversary cannot target everybody

Managing Peers

• Requires a mechanism that

1. Discovers peers

2. Scalable

3. Robust against adversaries

• Adversary can join more than once

Due to lack of central authentication

Adversaries Can Join System

• Try to prevent adversary from impersonating

large address space

Stopping Evil Peers

• Contact peers directly to– Validate IP address

– Learn public key

Adversary can only answer small address space

Tarzan: Joining the System

1. Contacts known peer in big (Chord) network

2. Learns of a few peers for routing queries

3. Contacts random peers to learn {IP addr, PK}

Performs Chord lookup(random)

Tarzan: Discovering Peers

Tarzan: Building Tunnel

4. Iteratively selects peers and builds tunnel

Public-key encrypts tunnel info during setup

Maps flowid session key, next hop IP addr

Tunnel Private AddressPublic Alias

Address

RealIP

Address

Tarzan: Tunneling Data Traffic

5. Reroutes packets over this tunnel

Diverts packets to tunnel source router

NATs to private address space 192.168.x.x

Layer encrypts packet

Encapsulates in UDP and forwards packet

Strips off encryption, forwards to next hop

IPIPIP

NATs again to public alias address

Reads IP headers and sends accordingly

Response repeats process in reverse

IPIPIPIP

APPIPIP

Transparently supports anonymous servers

Can build double-blinded channels

Server

IPIPIPIP

IPIP IPIP

IP IP IP IPIP

ObliviousUser

Tarzan is Fast (Enough)

• Prototype implementation in C++

• Setup time per hop:

~20 ms + transmission time

• Packet forwarding per hop:

< 1 ms + transmission time

• Network latency dominates performance

Summary

• Gain anonymity:– Millions of relays

– No centralization

• Transparent IP-layer anonymization– Towards a critical mass of users

Peer-to-Peer design

The Case for Network-Layer, Peer-to-Peer Anonymization Michael J. Freedman Emil Sit, Josh Cates,...

Documents