Peer-to-Peer audio conferencing using SIP:

Overall introduction

Luca Maccari, Gabriele Violino, Max Weltz

May 11, 2007

We have decided to take the context of an audio conferencing application to discuss severalissues on P2P/SIP. Audio conferencing is nowadays a widely use service on the Internet, whichmakes it a concrete frame of work. Many points are important when it comes to softwaresaddressed to a large public: look and feel, quality of the background service, security, hypeand others. We chose here to address the issue of security, as the past as often proved thatthe more common a system is, the more it is likely to be attacked, especially when like inP2P systems it is easy to join it ; the issue of quality (QoS) as people are more and moredemanding in terms of quality when it comes to communications and finally the issue of theP2P architecture itself, not visible to the end-user but an important part of the application.The security issue was addressed by Luca Maccari, the QoS issue by Gabriele Violino and theP2P architecture issue, as well as the introduction, was address by Max Weltz.

In the end, we hope to have demonstrated that a P2P audio conferencing solution was doable andcould offer the same services as a traditional SIP network, maybe not in a pure P2P solution butrather with a hierarchical system. With the increase of bandwidth and of QoS use on the Internetand with the solutions discussed for security, we think that a P2P/SIP conferencing system is viableon the long term for a wide public.

1

Peer-to-Peer audio conferencing using SIP:

P2P Architecture

Max Weltz

May 11, 2007

Abstract

This report is part of a collection of three report describing several aspects of Peer-to-Peer audioconferencing using SIP: security, Quality of Service and P2P architecture. This particular report willdetail the P2P architecture that can be used for an audio conferencing solution. Here will be described thedifferences between a pure SIP solution and a P2P/SIP solution, in terms of architecture and messages.We will see what issues are solved by that system and what other issuers are raised and how they canbe circumvented.

Contents

1 Introduction 1

2 Peer-to-Peer Architecture 12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Preliminaries on P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Audioconferencing basis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.4 Existing works on P2P/SIP solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.4.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4.2 Characteristics of a P2P/SIP solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4.3 SIP using DHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.4.4 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.6 Other aspects of a P2P solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Conclusion 10

References 11

1 Introduction

Peer-to-Peer (P2P) is one of the current trends on the Internet with up to 90% [San05] of the traffic share,depending on countries and sources. P2P is praised for its scalability and as the size of the communicationnetworks increases - for instance Skype has 80 million users [SJ06] and more than 8 million users online atpeak hours [Sky07], clearly demonstrating the capacities of P2P infrastructures - it is with no surprise thatSIP developers have turned towards this new solution, whether the P2PSIP working group1 or the Damaka2

company. In section 2 we will see what attempts were made to adapt the SIP protocol to be fully functionalin a P2P audio conferencing context and what is left to be done in that area.

2 Peer-to-Peer Architecture

2.1 Introduction

This whole section is devoted to the integration of P2P in SIP solutions. We will first discuss briefly P2Pprinciples and audioconferencing basics. We will then have a closer look at existing works on P2P/SIP lookingat the solutions they offer and the choices they made. We will wrap up with a quick look at alternativessolutions and name a few other aspects that deserve to be mentioned when it comes to P2P/SIP solutions.We will not give exhaustive definitions of SIP or P2P in that part as it is assumed they are already in themind of the readers. In case the reader needs or wants to go deeper into the subject, RFC 2543 and RFC3261 relates to SIP and Stoica et al. in [MKL+04] provide a comprehensive guide to P2P.

1http://www.p2psip.org/2http://damaka.com/

1

2.2 Preliminaries on P2P

Peer-to-Peer has proven over the past years its qualities in terms of scalability, reliability and flexibility asit can be used to address various resources such as files or audio communication and be used on multiple OSand platforms. The clear success of Skype, which is partially based on the P2P technology, is particularlyinteresting in the context of this paper. However we cannot stop there and be satisfied of the success of aP2P VoIP solution as Skype does not use SIP and therefore will be of no further interest us. P2P providesan alternative to the usual client-server model on the edge of Internet. Therefore P2P fits well into the SIPmodel as SIP itself delegates a great deal to end points even though SIP communications often go throughproxies and servers. In fact, except for resource location, SIP is end-to-end and the communication thatresults afterwards is also end-to-end [BL07], so why not make it all, end-to-end, P2P? Numerous benefitswould result including the possibility to allow SIP-communications on ad-hoc wireless networks, and moregenerally in the cases where accessing to distant servers is not possible or not preferable [BLJ05].

√

√ √

√

√

√ Member of the P2P overlay network

a) Physical connections between the nodes

b) Overlay network between the nodes

Figure 1: Difference between physical and overlay networks

Peer-to-Peer networks are based on overlay networks, that’s to say virtual networks of devices notnecessarily matching the lower-level connections between them (cf Figure 1). This overlay network canbe of two types: unstructured or structured. Only the latter will be of interest for the rest of this studybut we need to explain both to have a clear view of the subject. An unstructured network is built whennew nodes are placed anarchically into the pre-existing overlay network and when there is no better way tocontact a node than to flood the overlay network. On the other hand, a structured overlay network has aspecific handling of new nodes joining or leaving the network and provides an easy access to resources, oftenvia the use of a Distributed Hash Table. We will discuss the use of DHT later on.

2.3 Audioconferencing basis

Our objective is to propose a solution viable for an audioconferencing purpose. We should first describewhat are the specificities of audioconferencing. SIP audioconferencing should allow users to lead a chattingsession with audio support with more than two parties involved, a party being a SIP terminal.

2

As we are going for a P2P solution for the SIP network, it would be logical to go for a P2P solution duringthe actual conference, either with a completely connected network or with a ring-architecture. The problemof a ring architecture is that as we will see later it can take several hundreds milliseconds to go from onenode to another when passing through a number of other nodes, which would cause too much latency duringa speech conversation. A completely connected network would imply many connections established and awaste of resource. Therefore, the conferencing requires a local centralized solution.

Singh and Schulzrinne propose a good solution in [SS04]. The conferencing nodes should elect a centralnode who will do the mixing, resulting in a star-shaped pattern. Singh and Schulzrinne would go for thenode with the best bandwidth and CPU capacity but that is not enough as it does not address the problemof codecs and that of dynamic conferences with members joining and leaving during the actual conference.The chosen node definitely has to have the largest range of codecs (or at least each other participant shouldhave one codec in common with the central node) and to be the most likely to stay in the conference from thebeginning to the end (probably the instigator of the conference). The node with the largest range of codecsis likely to be a computer (as opposed to a SIP phone or a PDA) and dispose of a larger computationalpower, however a SIP phone might have been designed from scratch to enable conferencing and to act asa mixer. Another issue to keep in mind in this model is the question of privacy, which limits the choice tonodes involved in the conference. The determination of the central node is thus an open problem and theresult will most likely depend on assumptions made on the network usage and users.

