SOSIMPLE Self Organizing SIMPLE A Proposed P2P Instant Messaging System

Transcription

1 SOSIMPLE Self Organizing SIMPLE A Proposed P2P Instant Messaging System David A. Bryan College of William and Mary, CSCI 780, P2P and Grid Systems December, Introduction Instant messaging (IM) has become one of the most popular applications on the Internet today. Instant messaging has grown from its roots in chat applications such as ICQ to become an important tool for not only personal chat conversations, but also for collaboration in business and academia. Current instant messenger (IM) protocols are largely centralized in nature. These systems require that the clients of the machines be connected to a central server which not only relays messages, but controls the flow of information between the nodes. This approach has proved unattractive for a variety of reasons, including privacy, optimization of traffic, a desire to remove any central control, and reducing the reliance of the system on any particular organization or machine. Peerto-Peer (P2P) network technology offers an avenue to allow such a system to be self organized. This paper explores the current state of instant messenger protocols, along with closely related communications systems, and explores modifying one of these protocol families (SIP/SIMPLE) to be self organized by leveraging P2P technology. As IM use among organizations has increased, some limitations to the current structure of IM systems have emerged. All of today s most popular IM clients require users to connect their clients to a central server. Not only does this impose the overhead of an external internet connection, but it requires companies to transmit potentially sensitive internal information offsite to a third party. Many companies are not comfortable with this, and have gone so far as to preclude the use of these public IM clients to exchange information between employees. Additionally, individuals and groups who would prefer to have a communication system that is free of these central servers are interested in an alternative approach. In a partial response to this, several companies now offer IM servers that can be installed by a local administrator on local machines, allowing information to be exchanged between individuals within the organization without having to connect to a central server and risk the potential of information being leaked. These systems provide an attractive solution for companies or large organizations that can afford them, but are not well suited to individuals or groups that wish to have a communication system and cannot afford these turn key solutions. A final class of instant messenger solution is the open source IM server. This system is available at a far lower cost to individuals who might not be able to afford a turnkey solution. One such system that has seen widespread adoption is Jabber. [13] Several open 1

2 source servers and clients, all implementing the Jabber protocol are available. While this solution solves the financial problems faced by small groups, there are often other hurtles to be faced. The organization may not have the technical expertise to install and maintain a Jabber server, or the group may not have access to a dedicated, always-available machine on which to host the server. For these individuals, having a serverless design is very attractive. P2P technology seems the ideal way to create such a system. The self organizing nature of the technology can be leveraged to allow nodes interested in participating in an IM session to locate each other, and the nodes can then communicate directly with each other, using some existing IM protocol. This solution requires no server and doesn t force users to resort to using some central system for IM. 2 Existing Instant Messaging Systems 2.1 Centralized Systems There are a wide variety of centralized instant messenger systems available to users today. The most popular are commercial offerings, with full centralized control. These include AOL s AIM [17], Yahoo! s Messenger [18], and Microsoft s MSN Messenger [19]. All of these applications require the user to download a client program, and use this client program to connect to their server. The namespace of user names is defined and controlled by the central server s organization. Applications that allow users to install and maintain their own central server include Microsoft s commercial Office Live Communication s Server [20] and Jabber. 2.2 Waste A search of the internet for P2P based instant message projects will return several references to a software project called Waste [12]. Waste was created by Nullsoft, later acquired by AOL, maker of the AIM instant messaging protocol. The software was briefly released under the GPL [16] by Nullsoft, but was pulled within days by AOL. While there was a brief flurry of interest, interest in the application seems to be thin, possibly because of the murky legal status of the application. Waste is a P2P product that incorporates conventional P2P file trading, instant messaging, and chat conferencing. The application s most critical differentiator is that the system using very strong encryption and relies on trust between the nodes as the basis for the system. Waste uses strong cryptographic keys to limit access to the network and to encrypt the traffic, and requires that some node in the overlay network grant permission before a new node is allowed to join. The size of the network is intended to be limited to 50 or fewer highly trusted users a constraint that is required to address what would otherwise be serious scaling and security problems with the system. Once connected to a waste overlay network, the instant message aspects of waste are highly P2P in nature. Presence is a term used in instant messaging to refer to the ability of users to see if other users are connected, and to notice when they leave. For example, a 2

