Peer Rendezvous

  Peer Rendezvous

                      ABSTRACT

We have developed a peer-to-peer based interactive system for an enterprise as a part of Project Peer Rendezvous. Our system is a highly available and secure system for Instant Messaging and Event notification. The service is where employees rendezvous i.e. meet and interact with one-another to share and exchange knowledge and experiences, and notify other members of the enterprise about the upcoming events. Unlike other services available in the market, our system has high availability and security as two of its most important features. This means that our system is less vulnerable to attacks from outsiders, sensitive information is exchanged without the loss of authenticity of peers, communications is not be eavesdropped, integrity of messages exchanged is maintained and other security features are not being compromised. Also the feature of availability is supported by the fact we have used a primary backup approach for the central server responsible for authentication, handling of offline messages and events and maintaining the list of buddies for each client. In today’s world it is of utmost importance that companies deploy highly available secure systems to protect their information from competitors and our system provides an enterprise with exactly that.

INTRODUCTION

Motivation for the Project

Enterprises currently have to depend on external services or propriety expensive software for Intra-Enterprise Communication. Not many software packages provide the features and convenience that enterprises want. Messengers like MSN and AOL need the intra-enterprise traffic to go beyond the boundaries of their firewall and is not a secure means of communication. Such traffic might involve transfer of sensitive information, making security a reason of concern. Also having a peer-to-peer means of communication will reduce the load on the servers and tend to be more favorable for applicants like Instant Messaging. This is currently not the case with many software packages like Lotus Notes, which have a centralized means of communication. There is also a need for an open source code so that enterprises have flexibility to mold the software to be suitable to their needs. Peer Rendezvous comes as a solution to all the above problems and an answer to the software packages as desired by the enterprises. It is a secure, peer to peer based interactive system for an enterprise, which could be open source to increase its applicability according to specific needs of various enterprises.

Our Vision

Peer Rendezvous has a unique vision for the future of an Enterprise. Our software provides an Enterprise with the essential components for making it an interactive and interleaved Entity with a life and therefore heartbeat of its own, to make a personification. It had been our prime concern to incorporate security and high availability in an Enterprise to ensure and further enhance its long life and ongoing progress.

In terms of the features, the vision includes Instant Messaging, Offline Messaging, Event Notification, Bulletin Board, Discussion Board, Meeting Scheduler, Shared Diary and File Sharing as the applications satisfying most, if not all the requirements of an enterprise. Two key infrastructural features, which we thought are most needed, were security and robustness (in the sense that if one central server goes down, the system should not stop functioning)

PROJECT REQUIREMENTS

Peer Rendezvous incorporates the following salient features:

􀂉 Instant Messaging

The users of Peer Rendezvous can employ secure P2P Instant Messaging for communication with other members of the Enterprise. The communication between the peers is completely decentralized. We also have a special feature in which a peer can select the name of the peers from his friend’s list so that only those peers see him online and not others. The widely deployed instant messengers like Yahoo and AOL do not support this feature.

􀂉 Offline Messaging

This supports sending messages to a person on the friend’s list who is not currently logged in or is offline.

􀂉 Event Notification

This is an offshoot of Instant Messaging where a peer can notify other peers on his buddy list about an upcoming event like a meeting, and can select the date and time of the event. The sender and recipients are informed of the event, each time they login thereafter.

􀂉 Bulletin Board

This supports the posting of messages, which can be viewed by all members of enterprise

􀂉 Discussion Board

This is like an instant messaging but more than two peers can join in.

Infrastructural Features

􀂉 Security

The main feature of our project, which makes it unique, is security. We have provided a reliable and secure communication using Transport Layer Security (TLS). The main feature of our project is privacy of communication, authentication of peers and integrity of messages.

􀂉 Location Transparency

The end-user can log into ‘Peer Rendezvous’ from anywhere in his work environment within the Enterprise and can avail all features of Peer Rendezvous.

