SOSIMPLE: A Serverless, Standardsbased, P2P SIP Communication System

1
SOSIMPLE A Serverless, Standards-based, P2P SIP
Communication System

• David A. Bryan and Bruce B. Lowekamp
• College of William and Mary
• Cullen Jennings
• Cisco

2
VoIP/IM

• VoIP Voice over IP (Internet Protocol)
• IM Instant Messaging (such as AOL)
• Common components
• Resource location
• Session establishment and management
• Presence
• SIP IETF standard supporting VoIP
• SIMPLE IM extensions to SIP

3
Problems with Traditional Architecture
4
SOSIMPLE

• Self-Organizing SIMPLE
• Based on existing SIP/SIMPLE architecture
• Incorporates P2P technology for
• Scalability
• Secure messages
• Ad-hoc or limited connectivity
• Draft submitted to IETF

5
Talk Outline

• Introduction
• SIP/SIMPLE
• Motivating Scenarios
• Requirements
• SOSIMPLE Architecture
• Security and Performance

6
SIP/SIMPLE

• SIP
• IETF (Internet Engineering Task Force) defined a
  protocol for VoIP, called SIP
• Designed for packet networks, useful for any sort
  of multimedia session establishment
• Support for integration with email/web services
• SIMPLE is a set of extensions to SIP to support
  instant messaging

7
Why SIP?

• Widely used today for VoIP and IM
• Vonage, Microsoft MSN
• Large investment
• (phones, gateways)
• Effort (applications, stacks)
• Reuse/cheap COTS devices
• SIP is extensible we can extend for P2P
• Used SIPs REGISTRATION support

8
Scenario Small Organization

• Traditional VoIP and IM systems use centralized
  servers.
• Not appropriate for private messages.
• Internal chat systems used.
• Not compatible with external users.

9
Scenario No Internet Connectivity

• Disaster management
• Remote locations
• ISP failure

10
Scenario Ad-hoc Groups

• Meetings, classrooms, and conferences
• Desire to establish quick connectivity between
  those present.
• No need to configure a server.

11
Scenarios Access Scalability

• Censorship always a problem
• Government censorship
• Corporate/ISP censorship
• Scalability
• Reliability
• Easy to join
• Cheap!

12
Scalability Requirements

• No central server
• No central naming authority
• Simple system discovery
• Scalable number of users

13
Usability Requirements

• Privacy
• Multiple realms
• Interconnection
• User mobility
• Compatibility and reuse

14
Why P2P SIP?

• SIP/SIMPLE are existing standards
• widely used commercially
• supports both voice and IM
• P2P meets many of our requirements
• SIP is easily extensible to implement P2P
• Different than file-sharing
• false negatives unacceptable
• anonymity undesirable

15
SOSIMPLE Messages

• Basic approach is a DHT
• current implementation based on Chord
• All messages are SIP messages
• SIP headers extensible
• Modify REGISTER for node and user registration
• Traditional use of REGISTER sending user location
  information to registrar
• Now send user location to peer
• Also used for node registration

16
Why Use SIP Messages?

• No standard P2P protocol implementation
• Existing filesharing applications generally not
  appropriately extensible
• Filesharing most commonly blocked apps
• Many firewalls already recognize SIP
• OpenDHT emerging standard
• Centralized super-peers
• Still need independent P2P for private nets,
  hierarchies, and infrastructureless modes

17
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
200 OK
Node C Node-ID 520
4. Joining node after join Node-ID 503

• Iterative search increases reliability

18
User Registration
Alices Node Node-ID 503
Node A Node-ID 023
Node B Node-ID 245
Alice-gt Alices Node
Alice -gt 234
Node C Node-ID 520
Alices Node Node-ID 503

• Users node must register in DHT

SIP REGISTER used for nodes and users
19
Contacting a User
Node A Node-ID 023
Bob-gt Bobs Node
Bobs Node Node-ID 683
1. INVITE
302 Bobs Node
Node B Node-ID 245
2. INVITE
Alice-gt Alices Node
Alice -gt 234 Bob -gt 723
Node C Node-ID 520
Alices Node Node-ID 503

• DHT used for initial location

SIP INVITE/MESSAGE used for location
20
Session Establishment
Node A Node-ID 023
Bob-gt Bobs Node
Bobs Node Node-ID 683
Node B Node-ID 245
Alice-gt Alices Node
Alice -gt 234 Bob -gt 723
Node C Node-ID 520
Alices Node Node-ID 503

• Standard SIP used for connection
• No reliance on DHT

21
Presence

• Buddies located upon joining
• Serve as additional finger table entries

22
Security Concerns

• User Authentication
• Routing
• NAT Traversal

23
User Authentication

• Need to know who were talking to, but
• There is no way to establish initial identity
• AIM, etc. provide no way to lookup handle
• Initial authentication
• Email addresses
• PGP web of trust
• CAs
• Face to face
• Big question Is this the same person Ive talked
  with before?

24
User Authentication

• User authentication easy with public key
• Duplicate IDs necessary evil
• Can specify CA as source
• User mobility requires storing user profiles in
  network, relying on password encryption
• Some aspects of user authentication harder
  without trusted nodes (email addresses)

25
Routing

• Can we trust other nodes?
• DOS attacks by misrouting queries
• Iterative search simplifies problem
• DHT traversal unimportant after location
• Buddies locations cached
• Media routed end-to-end
• Social routing
• Finger table size

26
Related Work

• Skype
• Singh and Schulzrinne, NOSSDAV 2005
• SPROUT
• OpenDHT

27
Conclusions

• P2P ideal for user location
• SIP gives compatibility with existing tech
• P2P can never be fully secure
• Need to provide reliability with untrustworthy
  nodes and users
• IETF draft submitted
• http//www.p2psip.org/
• http//www.cs.wm.edu/bryan/lowekamp