3 user may have a list of individuals with whom the user wishes to communicate. These users are often called friends or buddies. Presence allows the user to see when a friend has entered, perhaps by highlighting that user on a list displayed on the user s GUI. Presence is implemented in waste with two mechanisms. First, each user periodically broadcasts on the network, particularly when they user first connects to the overlay network. This has the function of alerting others on the overlay that they are logged in, and allowing users to determine if and when the user has left the overlay. Additionally, a user can broadcast (using a Gnutella [21] flood like mechanism) a request asking each node in the overlay to reply with their user name. This provides a mechanism for quickly determining who is on a network at any given time. Since this is broadcast, as are the replies, anyone on the network will be able to know the complete status of users logged in at any time. Text messages are also broadcast to all users. Again, the fact that this is a trusted network is extremely important here. Every message sent from a user is broadcast using a flood mechanism to every other client. Theoretically, a packet sniffer placed in the overlay (assuming the user was within and could decrypt) would be able to monitor any and all conversations that are taking place within the network. Replies are routed back through the overlay to let the sender know that the message has been received. The documentation available does not specify if the reply is returned to the sender informing him that the message has been received or if the message is sent when the message has been read. Group chat messages are broadcast in much the same way that text messages are relayed. The messages include fields specifying which channel the message is associated with and what user sent the message. Client programs look at the channel name and display the chat if the user is monitoring that channel. Again, all messages are available to anyone on the overlay, and no authentication is in place to ensure that the sender listed in the message is really the sender of the message, further illustrating the requirement that users on the overlay be trusted. While Waste represented a very simple P2P based IM system, it had a number of shortcomings. The system used a flood based technique not only for resource location, but also for message transmission. This made the system impractical for any system where all of the nodes were not trusted. In addition, this limited the scalability of the system, since any system with thousands of users cannot require each user to relay the messages, even if the messages are encrypted in transit to protect the messages. 3 A New Approach to Instant Messaging We propose a system that uses a structured P2P system as a mechanism for resource location and presence, but uses a direct communication mechanism to exchange the actual text messages, or whatever other sort of media is to be exchanged (voice, video, etc.). We wish to leverage to as great an extent as possible existing technology and protocols for both the P2P and IM portion of the application. 3

4 3.1 Motivation, Objectives and Assumptions Beyond the desire to use P2P technology and eliminate central control to the greatest extent possible, several factors motivated this design. We strongly believe in the reuse of existing work, protocols, and code, and therefore wanted to build this system, as much as possible, on existing protocols for which stacks were available. Ideally, the protocols should be widely recognized standards, and any software on which to we base an implementation should be available open-source. In order to keep our design simple and practical, we have made a number of assumptions. We assume that relationships between individuals in a P2P network are bilateral. Although most current instant messenger systems allow a user to add a friend without that individual reciprocating, this situation seems the exception rather than the rule. We assume that in order to add a user as a friend, that user must accept the arrangement and by so doing adds the friend as well. 3.2 Basic Design The basic approach is to use a structured P2P system to locate other users, and use this same P2P network to support presence. An existing IM protocol, perhaps with the location and presence portions excised, can then be used to connect the users and to facilitate conversations between them. 3.3 IM protocol There are many possible candidates for an IM protocol to modify. The authors wanted a protocol that is open, widely adopted, and for which several implementations exist. Two protocols seemed to meet the requirements. Both of the protocols that were considered are in development within the IETF [22], and both have existing bases of users, showing that the protocol is reasonably stable and robust. XMPP [14, 15] is an XML based protocol for IM. This protocol grew from the non-ietf protocol used for the Jabber project. The system exchanges all information, whether for location, presence or communication, in XML encoded messages. SIMPLE [2, 5, 6, 8] is a set of extensions to the SIP protocol [1, 7, 9, 10]. SIP is an IETF protocol in wide use for connecting IP telephony devices, also known as Voice over IP (VoIP), although SIP was designed generically to allow the establishment of multimedia sessions between two clients. SIP was extended with a number of additions needed to support instant messaging, resulting in the SIMPLE protocol. Several SIP implementations, including the stack needed to build applications, basic clients, and the central proxy server required are available, as are a number of SIMPLE enabled client applications. Open source versions of all these components are also available. SIP and SIMPLE are heavily based on the HTTP protocol, and so the message types and traffic are very similar to conventional web traffic. The information needed to make a 4

