PeertoPeer SIP

1
Peer-to-Peer SIP

• David Bryan
• July 27, 2005

2
Affiliation(s)
3
Overview

• Motivation
• What is Peer-to-Peer?
• Why P2P SIP?
• P2P basics
• Approaches to P2P SIP
• P2P SIP/SOSIMPLE
• Problems, barriers, and future work

4
What is Peer-to-Peer?

• Peer-to-Peer (P2P) technology
• Fundamentally different than client server
• Nodes cooperate to provide (collectively) the
  functionality a central server would provide
• Not all nodes provide all services/know
  everything, but as a group they do

5
What is Peer-to-Peer?
Client Server
???
???
???
???
6
What is Peer-to-Peer?
Peer-to-Peer
???
???
???
???
7
Motivating Cases

• Small deployments
• Security
• Lack of resource
• Limited/No Internet connectivity
• Ad-Hoc and ephemeral groups
• Censorship or impeded access
• Large scale decentralized communications
• Skype (sort of)

8
Client/Server Session
9
Problem w/Remote Server
10
Why P2P?

• Infrastructure independence
• No central servers
• Dont need connectivity
• Simple discovery and setup
• Privacy
• Highly scalable
• Lack of central control
• Dynamic DNS doesnt offer all of this

11
P2P Session
12
Why SIP?

• Widely established protocol
• Standards based
• Compatibility with existing equipment
• Reuse existing software components
• Many problems already solved
• SIP is already mostly P2P
• SIP vs. H.323
• Support for both IM and VoIP
• SIP/SIMPLE vs. XMPP

13
Related Work

• Skype
• Not as P2P as they imply, non-standard
• EarthLinks SIP Share
• Use SIP messages to encode filesharing DHT
• Others in this area
• Kundan Singh/Henning Schulzrinne at Columbia
  University

14
P2P Basics

• Most famous use of P2P is file sharing

• Most famous infamous use of P2P is file sharing
• Each user stores some number of files on the
  network, ask peers for the file
• Can also share other resources or services, no
  need to be files
• Connected to each other in a logical network
  called an overlay

15
Overlay Network

• Collection of nodes, connected logically in some
  way
• The connections in the overlay are frequently not
  related to those in the physical network

16
Flooding w/TTL
Node broadcasts to neighbors Node(s) respond
directly
TTL 1
TTL 2
TTL 3
17
Problems w/Flood

• Inefficient!
• Lots of network traffic
• Multiple nodes respond (can be good or bad)
• No guarantee of completion some outside of TTL
  horizon
• Nodes working on behalf of others
• DOS risk, but doubles traffic otherwise
• Gnutella was a flood based design

18
Structured P2P

• Basic idea is that what you are looking for has
  an identifier
• Locate items in the overlay based on the
  identifier
• Distributed Hash Table (DHT), Content Addressable
  Networks (CAN)
• Since everything has its place, eliminate false
  negatives
• Since you can go (close to) directly to the item
  you want, more efficient

19
Distributed Hash Tables

• Every resource has a keyword, hashed to produce a
  Resource ID, or key
• Every node participating hashes a unique property
  (IP address) to produce a Node ID
• The resource itself, or information about how to
  find it, for a particular Resource ID is stored
  at a node with a similar Node ID

20
Chord

• Algorithm/Implementation for a DHT in a circular
  namespace
• 0 and max ID are neighbors
• A resource w/key k is stored by the first node
  with Node ID k
• This node is called the successor node of key k

21
Example Chord Ring

• Example namespace is 0-31
• Wraps at 0/31
• Values increase clockwise
• Sometimes called an identifier circle

0
31
1
2
3
4
5
6
7
15
22
Example Chord Ring
Node A Node-ID 2
Item A, key 5
Node D Node-ID 29
Stores Item C, key 30
Item B, key 18
Item C, key 30
Node C Node-ID 18
Stores Item B, key 18
Node B Node-ID 13
Stores Item A, key 5
IDs/key namespace is 0-31
23
Finger Tables

