1 / 21

Peer-to-Peer Name Service (P2PNS)

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.

Download Presentation

Peer-to-Peer Name Service (P2PNS)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related