5 multimedia connection is carried in SIP messages, but the actual media of the session streams directly between the two participating endpoints. In SIMPLE, the text messages are exchanged directly in SIMPLE protocol messages, and no media connection is established. Although both protocols appeared to be good candidates, the author chose SIMPLE for a number of reasons. The ability of SIMPLE to more easily support multimedia sessions was attractive. Although the primary use of instant messaging is to exchange text based messages, many of the existing commercial IM clients allow for voice and video conversations. SIMPLE appears to have better support for this, simply because it grew from a protocol designed specifically to handle such conversations. Additionally, because SIMPLE is a set of extensions to SIP, changes made to a SIMPLE compliant SIP stack would allow not only for a decentralized instant messaging client, but also for decentralized VoIP. The disconnection of the media and signaling in these protocols is nicely analogous to existing P2P systems, where requests to find a file are used in the overlay network, and the file is transmitted directly between the endpoints. One of the most popular centralized instant messenger clients, Microsoft s MSN Messenger, is currently based on SIP and SIMPLE, which provides further incentive to use this protocol. 3.4 SIP and SIMPLE SIMPLE builds upon the SIP protocol, and much of the underlying technology used to locate resources, route messages, and establish sessions is shared between SIP and SIMPLE. SIP uses the notion of a proxy to locate and provide name resolution services. Before we discuss how to modify the behavior of SIMPLE to locate resources using the P2P network, we will briefly discuss how SIP and SIMPLE locate resources and communicate with them. Resource location in SIP works using a registrar based system. Users connect to a SIP system using a user agent (UA). In the case of a SIMPLE application, this would typically be an IM client. In the case of a pure SIP application, it could be an IP telephone, a video conferencing system, or a software program. Users are identified by an address of record, which uniquely defines an individual within a SIP system. Typically, these addresses are much like addresses or web URLs. In SIP, this is called SIP URI s (Universal Resource Identifiers) and typically look something like sip:bryan@cs.wm.edu. When a user wishes to make themselves available to be contacted at a particular SIP user agent, they send a SIP REGISTER message to a central SIP entity called a registrar. In practice, most SIP servers incorporate this registrar functionality along with other functionality, allowing a single central server to serve multiple roles (registrar and proxy server, for example) within the SIP network. This REGISTER message includes a contact the address and port where the user agent is listening (typically, port 5060 is used for SIP and SIMPLE), and the address of record that the user wishes to bind to this client. After receiving the message, the server knows that any messages that arrive for the address of record should be routed to the address and port that the register message contained. SIP allows for the notion of multiple registrations, and supports different 5