• Each node keeps n fingers spaced around the
  ring to route messages (where address space is
  2n)
• Fingers point 1, 2, 4, 2n-1 away from the node
  the ring, so nodes know more about neighbors than
  distant nodes
• Most distant finger is ½ the distance across the
  identifier ring, so all fingers are in the nodes
  half
• If no node at the exact value the finger should
  point to, points to the next actual node

24
Example Finger Table

• Namespace 0-31 is size 25, so 5 fingers
• Node is 3, so fingers are

0
31
1
2
3
4
5
6
7
15
25
Example Finger Table

• Namespace 0-31 is size 25, so 5 fingers
• Node is 3, so fingers are

3
4
5
7
11
19
26
Example Finger Table

• If only nodes 3, 6, 11 are in the overlay

3
6
11
27
Routing in Chord

• Chord routes by sending messages to some node
  nearer the desired resource
• The nearer node sends to an even closer node on
  behalf of sender
• Process repeats until a node receiving the
  message knows its successor controls that space
• Returns address of successor, sender and
  responsible node then exchange data

28
Applying this to SIP

• Use pure DHT to find the other UAs
• Could leverage standards for DHT, but there
  arent any
• Some firewalls block DHT traffic as file
  sharing
• Use DHT for location, but implemented as SIP
  messages
• Essentially, use DHT as another
  registration/location mechanism
• Requires some tweaks to Chord
• Use standard SIP to signal once resources are
  located

29
SOSIMPLE

• Protocol suggested by myself and Cullen Jennings
  of Cisco
• Available as IETF Internet-Draft
• Implemented and being studied at William Mary
• Implements a Chord-like DHT using SIP
• All traffic is SIP messages
• Very similar to Chord, only slight changes

30
Node vs. User Operations

• Operations can be either Node operations, or User
  operations
• Node operations are DHT related a node joining,
  a node leaving, a node updating its finger table
• Use REGISTER for much of this
• User operations are completely separate
• More traditional SIP registration here
• Registration is stored by Resource ID of hashed
  username
• A users node has a Node ID, but their User ID,
  and thus registration, will be stored at a
  different node
• Once a users node joins, only means the node is
  in the DHT. Still need to do a user registration
  to make calls

31
Node Joining
Joining Node Node-ID 503
1. REGISTER
Bootstrap Node Node-ID 023
302 Node B
2. REGISTER
Node B Node-ID 245
302 Node C
3. REGISTER
Differences from Chord node answers for itself
doesnt return successor that controls, iterative
vs. recursive
200 OK
Node C Node-ID 520
4. Joining node after join Node-ID 503
32
User Registration
Node A Node-ID 023
Node B Node-ID 245
Stores Alices Registration
Node C Node-ID 520
Alices Node Node-ID 503
33
Session Establishment
Alice hashes Bob and gets 011 Alice searches for
a registration with User ID 011, sends invite
to Node A (023)
Node A Node-ID 023
Bob-gt Bobs Node
Bobs Node Node-ID 683

• INVITE
• Bob

Alice (User ID 234)
Node B Node-ID 245
Bob (User ID 011)
Node C Node-ID 520
Alice-gt Alices Node
Alices Node Node-ID 503
34
Session Establishment
Node A stores a registration for Bob (User ID
011) and returns Bobs Node as a contact in a 302
Node A Node-ID 023
Bob-gt Bobs Node
Bobs Node Node-ID 683

• INVITE
• Bob

Alice (User ID 234)
302 Contact Bobs Node
Node B Node-ID 245
Bob (User ID 011)
Node C Node-ID 520
Alice-gt Alices Node
Alices Node Node-ID 503
35
Session Establishment
Alices UA now invites Bobs UA Call set up
proceeds as normal
Node A Node-ID 023
Bob-gt Bobs Node
Bobs Node Node-ID 683
Alice (User ID 234)
2. INVITE Bob
Node B Node-ID 245
Bob (User ID 011)
100, 180, 200
Node C Node-ID 520
Alice-gt Alices Node
Alices Node Node-ID 503
36
Session Establishment
Node A Node-ID 023
Bob-gt Bobs Node
Bobs Node Node-ID 683
Media and further signaling flow directly between
UAs
Alice (User ID 234)
Node B Node-ID 245
Bob (User ID 011)
Node C Node-ID 520
Alice-gt Alices Node
Alices Node Node-ID 503
37
Presence/Buddies