Another solution could be to use multicast but that could lead to flooding the network, at least the partof the overlay network involved in the conference. In that case, all nodes have to do the mixing. Becauseof these two drawbacks this solution cannot apply to conferences with many speakers debating at the sametime. The performances can be improved depending on the properties of the overlay network. For instance,some P2P overlay networks, like Pastry, provide proximity informations that can be used to smarten themulticast.

2.4 Existing works on P2P/SIP solutions

2.4.1 Objectives

From the works of Bryan, Lowekamp and Jennings in [BLJ05] and Kundan Singh and Henning Schulzrinnein [SS04], we came with a precise list of objectives to meet for a good P2P/SIP solution:3

1. Simple lookup: one issue with P2P systems is the problem of bootstrapping, or more clearly, how tojoin a P2P network without any a priori knowledge about its members, and namely, their addresses?

2. Privacy: often true when in the communication world, users might want their privacy, maybe byconnecting only to a subnetwork only made up of trusted users.

3. Mobility: with a wider use of P2P/SIP solutions for VoIP, users are likely to wish for mobility, whetherit is service mobility, personal mobility, session mobility or terminal mobility as defined in [SJ06].

4. Portability: along with mobility raises the issue of portability: users might want to keep the samesolution working, whether they are using their laptop or their PDA.

3We do not list here previously acknowledged advantages of P2P systems.

3

5. Compatibility: SIP products and solutions are already widely spread and it would be confusingand damageable to hinder the communications between P2P and non-P2P SIP products. Moreovercompatibility with former solutions is likely to lead to a larger reuse of existing code-snippets

6. Easy configuration: which is not dependent of the P2P/SIP choice but must be kept in mind asnowadays people are used to plug and play solutions when it comes to P2P and communications, whichmeans the developer is in charge of the inherent issues of NAT transversal, among others.

2.4.2 Characteristics of a P2P/SIP solution

Compatible characteristics

SIP in itself is not causing many problems for integrating it into a P2P solution. Namely, intermediateservers are optional and the SIP protocol allows user agents (UA) to communicate with each other with noother party involved. This means that the messages inherent at a P2P protocol can be transported in SIPmessages (cf. 2.4.3).

Modification needs

Presence Not only should we be aware of what does or does not change inside SIP’s core aspects,but also on services often associated with it, such as presence. The classical presence management overSIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) requires all UA to update theirpresence information on a remote centralized server. A system based on event packages has been proposedin RFC 3265 to deal with presence between nodes, using no external server but this solution might not beimplemented in all existing SIP products and so might not be suitable for all SIP devices and applicationsalready on the market.

Voicemail Another problematic aspect is that of voicemail when the callee’s machine is not connected(if the callee is connected but not answering her machine can store the resulting file). While voicemail canbe stored, and is actually stored, on the centralized server in most SIP implementations, there is no suchserver in our P2P/SIP model and adding one would break our efforts to bring SIP to a fully P2P modusoperandi. Instead, we have to designate a node, but more likely a set of nodes to improve chances thatthe voicemail message will be available when the node reconnect4, on the overlay network to store the filecontaining the voicemail message. Encrypting the message could guarantee privacy using the callee’s publickey and integrity using the caller’s private key. At this point, we have to further explain DHT to determinewhat node should stock the voicemail file.

4This problem is close to that of data replication on MANETs, except that all messages eventually need to be stored onlyby their legitimate recipient. Hayashi, Hara and Nishio in [HHN05] give good ideas on the subject.

4

2.4.3 SIP using DHT

Principles of a DHT architecture

Many implementations of DHT are available, Chord5 and Bamboo6 being the main ones, but they allrely on the same model that we are to explain here. As the name indicates, DHT makes use of a hash function,associating a variable-length string (a SIP AoR in our case) representing one resource of the network (a SIPuser) to a unique fixed-length identifier. To be more precise, a good hash function is one that minimizes risksof collision, therefore the identifier is not unique but has great probabilities to be so. Some P2P networks arehierarchical in that they distinguish super-nodes from regular nodes. Those super-nodes exchange messagesto manage the P2P network and act often like an entry point in the network. Those super-nodes make up asuper-overlay network. They are not fixed, nor do they have to belong to the institution responsible for theP2P network and technology used.

Every UA being associated with an identifier, all UAs are organized as a ring network, ordered byascending identifiers. This addressed the problem of identification so we now have to face the problem ofdestination lookup. Each node knows the location to its predecessor and successor in the ring. Furthermoreeach node stores the location of a small amount of other nodes, along with their identifiers. That amountis generally O log(n), which tops the lookup time at O log(n) [SS04] (see Figure 2 a). The case ofaudioconferencing narrows the assumptions on the network so we might decide to optimize the choice ofthe nodes, whose locations are stored. Namely, a node can store the locations of a few nodes from theoverlay network and fetch preferentially the location of nodes present in the user’s buddy list.

A

B

Lookup

A

M

a) Example of resource lookup using DHT

Access

B

b) Example of resource lookupwith a single URI associated to several terminals

Figure 2: Example of resource lookups using DHT5http://pdos.csail.mit.edu/chord/6http://bamboo-dht.org/

5

This leaves the problem of several devices associated to a single user. This issue is also logically noticedin [SS04], as the choices we made above are similar to those of Singh and Schulzrinne. Here is a suggestionwe make to deal with that issue.

To locate a node on the network, one needs to know to what value apply the hash function. On onehand, if we consider applying the hash value to the SIP AoR, then how do we know all URIs associated tothat AoR have been alerted? On the other hand, if we decide to apply the hash value to the IP or phonenumber of a particular device, we then need to know it beforehand, which would then make any sort oflookup useless. A solution would be to have all devices associated to the same AoR elect a representing nodeand let the other nodes pick different hashes known by the master node M. This is no longer strict, flatlystructured P2P (see Figure 2 b). Bryan, Lowekamp and Jennings in [BLJ05] propose to use the IP addressas input value for the hash function but in that case we need to maintain a parallel mapping between IPaddresses and AoRs.

SIP exchanges in the DHT architecture Singh and Schulzrinne in [SS04] develop explanations onappropriate SIP exchanges using their P2P model that we will detail and comment here. We also would liketo remind that the use of a P2P overlay network does not mean that the same SIP client cannot use a SIPonly network based on servers and proxies, especially since it was decided in this model to carry the P2Pmessages using SIP.

Node Joining For a node to join the network, two phases are to be observed:

1. Network discovery: to be able to join the network, the node has to find an entry point, quite often thismeans a super-node7. This can be achieved using the Service Location Protocol (SLP) or by flooding thelocal network for super-nodes or nodes that can provide useful information on their location. Otherwise,the cache of the joining node can be used for super-nodes lookup. In the worst case scenario, there canbe a few fixed super-nodes, for instance super-nodes belonging to the protocol’s creators that mightbe used for statistical purposes.

2. Node registration:8 suppose Alice wants to join the network. She will send:

REGISTER sip:123.234.1.1:5060 SIP/2.0

