Peer-to-Peer Name Service (P2PNS)

1. 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. register()resolve() Name Service put()get() DHT route()lookup() KBR 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,…)

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

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

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 withnodeIDs of overlay neighbours • Efficient lookup of keysand nodeIDs in O(log N)

12. Bob   Alice REGISTER alice => 141.31.93.13 INVITE alice P2P-Overlay Contact: 141.31.93.13  141.31.93.13 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

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. 1001-2000 4001-7000 40.001-65.536 H(“sip:baumgart”)=2313 Node stores the mapping (sip:baumgart, NodeID) 0-1000 10.001-21.000 2001-4000 7001-10.000 21.001-40.000 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

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 andcore network • Fast implementation of newoverlay protocols • Scalability and flexibility due toa 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