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

2. 1 What’s different to other proposals? Flexibility Modular architecture Two-stage name resolution Focus on security in a completely decentralized environment Implementation

3. 2 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. 3 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. 4 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. 5 P2PNS Example: REGISTER KBR DHT P2PNS Cache SIP route() lookup() put() get() register() resolve() Peer X 1. REGISTER(To:U) User U 4. PUT(U, NodeID_X) 2. REGISTER(U) 3. JOIN(NodeID_X)

7. 6 P2PNS Example: INVITE KBR DHT P2PNS Cache SIP route() lookup() put() get() register() resolve() Peer Y 1. INVITE(To:U) User V 3. GET(U) 2. RESOLVE(U) 4. LOOKUP(NodeID_X) SIP User U 5. INVITE(To:U) 6. INVITE(To:U)

8. 7 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. 8 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. 9 Thank you for your attention!

11. 10 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. 11 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 Bob REGISTER alicealice => 141.31.93.13 INVITE alice 141.31.93.13 Contact: 141.31.93.13   P2P- Overlay

13. 12 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. 13 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. 14 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. 15 Kademlia under attack

17. 16 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. 17 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”)=2313 Node 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. 18 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. 19 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. 20 P2PSIP Demonstrator