To: alice@atlanta.com

From: alice@atlanta.com

where sip:123.234.1.1:5060 is the address of the super-node Alice is contacting. The super-nodecan now calculate the hash of Alice’s AoR and register the new node in the DHT table. The P2Pnetwork will handle the registration following its own fashion. Namely, the P2P network still has toinform Alice she has been accepted and who and where are her neighbors. Alice is also still lackingthe addresses of the above-mentioned nodes used to reduce the lookup time. All this depends on theP2P network solution chosen. In the case of Chord, informations on successors and predecessors areobtained by looking-up for yourself on the network. This message is also used in [SS04] to make surethat the connection is alive between the node and its supernode.

7Singh and Schulzrinne consider a Chord network and the use of super-nodes. A regular Chord network is flat and does notinclude super-nodes. This means we have to consider adding a super-Chord network made of super-nodes only as in [JW06] orreplace Chord by another system.

8We will only discuss the registration of the node on the P2P network here.

6

More evolved scenarios can be considered when a node is joining the network. For instance, super-nodes may have been designed to split to the task of incoming nodes’ management depending on areas,functionalities or client versions. In that case a REGISTER message might be forwarded betweennodes. Similarly, for one reason or another, a REGISTER message might be received by a node thatis not a super-node (because it has lost this status recently for instance) and in that case again, theREGISTER message might be forwarded. The forwarding may be done by a REFER message. AlanB. Johnston and Henry Sinnreich claims in [JS06] that this solution is not suitable as some existingsolutions might not tolerate the forwarding of REGISTER messages. More generally they are opposedto the transport of P2P message on SIP for reasons of performances (cf. paragraph 2.4.4).

Node quitting A node quitting abnormally will be detected by the process above, but a node quittingnormally has to unregister from the P2P overlay network. This can be achieved by sending a REGISTERmessage with an expiry time set at zero. However due to their specific roles, super-nodes cannot just leaveon an unregistering message.

In the specific case of a super-node leaving the network, it has to communicate with its fellow super-nodes on the super-network the information concerning the nodes it was in charge of. This can be achieved bythe mean of REGISTER messages exchanged between the two super-nodes. The authors of [SS04] considerthat nodes will notice the departure of their super-node during the next refresh and then look for the newsuper-node responsible for them.The resulting delay can be avoided if the leaving super-node warns the nodesit is in charge of with a REFER message for instance.

This question of warning other nodes leads us to discuss the case of node failure. The failure of asuper-node matters especially and in such a case the remaining super-nodes will notice it and redistributeamong themselves the dropped nodes. Once again, the dropped nodes might be notified of the change bythe mean of a REFER message or wait until they realize the change, like in [SS04].

As we will see later, if some information is to be stored on the network, the failure of any node canbecome a serious issue. When online storage of information is considered, a disconnecting node has to passon its data to other nodes before the actual disconnection to allow the information to remain availableafterwards. This can be a problem and cause a long time between the request for disconnection and theactual disconnection.

Interaction between two nodes Here comes the aspect that interest the users the most: openingsessions with another node. Just like in non-P2P SIP, it consists of two parts: 1) finding the requested node,2) establishing a session with that node. Once again, using a P2P/SIP solution does not mean that thissolution is isolated from the pure SIP world, for instance, instead of the P2P lookup phase we are going todescribe further down, the node might successfully use a traditional SIP lookup.

1. Node lookup: The initiating node sends an INVITE message to its super-node that will forward it tothe called party. The super-node might have to act as a proxy in specific cases, for NAT-transversal forinstance. The lookup is done by the super-node using the DHT mechanism. Note that a node mightalso be a super-node and in that case it can issue directly the INVITE message to the called node.

2. Session: After the lookup is done, the SIP exchange can go on like a normal SIP exchange, eitherincluding the super-node as a proxy or as an end-to-end exchange.

7

Voicemail storage As we discussed before, the voicemail message has to be stored as long as the nodeconcerned by the message has not fetched it. The most intuitive way is probably to assign that messageto the super-node that should be in charge of the recipient node. ”Be in charge” can either mean store itand send it to the recipient node when it connects or manage the replication of the message on the overlaynetwork and alert the recipient node it has a message once it is connected. It is possible that at somepoint the super-node disconnects, in that case it has to pass its duty to another super node. Once that themessage has been delivered, the question of the confirmation creates another issue. If the sender is online,an acknowledging message can be sent and if it is not online, a system similar to the one described abovecan be used.

Device independence and presence Using a P2p network implies a greater facility to connect tothe P2P so it is likely that users might roam and connect from distant places, not having their main devicewith them. Therefore some settings, and especially the contact list, can be stored on the network, just likefor a voicemail message. Once again, privacy and integrity can be achieved by the mean of encryption asnowadays most people are used to entering passwords when they connect to an online service. The mainproblem remains availability in that model as there is no guarantee any replicates of the data will be onlineat any moment, especially if a node has a failure and cannot pass on the information to another node beforedisconnecting.

Once the issue of contact list retrieval is addressed, fetching presence information can be done directlyby requesting it from the concerned nodes, via the super-node. The super-node could store presenceinformation for all its associated nodes but it is preferable not to add to the burden of super-nodes somethingthat is not of primary priority.

More on SIP messages In [Bry05], David A. Bryan gives some smart hints on how to use existingheaders and parameters of SIP messages to convey P2P information:

• Supported/Require: respectively to specify the ability of a node to handle P2P interaction and ifthe current message is of that kind

• alg:9 to convey information on the hash algorithm used by the DHT

• user:9 to specify if the message is relative to a user-to-user SIP exchange or to a P2P message overSIP

Obviously those are just suggestions and P2P/SIP solutions are likely to use them differently even thoughan overall agreement would be an important towards unification, which is the current drawback of allwidespread IM and voice solutions.

2.4.4 Performances

Singh and Schulzrinne in [SS05] provide ”performance predictions” using the Chord DHT system basedon the work of Stoica et al. in [SMLN+03] and claims the following:

• with weak assumptions on the network and the nodes and strong assumptions on the use of thenetwork10, the maximum number of nodes on the network is of 2300,

9Used inside a To, From or Contact header1010 requests per second per node, one call per minute per node

8

• considering a network of 10,000 nodes using chord, six hops is the mean lookup path length, takingapproximately 200 ms.

This latter assumption of 10,000 nodes is pretty weak compared to a network like Skype with 8 millionusers online [Sky07]. Based on the results found in [SMLN+03], such a network would require a mean lookuppath length of 10 hops, or approximately 350 ms. Compared with the actual values observed on the Skypenetwork (three to eight seconds according to Baset and Schulzrinne in [BS04]), this probably means theassumptions made are not realistic for such a wide network. With optimization those values could be lowered,especially considering the large bandwidth of current networks, one hop lookup is conceivable [GLR03] andeven if not all nodes11 do not have that capacity, the delay would still be greatly reduced. In any case, thelatency in a P2P network is longer than that of a classic centralized network.