6 methods for trying these registrations, called forking. Several ways to fork exist, such as trying the multiple addresses in parallel, sequentially, etc. Registrations are provided with an expiration. If the registration is not refreshed after a certain period of time, the contact provided for the address of record will be removed. Clients need to periodically refresh their registrations. This mechanism ensures that registrations do not become stale. Typical values for the duration of a registration are around one hour. A registration time of zero can be used to explicitly unregister a connection, for example if a user goes home for the day and no longer wants to receive messages on a particular client. Once a client is registered, an incoming message intended for the address of record will be resolved by the proxy and forwarded to the client. If the user that is being contacted is not registered with the proxy, local rules may be consulted to determine how to route the call, the call may be rejected, or the URI may be examined and the request proxied to a different domain to be processed. A client placing an outbound call communicates with the proxy/registrar, meaning that the client need only know one address to communicate with many users, rather than having to know the individual addresses of all the users with which one might wish to correspond. However, SIP (and SIMPLE) has been designed in such a way that if one knows the address of the remote party, the central proxy is not needed. Session establishment in SIP (for a media session) and message passing in SIMPLE can be performed without a proxy, so long as the endpoints know the addresses where each can be reached. Since this is a required function of the protocol, all stacks will allow this behavior. Our design simply uses the P2P network to provide these addresses, rather than leaving this job to the proxy. Once we have the address of the person with whom we wish to communicate, a SIP media session can be established using a triple handshake mechanism, or an instant message conversation can be carried out using SIMPLE. First, assume caller Alice wishes to contact Bob using a media session. Alice sends an INVITE message to the Bob, who eventually replies with a response of 200 OK. Alice replies with an ACK, completing the triple handshake. Media (video, audio, or other) is then streamed between ports specified in the INVITE and ACK messages. When the session is completed, one side sends a BYE message, which is acknowledged with a 200 OK, and the media stream is terminated. All of these messages make up a single session, and are used to establish and tear down a media session. In SIMPLE, a new SIP message called MESSAGE is defined. Unlike the messages above, there is no notion of a session in SIMPLE. The analogy given in the draft is that of a pager. A message is sent from party to the other, and displayed by that user s client. Unlike a media session in SIP, there is no need to establish or tear down a session. User Alice sends a text message using the MESSAGE message to Bob, who responds with a 200 OK. If Alice wishes to send another message, she uses a new MESSAGE. Each piece of information that is sent is independent of the other. Any correlation of the messages 6

7 into a conversation is simply an effect of the user s client program. The underlying messages are completely separate transactions. Because of the close relationship between SIMPLE and SIP, a SIMPLE client that wishes to enable voice chat can do so very easily using the established SIP protocol. All of the SIMPLE messages and SIP messages use a common rule set for parsing and message construction, so one stack can be used to enable both applications. SIMPLE and SIP also offer a SUBSCRIBE/NOTIFY functionality. This functionality allows a device to subscribe to a particular string. When the string occurs, a NOTIFY message is sent. This is used in SIP for several things, the most common being for a phone to be told when voice mail is waiting. In SIMPLE, a user subscribes to their friends by name using the registrar, and the registrar informs the client when that user arrives or departs. Again, the SUBSCRIBE/NOTIFY can be used directly between endpoints, just like all other messages. Finally, SIP and SIMPLE offer redirect functionality. When a MESSAGE or INVITE is sent, a response (302 Moved Temporarily) can be returned informing the sender that the person they wish to reach has moved. A contact much like the contact used in register is returned, containing an address of record, with IP address and port where the user can be reached. When this happens, the sender is expected to try to contact the individual using this new address of record at the new IP and port. This functionality is essential to mobility allowing a user to move from one device to another and still have messages reach them. The approach taken by the authors in this design is to leave the SIP call establishment and SIMPLE messaging mechanisms largely untouched. The registration functionality is augmented by the P2P system, and presence is supported using a combination of existing SIP/SIMPLE functionality and P2P. 3.5 P2P protocol The choice of a P2P protocol was also open. We wanted to find a system that met the requirements outlined in the motivation. Finding a system that allowed for numerous usernames to be registered seemed essential, since some existing IM networks have thousands or even millions of users. The two P2P systems that were examined were Chord [3, 4, 11] and Pastry. [23] Both Chord and Pastry seem to be well suited for our application. Either one provides a large hash space in which to locate a name. Both provide mechanisms for locating the node that is associated with a particular name. Pastry attempts to exploit locality within the network, but we expect that because of the geographically distributed nature of IM friends this isn t a particularly strong benefit often, one uses such a tool to keep in touch with friends from around the globe. 7