• Subscribe/Notify used for presence
• Subscribe to all available buddies at startup and
  periodically
• Serve as additional finger table entries

38
Encoding P2P in SIP

• SIP URI parameters
• alg (defined in draft-ietf-sip-identity) to
  convey hash algorithm used
• usernode used when messages are about node
  operations, rather than user
• resourceID used on user messages to indicate
  what a resource hashes to
• overlay-name indicates name of the particular
  overlay (can be more than 1)

39
Encoding P2P in SIP

• New headers
• DHT-NodeID defines sending nodes node ID
• DHT-Link used by nodes to exchange information
  about fingers, successors, predecessors

40
Encoding P2P in SIP
Register for a node first joining the overlay
REGISTER sip10.7.7.1 SIP/2.0 To
sip4737a8fe3d_at_10.4.2.2usernodealgrsa-sha1ove
rlaychat From sip4737a8fe3d_at_10.4.2.2usernode
algrsa-sha1overlaychat Contact
sip4737a8fe3d_at_10.4.2.2usernodealgrsa-sha1ove
rlaychat Expires 600 DHT-NodeID rsa-sha1
4737a8fe3d 10.4.2.2 Require dht Supported dht
41
Encoding P2P in SIP
Response from accepting node
SIP/2.0 200 OK To sip4737a8fe3d_at_10.4.2.2usern
odealgrsa-sha1overlaychat From
sip4737a8fe3d_at_10.4.2.2usernodealgrsa-sha1ove
rlaychat Contact sip4737a8fe3d_at_10.4.2.2userno
dealgrsa-sha1overlaychat Expires
600 DHT-NodeID rsa-sha1 34f2a82eee
10.7.7.1 DHT-Link P 1 rsa-sha1 312a18dd12
10.8.7.5 DHT-Link S 1 rsa-sha1 3863a23ad1
10.11.22.233 DHT-Link F 2 rsa-sha1 459a1211df
10.101.0.45 DHT-Link F 3 rsa-sha1 a61bd8c100
10.210.78.101 Supported dht Require dht
42
Encoding P2P in SIP
User Registration
REGISTER sip10.5.22.112 SIP/2.0 To
sipalice_at_10.4.2.2 algrsa-sha1overlaychatreso
urce-ID51a6f9098d From sipalice_at_10.4.2.2algrs
a-sha1overlaychatresource-ID51a6f9098d Contact
sipalice_at_10.4.2.2algrsa-sha1overlaychatres
ource-ID51a6f9098d Expires 600 DHT-NodeID
rsa-sha1 4737a8fe3d 10.4.2.2 Require
dht Supported dht
43
Problems with P2P SIP

• Like most things SIP, NATs
• Same problems, plus some new ones
• Super nodes?
• Security
• Sybil attacks
• DOS (through traffic and true denial)
• Encryption
• Information leakage
• Choosing node locations to divert/block

44
Future Work

• Improved Security
• Adding features
• Configuration information, VM storage
• Using overlay for voice traffic as well
• Alternate methods for routing
• Comparing different P2P approaches

45
References

• draft-bryan-sipping-p2p-01
• D. A. Bryan, B. B. Lowekamp and C. Jennings,
  SOSIMPLE Towards a Serverless, Standards-based,
  P2P Communication System, AAA-IDEA, June 2005
• Stoica et al., Chord A Scalable Peer-to-Peer
  Lookup Protocol for Internet Applications,
  IEEE/ACM Transactions on Networking (to appear)
• (Dont use the algorithms from SIGCOMM paper by
  same authors with same title it contains some
  algorithmic errors)
• I maintain a list of references at
• http//www.p2psip.org
• Contact me via email
• bryan at ethernot dot org