2.5 Alternatives

Alternatives in the domain of P2P/SIP The different papers studied above list several alternativesto P2P/SIP, each with their drawbacks and advantages. Other solutions have been designed that were notdiscussed above:

• Damaka12 is offering a P2P/SIP client as a non-open source software.

• In [SBC06], Stiemerling, Brunner and Cassini discuss the use of Service-Aware Transport Overlay(SATO), a technology relative to ambient networks defining another way to handle overlay networksand DHTs.

Alternatives to P2P/SIP Other projects exists that do not use SIP, or P2P or non of them, but thatcan still be applied for an audio conferencing solution:

• Skype, which is a commercial, proprietary, non-disclosed solution but widely in use. The model isnot strictly P2P and includes central servers for authentication and charging. Skype also adds IMsupport and NAT transversal functionalities and more generally enjoys a larger support thanks to itscommercial nature.

• vop2p, a currently inactive project, based on JXTA, a Java-based P2P technology which is howeverlisted as inactive on the JXTA projects’ list13. Such a project could have been promising as JXTAprovides service discovery functionalities, among others.

• Solutions using a Dynamic DNS are also considered as a solution mixing the P2P and server-basedapproaches. The use of a REGISTER message can then be avoided by the using of Dynamic DNS toresolve SIP URIs. Another solution is to have servers joining and leaving dynamically and still use theDynamic DNS resolving to access them.

11Namely mobile devices might not have all 384 kbps (in the case of a network with 106 nodes) of bandwidth to give away.12We contacted Damaka to have further information on their system but they did not reply.13http://vop2p.jxta.org/

9

2.6 Other aspects of a P2P solution

The use of P2P in SIP solutions sharpens some pre-existing problems that are that of security and privacy, ofNAT transversal and QoS. When non-trusted machines are involved, users get worried about their personalinformations. Finally, a larger public often means more chances to encounter NAT on the path of the messageand also means great constraints in term of quality of service, or at least a sufficient quality/price ratio. Thislatter issue is addressed in [Vio07] and the security issue is addressed in [Mac07].

3 Conclusion

Many solutions are actually studied to implement SIP communication on a P2P network. Some like theone we presented here send P2P-related messages using SIP, some do not. We also tried to discuss some issuesthat were not, or not sufficiently, discussed by Singh and Schulrzinne in [SS04] on which we based our report.The darkest spot for the future of P2P/SIP solutions seem to be the availability of some information, suchas contact list and voicemail messages, inherent to pure P2P systems. One solution could be to have hybridssystems using private nodes and super-nodes but including a few servers ran by the company promoting thesolution, or possibly some service providers. Nevertheless we feel confident that a P2P/SIP solution for voiceand audio conferencing is not impossible to deploy at a large scale and for a common public use.

10

References

[BL07] David A. Bryan and Bruce B. Lowekamp. Decentralizing sip. ACM Queue, March 2007.

[BLJ05] David A. Bryan, Bruce B. Lowekamp, and Cullen Jennings. SOSIMPLE: A serverless, standards-based, P2P SIP communication system. Technical report, College of William and MaryWilliamsburg, Vancouver, 2005.

[Bry05] David A. Bryan. Peer-to-peer SIP. 2005.

[BS04] Salman A. Baset and Henning Schulzrinne. An analysis of the Skype peer-to-peer internettelephony protocol. Technical report, Columbia University, September 2004.

[GLR03] Anjali Gupta, Barbara Liskov, and Rodrigo Rodrigues. One hop lookups for peer-to-peeroverlays. Technical report, MIT, 2003.

[HHN05] Hideki Hayashi, Takahiro Hara, and Shojiro Nishio. A replica allocation method adapting totopology changes in ad hoc networks. Technical report, Osaka University, 2005.

[JS06] Alan B. Johnston and Henry Sinnreich. SIP, P2P, and Internet Communications. Technicalreport, IETF, SIPPING Working Group, 2006.

[JW06] Yuh-Jzer Joung and Jiaw-Chang Wang. Chord2: A two-layer Chord for reducing maintenanceoverhead via heterogeneity. Technical report, National Taiwan University, 2006.

[Mac07] Luca Maccari. Peer-to-peer audio conferencing using SIP: Security issues. Technical report,Kungliga Tekniska Hogskolan, 2007.

[MKL+04] Dejan S. Milojicic, Vana Kalogeraki, Rajan Lukose, Kiran Nagaraja, Jim Pruyne, BrunoRichard, Sami Rollins, and Zhichen Xu. Peer-to-peer computing. Technical report, HP, 2004.

[San05] Sandvine. EDonkey - still king of P2P in France and Germany. Technical report, Sandvine,2005.

[SBC06] M. Stiemerling, M. Brunner, and M. Cassini. Peer-to-peer SIP Implementation Report.Technical report, IETF, P2PSIP, 2006.

[SJ06] Henry Sinnreich and Alan B. Johnston. Internet Communications Using SIP - Delivering VoIPand Multimedia Services with Session Initiation Protocol. Wiley, 2006.

[Sky07] Skype. Skype statistics. http://share.skype.com/stats_rss.xml, 2007.

[SMLN+03] Ion Stoica, Robert Morris, David Liben-Nowell, David R. Karger, M. Frans Kaashoek, FrankDabek, and Hari Balakrishnan. Chord: A scalable peer-to-peer lookup protocol for internetapplications. Technical report, IEEE, February 2003.

[SS04] Kundan Singh and Henning Schulzrinne. Peer-to-peer internet telephony using SIP. Technicalreport, Columbia University, 2004.

[SS05] Kundan Singh and Henning Schulzrinne. Peer-to-peer internet telephony using SIP. Technicalreport, Columbia University, 2005.

[Vio07] Gabriele Violino. Peer-to-peer audio conferencing using SIP: QoS issues. Technical report,Kungliga Tekniska Hogskolan, 2007.

11

Peer-to-Peer audio conferencing using SIP:

QoS issues

Gabriele Violino

May 10, 2007

Abstract

This report is part of a collection of three reports describing several aspects of Peer-to-Peer audio conferencing using SIP: security, Quality of Service and P2P architecture. This particular report will focus on possible QoS issues in an audio conferencing solutions.

QoS in audio conferencing

What is QoS? How can it be evaluated? QoS is a delicate matter: for years it has been misused in commercials for ISP or VoIP companies. In fact there is no formal definition of QoS: in 1994 IETF in [2] tried for the first time to define QoS inside integrated services. According to this document many years ago (10 circa), there was no QoS at all, internet was just a best effort network that means no more than a network based on IP packets could offer. It is easy to understand why 10 years ago there was no support for QoS: there was no need of it because internet at that time was not used to carry multimedia data. But QoS originally was not born to fit quality requirements such as for audio and video streams. Originally the ISPs needed to distinguish different classes of service to accomplish the quality requirements (mostly bandwidth) inside the agreements with the users. That is a general problem also nowadays, that means that if a user pays more, it will be offered to him a better QoS (e.g. guaranteed minimum bandwidth, low probability to be out of service, etc..). The kinds of applications that the end-user utilizes can be very heterogeneous: there are some applications like web browser, FTP, mail client, etc.. that can adapt to situations, that means if a resource in the network is temporally unavailable they can wait so they are flexible, other applications need always a minimum amount of resources to work properly, otherwise the user will experience an unacceptable service. Thus it seems clear that there should be a way to distinguish between different kinds of packets within a network.