8 Chord was selected primarily because a library for the protocol was readily available under a completely non-restrictive public domain license. This, along with the ready availability of open source SIP/SIMPLE applications means that a prototype can be constructed from readily available software components. Additionally, Chord is a very simple system. Most of the advanced features of a P2P network, such as replication and authentication, are left to the application. Since we are attempting to merge two protocols, with widely differing goals, the minimum functionality seemed ideal it left the most room for bringing functionality either from the SIP/SIMPLE protocol or allowing for a SIP/SIMPLE compatible decision. 3.6 Resource Location in Chord We assume the reader is largely familiar with Chord, and will only briefly review the basics of resource location in Chord. For further details, consult [3, 4, 11]. Resources are located in Chord using a consistent hashing algorithm. Keys are hashed into an identifier circle, so that the namespace within a Chord overlay maps as a circle. Successors to each node, which are often used to provide reliability, would be those locations in the identifier space that follow the location a particular key hashes to. To improve performance, each node n keeps references to directly access nodes n+1, n+2, n+4,, n+2 k. These references are kept in a table called a finger table, which allows for rapid access to a particular location. When a node wishes to find a location, it hashes the key, and finds the entry in the finger table that points as close to the destination as possible, without going beyond it. The request is forwarded to this node. From there, that node uses its finger table to forward the message closer to the destination. Eventually, the node nearest the key requested should store the information related to that key. This algorithm provides a O(log n) mechanism for locating the desired resource. Nodes use their IP addresses to hash into the Chord namespace, and the node nearest to a keys location in the namespace will be responsible for storing information related to that key. 4 Design of the SOSIMPLE System We chose to name our system SOSIMPLE, as it was based on the SIMPLE protocol, but extended to be Self-Organizing (SO) Although the details of the inner workings of each message within the SIP/SIMPLE and Chord protocols is outlined above and presented in detail in [1, 2, 3, 5, 6], we will present how these tools are used together to enable SOSIMPLE. We will then discuss some issues and problems facing us in the implementation of SOSIMPLE, and discuss research into candidate software that that can be used to create a working SOSIMPLE prototype. Users select their own usernames, which should be a valid address for the user. Because addresses are unique, using an address will ensure that no one else 8

9 : : :5060 has selected a similar address. Enforcement of this constraint to ensure that no usernames are duplicated and that users are who they say they are is the largest problem currently known with this system, and is discussed below. The application that the user uses to connect to the system will be referred to here as a User Agent (UA), following SIP/SIMPLE convention. This application needs to include a SIP stack with SIMPLE extensions. It must handle basic SIP registrar functionality (in this case, this simply means being able to receive a REGISTER message and store a mapping between an address of record and a contact), as well as redirect (providing the contact when a message arrives). Finally, the UA must incorporate the Chord library. 4.1 Registration, Location and Presence Location of resources is performed using the Chord P2P system. When a user s UA enters the system, they use the Chord library to hash their username to a node. Chord provides no replication, but a recommended strategy is to save data not only at the node for which the data hashes, but at the following k nodes as well. Accordingly, after hashing their username to a Chord node, the UA sends a SIP REGISTER message to the node and its k successors. The contact field of the registration contains the IP address and port on which the user s UA is listening. Each of the nodes now has a registration, and knows where the user can be contacted. At the time of writing, an effective value for k has not been determined. We feel that either a simulation, or perhaps actual tests with a prototype implementation will be needed to determine an effective value. Figure 1 illustrates an example. Alice starts a UA at :5060 and connects to the overlay. Her username, alice@alice.com hashes (hypothetically) to a node located at , and the k=2 successor nodes are at and Alice sends a SIP REGISTER to each one, and receives a 200 OK in response. Each node now stores a mapping from alice@alice.com to :5060. Only the messages between Alice and the first node ( ) are shown the remainder are omitted for clarity. Figure 1 alice@alice.com hashes to in the Chord ring Alice s UA :5060 (1) MESSAGE (2) 200 OK Node Map: alice@alice.com Node Map: alice@alice.com Node Map: alice@alice.com 9