􀂉 High Availability

We have employed the Primary Back Up approach for the central server responsible for authentication. We are also exchanging heartbeats between each client, primary and backup to keep track of their status.

                                             SYSTEM DESIGN

Instant Messaging

Instant Messenger (IM) is an application that enables instant communication across the network. It is a great tool for a quick dialogue, an immediate response, an answer to a problem, a reaction to a joke and so on… It's a great way to stay in touch with friends and family across the world. The IM application that we have developed in our project is a P2P based instant messaging running on JXTA for an enterprise network. It is basically useful for people in an enterprise to discuss projects, problems, and any official or personal issue instantaneously.

The currently used instant messaging works on a hybrid of P2P and client/server architectures. The central server monitors the users, which are online and notify the interested clients or users when new users connect to the network. All other communication between users is conducted in a P2P fashion. Our Instant Messaging will be an attempt to make IM more towards all peer-to-peer. Following steps are involved in our IM:

􀂉 When one installs our IM software and opens the client, a configuration panel opens up which requires the user to give the names of servers of an enterprise or in our case Angelo’s servers. The client then connects to the central server.

􀂉 The server then asks the client for authentication by asking the client’s user name and password. When user enters the username and password, the server verifies it and on successful verification sends the client his buddy list along with pipe Ids of the buddies. Buddies or peers for whom the pipe ID is NILL are offline.

􀂉 The client then has an option to select from the list of buddies on his list whom he wants to inform that he is online and sends a message to them that he is online along with his pipe ID.

􀂉 Now the peer can send and receive messages from his peers or buddies.

􀂉 When a client logs off, all the peers on his buddy list who are online are informed that the person is offline. Also the server is informed, so that it can update the database by setting that peer’s pipe ID to be NILL.

Components of IM

􀂉 Buddy list: It contains the list of people, which are in a particular peer’s list along with their status i.e. whether they are online or offline. Normally maintained by the server in his database along with their pipe Ids.

􀂉 Add Buddy: This helps user to find people whom he wants to communicate with using the peer id of the person in the Angelo Enterprise.

 􀂉 Delete Buddy: This helps a user to delete a buddy from his list.

􀂉 Logout: When a user clicks on this icon, all the buddies in his buddy list who are online are informed that he’s now offline. Also the server is informed so that it can update its database.

􀂉 Message Window: This is the place where the messages exchanged between two peers appear. One can have multiple windows to talk to different users.

Off-Line Messaging

This is a service in which a user wants to leave a message for a peer who’s not logged on or is offline. In that case he frames a message and sends it to the server with a field, which indicates to whom, it is intended to and from whom it is sent. The server stores it in its database and whenever a user next logs in, he gets the offline messages stored for him.

Event Notification

It is a service, in which a user can notify the peers on his buddy list about an upcoming event, date and time of the event. This gets stored at the central server and is sent to all recipients of the event as well as the sender, whenever they log in every time till the time of the event. So it reminds peers of events incase they have forgot about it.

Bulletin Board

It is service in which users can post messages, which can be viewed by all members of the enterprise. These messages are stored at the server and displayed every time some one retrieves the bulletin board.

Discussion Board

It is a service in which users can start a discussion on any topic. It is like an instant messaging with conference facility. Only online users can participate in it. Whenever someone types a message, it goes to the central server which then propagates it to all members participating in the discussion.

Distributed System Features

Security

The main desired security features in any communication are:

􀂉 Privacy – This means there is no eavesdropping on communication

􀂉 Authentication - This means a person is what he says he is.

􀂉 Integrity - What a user sends is what a receiver receives

We have used a central server to authenticate the clients who login to “Angelo” peer group.

We have adopted the Transport Layer Security (TLS) [TLS] version 1 to support reliable private connections between peers. TLS is the IETF Security Working Group's continuation of the development of SSL v3 and is defined in RFC 2246. The reasons for choosing TLS are cryptographic security, interoperability, extensibility and relative efficiency. Since JXTA messages are independent of the underlying transport and its protocols, encrypted content remains encrypted, even during the protocols conversions that occur between networks.