Audio and voice quality criteria and parameters

During the last past years several techniques have been proved to be efficient in improving the quality in packeted audio. However when one deals with voice (or audio in general) it is difficult to define some objective parameters to evaluate the audio quality. In [19] there are three different definitions of QoS that are interesting for clarify a term that has a use that is often abused:

1. Preferential QoS (classes of service)2. Intrinsic QoS (latency, jitter, dropped packet rate)3. Perceived QoS (QoS perceived by the end user)

I would say that the most important one is the (3) and for it to be improved, both (1) and (2) have to be improved. (1) and (2) can be easily established/measured because are objective parameters. The third highly depends on the user: when the user likes the sound that means that the quality is good, when the user dislikes it then the quality is bad so this is clearly a subjective parameter. How to measure a subjective parameter? The only feasible way seems to be statistical methods based on observations: if in repeated experiments has been observed that the users like that sound, that

means that, with high probability, that sound has high quality. Nowadays the most rated method to measure the user perception of voice is called MOS (Mean Opinion Scores). There are some sessions where some persons are invited to participate and listen to audio traces. Every person can evaluate the sound on a scale from 0 to 4 with the following description: unsatisfactory/bad, poor, fair, good, excellent. When all the people have expressed their opinion then all the values are collected and averaged, the average will be the rounded and the final result will be expressed as an integer [0-4] (or [1-5] with the ITU convention). An other subjective test that can be performed is the PSQM (Perceptual Speech Quality Measure) it has been made by ITU-T to measure the quality of speech codecs. MOS tests are performed in “laboratory conditions” that means no background noise: in the every day life there is always a background noise and this is what PSQM tries to emulate during the tests: results of the experiments with and without noise are then compared. PAMS (Perceptual Analysis Measurement System) is a method that performs calculations on the spectrum (also PSQM does that) of the audio signal with some sophisticated waveforms (ASTS) and also gives some additional information about the effort (to understand the meaning of the speech) made by the user listening to the audio signal. In addition, in PAMS, there are some attempts to take in consideration also the jitter so that the original signals and signals with variable delay are compared. PESQ (Perceptual Evaluation of Speech Quality) instead is a more objective criterion born to be applicable in the “real world” in end-to-end communications in VoIP, GSM, POTS (Plain Old Telephone Service), ISDN, etc... Other useful methods for VoIP qualitative measurements are PSQM+, ITU-T´s P.563 (non-intrusive voice quality testing), psyVoIP2 by Psytechnics and “E-model” by ITU for passive monitoring.

P2P bottlenecks

As we have defined nodes and super nodes in our P2P scenario for voice conferencing the super nodes should be connected with high bandwidth links and have much more computational power than regular nodes. However if one of this super nodes is performing an action, say sending a big packet with priority x, and then a small packet containing some voice samples with priority x+1 has to be delivered to n nodes then what happens? Should the transmission of the lower priority packet be preempted to let the voice packet be delivered with an acceptable delay? This is a general problem and does not affect only the case of P2P communications: every time a node (router) should decide which packet deliver (schedule) problems such as head of the line blocking and all the other queuing problems occur. In the case of P2P communications these problems can be much worse since usually regular PC/workstations cannot send and transmit more than one packet per unit of time (this is due to the limited number of interfaces that usually is 1). Figure (1) can highlight some of the problems that can occur.

Figure 1. Possible bottleneck in router: if the router is forwarding big IP packets from WAN2 to WAN then VoIP packet with source address node 1 and destination address node 2 may be delayed (even if the VoIP packet has higher priority).

Figure 2.

How to achieve QoS

In this section I will analyse the possible solutions to the problem of granting a certain level of QoS:● Over provisioning● TOS field inside IP packet● Intserv● Diffserv● RSVP● Future evolution

Over provisioning

Over provisioning is the simplest method to provide high QoS. Over provisioning is typical in circuit switching solutions (e.g. classical telephony where 1 call = 1 link). As it is shown in Figure 2, there is always a trade-off between the quality (wanted by the user) and hight utilization-efficiency (wanted by the service provider). In an ideal world there are enough resources to fulfil all the requests of all the users at the same time however, since the service providers want to minimize

node1 node

supernode

WAN

node node2

supernode

router

WAN2

Quality

High utilization

Service provider

User

the cost of the service, they tend to “overbook” links since it is not supposed that all the users need the service at the same time: this fact leads to unpredictable behaviour of the data flows that are not any more deterministic and become dependent to stochastic models! Thus the question is how much should we do over provisioning? According to [3] it seems that doing over provisioning equal to the double of the maximum possible load on the aggregate band in the backbone areas is enough to guarantee low delay, jitter and loss. Many times this is the only type of optimization possible for low delay since, if we don´t know the queuing policies in every router of the network the only possibility is to raise the capacity of the backbone so that, since there will not be a high load in the queues, the queues will be almost empty and then there will be no risk of starvation for the packets.

TOS field inside IP packet

Figure 3. IP header. Source: [4]

TOS is a 8-bits field in IP packet - see Figure (3). As defined in the original RFC [4], TOS should “provides an indication of the abstract parameters of the quality of service desired”. So this should allow to mark an IP packet with a desired priority: the source could choose to minimize the delay, maximize the throughput or maximize the reliability. Of course the major problem in real time systems such audio conferencing is the delay: in fact if the delay is greater than a certain threshold it is equivalent to a lost packet. Unfortunately not a lot of service providers and router manufacturers have implemented in their systems a way to treat packets with different TOS codes in different manners: this causes the packet to be treated in different ways in the path from the source to the destination and so the QoS cannot be guaranteed. Nowadays TOS is either ignored,

0 1 2 3 4 5 6 7 | reservedTOS FIELD

used for explicit congestion notification [5] or to store DiffServ code point (see next paragraphs).

Intserv

Intserv, as specified in [6] allow the source to specify different QoS parameters for each data flow: the routers in the networks reserve resources for each flow, each call (or session) is started by signalling so that each application in the source node opens a session that can eventually be refused by the destination node. The data flow is characterized by a “T-spec” array and the desired QoS by a “R-spec” array for each flow. Unfortunately, due to scalability problems, Intserv solution fits only small LAN and not WAN such internet; this is the reason why nowadays it is not very used.

Diffserv