10 :5060 As with any SIP registration, this one will expire after a time. If, for example, Alice leaves the network, her registration will expire after some time. Since IM clients enter and leave quickly in many cases, we recommend a short registration expiration perhaps 60 seconds. Alice needs to hash every time before sending these registrations it is possible that some nodes have left the network, and she wants to subscribe with the primary and k other nodes every time she sends her subscribe messages. When a user wishes to send a message another, a similar process takes place. Assume Bob wishes to send an instant message to Alice. Bob hashes Alice s user ID using the Chord library, and gets He sends the MESSAGE to :5060. When this node receives the message, it examines it. If Alice was not registered (for example, if she was logged off), the SIP return code 404 Not Found would be returned. Since Alice is registered, it sends a SIP redirect (a 302 Moved Temporarily) to Bob. Bob then contacts Alice at the contact provided (figure 2) in the 302. Once the message arrives at Alice, her UA will send a 200 OK, indicating the message has been received (although not necessarily read) (3) MESSAGE Alice s UA :5060 Bob s UA :5060 (4) 200 OK (1) MESSAGE (2) 302 Moved Temporarily Node Map: alice@alice.com Figure 2 Bob will also cache this contact, using that address to contact Alice in the future. If he subsequently fails to contact Alice, (for example, if he sends a message and receives no 200 OK), he will try the hash again, hoping to find Alice s address. In addition, if he hasn t already, Bob sends a SUBSCRIBE to Alice, asking her to inform Bob with a NOTIFY if she disconnects from the network. Alice will also periodically (we suggest every 60 seconds) send a NOTIFY message to Bob informing him she is still available. As the SIP PUBLISH draft [24] comes into wider use, we suggest migrating to this from the current SUBSCRIBE/NOTIFY. The SUBSCRIBE/NOTIFY mechanism will also be used for other aspects of presence. Each user maintains a list of usernames that are friends. These users are allowed to send messages to the user, and the user wishes to know if these friends become available. When a user receives a message from a user who is not on their friend list, the UA will ask the user if they wish to add this person as a friend. If they say yes, the user will be 10

11 added to the friend list, otherwise, they will not be. Friend lists are symmetric. Both sides must agree for the user to be added. When a user first logs on, they hash all the users in their friend list, and attempt to send a SUBSCRIBE to each of them. Subscriptions will be successfully established with those that are logged on, and the SUBSCRIBE/NOTIFY mechanism will be used to see if they continue to be logged on. For those that are not logged on, the UA will periodically (perhaps every seconds) attempt to subscribe to those users. As we assume symmetric relationships, it is expected that those users who are logged on will also be subscribing back, so that both sides will be able to monitor the status of each other. Although it is beyond the scope of this paper, one can also recreate some of the functionality of popular IM clients using the SUBSCRIBE/NOTIFY mechanism. One could subscribe not only to information about whether the user is still logged on, but also information about idle time, and away messages. As above, if the SIP PUBLISH draft comes into wider use, we would recommend its adoption for presence. 4.2 Sending Text Messages As discussed and shown in the examples above, instant messages are sent between the nodes at the SIP/SIMPLE level using the MESSAGE method. The overlay and Chord library need only be involved in a few cases. If the user is sending to someone who they have not already subscribed to (for example, the first time that a user contacts another user), then as shown above we must use the overlay hash to locate the target of the message. Similarly, if a message is sent and no response is received (the message times out), then any cached contact value is invalidated, the overlay consulted, and a new MESSAGE sent to the result of this cache. Once the UA has a valid address for a particular destination, and is receiving updates to confirm that the destination is still alive, the exchanging of messages requires no involvement of the Chord overlay. As mentioned above, these messages are not correlated into a session, but rather sent individually, as specified by the SIMPLE protocol. As such, there is no need to maintain any state for instant messaging, other than the cache of the current location of a user. Advanced instant messaging, such as sending simultaneously to multiple clients, has not yet been explored. Traditionally, this has been handled at the proxy level in SIMPLE, but could likely be handled here by maintaining multiple entries in the cache for a given contact. 4.3 Voice or Video Sessions SIP voice or video sessions can be easily supported, since a voice session can be established between two devices directly, bypassing the proxy. Adding this logic does slightly complicate the logic of the system. MESSAGE methods have no session, so every single message is sent to the contact for a particular user, and the response (200) is sent back to the sender. 11

