Peer-to-Peer Name Service (P2PNS) Ingmar Baumgart Institute of Telematics, Universität Karlsruhe IETF 70, Vancouver.

Peer-to-Peer Name Service (P2PNS)

Ingmar Baumgart

Institute of Telematics, Universität Karlsruhe

IETF 70, Vancouver

2

What’s different to other proposals?

• Flexibility

• Modular architecture

• Two-stage name resolution

• Focus on security in a completely decentralized environment

• Implementation

3

Flexibility

• Distributed name resolution for:– P2PSIP, decentralized DNS, HIP,

decentralized IM (XMPP)

• Same task in all scenarios:– Resolve a P2PName (AoR, Domain Name,

HIT) to the current transport address (IP, Port)

• P2PNS XML-RPC Interface:– register(P2PName, transport address)– resolve(P2PName)

4

Modular Architecture

• Key Based Routing (KBR)– Task: Message routing to nodeIDs – route(key, msg)– lookup(key)

• Distributed Hash Table (DHT)– Task: Data storage– put(key, value)– get(key)

• Name Service– Task: Resolution/Caching of P2PNames– register(P2PName, transport address)– resolve(P2PName)

Modular architecture allows to reuse implementations for different applications (ALM, Filesharing, Gaming,…)

KBR

DHT

Name Service

route()lookup()

put()get()

register()resolve()

5

Two-Stage Name Resolution

1.) Resolve AoR NodeID (DHT layer)

2.) Resolve NodeID IP (KBR layer)

Motivation:– Modification of data records on DHT is expensive

(due to security mechanisms)– (AoR, NodeID) binding is static: No modification

needed if IP address changes– IP address changes are efficiently handled on KBR

layer

6

P2PNS Example: REGISTER

KBR

DHT

P2PNSCache

SIP

route()lookup()

put()get()

register()resolve()

Peer X

1. REGISTER(To:U)

User U

4. PUT(U, NodeID_X)

2. REGISTER(U)

3. J

OIN

(No

deI

D_X

)

7

P2PNS Example: INVITE

KBR

DHT

P2PNSCache

SIP

route()lookup()

put()get()

register()resolve()

Peer Y

1. I

NV

ITE

(To

:U)

User V

3. GET(U)

2. RESOLVE(U)4.

LO

OK

UP

(No

deI

D_X

)

SIP

User U

5. INVITE(To:U)

6. INVITE(To:U)

8

P2PNS Security

• KBR layer:– Limit nodeID generation (crypto puzzles or offline CA)– Iterative routing over disjoint paths– Secure routing table maintenance

• DHT layer:– Replication and majority vote– Only owner may modify data records (nodeID

signature)• Prevents identity theft• Unique usernames (same key in DHT is only allowed once)

– Insertion DoS attack prevention

9

P2PNS Implementation

• Unmodified SIP UAs

• Added P2PNS support to OpenSER SIP proxy

• Overlay Framework OverSim– Provides P2PNS service to the P2PSIP proxy

– Several KBR protocols implemented:• Chord, Koorde, Pastry, Kademlia, Broose

– Simulation and emulation of overlay protocols

• To be released as open source project in January

10

Thank you for your attention!

11

Key-based Routing (KBR)

• Provided by structured overlay networks– Kademlia, Chord, Koorde, Broose

• Main idea:– Each node has a nodeID – Overlay routing table with

nodeIDs of overlay neighbours– Efficient lookup of keys

and nodeIDs in O(log N)

12

KBR for P2PSIP

• Main task in P2PSIP:– Resolve AoR to current IP address

• Idea: Use KBR nodeID as AoR– Efficient lookup of AoRs in O(log N) hops– If the IP address of a nodes changes, it rejoins the

overlay with his old nodeID

• Several security issues with KBR

Alice BobREGISTERalice => 141.31.93.13

INVITE alice

141.31.93.13

Contact: 141.31.93.13

P2P-

Overlay

13

Attacks on node ID generation

• By carefully choosing a nodeID an attacker can control access to target objects

• Sybil attack: A single node can join the network with several nodeIDs

• Countermeasure:– Make nodeID generation expensive– Limit free nodeID selection

14

Secure NodeID generation

• Common approach: NodeID = SHA1(IP+port)– Problems:

• Sybil attack still possible if an attacker controls several IP addresses

• Constantly changing nodeIDs on dial-up connections

• Better: NodeID = SHA1(public key)– Public key can be used to authenticate node

messages– Sybil attack and choose of a specific nodeID still

feasible• Use in combination with crypto puzzles to make creation of

new nodeIDs expensive

15

Attacks on message forwarding

• Malicious nodes along the path between sender and target node can modify or drop messages to a key

• Countermeasure: Parallel lookup over disjoint paths increases the lookup success ratio:

P(lookup success) = 1 – (1 – (1 – m)h)d

• Most important security properties of KBR protocols– Average path length h– Number of disjoint paths d

16

Kademlia under attack

17

Choosing an overlay for KBR

• Several KBR candidates:– Chord, Kademlia, Koorde, Broose

• Important KBR properties for security:– Number of disjoint paths– Average path length– Restrictions on nodeID generation

• Trade-Off between security and bandwidth consumption

18

KBR is not sufficient

• Nobody wants to remember a 160 bit nodeID as AoR

• Solution:– Use a DHT to store (AoR, nodeID) mappings– DHT uses KBR layer to stores (key, value)

tuples

21.001-40.000

H(“sip:baumgart”)=2313Node stores the mapping (sip:baumgart, NodeID)

0-1000

4001-7000

1001-2000

7001-10.000

10.001-

21.000

40.001-65.536

2001-4000

19

DHT security is expensive

• Malicious nodes can modify or delete locally stored data items

• Countermeasure: Replicate data items on k nodes and use majority votes

Changing data records in a DHT is expensive• Our approach:

– Only store (AoR, nodeID) mappings in DHT(normally doesn’t change)

– The dynamic (nodeID, IP) mapping is efficiently done by the KBR layer

20

Overlay Framework OverSim

• Analysis of different overlays in NGNs– Terminal mobility– Heterogeneous access networks– Overlay devices in access and

core network• Fast implementation of new

overlay protocols• Scalability and flexibility due to

a modular design• Emulation of overlay terminals (connect to real networks)• Several state of the art overlay protocols:

– Chord, Pastry, Kademlia, Koorde, Broose, Gia• Several overlay applications:

– Generic DHT, i3, P2PNS, Gaming Application

21

P2PSIP Demonstrator