Diffserv allows different kinds of over provisioning on different classes of service. In [13] are defined some provisioning classes and different policy domains (so that it is possible to specify different policies in different domains). With Diffserv it is possible to do packet classification, traffic shaping, marking the packets using the field TOS (see Figure 3) with DSCP (Differentiated Services Code Point), doing CAC (Connection Admission Control) and traffic dropping and classification of the traffic in queues with different priorities. Special tables called PIB (Policy Information Base) are sent over the network to the nodes that perform QoS controls. In [14] a comparison between DiffServ and IntServ is made, nowadays DiffServ is much more used than IntServ however IntServ can be used inside a LAN so the typical scenario is LAN with IntServ connected to WAN with DiffServ.

RSVP

RSVP stands for Resource reSerVation Protocol [15]. This protocol is designed for both unicast and multicast traffic, it allows to book resources on the path on which the data is being transferred. In addition it is possible to send requests with QoS requirements to the nodes on that path: each node try to reserve a much resources as are needed to satisfy the QoS requirements. RSVP does no routing, however, given many routing possibilities it can decide which packets, according to the priorities and groups, should be on the same path. The packets are classified by a packet classifier and then sent to the packet scheduler that will send the packets on a path or another according to the type of the packet (class). A RSVP process continuously exchanges informations with the scheduler, the routing process and the policy control.

Future evolution

Since the QoS is a quite new research field it can be interesting to take a look to the possible future evolution of the technology. To do that it can be interesting to see what are the practical solutions that are provided by companies around the world. One interesting solution is that provided by Sprint in [16]: Virtual Private Network and MPLS to provide guaranteed QoS to business customers. For sure not all the users are supposed to support the cost of a VPN just because they want to make audio conferencing but it can be interesting for big companies that need to have worldwide communications among employees and need to be sure that those communications will, with high probability, never be interrupted or having very bad quality. Traffic in the backbone is divided in classes of service with different priorities (and fees), this leads also to a different queuing policies insides the nodes resulting to a deterministic maximum end to end delay known a priori! These characteristics are fundamental when one has to deal with real time applications such voice conferencing. It is also interesting to note that there is a direct level-3 (IP) support to multicasting and some performance guarantees like: “Packet Loss performance metric:

0.1% or less globally” or “Jitter performance metric: 2 ms or less globally”. VPNs can also add end-to-end security to the network, for related security issues see [21].

SDP

Session Description Protocol [12] is often used to format SIP session descriptions, in addition it can be used by RTSP during a media streaming and for multicasting announcements.STP session descriptions may (it is recommended) include some informations about the available bandwidth to be used by the session, the transport protocol (RTP, UDP...), the type and the format of media for the session.

RTP and RTCP [8][9]

RTP is an application level protocol born to efficiently transfer multimedia data. After P2P-SIP has performed the resolution of addresses, negotiated the compression type and codec, then multimedia data is transferred end to end. Both UDP and TCP are not suitable to transfer multimedia data since: UDP is fast but does not guarantee anything in terms of data loss recovery, jitter and packets´s sequence, TCP is reliable but slow because of delays in case of loss (retransmissions) and congestion control can cause variations in the available bandwidth. These are the motivations for a new transport protocol: Real Time Protocol. RTP is designed for

interactive audio/video so theoretically fits at 100% the audio conferencing problem. Unfortunately it does not directly support QoS so, again we don´t know a priori the QoS that a conference will have. However practically it seems to work quite well and that is why nowadays is the most used protocol to carry real time multimedia data. RTCP is a protocol that works together with RTP: with RTCP the destination of a multimedia flow periodically sends feedback informations to the source to report the quality of the multimedia flow. RTP has been designed for many purposes, one of them is simple multicast audio conference, in this case RTP headers contain informations about the audio codec (PCM, ADPCM, CELP...) and the codec can be changed at any time since eventually each packet can specify a different codec so that new users can join the discussion at any moment and the source can accommodate them by simply switching the codec in the packet header. RTP packets contain also a timestamp so that if the destination receive packets in the wrong order they can be sorted and then processed. However if a packet is delayed too much (parameters like these are freely configurable by the programmer) that packet should be discarded and the processing of the other packets should go on. RTP does not support directly multicast, so if the network does not support multicast, a unicast connection should be established for each pair of peers and then this solution could not scale if there are too many peers since too many connections on the same host means bandwidth division (theoretically by the number of peers) and also not enough computational power.

SIP and QoS

According to [1], during the SIP session setup, the INVITE message let the destination pick the audio protocol within a set of specified audio/video codecs. However this it the typical behaviour of the re-invitation message since the first invitation message (sent before the re-invitation) has the purpose of establish a best effort session. To do that the TOS field inside IP header is set to best effort = |000000|. Even SIP is media-independent a SIP session establishment can fail because of lack of resources (usually bandwidth). Generally SDP is used to avoid that a call is established if there are not enough resources to perform the call. Since when one deals with P2P communications she does not know a priori how big is the latency and the capacity of the channels among nodes, it could be very useful to compress SIP messages applying signalling compression (SigComp) as specified in [17]. This technique of compressing SIP messages has proven in [18] to be essential when one deals with the radio channel (high latency) and has to be taken in consideration to avoid high delays caused by a portion of peers to be connected via radio.SIP protocol (RFC [7]) does not specify explicitly which protocol to use for QoS support. However Iit does exist a “warning field”, inside the header of the response messages that can contain important information about the protocol used to grant QoS. These warning messages contain a code, a human readable message (explaining the reason of the warning) and the host name. I will

not describe in detail all the warning codes and relatives messages but it is interesting to analyse the warning codes in the range [370,379] since they are related to the quantitative parameters of QoS requested in the session description. Messages are reported in figure 3.

370 Insufficient bandwidth: The bandwidth specified in the session description or defined by the media exceeds that known to be available.

Figure 3. warning messages

It can be noticed that there is only one warning message: this means that most of the QoS management is demanded to the protocols SIP is supposed to work with, according to the RFC: RTP [8] and RTCP [9], RTSP [10], MEGACO (now Gateway Control Protocol Version 1) [11] and SDP [12].

Conclusion

It seems that nowadays the QoS in general is still largely dependant on the low level layers and the contract agreements with the service providers. However for big companies it is not difficult to build up entire audio conferencing infrastructures that uses the Session Initiation Protocol since they often own big LANs or afford the cost for VPN or dedicated infrastructures. Due to the heterogeneous and unpredictable speeds and computational capacity in the nodes, it seems unlikely to see in the future systems with guaranteed QoS built on plain P2P systems but, instead on hierarchical sets of P2P sub-systems.

References