The desired security features in our project are the ones stated above.

Transport Layer Security (TLS)

The primary goal of the TLS Protocol is to provide privacy and data integrity between two communicating applications. The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. At the lowest level, layered on top of some reliable transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol. The TLS Record Protocol provides connection security that has two basic properties:

􀂉 The connection is private. Symmetric cryptography is used for data encryption (e.g., DES [DES], RC4 [RC4], etc.) The keys for this symmetric encryption are generated uniquely for each connection and are based on a secret negotiated by another protocol (such as the TLS Handshake Protocol).

􀂉 The connection is reliable. Message transport includes a message integrity check using a keyed MAC. Secure hash functions (e.g., SHA, MD5, etc.) are used for MAC computations.

The TLS Record Protocol is used for encapsulation of various higher-level protocols.

One such encapsulated protocol, the TLS Handshake Protocol, allows the server and client to authenticate each other and to negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. The TLS Handshake Protocol provides connection security that has three basic properties: 

􀂉 A central server authenticates the peer’s identity with X509.v3 certificates using asymmetric, or public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This authentication is required for all of the peers. 

􀂉 The negotiation of a shared secret is secure: the negotiated secret is unavailable to eavesdroppers, and for any authenticated connection the secret cannot be obtained, even by an attacker who can place himself in the middle of the connection. The shared secret is usually an encryption algorithm and cryptographic keys used for the TLS record protocol. 

􀂉 The negotiation is reliable: no attacker can modify the negotiation communication without being detected by the parties to the communication. 

High Availability

The central server acts as an authenticator and maintains the buddy list of each peer along with the list of his or her pipe ID. Also it acts as a store for offline messages and upcoming events. To ensure its high availability, we are using a PRIMARY BACKUP APPROACH. In this approach, one server acts as a primary with a replica acting as backup. Clients send requests only to the primary, if the primary fails, the backup becomes primary in a fail over. Heartbeats are exchanged between the primary and its backups at regular intervals (sent every 1 min) so that the backup keeps a track of when the primary goes down and when it has to take over as primary and also primary comes to know whether the backup is there or is down. It uses a time-out mechanism for this. If it does not receive a heartbeat within a certain time interval from the last heartbeat (2 min in our case), it assumes that the primary has gone down. The primary server and the backup also exchange heartbeats with each client (sends them every 1 min) to check if client is alive. If doesn’t get a response from a client within a certain period of time (2 min in our case), it assumes that the client has gone offline and informs all other peers on the client’s buddy list of his new status as well as updates his status in the database. Whenever any change is made at the server side, the change is communicated to the backup, so that primary and backup have same status at any given point of time. Also if the client does not get a heartbeat from the server within certain amount of time (2 min in our case), it assumes that the server or primary has gone down and contacts the backup. From this point onwards any communication with the client is with the backup server. This is however transparent to the end-user. When the primary is repaired and plugged back in, it becomes the backup of the server, which is running.

References:

[TCP] Postel, J., "Transmission Control Protocol," STD 7, RFC 793, September 1981.

[DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption," American National Standards Institute, 1983.

[DSS] NIST FIPS PUB 186, "Digital Signature Standard," National Institute of Standards and Technology, U.S. Department of Commerce, May 18, 1994.

[RC4] Thayer, R. and K. Kaukonen, A Stream Cipher Encryption Algorithm, Work in Progress.

[RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, v. 21, n. 2, Feb 1978, pp. 120-126.

[TLS] Internet Engineering Task Force, RFC 2246.

[1] www.jxta.org

[2] www.openp2p.com

[3] http://www.jxta.org/servlets/DomainProjects

[4] http://conferences.oreillynet.com/cs/p2pweb2001/pub/w/16/presentations.html