peer to peer name service p2pns
Download
Skip this Video
Download Presentation
Peer-to-Peer Name Service (P2PNS)

Loading in 2 Seconds...

play fullscreen
1 / 21

Peer-to-Peer Name Service (P2PNS) - PowerPoint PPT Presentation


  • 93 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Peer-to-Peer Name Service (P2PNS)' - joshua-hernandez


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
What’s different to other proposals?
  • Flexibility
  • Modular architecture
  • Two-stage name resolution
  • Focus on security in a completely decentralized environment
  • Implementation
flexibility
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)
modular architecture

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,…)

two stage name resolution
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
p2pns example register

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

p2pns example invite

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

p2pns security
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
p2pns implementation
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
key based routing kbr
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)
kbr for p2psip

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
attacks on node id generation
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
secure nodeid generation
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
attacks on message forwarding
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
choosing an overlay for kbr
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
kbr is not sufficient

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
dht security is expensive
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
overlay framework oversim
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
ad