Transcript Peer-to-Peer Name Service (P2PNS) Ingmar Baumgart Institute of Telematics, Universität Karlsruhe

Peer-to-Peer Name Service
(P2PNS)
Ingmar Baumgart
Institute of Telematics, Universität Karlsruhe
IETF 70, Vancouver
What’s different to other proposals?
•
•
•
•
Flexibility
Modular architecture
Two-stage name resolution
Focus on security in a completely
decentralized environment
• Implementation
1
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)
2
Modular Architecture
• Key Based Routing (KBR)
– Task: Message routing to nodeIDs
– route(key, msg)
– lookup(key)
register()
resolve()
• 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)
Name Service
put()
get()
DHT
route()
lookup()
KBR
 Modular architecture allows to reuse implementations for
different applications (ALM, Filesharing, Gaming,…)
3
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
4
P2PNS Example: REGISTER
2. REGISTER(U)
1. REGISTER(To:U)
SIP
User U
3. JOIN(NodeID_X)
register()
resolve()
P2PNS
Cache
put()
get()
4. PUT(U, NodeID_X)
DHT
route()
lookup()
KBR
Peer X
5
P2PNS Example: INVITE
5. INVITE(To:U)
2. RESOLVE(U)
SIP
User V
4. LOOKUP(NodeID_X)
1. INVITE(To:U)
register()
resolve()
P2PNS
Cache
put()
get()
3. GET(U) 6. INVITE(To:U)
DHT
SIP
route()
lookup()
KBR
User U
Peer Y
6
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
7
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
8
Thank you for your attention!
9
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)
10
KBR for P2PSIP
Alice
 REGISTER
alice => 141.31.93.13
 INVITE alice
P2POverlay
141.31.93.13
Bob
Contact: 141.31.93.13

• 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
11
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
12
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
13
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
14
Kademlia under attack
15
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
16
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
40.00165.536
01000
21.00140.000
7001-10.000
10012000
40017000
10.001
21.000
H(“sip:baumgart”)=2313
Node stores the mapping
(sip:baumgart, NodeID)
20014000
17
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
18
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
19
P2PSIP Demonstrator
20