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 Organization B Internet Organization A 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 /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 SIP’s 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 Iterative search increases reliability Bootstrap Node Node-ID 023 Node B Node-ID 245 Joining Node Node-ID REGISTER 302 Node B 2. REGISTER 302 Node C 3. REGISTER 200 OK 4. Joining node after join Node-ID 503 Node C Node-ID 520

18 User Registration User’s node must register in DHT Node A Node-ID 023 Node B Node-ID 245 Alice’s Node Node-ID 503 Alice’s Node Node-ID 503 Alice -> REGISTER 302 Node B 2. REGISTER 200 OK Alice-> Alice’s Node SIP REGISTER used for nodes and users Node C Node-ID 520

19 Contacting a User Node A Node-ID 023 Node B Node-ID 245 Node C Node-ID 520 Alice’s Node Node-ID 503 Alice -> 234 Bob -> 723 Alice-> Alice’s Node Bob-> Bob’s Node DHT used for initial location SIP INVITE/MESSAGE used for location Bob’s Node Node-ID INVITE 302 Bob’s Node 2. INVITE

20 Session Establishment Node A Node-ID 023 Node B Node-ID 245 Node C Node-ID 520 Alice’s Node Node-ID 503 Alice -> 234 Bob -> 723 Alice-> Alice’s Node Bob-> Bob’s Node Standard SIP used for connection No reliance on DHT Bob’s Node Node-ID 683

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 we’re talking to, but There is no way to establish initial identity AIM, etc. provide no way to lookup handle Initial authentication addresses PGP web of trust CAs Face to face Big question: Is this the same person I’ve 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 ( 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