[1] Henry Sinnreich and Alan B. Johnston. Internet Communications Using SIP - Delivering VoIP and Multimedia Services with Session Initiation Protocol. Wiley, 2006.[2] RFC 1633 - Integrated Services in the Internet Architecture: an Overview. IETF, 1994. http://www.ietf.org/rfc/rfc1633.txt[3] Tim Szigeti and Christina Hattingh. End-to-End QoS Network Design. Cisco Press. November 09, 2004 ISBN : 1-58705-176-1. 768 pages[4] RFC 0791 – Internet Protocol: protcol specification. IETF, 1981. http://www.ietf.org/rfc/rfc0791.txt[5] RFC 3168 - The Addition of Explicit Congestion Notification (ECN) to IP. IETF, September 2001. http://www.ietf.org/rfc/rfc3168.txt[6] RFC 2115 - General Characterization Parameters for Integrated Service Network Elements. IETF, 1997. http://www.ietf.org/rfc/rfc2215.txt[7] RFC 3261 - SIP: Session Initiation Protocol. IETF, June 2002. http://www.ietf.org/rfc/rfc3261.txt

[8] RFC 3550 - RTP: A Transport Protocol for Real-Time Applications. IETF, July 2003. http://www.ietf.org/rfc/rfc3550.txt[9] RFC 3550 - RTPCP: RTP Control Protocol. IETF, July 2003. http://www.ietf.org/rfc/rfc3550.txt[10] RFC 2326 - Real Time Streaming Protocol (RTSP). IETF, 1998. http://www.ietf.org/rfc/rfc2326.txt[11] RFC 3525 - Gateway Control Protocol Version 1. IETF, June 2003. http://www.ietf.org/rfc/rfc3525.txt[12] RFC 4566 - SDP: Session Description Protocol. IETF, July 2006. http://www.ietf.org/rfc/rfc4566.txt[13] RFC 3317 - Differentiated Services Quality of Service Policy Information Base. IETF, March 2003. http://www.ietf.org/rfc/rfc3317.txt[14] Harju, J.; Kivimaki, P. - Co-operation and comparison of DiffServ and IntServ: performance measurements. IEEE. Digital Object Identifier 10.1109/LCN.2000.891025[15] RFC 2205 - Resource ReSerVation Protocol (RSVP). IETF, 1997. http://www.ietf.org/rfc/rfc2205.txt[16] Sprint MPLS VPN. IP Whitepaper. January 2005http://www.sprintworldwide.com/english/contact/MPLS_VPN_WP.pdf[17] Draft. IETF. Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP). March 2007. http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-sip-05.txt[18] Research paper. Performance Analysis of SigComp for 3G Cellular Networks. W. Han, K.-j. Lee, H.-h. Park, K.-g. Lee, and J. Jang. http://www.actapress.com/PaperInfo.aspx?PaperID=30368[19] William C. Hardy. VoIP Service Quality: Measuring and Evaluating Packet-Switched Voice. McGraw-Hill. 2003.[20] Max Welz. Peer-to-Peer audio conferencing using SIP: P2P Architecture. Technical report, Kungliga Tekniska Högskolan, 2007.[21] Luca Maccari. Peer-to-Peer audio conferencing using SIP: Security issues. Technical report, Kungliga Tekniska Högskolan, 2007.

FiguresAll figures/graphics have been realized with open source tools such as Dia and OpenOffice:http://www.gnome.org/projects/dia/ http://www.openoffice.org

Peer-to-Peer audio conferencing using SIP:

P2P security issues

Luca Maccari

May 11, 2007

Abstract

This report is part of a collection of three report describing several aspects of Peer-to-Peeraudio conferencing using SIP: security, Quality of Service and P2P architecture. This particularreport will detail in the P2P security; in this paper it will be analyze the solutions that someother P2P architecture use and then we will try to give the best solution for making secureaudio-conferencing using SIP.

Contents

1 Introduction 2

2 Security in overlay network 22.1 Overlay network : briefly introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 22.2 Typology of overlay network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22.3 Sybil attack : an overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.4 MITM (Man In The Middle) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.5 Self certifying SIP URIs in P2P SIP network . . . . . . . . . . . . . . . . . . . . . . 42.6 Alternative way of autentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.7 Conferencing consideration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Conclusion 6

References 7

1

1 Introduction

The typology of information exchanged over Internet is various ( HTTPS, ssh and many more);it is proved that most of the Internet traffic is generated by peer-to-peer network [San05]. If wethink that most of the VoiceOverIP traffic between peers is uncrypted,the risk of caption of reservedinformation (that a company,an institutions or two friends exchange) by a malicious peers is veryhigh. VoIP introduce others type of problems that involve,for example, SPIT (SPam Over Internettelephony); if we think about how tedious is spam email,shall we even imagine voice spam in ourconversation? The problem in P2P application for handling secure conversation is : ”who canmanage a policy for accepting/rejecting a peer?”. This is a really hard problem to solve if we don’tintroduce centralized strument for monitoring the access of users;our goal is to realize secure P2Paudio conferencing utilizying super-peer networks,as is explained in next chapter 2.

2 Security in overlay network

2.1 Overlay network : briefly introduction

In this paper we assume that the concept of P2P network overlay as well as DHT are very wellknow concept; we aren’t going to explain on how a overlay network is working. The problem thatwe are going to try to resolve is : how secure will be built this solution?Basic, we are going to apply the solution onto a overlay network like Chord2 [YJJ06] ;this overlayis composed by peers and super peers; we assume that these last peers from now have the onlytask to act as entry point for peers that want to join in the ring,forwarding incoming request andgive response to peers. A peer is elegible to be super-peer whenever it has good quality for improvethe performance of the overlay network;this kind of quality are availability of bandwidth,averagesession time,CPU/memory and latency.

2.2 Typology of overlay network

Recently the use of product using VoiceOverIP for phone all around the world is increasingexponentially. The predominant structure used for VOIP up-to-now is client-server,with SIP serversmanaging the traffic and the clients that just need to sign in. What we want,instead of this typologyof architecture, is building a P2P SIP network that supports audio-conferencing;we would be able tomanage the reserved conversation of the nodes in any case. The overlay network that our solutionis going to work is Chord2, a typology of network that is based onto overlay network based usingDHT and the super peer nodes.

2

There are several problem in the overlay network that uses DHT,the two biggest are evenreported in [ES] and are the follow:

1. is the super-peer node that i’m asking for joining a trusted node?

2. is the joining node a malicious one?

The major risk is to find in the ring,after X joining of nodes,X malicious nodes.With taking inconsideration that any peers that satisfy certain conditions can become super-peers we can find aentire ring that is made of malicious peers.This last choice is even call The sybil attack [Dou] [GDA]that is described in the next paragraph 2.3.In the case of conferencing this problem could be bigger;the probability that some peers can intercept information is growing as the partecipants of theconference increase. For giving a valid solution to that problem we need to analyze first solutionsapply to basic Chord network overlay.

2.3 Sybil attack : an overview