12 In the case of a voice or video session, we need to maintain some state for the session. The call can last for an extended period of time, after which a BYE message is sent. It is possible that, for some reason, the user has switched to a different device and their contact has changed since the beginning of the media session. As an example, suppose Alice calls Bob, but then some time later logs in from a different client, while still maintaining the call. When Bob hangs up some time later, he must sent the BYE message to Alice s original client, not the new client she has logged on with, since the media session is with that original client. In practice, this problem should be rather easy to solve. Most SIP stacks today maintain this state for the user, and we anticipate that anyone implementing this service would use an existing stack, rather than try to develop a new one. 5 Problems and Issues While we feel this approach is likely to work very well in practice, there are some shortcomings that we have identified. Only one of these shortcomings appears to be serious in nature, and we hope that some additional thought will allow us to solve these problems. We have also identified a few problems that affect most systems of this type. 5.1 Security Probably the single greatest issue with this system is security. While we do not intend to implement it in the first version, SIP/SIMPLE offers mechanisms for using secure and encrypted traffic both on the signaling information (which would include the MESSAGE methods carrying text messages), as well as for negotiating and specifying encryption for the media. The problem that we see arising with security, and have not yet solved, is how to prevent one user from spoofing another. At present, a user connects to the system by registering with a particular node and claiming to be a particular user. From this point forward, messages will be routed to this user. There is very little in place to stop a malicious user from registering as some other user and intercepting their messages. SIP/SIMPLE systems with central servers solve this problem by storing a password, and use this to issue a cryptographic challenge to the user that is attempting to register. Such a mechanism won t work with this system, as there is no central server. Our current thought on this issue is to not worry about the registration, but rather use a public key mechanism end to end so that both ends can use to confirm the identity of the sender. This public key information could be obtained from a web page, in much the same way that a user can obtain a PGP key of another user to ensure their identity. The problem is similar to that of one can send claiming to be someone else quite easily but is exacerbated by the fact that one can also intercept messages intended for another something that does not happen with . 12

13 5.2 Multiple Outbound SIP/SIMPLE Contacts While a far more minor problem, one needs to deal with the issue of having to contact multiple SIP destinations. Most SIP stacks are designed to send all initial outgoing messages to a particular proxy, but in our case, we need instead to consult a local cache for the destination, or, failing that, do a Chord lookup. Fortunately, many stacks, including the one we mention later, use a call to a provisioning system to get the address outbound proxy each time it is needed. Simply modifying this call to access the contact cache and/or Chord lookup can done with a minimum of effort. 5.3 Bootstrapping As with all P2P systems, our faces the issue of bootstrapping. In order to join, one must locate a node in the P2P network. We anticipate addressing this in much the same way as earlier P2P systems. A user can visit a well known web page, or perhaps well known Chord node that will allow them to access the system. In the future, a broadcast approach could be used. Such a system would attempt to locate a node already participating in the Chord network that is near the user. While this is a desirable improvement, it might introduce a security risk. If the local node was a dummy, leading users to non-functional or compromised overlay, it could fragment the overlay. 5.4 Conference Calls Implementation of multiparty chat or voice conferencing is a difficult issue. For text messaging, one would need to track all of the participants in the conversation, perhaps through an out of band mechanism such as the SIP INFO message, and ensure that messages for people in the conversation are routed to all of the participants. While this is possible, the mechanism seems prone to failures of coherence, where some users miss messages. Voice or video conferencing is even more difficult. The present mechanism for implementing this in SIP systems requires a centralized audio mixer. Each user sends their audio stream to this central server, where the streams are mixed and a single stream is sent back to each user. It is possible to mix audio streams locally at each client, but this requires the high expense of sending each audio stream to each participant, which clearly would not scale for large numbers of users. While this is not a show stopping problem, it is a functionality that is currently supported by most IM clients, but will be difficult to implement in our system. 13