Sybil is one of the cancer that can afflict a DHT table. Malicious nodes have two behavior : noncooperation or flooding .Non-cooperation node means that they never look-up;whenever there is arequest,they just don’t give back any information; this cause in the network a slower behaviour andthe structure of the ring will be fragile. The other behaviour that can associated to a malicious nodeis flooding;whenever it receive a look up request,it provide as response another malicious node.Thisproblem could not be resolve without using a central node. Dinger and Hartenstein [DHHA] triedto resolve the problem using a general algorithm that can work with all overlay network that useDHT;they use an hash algorithm to control a ”join request”;the basic idea is based on compliance: if more than a certain number of nodes that have checked the information are in agree with whatthey calculate,the node can join to the network. A more general problem is Eclipse attack [AS];this problem involve a lot of malicious peers that are inside the network;they can ”ecplise” nonmalicious nodes mainteining the control of the overlay network.Castro et al give a solution of thisproblem in [AS]

2.4 MITM (Man In The Middle)

Let’s see how man in the middle (MITM) attack works in Chord. Suppose we have a node,we give anumber for semplicity,let’s give it 156.That node acts like a malicious node,and we have somewherea node requesting for a content. When the message is going to be redirect to the source that askedfor the content it will receive from the node 156 (that was in the routing table of the requester) awrong ip-address and so,in a VO-IP enviroments could be a deviation of the call to other users.Ina conferencing this risk could be higher,because if only one of the node is wrong that the entireconversation will be not secure. In a case of P2P SIP the content must be protected; the contentstored in the network is the binding of SIP-URI (the identifier of the users in the network) and thelocation.The idea that we have for certifying data is not new (a discussion [See] on how autenthicate

3

content in peer-to-peer network is even treat here;the idea is even used in many applications,likeCGA [FDa] or [FDb]) ; next we are going to explain how to build a self certyfing SIP-URIs.

2.5 Self certifying SIP URIs in P2P SIP network

This idea has been developed by Seedorf [See]; he realized a solution for protecting location frombinding updates.Using RSA, the user creates public and private key;then he/she create a SIP-URIusing the hash of the public key;then he/she can use his/her private key to binding upgrade to bestored in the network;then if a user want to verify the identity of a location-binding he has justto hashing the public key and verify that that one belong to the SIP-URI and verify the digitalsignature with the public key. Seedorf detect these three steps :

1. generating a SIP URI using cryptography: user generate the public/private key,hashesthe public one,convert the result in a string and concatenate that string with his domain(ex.xx@domain)

2. Registering a location for a SIP URI: an entry of the Chord will be composed of(u1,IPu1,s1,Kpubu1) where s1 is the result of the sign of the current location u1

3. Verify the correctness of location data: a third node will be able to verify if the resourcethat he want is really that witch he received just verifying if the entry that he public key thathe received belongs to the domain specified with the SIP URI and if yes he will verify thelocation signature with the public key.

We now have to take care about two things;the first one is that SIP URI has to be in agreewith SIP standards [MH];the second one is that an user must be able to write the SIP URI in theuser interface.Seedorf[See] resolve the problem of the SIP URI converting the hash of the public keyinto a string,exactly containing only lower case letters and digits. This solution is working good forpeer-to-peer system;as matter of fact[See] the solution keep the behiavior of the network far fromusing centralyzed server(one or more) for realizing security in the network. This solution has evennegative aspects;first of all,all the time that we want to know if a content is from a malicious nodewe have to spend time for be sure of that and waste a lot of resource;in a real-time enviroment likeVOIP is this would be a bottleneck. Another problem of that solution is might the user don’t wantto remember a strange string for logging in the ring;this could be a cause for migrating to othersproduct like Skype1 .

1http://www.skype.com/

4

2.6 Alternative way of autentication

The proposed solution that we explained in the previos section it’s not the only solution that isgood for P2P SIP;Phil Zimmerman gave another type of authentication based on ZRTP[P.Z]. Thisnew protocol created by Zimmermann (that had created even PGP,Pretty Good Privacy) is basedon another protocol,RTP (Real Time Transport Protocol). ZRTP is a key agreement protocolwhich uses Diffie- Hellman (D-H) key exchange during call setup ın-band” in the RTP stream.Thesecurity model used for the implementation is like SSH:exchanging keys supposing that there is nosniffer intercepting the keys and then start to exchange data encrypted. The first D-H exchange isfor creating a shared secret;this secret will be used by the users for generating a master key.Thisconcept is a project2 and there’s a implemented version for that project. It can be used withthe most P2P SIP software (obviously not with skype).Our goal however is to realize P2P SIPconferencing,so we must adapt that software before having an available version.

2.7 Conferencing consideration

In previous section we were concerning on how Chord will be secure and we explain how solutionswas evaluated; the problems that we expose up are much more heavier when we are speaking aboutconferencing and Chord2. The security of the network is essential as well as the absolute nonmalicious behaviour of internal node; with this in mind our solution we will use the algorithmthat[See] introduced for this reason :

1. users can know if an content is from a corrupted node just doing a check;

2. the ring is robust and scalable;

3. no introduction of third part for autentication;

2http://zfoneproject.com/

5

3 Conclusion

We saw more than one problem that DHT routing table introduce involving the security of thering.We saw that Sybil can not be resolved without a centralized authority;it’s clearly impossiblejoining to a network and be sure that the father node will be a trusted node;we have to take some riskbut improving the algorithm that was briefly reported in this paper. Zimmermann has introducedsomething new for the field of VOIP security : he introduced a procedure that is similar,for howit works,to SSH,however that solution involve only two parts. The clear concept and behavior ofthe Seedorf’s solution shall be study and enlarge for using in an enviroment like video and audioconferencing ; as he showed we can every time check for the integrity of data,and that is exactlywhat we want when we are treating some delicate and personal data like calling in a P2P network.

6

References

[AS] Peter Druschel Antony Rowstron Atul Singh, Miguel Castro.

[DHHA] Jochen Dinger, M. Frans Kaashoek Hannes Hartenstein, and Ross Anderson. Defendingthe sybil attack in p2p networks: Taxonomy, challenges, and a proposal for self-registration.

[Dou] John R. Douceur. The sybil attack.

[ES] Robert Morris Emil Sit. Security considerations for peer-to-peer distributed hash tables.

[FDa] David Karger Robert Morris Ion Stoica Frank Dabek, M. Frans Kaashoek. Cryptographi-cally generated addresses(cga).

[FDb] David Karger Robert Morris Ion Stoica Frank Dabek, M. Frans Kaashoek. Wide-areacooperative storage with cfs.

[GDA] M. Frans Kaashoek George Danezis, Chris Lesniewski-Laas and Ross Anderson. Sybil-resistant dht routing.

[MH] Eve Schooler Jonathan Rosenberg Mark Handley, Henning Schulzrinne. Sip: Sessioninitiation protocol.

[P.Z] J.Callas P.Zimmerman, A.Johnston. Zrtp: Extensions to rtp for diffie-hellman keyagreement for srtp.

[San05] Sandvine. Edonkey - still king of p2p in france and germany. Technical report, 2005.

[See] Jan Seedorf. Using cryptographically generated sip-uris.

[YJJ06] Jiaw-Chang Wang Yuh-Jzer Joung. A two layer chord for reducing manteinance overheadvia heterogeneity. 2006.

7