14 6 Implementation While we have not completed an implementation, we have located software to be used for the modification. We have examined this software to ensure that it can be used to implement the desired functionality, and have started to modify the code. 6.1 Selected Libraries/Applications As discussed above, we have chosen to use the Chord P2P library. This library is available from the MIT Chord website. [11] This library is very simple, providing primarily support for hashing and locating resources. As such, the Chord library appears to be able to be used without modification. Several open source SIP stacks are available. [25, 26] We opted to use the ReSIProcate project. This project has currently developed a fully compliant SIP/SIMPLE stack, which incorporates most of the new features introduced to SIP in the last year. The stack is built on C++, and features a very high level API, making it quite simple to modify. Additionally, ReSIProcate is one of the few SIP stacks that includes fully tested SIMPLE support. The GAIM [27] instant message client has been modified to use the ReSIProcate stack, and an all new SIMPLE client called SIPImp [28] is also based on the ReSIProcate stack. We have chosen to modify SIPImp. While GAIM has a larger user base and more advanced features, it is also a larger and more complicated piece of code. SIPImp is a very basic SIMPLE client, offering only basic SIMPLE functionality, and seems the logical choice for prototype modification. 7 Conclusion and Future Work It appears that, if the security problem of spoofing can be solved, SOSIMPLE would be a viable and easy to implement approach to P2P based IM. The leveraging of existing clients will allow this to be more easily implemented. Using SIP/SIMPLE as the IM protocol will allow for rapid integration of multimedia sessions. Future work for this project includes completing a working implementation, and testing the practicality of this system. While it appears that it will work quite well, it remains to be seen how difficult the modifications will be, and how well the system will scale. Additionally, the security issues need to be explored carefully. While the system looks attractive, if the security problems cannot be resolved the system will not see widespread adoption. 14

15 Acknowledgements The author would like to thank Dr. Cullen Jennings, Distinguished Engineer at Cisco Systems, IETF Working Group Chair, and long time contributor to the SIP and SIMPLE projects. Dr. Jennings kindly spent a half hour of his time discussing some of the details of SIMPLE and providing opinions on design decisions for this project. References [1] SIP: Session Initiation Protocol, IETF RFC 3261, [2] Session Initiation Protocol (SIP) Extensions for Instant Messaging, IETF RFC 3428, [3] STOICA ET AL, Chord: A Scalable Peer-to-peer Lookup Protocol for Internet Applications, ACM SIGCOMM 2001, 2001, [4] DABEK ET AL, Building Peer-to-peer Systems with Chord, a Distributed Lookup Service, Proceedings of the 8 th Workshop on Hot Topics in Operating Systems (HotOS-VIII), 2001, [5] The Message Session Relay Protocol, IETF draft-ietf-simple-message-sessions- 02.txt, [6] A Presence Event Package for the Session Initiation Protocol (SIP), draft-ietfsimple-presence-10.txt, [7] Session Initiation Protocol Basic Call Flow Examples, IETF draft-ietf-sippingbasic-call-flows-02.txt, [8] IETF simple working group web page, [9] IETF sip working group web page, [10] IETF sipping working group web page, [11] Chord Project, [12] Weblog of Lucas Gonze - Extensive links to Waste articles and material, [13] Jabber, Jabber Software Foundation, [14] Extensible Messaging and Presence Protocol (XMPP) : instant Messaging and Presence, IETF draft-ietf-xmpp-im-19, 15

16 [15] IETF xmpp working group web page, [16] GNU General Public License, GNU project, [17] AOL AIM, [18] Yahoo Messenger, [19] Microsoft MSN Messenger, [20] Microsoft Live Communications Server, [21] Gnutella RFC, [22] Internet Engineering Task Force, [23] A. ROWSTRON AND P. DRUSCHEL, Pastry: Scaleable, Decentralized Object Location and Routing for Large-scale Peer-to-peer Systems, IFIP/ACM International Conference on Distributed System Platforms (Middleware), 2001, [24] SIP Event State Publication, draft-ietf-sip-publish-01.txt, [25] ReSIProcate Project, [26] VOCAL Project, [27] GAIM Project, [28] SIPImp Project, 16