From p2psip-bounces@ietf.org Tue Nov 06 21:08:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpaKj-0002MR-1P; Tue, 06 Nov 2007 21:07:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpaKh-0002Lz-5K for p2psip@ietf.org; Tue, 06 Nov 2007 21:07:55 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpaKd-0002E3-9D for p2psip@ietf.org; Tue, 06 Nov 2007 21:07:55 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JR4006SZ5X2L4@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 06 Nov 2007 18:07:50 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JR4004RM5X00I@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 06 Nov 2007 18:07:50 -0800 (PST) Date: Tue, 06 Nov 2007 20:07:01 -0600 From: Spencer Dawkins To: P2PSIP Mailing List Message-id: <02a601c820e2$e2b416d0$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Just as a heads-up - we've redone the Use Case draft (as "application scenarios") and submitted the document - should be available now. Please feel free to express opinions (and outrage - flaming torches and pitchforks will work better in cyberspace than in damp Vancouver :-) Thanks, Spencer >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Application Scenarios for Peer-to-Peer Session > Initiation Protocol (P2PSIP) > Author(s) : D. Bryan, et al. > Filename : draft-bryan-p2psip-app-scenarios-00.txt > Pages : 19 > Date : 2007-11-06 > > This document attempts to identify and classify application scenarios > of P2P based SIP. It does not attempt to exhaustively enumerate > these scenarios, and is focused exclusively on scenarios related to > real-time IP communication. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bryan-p2psip-app-scenarios-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-bryan-p2psip-app-scenarios-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bryan-p2psip-app-scenarios-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 06 21:26:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipace-0001tb-Gy; Tue, 06 Nov 2007 21:26:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipacd-0001sK-5n for p2psip@ietf.org; Tue, 06 Nov 2007 21:26:27 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipaca-0002oe-0y for p2psip@ietf.org; Tue, 06 Nov 2007 21:26:27 -0500 Received: from Henning-Schulzrinnes-Computer (pool-70-21-200-37.nwrk.east.verizon.net [70.21.200.37]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lA72QM5p024047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 6 Nov 2007 21:26:23 -0500 (EST) Message-Id: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> From: Henning Schulzrinne To: P2PSIP Mailing List Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Tue, 6 Nov 2007 21:26:22 -0500 X-Mailer: Apple Mail (2.912) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -1.0 (-) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [P2PSIP] Proposal for progress on protocols X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'd like to propose a mechanism to make progress on converging on a protocol. My high-level impression is that most of the proposals, with the exception of the HIP-based ones, are philosophically not that far removed, and the differences are more at the mechanical level. One way to make progress would be to identify some of the major pieces, and then, in Vancouver, systematically go through them. An initial list, definitely incomplete, includes - packet format - NAT traversal for p2p messages (not media or SIP signaling) - channel security for p2p messages - recursion vs. iterative - hash algorithm negotiation and usage One possibility is to identify a volunteer for each area, so that the task is more manageable. If there are major philosophical differences, we should probably discuss those first, however. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 06 21:54:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipb3M-0001Bj-0J; Tue, 06 Nov 2007 21:54:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipb3K-0001B7-Ly for p2psip@ietf.org; Tue, 06 Nov 2007 21:54:02 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipb3H-0003sk-Je for p2psip@ietf.org; Tue, 06 Nov 2007 21:54:02 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JR400M3081OTP@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 07 Nov 2007 10:53:48 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JR4001MV81NBX@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 07 Nov 2007 10:53:48 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JR400BFI81NL8@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 07 Nov 2007 10:53:47 +0800 (CST) Date: Wed, 07 Nov 2007 10:53:47 +0800 From: JiangXingFeng Subject: FW: [P2PSIP] Proposal for progress on protocols To: 'P2PSIP Mailing List' Message-id: <007901c820e9$6af81090$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acgg5aeCir9a0fXOQ/KNgijzAuUDyQAAeRlgAAByuYA= X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, all: Sorry for not copying to the list. Regards! -- Jiang XingFeng > -----Original Message----- > From: JiangXingFeng [mailto:jiang.x.f@huawei.com] > Sent: Wednesday, November 07, 2007 10:53 AM > To: 'Henning Schulzrinne' > Subject: RE: [P2PSIP] Proposal for progress on protocols > > Hi, Henning: > > See inline. > > -- > Jiang XingFeng > > -----Original Message----- > > > > I'd like to propose a mechanism to make progress on converging on a > > protocol. My high-level impression is that most of the proposals, with > > the exception of the HIP-based ones, are philosophically not that far > > removed, and the differences are more at the mechanical level. One way > > to make progress would be to identify some of the major pieces, and > > then, in Vancouver, systematically go through them. > I agree with your proposal. We could discuss these issues one by one and get the > best solution to them, then we could assemble them into a integrated protocol. > > An initial list, > > definitely incomplete, includes > > > > - packet format > > - NAT traversal for p2p messages (not media or SIP signaling) > > - channel security for p2p messages > > - recursion vs. iterative > IMHO, we should consider semi-recursive and overlay native routing mode (it > means that in some cases the response will be returned to the source peer in the > same way as the request which are forwarded through the overlay.) > > - hash algorithm negotiation and usage > > I'd like to add the following two items: > >- Service discovery mechanism which could be used to find out which peers in the > overlay provides which kinds of service which may be helpful to overlay operations. > >- an end-to-end reliability mechanism; source peer could retransmit the request, > but how do the destination peer knows whether the response has returned to the > source peer correctly. It may be helpful to some operations in the overlay. For > example, if Peer A and Peer B should perform the ICE procedure to traverse NAT > between them, in P2P overlay, it often relies on the preceding transaction to > exchange their own candidate to the other. So the question is: when the destination > peer B sends the response, when will the destination peer start the ICE connectivity > check? Maybe the response has been dropped in transit. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 07 04:02:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpgnY-0006gQ-9N; Wed, 07 Nov 2007 04:02:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpgnW-0006fA-FJ for p2psip@ietf.org; Wed, 07 Nov 2007 04:02:06 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpgnS-0007sU-B1 for p2psip@ietf.org; Wed, 07 Nov 2007 04:02:06 -0500 Received: by ug-out-1314.google.com with SMTP id u2so274785uge for ; Wed, 07 Nov 2007 01:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=l3NUrGwZ8+VfpHUJ4IK+5t0amq57rkJj7l4ciGOGqKc=; b=OBpfnwJVvJov8yEX27h8E7Fvk5kgXn8ZPVAUSVsylIaGYjsk7zQWltTVY2Obl/xj9fJoAZLQOwWiPz4jaZjR0wcdmUrdnGamcurV00/8w0naroYDfyCUXd6LlM9kMTRuhIqHtFCxTjirM9nvi0nSG15PoRtHgzO2hFOVd3edP9U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UVlzzUHASj/lMIYYtzHLCFfL+aojoomdnsQEckns0iE7fIkdfY/uAfKxRbbootaXFYAm/+M9Ta5W7rHOmMvtdxGvgAwhH6DQeI4holyc7U5nwI8LRzoJHvRK722I6NASz40bVqQCHYod8oUyalYEJ+HfmqrhJhpoPyrx7OJM1og= Received: by 10.66.243.4 with SMTP id q4mr122354ugh.1194426121479; Wed, 07 Nov 2007 01:02:01 -0800 (PST) Received: by 10.67.30.12 with HTTP; Wed, 7 Nov 2007 01:02:01 -0800 (PST) Message-ID: <618e24240711070102s205e1e71u277079401e096e79@mail.gmail.com> Date: Wed, 7 Nov 2007 10:02:01 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: JiangXingFeng Subject: Re: FW: [P2PSIP] Proposal for progress on protocols In-Reply-To: <007901c820e9$6af81090$6905a40a@china.huawei.com> MIME-Version: 1.0 References: <007901c820e9$6af81090$6905a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2099955507==" Errors-To: p2psip-bounces@ietf.org --===============2099955507== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGVsbG8sCgpPbiAwNy8xMS8yMDA3LCBKaWFuZ1hpbmdGZW5nIDxqaWFuZy54LmZAaHVhd2VpLmNv bT4gd3JvdGU6Cj4gPiA+IEknZCBsaWtlIHRvIHByb3Bvc2UgYSBtZWNoYW5pc20gdG8gbWFrZSBw cm9ncmVzcyBvbiBjb252ZXJnaW5nIG9uIGEKPiA+ID4gcHJvdG9jb2wuIE15IGhpZ2gtbGV2ZWwg aW1wcmVzc2lvbiBpcyB0aGF0IG1vc3Qgb2YgdGhlIHByb3Bvc2Fscywgd2l0aAo+ID4gPiB0aGUg ZXhjZXB0aW9uIG9mIHRoZSBISVAtYmFzZWQgb25lcywgYXJlIHBoaWxvc29waGljYWxseSBub3Qg dGhhdCBmYXIKPiA+ID4gcmVtb3ZlZCwgYW5kIHRoZSBkaWZmZXJlbmNlcyBhcmUgbW9yZSBhdCB0 aGUgbWVjaGFuaWNhbCBsZXZlbC4gT25lIHdheQo+ID4gPiB0byBtYWtlIHByb2dyZXNzIHdvdWxk IGJlIHRvIGlkZW50aWZ5IHNvbWUgb2YgdGhlIG1ham9yIHBpZWNlcywgYW5kCj4gPiA+IHRoZW4s IGluIFZhbmNvdXZlciwgc3lzdGVtYXRpY2FsbHkgZ28gdGhyb3VnaCB0aGVtLgoKSU1ITyB0aGUg a2V5IHBvaW50IGlzIGNvbXBsZXRpbmcgYW5kIHVwZGF0aW5nIHRoZSBjb25jZXB0cyBkb2N1bWVu dApzcGVjaWZ5aW5nIGlzc3VlcyBsaWtlOiBvbmUgb3IgdHdvIHByb3RvY29scywgcmVxdWlyZW1l bnRzIGZvciB0aGUKb3ZlcmxheSwgYmFzaWMgZnVuY3Rpb25hbGl0aWVzLCBldGMuIEkgdGhpbmsg aXMgbW9yZSBpbXBvcnRhbnQgdG8KZGVmaW5lIFAyUFNJUCBwaGlsb3NvcGh5IGluc3RlYWQgb2Yg ZGVmaW5pbmcgaWYgY2hvcmQgd2lsbCBiZSB1c2VkIHRvCmltcGxlbWVudCB0aGUgREhUIG9yIHBl ZXIgcHJvdG9jb2wgd2lsbCBiZSBiaW5hcnkgb3Igbm90LgoKSSBzdWdnZXN0IHRvIGluY2x1ZGUg YSAnY29tbWVudHMgb24gY29uY2VwdHMgZG9jdW1lbnQnIHNlc3Npb24gaW4gdGhlCm1lZXRpbmcg YWdlbmRhCgo+ID4gPi0gU2VydmljZSBkaXNjb3ZlcnkgbWVjaGFuaXNtIHdoaWNoIGNvdWxkIGJl IHVzZWQgdG8gZmluZCBvdXQgd2hpY2ggcGVlcnMKPiBpbiB0aGUKPiA+IG92ZXJsYXkgcHJvdmlk ZXMgd2hpY2gga2luZHMgb2Ygc2VydmljZSB3aGljaCBtYXkgYmUgaGVscGZ1bCB0byBvdmVybGF5 Cj4gb3BlcmF0aW9ucy4KCldlIChLcnp5c3p0b2YgSGVubmlnLCBNaWNoYWwgR2llcm1hc2luc2tp IGFuZCBtZSkgYXJlIHdvcmtpbmcgaW4gU09BLVAyUFNJUC4KClRoaXMgcHJvamVjdCBhaW1zIHRv IGRlZmluZSBhbiBvcGVuLCBkZWNlbnRyYWxpemVkIGFuZCBzZXJ2aWNlCm9yaWVudGVkIGFyY2hp dGVjdHVyZSBmb3IgUDJQU0lQIChQZWVyLXRvLVBlZXIgU2Vzc2lvbiBJbml0aWF0aW9uClByb3Rv Y29sKSBiYXNlZCBvdmVybGF5IG5ldHdvcmtzLiBTdWNoIGFyY2hpdGVjdHVyZSB3aWxsIGFsbG93 IHRoZQplYXN5IGFuZCByYXBpZGx5IGRlcGxveW1lbnQgb2YgYWR2YW5jZWQgc2VydmljZXMgaW4g c3VjaCBlbnZpcm9ubWVudHMKd2hlcmUgY2VudHJhbGl6ZWQgc2VydmVycyBhcmUgZGFtYWdlZCwg bm90IGF2YWlsYWJsZSBvciBqdXN0IHdhbnQgdG8KYmUgcmVkdW5kYW50LiBPcGVuIGFyY2hpdGVj dHVyZSB3aWxsIGFsc28gcHJvdmlkZSBlbmQgdXNlcnMgd2l0aApwb3NzaWJpbGl0eSBmb3IgY3Jl YXRpbmcgdGhlaXIgb3duIHNlcnZpY2VzIGluZGVwZW5kZW50bHkgb3Igd2l0aApjb29wZXJhdGlv biB3aXRoIGNvbW11bmljYXRpb24gY29tcGFuaWVzLgoKT3VyIGdvYWwgaXMgdG8gZGVzaWduIGEg ZnJhbWV3b3JrIGZvciBwcm92aWRpbmcgYWR2YW5jZWQgY29tbXVuaWNhdGlvbgpzZXJ2aWNlcyBi YXNlZCBvbiBwMnBzaXAgb3ZlcmxheSBuZXR3b3JrLgoKU2NvcGUgb2YgcHJvamVjdCBjb3ZlcnM6 CgogKiBCdWlsZGluZyBkZXNpZ24gb3BlbiBhcmNoaXRlY3R1cmUgdGhhdCBhbGxvd3MgZGVwbG95 bWVudCAgbmV3CmFkdmFuY2VkIHNlcnZpY2VzIGluIGRpc3RyaWJ1dGVkIGFuZCBzZXJ2ZXJsZXNz IGVudmlyb25tZW50IHdpdGhvdXQKbW9kaWZ5aW5nIGN1cnJlbnQgYXJjaGl0ZWN0dXJlLgoKICog U3VnZ2VzdGVkIG9wZW4gYXJjaGl0ZWN0dXJlIHNob3VsZCBwcm92aWRlIGZvbGxvd2luZyBmdW5j dGlvbnMgZm9yCnNlcnZpY2UgZW5hYmxpbmc6CgoJLSBJbXBsZW1lbnQgYW5kIERlbGl2ZXJ5OiBh IG5vZGUgc2hvdWxkIGJlIGFibGUgdG8gY292ZXIgYSBuZXcKZnVuY3Rpb25hbGl0eSBvciBzZXJ2 aWNlLCB0aGF0IGlzOiBhIG5vZGUgc2hvdWxkIGNvbnRhaW4gYW4gZXhlY3V0YWJsZQpjb2RlIHRo YXQgaW1wbGVtZW50cyBkZXNpcmVkIHNlcnZpY2UgbG9naWMgYWxvbmcgd2l0aCBhbGwgcmVxdWly ZWQKbWVkaWEgcHJvY2Vzc2luZywgZGIgcXVlcmllcyBhbmQgc2lnbmFsaW5nIGluIG9yZGVyIHRv IGRlbGl2ZXIgYQpzZXJ2aWNlIG9yIGZ1bmN0aW9uYWxpdHkgYXMgYSBtb2R1bGFyLCBzZWxmLWNv bnRhaW5lZCBhbmQgaW5kZXBlbmRlbnQKYmxvY2sgZm9yIHJlcXVlc3RpbmcgcGVlcnMsIGUuZy4g YSBuZXcgYXBwbGljYXRpb24gdGhhdCB0cmFuc2xhdGVzCnZvaWNlIGZsb3dzIGludG8gb3RoZXIg bGFuZ3VhZ2VzCgoJLSBQdWJsaXNoaW5nOiBhIG5vZGUgc2hvdWxkIGJlIGFibGUgdG8gaW5jbHVk ZSBhIG5ldyBmdW5jdGlvbmFsaXR5IG9yCnNlcnZpY2UgaW50byBhIGdsb2JhbCBkaXJlY3Rvcnks IG9uZSBhY2Nlc3NpYmxlIGJ5IGFsbCBvdGhlciBub2Rlcy4KZS5nLjogaW5jbHVkZSB0aGUgdHJh bnNsYXRpb24gYXBwbGljYXRpb24gYXMgYSBuZXcgdHJhbnNsYXRpb24gc2VydmljZQppbnRvIHRo ZSBnbG9iYWwgc2VydmljZSBkaXJlY3RvcnkKCgktIERpc2NvdmVyeTogYSBub2RlIHNob3VsZCBi ZSBhYmxlIHRvIGxvb2sgdXAgYSBzZXJ2aWNlIG9yIGEgc2luZ2xlCmZ1bmN0aW9uYWxpdHkgaW1w bGVtZW50ZWQgYnkgYW55IG5vZGUgaW4gYSBnbG9iYWwgZGlyZWN0b3J5IGFsb25nIHdpdGgKb2J0 YWluaW5nIGEgZGVzY3JpcHRpb24gYWJvdXQgdGhlIHNlcnZpY2UgYW5kIGl0cyB1c2FnZSwgaW50 ZXJmYWNlcwphbmQgZnVuY3Rpb25hbGl0eSwgZS5nLjogZGlzY292ZXIgYW5kIGxlYXJuIGhvdyB0 byB1c2UgdGhlIHRyYW5zbGF0aW9uCnNlcnZpY2UKCQogICAgIAktIENvbXBvc2luZzogYSBub2Rl IHNob3VsZCBiZSBhYmxlIHRvIGRpc2NvdmVyIGFscmVhZHkgZXhpc3RlbnQKZnVuY3Rpb25hbGl0 aWVzIG9yIHNlcnZpY2VzLCBhbmQgaW1wbGVtZW50IG90aGVyIG5ldyBieSBjb21iaW5pbmcKZXhp c3RlbnQgb25lcy4gVGhpcyBuZXcgc2VydmljZSBzaG91bGQgYmUgYWJsZSB0byBiZSBwdWJsaXNo ZWQgYXMgYQpzZWxmIGNvbnRhaW5lZCBlbnRpdHkgaW4gb3JkZXIgdG8gYmUgZGlzY292ZXJlZCBi eSBvdGhlciBub2RlcywgZS5nLjoKaW50ZWdyYXRlIHRoZSB0cmFuc2xhdGlvbiBzZXJ2aWNlIHdp dGggdGhlIGFscmVhZHkgZXhpc3RlbnQgc2VydmljZQprbm93biBhcyAndm9pY2VtYWlsJy4gVGhl biwgbWVzc2FnZXMgc3RvcmVkIGluIHRoZSB2b2ljZW1haWwgY291bGQgYmUKdHJhbnNsYXRlZCBp bnRvIG1hbnkgbGFuZ3VhZ2VzLgoKICogRnJhbWV3b3JrIHNob3VsZCByZXVzZSBleGlzdGluZyBw cm90b2NvbHMgdG9nZXRoZXIgd2l0aCBjdXJyZW50bHkKZGV2ZWxvcGVkIHBlZXItdG8tcGVlciBw cm90b2NvbCBwcmVzZXJ2aW5nIGZ1bGwgYmFja3dhcmQgY29tcGF0aWJpbGl0eQoKICogRnJhbWV3 b3JrIHNob3VsZCBhbGxvdyBmb3IgcHJvdmlkaW5nIGFkdmFuY2VkIHNlcnZpY2VzIGluIGFkLWhv YwpwMnAgbmV0d29ya3Mgd2l0aG91dCBleHRlcm5hbCBuZXR3b3JrIHNlcnZpY2VzIGxpa2UgRE5T LCBTVFVOLCBYLjQwMCwKZXRjLiBJbiBvdGhlciB3b3JkcyBmcmFtZXdvcmsgTVVTVCBOT1QgZGVw ZW5kIG9uIGFueSBvdGhlciBzeXN0ZW1zIG9yCmFwcGxpY2F0aW9ucy4gUGVlciBtYXkgaW50ZXJh Y3Qgd2l0aCBkaWZmZXJlbnQgbmV0d29ya2VkIHN5c3RlbXMsCmhvd2V2ZXIgdGhpcyBzaG91bGQg YmUgYSBzdWJqZWN0IGZvciBzZXJ2aWNlIGRlbGl2ZXJ5IChpbXBsZW1lbnRlZApmdW5jdGlvbmFs aXR5IGluIG9uZSBvciBtb3JlIHBlZXJzKSBidXQgbm90IGZvciBvdXIgZnJhbWV3b3JrIHdoaWNo CmNvdmVycyBzZXJ2aWNlIHB1Ymxpc2hpbmcsIGxvb2t1cCBhbmQgY29tcG9zaXRpb24uIEluIGV4 YW1wbGU6IGEgcGVlcgppbXBsZW1lbnRpbmcgc2VydmljZSBYIG1heSBmZXRjaCBkYXRhIGZyb20g b3RoZXIgc3lzdGVtcyBkdXJpbmcKc2VydmljZSBkZWxpdmVyeS4gSG93ZXZlciBkdXJpbmcgc2Vy dmljZSBwdWJsaXNoaW5nLCBkaXNjb3Zlcnkgb3IKY29tcG9zaXRpb24gb25seSBzZXJ2aWNlIHJl bGF0ZWQgZGV0YWlscyBkZXNjcmliaW5nIHRoZSBzZXJ2aWNlIFgKc2hvdWxkIGJlIGV4Y2hhbmdl ZCBpbiB0aGUgZnJhbWV3b3JrIGluc3RlYWQgb2YgZGF0YSBmcm9tIGV4dGVybmFsCnN5c3RlbS4K CiAqIEZyYW1ld29yayBzaG91bGQgYmUgSVAgYmFzZWQsIGVpdGhlciBJUHY0IGFuZCBJUHY2LiBX ZSB0aGVyZWZvcmUKYWJzdHJhY3QgZnJvbSBMMiBuZXR3b3JrIHR5cGUsIGhvd2V2ZXIgc2hvdWxk IGJlIHBvc3NpYmxlIHRvIHByb3ZpZGUKc2VydmljZXMgb3ZlciBhbnkgcmFkaW8sIHhEU0wgb3Ig RXRoZXJuZXQgbmV0d29yayB0YWtpbmcgaW50bwpjb25zaWRlcmF0aW9uIHNwZWNpZmljIGNoYXJh Y3RlcmlzdGljcyBsaWtlIGJhbmR3aWR0aCwgbGF0ZW5jeSBvcgplcnJvciByYXRlLgoKICogRnJh bWV3b3JrIHNob3VsZCBlbmFibGUgc2VydmljZXMgdG8gYmUgInBsdWdnYWJsZSIgYnkgYW55IHNl cnZpY2UKcHJvdmlkZXIgLSBlaXRoZXIgYXNzb2NpYXRlZCB3aXRoIGh1bWFuIG9yIG5vdC4gSW4g b3RoZXIgd29yZHMgYW55b25lCm9uIHRoZSBJbnRlcm5ldCBjb3VsZCBwdWJsaXNoIHNlcnZpY2Vz IGRldmVsb3BlZCBieSBoaXMvaGVyIG93biAob3IKaGlzL2hlciBVQSkuIFN1Y2ggc2VydmljZSBj b3VsZCBiZSBkaXNjb3ZlcmVkIGFuZCB1c2VkIGJ5IG90aGVyIHBlZXJzCih0aGVpciBmcmllbmRz KS4gIEZyYW1ld29yayBzaG91bGQgbm90IGNvbnN0cmFpbiBtZWNoYW5pc20gZm9yCnB1Ymxpc2hp bmcgb2Ygc2VydmljZXMgd2l0aGluIFAyUFNJUCBvdmVybGF5IG5ldHdvcmsgZXNwZWNpYWxseSBz aG91bGQKbm90IGludHJvZHVjZSBjZW50cmFsIHJlZ2lzdHJhcnMgZm9yIG5hbWVzIGV0Yy4KCklu IGNhc2UgeW91IGFyZSBpbnRlcmVzdGVkIGluIHRoaXMgcHJvamVjdCwgd2UgY291bGQgYXJyYW5n ZSBhIHNtYWxsCnByZXNlbnRhdGlvbiBkdXJpbmcgdGhlIG1lZXRpbmcuCgpSZWdhcmRzLAotLSAK VmljdG9yIFBhc2N1YWwgw4F2aWxhCg== --===============2099955507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============2099955507==-- From p2psip-bounces@ietf.org Wed Nov 07 09:06:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IplXa-0005Hz-DL; Wed, 07 Nov 2007 09:05:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IplXZ-0005FA-9e for p2psip@ietf.org; Wed, 07 Nov 2007 09:05:57 -0500 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IplXY-0000mM-RP for p2psip@ietf.org; Wed, 07 Nov 2007 09:05:57 -0500 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Wed, 07 Nov 2007 06:05:43 PST Received: from inner-relay-1.corp.adobe.com (inner-relay-1.corp.adobe.com [153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lA7E5eKn003792; Wed, 7 Nov 2007 06:05:41 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lA7E5BRG004935; Wed, 7 Nov 2007 06:05:29 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 23:05:11 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Proposal for progress on protocols Date: Wed, 7 Nov 2007 06:05:08 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE235@namail5.corp.adobe.com> In-Reply-To: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Proposal for progress on protocols Thread-Index: Acgg5aKcM40EnFnGTEu5TxsURFV9OQAXlSbg References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> From: "Henry Sinnreich" To: "Henning Schulzrinne" , "P2PSIP Mailing List" X-OriginalArrivalTime: 07 Nov 2007 14:05:11.0891 (UTC) FILETIME=[3662FA30:01C82147] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear co-chairs, Can we put this item on the P2PSIP WG meeting agenda? Thanks, Henry Sinnreich -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday, November 06, 2007 8:26 PM To: P2PSIP Mailing List Subject: [P2PSIP] Proposal for progress on protocols I'd like to propose a mechanism to make progress on converging on a =20 protocol. My high-level impression is that most of the proposals, with =20 the exception of the HIP-based ones, are philosophically not that far =20 removed, and the differences are more at the mechanical level. One way =20 to make progress would be to identify some of the major pieces, and =20 then, in Vancouver, systematically go through them. An initial list, =20 definitely incomplete, includes - packet format - NAT traversal for p2p messages (not media or SIP signaling) - channel security for p2p messages - recursion vs. iterative - hash algorithm negotiation and usage One possibility is to identify a volunteer for each area, so that the =20 task is more manageable. If there are major philosophical differences, =20 we should probably discuss those first, however. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 07 09:41:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipm5z-0001xz-Oh; Wed, 07 Nov 2007 09:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipm5x-0001t0-90 for p2psip@ietf.org; Wed, 07 Nov 2007 09:41:29 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipm5t-0003AY-B6 for p2psip@ietf.org; Wed, 07 Nov 2007 09:41:29 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JR500J2M4T0OO@usaga01-in.huawei.com> for p2psip@ietf.org; Wed, 07 Nov 2007 06:41:24 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JR500A7V4SZ7Q@usaga01-in.huawei.com> for p2psip@ietf.org; Wed, 07 Nov 2007 06:41:24 -0800 (PST) Date: Wed, 07 Nov 2007 08:40:32 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Proposal for progress on protocols To: P2PSIP Mailing List Message-id: <048b01c8214c$265cdbb0$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE235@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear P2PSIP working group, Can we also discuss these topics between now and the P2PSIP meeting in Vancouver, which is about a month away? :-) We REALLY need more mailing list traffic on specific text between meetings... I agree with Henning's proposal. I'm willing to volunteer for "recursion vs iterative". Two related questions: - do we know which drafts Henning's proposal covers? Only the non-HIP drafts prepared for IETF 69, or are there other drafts people have been working on since then? and - are current versions of these drafts available, or are people working madly to submit something before the ID cutoff? Thanks, Spencer ----- Original Message ----- From: "Henry Sinnreich" To: "Henning Schulzrinne" ; "P2PSIP Mailing List" Sent: Wednesday, November 07, 2007 8:05 AM Subject: RE: [P2PSIP] Proposal for progress on protocols Dear co-chairs, Can we put this item on the P2PSIP WG meeting agenda? Thanks, Henry Sinnreich -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, November 06, 2007 8:26 PM To: P2PSIP Mailing List Subject: [P2PSIP] Proposal for progress on protocols I'd like to propose a mechanism to make progress on converging on a protocol. My high-level impression is that most of the proposals, with the exception of the HIP-based ones, are philosophically not that far removed, and the differences are more at the mechanical level. One way to make progress would be to identify some of the major pieces, and then, in Vancouver, systematically go through them. An initial list, definitely incomplete, includes - packet format - NAT traversal for p2p messages (not media or SIP signaling) - channel security for p2p messages - recursion vs. iterative - hash algorithm negotiation and usage One possibility is to identify a volunteer for each area, so that the task is more manageable. If there are major philosophical differences, we should probably discuss those first, however. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 07 11:53:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipo9b-0002IX-J8; Wed, 07 Nov 2007 11:53:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipo9a-0002HQ-HW for p2psip@ietf.org; Wed, 07 Nov 2007 11:53:22 -0500 Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ipo9W-000879-9Q for p2psip@ietf.org; Wed, 07 Nov 2007 11:53:22 -0500 Received: (qmail 18170 invoked for bounce); 7 Nov 2007 18:58:28 -0000 Received: from unknown (HELO ?130.79.90.87?) (emcho@unknown) by unknown with RC4-MD5 encrypted SMTP; 7 Nov 2007 18:58:28 -0000 Message-ID: <4731ED7B.2070901@sip-communicator.org> Date: Wed, 07 Nov 2007 17:53:15 +0100 From: Emil Ivov User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> In-Reply-To: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henning, all, I think this is definitely the way to go and both Enrico and I (as authors of one of the proposals) would be happy to contribute on any of the points in your list. We also thought that there are two other issues that would probably require some consideration: - DHT upgrades - as far as I can see, it is currently most covered by ASP, but the general opinion in Chicago seemed to be that this is indeed an important issue that would have to be addressed by the peer protocol. - Mobility - taking mobility into account would probably influence some of the design choices (underlying protocol, session flexibility, etc..) so it might be worth to try and see to what extent would the existing proposals fit mobile nodes. One last thing. We should probably try and start having some of these discussions before the meeting or, even better, to find some way to foster offline work on each topic, since they are likely to require more than the time we'll have there. I guess that Philip's presentation in Chicago was made with the same intentions, but it was pretty clear that the time we had was insufficient for any meaningful discussions. Cheers Emil Henning Schulzrinne wrote: > I'd like to propose a mechanism to make progress on converging on a > protocol. My high-level impression is that most of the proposals, with > the exception of the HIP-based ones, are philosophically not that far > removed, and the differences are more at the mechanical level. One way > to make progress would be to identify some of the major pieces, and > then, in Vancouver, systematically go through them. An initial list, > definitely incomplete, includes > > - packet format > - NAT traversal for p2p messages (not media or SIP signaling) > - channel security for p2p messages > - recursion vs. iterative > - hash algorithm negotiation and usage > > One possibility is to identify a volunteer for each area, so that the > task is more manageable. If there are major philosophical differences, > we should probably discuss those first, however. > > Henning > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 07 17:57:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IptqC-0007oY-SQ; Wed, 07 Nov 2007 17:57:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IptqA-0007hu-Qg for p2psip@ietf.org; Wed, 07 Nov 2007 17:57:42 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iptq7-0006F1-1o for p2psip@ietf.org; Wed, 07 Nov 2007 17:57:42 -0500 Received: from [192.168.2.1] (HSI-KBW-091-089-004-031.hsi2.kabelbw.de [91.89.4.31]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis) id 0MKwh2-1Iptq43xot-0005FN; Wed, 07 Nov 2007 23:57:37 +0100 Message-ID: <4732430E.5010103@tm.uka.de> Date: Wed, 07 Nov 2007 23:58:22 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [P2PSIP] Proposal for progress on protocols References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE235@namail5.corp.adobe.com> <048b01c8214c$265cdbb0$6501a8c0@china.huawei.com> In-Reply-To: <048b01c8214c$265cdbb0$6501a8c0@china.huawei.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V01U2FsdGVkX1/bFOefxAxI6JUrjvDQYmMFZZGA21ei84u5eLC dKj7nC/tlsYkf6ldZ4UBI8zPj7npN+lBT4PUC+mk1c+bqN2zR2 x9MLEqbEOZNzi93YFtngg== X-Spam-Score: -0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear working group, to answer the second question: I'm one of these people working (more or less madly ;-) ) on a proposal called "Peer-to-Peer Name Service (P2PNS)". This proposal describes our P2PSIP implementation (based on OverSim) which we presented at P2P2007 recently. The main contribution is on two aspects: One is reusability of the name service for things like distributed DNS or HIP. The other is security in a completely decentralized environment (without login severs). It would be great if these aspects could also be included in the discussion (The draft should be finished on Friday...). Regards, Ingmar Spencer Dawkins wrote: > Dear P2PSIP working group, > > Can we also discuss these topics between now and the P2PSIP meeting in > Vancouver, which is about a month away? :-) > > We REALLY need more mailing list traffic on specific text between > meetings... > > I agree with Henning's proposal. I'm willing to volunteer for "recursion > vs iterative". > > Two related questions: > > - do we know which drafts Henning's proposal covers? Only the non-HIP > drafts prepared for IETF 69, or are there other drafts people have been > working on since then? and > > - are current versions of these drafts available, or are people working > madly to submit something before the ID cutoff? > > Thanks, > > Spencer > > > ----- Original Message ----- From: "Henry Sinnreich" > To: "Henning Schulzrinne" ; "P2PSIP Mailing List" > > Sent: Wednesday, November 07, 2007 8:05 AM > Subject: RE: [P2PSIP] Proposal for progress on protocols > > > Dear co-chairs, > > Can we put this item on the P2PSIP WG meeting agenda? > > Thanks, > > Henry Sinnreich > > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, November 06, 2007 8:26 PM > To: P2PSIP Mailing List > Subject: [P2PSIP] Proposal for progress on protocols > > I'd like to propose a mechanism to make progress on converging on a > protocol. My high-level impression is that most of the proposals, with > the exception of the HIP-based ones, are philosophically not that far > removed, and the differences are more at the mechanical level. One way > to make progress would be to identify some of the major pieces, and > then, in Vancouver, systematically go through them. An initial list, > definitely incomplete, includes > > - packet format > - NAT traversal for p2p messages (not media or SIP signaling) > - channel security for p2p messages > - recursion vs. iterative > - hash algorithm negotiation and usage > > One possibility is to identify a volunteer for each area, so that the > task is more manageable. If there are major philosophical differences, > we should probably discuss those first, however. > > Henning > > _______________________________________________ -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 07 20:32:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpwGF-0004Mf-9A; Wed, 07 Nov 2007 20:32:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpwGE-0004MO-C6 for p2psip@ietf.org; Wed, 07 Nov 2007 20:32:46 -0500 Received: from exprod6og55.obsmtp.com ([64.18.1.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpwGA-0002Xc-Nn for p2psip@ietf.org; Wed, 07 Nov 2007 20:32:46 -0500 Received: from source ([192.150.20.142]) by exprod6ob55.postini.com ([64.18.5.12]) with SMTP; Wed, 07 Nov 2007 17:30:20 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lA81UIKn022633; Wed, 7 Nov 2007 17:30:19 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lA81UERE013684; Wed, 7 Nov 2007 17:30:17 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 10:30:14 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Proposal for progress on protocols Date: Wed, 7 Nov 2007 17:30:09 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE242@namail5.corp.adobe.com> In-Reply-To: <048b01c8214c$265cdbb0$6501a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Proposal for progress on protocols Thread-Index: AcghTKBBAD3d/0rQRyi7WdBx7NSUAwANdl1A References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu><24CCCC428EFEA2469BF046DB3C7A8D223AE235@namail5.corp.adobe.com> <048b01c8214c$265cdbb0$6501a8c0@china.huawei.com> From: "Henry Sinnreich" To: "Spencer Dawkins" , "P2PSIP Mailing List" X-OriginalArrivalTime: 08 Nov 2007 01:30:14.0706 (UTC) FILETIME=[E992D120:01C821A6] X-Spam-Score: -4.0 (----) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Spencer, >- do we know which drafts Henning's proposal covers? P2PP has running code and is available online.=20 I expect P2PP-01 to be out shortly. For all the existing proposals, please consider also the I-D by Brian Carpenter "Considering availability of free software when evaluating Draft Standards" ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-carpenter-ipr-pa tent-frswds-01.txt=20 A specification from which at least two independent and interoperable implementations from different code bases have been developed, _of which at least one is preferably available as free software_, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. (my underline) Henry -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Wednesday, November 07, 2007 8:41 AM To: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols Dear P2PSIP working group, Can we also discuss these topics between now and the P2PSIP meeting in=20 Vancouver, which is about a month away? :-) We REALLY need more mailing list traffic on specific text between=20 meetings... I agree with Henning's proposal. I'm willing to volunteer for "recursion vs=20 iterative". Two related questions: - do we know which drafts Henning's proposal covers? Only the non-HIP drafts=20 prepared for IETF 69, or are there other drafts people have been working on=20 since then? and - are current versions of these drafts available, or are people working=20 madly to submit something before the ID cutoff? Thanks, Spencer ----- Original Message -----=20 From: "Henry Sinnreich" To: "Henning Schulzrinne" ; "P2PSIP Mailing List"=20 Sent: Wednesday, November 07, 2007 8:05 AM Subject: RE: [P2PSIP] Proposal for progress on protocols Dear co-chairs, Can we put this item on the P2PSIP WG meeting agenda? Thanks, Henry Sinnreich -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Tuesday, November 06, 2007 8:26 PM To: P2PSIP Mailing List Subject: [P2PSIP] Proposal for progress on protocols I'd like to propose a mechanism to make progress on converging on a protocol. My high-level impression is that most of the proposals, with the exception of the HIP-based ones, are philosophically not that far removed, and the differences are more at the mechanical level. One way to make progress would be to identify some of the major pieces, and then, in Vancouver, systematically go through them. An initial list, definitely incomplete, includes - packet format - NAT traversal for p2p messages (not media or SIP signaling) - channel security for p2p messages - recursion vs. iterative - hash algorithm negotiation and usage One possibility is to identify a volunteer for each area, so that the task is more manageable. If there are major philosophical differences, we should probably discuss those first, however. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 07 20:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpwTV-0001TU-1X; Wed, 07 Nov 2007 20:46:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpwTT-0001TM-WC for p2psip@ietf.org; Wed, 07 Nov 2007 20:46:28 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpwTT-00032Q-Dq for p2psip@ietf.org; Wed, 07 Nov 2007 20:46:27 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lA81kNta002335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 7 Nov 2007 17:46:23 -0800 Received: from [10.70.41.19] (vpn-10-50-0-132.qualcomm.com [10.50.0.132]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lA81kMHn024271; Wed, 7 Nov 2007 17:46:22 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE242@namail5.corp.adobe.com> References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu><24CCCC428EFEA2469BF 046DB3C7A8D223AE235@namail5.corp.adobe.com> <048b01c8214c$265cdbb0$6501a8c0@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE242@namail5.corp.adobe.com> Date: Wed, 7 Nov 2007 17:46:21 -0800 To: "Henry Sinnreich" , "Spencer Dawkins" , "P2PSIP Mailing List" From: Ted Hardie Subject: RE: [P2PSIP] Proposal for progress on protocols Content-Type: text/plain; charset="us-ascii" X-Spam-Score: -4.0 (----) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > >For all the existing proposals, please consider also the I-D by Brian >Carpenter "Considering availability of free software when evaluating >Draft Standards" >ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-carpenter-ipr-pa >tent-frswds-01.txt > > A specification from which at least two independent and >interoperable > implementations from different code bases have been developed, _of > which at least one is preferably available as free software_, and > for which sufficient successful operational experience has been > obtained, may be elevated to the "Draft Standard" level. Henry, That draft is an individual submission that's being discussed in the IPR working group. My current assessment is that there is no consensus behind Brian's language, with multiple folks preferring the language by Scott Brim: > A specification from which at least two independent and > interoperable implementations from different code bases have been > developed, and for which sufficient successful operational > experience has been obtained, may be elevated to the "Draft > Standard" level. Issues with general deployability should be > taken into consideration, including issues of licensing terms > associated with those implementations. The main issue being that what qualifies as "free software" could turn out to be a rathole of epic proportions. For those interested in developing a consensus on this please join the IPR list and express your opinions. At this juncture, at least, this working group needs to get out a PS. We have at least six months after that to worry about DS :) . regards, Ted _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 07 21:22:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipx2Q-0007QE-6h; Wed, 07 Nov 2007 21:22:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipx2O-0007Pl-NT for p2psip@ietf.org; Wed, 07 Nov 2007 21:22:32 -0500 Received: from chip2og53.obsmtp.com ([64.18.13.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipx2O-00047b-5x for p2psip@ietf.org; Wed, 07 Nov 2007 21:22:32 -0500 Received: from source ([192.150.11.134]) by chip2ob53.postini.com ([64.18.5.12]) with SMTP; Wed, 07 Nov 2007 18:22:28 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lA82KOOP008785; Wed, 7 Nov 2007 18:20:24 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lA82MRRC023777; Wed, 7 Nov 2007 18:22:27 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 18:22:27 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Proposal for progress on protocols Date: Wed, 7 Nov 2007 18:22:22 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE249@namail5.corp.adobe.com> In-Reply-To: <4731ED7B.2070901@sip-communicator.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Proposal for progress on protocols Thread-Index: AcghXsK8tw5/3WgRQI6/s6TCNhk0nQAS5zSw References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <4731ED7B.2070901@sip-communicator.org> From: "Henry Sinnreich" To: "Emil Ivov" , "P2PSIP Mailing List" X-OriginalArrivalTime: 08 Nov 2007 02:22:27.0770 (UTC) FILETIME=[350671A0:01C821AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >- DHT upgrades Please help me understand why infrequent software upgrades have to be part of the p2p overlay functions or its services, such as SIP. Or maybe we are talking of different things? Thanks, Henry -----Original Message----- From: Emil Ivov [mailto:emcho@sip-communicator.org]=20 Sent: Wednesday, November 07, 2007 10:53 AM To: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols Henning, all, I think this is definitely the way to go and both Enrico and I (as authors of one of the proposals) would be happy to contribute on any of the points in your list. We also thought that there are two other issues that would probably require some consideration: - DHT upgrades - as far as I can see, it is currently most covered by ASP, but the general opinion in Chicago seemed to be that this is indeed an important issue that would have to be addressed by the peer protocol. - Mobility - taking mobility into account would probably influence some of the design choices (underlying protocol, session flexibility, etc..) so it might be worth to try and see to what extent would the existing proposals fit mobile nodes. One last thing. We should probably try and start having some of these discussions before the meeting or, even better, to find some way to foster offline work on each topic, since they are likely to require more than the time we'll have there. I guess that Philip's presentation in Chicago was made with the same intentions, but it was pretty clear that the time we had was insufficient for any meaningful discussions. Cheers Emil Henning Schulzrinne wrote: > I'd like to propose a mechanism to make progress on converging on a =20 > protocol. My high-level impression is that most of the proposals, with > the exception of the HIP-based ones, are philosophically not that far > removed, and the differences are more at the mechanical level. One way > to make progress would be to identify some of the major pieces, and =20 > then, in Vancouver, systematically go through them. An initial list, =20 > definitely incomplete, includes >=20 > - packet format > - NAT traversal for p2p messages (not media or SIP signaling) > - channel security for p2p messages > - recursion vs. iterative > - hash algorithm negotiation and usage >=20 > One possibility is to identify a volunteer for each area, so that the > task is more manageable. If there are major philosophical differences, > we should probably discuss those first, however. >=20 > Henning >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 07 21:22:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipx2b-0007dk-F6; Wed, 07 Nov 2007 21:22:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipx2Z-0007cU-SE for p2psip@ietf.org; Wed, 07 Nov 2007 21:22:43 -0500 Received: from chip2og54.obsmtp.com ([64.18.13.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipx2Z-000487-8w for p2psip@ietf.org; Wed, 07 Nov 2007 21:22:43 -0500 Received: from source ([192.150.11.134]) by chip2ob54.postini.com ([64.18.5.12]) with SMTP; Wed, 07 Nov 2007 18:22:33 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lA82KPOP008788; Wed, 7 Nov 2007 18:20:25 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lA82MRRE023777; Wed, 7 Nov 2007 18:22:28 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 18:22:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Nov 2007 18:22:23 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE24B@namail5.corp.adobe.com> In-Reply-To: <4732430E.5010103@tm.uka.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PNS Thread-Index: AcghkfRIvk4hY3SrTf655baaI8ANKwAGjoHQ References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE235@namail5.corp.adobe.com><048b01c8214c$265cdbb0$6501a8c0@china.huawei.com> <4732430E.5010103@tm.uka.de> From: "Henry Sinnreich" To: "Ingmar Baumgart" , "Spencer Dawkins" X-OriginalArrivalTime: 08 Nov 2007 02:22:28.0098 (UTC) FILETIME=[35387E20:01C821AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: P2PSIP Mailing List Subject: [P2PSIP] P2PNS X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Ingmar, this is very interesting. >This proposal describes our P2PSIP implementation (based on OverSim) >which we presented at P2P2007 recently. Is there a link to the existing document? Thanks, Henry -----Original Message----- From: Ingmar Baumgart [mailto:baumgart@tm.uka.de]=20 Sent: Wednesday, November 07, 2007 4:58 PM To: Spencer Dawkins Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols Dear working group, to answer the second question: I'm one of these people working (more or less madly ;-) ) on a proposal called "Peer-to-Peer Name Service = (P2PNS)". This proposal describes our P2PSIP implementation (based on OverSim) which we presented at P2P2007 recently. The main contribution is on two aspects: One is reusability of the name service for things like distributed DNS or HIP. The other is security in a completely decentralized environment (without login severs). It would be great if these aspects could also be included in the discussion (The draft should be finished on Friday...). Regards, Ingmar Spencer Dawkins wrote: > Dear P2PSIP working group, >=20 > Can we also discuss these topics between now and the P2PSIP meeting in > Vancouver, which is about a month away? :-) >=20 > We REALLY need more mailing list traffic on specific text between > meetings... >=20 > I agree with Henning's proposal. I'm willing to volunteer for = "recursion > vs iterative". >=20 > Two related questions: >=20 > - do we know which drafts Henning's proposal covers? Only the non-HIP > drafts prepared for IETF 69, or are there other drafts people have = been > working on since then? and >=20 > - are current versions of these drafts available, or are people = working > madly to submit something before the ID cutoff? >=20 > Thanks, >=20 > Spencer >=20 >=20 > ----- Original Message ----- From: "Henry Sinnreich" = > To: "Henning Schulzrinne" ; "P2PSIP Mailing List" > > Sent: Wednesday, November 07, 2007 8:05 AM > Subject: RE: [P2PSIP] Proposal for progress on protocols >=20 >=20 > Dear co-chairs, >=20 > Can we put this item on the P2PSIP WG meeting agenda? >=20 > Thanks, >=20 > Henry Sinnreich >=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, November 06, 2007 8:26 PM > To: P2PSIP Mailing List > Subject: [P2PSIP] Proposal for progress on protocols >=20 > I'd like to propose a mechanism to make progress on converging on a > protocol. My high-level impression is that most of the proposals, with > the exception of the HIP-based ones, are philosophically not that far > removed, and the differences are more at the mechanical level. One way > to make progress would be to identify some of the major pieces, and > then, in Vancouver, systematically go through them. An initial list, > definitely incomplete, includes >=20 > - packet format > - NAT traversal for p2p messages (not media or SIP signaling) > - channel security for p2p messages > - recursion vs. iterative > - hash algorithm negotiation and usage >=20 > One possibility is to identify a volunteer for each area, so that the > task is more manageable. If there are major philosophical differences, > we should probably discuss those first, however. >=20 > Henning >=20 > _______________________________________________ -- Dipl.-Inform. Ingmar Baumgart Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 08 03:25:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2hl-00037K-Ak; Thu, 08 Nov 2007 03:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2hj-00037E-OM for p2psip@ietf.org; Thu, 08 Nov 2007 03:25:35 -0500 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq2he-00052i-RB for p2psip@ietf.org; Thu, 08 Nov 2007 03:25:35 -0500 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 09:25:28 +0100 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 09:25:28 +0100 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 09:25:26 +0100 Message-ID: <4732C82E.70603@telecomitalia.it> Date: Thu, 08 Nov 2007 09:26:22 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] Proposal for progress on protocols References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <4731ED7B.2070901@sip-communicator.org> <24CCCC428EFEA2469BF046DB3C7A8D223AE249@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE249@namail5.corp.adobe.com> X-OriginalArrivalTime: 08 Nov 2007 08:25:26.0907 (UTC) FILETIME=[EA6704B0:01C821E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0276343176==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0276343176== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070403010206010604080601" This is a cryptographically signed message in MIME format. --------------ms070403010206010604080601 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Henry Sinnreich wrote: >> - DHT upgrades > > Please help me understand why infrequent software upgrades have to be > part of the p2p overlay functions or its services, such as SIP. > > Or maybe we are talking of different things? I guess Emil is referring to DHT migration as described in section 2.6 of ASP draft, not exactly to software upgrades. The issue was raised by Jonathan during the ad-hoc meeting in Chicago and, AFAIR, it was quite agreed that it is something which should be considered from the very beginning. The main point was that, since overlays are supposed to last for long periods, they may require upgrades and migrations which are unlikely to happen if a common mechanism was not agreed in advance. -- Ciao, Enrico --------------ms070403010206010604080601 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcxMTA4MDgyNjIyWjAjBgkqhkiG9w0BCQQxFgQUm1ZwNFxa voTYzuZeKfkwkxzpBKgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAGoLKRa7MXbTccY8PI5YO3K0HUVJtyuFumHypbraY+BJkT1JgvXJYJEu 6jVfNYfv0Gs/xsAizyaIpsk/ZKlnStEwJNUV3+Hwn00ciAc37exviOKghfs3B81NUWo0tpP0 ep50m5bYAixzBovCR1SbFcHhU4Otp6Yxg7A3Mv3cVSws9peaANzQ3senqcTjiK2g2dRLnYN6 lQY6iU7rr8vKREu4yq4vBF4IZYQadq6HF0V0afH5zgMDC4dHn1RYcuAE8Ektc2/yVILEJGyz LSxoog/aJ5qZBXOkrPwRFdNUO3IpaB0O0qkzMRHIVg9vCvZZJCy6sXKg+Qljkm3+toEjL4IA AAAAAAA= --------------ms070403010206010604080601-- --===============0276343176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0276343176==-- From p2psip-bounces@ietf.org Thu Nov 08 04:26:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3ez-0005jV-Ei; Thu, 08 Nov 2007 04:26:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3ey-0005if-Hg for p2psip@ietf.org; Thu, 08 Nov 2007 04:26:48 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iq3ex-0007ed-Si for p2psip@ietf.org; Thu, 08 Nov 2007 04:26:48 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA89Q6Nl010104; Thu, 8 Nov 2007 11:26:33 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 11:26:32 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 11:26:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Proposal for progress on protocols Date: Thu, 8 Nov 2007 11:28:48 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> In-Reply-To: <4731ED7B.2070901@sip-communicator.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Proposal for progress on protocols Thread-Index: AcghXst/jtmJX1c/RBS/pOGKWkHYGgAiLgAQ References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <4731ED7B.2070901@sip-communicator.org> From: To: , X-OriginalArrivalTime: 08 Nov 2007 09:26:32.0154 (UTC) FILETIME=[730F53A0:01C821E9] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, I agree with Henning's proposal. There is another issue: support for clients.=20 I can to volunteer for "mobility" or "support for clients". =20 Marcin=20 >-----Original Message----- >From: ext Emil Ivov [mailto:emcho@sip-communicator.org]=20 >Sent: 07 November, 2007 18:53 >To: P2PSIP Mailing List >Subject: Re: [P2PSIP] Proposal for progress on protocols > >Henning, all, > >I think this is definitely the way to go and both Enrico and I=20 >(as authors of one of the proposals) would be happy to=20 >contribute on any of the points in your list. We also thought=20 >that there are two other issues that would probably require=20 >some consideration: > >- DHT upgrades - as far as I can see, it is currently most=20 >covered by ASP, but the general opinion in Chicago seemed to=20 >be that this is indeed an important issue that would have to=20 >be addressed by the peer protocol. > >- Mobility - taking mobility into account would probably=20 >influence some of the design choices (underlying protocol,=20 >session flexibility, etc..) so it might be worth to try and=20 >see to what extent would the existing proposals fit mobile nodes. > >One last thing. We should probably try and start having some=20 >of these discussions before the meeting or, even better, to=20 >find some way to foster offline work on each topic, since they=20 >are likely to require more than the time we'll have there. I=20 >guess that Philip's presentation in Chicago was made with the=20 >same intentions, but it was pretty clear that the time we had=20 >was insufficient for any meaningful discussions. > >Cheers >Emil > >Henning Schulzrinne wrote: >> I'd like to propose a mechanism to make progress on converging on a=20 >> protocol. My high-level impression is that most of the=20 >proposals, with=20 >> the exception of the HIP-based ones, are philosophically not=20 >that far=20 >> removed, and the differences are more at the mechanical=20 >level. One way=20 >> to make progress would be to identify some of the major pieces, and=20 >> then, in Vancouver, systematically go through them. An initial list,=20 >> definitely incomplete, includes >>=20 >> - packet format >> - NAT traversal for p2p messages (not media or SIP signaling) >> - channel security for p2p messages >> - recursion vs. iterative >> - hash algorithm negotiation and usage >>=20 >> One possibility is to identify a volunteer for each area, so=20 >that the=20 >> task is more manageable. If there are major philosophical=20 >differences,=20 >> we should probably discuss those first, however. >>=20 >> Henning >>=20 >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >>=20 > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 08 12:39:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBLW-0003gU-N4; Thu, 08 Nov 2007 12:39:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBLU-0003Xq-GW for p2psip@ietf.org; Thu, 08 Nov 2007 12:39:12 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqBLS-0005A1-0m for p2psip@ietf.org; Thu, 08 Nov 2007 12:39:12 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JR7005X27P9HC@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 08 Nov 2007 09:39:09 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JR700HJT7P8ZX@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 08 Nov 2007 09:39:09 -0800 (PST) Date: Thu, 08 Nov 2007 11:38:08 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Proposal for progress on protocols To: P2PSIP Mailing List Message-id: <086801c8222e$2063cab0$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <"24CCCC428EFEA2469BF 046DB3C7A8D223AE235"@namail5.corp.adobe.com> <048b01c8214c$265cdbb0$6501a8c0@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE242@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Backing up from Ted's reasonable points about Henry's reasonable high-level concerns ... IPR discussions are going to be challenging enough (with or without Brian's draft, which doesn't change patent law) that as one of the volunteers, I would prefer to do the analysis, let people look at the analysis and pick a preferred direction, and then consider IPR concerns for that preferred direction. If the preferred direction for one of these decision points is encumbered, we can figure out what to do then. Spending time trying to understand what the IPR considerations for ideas that the working group will reject because of technical considerations doesn't sound like fun to me. One minor point that Henry may be assuming - are all the people who have submitted proposals current on their IPR disclosures? I've seen delays of months in other groups between draft submission and IPR disclosure submission - we really need to know as much as we can know when we DO consider IPR concerns. Thanks, Spencer >>For all the existing proposals, please consider also the I-D by Brian >>Carpenter "Considering availability of free software when evaluating >>Draft Standards" >>ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-carpenter-ipr-pa >>tent-frswds-01.txt >> >> A specification from which at least two independent and >>interoperable >> implementations from different code bases have been developed, _of >> which at least one is preferably available as free software_, and >> for which sufficient successful operational experience has been >> obtained, may be elevated to the "Draft Standard" level. > > Henry, > That draft is an individual submission that's being discussed > in the IPR working group. My current assessment is that there is no > consensus behind Brian's language, with multiple folks preferring the > language by Scott Brim: > >> A specification from which at least two independent and >> interoperable implementations from different code bases have been >> developed, and for which sufficient successful operational >> experience has been obtained, may be elevated to the "Draft >> Standard" level. Issues with general deployability should be >> taken into consideration, including issues of licensing terms >> associated with those implementations. > > The main issue being that what qualifies as "free software" > could turn out to be a rathole of epic proportions. For those interested > in developing a consensus on this please join the IPR list and express > your opinions. > At this juncture, at least, this working group needs to get > out a PS. We have at least six months after that to worry about DS :) . > > regards, > Ted > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 08 22:08:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqKET-0005Bj-Cc; Thu, 08 Nov 2007 22:08:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqKER-0005BR-JF for p2psip@ietf.org; Thu, 08 Nov 2007 22:08:31 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqKEK-0006iz-Di for p2psip@ietf.org; Thu, 08 Nov 2007 22:08:31 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JR700JGEY1SZI@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 09 Nov 2007 11:08:16 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JR700ID9Y1QC3@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 09 Nov 2007 11:08:16 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JR700M01Y1Q2R@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 09 Nov 2007 11:08:14 +0800 (CST) Date: Fri, 09 Nov 2007 11:08:14 +0800 From: Song Yongchao Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D22A6D56A@namail5.corp.adobe.com> To: 'P2PSIP Mailing List' Message-id: <015601c8227d$c4d9bec0$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace9MWHD+vUfDtjbTF+DzT9QkMfRDgEU95vwGD24xOA= X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, dear co-chairs This topic was discussed four months ago, and there was a lot of arguments about it. I think it is a very basic and important concept in P2PSIP, and it should be discussed and achieve a consensus in Vancouver, anyone agree with me? Best Regards! Song Yongchao > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Monday, July 09, 2007 2:07 AM > To: Cullen Jennings; Dean Willis > Cc: P2PSIP Mailing List > Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays > > Cullen Jennings wrote: > > > Consider the other end of the dog, > > namespaces and enrollment servers. > > This is an extremely useful contribution since the critical importance > of the enrollment server cannot be over emphasized. The enrollment > server can also play a role by linking p2p domains from a business > perspective, for example: > > - p2p.com runs a global commercial p2p overlay and has resellers, such > as > > - myisp.com who resells p2p service to > > - ourit.com who enrolls its employees into the ourit.com overlay, and to > > - ourschool.edu for students and alumni of ourschool.edu > > Note there must be a hierarchy of enrollment servers to make this happen > and the hierarchy is controlled by cryptographic means. > > The advantage of creating the enrollment hierarchy include greater reach > for p2p.com and the accompanying better functioning of the partitioned > overlay: The more users, the better it works. > > Contrary to the golden tree of the DNS hierarchy however we would want > many such p2p trees for a healthy competitive market place. (This is no > endorsement in any way for private ENUM, but that's a rat hole to please > avoid here on the list). > > Does it make sense to have a BCP on namespaces and enrollment servers? > Such a BCP could also discuss the use the UUID (RFC 4122) that has been > mentioned in several I-Ds submitted to the P2PSIP WG. > > Henry > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Tuesday, July 03, 2007 12:15 AM > To: Dean Willis > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Concepts issue: Domains and Overlays > > > Short answer: Yes, Dean, I basically like what you are proposing. > > Long answer: > > I got pretty lost on the thread that came out of this but it occurred > to me that looking at this as domains and overlays might be trying to > wag the dog from the wrong end. Consider the other end of the dog, > namespaces and enrollment servers. > > I think we can all agree that if Cullen is known on some overlay as > fluffy@example.org, then we really don't want Dean to also be known > on some other overlay as fluffy@example.org. We need the names to be > useful and refer to a unique human user. So who decided who gets the > name fluffy@example.org, Dean or Cullen? The enrollment server that > is responsible for example.org gets to decide. I think this more or > less means that an enrollment server may be able to have more than > one domain mapped to it but a domain maps to at most one enrollment > server. Now all the peers on the overlay need to be able to have a > common trust root of some form on who the peers believe is allowed to > allocate the names in this particular overlay. Once again, that is > the enrollment server. So an given overlay can only have one logical > enrollment server. (Someone will say there could be multiple trust > roots here but given the peers in the overlay have to know about > *everyone* of the trust roots, I would just argue this had virtually > formed all the trust roots into a single logical enrollment server). > Similarly, if someone is trying to reach fluffy@example.org, unless > fluffy is in all the overlays that the example.org enrollment server > is responsible for, then we need to know which overlay to look in and > it seems the only way to know this is to have at most one overlay for > each domain. So if you follow this somewhat confused logic, I come > out thinking that the easiest solution looks like the following: > > A set of one more domain name (typically one) maps to a exactly one > logical enrollment server. The single logical enrollment server maps > to exactly one overlay. The enrollment server creates unique names > inside the namespace that is delegated to it by the domain names that > map to it. > > So to answer Deans question below - model one works for me. Model two > only works for me if every peer in the overlay knows about the > credentials of every enrollment server for every domain that can > allocate names in the overlay *before* any peer ever enrolls in the > overlay. This seems pretty impractical for anything but a very small > set of enrollment servers. > > Cullen > > > > > > > > On Jun 13, 2007, at 4:00 PM, Dean Willis wrote: > > > > > Someone brought this up on the list, and I wanted to clarify the > > consensus here before nailing it down further in the concepts doc. > > > > We think of usernames as domain-scoped, like "joebob@example.com". > > > > One model of an overlay allows users to enroll names from many > > domains. In this model, there might be only one overlay serving > > every domain in the world, including (for example) "example.com" > > and "example.net". Clearly routing messages within this overlay is > > straightforward, and there's no need to talk to any other overlay. > > > > In another model, each overlay corresponds to one or more but not > > all domains, and we use RFC 3263 procedures to route between > > overlays. So "example.com" might be in one overlay, and > > "example.net" in another. Each overlay can look up the other in DNS > > to find it. > > > > This second model mostly precludes having one domain scattered > > across multiple overlays. > > > > Here's the deal: Assume we have overlays A and B. Alice@example.com > > enrolls with overlay A, and Bob@example.com enrolls with overlay B. > > > > Alice now wants to call Bob. She looks him up in her overlay, and > > he's not there. What to do? She can't just look up example.com in > > DNS, because it has been split across A and B and DNS just doesn't > > work that way. Now, if both A and B registered with some "upstream" > > lookup function (a meta-overlay), then Alice could perhaps look > > there. But this starts to get messy really quickly. > > > > So unless we want to solve the namespace-split-across-overlays > > problem (and that's not easy), we're much better off at this time > > having a model where each domain can be mapped onto only one > > overlay at a time. > > > > Y'all ok with that? > > > > -- > > Dean > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 08 22:23:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqKSp-00045y-R8; Thu, 08 Nov 2007 22:23:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqKSo-00043f-AJ for p2psip@ietf.org; Thu, 08 Nov 2007 22:23:22 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqKSl-00072o-Bm for p2psip@ietf.org; Thu, 08 Nov 2007 22:23:22 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JR700H52YQL6Y@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 09 Nov 2007 11:23:09 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JR700503YQLHN@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 09 Nov 2007 11:23:09 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JR700EW0YQK01@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 09 Nov 2007 11:23:09 +0800 (CST) Date: Fri, 09 Nov 2007 11:23:08 +0800 From: Song Yongchao Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays In-reply-to: <015601c8227d$c4d9bec0$3e05a40a@china.huawei.com> To: 'Song Yongchao' , 'P2PSIP Mailing List' Message-id: <016001c8227f$d9b9c2c0$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Ace9MWHD+vUfDtjbTF+DzT9QkMfRDgEU95vwGD24xOAAAMVrcA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org And here is section 6.5 from the [Concepts]. " 6.5. Relationships of Domains to Overlays 1. Can there be names from more than one domain in a single overlay? 2. Can there be names from one domain in more than a single overlay? If so, how do we route Client/Server SIP requests to the right overlay? 3. Can the domain of an AoR be in more than one overlay? 4. Should we have a "default overlay" to search for peers in many domains? " Best Regards! Song Yongchao > -----Original Message----- > From: Song Yongchao [mailto:melodysong@huawei.com] > Sent: Friday, November 09, 2007 11:08 AM > To: 'P2PSIP Mailing List' > Subject: RE: [P2PSIP] Concepts issue: Domains and Overlays > > Hi, dear co-chairs > This topic was discussed four months ago, and there was a lot of arguments > about it. I think it is a very basic and important concept in P2PSIP, and it > should be discussed and achieve a consensus in Vancouver, anyone agree with > me? > > Best Regards! > Song Yongchao _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 09 12:55:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqY4v-0007fB-81; Fri, 09 Nov 2007 12:55:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqY4u-0007ex-2R for p2psip@ietf.org; Fri, 09 Nov 2007 12:55:36 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqY4q-0007gU-B6 for p2psip@ietf.org; Fri, 09 Nov 2007 12:55:36 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IqY4i-0008PP-NX for ; Fri, 09 Nov 2007 18:55:31 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps for id 1IqY4h-0007a2-EL; Fri, 09 Nov 2007 18:55:24 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps for id 1IqY4h-0004CA-5y; Fri, 09 Nov 2007 18:55:23 +0100 Received: from [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4] (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id A5BC62FC00C for ; Fri, 9 Nov 2007 18:55:22 +0100 (CET) Message-ID: <47349F0A.5090201@tm.uka.de> Date: Fri, 09 Nov 2007 18:55:22 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: p2psip@ietf.org X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear working group, I've submitted a draft for a Peer-to-Peer Name Service (P2PNS) which can be used to resolve AoRs to Contact URIs without using DNS. The main contribution is on two aspects: One is reusability of the name service for things like distributed DNS or HIP. The other is security in a completely decentralized environment (without login severs). Until it is on the official servers, you can get it from here: http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.txt http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.html Some additional information about the implementation can be found in this P2P2007 demo abstract: http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 09 13:25:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqYY0-0004oJ-3r; Fri, 09 Nov 2007 13:25:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqYXz-0004oE-1d for p2psip@ietf.org; Fri, 09 Nov 2007 13:25:39 -0500 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IqYXy-00061c-G3 for p2psip@ietf.org; Fri, 09 Nov 2007 13:25:38 -0500 Received: from lappy ([70.6.147.196]) by quinthar.com for ; Fri, 9 Nov 2007 10:25:36 -0800 From: "David Barrett" To: "'Ingmar Baumgart'" , Subject: RE: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) Date: Fri, 9 Nov 2007 13:25:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgi+cLFIIuVjdLiSeGGeqKMhUvkSAAA5I4g In-Reply-To: <47349F0A.5090201@tm.uka.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: This is pretty cool! One question: Though I only read it quick, I didn't see any mention of how it = arbitrates between humans competing for the same name. I understand that each node securely generates a unique GUID, but that's not human-readable. If you = and I both want to be baumgart@p2psip.org -- meaning, we each want to = associate our data with that name -- how does it determine who "wins"? -david > -----Original Message----- > From: Ingmar Baumgart [mailto:baumgart@tm.uka.de] > Sent: Friday, November 09, 2007 12:55 PM > To: p2psip@ietf.org > Subject: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) >=20 > Dear working group, >=20 > I've submitted a draft for a Peer-to-Peer Name Service (P2PNS) which = can > be used to resolve AoRs to Contact URIs without using DNS. >=20 > The main contribution is on two aspects: One is reusability of the = name > service for things like distributed DNS or HIP. The other is security = in > a completely decentralized environment (without login severs). >=20 > Until it is on the official servers, you can get it from here: >=20 > http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.txt > http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.html >=20 > Some additional information about the implementation can be found in > this P2P2007 demo abstract: >=20 > http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf >=20 > Regards, > Ingmar >=20 > -- > Dipl.-Inform. Ingmar Baumgart > Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) > Zirkel 2, 76128 Karlsruhe, Germany > Phone: +49 721 608 8281, Fax: +49 721 608 6789 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 09 13:49:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqYvM-0007pA-Jx; Fri, 09 Nov 2007 13:49:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqYvK-0007oa-Rk for p2psip@ietf.org; Fri, 09 Nov 2007 13:49:47 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqYvK-0006uZ-7E for p2psip@ietf.org; Fri, 09 Nov 2007 13:49:46 -0500 Received: from [192.168.2.1] (HSI-KBW-091-089-004-031.hsi2.kabelbw.de [91.89.4.31]) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis) id 0ML21M-1IqYvI2xkT-0002Fn; Fri, 09 Nov 2007 19:49:45 +0100 Message-ID: <4734AC01.4030602@tm.uka.de> Date: Fri, 09 Nov 2007 19:50:41 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: David Barrett Subject: Re: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) References: <20071109183424.B53F82FC00C@smtp.ipv6.tm.uni-karlsruhe.de> In-Reply-To: <20071109183424.B53F82FC00C@smtp.ipv6.tm.uni-karlsruhe.de> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V01U2FsdGVkX1/2SviSPoMOKbEb20CBjFxp4IXY5YljDzZ5mGF U9IaI7RSgdoBAT8G9se3yKEDFbWmoFfHMnMGtHKBX69Gb5l9tN Bkh3CL0STYCr2eMWlSOqA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The user who tries to registers the name first wins. If the name is not already registered by another user, the name gets stored in the DHT together with the nodeID of the owner. If a name is already stored in the DHT, only the owner is allowed to modify the mapping. Regards, Ingmar David Barrett wrote: > This is pretty cool! One question: > > Though I only read it quick, I didn't see any mention of how it arbitrates > between humans competing for the same name. I understand that each node > securely generates a unique GUID, but that's not human-readable. If you and > I both want to be baumgart@p2psip.org -- meaning, we each want to associate > our data with that name -- how does it determine who "wins"? > > -david > >> -----Original Message----- >> From: Ingmar Baumgart [mailto:baumgart@tm.uka.de] >> Sent: Friday, November 09, 2007 12:55 PM >> To: p2psip@ietf.org >> Subject: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) >> >> Dear working group, >> >> I've submitted a draft for a Peer-to-Peer Name Service (P2PNS) which can >> be used to resolve AoRs to Contact URIs without using DNS. >> >> The main contribution is on two aspects: One is reusability of the name >> service for things like distributed DNS or HIP. The other is security in >> a completely decentralized environment (without login severs). >> >> Until it is on the official servers, you can get it from here: >> >> http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.txt >> http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.html >> >> Some additional information about the implementation can be found in >> this P2P2007 demo abstract: >> >> http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf >> >> Regards, >> Ingmar >> >> -- >> Dipl.-Inform. Ingmar Baumgart >> Institut für Telematik, Universität Karlsruhe (TH) >> Zirkel 2, 76128 Karlsruhe, Germany >> Phone: +49 721 608 8281, Fax: +49 721 608 6789 >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Nov 10 10:53:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqseM-0005pR-L9; Sat, 10 Nov 2007 10:53:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqseL-0005pG-UK for p2psip@ietf.org; Sat, 10 Nov 2007 10:53:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqseH-000420-7r for p2psip@ietf.org; Sat, 10 Nov 2007 10:53:33 -0500 X-IronPort-AV: E=Sophos;i="4.21,399,1188802800"; d="scan'208";a="249577910" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2007 07:53:28 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAAFrSeO023049; Sat, 10 Nov 2007 07:53:28 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAAFrSQ6025287; Sat, 10 Nov 2007 15:53:28 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Nov 2007 07:53:28 -0800 Received: from [10.32.241.148] ([10.32.241.148]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Nov 2007 07:53:28 -0800 Message-ID: <4735D416.6050400@cisco.com> Date: Sat, 10 Nov 2007 10:53:58 -0500 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [P2PSIP] Proposal for progress on protocols References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> In-Reply-To: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2007 15:53:28.0100 (UTC) FILETIME=[D5AB0E40:01C823B1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2429; t=1194710008; x=1195574008; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[P2PSIP]=20Proposal=20for=20progress=20on=20protocols |Sender:=20; bh=w4sL5Uljbv+inXPJq2o/y/uz4rCd3EV+kXbVdHNTjZ0=; b=Au5RKJX/Qe/XHurC8TuOnfVE4BeyDvA3O8djj+vOV8304l+YexBw29lH9iLGgJd18oObeZZE COwIfNuvbL2BMJzqya3Jh8L7ncM3X3oF8bdbN4202qeqQCWFNunXJ3y3; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think Philips presentation and the slides he put together last time were meant to do exactly this kind of thing - to show in what ways various proposals were the same, and where they were different. That said, what I do NOT want to do, is to try and work through each and every issue for a p2p protocol through a group consensus process, and then assemble the results into a built-from-ground-up working group document. I've seen that process tried before in other groups (midcom, the impp protocols), and in each case it has been a dismal failure, taking a long time and producing results no one liked. I'd prefer to do what we normally do - adopt one of the drafts as a working group item and make changes from there based on discussions. Note that, just because a document is adopted as a working group item doesn't mean it can't be changed. But it does mean that the document is believed to be on the right track and a "good starting point" for producing the final deliverable. -Jonathan R. Henning Schulzrinne wrote: > I'd like to propose a mechanism to make progress on converging on a > protocol. My high-level impression is that most of the proposals, with > the exception of the HIP-based ones, are philosophically not that far > removed, and the differences are more at the mechanical level. One way > to make progress would be to identify some of the major pieces, and > then, in Vancouver, systematically go through them. An initial list, > definitely incomplete, includes > > - packet format > - NAT traversal for p2p messages (not media or SIP signaling) > - channel security for p2p messages > - recursion vs. iterative > - hash algorithm negotiation and usage > > One possibility is to identify a volunteer for each area, so that the > task is more manageable. If there are major philosophical differences, > we should probably discuss those first, however. > > Henning > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 11 18:35:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrMLA-000163-0P; Sun, 11 Nov 2007 18:35:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrML8-00010j-16 for p2psip@ietf.org; Sun, 11 Nov 2007 18:35:42 -0500 Received: from chip2og55.obsmtp.com ([64.18.13.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrML6-0006O0-Cv for p2psip@ietf.org; Sun, 11 Nov 2007 18:35:42 -0500 Received: from source ([192.150.11.134]) by chip2ob55.postini.com ([64.18.5.12]) with SMTP; Sun, 11 Nov 2007 15:35:33 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lABNXSOP021648; Sun, 11 Nov 2007 15:33:28 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lABNZUFV025860; Sun, 11 Nov 2007 15:35:31 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 15:35:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Proposal for progress on protocols Date: Sun, 11 Nov 2007 15:35:09 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE280@namail5.corp.adobe.com> In-Reply-To: <4735D416.6050400@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Proposal for progress on protocols Thread-Index: AcgjseRBIiEN7h8XQrK+rGpWhOyXhgBCRrXg References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <4735D416.6050400@cisco.com> From: "Henry Sinnreich" To: "Jonathan Rosenberg" , "Henning Schulzrinne" X-OriginalArrivalTime: 11 Nov 2007 23:35:30.0932 (UTC) FILETIME=[8C2D4340:01C824BB] X-Spam-Score: -4.0 (----) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Would a limited generic/broad set of requirements be a good start? Something quite general, such as - Must work on the Internet 'as is' today - Most peers are presumed to be behind NAT - etc. No routing or protocol specifics of any kind at this point in time. What do you all think about starting with a requirements document? Thanks, Henry -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Saturday, November 10, 2007 9:54 AM To: Henning Schulzrinne Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols I think Philips presentation and the slides he put together last time=20 were meant to do exactly this kind of thing - to show in what ways=20 various proposals were the same, and where they were different. That said, what I do NOT want to do, is to try and work through each and every issue for a p2p protocol through a group consensus process, and=20 then assemble the results into a built-from-ground-up working group=20 document. I've seen that process tried before in other groups (midcom,=20 the impp protocols), and in each case it has been a dismal failure,=20 taking a long time and producing results no one liked. I'd prefer to do what we normally do - adopt one of the drafts as a=20 working group item and make changes from there based on discussions.=20 Note that, just because a document is adopted as a working group item=20 doesn't mean it can't be changed. But it does mean that the document is=20 believed to be on the right track and a "good starting point" for=20 producing the final deliverable. -Jonathan R. Henning Schulzrinne wrote: > I'd like to propose a mechanism to make progress on converging on a=20 > protocol. My high-level impression is that most of the proposals, with > the exception of the HIP-based ones, are philosophically not that far=20 > removed, and the differences are more at the mechanical level. One way > to make progress would be to identify some of the major pieces, and=20 > then, in Vancouver, systematically go through them. An initial list,=20 > definitely incomplete, includes >=20 > - packet format > - NAT traversal for p2p messages (not media or SIP signaling) > - channel security for p2p messages > - recursion vs. iterative > - hash algorithm negotiation and usage >=20 > One possibility is to identify a volunteer for each area, so that the=20 > task is more manageable. If there are major philosophical differences, > we should probably discuss those first, however. >=20 > Henning >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 11 20:37:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrOEW-0004ZE-Fo; Sun, 11 Nov 2007 20:37:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrOEV-0004Z4-MD for p2psip@ietf.org; Sun, 11 Nov 2007 20:36:59 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrOES-0001cl-AX for p2psip@ietf.org; Sun, 11 Nov 2007 20:36:59 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRD00G0VDTB2R@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 09:36:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRD00JY4DTAT2@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 09:36:47 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRD007ZMDTARI@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 09:36:46 +0800 (CST) Date: Mon, 12 Nov 2007 09:36:46 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Proposal for progress on protocols In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D223AE280@namail5.corp.adobe.com> To: 'Henry Sinnreich' , 'Jonathan Rosenberg' , 'Henning Schulzrinne' Message-id: <003a01c824cc$7cba94b0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcgjseRBIiEN7h8XQrK+rGpWhOyXhgBCRrXgAAQV0fA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I prefer a requirement draft first. We should ensure that the issues address in the coming peer protocol should meet the requirements based on our rough consensus. Without a requirement document, we have no a formal place to track what have been done in existing proposals and what will be address in the future. Regards! -- Jiang XingFeng > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Monday, November 12, 2007 7:35 AM > To: Jonathan Rosenberg; Henning Schulzrinne > Cc: P2PSIP Mailing List > Subject: RE: [P2PSIP] Proposal for progress on protocols > > Would a limited generic/broad set of requirements be a good start? > > Something quite general, such as > > - Must work on the Internet 'as is' today > - Most peers are presumed to be behind NAT > - etc. > > No routing or protocol specifics of any kind at this point in time. > > What do you all think about starting with a requirements document? > > Thanks, Henry > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: Saturday, November 10, 2007 9:54 AM > To: Henning Schulzrinne > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Proposal for progress on protocols > > I think Philips presentation and the slides he put together last time > were meant to do exactly this kind of thing - to show in what ways > various proposals were the same, and where they were different. > > That said, what I do NOT want to do, is to try and work through each and > > every issue for a p2p protocol through a group consensus process, and > then assemble the results into a built-from-ground-up working group > document. I've seen that process tried before in other groups (midcom, > the impp protocols), and in each case it has been a dismal failure, > taking a long time and producing results no one liked. > > I'd prefer to do what we normally do - adopt one of the drafts as a > working group item and make changes from there based on discussions. > Note that, just because a document is adopted as a working group item > doesn't mean it can't be changed. But it does mean that the document is > believed to be on the right track and a "good starting point" for > producing the final deliverable. > > -Jonathan R. > > Henning Schulzrinne wrote: > > I'd like to propose a mechanism to make progress on converging on a > > protocol. My high-level impression is that most of the proposals, with > > > the exception of the HIP-based ones, are philosophically not that far > > removed, and the differences are more at the mechanical level. One way > > > to make progress would be to identify some of the major pieces, and > > then, in Vancouver, systematically go through them. An initial list, > > definitely incomplete, includes > > > > - packet format > > - NAT traversal for p2p messages (not media or SIP signaling) > > - channel security for p2p messages > > - recursion vs. iterative > > - hash algorithm negotiation and usage > > > > One possibility is to identify a volunteer for each area, so that the > > task is more manageable. If there are major philosophical differences, > > > we should probably discuss those first, however. > > > > Henning > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Cisco Fellow Parsippany, NJ 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 11 22:32:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrQ2O-00070A-Br; Sun, 11 Nov 2007 22:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrQ2N-000700-5y for p2psip@ietf.org; Sun, 11 Nov 2007 22:32:35 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrQ2K-0005J4-O8 for p2psip@ietf.org; Sun, 11 Nov 2007 22:32:35 -0500 Received: by rv-out-0910.google.com with SMTP id l15so978322rvb for ; Sun, 11 Nov 2007 19:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Sg42CMem0XauNobaIR5hj6TQ2s1vqmq5HW7+qgzbhKU=; b=Xxodz1y2zIXTd95w2xI5DgWZwQL3OXxN8jwz+tB0RNIbjmnnQekxTwyHDtawBrdSuTiHeKNiOjavbKDLAKjEt74pye5fwZfk+UmXbKmp073/qZLKVtH+TlhAUweoKv3KOeu6gijvQ639gudZEyJZyjLOkdsydlQyzx9Bmn7KKhs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Unsx2IM8JlvK0U4R9GnKnIroPerpfWKWKYmeOBWGUZHe2fVfZdAnZ+QcZj/F9YLHynhI3E0lJHbkSyXmvv4N2nnnIZPxOjYBMey23HDA4dzHlpgVbBPZNhujlDq+T5f8oPSyqKt2ANg8tU79MYRYOk52AmWJQSptYt2P6CnR1kI= Received: by 10.140.141.15 with SMTP id o15mr2175859rvd.1194838352202; Sun, 11 Nov 2007 19:32:32 -0800 (PST) Received: by 10.140.133.18 with HTTP; Sun, 11 Nov 2007 19:32:32 -0800 (PST) Message-ID: <77443c4c0711111932u6ef0d82ance05901130c7668a@mail.gmail.com> Date: Mon, 12 Nov 2007 11:32:32 +0800 From: "Yao Wang" To: "marcin.matuszewski@nokia.com" Subject: Re: [P2PSIP] Proposal for progress on protocols In-Reply-To: <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> MIME-Version: 1.0 References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <4731ED7B.2070901@sip-communicator.org> <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0247987332==" Errors-To: p2psip-bounces@ietf.org --===============0247987332== Content-Type: multipart/alternative; boundary="----=_Part_2393_1916562.1194838352210" ------=_Part_2393_1916562.1194838352210 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I agree Marcin's point that the support for client should be considered at current stage. In my memory, the concept of P2PSIP Client and its role have been a controversial source in the discussion of this maillist. Many people think Client is not part of P2PSIP system, thus there is no need to define the concept of P2PSIP Client or a separate protocol called P2PSIP Client protocol. However, in my and my colleagues' opinions, we argue that P2PSIP Client is indispensable. Generally speaking, the necessity of P2PSIP Client comes from the heterogeneity among all the nodes which want or need to use P2PSIP services. Some nodes are unable or unsuitable to join the P2PSIP Overlay as peers due to the heterogeneity of DHT algorithms, heterogeneity among P2PSIP nodes and other heterogeneity. Currently, we are working on a draft which is dedicated to discuss the necessity of P2PSIP Client and present a high-level description of our proposed P2PSIP Client Protocol. This draft will be finished and submitted soon. Before the submission of this draft, we'd like more discussions of this topic in the maillist. Comments are always welcomed. On 11/8/07, marcin.matuszewski@nokia.com wrote: > > Hi all, > > I agree with Henning's proposal. There is another issue: support for > clients. > > I can to volunteer for "mobility" or "support for clients". > > Marcin > > >-----Original Message----- > >From: ext Emil Ivov [mailto: emcho@sip-communicator.org ] > >Sent: 07 November, 2007 18:53 > >To: P2PSIP Mailing List > >Subject: Re: [P2PSIP] Proposal for progress on protocols > > > >Henning, all, > > > >I think this is definitely the way to go and both Enrico and I > >(as authors of one of the proposals) would be happy to > >contribute on any of the points in your list. We also thought > >that there are two other issues that would probably require > >some consideration: > > > >- DHT upgrades - as far as I can see, it is currently most > >covered by ASP, but the general opinion in Chicago seemed to > >be that this is indeed an important issue that would have to > >be addressed by the peer protocol. > > > >- Mobility - taking mobility into account would probably > >influence some of the design choices (underlying protocol, > >session flexibility, etc..) so it might be worth to try and > >see to what extent would the existing proposals fit mobile nodes. > > > >One last thing. We should probably try and start having some > >of these discussions before the meeting or, even better, to > >find some way to foster offline work on each topic, since they > >are likely to require more than the time we'll have there. I > >guess that Philip's presentation in Chicago was made with the > >same intentions, but it was pretty clear that the time we had > >was insufficient for any meaningful discussions. > > > >Cheers > >Emil > > > >Henning Schulzrinne wrote: > >> I'd like to propose a mechanism to make progress on converging on a > >> protocol. My high-level impression is that most of the > >proposals, with > >> the exception of the HIP-based ones, are philosophically not > >that far > >> removed, and the differences are more at the mechanical > >level. One way > >> to make progress would be to identify some of the major pieces, and > >> then, in Vancouver, systematically go through them. An initial list, > >> definitely incomplete, includes > >> > >> - packet format > >> - NAT traversal for p2p messages (not media or SIP signaling) > >> - channel security for p2p messages > >> - recursion vs. iterative > >> - hash algorithm negotiation and usage > >> > >> One possibility is to identify a volunteer for each area, so > >that the > >> task is more manageable. If there are major philosophical > >differences, > >> we should probably discuss those first, however. > >> > >> Henning > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > >_______________________________________________ > >P2PSIP mailing list > > P2PSIP@ietf.org > >https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Sincerely yours, Yao Wang Mobile Life Lab Beijing University of Posts & Telecommunications ------=_Part_2393_1916562.1194838352210 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi, 
    I agree Marcin's point that the support for client should be considered at current stage.
    In my memory, the concept of P2PSIP Client and its role have been a controversial source in the discussion of this maillist. Many people think Client is not part of P2PSIP system, thus there is no need to define the concept of P2PSIP Client or a separate protocol called P2PSIP Client protocol.
   However, in my and my colleagues' opinions, we argue that P2PSIP Client is indispensable. Generally speaking, the necessity of P2PSIP Client comes from the heterogeneity among all the nodes which want or need to use P2PSIP services. Some nodes are unable or unsuitable to join the P2PSIP Overlay as peers due to the heterogeneity of DHT algorithms, heterogeneity among P2PSIP nodes and other heterogeneity.
   Currently, we are working on a draft which is dedicated to discuss the necessity of P2PSIP Client and present a high-level description of our proposed P2PSIP Client Protocol. This draft will be finished and submitted soon. Before the submission of this draft, we'd like more discussions of this topic in the maillist.
 
   Comments are always welcomed.  

 
On 11/8/07, marcin.matuszewski@nokia.com <marcin.matuszewski@nokia.com > wrote:
Hi all,

I agree with Henning's proposal. There is another issue: support for
clients.

I can to volunteer for "mobility" or "support for clients".

Marcin

>-----Original Message-----
>From: ext Emil Ivov [mailto: emcho@sip-communicator.org ]
>Sent: 07 November, 2007 18:53
>To: P2PSIP Mailing List
>Subject: Re: [P2PSIP] Proposal for progress on protocols
>
>Henning, all,
>
>I think this is definitely the way to go and both Enrico and I
>(as authors of one of the proposals) would be happy to
>contribute on any of the points in your list. We also thought
>that there are two other issues that would probably require
>some consideration:
>
>- DHT upgrades - as far as I can see, it is currently most
>covered by ASP, but the general opinion in Chicago seemed to
>be that this is indeed an important issue that would have to
>be addressed by the peer protocol.
>
>- Mobility - taking mobility into account would probably
>influence some of the design choices (underlying protocol,
>session flexibility, etc..) so it might be worth to try and
>see to what extent would the existing proposals fit mobile nodes.
>
>One last thing. We should probably try and start having some
>of these discussions before the meeting or, even better, to
>find some way to foster offline work on each topic, since they
>are likely to require more than the time we'll have there. I
>guess that Philip's presentation in Chicago was made with the
>same intentions, but it was pretty clear that the time we had
>was insufficient for any meaningful discussions.
>
>Cheers
>Emil
>
>Henning Schulzrinne wrote:
>> I'd like to propose a mechanism to make progress on converging on a
>> protocol. My high-level impression is that most of the
>proposals, with
>> the exception of the HIP-based ones, are philosophically not
>that far
>> removed, and the differences are more at the mechanical
>level. One way
>> to make progress would be to identify some of the major pieces, and
>> then, in Vancouver, systematically go through them. An initial list,
>> definitely incomplete, includes
>>
>> - packet format
>> - NAT traversal for p2p messages (not media or SIP signaling)
>> - channel security for p2p messages
>> - recursion vs. iterative
>> - hash algorithm negotiation and usage
>>
>> One possibility is to identify a volunteer for each area, so
>that the
>> task is more manageable. If there are major philosophical
>differences,
>> we should probably discuss those first, however.
>>
>> Henning
>>
>> _______________________________________________
>> P2PSIP mailing list
>> P2PSIP@ietf.org
>> https://www1.ietf.org/mailman/listinfo/p2psip
>>
>
>_______________________________________________
>P2PSIP mailing list
> P2PSIP@ietf.org
>https://www1.ietf.org/mailman/listinfo/p2psip
>

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



--
          Sincerely yours,

Yao Wang

Mobile Life Lab

Beijing University of Posts & Telecommunications ------=_Part_2393_1916562.1194838352210-- --===============0247987332== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0247987332==-- From p2psip-bounces@ietf.org Sun Nov 11 23:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrQWR-0007HM-Nc; Sun, 11 Nov 2007 23:03:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrQWP-0007H4-Sa for p2psip@ietf.org; Sun, 11 Nov 2007 23:03:38 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrQWO-0007aB-7K for p2psip@ietf.org; Sun, 11 Nov 2007 23:03:37 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRD00DCOKLXW0@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 12:03:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRD00685KLUD9@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 12:03:33 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRD000WKKLQWQ@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 12:03:30 +0800 (CST) Date: Mon, 12 Nov 2007 12:03:26 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Proposal for progress on protocols In-reply-to: <77443c4c0711111932u6ef0d82ance05901130c7668a@mail.gmail.com> To: 'Yao Wang' , marcin.matuszewski@nokia.com Message-id: <002a01c824e0$fa100fd0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acgk3LUc71uGa8IWRvOrgnoWvzZwsQAA0GGg X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0058021165==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0058021165== Content-type: multipart/alternative; boundary="Boundary_(ID_eJpbrzmPeDV4q5/EaduPiw)" This is a multi-part message in MIME format. --Boundary_(ID_eJpbrzmPeDV4q5/EaduPiw) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Hi, =20 Agree with your viewpoint about P2PSIP client. We submitted a draft named with "P2PSIP client protocol" in 10th = November 2007, it should be available soon in = http://tools.ietf.org/wg/p2psip/. It mainly describes the basic functions of P2PSIP client protocol in = accordance with P2PSIP WG charter = (http://www.ietf.org/html.charters/p2psip-charter.html). It reuses the = P2PSIP peer protocol = (http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt) to = implement those functions. Any comment is appreciated. =20 Best regards, Hewen =20 _____ =20 From: Yao Wang [mailto:yaowang.bupt@gmail.com]=20 Sent: 2007=E5=B9=B411=E6=9C=8812=E6=97=A5 11:33 To: marcin.matuszewski@nokia.com Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Proposal for progress on protocols Hi,=20 I agree Marcin's point that the support for client should be = considered at current stage. In my memory, the concept of P2PSIP Client and its role have been a = controversial source in the discussion of this maillist. Many people = think Client is not part of P2PSIP system, thus there is no need to = define the concept of P2PSIP Client or a separate protocol called P2PSIP = Client protocol.=20 However, in my and my colleagues' opinions, we argue that P2PSIP = Client is indispensable. Generally speaking, the necessity of P2PSIP = Client comes from the heterogeneity among all the nodes which want or = need to use P2PSIP services. Some nodes are unable or unsuitable to join = the P2PSIP Overlay as peers due to the heterogeneity of DHT algorithms, = heterogeneity among P2PSIP nodes and other heterogeneity.=20 Currently, we are working on a draft which is dedicated to discuss = the necessity of P2PSIP Client and present a high-level description of = our proposed P2PSIP Client Protocol. This draft will be finished and = submitted soon. Before the submission of this draft, we'd like more = discussions of this topic in the maillist.=20 =20 Comments are always welcomed. =20 =20 On 11/8/07, marcin.matuszewski@nokia.com > wrote:=20 Hi all, I agree with Henning's proposal. There is another issue: support for clients. I can to volunteer for "mobility" or "support for clients". Marcin >-----Original Message----- >From: ext Emil Ivov [mailto: = emcho@sip-communicator.org ] >Sent: 07 November, 2007 18:53 >To: P2PSIP Mailing List >Subject: Re: [P2PSIP] Proposal for progress on protocols > >Henning, all, > >I think this is definitely the way to go and both Enrico and I=20 >(as authors of one of the proposals) would be happy to >contribute on any of the points in your list. We also thought >that there are two other issues that would probably require >some consideration:=20 > >- DHT upgrades - as far as I can see, it is currently most >covered by ASP, but the general opinion in Chicago seemed to >be that this is indeed an important issue that would have to >be addressed by the peer protocol.=20 > >- Mobility - taking mobility into account would probably >influence some of the design choices (underlying protocol, >session flexibility, etc..) so it might be worth to try and >see to what extent would the existing proposals fit mobile nodes.=20 > >One last thing. We should probably try and start having some >of these discussions before the meeting or, even better, to >find some way to foster offline work on each topic, since they >are likely to require more than the time we'll have there. I=20 >guess that Philip's presentation in Chicago was made with the >same intentions, but it was pretty clear that the time we had >was insufficient for any meaningful discussions. > >Cheers >Emil > >Henning Schulzrinne wrote: >> I'd like to propose a mechanism to make progress on converging on a >> protocol. My high-level impression is that most of the >proposals, with=20 >> the exception of the HIP-based ones, are philosophically not >that far >> removed, and the differences are more at the mechanical >level. One way >> to make progress would be to identify some of the major pieces, and=20 >> then, in Vancouver, systematically go through them. An initial list, >> definitely incomplete, includes >> >> - packet format >> - NAT traversal for p2p messages (not media or SIP signaling)=20 >> - channel security for p2p messages >> - recursion vs. iterative >> - hash algorithm negotiation and usage >> >> One possibility is to identify a volunteer for each area, so=20 >that the >> task is more manageable. If there are major philosophical >differences, >> we should probably discuss those first, however. >> >> Henning >> >> _______________________________________________=20 >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >>=20 > >_______________________________________________ >P2PSIP mailing list > P2PSIP@ietf.org =20 >https://www1.ietf.org/mailman/listinfo/p2psip = =20 > _______________________________________________=20 P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip = =20 --=20 Sincerely yours,=20 Yao Wang Mobile Life Lab Beijing University of Posts & Telecommunications=20 --Boundary_(ID_eJpbrzmPeDV4q5/EaduPiw) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
Hi,
 
    Agree = with your=20 viewpoint about P2PSIP client.
    We submitted a = draft named=20 with "P2PSIP client protocol" in 10th November 2007, it should be = available soon=20 in http://tools.ietf.org/wg/p2psip= /.
   =20 It mainly describes the basic functions of P2PSIP client protocol in = accordance=20 with P2PSIP WG charter (http://www= .ietf.org/html.charters/p2psip-charter.html).=20 It reuses the P2PSIP peer protocol (ht= tp://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt)=20 to implement those functions.
    Any comment is=20 appreciated.
 
Best regards,
Hewen
 

From: Yao Wang = [mailto:yaowang.bupt@gmail.com]=20
Sent: 2007=E5=B9=B411=E6=9C=8812=E6=97=A5 11:33
To: = marcin.matuszewski@nokia.com
Cc: = p2psip@ietf.org
Subject:=20 Re: [P2PSIP] Proposal for progress on protocols

Hi, 
    I agree Marcin's point that the support for = client=20 should be considered at current stage.
    In my memory, the concept of P2PSIP Client = and its=20 role have been a controversial source in the discussion of this = maillist.=20 Many people think Client is not part of P2PSIP system, thus there = is no=20 need to define the concept of P2PSIP Client or a separate protocol = called=20 P2PSIP Client protocol.
   However, in my and my colleagues' opinions, we argue = that=20 P2PSIP Client is indispensable. Generally speaking, the necessity of = P2PSIP=20 Client comes from the heterogeneity among all the nodes which want = or need=20 to use P2PSIP services. Some nodes are unable or unsuitable to join the = P2PSIP=20 Overlay as peers due to the heterogeneity of DHT algorithms, = heterogeneity among=20 P2PSIP nodes and other heterogeneity.
   Currently, we are working on a draft which is = dedicated to=20 discuss the necessity of P2PSIP Client and present a high-level = description=20 of our proposed P2PSIP Client Protocol. This draft will be finished and=20 submitted soon. Before the submission of this draft, we'd=20 like more discussions of this topic in the maillist.
 
   Comments are always=20 welcomed.  

 
On 11/8/07, marcin.matuszewski@nokia.com <marcin.matuszewski@nokia.com > wrote:=20
Hi=20 all,

I agree with Henning's proposal. There is another issue: = support=20 for
clients.

I can to volunteer for "mobility" or "support = for=20 clients".

Marcin

>-----Original = Message-----
>From: ext=20 Emil Ivov [mailto:=20 emcho@sip-communicator.org ]
>Sent: 07 November, 2007=20 18:53
>To: P2PSIP Mailing List
>Subject: Re: [P2PSIP] = Proposal for=20 progress on protocols
>
>Henning, all,
>
>I = think this=20 is definitely the way to go and both Enrico and I
>(as authors = of one=20 of the proposals) would be happy to
>contribute on any of the = points in=20 your list. We also thought
>that there are two other issues that = would=20 probably require
>some consideration:
>
>- DHT = upgrades -=20 as far as I can see, it is currently most
>covered by ASP, but = the=20 general opinion in Chicago seemed to
>be that this is indeed an=20 important issue that would have to
>be addressed by the peer = protocol.=20
>
>- Mobility - taking mobility into account would=20 probably
>influence some of the design choices (underlying=20 protocol,
>session flexibility, etc..) so it might be worth to = try=20 and
>see to what extent would the existing proposals fit mobile = nodes.=20
>
>One last thing. We should probably try and start = having=20 some
>of these discussions before the meeting or, even better,=20 to
>find some way to foster offline work on each topic, since=20 they
>are likely to require more than the time we'll have there. = I=20
>guess that Philip's presentation in Chicago was made with=20 the
>same intentions, but it was pretty clear that the time we=20 had
>was insufficient for any meaningful=20 discussions.
>
>Cheers
>Emil
>
>Henning=20 Schulzrinne wrote:
>> I'd like to propose a mechanism to make = progress on converging on a
>> protocol. My high-level = impression is=20 that most of the
>proposals, with
>> the exception of = the=20 HIP-based ones, are philosophically not
>that far
>> = removed,=20 and the differences are more at the mechanical
>level. One=20 way
>> to make progress would be to identify some of the = major=20 pieces, and
>> then, in Vancouver, systematically go through = them.=20 An initial list,
>> definitely incomplete,=20 includes
>>
>> - packet format
>> - NAT = traversal=20 for p2p messages (not media or SIP signaling)
>> - channel = security=20 for p2p messages
>> - recursion vs. iterative
>> - = hash=20 algorithm negotiation and usage
>>
>> One = possibility is to=20 identify a volunteer for each area, so
>that the
>> = task is=20 more manageable. If there are major=20 philosophical
>differences,
>> we should probably = discuss those=20 first, however.
>>
>> = Henning
>>
>>=20 _______________________________________________
>> P2PSIP = mailing=20 list
>> P2PSIP@ietf.org
>> https://www1.ietf.org/mailman/listinfo/p2psip
>= >=20 =
>
>_______________________________________________
>P2= PSIP=20 mailing list
> = P2PSIP@ietf.org
>https://www1.ietf.org/mailman/listinfo/p2psip=20
>

_______________________________________________ =
P2PSIP=20 mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip=20



--=20
          Sincerely= yours,=20

Yao Wang

Mobile Life Lab

Beijing University = of Posts=20 & Telecommunications --Boundary_(ID_eJpbrzmPeDV4q5/EaduPiw)-- --===============0058021165== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0058021165==-- From p2psip-bounces@ietf.org Sun Nov 11 23:31:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrQxS-0002fk-RC; Sun, 11 Nov 2007 23:31:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrQxQ-0002f4-TA for p2psip@ietf.org; Sun, 11 Nov 2007 23:31:32 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrQxQ-0000On-Em for p2psip@ietf.org; Sun, 11 Nov 2007 23:31:32 -0500 Received: from [24.139.16.154] (helo=[10.0.1.3]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrQxO-0000Ca-2Q; Sun, 11 Nov 2007 23:31:30 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Sun, 11 Nov 2007 23:32:35 -0500 To: P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.0.1.3]) [24.139.16.154] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Cooper, Alan Johnston, and I have just submitted a new draft: http://www.ietf.org/internet-drafts/draft-matthews-p2psip-id- loc-00.txt This draft attempts to present what we feel is the most important concept that P2PSIP can take from HIP: the concept of the ID/Locator split. This draft describes the concept and how it can be implemented, and argues why it is so beneficial to P2PSIP. The goal of this draft is to focus discussion around this concept, without getting distracted by the other features that HIP has. We deliberately kept this draft short to make it an easy read (only 14 pages). We are looking forward to the discussion. - Philip Here is the meta-data for the draft (from the secretariat): Filename: draft-matthews-p2psip-id-loc Revision: 00 Title: An ID/Locator Architecture for P2PSIP Creation_date: 2007-11-11 WG ID: Independent Submission Number_of_pages: 14 Abstract: This document describes an architecture where peers in an overlay use special IP addresses to identify other peers. Two of the advantages of this approach are that (a) most existing applications can run in an overlay without needing any changes and (b) peer mobility and NAT traversal are handled in a way that is transparent to most applications.Terminology _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 03:44:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUtj-0007vZ-Bu; Mon, 12 Nov 2007 03:43:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUth-0007vP-Gq for p2psip@ietf.org; Mon, 12 Nov 2007 03:43:57 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrUtd-0000J3-Dx for p2psip@ietf.org; Mon, 12 Nov 2007 03:43:57 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRD00BXSXKYHY@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 16:43:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRD00M8LXKXJ7@szxga03-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 16:43:46 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRD00B3FXKWJY@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 16:43:45 +0800 (CST) Date: Mon, 12 Nov 2007 16:43:44 +0800 From: JiangXingFeng To: 'P2PSIP Mailing List' Message-id: <004c01c82508$22a3b7e0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcglCCJLBm4PENKqRvuets8p1yCNdQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [P2PSIP] New draft: An proposal for P2PSIP Peer protocol, named SEP( Service Extensible Peer Protocol) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, We have just submitted a new draft which you can get at http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt; This draft proposes a new Peer protocol named SEP (Service Extensible Peer Protocol). This protocol has addressed some interesting issues listed as follows: 1. A built-in NAT traversal mechanism used in semi-recursive routing mode. The source peer tries to put into the request some relaying peers which will be delegated to relay the response destined to the source peer and the destination peer could use these relaying peers to relay the response. 2. A general service discovery mechanism which makes full use of other peers' total knowledge of the overlay and ask other peers to collect information about service peers. The discovered information will be returned to the requester for the service discovery in the end. 3. Introduce a simple flow-control mechanism performed between immediate peers because some peers may be overloaded with traffic that is beyond its processing capability. If the upstream peer is aware of the status of its downstream peers, it could do intelligent forwarding decision based on the status. The flow control mechanism could be easily realized by extending KEEPALIVE message or a NOTIFY message. Any comments are appreciated. Regards! -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 04:28:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVap-00077P-UI; Mon, 12 Nov 2007 04:28:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVap-00074F-E7 for p2psip@ietf.org; Mon, 12 Nov 2007 04:28:31 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrVao-0005Gb-6d for p2psip@ietf.org; Mon, 12 Nov 2007 04:28:31 -0500 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 48F7E14DDC4E; Mon, 12 Nov 2007 17:28:27 +0800 (CST) Message-ID: <009b01c8250e$62a305c0$da07740a@DELLWEI> From: "Wei Gengyu" To: References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu><4731ED7B.2070901@sip-communicator.org> <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> Subject: Re: [P2PSIP] Proposal for progress on protocols Date: Mon, 12 Nov 2007 17:28:29 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.8 (++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1590962718==" Errors-To: p2psip-bounces@ietf.org --===============1590962718== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIGFsbA0KDQpJIGhhdmUgYSBxdWVzdGlvbi4NCg0KQSBwZWVyIGluIGEgUDJQU0lQIG92ZXJs YXkgY2FuIGJlIHRoZSBwcm94eSBvZiBhIG1vYmlsZSBjbGllbnQuIA0KQ291bGQgU0lQKHJmYzMy NjEpIGJlIHVzZWQgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgcHJveHkgUGVlciBpbnN0ZWFk IG9mIGRlZmluaW5nIGEgbmV3IHByb3RvY29sPw0KDQpCZXN0IHJlZ2FyZHMsDQoNCkdlbmd5dQ0K DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogPG1hcmNpbi5tYXR1c3pld3Nr aUBub2tpYS5jb20+DQpUbzogPGVtY2hvQHNpcC1jb21tdW5pY2F0b3Iub3JnPjsgPHAycHNpcEBp ZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwOCwgMjAwNyA1OjI4IFBNDQpTdWJq ZWN0OiBSRTogW1AyUFNJUF0gUHJvcG9zYWwgZm9yIHByb2dyZXNzIG9uIHByb3RvY29scw0KDQoN CkhpIGFsbCwNCg0KSSBhZ3JlZSB3aXRoIEhlbm5pbmcncyBwcm9wb3NhbC4gVGhlcmUgaXMgYW5v dGhlciBpc3N1ZTogc3VwcG9ydCBmb3INCmNsaWVudHMuIA0KDQpJIGNhbiB0byB2b2x1bnRlZXIg Zm9yICJtb2JpbGl0eSIgb3IgInN1cHBvcnQgZm9yIGNsaWVudHMiLiAgIA0KDQpNYXJjaW4gDQoN Cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IGV4dCBFbWlsIEl2b3YgW21haWx0 bzplbWNob0BzaXAtY29tbXVuaWNhdG9yLm9yZ10gDQo+U2VudDogMDcgTm92ZW1iZXIsIDIwMDcg MTg6NTMNCj5UbzogUDJQU0lQIE1haWxpbmcgTGlzdA0KPlN1YmplY3Q6IFJlOiBbUDJQU0lQXSBQ cm9wb3NhbCBmb3IgcHJvZ3Jlc3Mgb24gcHJvdG9jb2xzDQo+DQo+SGVubmluZywgYWxsLA0KPg0K PkkgdGhpbmsgdGhpcyBpcyBkZWZpbml0ZWx5IHRoZSB3YXkgdG8gZ28gYW5kIGJvdGggRW5yaWNv IGFuZCBJIA0KPihhcyBhdXRob3JzIG9mIG9uZSBvZiB0aGUgcHJvcG9zYWxzKSB3b3VsZCBiZSBo YXBweSB0byANCj5jb250cmlidXRlIG9uIGFueSBvZiB0aGUgcG9pbnRzIGluIHlvdXIgbGlzdC4g V2UgYWxzbyB0aG91Z2h0IA0KPnRoYXQgdGhlcmUgYXJlIHR3byBvdGhlciBpc3N1ZXMgdGhhdCB3 b3VsZCBwcm9iYWJseSByZXF1aXJlIA0KPnNvbWUgY29uc2lkZXJhdGlvbjoNCj4NCj4tIERIVCB1 cGdyYWRlcyAtIGFzIGZhciBhcyBJIGNhbiBzZWUsIGl0IGlzIGN1cnJlbnRseSBtb3N0IA0KPmNv dmVyZWQgYnkgQVNQLCBidXQgdGhlIGdlbmVyYWwgb3BpbmlvbiBpbiBDaGljYWdvIHNlZW1lZCB0 byANCj5iZSB0aGF0IHRoaXMgaXMgaW5kZWVkIGFuIGltcG9ydGFudCBpc3N1ZSB0aGF0IHdvdWxk IGhhdmUgdG8gDQo+YmUgYWRkcmVzc2VkIGJ5IHRoZSBwZWVyIHByb3RvY29sLg0KPg0KPi0gTW9i aWxpdHkgLSB0YWtpbmcgbW9iaWxpdHkgaW50byBhY2NvdW50IHdvdWxkIHByb2JhYmx5IA0KPmlu Zmx1ZW5jZSBzb21lIG9mIHRoZSBkZXNpZ24gY2hvaWNlcyAodW5kZXJseWluZyBwcm90b2NvbCwg DQo+c2Vzc2lvbiBmbGV4aWJpbGl0eSwgZXRjLi4pIHNvIGl0IG1pZ2h0IGJlIHdvcnRoIHRvIHRy eSBhbmQgDQo+c2VlIHRvIHdoYXQgZXh0ZW50IHdvdWxkIHRoZSBleGlzdGluZyBwcm9wb3NhbHMg Zml0IG1vYmlsZSBub2Rlcy4NCj4NCj5PbmUgbGFzdCB0aGluZy4gV2Ugc2hvdWxkIHByb2JhYmx5 IHRyeSBhbmQgc3RhcnQgaGF2aW5nIHNvbWUgDQo+b2YgdGhlc2UgZGlzY3Vzc2lvbnMgYmVmb3Jl IHRoZSBtZWV0aW5nIG9yLCBldmVuIGJldHRlciwgdG8gDQo+ZmluZCBzb21lIHdheSB0byBmb3N0 ZXIgb2ZmbGluZSB3b3JrIG9uIGVhY2ggdG9waWMsIHNpbmNlIHRoZXkgDQo+YXJlIGxpa2VseSB0 byByZXF1aXJlIG1vcmUgdGhhbiB0aGUgdGltZSB3ZSdsbCBoYXZlIHRoZXJlLiBJIA0KPmd1ZXNz IHRoYXQgUGhpbGlwJ3MgcHJlc2VudGF0aW9uIGluIENoaWNhZ28gd2FzIG1hZGUgd2l0aCB0aGUg DQo+c2FtZSBpbnRlbnRpb25zLCBidXQgaXQgd2FzIHByZXR0eSBjbGVhciB0aGF0IHRoZSB0aW1l IHdlIGhhZCANCj53YXMgaW5zdWZmaWNpZW50IGZvciBhbnkgbWVhbmluZ2Z1bCBkaXNjdXNzaW9u cy4NCj4NCj5DaGVlcnMNCj5FbWlsDQo+DQo+SGVubmluZyBTY2h1bHpyaW5uZSB3cm90ZToNCj4+ IEknZCBsaWtlIHRvIHByb3Bvc2UgYSBtZWNoYW5pc20gdG8gbWFrZSBwcm9ncmVzcyBvbiBjb252 ZXJnaW5nIG9uIGEgDQo+PiBwcm90b2NvbC4gTXkgaGlnaC1sZXZlbCBpbXByZXNzaW9uIGlzIHRo YXQgbW9zdCBvZiB0aGUgDQo+cHJvcG9zYWxzLCB3aXRoIA0KPj4gdGhlIGV4Y2VwdGlvbiBvZiB0 aGUgSElQLWJhc2VkIG9uZXMsIGFyZSBwaGlsb3NvcGhpY2FsbHkgbm90IA0KPnRoYXQgZmFyIA0K Pj4gcmVtb3ZlZCwgYW5kIHRoZSBkaWZmZXJlbmNlcyBhcmUgbW9yZSBhdCB0aGUgbWVjaGFuaWNh bCANCj5sZXZlbC4gT25lIHdheSANCj4+IHRvIG1ha2UgcHJvZ3Jlc3Mgd291bGQgYmUgdG8gaWRl bnRpZnkgc29tZSBvZiB0aGUgbWFqb3IgcGllY2VzLCBhbmQgDQo+PiB0aGVuLCBpbiBWYW5jb3V2 ZXIsIHN5c3RlbWF0aWNhbGx5IGdvIHRocm91Z2ggdGhlbS4gQW4gaW5pdGlhbCBsaXN0LCANCj4+ IGRlZmluaXRlbHkgaW5jb21wbGV0ZSwgaW5jbHVkZXMNCj4+IA0KPj4gLSBwYWNrZXQgZm9ybWF0 DQo+PiAtIE5BVCB0cmF2ZXJzYWwgZm9yIHAycCBtZXNzYWdlcyAobm90IG1lZGlhIG9yIFNJUCBz aWduYWxpbmcpDQo+PiAtIGNoYW5uZWwgc2VjdXJpdHkgZm9yIHAycCBtZXNzYWdlcw0KPj4gLSBy ZWN1cnNpb24gdnMuIGl0ZXJhdGl2ZQ0KPj4gLSBoYXNoIGFsZ29yaXRobSBuZWdvdGlhdGlvbiBh bmQgdXNhZ2UNCj4+IA0KPj4gT25lIHBvc3NpYmlsaXR5IGlzIHRvIGlkZW50aWZ5IGEgdm9sdW50 ZWVyIGZvciBlYWNoIGFyZWEsIHNvIA0KPnRoYXQgdGhlIA0KPj4gdGFzayBpcyBtb3JlIG1hbmFn ZWFibGUuIElmIHRoZXJlIGFyZSBtYWpvciBwaGlsb3NvcGhpY2FsIA0KPmRpZmZlcmVuY2VzLCAN Cj4+IHdlIHNob3VsZCBwcm9iYWJseSBkaXNjdXNzIHRob3NlIGZpcnN0LCBob3dldmVyLg0KPj4g DQo+PiBIZW5uaW5nDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBQMlBTSVAgbWFpbGluZyBsaXN0DQo+PiBQMlBTSVBAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0KPj4gDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5QMlBT SVAgbWFpbGluZyBsaXN0DQo+UDJQU0lQQGlldGYub3JnDQo+aHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vcDJwc2lwDQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpQMlBTSVAgbWFpbGluZyBsaXN0DQpQMlBTSVBAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycHNpcA0K --===============1590962718== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1590962718==-- From p2psip-bounces@ietf.org Mon Nov 12 05:52:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWuG-0001sS-UB; Mon, 12 Nov 2007 05:52:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWuG-0001rY-2e for p2psip@ietf.org; Mon, 12 Nov 2007 05:52:40 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrWuE-0008TJ-VO for p2psip@ietf.org; Mon, 12 Nov 2007 05:52:39 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE007XX3JMTD@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 18:52:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE007QX3JK0P@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 18:52:33 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRE0088G3JGDF@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 18:52:32 +0800 (CST) Date: Mon, 12 Nov 2007 18:52:41 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Proposal for progress on protocols In-reply-to: <009b01c8250e$62a305c0$da07740a@DELLWEI> To: 'Wei Gengyu' , marcin.matuszewski@nokia.com Message-id: <009601c8251a$25f7bfb0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcglDmx9lnRtS+fXTLa9BIgGoMv97gACuGFQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, In my understanding according to P2PSIP Reference model defined in "Concepts and Terminology for Peer to Peer SIP" (draft-ietf-p2psip-concepts-00), SIP is not eligible to act as a communication protocol between a peer and its associated clients. Further, in detail, considering those reasons as below, SIP is not eligible to be chosen as the signal underlying protocol of P2PSIP client protocol: (1). SIP does not exist between a client and its associated peer at some scenarios. According to P2PSIP Overlay Reference Model depicted in Figure 1 in "Concepts and Terminology for Peer to Peer SIP" (draft-ietf-p2psip-concepts-00), P2PSIP client protocol runs between a peer without any SIP entity and a client with a SIP entity, the peer does not recognize SIP protocol, SIP is not eligible to act as the signal underlying protocol of P2PSIP client protocol. (2). SIP is not a general Remote Procedure Call (RPC). A P2PSIP client protocol on top of SIP acts as a remote procedure call (RPC) mechanism. The SIP guidelines document [RFC4485] prohibits the use of SIP as a RPC mechanism. (3). SIP is not a general purpose transfer protocol. One of P2PSIP client protocol main tasks is to transfer resource object and its content, those contents is irrelevant to SIP. SIP's operation and the SIP guideline document [RFC4485] prohibit sending large amounts of data unrelated to SIP's operation. (4). SIP is not a lookup protocol. SIP is not a lookup protocol; it relies on DNS to locate an appropriate SIP server. Insert and lookup functionality is essential for any P2PSIP client protocol. Using SIP as a peer-to-peer protocol requires integrating lookup functionality into SIP which goes against its design philosophy. Best regards, Hewen -----Original Message----- From: Wei Gengyu [mailto:weigengyu@vip.sina.com] Sent: 2007?11?12? 17:28 To: marcin.matuszewski@nokia.com Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Proposal for progress on protocols Hi, all I have a question. A peer in a P2PSIP overlay can be the proxy of a mobile client. Could SIP(rfc3261) be used between the client and the proxy Peer instead of defining a new protocol? Best regards, Gengyu ----- Original Message ----- From: To: ; Sent: Thursday, November 08, 2007 5:28 PM Subject: RE: [P2PSIP] Proposal for progress on protocols Hi all, I agree with Henning's proposal. There is another issue: support for clients. I can to volunteer for "mobility" or "support for clients". Marcin >-----Original Message----- >From: ext Emil Ivov [mailto:emcho@sip-communicator.org] >Sent: 07 November, 2007 18:53 >To: P2PSIP Mailing List >Subject: Re: [P2PSIP] Proposal for progress on protocols > >Henning, all, > >I think this is definitely the way to go and both Enrico and I >(as authors of one of the proposals) would be happy to >contribute on any of the points in your list. We also thought >that there are two other issues that would probably require >some consideration: > >- DHT upgrades - as far as I can see, it is currently most >covered by ASP, but the general opinion in Chicago seemed to >be that this is indeed an important issue that would have to >be addressed by the peer protocol. > >- Mobility - taking mobility into account would probably >influence some of the design choices (underlying protocol, >session flexibility, etc..) so it might be worth to try and >see to what extent would the existing proposals fit mobile nodes. > >One last thing. We should probably try and start having some >of these discussions before the meeting or, even better, to >find some way to foster offline work on each topic, since they >are likely to require more than the time we'll have there. I >guess that Philip's presentation in Chicago was made with the >same intentions, but it was pretty clear that the time we had >was insufficient for any meaningful discussions. > >Cheers >Emil > >Henning Schulzrinne wrote: >> I'd like to propose a mechanism to make progress on converging on a >> protocol. My high-level impression is that most of the >proposals, with >> the exception of the HIP-based ones, are philosophically not >that far >> removed, and the differences are more at the mechanical >level. One way >> to make progress would be to identify some of the major pieces, and >> then, in Vancouver, systematically go through them. An initial list, >> definitely incomplete, includes >> >> - packet format >> - NAT traversal for p2p messages (not media or SIP signaling) >> - channel security for p2p messages >> - recursion vs. iterative >> - hash algorithm negotiation and usage >> >> One possibility is to identify a volunteer for each area, so >that the >> task is more manageable. If there are major philosophical >differences, >> we should probably discuss those first, however. >> >> Henning >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 06:01:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrX36-0003oI-2e; Mon, 12 Nov 2007 06:01:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrX34-0003jj-Ms for p2psip@ietf.org; Mon, 12 Nov 2007 06:01:46 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrX33-0000Ve-5I for p2psip@ietf.org; Mon, 12 Nov 2007 06:01:46 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE00FZ23YT0J@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 19:01:41 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE007HW3YSVV@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 19:01:41 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRE00FXG3YOYH@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 19:01:40 +0800 (CST) Date: Mon, 12 Nov 2007 19:01:38 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Proposal for progress on protocols In-reply-to: <009b01c8250e$62a305c0$da07740a@DELLWEI> To: 'Wei Gengyu' , marcin.matuszewski@nokia.com Message-id: <00a001c8251b$6651f110$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcglDmx9lnRtS+fXTLa9BIgGoMv97gADByBg X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, A client can contribute its storage capacity to its associated peer, certainly, it gets P2PSIP overlay service through its associated peer, as you mentioned, the peer act as a proxy for the client. In my opinion, maybe P2PSIP client protocol does not emerge as a distinct protocol at last, for example, it emerge a subset of P2PSIP peer protocol. Thanks, Hewen -----Original Message----- From: Wei Gengyu [mailto:weigengyu@vip.sina.com] Sent: 2007?11?12? 17:28 To: marcin.matuszewski@nokia.com Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Proposal for progress on protocols Hi, all I have a question. A peer in a P2PSIP overlay can be the proxy of a mobile client. Could SIP(rfc3261) be used between the client and the proxy Peer instead of defining a new protocol? Best regards, Gengyu ----- Original Message ----- From: To: ; Sent: Thursday, November 08, 2007 5:28 PM Subject: RE: [P2PSIP] Proposal for progress on protocols Hi all, I agree with Henning's proposal. There is another issue: support for clients. I can to volunteer for "mobility" or "support for clients". Marcin >-----Original Message----- >From: ext Emil Ivov [mailto:emcho@sip-communicator.org] >Sent: 07 November, 2007 18:53 >To: P2PSIP Mailing List >Subject: Re: [P2PSIP] Proposal for progress on protocols > >Henning, all, > >I think this is definitely the way to go and both Enrico and I >(as authors of one of the proposals) would be happy to >contribute on any of the points in your list. We also thought >that there are two other issues that would probably require >some consideration: > >- DHT upgrades - as far as I can see, it is currently most >covered by ASP, but the general opinion in Chicago seemed to >be that this is indeed an important issue that would have to >be addressed by the peer protocol. > >- Mobility - taking mobility into account would probably >influence some of the design choices (underlying protocol, >session flexibility, etc..) so it might be worth to try and >see to what extent would the existing proposals fit mobile nodes. > >One last thing. We should probably try and start having some >of these discussions before the meeting or, even better, to >find some way to foster offline work on each topic, since they >are likely to require more than the time we'll have there. I >guess that Philip's presentation in Chicago was made with the >same intentions, but it was pretty clear that the time we had >was insufficient for any meaningful discussions. > >Cheers >Emil > >Henning Schulzrinne wrote: >> I'd like to propose a mechanism to make progress on converging on a >> protocol. My high-level impression is that most of the >proposals, with >> the exception of the HIP-based ones, are philosophically not >that far >> removed, and the differences are more at the mechanical >level. One way >> to make progress would be to identify some of the major pieces, and >> then, in Vancouver, systematically go through them. An initial list, >> definitely incomplete, includes >> >> - packet format >> - NAT traversal for p2p messages (not media or SIP signaling) >> - channel security for p2p messages >> - recursion vs. iterative >> - hash algorithm negotiation and usage >> >> One possibility is to identify a volunteer for each area, so >that the >> task is more manageable. If there are major philosophical >differences, >> we should probably discuss those first, however. >> >> Henning >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 06:29:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXU1-0007Fr-3V; Mon, 12 Nov 2007 06:29:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrXTz-0007Fh-Nr for p2psip@ietf.org; Mon, 12 Nov 2007 06:29:35 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrXTw-0006ou-E4 for p2psip@ietf.org; Mon, 12 Nov 2007 06:29:35 -0500 Received: by ug-out-1314.google.com with SMTP id u2so2037134uge for ; Mon, 12 Nov 2007 03:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=s8Ppju/fSIKqbhro2j/eUG9GVnz7ypcYoHuuKJtaY8E=; b=bBdiFCDLIU8u0rBXSIZk5fmDuJzEh3F6yWib+qcqaTsNZVc+ddU1oK4eclaRu+4JVOayYltiUMgax4qG+DPJzF4yriPM+7lZK1vcYvWFpTnxfRYLwloISK0z/bCpETaQ8cmwadL0TgULSL9ebr/oGryJEvw4rutiw4jNlBfNp10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fmmKGRhhBsWtkmuR7+u1ns06aNZIW32qnPCV94lMiiHxuEQMOwFpNLX84HkiLq/xsWcMO2C82veucetazzsRO0O3jGMOVCQc3c/fW/Xbb//M0G8RglCv4niVgS2iPwXmKxrIUHzNlYIMxwIxaMH544mjFuYT1IzJ9X9N8uZIqVI= Received: by 10.66.250.18 with SMTP id x18mr2951156ugh.1194866971673; Mon, 12 Nov 2007 03:29:31 -0800 (PST) Received: by 10.66.252.5 with HTTP; Mon, 12 Nov 2007 03:29:31 -0800 (PST) Message-ID: <618e24240711120329k7f890a91t21e8f6c0caed7f81@mail.gmail.com> Date: Mon, 12 Nov 2007 12:29:31 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: "Zheng Hewen" Subject: Re: [P2PSIP] Proposal for progress on protocols In-Reply-To: <00a001c8251b$6651f110$5105a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <009b01c8250e$62a305c0$da07740a@DELLWEI> <00a001c8251b$6651f110$5105a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, On 12/11/2007, Zheng Hewen wrote: > A client can contribute its storage capacity to its associated peer IMHO we should consider 3 main actors: - Peers: nodes to perform the overlay and offer storage and routing capabilities. [coupled with one or more SIP entities] -> interact with other peers using peer protocol - Clients: nodes to contribute its storage capacity to its associated peer [coupled with SIP UA] -> interact with peers using client protocol - SIP [RFC3161] UA with no other capabilities -> interact with peers using SIP Clients and SIP UA will reach P2PSIP overlay through peers. While Clients will store some information, peers will store information on behalf of SIP UA (e.g. preferences). We should also consider how clients will interact, if directly -client protocol- or using a broker peer. I think this and other philosophical issues should be addressed in order to reach a consensus and update the concepts document. Thanks, Victor Pascual _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 07:47:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYhA-0005xH-UA; Mon, 12 Nov 2007 07:47:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrYh7-0005wz-NV for p2psip@ietf.org; Mon, 12 Nov 2007 07:47:13 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrYh7-0004tq-3T for p2psip@ietf.org; Mon, 12 Nov 2007 07:47:13 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE003C88UL2K@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 20:47:09 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRE007II8ULVV@szxga04-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 20:47:09 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRE00D4A8UHK6@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 12 Nov 2007 20:47:09 +0800 (CST) Date: Mon, 12 Nov 2007 20:47:05 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Proposal for progress on protocols In-reply-to: <618e24240711120329k7f890a91t21e8f6c0caed7f81@mail.gmail.com> To: 'Victor Pascual =?UNKNOWN?B?qKJ2aWxhJw==?= Message-id: <010d01c8252a$2165e840$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: AcglH08Eqz0ftyGvQu+nm+NYBPaFcQAChKTw X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Agree with your opinion which is compatible with P2PSIP Referenc= e Model. I suggest that we could adopt P2PSIP Reference Model defined in = draft-ietf-p2psip-concepts-00 as the primitive baseline=20 to reach a consensus and update the concepts document. Tahnks, Hewen -----Original Message----- =46rom: Victor Pascual =A8=A2vila [mailto:victor.pascual.avila@gmail.= com] Sent: 2007=C4=EA11=D4=C212=C8=D5 19:30 To: Zheng Hewen Cc: Wei Gengyu; marcin.matuszewski@nokia.com; p2psip@ietf.org Subject: Re: [P2PSIP] Proposal for progress on protocols Hi, On 12/11/2007, Zheng Hewen wrote: > A client can contribute its storage capacity to its associated peer IMHO we should consider 3 main actors: - Peers: nodes to perform the overlay and offer storage and routing c= apabilities. [coupled with one or more SIP entities] ->=20 interact with other peers using peer protocol - Clients: nodes to contribute its storage capacity to its associated= peer [coupled with SIP UA] -> interact with peers using=20 client protocol - SIP [RFC3161] UA with no other capabilities -> interact with peers = using SIP Clients and SIP UA will reach P2PSIP overlay through peers. While Cli= ents will store some information, peers will store=20 information on behalf of SIP UA (e.g. preferences). We should also consider how clients will interact, if directly -clien= t protocol- or using a broker peer. I think this and other philosophical issues should be addressed in or= der to reach a consensus and update the concepts=20 document. Thanks, Victor Pascual _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 09:55:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irah2-0006j1-1V; Mon, 12 Nov 2007 09:55:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irah0-0006iq-Iy for p2psip@ietf.org; Mon, 12 Nov 2007 09:55:14 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iragy-0002cB-LF for p2psip@ietf.org; Mon, 12 Nov 2007 09:55:14 -0500 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id 8F840AC241E; Mon, 12 Nov 2007 22:55:09 +0800 (CST) Message-ID: <005401c8253c$06417e00$da07740a@DELLWEI> From: "Wei Gengyu" To: "Zheng Hewen" References: <009601c8251a$25f7bfb0$5105a40a@china.huawei.com> Subject: Re: [P2PSIP] Proposal for progress on protocols Date: Mon, 12 Nov 2007 22:55:10 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.8 (++) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0551096880==" Errors-To: p2psip-bounces@ietf.org --===============0551096880== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIA0KDQpTSVAgaGFzIGJlZW4gd2lkZWx5IHVzZWQgYmV0d2VlbiBTSVAgY2xpZW50IGFuZCBw cm94eSBvciBzZXJ2ZXJzLCANCmFuZCBpdCBpcyBlYXN5IHRvIGdldCBzb21lIHRlc3RiZWQgcmVz dWx0cy4gIA0KDQpBbmQgd2UgaGF2ZSB0byBzZWUgdGhlIGZhY3QgdGhhdCB0aGVyZSBhcmUgbWFu eSBtb2JpbGUgdGVybWluYWxzIGluc3RhbGxlZCB3aXRoIFNJUCBVQS4NCldoZW4gY29uc2lkZXJp bmcgdGhlIG1vYmlsZSB0ZXJtaW5hbCBhcyBhIGNsaWVudCBvZiBQMlBTSVAgb3ZlcmxheSwgDQp0 aGUgU0lQIHByb3RvY29sIGlzIGNoZWFwIGFuZCBzdWl0YWJsZS4gDQoNCldoaWxlIGluICJDb25j ZXB0cyBhbmQgVGVybWlub2xvZ3kgZm9yIFBlZXIgdG8gUGVlciBTSVAgZHJhZnQtd2lsbGlzLXAy cHNpcC1jb25jZXB0cy0wNCINCm9yICJDb25jZXB0cyBhbmQgVGVybWlub2xvZ3kgZm9yIFBlZXIg dG8gUGVlciBTSVAiIChkcmFmdC1pZXRmLXAycHNpcC1jb25jZXB0cy0wMCksDQoiQW4gb3Zlcmxh eSBtYXkgb3IgbWF5IG5vdCBhbHNvIGluY2x1ZGUgb25lIG9yIG1vcmUgbm9kZXMgY2FsbGVkDQog ICBQMlBTSVAgQ2xpZW50cy4gIFRoZSByb2xlIG9mIGEgY2xpZW50IGluIHRoZSBQMlBTSVAgbW9k ZWwgaXMgc3RpbGwNCiAgIHVuZGVyIGRpc2N1c3Npb24sIHdpdGggYSBudW1iZXIgb2Ygc3VnZ2Vz dGlvbnMgZm9yIHJvbGVzIGJlaW5nIHB1dA0KICAgZm9ydGgsIGFuZCBzb21lIGFyZ3VpbmcgdGhh dCBjbGllbnRzIGFyZSBub3QgbmVlZGVkIGF0IGFsbC4gIEhvd2V2ZXIsDQogICBpZiB0aGV5IGV4 aXN0LCB0aGVuIHBlb3BsZSBhZ3JlZSB0aGF0IHRoZXkgd2lsbCBhbHNvIGJlIGFibGUgdG8gc3Rv cmUNCiAgIGFuZCByZXRyaWV2ZSBpbmZvcm1hdGlvbiBmcm9tIHRoZSBvdmVybGF5LiAgU2VjdGlv biA1LjUgZGlzY3Vzc2VzIHRoZQ0KICAgcG9zc2libGUgcm9sZXMgb2YgYSBjbGllbnQgaW4gbW9y ZSBkZXRhaWwuIg0KDQpJbiBzZWN0aW9uIDUuNToNCiJJbiBvbmUgYWx0ZXJuYXRpdmUsIGEgY2xp ZW50IGludGVyYWN0cyB3aXRoIHRoZSBQMlBTSVAgb3ZlcmxheQ0KICAgdGhyb3VnaCBhbiBhc3Nv Y2lhdGVkIHBlZXIgKG9yIHBlcmhhcHMgc2V2ZXJhbCBzdWNoIHBlZXJzKSB1c2luZyB0aGUNCiAg IENsaWVudCBQcm90b2NvbC4gIFRoZSBjbGllbnQgZG9lcyBub3QgcnVuIHRoZSBkaXN0cmlidXRl ZCBkYXRhYmFzZQ0KICAgYWxnb3JpdGhtLCBkb2VzIG5vdCBzdG9yZSByZXNvdXJjZSByZWNvcmRz LCBhbmQgaXMgbm90IGludm9sdmVkIGluDQogICByb3V0aW5nIG1lc3NhZ2VzIHRvIG90aGVyIHBl ZXJzIG9yIGNsaWVudHMuICBUaG91Z2ggaW50ZXJhY3Rpb25zIHdpdGgNCiAgIGl0cyBhc3NvY2lh dGVkIHBlZXIsIGEgY2xpZW50IGNhbiBpbnNlcnQsIG1vZGlmeSwgZXhhbWluZSwgYW5kIHJlbW92 ZQ0KICAgcmVzb3VyY2UgcmVjb3Jkcy4gIEEgY2xpZW50IGNhbiBhbHNvIHNlbmQgU0lQIG1lc3Nh Z2VzIHRvIGl0cw0KICAgYXNzb2NpYXRlZCBwZWVyIGZvciByb3V0aW5nIHRocm91Z2ggdGhlIG92 ZXJsYXkuICBJbiB0aGlzDQogICBhbHRlcm5hdGl2ZSwgYSBjbGllbnQgaXMgYSBub2RlIHRoYXQg d2FudHMgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlDQogICBvdmVybGF5LCBidXQgaXMgdW5hYmxl IG9yIHVud2lsbGluZyB0byBjb250cmlidXRlIHJlc291cmNlcyBiYWNrIHRvDQogICB0aGUgb3Zl cmxheS4NCg0KICAgT25lIHdheSB0byByZWFsaXplIHRoaXMgYWx0ZXJuYXRpdmUgaXMgZm9yIGEg cGVlciB0byBiZWhhdmUgYXMNCiAgIFtSRkMzMjYxXSBwcm94eS9yZWdpc3RyYXIuICBDbGllbnRz IHRoZW4gdXNlIHN0YW5kYXJkIFNJUCBtZWNoYW5pc21zDQogICB0byBhZGQsIHVwZGF0ZSwgYW5k IHJlbW92ZSByZWdpc3RyYXRpb25zIGFuZCB0byBzZW5kIFNJUCBtZXNzYWdlcyB0bw0KICAgcGVl cnMgYW5kIG90aGVyIGNsaWVudHMuICBJZiB0aGlzIGlzIGRvbmUsIHRoZXJlIGlzIG5vIG5lZWQg Zm9yIGENCiAgIHNlcGFyYXRlIENsaWVudCBQcm90b2NvbCBhbmQgbm8gbmVlZCBmb3IgUDJQU0lQ IHRvIGRlZmluZSBhIGRpc3RpbmN0DQogICAiUDJQU0lQIENsaWVudCIgY29uY2VwdC4iDQoNCiAg IEFuZCB0aGVyZSBhcmUgYWxzbyBzZWNvbmQgYW5kIHRoaXJkIGFsdGVybmF0aXZlcy4gDQoNCk15 IG9waW5pb24gaXMgdGhhdCBhZG9wdGluZyBTSVAgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUg YXNzb2NpYXRlZCBwcm94eSBQZWVyDQp3aWxsIGJlIHNpbXBsaWZ5IHRoZSBmYWNpbGl0aWVzIHRv IHN1cHBvcnQgbW9iaWxlIGNsaWVudHMgaW4gdGhlIHJlZmVyZW5jZSBtb2RlbC4NCg0KQmVzdCBy ZWdhcmRzLA0KDQpHZW5neXUgDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9t OiAiWmhlbmcgSGV3ZW4iIDxod3poZW5nQGh1YXdlaS5jb20+DQpUbzogIidXZWkgR2VuZ3l1JyIg PHdlaWdlbmd5dUB2aXAuc2luYS5jb20+OyA8bWFyY2luLm1hdHVzemV3c2tpQG5va2lhLmNvbT4N CkNjOiA8cDJwc2lwQGlldGYub3JnPg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMiwgMjAwNyA2 OjUyIFBNDQpTdWJqZWN0OiBSRTogW1AyUFNJUF0gUHJvcG9zYWwgZm9yIHByb2dyZXNzIG9uIHBy b3RvY29scw0KDQoNCj4gDQo+IEhpLA0KPiANCj4gICAgSW4gbXkgdW5kZXJzdGFuZGluZyBhY2Nv cmRpbmcgdG8gUDJQU0lQIFJlZmVyZW5jZSBtb2RlbCBkZWZpbmVkIGluICJDb25jZXB0cyBhbmQg VGVybWlub2xvZ3kgZm9yIFBlZXIgdG8gUGVlciBTSVAiDQo+IChkcmFmdC1pZXRmLXAycHNpcC1j b25jZXB0cy0wMCksIFNJUCBpcyBub3QgZWxpZ2libGUgdG8gYWN0IGFzIGEgY29tbXVuaWNhdGlv biBwcm90b2NvbCBiZXR3ZWVuIGEgcGVlciBhbmQgaXRzIGFzc29jaWF0ZWQNCj4gY2xpZW50cy4N Cj4gICAgRnVydGhlciwgaW4gZGV0YWlsLCBjb25zaWRlcmluZyB0aG9zZSByZWFzb25zIGFzIGJl bG93LCBTSVAgaXMgbm90IGVsaWdpYmxlIHRvIGJlIGNob3NlbiBhcyB0aGUgc2lnbmFsIHVuZGVy bHlpbmcNCj4gcHJvdG9jb2wgb2YgUDJQU0lQIGNsaWVudCBwcm90b2NvbDoNCj4gICAoMSkuIFNJ UCBkb2VzIG5vdCBleGlzdCBiZXR3ZWVuIGEgY2xpZW50IGFuZCBpdHMgYXNzb2NpYXRlZCBwZWVy IGF0IHNvbWUgc2NlbmFyaW9zLg0KPiAgIEFjY29yZGluZyB0byBQMlBTSVAgT3ZlcmxheSBSZWZl cmVuY2UgTW9kZWwgZGVwaWN0ZWQgaW4gRmlndXJlIDEgaW4gIkNvbmNlcHRzIGFuZCBUZXJtaW5v bG9neSBmb3IgUGVlciB0byBQZWVyIFNJUCINCj4gKGRyYWZ0LWlldGYtcDJwc2lwLWNvbmNlcHRz LTAwKSwgUDJQU0lQIGNsaWVudCBwcm90b2NvbCBydW5zIGJldHdlZW4gYSBwZWVyIHdpdGhvdXQg YW55IFNJUCBlbnRpdHkgYW5kIGEgY2xpZW50IHdpdGggYSBTSVANCj4gZW50aXR5LCB0aGUgcGVl ciBkb2VzIG5vdCByZWNvZ25pemUgU0lQIHByb3RvY29sLCBTSVAgaXMgbm90IGVsaWdpYmxlIHRv IGFjdCBhcyB0aGUgc2lnbmFsIHVuZGVybHlpbmcgcHJvdG9jb2wgb2YgUDJQU0lQDQo+IGNsaWVu dCBwcm90b2NvbC4NCj4gDQo+ICAgKDIpLiBTSVAgaXMgbm90IGEgZ2VuZXJhbCBSZW1vdGUgUHJv Y2VkdXJlIENhbGwgKFJQQykuDQo+ICAgQSBQMlBTSVAgY2xpZW50IHByb3RvY29sIG9uIHRvcCBv ZiBTSVAgYWN0cyBhcyBhIHJlbW90ZSBwcm9jZWR1cmUgY2FsbCAoUlBDKSBtZWNoYW5pc20uICBU aGUgU0lQIGd1aWRlbGluZXMgZG9jdW1lbnQNCj4gW1JGQzQ0ODVdIHByb2hpYml0cyB0aGUgdXNl IG9mIFNJUCBhcyBhIFJQQyBtZWNoYW5pc20uDQo+IA0KPiAgICgzKS4gU0lQIGlzIG5vdCBhIGdl bmVyYWwgcHVycG9zZSB0cmFuc2ZlciBwcm90b2NvbC4NCj4gICBPbmUgb2YgUDJQU0lQIGNsaWVu dCBwcm90b2NvbCBtYWluIHRhc2tzIGlzIHRvIHRyYW5zZmVyIHJlc291cmNlIG9iamVjdCBhbmQg aXRzIGNvbnRlbnQsIHRob3NlIGNvbnRlbnRzIGlzIGlycmVsZXZhbnQgdG8NCj4gU0lQLiAgU0lQ J3Mgb3BlcmF0aW9uIGFuZCB0aGUgU0lQIGd1aWRlbGluZSBkb2N1bWVudCBbUkZDNDQ4NV0gcHJv aGliaXQgc2VuZGluZyBsYXJnZSBhbW91bnRzIG9mIGRhdGEgdW5yZWxhdGVkIHRvIFNJUCdzDQo+ IG9wZXJhdGlvbi4NCj4gDQo+ICAgKDQpLiBTSVAgaXMgbm90IGEgbG9va3VwIHByb3RvY29sLg0K PiAgIFNJUCBpcyBub3QgYSBsb29rdXAgcHJvdG9jb2w7IGl0IHJlbGllcyBvbiBETlMgdG8gbG9j YXRlIGFuIGFwcHJvcHJpYXRlIFNJUCBzZXJ2ZXIuICBJbnNlcnQgYW5kIGxvb2t1cCBmdW5jdGlv bmFsaXR5IGlzDQo+IGVzc2VudGlhbCBmb3IgYW55IFAyUFNJUCBjbGllbnQgcHJvdG9jb2wuICBV c2luZyBTSVAgYXMgYSBwZWVyLXRvLXBlZXIgcHJvdG9jb2wgcmVxdWlyZXMgaW50ZWdyYXRpbmcg bG9va3VwIGZ1bmN0aW9uYWxpdHkNCj4gaW50byBTSVAgd2hpY2ggZ29lcyBhZ2FpbnN0IGl0cyBk ZXNpZ24gcGhpbG9zb3BoeS4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gSGV3ZW4NCj4gDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdlaSBHZW5neXUgW21haWx0bzp3ZWln ZW5neXVAdmlwLnNpbmEuY29tXQ0KPiBTZW50OiAyMDA3PzExPzEyPyAxNzoyOA0KPiBUbzogbWFy Y2luLm1hdHVzemV3c2tpQG5va2lhLmNvbQ0KPiBDYzogcDJwc2lwQGlldGYub3JnDQo+IFN1Ympl Y3Q6IFJlOiBbUDJQU0lQXSBQcm9wb3NhbCBmb3IgcHJvZ3Jlc3Mgb24gcHJvdG9jb2xzDQo+IA0K PiBIaSwgYWxsDQo+IA0KPiBJIGhhdmUgYSBxdWVzdGlvbi4NCj4gDQo+IEEgcGVlciBpbiBhIFAy UFNJUCBvdmVybGF5IGNhbiBiZSB0aGUgcHJveHkgb2YgYSBtb2JpbGUgY2xpZW50Lg0KPiBDb3Vs ZCBTSVAocmZjMzI2MSkgYmUgdXNlZCBiZXR3ZWVuIHRoZSBjbGllbnQgYW5kIHRoZSBwcm94eSBQ ZWVyIGluc3RlYWQgb2YgZGVmaW5pbmcgYSBuZXcgcHJvdG9jb2w/DQo+IA0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IA0KPiBHZW5neXUNCj4gDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCj4g RnJvbTogPG1hcmNpbi5tYXR1c3pld3NraUBub2tpYS5jb20+DQo+IFRvOiA8ZW1jaG9Ac2lwLWNv bW11bmljYXRvci5vcmc+OyA8cDJwc2lwQGlldGYub3JnPg0KPiBTZW50OiBUaHVyc2RheSwgTm92 ZW1iZXIgMDgsIDIwMDcgNToyOCBQTQ0KPiBTdWJqZWN0OiBSRTogW1AyUFNJUF0gUHJvcG9zYWwg Zm9yIHByb2dyZXNzIG9uIHByb3RvY29scw0KPiANCj4gDQo+IEhpIGFsbCwNCj4gDQo+IEkgYWdy ZWUgd2l0aCBIZW5uaW5nJ3MgcHJvcG9zYWwuIFRoZXJlIGlzIGFub3RoZXIgaXNzdWU6IHN1cHBv cnQgZm9yDQo+IGNsaWVudHMuDQo+IA0KPiBJIGNhbiB0byB2b2x1bnRlZXIgZm9yICJtb2JpbGl0 eSIgb3IgInN1cHBvcnQgZm9yIGNsaWVudHMiLg0KPiANCj4gTWFyY2luDQo+IA0KPj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBleHQgRW1pbCBJdm92IFttYWlsdG86ZW1jaG9A c2lwLWNvbW11bmljYXRvci5vcmddDQo+PlNlbnQ6IDA3IE5vdmVtYmVyLCAyMDA3IDE4OjUzDQo+ PlRvOiBQMlBTSVAgTWFpbGluZyBMaXN0DQo+PlN1YmplY3Q6IFJlOiBbUDJQU0lQXSBQcm9wb3Nh bCBmb3IgcHJvZ3Jlc3Mgb24gcHJvdG9jb2xzDQo+Pg0KPj5IZW5uaW5nLCBhbGwsDQo+Pg0KPj5J IHRoaW5rIHRoaXMgaXMgZGVmaW5pdGVseSB0aGUgd2F5IHRvIGdvIGFuZCBib3RoIEVucmljbyBh bmQgSQ0KPj4oYXMgYXV0aG9ycyBvZiBvbmUgb2YgdGhlIHByb3Bvc2Fscykgd291bGQgYmUgaGFw cHkgdG8NCj4+Y29udHJpYnV0ZSBvbiBhbnkgb2YgdGhlIHBvaW50cyBpbiB5b3VyIGxpc3QuIFdl IGFsc28gdGhvdWdodA0KPj50aGF0IHRoZXJlIGFyZSB0d28gb3RoZXIgaXNzdWVzIHRoYXQgd291 bGQgcHJvYmFibHkgcmVxdWlyZQ0KPj5zb21lIGNvbnNpZGVyYXRpb246DQo+Pg0KPj4tIERIVCB1 cGdyYWRlcyAtIGFzIGZhciBhcyBJIGNhbiBzZWUsIGl0IGlzIGN1cnJlbnRseSBtb3N0DQo+PmNv dmVyZWQgYnkgQVNQLCBidXQgdGhlIGdlbmVyYWwgb3BpbmlvbiBpbiBDaGljYWdvIHNlZW1lZCB0 bw0KPj5iZSB0aGF0IHRoaXMgaXMgaW5kZWVkIGFuIGltcG9ydGFudCBpc3N1ZSB0aGF0IHdvdWxk IGhhdmUgdG8NCj4+YmUgYWRkcmVzc2VkIGJ5IHRoZSBwZWVyIHByb3RvY29sLg0KPj4NCj4+LSBN b2JpbGl0eSAtIHRha2luZyBtb2JpbGl0eSBpbnRvIGFjY291bnQgd291bGQgcHJvYmFibHkNCj4+ aW5mbHVlbmNlIHNvbWUgb2YgdGhlIGRlc2lnbiBjaG9pY2VzICh1bmRlcmx5aW5nIHByb3RvY29s LA0KPj5zZXNzaW9uIGZsZXhpYmlsaXR5LCBldGMuLikgc28gaXQgbWlnaHQgYmUgd29ydGggdG8g dHJ5IGFuZA0KPj5zZWUgdG8gd2hhdCBleHRlbnQgd291bGQgdGhlIGV4aXN0aW5nIHByb3Bvc2Fs cyBmaXQgbW9iaWxlIG5vZGVzLg0KPj4NCj4+T25lIGxhc3QgdGhpbmcuIFdlIHNob3VsZCBwcm9i YWJseSB0cnkgYW5kIHN0YXJ0IGhhdmluZyBzb21lDQo+Pm9mIHRoZXNlIGRpc2N1c3Npb25zIGJl Zm9yZSB0aGUgbWVldGluZyBvciwgZXZlbiBiZXR0ZXIsIHRvDQo+PmZpbmQgc29tZSB3YXkgdG8g Zm9zdGVyIG9mZmxpbmUgd29yayBvbiBlYWNoIHRvcGljLCBzaW5jZSB0aGV5DQo+PmFyZSBsaWtl bHkgdG8gcmVxdWlyZSBtb3JlIHRoYW4gdGhlIHRpbWUgd2UnbGwgaGF2ZSB0aGVyZS4gSQ0KPj5n dWVzcyB0aGF0IFBoaWxpcCdzIHByZXNlbnRhdGlvbiBpbiBDaGljYWdvIHdhcyBtYWRlIHdpdGgg dGhlDQo+PnNhbWUgaW50ZW50aW9ucywgYnV0IGl0IHdhcyBwcmV0dHkgY2xlYXIgdGhhdCB0aGUg dGltZSB3ZSBoYWQNCj4+d2FzIGluc3VmZmljaWVudCBmb3IgYW55IG1lYW5pbmdmdWwgZGlzY3Vz c2lvbnMuDQo+Pg0KPj5DaGVlcnMNCj4+RW1pbA0KPj4NCj4+SGVubmluZyBTY2h1bHpyaW5uZSB3 cm90ZToNCj4+PiBJJ2QgbGlrZSB0byBwcm9wb3NlIGEgbWVjaGFuaXNtIHRvIG1ha2UgcHJvZ3Jl c3Mgb24gY29udmVyZ2luZyBvbiBhDQo+Pj4gcHJvdG9jb2wuIE15IGhpZ2gtbGV2ZWwgaW1wcmVz c2lvbiBpcyB0aGF0IG1vc3Qgb2YgdGhlDQo+PnByb3Bvc2Fscywgd2l0aA0KPj4+IHRoZSBleGNl cHRpb24gb2YgdGhlIEhJUC1iYXNlZCBvbmVzLCBhcmUgcGhpbG9zb3BoaWNhbGx5IG5vdA0KPj50 aGF0IGZhcg0KPj4+IHJlbW92ZWQsIGFuZCB0aGUgZGlmZmVyZW5jZXMgYXJlIG1vcmUgYXQgdGhl IG1lY2hhbmljYWwNCj4+bGV2ZWwuIE9uZSB3YXkNCj4+PiB0byBtYWtlIHByb2dyZXNzIHdvdWxk IGJlIHRvIGlkZW50aWZ5IHNvbWUgb2YgdGhlIG1ham9yIHBpZWNlcywgYW5kDQo+Pj4gdGhlbiwg aW4gVmFuY291dmVyLCBzeXN0ZW1hdGljYWxseSBnbyB0aHJvdWdoIHRoZW0uIEFuIGluaXRpYWwg bGlzdCwNCj4+PiBkZWZpbml0ZWx5IGluY29tcGxldGUsIGluY2x1ZGVzDQo+Pj4NCj4+PiAtIHBh Y2tldCBmb3JtYXQNCj4+PiAtIE5BVCB0cmF2ZXJzYWwgZm9yIHAycCBtZXNzYWdlcyAobm90IG1l ZGlhIG9yIFNJUCBzaWduYWxpbmcpDQo+Pj4gLSBjaGFubmVsIHNlY3VyaXR5IGZvciBwMnAgbWVz c2FnZXMNCj4+PiAtIHJlY3Vyc2lvbiB2cy4gaXRlcmF0aXZlDQo+Pj4gLSBoYXNoIGFsZ29yaXRo bSBuZWdvdGlhdGlvbiBhbmQgdXNhZ2UNCj4+Pg0KPj4+IE9uZSBwb3NzaWJpbGl0eSBpcyB0byBp ZGVudGlmeSBhIHZvbHVudGVlciBmb3IgZWFjaCBhcmVhLCBzbw0KPj50aGF0IHRoZQ0KPj4+IHRh c2sgaXMgbW9yZSBtYW5hZ2VhYmxlLiBJZiB0aGVyZSBhcmUgbWFqb3IgcGhpbG9zb3BoaWNhbA0K Pj5kaWZmZXJlbmNlcywNCj4+PiB3ZSBzaG91bGQgcHJvYmFibHkgZGlzY3VzcyB0aG9zZSBmaXJz dCwgaG93ZXZlci4NCj4+Pg0KPj4+IEhlbm5pbmcNCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gUDJQU0lQIG1haWxpbmcgbGlzdA0K Pj4+IFAyUFNJUEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3AycHNpcA0KPj4+DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj5QMlBTSVAgbWFpbGluZyBsaXN0DQo+PlAyUFNJUEBpZXRmLm9y Zw0KPj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCj4+DQo+ IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBQ MlBTSVAgbWFpbGluZyBsaXN0DQo+IFAyUFNJUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCj4gDQo+IA0KPiANCj4= --===============0551096880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0551096880==-- From p2psip-bounces@ietf.org Mon Nov 12 11:36:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcHF-0006bB-G6; Mon, 12 Nov 2007 11:36:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcHE-0006aY-3V for p2psip@ietf.org; Mon, 12 Nov 2007 11:36:44 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrcHD-0007UJ-QD for p2psip@ietf.org; Mon, 12 Nov 2007 11:36:44 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrcHB-0001J6-0u; Mon, 12 Nov 2007 11:36:41 -0500 In-Reply-To: <009b01c8250e$62a305c0$da07740a@DELLWEI> References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu><4731ED7B.2070901@sip-communicator.org> <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> <009b01c8250e$62a305c0$da07740a@DELLWEI> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Proposal for progress on protocols Date: Mon, 12 Nov 2007 11:37:44 -0500 To: Wei Gengyu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12-Nov-07, at 04:28 , Wei Gengyu wrote: > Hi, all > > I have a question. > > A peer in a P2PSIP overlay can be the proxy of a mobile client. > Could SIP(rfc3261) be used between the client and the proxy Peer > instead of defining a new protocol? This is in fact a long-running proposal. The answer to this question depends on whether you are interested in using a P2PSIP overlay for just SIP, or whether you think our work should be more general. If you are interested in just SIP, then this is an excellent suggestion. However, if you are interested in protocols other than SIP, then this idea doesn't work. Up until about Jan 2007, most of the active players in this group seemed to be primarily interested in just SIP. However, this year has seen a rise in interest in non-SIP usages. However, most (all?) of the currently active proposals are not considering clients right now. Personally, I think this is because people are still trying to figure out how peers work. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 11:39:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcJg-0007MO-Fz; Mon, 12 Nov 2007 11:39:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcJe-0007ME-P0 for p2psip@ietf.org; Mon, 12 Nov 2007 11:39:14 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrcJe-0007Yq-Gb for p2psip@ietf.org; Mon, 12 Nov 2007 11:39:14 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrcJX-0002xV-11; Mon, 12 Nov 2007 11:39:07 -0500 In-Reply-To: <00a001c8251b$6651f110$5105a40a@china.huawei.com> References: <00a001c8251b$6651f110$5105a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8E01D862-DC31-4889-B427-C7B53FD86589@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Proposal for progress on protocols Date: Mon, 12 Nov 2007 11:40:10 -0500 To: Zheng Hewen X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12-Nov-07, at 06:01 , Zheng Hewen wrote: > > In my opinion, maybe P2PSIP client protocol does not emerge as > a distinct protocol at last, for example, it emerge a > subset of P2PSIP peer protocol. The WG has agreed that, _if_ there is a client protocol, then it should be a logical subset of the peer protocol. Here logical means that it may have different syntax, but you cannot do more as a client than you can as a peer. This is documented in the Concepts draft. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 11:44:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcOT-0001JB-4r; Mon, 12 Nov 2007 11:44:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcOQ-0001Iy-GY for p2psip@ietf.org; Mon, 12 Nov 2007 11:44:10 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrcOQ-0007mK-7C for p2psip@ietf.org; Mon, 12 Nov 2007 11:44:10 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrcOP-00006u-2d; Mon, 12 Nov 2007 11:44:09 -0500 In-Reply-To: <010d01c8252a$2165e840$5105a40a@china.huawei.com> References: <010d01c8252a$2165e840$5105a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Proposal for progress on protocols Date: Mon, 12 Nov 2007 11:45:15 -0500 To: Zheng Hewen X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12-Nov-07, at 07:47 , Zheng Hewen wrote: > I suggest that we could adopt P2PSIP Reference Model defined > in draft-ietf-p2psip-concepts-00 as the primitive baseline > to reach a consensus and update the concepts document. I don't understand what you are suggesting. The Reference Model in section 3 of draft-ietf-p2psip-concepts-00 is supposed to reflect current group consensus. That means it is _already_ adopted, and the Concepts draft is _already_ up-to-date on this issue. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 13:22:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irdw2-0007Nj-CR; Mon, 12 Nov 2007 13:22:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irdvz-0007Mi-VG for p2psip@ietf.org; Mon, 12 Nov 2007 13:22:56 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irdvz-00043P-Lg for p2psip@ietf.org; Mon, 12 Nov 2007 13:22:55 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrdvV-0006fN-19 for p2psip@ietf.org; Mon, 12 Nov 2007 13:22:25 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: P2PSIP Mailing List From: Philip Matthews Date: Mon, 12 Nov 2007 13:24:02 -0500 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [P2PSIP] Proposed term: "Responsible Peer" X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Folks: I have been reviewing the mailing list again in preparation to revise the Concepts draft for this IETF cycle. As I said in an earlier e- mail message: http://www1.ietf.org/mail-archive/web/p2psip/current/msg02973.html the authors don't see a big revision this time, preferring to wait until the various active proposals come closer together. However, one change that has been discussed on the mailing list was a term for the peer which is responsible for storing the resource record for a given resource. I saw two terms were proposed on the mailing list and in private e-mails around this topic: "Responsible Peer" and "Root Peer". The authors currently feel that the term "Responsible Peer" would be a better choice, while recogizing that the term "Root Peer" is also used in the literature. So I am proposing the following text for the next revision of the Concepts draft: P2PSIP Responsible Peer: The Peer that is responsible for storing the Resource Record for a Resource. In the literature, the term "Root Peer" is also used for this concept. Comments? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 13:54:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreQN-00033U-IL; Mon, 12 Nov 2007 13:54:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreQL-0002z7-U3 for p2psip@ietf.org; Mon, 12 Nov 2007 13:54:17 -0500 Received: from aplesnation.dom1.jhuapl.edu ([128.244.198.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IreQL-0005Lf-HV for p2psip@ietf.org; Mon, 12 Nov 2007 13:54:17 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Mon, 12 Nov 2007 13:54:15 -0500 Message-ID: <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> In-Reply-To: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Thread-Index: Acgk5Rq5MwQZ3O4lTLq5NMXtNhgPCQAdD1/Q References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> From: "Wang, XiaoXiao (Sherry)" To: "Philip Matthews" , "P2PSIP Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Zheng, Harold" , "Cole, Robert G." X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Philip, Some minor comments: 1. Since the term "identifiers" has been used by the Host Identity Protocol (HIP) from its beginning, which has a similar meaning as yours, would you please coin another term to avoid confusion? Though these protocols share the same concept as you have pointed out, but they do not perform the same functions. It is better to use another term unless you do mean the same thing.=20 2. The benefits are not clear to me why to add one more "ID" at the network layer besides home IP address, care-of-address, and collocated care-of-address. I had the same question to HIP. I cannot see the benefits of using it at the network layer for routing. I need to be educated. Thanks a lot, Sherry =20 -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Sunday, November 11, 2007 11:33 PM To: P2PSIP Mailing List Subject: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Eric Cooper, Alan Johnston, and I have just submitted a new draft: http://www.ietf.org/internet-drafts/draft-matthews-p2psip-id- loc-00.txt This draft attempts to present what we feel is the most important concept that P2PSIP can take from HIP: the concept of the ID/Locator split. This draft describes the concept and how it can be implemented, and argues why it is so beneficial to P2PSIP. The goal of this draft is to focus discussion around this concept, without getting distracted by the other features that HIP has. We deliberately kept this draft short to make it an easy read (only 14 pages). We are looking forward to the discussion. - Philip Here is the meta-data for the draft (from the secretariat): Filename: draft-matthews-p2psip-id-loc Revision: 00 Title: An ID/Locator Architecture for P2PSIP Creation_date: 2007-11-11 WG ID: Independent Submission Number_of_pages: 14 Abstract: This document describes an architecture where peers in an overlay use special IP addresses to identify other peers. Two of the advantages of this approach are that (a) most existing applications can run in an overlay without needing any changes and (b) peer mobility and NAT traversal are handled in a way that is transparent to most applications.Terminology _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 14:27:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrewF-0004HQ-Ao; Mon, 12 Nov 2007 14:27:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrewD-0004Cl-Ln for p2psip@ietf.org; Mon, 12 Nov 2007 14:27:13 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrewD-0006gh-5X for p2psip@ietf.org; Mon, 12 Nov 2007 14:27:13 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrewA-0007Un-1L; Mon, 12 Nov 2007 14:27:10 -0500 In-Reply-To: <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6BB12D91-38F3-47C5-91F9-BE4E3631C7F7@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Mon, 12 Nov 2007 14:28:18 -0500 To: "Wang, XiaoXiao (Sherry)" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: "Zheng, Harold" , "Cole, Robert G." , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12-Nov-07, at 13:54 , Wang, XiaoXiao (Sherry) wrote: > Philip, > > Some minor comments: > 1. Since the term "identifiers" has been used by the Host Identity > Protocol (HIP) from its beginning, which has a similar meaning as > yours, > would you please coin another term to avoid confusion? Though these > protocols share the same concept as you have pointed out, but they do > not perform the same functions. It is better to use another term > unless > you do mean the same thing. You are right. Using just the term "identifier" was probably a bad choice. Until recently, we thought that our IPv6 "identifier" was the same as a HIT (Host Identity Tag in HIP). It is only recently that we have started to question that. So think of it as "possibly a HIT, or possibly something else". > > 2. The benefits are not clear to me why to add one more "ID" at the > network layer besides home IP address, care-of-address, and collocated > care-of-address. I had the same question to HIP. I cannot see the > benefits of using it at the network layer for routing. I need to be > educated. These identifiers are not used for routing. Instead, they identify a node independent of where it is located. This is particularly useful for peers behind a NAT. In a large P2PSIP overlay, there will probably be hundreds of peers with IP address of 10.0.0.1. When these peers talk to nodes outside their NAT, they will be allocated public (IP address,port) combinations, but these can be ephemeral, and may differ based on who the peer is talking to. So addresses are a really poor way of identifying peers behind a NAT. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 14:30:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrezN-0007X5-Je; Mon, 12 Nov 2007 14:30:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrezM-0007Wl-NT for p2psip@ietf.org; Mon, 12 Nov 2007 14:30:28 -0500 Received: from aplesnation.dom1.jhuapl.edu ([128.244.198.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrezK-0001Pq-BV for p2psip@ietf.org; Mon, 12 Nov 2007 14:30:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Mon, 12 Nov 2007 14:30:23 -0500 Message-ID: <7B95239DDD54E54B9BFA23847142B1EE03065B98@aplesnation.dom1.jhuapl.edu> In-Reply-To: <6BB12D91-38F3-47C5-91F9-BE4E3631C7F7@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Thread-Index: AcglYhpqoB3iejZsQ3G72Yv2zBgKFgAAE6+g References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca><7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <6BB12D91-38F3-47C5-91F9-BE4E3631C7F7@magma.ca> From: "Wang, XiaoXiao (Sherry)" To: "Philip Matthews" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: "Zheng, Harold" , "Cole, Robert G." , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Philip, Thanks. It's very helpful. Sherry=20 -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Monday, November 12, 2007 2:28 PM To: Wang, XiaoXiao (Sherry) Cc: Zheng, Harold; Cole, Robert G.; P2PSIP Mailing List Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP On 12-Nov-07, at 13:54 , Wang, XiaoXiao (Sherry) wrote: > Philip, > > Some minor comments: > 1. Since the term "identifiers" has been used by the Host Identity=20 > Protocol (HIP) from its beginning, which has a similar meaning as=20 > yours, would you please coin another term to avoid confusion? Though=20 > these protocols share the same concept as you have pointed out, but=20 > they do not perform the same functions. It is better to use another=20 > term unless you do mean the same thing. You are right. Using just the term "identifier" was probably a bad choice. Until recently, we thought that our IPv6 "identifier" was the same as a HIT (Host Identity Tag in HIP). It is only recently that we have started to question that. So think of it as "possibly a HIT, or possibly something else". > > 2. The benefits are not clear to me why to add one more "ID" at the=20 > network layer besides home IP address, care-of-address, and collocated > care-of-address. I had the same question to HIP. I cannot see the=20 > benefits of using it at the network layer for routing. I need to be=20 > educated. These identifiers are not used for routing. Instead, they identify a node independent of where it is located. This is particularly useful for peers behind a NAT. In a large P2PSIP overlay, there will probably be hundreds of peers with IP address of 10.0.0.1. When these peers talk to nodes outside their NAT, they will be allocated public (IP address,port) combinations, but these can be ephemeral, and may differ based on who the peer is talking to. So addresses are a really poor way of identifying peers behind a NAT. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 15:09:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irfak-0005be-84; Mon, 12 Nov 2007 15:09:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irfaj-0005b5-HZ for p2psip@ietf.org; Mon, 12 Nov 2007 15:09:05 -0500 Received: from chip2og54.obsmtp.com ([64.18.13.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irfai-0000CR-Sc for p2psip@ietf.org; Mon, 12 Nov 2007 15:09:05 -0500 Received: from source ([192.150.11.134]) by chip2ob54.postini.com ([64.18.5.12]) with SMTP; Mon, 12 Nov 2007 12:08:57 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lACK6pOP006449; Mon, 12 Nov 2007 12:06:52 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lACK8sFV027139; Mon, 12 Nov 2007 12:08:55 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 12:08:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Mon, 12 Nov 2007 12:08:45 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> In-Reply-To: <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Thread-Index: Acgk5Rq5MwQZ3O4lTLq5NMXtNhgPCQAdD1/QAANYXOA= References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> From: "Henry Sinnreich" To: "Wang, XiaoXiao (Sherry)" , "Philip Matthews" , "P2PSIP Mailing List" X-OriginalArrivalTime: 12 Nov 2007 20:08:54.0140 (UTC) FILETIME=[D986ABC0:01C82567] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "Zheng, Harold" , "Cole, Robert G." X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The term commonly used in the p2p communities is as a hash of some data or location. Is there a problem using ? Thanks, Henry -----Original Message----- From: Wang, XiaoXiao (Sherry) [mailto:Sherry.Wang@jhuapl.edu]=20 Sent: Monday, November 12, 2007 12:54 PM To: Philip Matthews; P2PSIP Mailing List Cc: Zheng, Harold; Cole,Robert G. Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Philip, Some minor comments: 1. Since the term "identifiers" has been used by the Host Identity Protocol (HIP) from its beginning, which has a similar meaning as yours, would you please coin another term to avoid confusion? Though these protocols share the same concept as you have pointed out, but they do not perform the same functions. It is better to use another term unless you do mean the same thing.=20 2. The benefits are not clear to me why to add one more "ID" at the network layer besides home IP address, care-of-address, and collocated care-of-address. I had the same question to HIP. I cannot see the benefits of using it at the network layer for routing. I need to be educated. Thanks a lot, Sherry =20 -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Sunday, November 11, 2007 11:33 PM To: P2PSIP Mailing List Subject: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Eric Cooper, Alan Johnston, and I have just submitted a new draft: http://www.ietf.org/internet-drafts/draft-matthews-p2psip-id- loc-00.txt This draft attempts to present what we feel is the most important concept that P2PSIP can take from HIP: the concept of the ID/Locator split. This draft describes the concept and how it can be implemented, and argues why it is so beneficial to P2PSIP. The goal of this draft is to focus discussion around this concept, without getting distracted by the other features that HIP has. We deliberately kept this draft short to make it an easy read (only 14 pages). We are looking forward to the discussion. - Philip Here is the meta-data for the draft (from the secretariat): Filename: draft-matthews-p2psip-id-loc Revision: 00 Title: An ID/Locator Architecture for P2PSIP Creation_date: 2007-11-11 WG ID: Independent Submission Number_of_pages: 14 Abstract: This document describes an architecture where peers in an overlay use special IP addresses to identify other peers. Two of the advantages of this approach are that (a) most existing applications can run in an overlay without needing any changes and (b) peer mobility and NAT traversal are handled in a way that is transparent to most applications.Terminology _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 15:47:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrgAY-0006SX-GM; Mon, 12 Nov 2007 15:46:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrgAW-0006RH-6r for p2psip@ietf.org; Mon, 12 Nov 2007 15:46:04 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrgAV-0001ko-NO for p2psip@ietf.org; Mon, 12 Nov 2007 15:46:04 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrgAV-0003bN-0R; Mon, 12 Nov 2007 15:46:03 -0500 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Mon, 12 Nov 2007 15:47:09 -0500 To: "Henry Sinnreich" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "Zheng, Harold" , "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12-Nov-07, at 15:08 , Henry Sinnreich wrote: > The term commonly used in the p2p communities is as a hash of > some data or location. > > Is there a problem using ? > There are actually three different concepts to deal with, and the challenge is to figure out their relationship. The first is the Peer ID as defined in the Concepts draft. This ID uniquely identifies a peer in the overlay. In many DHTs, it also describes where in the overlay the peer can be found (e.g., Chord arranges peers in a ring based on their peer ids). The second is the local identifier used inside an application to refer to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all propose to make this identifier look like an IP address, so that applications can continue to use the Socket API, which allows many existing applications to operate without change in an overlay. The third is the Host ID as defined by HIP. This ID uniquely identifies a host in the Internet, and is especially useful in mobility situation and when nodes are behind NATs. So what is the relationship between these three concepts? o Does local identifier = peer ID? If yes, then Peer IDs probably need to be globally unique, not just unique within a overlay, otherwise you get into problems when a peer is a member of two different overlays. Globally unique Peer IDs are possible, but present some challenges. o Does Host ID = Peer ID? This is what HIP-HOP-00 proposes. However, Eric Rescorla argues that this opens up the overlay to Sybil attacks. Right now, I am personally thinking that three of these are distinct. However, these questions are listed in the ID/Loc document as open issues. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 15:56:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrgKF-0006Ul-GT; Mon, 12 Nov 2007 15:56:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrgKE-0006R2-Im for p2psip@ietf.org; Mon, 12 Nov 2007 15:56:06 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrgKB-0004c3-Uo for p2psip@ietf.org; Mon, 12 Nov 2007 15:56:06 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1187775rvb for ; Mon, 12 Nov 2007 12:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=WpsHEoX2Dk6Fw5BB9w/LLsASCETzhLtdp8uh2d+ZPXg=; b=mQjALraRaIgqwQjERqWdKXD9NUkwDr+nDznN9ILMIUCwYOlzHlsZzuN3VxHwLY/PSyfJdXepl6HfG0t+berU4STlshXgCB1IWqHCLBgREsbUaKcbtKuADghG+TGev4IemVa4ZrhfJhGlvOzVXd1lLXms7+aC6iTaQFlFKG84RPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gV8BINiKU60Eb8PncZsoGzVZPn6qd08OKHrib9ImJT4w4doAjfvxa8ys5BxCrP0GLL1uxgSEX6r5GnUuXuaAwaJtICgffPztmFYBNXuFJJxo/RkpI4zZrqCjlkVCZ9LrqB+jxATDiaxZz1leJq9SQCGpqJE1fo2GrIkqs9cOP34= Received: by 10.141.52.5 with SMTP id e5mr2664050rvk.1194900963115; Mon, 12 Nov 2007 12:56:03 -0800 (PST) Received: by 10.65.180.16 with HTTP; Mon, 12 Nov 2007 12:56:03 -0800 (PST) Message-ID: <4d4304a00711121256r7814b413t2ff3958b38112775@mail.gmail.com> Date: Mon, 12 Nov 2007 15:56:03 -0500 From: "David A. Bryan" To: "Philip Matthews" Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-Reply-To: <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> X-Google-Sender-Auth: 8c769a60ef1a70f4 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "Zheng, Harold" , Henry Sinnreich , "Cole, Robert G." , "Wang, XiaoXiao \(Sherry\)" , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org When you talk about making identifiers "globally unique, not just unique within an overlay", I get a bit confused. Technically, there is nothing that is really making most Peer-IDs or Resource-IDs, which may just be a hash of something, truly unique. It is simply the remote odds (1 : 2^160, for one possible case) that makes a collision very unlikely. Are you looking to get something stronger from these identifiers? David (as individual) On Nov 12, 2007 3:47 PM, Philip Matthews wrote: > > > On 12-Nov-07, at 15:08 , Henry Sinnreich wrote: > > > The term commonly used in the p2p communities is as a hash of > > some data or location. > > > > Is there a problem using ? > > > > There are actually three different concepts to deal with, and the > challenge is to figure out their relationship. > > The first is the Peer ID as defined in the Concepts draft. This ID > uniquely identifies a peer in the overlay. In many DHTs, it also > describes where in the overlay the peer can be found (e.g., Chord > arranges peers in a ring based on their peer ids). > > The second is the local identifier used inside an application to > refer to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all > propose to make this identifier look like an IP address, so that > applications can continue to use the Socket API, which allows many > existing applications to operate without change in an overlay. > > The third is the Host ID as defined by HIP. This ID uniquely > identifies a host in the Internet, and is especially useful in > mobility situation and when nodes are behind NATs. > > > So what is the relationship between these three concepts? > o Does local identifier = peer ID? If yes, then Peer IDs probably > need to be globally unique, not just unique within a overlay, > otherwise you get into problems when a peer is a member of two > different overlays. Globally unique Peer IDs are possible, but > present some challenges. > > o Does Host ID = Peer ID? This is what HIP-HOP-00 proposes. > However, Eric Rescorla argues that this opens up the overlay to Sybil > attacks. > > > Right now, I am personally thinking that three of these are distinct. > However, these questions are listed in the ID/Loc document as open > issues. > > - Philip > > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 16:00:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrgOe-0003lm-FU; Mon, 12 Nov 2007 16:00:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrgOc-0003l6-4x for p2psip@ietf.org; Mon, 12 Nov 2007 16:00:38 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrgOb-0002e7-LZ for p2psip@ietf.org; Mon, 12 Nov 2007 16:00:38 -0500 Received: from macmini1.cs.columbia.edu (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lACL0Yuh004683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Nov 2007 16:00:35 -0500 (EST) Message-Id: From: Henning Schulzrinne To: Philip Matthews In-Reply-To: <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Mon, 12 Nov 2007 16:00:28 -0500 References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> X-Mailer: Apple Mail (2.912) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: "Zheng, Harold" , Henry Sinnreich , "Cole, Robert G." , "Wang, XiaoXiao \(Sherry\)" , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The notion of using the IP stack transparently seems dubious, as this would require quite a few restrictions on the identifier, leaving issues of how to implement this aside. I'm also doubting that this is useful, since we really do not want to route all packets through the overlay, only the first one, for efficiency reasons. On the numbering issue: The numbering space would have to exclude - the RFC 1918 ranges - the local address ranges (since routing would likely direct this to the local interface and bypass routing) - class E addresses The socket call would have to say "this is a real IPv4/IPv6 address, not an overlay address". How? If you designate this as a different protocol, in parallel to IPv4 and IPv6, you could just as well use a node ID of any length. Thus, I'm not convinced that this is a useful goal for an overlay network. Even if it can be done, all it accomplishes is making packets take ten hops across the Internet instead of one. Henning On Nov 12, 2007, at 3:47 PM, Philip Matthews wrote: > > > On 12-Nov-07, at 15:08 , Henry Sinnreich wrote: > >> The term commonly used in the p2p communities is as a hash >> of >> some data or location. >> >> Is there a problem using ? >> > > There are actually three different concepts to deal with, and the > challenge is to figure out their relationship. > > The first is the Peer ID as defined in the Concepts draft. This ID > uniquely identifies a peer in the overlay. In many DHTs, it also > describes where in the overlay the peer can be found (e.g., Chord > arranges peers in a ring based on their peer ids). > > The second is the local identifier used inside an application to > refer to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all > propose to make this identifier look like an IP address, so that > applications can continue to use the Socket API, which allows many > existing applications to operate without change in an overlay. > > The third is the Host ID as defined by HIP. This ID uniquely > identifies a host in the Internet, and is especially useful in > mobility situation and when nodes are behind NATs. > > > So what is the relationship between these three concepts? > o Does local identifier = peer ID? If yes, then Peer IDs probably > need to be globally unique, not just unique within a overlay, > otherwise you get into problems when a peer is a member of two > different overlays. Globally unique Peer IDs are possible, but > present some challenges. > > o Does Host ID = Peer ID? This is what HIP-HOP-00 proposes. > However, Eric Rescorla argues that this opens up the overlay to > Sybil attacks. > > > Right now, I am personally thinking that three of these are > distinct. However, these questions are listed in the ID/Loc document > as open issues. > > - Philip > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 16:55:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrhFO-0005Pl-ER; Mon, 12 Nov 2007 16:55:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrhFO-0005Pg-1F for p2psip@ietf.org; Mon, 12 Nov 2007 16:55:10 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrhFH-0007FG-OC for p2psip@ietf.org; Mon, 12 Nov 2007 16:55:10 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IrhFE-0004EY-3K; Mon, 12 Nov 2007 22:55:02 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IrhFA-0003H7-Uf; Mon, 12 Nov 2007 22:54:59 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IrhFA-0000kr-I0; Mon, 12 Nov 2007 22:54:56 +0100 Received: from [192.168.2.1] (HSI-KBW-091-089-004-031.hsi2.kabelbw.de [91.89.4.31]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 8FB7E2FC00C; Mon, 12 Nov 2007 22:54:55 +0100 (CET) Message-ID: <4738CBAA.3000902@tm.uka.de> Date: Mon, 12 Nov 2007 22:54:50 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> In-Reply-To: <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: _SUMMARY_ X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: "Zheng, Harold" , Henry Sinnreich , "Cole, Robert G." , "Wang, XiaoXiao \(Sherry\)" , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I don't get the point why using only a single ID is a problem: - "Local identifier = peer ID": If your choose a random (or cryptographic) 128 bit (or better 160 bit) ID, it should be globally unique. Of course there is still the very unlikely chance of a collision, but this can also happen if you use the ID only within one overlay. - "Host ID = Peer ID": To inhibit a Sybil attack you have to limit the generation of IDs (e.g. by using a central authority). But this problem seems to be independent from the fact "Host ID = Peer ID", or do I miss something? Regards, Ingmar Philip Matthews wrote: > > There are actually three different concepts to deal with, and the > challenge is to figure out their relationship. > > The first is the Peer ID as defined in the Concepts draft. This ID > uniquely identifies a peer in the overlay. In many DHTs, it also > describes where in the overlay the peer can be found (e.g., Chord > arranges peers in a ring based on their peer ids). > > The second is the local identifier used inside an application to refer > to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all propose to > make this identifier look like an IP address, so that applications can > continue to use the Socket API, which allows many existing applications > to operate without change in an overlay. > > The third is the Host ID as defined by HIP. This ID uniquely identifies > a host in the Internet, and is especially useful in mobility situation > and when nodes are behind NATs. > > > So what is the relationship between these three concepts? > o Does local identifier = peer ID? If yes, then Peer IDs probably > need to be globally unique, not just unique within a overlay, otherwise > you get into problems when a peer is a member of two different overlays. > Globally unique Peer IDs are possible, but present some challenges. > > o Does Host ID = Peer ID? This is what HIP-HOP-00 proposes. However, > Eric Rescorla argues that this opens up the overlay to Sybil attacks. > > > Right now, I am personally thinking that three of these are distinct. > However, these questions are listed in the ID/Loc document as open issues. > > - Philip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 17:11:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrhUv-00054v-26; Mon, 12 Nov 2007 17:11:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrhUt-00054e-8w for p2psip@ietf.org; Mon, 12 Nov 2007 17:11:11 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrhUs-0005mL-QB for p2psip@ietf.org; Mon, 12 Nov 2007 17:11:11 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id DAE4733C2B; Mon, 12 Nov 2007 14:06:20 -0800 (PST) Date: Mon, 12 Nov 2007 14:06:20 -0800 From: Eric Rescorla To: Ingmar Baumgart Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-Reply-To: <4738CBAA.3000902@tm.uka.de> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071112220620.DAE4733C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , P2PSIP Mailing List , "Zheng, Harold" , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 12 Nov 2007 22:54:50 +0100, Ingmar Baumgart wrote: > > I don't get the point why using only a single ID is a problem: > > - "Local identifier = peer ID": If your choose a random (or > cryptographic) 128 bit (or better 160 bit) ID, it should be globally > unique. Of course there is still the very unlikely chance of a > collision, but this can also happen if you use the ID only within one > overlay. > > - "Host ID = Peer ID": To inhibit a Sybil attack you have to limit the > generation of IDs (e.g. by using a central authority). But this problem > seems to be independent from the fact "Host ID = Peer ID", or do I miss > something? The issue isn't a Sybil attack. It's a chosen location attack. If you choose peer-ids by hashing public keys, then an attacker can choose the top X bits of the peer-id by generating 2^X keys. This doesn't sound bad because the IDs are very long, but the relevant issue isn't the SIZE of the peer ID but rather the distance between peer-IDs as a fraction of the size of the peer-ID space, and that's determined solely by the number of peers. To take a specific case, say you're using 160-bit IDs and the ring has 2^10 (1024) users. On average, each peer will be a distance of 2^150 away from the next peer. Say you want to be between peers X and X+1. If you generate a random key pair and hash it, your chances of getting a value between X and X+1 is approximately 2^-10. So, in order 2^10 trials you can get a value in between those two peers. In general, the number of trials you need scales with the number of peers, but consider that 2^30 is an absurdly large p2p network and yet easily within the brute force limit. Note that this can't be fixed purely by rate limiting at some central authority (though puzzles can help) because the computation is performed completely offline. The fix is to have the central authority dispense peer-ids, but then this breaks the binding between public keys and identities which is one of the major attractions of HIP. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 17:57:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IriDv-00038t-7U; Mon, 12 Nov 2007 17:57:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IriDu-00037f-3e for p2psip@ietf.org; Mon, 12 Nov 2007 17:57:42 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IriDq-0001Wt-RV for p2psip@ietf.org; Mon, 12 Nov 2007 17:57:42 -0500 X-IronPort-AV: E=Sophos;i="4.21,407,1188802800"; d="scan'208";a="415292598" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 12 Nov 2007 14:57:38 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lACMvc9I001900; Mon, 12 Nov 2007 14:57:38 -0800 Received: from [128.107.139.225] (dhcp-128-107-139-225.cisco.com [128.107.139.225]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id lACMvbYe000114; Mon, 12 Nov 2007 22:57:38 GMT In-Reply-To: References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu><4731ED7B.2070901@sip-communicator.org> <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> <009b01c8250e$62a305c0$da07740a@DELLWEI> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <247006B3-44C3-4C0C-9174-57085A506C21@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Proposal for progress on protocols Date: Mon, 12 Nov 2007 14:57:30 -0800 To: Philip Matthews X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=388; t=1194908258; x=1195772258; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Proposal=20for=20progress=20on=20protocols |Sender:=20; bh=Atqzvzj10o85Hwa1w3qDI+C+VRRUzLGH6rKSftrE9Qo=; b=PHQU02gE0xjepPIC+QEx12yTPyg6cvIEEgMXnMTG59u9nmUNZQZrXeamya1PUEreKw+ffTjh RA4mvjfAqSNqQsUbtAz7rl/uxONfFJINCJ1tOqT5YoEaKANBY2+IW2bH; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 12, 2007, at 8:37 AM, Philip Matthews wrote: > However, most (all?) of the currently active proposals are not > considering clients right now. Personally, I think this is because > people are still trying to figure out how peers work. Just as a side note, ASP support clients talking to peers using a subset of the protocol that peers use to talk to each other. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 17:59:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IriFu-0005Ai-SO; Mon, 12 Nov 2007 17:59:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IriFu-00059m-5U for p2psip@ietf.org; Mon, 12 Nov 2007 17:59:46 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IriFt-00086z-LT for p2psip@ietf.org; Mon, 12 Nov 2007 17:59:46 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IriFp-0006MG-6j; Mon, 12 Nov 2007 23:59:44 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IriFl-0003ME-J1; Mon, 12 Nov 2007 23:59:40 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IriFl-0001CA-6d; Mon, 12 Nov 2007 23:59:37 +0100 Received: from [192.168.2.1] (HSI-KBW-091-089-004-031.hsi2.kabelbw.de [91.89.4.31]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 1257D2FC00E; Mon, 12 Nov 2007 23:59:36 +0100 (CET) Message-ID: <4738DADB.305@tm.uka.de> Date: Mon, 12 Nov 2007 23:59:39 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> In-Reply-To: <20071112220620.DAE4733C2B@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Spam-Report: _SUMMARY_ X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , P2PSIP Mailing List , "Zheng, Harold" , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Rescorla wrote: > The issue isn't a Sybil attack. It's a chosen location attack. > > [...] > > Note that this can't be fixed purely by rate limiting at some > central authority (though puzzles can help) because > the computation is performed completely offline. The fix is > to have the central authority dispense peer-ids, but then this > breaks the binding between public keys and identities which > is one of the major attractions of HIP. Thank you for clarifying this. But why does this break the binding between public key and identity? The central authority could generate the public key pair and sign it. In case you don't want the central authority to posses your private key, peers could also generate the key pair on their own - in this case the central authority would impose some kind of online crypto puzzle on public key generation. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 18:12:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IriRw-00006L-4D; Mon, 12 Nov 2007 18:12:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IriRt-0008Rl-0F for p2psip@ietf.org; Mon, 12 Nov 2007 18:12:09 -0500 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IriRs-0008TA-FA for p2psip@ietf.org; Mon, 12 Nov 2007 18:12:08 -0500 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Mon, 12 Nov 2007 15:12:03 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lACNC1Kn006571; Mon, 12 Nov 2007 15:12:01 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lACNC0FV017190; Mon, 12 Nov 2007 15:12:00 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Nov 2007 15:11:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Mon, 12 Nov 2007 15:11:27 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE295@namail5.corp.adobe.com> In-Reply-To: <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Thread-Index: AcglbQ1PdP3H4URFQEafmDhmuM03IAAE2GuQ References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" X-OriginalArrivalTime: 12 Nov 2007 23:11:59.0891 (UTC) FILETIME=[6D8B3E30:01C82581] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: "Zheng, Harold" , "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Phil, This is a good item to clarify:=20 A node ID can be the hash of a location in the DHT space (with a name and URL) or a hash of some data, such as a voice mail sound file or a buddy list.=20 The key is that both locations and data items are placed in the same hash space and identified there with the node ID. What have the authors of the concept draft and everyone else to say here? Some well wordsmithed text and examples would be very welcome here. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Monday, November 12, 2007 2:47 PM To: Henry Sinnreich Cc: Wang, XiaoXiao (Sherry); P2PSIP Mailing List; Zheng, Harold; Cole,Robert G. Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP On 12-Nov-07, at 15:08 , Henry Sinnreich wrote: > The term commonly used in the p2p communities is as a hash of > some data or location. > > Is there a problem using ? > There are actually three different concepts to deal with, and the =20 challenge is to figure out their relationship. The first is the Peer ID as defined in the Concepts draft. This ID =20 uniquely identifies a peer in the overlay. In many DHTs, it also =20 describes where in the overlay the peer can be found (e.g., Chord =20 arranges peers in a ring based on their peer ids). The second is the local identifier used inside an application to =20 refer to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all =20 propose to make this identifier look like an IP address, so that =20 applications can continue to use the Socket API, which allows many =20 existing applications to operate without change in an overlay. The third is the Host ID as defined by HIP. This ID uniquely =20 identifies a host in the Internet, and is especially useful in =20 mobility situation and when nodes are behind NATs. So what is the relationship between these three concepts? o Does local identifier =3D peer ID? If yes, then Peer IDs probably =20 need to be globally unique, not just unique within a overlay, =20 otherwise you get into problems when a peer is a member of two =20 different overlays. Globally unique Peer IDs are possible, but =20 present some challenges. o Does Host ID =3D Peer ID? This is what HIP-HOP-00 proposes. =20 However, Eric Rescorla argues that this opens up the overlay to Sybil =20 attacks. Right now, I am personally thinking that three of these are distinct. =20 However, these questions are listed in the ID/Loc document as open =20 issues. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 18:46:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrizD-00080H-4v; Mon, 12 Nov 2007 18:46:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrizB-0007xz-IH for p2psip@ietf.org; Mon, 12 Nov 2007 18:46:33 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iriz7-00032c-PA for p2psip@ietf.org; Mon, 12 Nov 2007 18:46:33 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 73AE233C2B; Mon, 12 Nov 2007 15:41:39 -0800 (PST) Date: Mon, 12 Nov 2007 15:41:38 -0800 From: Eric Rescorla To: Ingmar Baumgart Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-Reply-To: <4738DADB.305@tm.uka.de> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071112234139.73AE233C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , "Zheng, Harold" , Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 12 Nov 2007 23:59:39 +0100, Ingmar Baumgart wrote: > > Eric Rescorla wrote: > > The issue isn't a Sybil attack. It's a chosen location attack. > > > > [...] > > > > Note that this can't be fixed purely by rate limiting at some > > central authority (though puzzles can help) because > > the computation is performed completely offline. The fix is > > to have the central authority dispense peer-ids, but then this > > breaks the binding between public keys and identities which > > is one of the major attractions of HIP. > > Thank you for clarifying this. But why does this break the binding > between public key and identity? > > The central authority could generate the public key pair and sign it. In > case you don't want the central authority to posses your private key, > peers could also generate the key pair on their own - in this case the > central authority would impose some kind of online crypto puzzle on > public key generation. So, the idea in HIP is to let the node self-generate their own identity by generating a random cryptographic key and then using the digest of the key as an identifier. This allows for a strong binding between the identifier and your cryptographic keying material without any central authority, because it's impractical for an attacker to generate another key with the same identifier. So, as long as you can get your hands on the identifier securely, the system doesn't need a central authority. The reason this doesn't work in P2P systems is that it's not sufficient to force the attacker not to generate a *specific* digest postimage, but rather you need to stop them from generating a range of postimages, which radically reduces the complexity of the problem. The system you describe has a central authority. At that point, there's no value in having the peer-id derived from the key because you need to certificate to validate the key. You might as well just shove the peer-id in the cert. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 20:36:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrkhY-00055f-RU; Mon, 12 Nov 2007 20:36:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrkhW-0004w4-O1 for p2psip@ietf.org; Mon, 12 Nov 2007 20:36:27 -0500 Received: from mu-out-0910.google.com ([209.85.134.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrkhS-00065P-Ps for p2psip@ietf.org; Mon, 12 Nov 2007 20:36:26 -0500 Received: by mu-out-0910.google.com with SMTP id i10so1644986mue for ; Mon, 12 Nov 2007 17:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; bh=Q8CIJJXf/CvREdgfU4dXRPxUDx3gBSfoJSvjruTOrBw=; b=bM424+FC15O6j0gBha4JOnrFXKuKIpg02n7DbY82HkDM1uRRoePfTniER+Fke9jxr0pXQ/SWt3kCesuBbUb5OnNi/UlNSKcvQQufbQP1+4fEQ8aSF9je0XVmO/CF7azZw1Vpnb5RA+dzJh+Y9D5hHZSqEyWPoE6EEE2B3pr7sSs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:in-reply-to:thread-index; b=UCLnpzCZHyBMO2z3VtmYTbUKXK+iMPIhTQh6ftD41ZeA1FndAupzSRgf/1xWSQtgaqQRzrmqSJdtv3mVNOdYzGxE6tP80sZ+u2gcb41sOoz8MX0sux7bCwsmXOZGO2SyCzPcjPt60T0aUjIgVsMFQ8EadWPArEQY1Dgy27fBj78= Received: by 10.65.225.7 with SMTP id c7mr6626685qbr.1194917780873; Mon, 12 Nov 2007 17:36:20 -0800 (PST) Received: from mlifewangyao ( [123.116.128.44]) by mx.google.com with ESMTPS id 14sm770641nzp.2007.11.12.17.36.10 (version=SSLv3 cipher=RC4-MD5); Mon, 12 Nov 2007 17:36:16 -0800 (PST) From: "Yao Wang" To: "'Philip Matthews'" , "'Wei Gengyu'" Subject: Re: [P2PSIP] Proposal for progress on protocols Date: Tue, 13 Nov 2007 09:36:53 +0800 Message-ID: <000b01c82595$b47bdbb0$9a00a8c0@mlifewangyao> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcglSpqAntfPNmXETpuoLv9QbwjgZwARcIaw X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Philip and folks Some comments to your points. "If you are interested in just SIP, then this is an excellent = suggestion. However, if you are interested in protocols other than SIP, = then this idea doesn't work." Personally, I think the relationship between SIP and other protocols is = complementary rather than conflictive. SIP can be utilized to exchange = information, such as the detailed parameters of other services other = than SIP, between clients and peers. If a client is interested in a = service which is provided by a particular protocol not SIP, this client = could get the detailed parameters for accessing the service using SIP, = for example, if the client want to access FTP services in P2PSIP = Overlay, it can get the IP address, port number, available user name = and(or) password, etc. In this example, after getting all these = parameters, the client can access the service using FTP. SIP is used for = service location and the other protocols are used for providing = particular services. Therefore, that relationship between SIP and other = protocols is complementary rather than conflictive.=20 Of course, a completely new protocol can be used for this function, but = SIP has been widely used, why not reuse it?=20 One possible way to implement this is by extending SIP with new Sip = Event Packages. We have submitted a new draft, named as "A SIP-based = P2PSIP Client Protocol" = (http://www.ietf.org/internet-drafts/draft-li-p2psip-client-protocol-00.t= xt) In this draft, we explained our viewpoints on the functions of = P2PSIP client and some key requirements on the proposed client protocol. =09 Comments are always welcomed. Sincerely yours, =20 Yao Wang=20 Mobile Life New Media Lab, BUPT -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Tuesday, November 13, 2007 12:38 AM To: Wei Gengyu Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols On 12-Nov-07, at 04:28 , Wei Gengyu wrote: > Hi, all > > I have a question. > > A peer in a P2PSIP overlay can be the proxy of a mobile client. > Could SIP(rfc3261) be used between the client and the proxy Peer =20 > instead of defining a new protocol? This is in fact a long-running proposal. The answer to this question depends on whether you are interested in =20 using a P2PSIP overlay for just SIP, or whether you think our work =20 should be more general. If you are interested in just SIP, then this =20 is an excellent suggestion. However, if you are interested in =20 protocols other than SIP, then this idea doesn't work. Up until about Jan 2007, most of the active players in this group =20 seemed to be primarily interested in just SIP. However, this year has =20 seen a rise in interest in non-SIP usages. However, most (all?) of the currently active proposals are not =20 considering clients right now. Personally, I think this is because =20 people are still trying to figure out how peers work. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 20:44:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrkpW-0007IH-KB; Mon, 12 Nov 2007 20:44:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrkpU-0007CK-QN for p2psip@ietf.org; Mon, 12 Nov 2007 20:44:40 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrkpT-0004tQ-7C for p2psip@ietf.org; Mon, 12 Nov 2007 20:44:40 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF008IY8U9FB@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 09:44:33 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF008EB8U66G@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 09:44:33 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRF00J5F8U3FJ@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 09:44:30 +0800 (CST) Date: Tue, 13 Nov 2007 09:44:26 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Proposal for progress on protocols In-reply-to: <005401c8253c$06417e00$da07740a@DELLWEI> To: 'Wei Gengyu' Message-id: <016c01c82596$b9a32ca0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: AcglPAkKBDFqSGcJRLyG8TU2M+OVDgAVl0eA X-Spam-Score: 0.0 (/) X-Scan-Signature: be922d419820e291bde1362184dc32fd Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline.... Best regards, Hewen -----Original Message----- =46rom: Wei Gengyu [mailto:weigengyu@vip.sina.com] Sent: 2007=C4=EA11=D4=C212=C8=D5 22:55 To: Zheng Hewen Cc: p2psip@ietf.org Subject: Re: [P2PSIP] Proposal for progress on protocols Hi, SIP has been widely used between SIP client and proxy or servers, and= it is easy to get some testbed results. And we have to see the fact that there are many mobile terminals inst= alled with SIP UA. When considering the mobile terminal as a client of P2PSIP overlay, t= he SIP protocol is cheap and suitable. [Hewen] You are right. If a peer acts as SIP proxy, then the unmodifi= ed SIP protocol can completely act as the communication protocol between the peer and its associated clients, at this time, a= client protocol is not necessary. If a peer does not couple with any SIP entity as in Reference model, a client protocol i= s desire and SIP is not the choice since the peer Does Not couple with a SIP entity. P2PSIP is used in the other scenarios b= esides mobile communication, do you think so? A suite of general P2PSIP protocols should be preferred. In IETF69, it is con= sensus that separate P2P layer is preferred than extending SIP considering some known limitation of extension of SIP p= rotocol. While in "Concepts and Terminology for Peer to Peer SIP draft-willis-= p2psip-concepts-04" or "Concepts and Terminology for Peer to Peer SIP" (draft-ietf-p2psip= -concepts-00), "An overlay may or may not also include one or more nodes called P2PSIP Clients. The role of a client in the P2PSIP model is still under discussion, with a number of suggestions for roles being put forth, and some arguing that clients are not needed at all. Howev= er, if they exist, then people agree that they will also be able to st= ore and retrieve information from the overlay. Section 5.5 discusses = the possible roles of a client in more detail." In section 5.5: "In one alternative, a client interacts with the P2PSIP overlay through an associated peer (or perhaps several such peers) using t= he Client Protocol. The client does not run the distributed database algorithm, does not store resource records, and is not involved in routing messages to other peers or clients. Though interactions w= ith its associated peer, a client can insert, modify, examine, and rem= ove resource records. A client can also send SIP messages to its associated peer for routing through the overlay. In this alternative, a client is a node that wants to take advantage of th= e overlay, but is unable or unwilling to contribute resources back t= o the overlay. One way to realize this alternative is for a peer to behave as [RFC3261] proxy/registrar. Clients then use standard SIP mechanis= ms to add, update, and remove registrations and to send SIP messages = to peers and other clients. If this is done, there is no need for a separate Client Protocol and no need for P2PSIP to define a distin= ct "P2PSIP Client" concept." And there are also second and third alternatives. [Hewen] The original Concept document need modification, IMHO, it is = primitive somewhere, the definition of a client character from the Reference model is clear, but the Section 5.5 desc= ribes some confused behaviors. In detail, the first alternative potentially that the peer couples with a SIP entity(proxy= /registrar), hence SIP protocol is enough and a client protocol is not necessary, at the same time any extension of SIP prot= ocol is not necessary, but P2PSIP provides an alternative to the SIP discovery process of RFC 3263, it means that a= SIP entity is not mandatory for a peer, the true requirement for a client protocol between a peer without any SIP enti= ty and a client with a SIP UA; the second alternative requests a client can contribute its storage capacity to its associat= ed peer, in this scenario, if SIP is adopted as the underlying protocol for the client protocol, we have to extend SIP pr= otocol, but the extension is limited/prohibited by RFC4485. The third alternative is strange, it thinks that a client ha= s a "Peer-ID", but in IETF69, we think that a client is a non-overlay-routing node (e.g., the P2PSIP overlay is transparent t= o any client). In summary, for a client protocol between a peer and its associated clients, we only need to think abou= t two scenarios: (1). the interaction between a peer without any SIP entity and a client with SIP UA; (2). a client contri= butes its storage capacity to its associated peer, and at the same time, SIP is already not a choice. We need to update Sect= ion 5.5 in Concept document according to the Reference model. My opinion is that adopting SIP between the client and the associated= proxy Peer will be simplify the facilities to support mobile clients in the reference model. Best regards, Gengyu ----- Original Message ----- =46rom: "Zheng Hewen" To: "'Wei Gengyu'" ; Cc: Sent: Monday, November 12, 2007 6:52 PM Subject: RE: [P2PSIP] Proposal for progress on protocols > > Hi, > > In my understanding according to P2PSIP Reference model defined = in "Concepts and Terminology for Peer to Peer SIP" > (draft-ietf-p2psip-concepts-00), SIP is not eligible to act as a co= mmunication protocol between a peer and its associated > clients. > Further, in detail, considering those reasons as below, SIP is n= ot eligible to be chosen as the signal underlying > protocol of P2PSIP client protocol: > (1). SIP does not exist between a client and its associated peer = at some scenarios. > According to P2PSIP Overlay Reference Model depicted in Figure 1 = in "Concepts and Terminology for Peer to Peer SIP" > (draft-ietf-p2psip-concepts-00), P2PSIP client protocol runs betwee= n a peer without any SIP entity and a client with a SIP > entity, the peer does not recognize SIP protocol, SIP is not eligib= le to act as the signal underlying protocol of P2PSIP > client protocol. > > (2). SIP is not a general Remote Procedure Call (RPC). > A P2PSIP client protocol on top of SIP acts as a remote procedure= call (RPC) mechanism. The SIP guidelines document > [RFC4485] prohibits the use of SIP as a RPC mechanism. > > (3). SIP is not a general purpose transfer protocol. > One of P2PSIP client protocol main tasks is to transfer resource = object and its content, those contents is irrelevant to > SIP. SIP's operation and the SIP guideline document [RFC4485] proh= ibit sending large amounts of data unrelated to SIP's > operation. > > (4). SIP is not a lookup protocol. > SIP is not a lookup protocol; it relies on DNS to locate an appro= priate SIP server. Insert and lookup functionality is > essential for any P2PSIP client protocol. Using SIP as a peer-to-p= eer protocol requires integrating lookup functionality > into SIP which goes against its design philosophy. > > Best regards, > Hewen > > -----Original Message----- > From: Wei Gengyu [mailto:weigengyu@vip.sina.com] > Sent: 2007?11?12? 17:28 > To: marcin.matuszewski@nokia.com > Cc: p2psip@ietf.org > Subject: Re: [P2PSIP] Proposal for progress on protocols > > Hi, all > > I have a question. > > A peer in a P2PSIP overlay can be the proxy of a mobile client. > Could SIP(rfc3261) be used between the client and the proxy Peer in= stead of defining a new protocol? > > Best regards, > > Gengyu > > ----- Original Message ----- > From: > To: ; > Sent: Thursday, November 08, 2007 5:28 PM > Subject: RE: [P2PSIP] Proposal for progress on protocols > > > Hi all, > > I agree with Henning's proposal. There is another issue: support fo= r > clients. > > I can to volunteer for "mobility" or "support for clients". > > Marcin > >>-----Original Message----- >>From: ext Emil Ivov [mailto:emcho@sip-communicator.org] >>Sent: 07 November, 2007 18:53 >>To: P2PSIP Mailing List >>Subject: Re: [P2PSIP] Proposal for progress on protocols >> >>Henning, all, >> >>I think this is definitely the way to go and both Enrico and I >>(as authors of one of the proposals) would be happy to >>contribute on any of the points in your list. We also thought >>that there are two other issues that would probably require >>some consideration: >> >>- DHT upgrades - as far as I can see, it is currently most >>covered by ASP, but the general opinion in Chicago seemed to >>be that this is indeed an important issue that would have to >>be addressed by the peer protocol. >> >>- Mobility - taking mobility into account would probably >>influence some of the design choices (underlying protocol, >>session flexibility, etc..) so it might be worth to try and >>see to what extent would the existing proposals fit mobile nodes. >> >>One last thing. We should probably try and start having some >>of these discussions before the meeting or, even better, to >>find some way to foster offline work on each topic, since they >>are likely to require more than the time we'll have there. I >>guess that Philip's presentation in Chicago was made with the >>same intentions, but it was pretty clear that the time we had >>was insufficient for any meaningful discussions. >> >>Cheers >>Emil >> >>Henning Schulzrinne wrote: >>> I'd like to propose a mechanism to make progress on converging on= a >>> protocol. My high-level impression is that most of the >>proposals, with >>> the exception of the HIP-based ones, are philosophically not >>that far >>> removed, and the differences are more at the mechanical >>level. One way >>> to make progress would be to identify some of the major pieces, a= nd >>> then, in Vancouver, systematically go through them. An initial li= st, >>> definitely incomplete, includes >>> >>> - packet format >>> - NAT traversal for p2p messages (not media or SIP signaling) >>> - channel security for p2p messages >>> - recursion vs. iterative >>> - hash algorithm negotiation and usage >>> >>> One possibility is to identify a volunteer for each area, so >>that the >>> task is more manageable. If there are major philosophical >>differences, >>> we should probably discuss those first, however. >>> >>> Henning >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >>> >> >>_______________________________________________ >>P2PSIP mailing list >>P2PSIP@ietf.org >>https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 21:00:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irl4i-0002tt-CS; Mon, 12 Nov 2007 21:00:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irl4g-0002q0-QO for p2psip@ietf.org; Mon, 12 Nov 2007 21:00:22 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irl4g-0005TM-4y for p2psip@ietf.org; Mon, 12 Nov 2007 21:00:22 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF00D8Y9KGU8@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:00:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF00DOS9KFBI@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:00:16 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRF005339KCN9@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:00:15 +0800 (CST) Date: Tue, 13 Nov 2007 10:00:11 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Proposal for progress on protocols In-reply-to: To: 'Philip Matthews' , 'Wei Gengyu' Message-id: <016d01c82598$ed108a40$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcglSj2FoT+bM+9ERFyjfFijgHegNQATKXlg X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline... Best regards, Hewen -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: 2007?11?13? 0:38 To: Wei Gengyu Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols On 12-Nov-07, at 04:28 , Wei Gengyu wrote: > Hi, all > > I have a question. > > A peer in a P2PSIP overlay can be the proxy of a mobile client. > Could SIP(rfc3261) be used between the client and the proxy Peer > instead of defining a new protocol? This is in fact a long-running proposal. The answer to this question depends on whether you are interested in using a P2PSIP overlay for just SIP, or whether you think our work should be more general. If you are interested in just SIP, then this is an excellent suggestion. However, if you are interested in protocols other than SIP, then this idea doesn't work. [Hewen] Agree. Up until about Jan 2007, most of the active players in this group seemed to be primarily interested in just SIP. However, this year has seen a rise in interest in non-SIP usages. However, most (all?) of the currently active proposals are not considering clients right now. Personally, I think this is because people are still trying to figure out how peers work. [Hewen]IMHO, a P2PSIP client character is more simple and clear than a peer, we can clarify the P2PSIP client definition and character according to the explicit Reference Model in Concept document, in my memory, some proposals such as P2PP, RELOAD and ASP mention even describe the behavior of a P2PSIP client. Essentially, the explicit definition of a P2PSIP client can help to clarify and define the functions of P2PSIP peer protocol, I think that most of players in this group do not want to continue to see the chaos about the definition of P2PSIP peer and client. At least we can reach the agreement about P2PSIP client character according to the Reference model before completing standardization of P2PSIP peer protocol. Any comment? [Hewen]Here are info about P2PSIP client protocol in some Peer protocol. "Clients can use overlay services through peers. Multiple clients can participate in the overlay through one peer but clients can also communicate with multiple peers at the same time. Client and peers communicate using the same protocol as peers do, i.e., there is no distinct protocol for client-to-peer and peer-to-peer communication. ..." "In this architecture, no P2PSIP Client Protocol is needed, rather unmodified SIP is used for access by non-peers." "A P2P signaling protocol provides its clients with an abstract hash table service between a set of cooperating peers that form the P2P network. ..." - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 21:08:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlCg-00027O-4X; Mon, 12 Nov 2007 21:08:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlCf-00027E-BM for p2psip@ietf.org; Mon, 12 Nov 2007 21:08:37 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrlCe-0005mm-QR for p2psip@ietf.org; Mon, 12 Nov 2007 21:08:37 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF00DZR9YBU8@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:08:35 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF00LYE9YAAX@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:08:35 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRF00J3D9Y7FJ@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:08:34 +0800 (CST) Date: Tue, 13 Nov 2007 10:08:31 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Proposal for progress on protocols In-reply-to: <8E01D862-DC31-4889-B427-C7B53FD86589@magma.ca> To: 'Philip Matthews' Message-id: <016e01c8259a$16b26340$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcglSpNZQnrlj1tCRgW6evnXjfXL4gAToSrQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline... Best regards, Hewen -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: 2007?11?13? 0:40 To: Zheng Hewen Cc: 'Wei Gengyu'; marcin.matuszewski@nokia.com; p2psip@ietf.org Subject: Re: [P2PSIP] Proposal for progress on protocols On 12-Nov-07, at 06:01 , Zheng Hewen wrote: > > In my opinion, maybe P2PSIP client protocol does not emerge as a > distinct protocol at last, for example, it emerge a subset of P2PSIP > peer protocol. The WG has agreed that, _if_ there is a client protocol, then it should be a logical subset of the peer protocol. Here logical means that it may have different syntax, but you cannot do more as a client than you can as a peer. [Hewen]Thanks for you mention first. As you said, we all must abide the agreed WG charter once it is determined^_^ A new distinct client protocol may not be necessary, but as a subset of the Peer protocol, some semantic extension of Peer protocol for the communication protocol between a client and its associated peer may be desired after clarifying the P2PSIP client character. I think that a distinct document is desired to clarify the functions of the communication protocol between a client and its associated peer. This is documented in the Concepts draft. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 21:16:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlK4-0007DX-AM; Mon, 12 Nov 2007 21:16:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlK2-00078z-Pk for p2psip@ietf.org; Mon, 12 Nov 2007 21:16:14 -0500 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrlK0-0007Hf-78 for p2psip@ietf.org; Mon, 12 Nov 2007 21:16:14 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1029973nzf for ; Mon, 12 Nov 2007 18:16:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; bh=jdSMToQrmU26OsNYDVMN8EMdPEoCTrJbZMaoPCLjTes=; b=b50jXeyZ4Ea8wb/fN98gR6plwwTeLjPbWFYH41NfO/GCWCifKw1CmLrNY5JPF5Uehpjpm/bqJqivCHpFKETf9NE354Ax62vgv1HldJya+sNCKBo8Wq7NMlUcZt4n9tW9gCFTBHZ+xpTXaldNvm5EQrsfZ65lIGgt9oJ/wEDqpqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=svANwpQXSCOZ0nKRmS2ncuAIrhfa0iPzDitL/1l/a/J2kCbr3xZg887LnmeG7XcmIEOLOiLH6J56FHM4SaafRGeCxjHYHTBHEN7myceEfc7LZjNg+1hmBmeAdza05QkPKbnt/3FI7CZFGXhYpg/hTAt4COAInPNfFvMzOGzwo9U= Received: by 10.115.76.1 with SMTP id d1mr75909wal.1194920168168; Mon, 12 Nov 2007 18:16:08 -0800 (PST) Received: from mlifewangyao ( [123.116.128.44]) by mx.google.com with ESMTPS id n40sm8496570wag.2007.11.12.18.16.04 (version=SSLv3 cipher=RC4-MD5); Mon, 12 Nov 2007 18:16:06 -0800 (PST) From: "Yao Wang" To: "'Zheng Hewen'" , "'Philip Matthews'" , "'Wei Gengyu'" Subject: RE: [P2PSIP] Proposal for progress on protocols Date: Tue, 13 Nov 2007 10:16:45 +0800 Message-ID: <000001c8259b$455a17f0$9a00a8c0@mlifewangyao> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: <016d01c82598$ed108a40$5105a40a@china.huawei.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcglSj2FoT+bM+9ERFyjfFijgHegNQATKXlgAADPXvA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Agree on "At least we can reach the agreement about P2PSIP client = character according to the Reference model before completing = standardization of P2PSIP peer protocol" In my opinion, a document specifying the exact characters of P2PSIP = Client and the requirements of P2PSIP Client Protocol based on the = consensus of this WG is needed before the standardization of client = protocol and peer protocol. Sincerely yours, =20 Yao Wang=20 Mobile Life New Media Lab, BUPT -----Original Message----- From: Zheng Hewen [mailto:hwzheng@huawei.com]=20 Sent: Tuesday, November 13, 2007 10:00 AM To: 'Philip Matthews'; 'Wei Gengyu' Cc: 'P2PSIP Mailing List' Subject: RE: [P2PSIP] Proposal for progress on protocols Hi, Please see inline... Best regards, Hewen -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: 2007?11?13? 0:38 To: Wei Gengyu Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols On 12-Nov-07, at 04:28 , Wei Gengyu wrote: > Hi, all > > I have a question. > > A peer in a P2PSIP overlay can be the proxy of a mobile client. > Could SIP(rfc3261) be used between the client and the proxy Peer > instead of defining a new protocol? This is in fact a long-running proposal. The answer to this question depends on whether you are interested in = using a P2PSIP overlay for just SIP, or whether you think our work should be more general. If you are interested in just = SIP, then this is an excellent suggestion. However, if you are interested in protocols other than SIP, then this idea doesn't = work. [Hewen] Agree. Up until about Jan 2007, most of the active players in this group seemed = to be primarily interested in just SIP. However, this year has seen a rise in interest in non-SIP usages. However, most (all?) of the currently active proposals are not = considering clients right now. Personally, I think this is because people are still trying to figure out how peers work. [Hewen]IMHO, a P2PSIP client character is more simple and clear than a = peer, we can clarify the P2PSIP client definition and character according to the explicit Reference Model in Concept document, = in my memory, some proposals such as P2PP, RELOAD and ASP mention even describe the behavior of a P2PSIP client. = Essentially, the explicit definition of a P2PSIP client can help to clarify and define the functions of P2PSIP peer protocol, I = think that most of players in this group do not want to continue to see the chaos about the definition of P2PSIP peer and = client. At least we can reach the agreement about P2PSIP client character according to the Reference model before completing = standardization of P2PSIP peer protocol. Any comment? [Hewen]Here are info about P2PSIP client protocol in some Peer protocol. "Clients can use overlay services through peers. Multiple clients = can participate in the overlay through one peer but clients can also communicate with multiple peers at the same time. = Client and peers communicate using the same protocol as peers do, i.e., there is no distinct protocol for client-to-peer and = peer-to-peer communication. ..." "In this architecture, no P2PSIP Client Protocol is needed, = rather unmodified SIP is used for access by non-peers." "A P2P signaling protocol provides its clients with an abstract = hash table service between a set of cooperating peers that form the P2P network. ..." - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 21:19:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlNe-0002wP-BA; Mon, 12 Nov 2007 21:19:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlNd-0002wK-Ix for p2psip@ietf.org; Mon, 12 Nov 2007 21:19:57 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrlMN-00068U-SE for p2psip@ietf.org; Mon, 12 Nov 2007 21:19:57 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF0081KAEUFB@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:18:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF00LS7AESLL@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:18:30 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRF00GZ6AEPZN@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:18:28 +0800 (CST) Date: Tue, 13 Nov 2007 10:18:25 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Proposal for progress on protocols In-reply-to: To: 'Philip Matthews' Message-id: <017801c8259b$78957b00$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcglS0A08OpKiKvwSOirq0C3MkKy+wATvSaw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please forgive my repeat and straight expression first. The original Concept document needs some modification especially on the description of P2PSIP client behaviors. IMHO, it is primitive somewhere, the definition of a client character from the Reference model is clear, but the Section 5.5 describes some confused behaviors. In detail, the first alternative potentially that the peer couples with a SIP entity(proxy/registrar), hence SIP protocol is enough and a client protocol is not necessary (as said in RELOAD proposal), at the same time any extension of SIP protocol is not necessary , but P2PSIP provides an alternative to the SIP discovery process of RFC 3263, it means that a SIP entity is not mandatory for a peer, the true requirement for a client protocol between a peer without any SIP entity and a client with a SIP UA. The second alternative requests a client can contribute its storage capacity to its associated peer, in this scenario, if SIP is adopted as the underlying protocol for the client protocol, we have to extend SIP protocol, but the extension is limited/prohibited by RFC4485. The third alternative is strange, it thinks that a client has a "Peer-ID", but in IETF69, we think that a client is a non-overlay-routing node (e.g., the P2PSIP overlay is transparent to any client). In summary, for a communication protocol (i.e., client protocol) between a peer and its associated clients, we only need to think about two scenarios: (1). the interaction between a peer without any SIP entity and a client with SIP UA; (2). a client contributes its storage capacity to its associated peer, and at the same time, SIP is already not a choice. We need to update Section 5.5 in Concept document according to the Reference model, (1). If the peer couple with SIP entity, SIP protocol is enough and at the same time the P2PSIP client protocol also works; (2).If the peer does not couple with any SIP entity, a P2PSIP client protocol is desired, and at the same time, a client can contribute its storage capacity to its associated peer. The P2PSIP overlay network is transparent to any P2PSIP client, a P2PSIP client is non-overlay-routing node. Best regards, Hewen -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: 2007?11?13? 0:45 To: Zheng Hewen Cc: 'Victor Pascual ??vila'; p2psip@ietf.org Subject: Re: [P2PSIP] Proposal for progress on protocols On 12-Nov-07, at 07:47 , Zheng Hewen wrote: > I suggest that we could adopt P2PSIP Reference Model defined in > draft-ietf-p2psip-concepts-00 as the primitive baseline to reach a > consensus and update the concepts document. I don't understand what you are suggesting. The Reference Model in section 3 of draft-ietf-p2psip-concepts-00 is supposed to reflect current group consensus. That means it is _already_ adopted, and the Concepts draft is _already_ up-to-date on this issue. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 21:24:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlSI-0001ER-Nw; Mon, 12 Nov 2007 21:24:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlSH-00017s-0x for p2psip@ietf.org; Mon, 12 Nov 2007 21:24:45 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrlP4-0006Fo-IF for p2psip@ietf.org; Mon, 12 Nov 2007 21:24:44 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF00DKAAJLU8@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:21:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF00KTJAJKZ9@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:21:21 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRF00GV9AJHZN@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:21:20 +0800 (CST) Date: Tue, 13 Nov 2007 10:21:17 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] Proposed term: "Responsible Peer" In-reply-to: To: 'Philip Matthews' , 'P2PSIP Mailing List' Message-id: <017901c8259b$df4e0510$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcglWRaCrLUraMWVQqaSueIzbl2+OwAQsW7A X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Support. -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: 2007?11?13? 2:24 To: P2PSIP Mailing List Subject: [P2PSIP] Proposed term: "Responsible Peer" Folks: I have been reviewing the mailing list again in preparation to revise the Concepts draft for this IETF cycle. As I said in an earlier e- mail message: http://www1.ietf.org/mail-archive/web/p2psip/current/msg02973.html the authors don't see a big revision this time, preferring to wait until the various active proposals come closer together. However, one change that has been discussed on the mailing list was a term for the peer which is responsible for storing the resource record for a given resource. I saw two terms were proposed on the mailing list and in private e-mails around this topic: "Responsible Peer" and "Root Peer". The authors currently feel that the term "Responsible Peer" would be a better choice, while recogizing that the term "Root Peer" is also used in the literature. So I am proposing the following text for the next revision of the Concepts draft: P2PSIP Responsible Peer: The Peer that is responsible for storing the Resource Record for a Resource. In the literature, the term "Root Peer" is also used for this concept. Comments? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 21:32:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlZT-0004Df-Bg; Mon, 12 Nov 2007 21:32:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrlZQ-00044c-9T for p2psip@ietf.org; Mon, 12 Nov 2007 21:32:08 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrlZJ-0007oc-FA for p2psip@ietf.org; Mon, 12 Nov 2007 21:32:08 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF007EAB13CH@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:31:51 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF00HH5B0HB2@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:31:51 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRF00JY3B0DFJ@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:31:29 +0800 (CST) Date: Tue, 13 Nov 2007 10:31:25 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-reply-to: To: 'Henning Schulzrinne' , 'Philip Matthews' Message-id: <017a01c8259d$49c660d0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acglbx5MJVcOE294S3Kx0N46fhhBwgALiq1A X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: "'Zheng, Harold'" , 'Henry Sinnreich' , "'Cole, Robert G.'" , "'Wang, XiaoXiao \(Sherry\)'" , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: 2007?11?13? 5:00 To: Philip Matthews Cc: Zheng, Harold; Henry Sinnreich; Cole, Robert G.; Wang, XiaoXiao (Sherry); P2PSIP Mailing List Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP The notion of using the IP stack transparently seems dubious, as this would require quite a few restrictions on the identifier, leaving issues of how to implement this aside. I'm also doubting that this is useful, since we really do not want to route all packets through the overlay, only the first one, for efficiency reasons. On the numbering issue: The numbering space would have to exclude - the RFC 1918 ranges - the local address ranges (since routing would likely direct this to the local interface and bypass routing) - class E addresses The socket call would have to say "this is a real IPv4/IPv6 address, not an overlay address". How? If you designate this as a different protocol, in parallel to IPv4 and IPv6, you could just as well use a node ID of any length. Thus, I'm not convinced that this is a useful goal for an overlay network. Even if it can be done, all it accomplishes is making packets take ten hops across the Internet instead of one. Henning On Nov 12, 2007, at 3:47 PM, Philip Matthews wrote: > > > On 12-Nov-07, at 15:08 , Henry Sinnreich wrote: > >> The term commonly used in the p2p communities is as a hash >> of some data or location. >> >> Is there a problem using ? >> > > There are actually three different concepts to deal with, and the > challenge is to figure out their relationship. > > The first is the Peer ID as defined in the Concepts draft. This ID > uniquely identifies a peer in the overlay. In many DHTs, it also > describes where in the overlay the peer can be found (e.g., Chord > arranges peers in a ring based on their peer ids). > > The second is the local identifier used inside an application to refer > to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all propose to > make this identifier look like an IP address, so that applications can > continue to use the Socket API, which allows many existing > applications to operate without change in an overlay. > > The third is the Host ID as defined by HIP. This ID uniquely > identifies a host in the Internet, and is especially useful in > mobility situation and when nodes are behind NATs. > > > So what is the relationship between these three concepts? > o Does local identifier = peer ID? If yes, then Peer IDs probably > need to be globally unique, not just unique within a overlay, > otherwise you get into problems when a peer is a member of two > different overlays. Globally unique Peer IDs are possible, but > present some challenges. > > o Does Host ID = Peer ID? This is what HIP-HOP-00 proposes. > However, Eric Rescorla argues that this opens up the overlay to > Sybil attacks. > > > Right now, I am personally thinking that three of these are > distinct. However, these questions are listed in the ID/Loc document > as open issues. > > - Philip > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 21:36:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irle6-0001tQ-GM; Mon, 12 Nov 2007 21:36:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irle5-0001sF-LZ for p2psip@ietf.org; Mon, 12 Nov 2007 21:36:57 -0500 Received: from rn-out-0910.google.com ([64.233.170.189] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irle2-00083B-LM for p2psip@ietf.org; Mon, 12 Nov 2007 21:36:57 -0500 Received: by rn-out-0102.google.com with SMTP id a46so730481rne for ; Mon, 12 Nov 2007 18:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=HvSsjEQGvrePp2hL6EOGuKtZNEEtJ2MigtxZm4eb4CM=; b=oSKYSy0lRoH6BxwMxKMvRD9cOOihobXYq3qxhoLC4c0/JUVn/ScSDocXezUs5leGEKq7wCeWs10rnZKQ4SwOHUIQXH8KXK8gV4InhsipxFlAY1bKGACuanuGsw5cTQY/7aiqa/BdgHTVgeQuS5hUwj/8thGej8H0DdKqUgEjFEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=NGVAJHGasdvtOnVm/0WLwSfdX9vdpWc/cNNcJvGnrBIf4ulmU+p1Cobgxdt9Q3/Hz5bza5PD9/Zmo+lWgE/Vwp3pm8u7IzNalpeKCuSnJ9+cRu96MJ5xRct09Lv4FpPV9YNzI/UEATsBl3VNRosfGtsgwbPM+Jo7xPs38IJkMpo= Received: by 10.142.178.13 with SMTP id a13mr1614251wff.1194921413354; Mon, 12 Nov 2007 18:36:53 -0800 (PST) Received: by 10.142.200.16 with HTTP; Mon, 12 Nov 2007 18:36:53 -0800 (PST) Message-ID: <7d6b50690711121836r6a2c3e1bm406178233d35e741@mail.gmail.com> Date: Tue, 13 Nov 2007 10:36:53 +0800 From: "lichun li" To: "Philip Matthews" Subject: Re: [P2PSIP] Proposal for progress on protocols In-Reply-To: MIME-Version: 1.0 References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <4731ED7B.2070901@sip-communicator.org> <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> <009b01c8250e$62a305c0$da07740a@DELLWEI> X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0933151250==" Errors-To: p2psip-bounces@ietf.org --===============0933151250== Content-Type: multipart/alternative; boundary="----=_Part_26282_28592331.1194921413368" ------=_Part_26282_28592331.1194921413368 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I agree with Philip Matthews. We need to identify the role of client first. IMHO, the basic role of client is: clients use P2PSIP overlay for SIP. If clients use P2PSIP overlay for SIP only, SIP and its extensions for P2PSIP can be used as client protocol. If P2PSIP overlay provides other services or clients may offer services, the protocols used between clients and peers may include all or some of the following protocols: SIP, STUN, SIP extensions for P2PSIP and other protocols. For backward-compatibility, we think SIP should be used to allow conventional clients using P2PSIP overlay . On 11/13/07, Philip Matthews wrote: > > > On 12-Nov-07, at 04:28 , Wei Gengyu wrote: > > > Hi, all > > > > I have a question. > > > > A peer in a P2PSIP overlay can be the proxy of a mobile client. > > Could SIP(rfc3261) be used between the client and the proxy Peer > > instead of defining a new protocol? > > This is in fact a long-running proposal. > > The answer to this question depends on whether you are interested in > using a P2PSIP overlay for just SIP, or whether you think our work > should be more general. If you are interested in just SIP, then this > is an excellent suggestion. However, if you are interested in > protocols other than SIP, then this idea doesn't work. > > Up until about Jan 2007, most of the active players in this group > seemed to be primarily interested in just SIP. However, this year has > seen a rise in interest in non-SIP usages. > > However, most (all?) of the currently active proposals are not > considering clients right now. Personally, I think this is because > people are still trying to figure out how peers work. > > - Philip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_26282_28592331.1194921413368 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I agree with Philip Matthews. We need to identify the role of client first.
IMHO, the basic role of client is: clients use P2PSIP overlay for SIP. If clients use P2PSIP overlay for SIP only, SIP and its extensions for P2PSIP can be used as client protocol.
If P2PSIP overlay provides other services or clients may offer services, the protocols used between clients and peers may include all or some of the following protocols: SIP, STUN, SIP extensions for P2PSIP and other protocols. For backward-compatibility, we think SIP should be used to allow conventional clients using P2PSIP overlay .

 
On 11/13/07, Philip Matthews <philip_matthews@magma.ca> wrote:

On 12-Nov-07, at 04:28 , Wei Gengyu wrote:

> Hi, all
>
> I have a question.
>
> A peer in a P2PSIP overlay can be the proxy of a mobile client.
> Could SIP(rfc3261) be used between the client and the proxy Peer
> instead of defining a new protocol?

This is in fact a long-running proposal.

The answer to this question depends on whether you are interested in
using a P2PSIP overlay for just SIP, or whether you think our work
should be more general. If you are interested in just SIP, then this
is an excellent suggestion. However, if you are interested in
protocols other than SIP, then this idea doesn't work.

Up until about Jan 2007, most of the active players in this group
seemed to be primarily interested in just SIP. However, this year has
seen a rise in interest in non-SIP usages.

However, most (all?) of the currently active proposals are not
considering clients right now. Personally, I think this is because
people are still trying to figure out how peers work.

- Philip



_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



--
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT ------=_Part_26282_28592331.1194921413368-- --===============0933151250== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0933151250==-- From p2psip-bounces@ietf.org Mon Nov 12 21:45:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irlmc-00006t-MG; Mon, 12 Nov 2007 21:45:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irlmb-00006B-Ft for p2psip@ietf.org; Mon, 12 Nov 2007 21:45:45 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrlmX-0008KE-8e for p2psip@ietf.org; Mon, 12 Nov 2007 21:45:45 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF007MYBNVCH@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:45:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRF005NKBNUNH@szxga04-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:45:31 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRF00GVQBNQZN@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 10:45:30 +0800 (CST) Date: Tue, 13 Nov 2007 10:45:26 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-reply-to: To: 'Henning Schulzrinne' , 'Philip Matthews' Message-id: <017b01c8259f$3f06b0d0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acglbx5MJVcOE294S3Kx0N46fhhBwgALjcSQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: "'Zheng, Harold'" , 'Henry Sinnreich' , "'Cole, Robert G.'" , "'Wang, XiaoXiao \(Sherry\)'" , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Agree. Here is only my personal viewpoint, I think that the overhead and applicability need further consideration though I believe that HIP can solve some problems in traditional addressing architecture. It would be difficult before modifying the traditional addressing and forwarding framework until we can show strong and obvious benefits than introduced overhead, maybe MPLS is an example. Best regards, Hewen -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: 2007?11?13? 5:00 To: Philip Matthews Cc: Zheng, Harold; Henry Sinnreich; Cole, Robert G.; Wang, XiaoXiao (Sherry); P2PSIP Mailing List Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP The notion of using the IP stack transparently seems dubious, as this would require quite a few restrictions on the identifier, leaving issues of how to implement this aside. I'm also doubting that this is useful, since we really do not want to route all packets through the overlay, only the first one, for efficiency reasons. On the numbering issue: The numbering space would have to exclude - the RFC 1918 ranges - the local address ranges (since routing would likely direct this to the local interface and bypass routing) - class E addresses The socket call would have to say "this is a real IPv4/IPv6 address, not an overlay address". How? If you designate this as a different protocol, in parallel to IPv4 and IPv6, you could just as well use a node ID of any length. Thus, I'm not convinced that this is a useful goal for an overlay network. Even if it can be done, all it accomplishes is making packets take ten hops across the Internet instead of one. Henning On Nov 12, 2007, at 3:47 PM, Philip Matthews wrote: > > > On 12-Nov-07, at 15:08 , Henry Sinnreich wrote: > >> The term commonly used in the p2p communities is as a hash >> of some data or location. >> >> Is there a problem using ? >> > > There are actually three different concepts to deal with, and the > challenge is to figure out their relationship. > > The first is the Peer ID as defined in the Concepts draft. This ID > uniquely identifies a peer in the overlay. In many DHTs, it also > describes where in the overlay the peer can be found (e.g., Chord > arranges peers in a ring based on their peer ids). > > The second is the local identifier used inside an application to refer > to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all propose to > make this identifier look like an IP address, so that applications can > continue to use the Socket API, which allows many existing > applications to operate without change in an overlay. > > The third is the Host ID as defined by HIP. This ID uniquely > identifies a host in the Internet, and is especially useful in > mobility situation and when nodes are behind NATs. > > > So what is the relationship between these three concepts? > o Does local identifier = peer ID? If yes, then Peer IDs probably > need to be globally unique, not just unique within a overlay, > otherwise you get into problems when a peer is a member of two > different overlays. Globally unique Peer IDs are possible, but > present some challenges. > > o Does Host ID = Peer ID? This is what HIP-HOP-00 proposes. > However, Eric Rescorla argues that this opens up the overlay to > Sybil attacks. > > > Right now, I am personally thinking that three of these are > distinct. However, these questions are listed in the ID/Loc document > as open issues. > > - Philip > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 22:08:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irm8t-0000Wn-PS; Mon, 12 Nov 2007 22:08:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irm8s-0000WN-Mh for p2psip@ietf.org; Mon, 12 Nov 2007 22:08:46 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irm8p-0000Ob-GP for p2psip@ietf.org; Mon, 12 Nov 2007 22:08:46 -0500 Received: by wa-out-1112.google.com with SMTP id k40so2660004wah for ; Mon, 12 Nov 2007 19:08:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index; bh=2hzCYJKPRrWCAzThJM0DzaukCy0fp4fCqAwn/EHCUXw=; b=Z4rxNm4bcriIN31WeYi4vCHwozUD/ZCgvSl+8Z2z6FPIu1wulTo1P349YJz9/U1tbnyDsybJ48qRTc4INBQyMTaAK4b6wT0QdMuSBoTrgM6sr+GGBiEHptV+IUZc283ypPKvq3YV1jnEQL3IvaOuDh6jP7dp4DM+BOVsYKaYODU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:x-mimeole:thread-index; b=b+uacV1bQHxb6i9cLbL9vaDJj2C2A4B2NlfyLAePSpCk6L7NwF9wSHSN5AhpJCWu4phYY6kJN5YP1509dVw0EU1x4geJAG2P/JXy1xOZ1uw7dJJRjxPKdM+AC14AlVcgkGImVJoeXnqL3Udj/Zn3ExWC/yzwNtmkT54QE752iF0= Received: by 10.114.73.1 with SMTP id v1mr50052waa.1194923322594; Mon, 12 Nov 2007 19:08:42 -0800 (PST) Received: from mlifewangyao ( [123.116.128.44]) by mx.google.com with ESMTPS id l30sm8553800waf.2007.11.12.19.08.41 (version=SSLv3 cipher=RC4-MD5); Mon, 12 Nov 2007 19:08:42 -0800 (PST) From: "Yao Wang" To: "'P2PSIP Mailing List'" Date: Tue, 13 Nov 2007 11:09:31 +0800 Message-ID: <000901c825a2$9e1a1be0$9a00a8c0@mlifewangyao> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AcgloHKd6VUB/5R+QPOAecZw/gVSYQAAe+sw X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [P2PSIP] New Draft: A SIP-based P2PSIP Client Protocol X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, folks We have submitted a document, named as =E2=80=9CA SIP-based P2PSIP = Client Protocol=E2=80=9D, to explain our viewpoints on P2PSIP Client and = P2PSIP Client Protocol. Currently it is available at = http://www.ietf.org/internet-drafts/draft-li-p2psip-client-protocol-00.tx= t Based on the discussions on this list, it seems that the main = difference on P2PSIP Client Protocol is around whether the Client = Protocol should be SIP-based. In our points of view, we think it should = base on SIP not only for the compatibility with existing SIP devices but = also the simplicity, flexibility of SIP. Besides, the term "SIP-based" = does not exclude other protocols for some particular service. Currently, = SIP is extended to exchange service-related information between clients = and peers for service discovery and service location (this function need = the cooperation of peer protocol), other protocols can be utilized to = access the services. The details of our design are explained in the draft.=20 =09 Comments are welcomed. Sincerely yours, Yao Wang=20 Mobile Life New Media Lab, BUPT _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 12 22:56:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrmtI-0004H3-HT; Mon, 12 Nov 2007 22:56:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrmtH-0004EU-7m for p2psip@ietf.org; Mon, 12 Nov 2007 22:56:43 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrmtG-0000aU-Td for p2psip@ietf.org; Mon, 12 Nov 2007 22:56:43 -0500 Received: from Henning-Schulzrinnes-Computer (pool-70-21-184-101.nwrk.east.verizon.net [70.21.184.101]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAD3ue71028999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 12 Nov 2007 22:56:40 -0500 (EST) From: Henning Schulzrinne To: Cullen Jennings In-Reply-To: <247006B3-44C3-4C0C-9174-57085A506C21@cisco.com> Subject: Re: [P2PSIP] Proposal for progress on protocols X-Priority: 3 References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu><4731ED7B.2070901@sip-communicator.org> <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> <009b01c8250e$62a305c0$da07740a@DELLWEI> <247006B3-44C3-4C0C-9174-57085A506C21@cisco.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Mon, 12 Nov 2007 22:56:39 -0500 X-Mailer: Apple Mail (2.912) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is true for P2PP as well. We found little advantage in creating a completely separate protocol. On Nov 12, 2007, at 5:57 PM, Cullen Jennings wrote: > > On Nov 12, 2007, at 8:37 AM, Philip Matthews wrote: > >> However, most (all?) of the currently active proposals are not >> considering clients right now. Personally, I think this is because >> people are still trying to figure out how peers work. > > Just as a side note, ASP support clients talking to peers using a > subset of the protocol that peers use to talk to each other. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 03:31:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrAk-0006Tk-Tx; Tue, 13 Nov 2007 03:31:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrAk-0006Te-0s for p2psip@ietf.org; Tue, 13 Nov 2007 03:31:02 -0500 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrrAi-0000Kp-F2 for p2psip@ietf.org; Tue, 13 Nov 2007 03:31:02 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1096784nzf for ; Tue, 13 Nov 2007 00:31:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=If3KQK7ZK9T5WdMZMq6JNWo568tvEpS40VWssKmnTVA=; b=WAC9TQiAz4p3OdoaWOaPob0cpzThOEocsUTMP6fdbN5Lm9IfOO1CEc5VJhzxKIHSv7Fxq98z31hkrEM2vfIHl/74i/NolfS9UHlfQjAggOsvgXoGlR9LJbXwiGjD4j97eFU0yJ/APEhDFTWOSuzfIOA8QLVaqjoKKPunPpNqTX8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=hUbQ8H1v9RfKSZCeErOwKsZCpmq5QD5kiOWU4dZ5JvGRsFZMad/M1iwc78n2UmSuHX2nae9h+QkZpHCY/KY0dAwb2m3lRpFfWsw9S/GeY1JD5f2Xaby0lzIW82W3hKgwB5oTkIyZSNzxQag+/yKFaezso3n0HBsquq4tlcrkliU= Received: by 10.142.108.14 with SMTP id g14mr31638wfc.1194942659314; Tue, 13 Nov 2007 00:30:59 -0800 (PST) Received: by 10.142.200.16 with HTTP; Tue, 13 Nov 2007 00:30:59 -0800 (PST) Message-ID: <7d6b50690711130030y1b8816d2t9106dc342c6bec72@mail.gmail.com> Date: Tue, 13 Nov 2007 16:30:59 +0800 From: "lichun li" To: "Ingmar Baumgart" Subject: Re: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) In-Reply-To: <47349F0A.5090201@tm.uka.de> MIME-Version: 1.0 References: <47349F0A.5090201@tm.uka.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0001181188==" Errors-To: p2psip-bounces@ietf.org --===============0001181188== Content-Type: multipart/alternative; boundary="----=_Part_27091_3880016.1194942659317" ------=_Part_27091_3880016.1194942659317 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Great! Does the implementation implement all security mechanisms described in this draft? And have you implemented P2PNS applications other than P2PSIP? On 11/10/07, Ingmar Baumgart wrote: > > Dear working group, > > I've submitted a draft for a Peer-to-Peer Name Service (P2PNS) which can > be used to resolve AoRs to Contact URIs without using DNS. > > The main contribution is on two aspects: One is reusability of the name > service for things like distributed DNS or HIP. The other is security in > a completely decentralized environment (without login severs). > > Until it is on the official servers, you can get it from here: > > http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.txt > http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.html > > Some additional information about the implementation can be found in > this P2P2007 demo abstract: > > http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf > > Regards, > Ingmar > > -- > Dipl.-Inform. Ingmar Baumgart > Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) > Zirkel 2, 76128 Karlsruhe, Germany > Phone: +49 721 608 8281, Fax: +49 721 608 6789 > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_27091_3880016.1194942659317 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Great! Does the implementation implement all security mechanisms = described in this draft? And have you implemented P2PNS applications other = than P2PSIP?

On 11/10/07, Ingmar Baumgart <baumgart@tm.= uka.de> wrote:
Dear working group,

I'= ;ve submitted a draft for a Peer-to-Peer Name Service (P2PNS) which can
be used to resolve AoRs to Contact URIs without using DNS.

The main = contribution is on two aspects: One is reusability of the name
service f= or things like distributed DNS or HIP. The other is security in
a comple= tely decentralized environment (without login severs).

Until it is on the official servers, you can get it from here:
<= br>http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.txt
http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.html

So= me additional information about the implementation can be found in
this = P2P2007 demo abstract:

http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf

Regards,
Ingma= r

--
Dipl.-Inform. Ingmar Baumgart
Institut f=FCr Telematik, U= niversit=E4t Karlsruhe (TH)
Zirkel 2, 76128 Karlsruhe, Germany
Phone:= +49 721 608 8281, Fax: +49 721 608 6789

_______________________________________________
P2PSIP mailing l= ist
P2PSIP@ietf.org
https://www1.ietf.org/mailm= an/listinfo/p2psip



--
Sincerely yours= ,

Lichun Li
Mobile Life New Media Lab, BUPT=20 ------=_Part_27091_3880016.1194942659317-- --===============0001181188== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0001181188==-- From p2psip-bounces@ietf.org Tue Nov 13 05:06:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrsfY-0000AG-BB; Tue, 13 Nov 2007 05:06:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrsfX-00008e-8u for p2psip@ietf.org; Tue, 13 Nov 2007 05:06:55 -0500 Received: from mx06.uni-tuebingen.de ([134.2.3.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrsfW-0004MK-Kc for p2psip@ietf.org; Tue, 13 Nov 2007 05:06:55 -0500 Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id lADA6hNp021920; Tue, 13 Nov 2007 11:06:49 +0100 Received: from vpn2514.extern.uni-tuebingen.de ([134.2.186.14]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1IrsfI-0001WB-21; Tue, 13 Nov 2007 11:06:40 +0100 Message-ID: <4739772F.4050200@uni-tuebingen.de> Date: Tue, 13 Nov 2007 11:06:39 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> In-Reply-To: <20071112234139.73AE233C2B@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.6.0.34; VDF: 7.0.0.207; host: mx06) X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , P2PSIP Mailing List , "Zheng, Harold" , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric, Ingmar, all, the peer-ID needs to be chosen by a central authority (in order to avoid both Sybil attacks and "chosen location" attacks). In HIP, the public key needs to be chosen by the peer itself. So, if you want to use HIP, you *can not* use the HIT as peer-ID. You should rather append the peer-id in the certificate. This actually makes HIP less attractive for P2PSIP. Cheers, Ali Eric Rescorla wrote: > At Mon, 12 Nov 2007 23:59:39 +0100, > Ingmar Baumgart wrote: >> Eric Rescorla wrote: >>> The issue isn't a Sybil attack. It's a chosen location attack. >>> >>> [...] >>> >>> Note that this can't be fixed purely by rate limiting at some >>> central authority (though puzzles can help) because >>> the computation is performed completely offline. The fix is >>> to have the central authority dispense peer-ids, but then this >>> breaks the binding between public keys and identities which >>> is one of the major attractions of HIP. >> Thank you for clarifying this. But why does this break the binding >> between public key and identity? >> >> The central authority could generate the public key pair and sign it. In >> case you don't want the central authority to posses your private key, >> peers could also generate the key pair on their own - in this case the >> central authority would impose some kind of online crypto puzzle on >> public key generation. > > So, the idea in HIP is to let the node self-generate their own identity > by generating a random cryptographic key and then using the digest of > the key as an identifier. This allows for a strong binding between > the identifier and your cryptographic keying material without any > central authority, because it's impractical for an attacker to generate > another key with the same identifier. So, as long as you can get > your hands on the identifier securely, the system doesn't need a > central authority. > > The reason this doesn't work in P2P systems is that it's not > sufficient to force the attacker not to generate a *specific* > digest postimage, but rather you need to stop them from generating > a range of postimages, which radically reduces the complexity of > the problem. > > The system you describe has a central authority. At that point, there's > no value in having the peer-id derived from the key because you need > to certificate to validate the key. You might as well just shove > the peer-id in the cert. > > -Ekr > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 06:49:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IruHA-0004AW-EN; Tue, 13 Nov 2007 06:49:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IruH9-0004AL-8o for p2psip@ietf.org; Tue, 13 Nov 2007 06:49:51 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IruH4-0006kg-GX for p2psip@ietf.org; Tue, 13 Nov 2007 06:49:51 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id D7367208D6; Tue, 13 Nov 2007 12:49:45 +0100 (CET) X-AuditID: c1b4fb3c-b0e80bb0000007e1-5a-47398f59cfde Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B44132084F; Tue, 13 Nov 2007 12:49:45 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 12:49:45 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 12:49:44 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id BDBFD2465; Tue, 13 Nov 2007 13:49:44 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 96E104DC3B; Tue, 13 Nov 2007 13:49:42 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0D36C4DC3A; Tue, 13 Nov 2007 13:49:42 +0200 (EET) Message-ID: <47398FB8.2090203@ericsson.com> Date: Tue, 13 Nov 2007 13:51:20 +0200 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Ali Fessi Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> <4739772F.4050200@uni-tuebingen.de> In-Reply-To: <4739772F.4050200@uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 13 Nov 2007 11:49:44.0589 (UTC) FILETIME=[489D9BD0:01C825EB] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , "Zheng, Harold" , Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Ali et all, Ali Fessi wrote: > the peer-ID needs to be chosen by a central authority (in order to avoid > both Sybil attacks and "chosen location" attacks). In HIP, the public > key needs to be chosen by the peer itself. So, if you want to use HIP, > you *can not* use the HIT as peer-ID. You should rather append the > peer-id in the certificate. Well, you *could use* HIT as a peer-ID, because nothing (in HIP) prevents using such private/public key pair which is generated by someone else than the peer itself, e.g. by a central authority. As I see the peer-ID assignment, there are two separate scenarios: 1. There is a central authority: In this case central authority can assign peer-IDs to peers. This is more secure way of assigning peer-IDs that the scenario #2, but this has one major downside: If there are multiple P2PSIP domains, a PKI-like structure is required. 2. There is no central authority: In this case the next-best-thing would be to use peer-IDs which are derived from self-generated private/public key pairs. It is true that this is not nearly as secure that scenario #1, but this eases the deployment. -- Jani > Eric Rescorla wrote: >> At Mon, 12 Nov 2007 23:59:39 +0100, >> Ingmar Baumgart wrote: >>> Eric Rescorla wrote: >>>> The issue isn't a Sybil attack. It's a chosen location attack. >>>> >>>> [...] >>>> >>>> Note that this can't be fixed purely by rate limiting at some >>>> central authority (though puzzles can help) because >>>> the computation is performed completely offline. The fix is >>>> to have the central authority dispense peer-ids, but then this >>>> breaks the binding between public keys and identities which >>>> is one of the major attractions of HIP. >>> Thank you for clarifying this. But why does this break the binding >>> between public key and identity? >>> >>> The central authority could generate the public key pair and sign it. In >>> case you don't want the central authority to posses your private key, >>> peers could also generate the key pair on their own - in this case the >>> central authority would impose some kind of online crypto puzzle on >>> public key generation. >> >> So, the idea in HIP is to let the node self-generate their own identity >> by generating a random cryptographic key and then using the digest of >> the key as an identifier. This allows for a strong binding between >> the identifier and your cryptographic keying material without any >> central authority, because it's impractical for an attacker to generate >> another key with the same identifier. So, as long as you can get >> your hands on the identifier securely, the system doesn't need a >> central authority. >> >> The reason this doesn't work in P2P systems is that it's not >> sufficient to force the attacker not to generate a *specific* >> digest postimage, but rather you need to stop them from generating >> a range of postimages, which radically reduces the complexity of >> the problem. >> The system you describe has a central authority. At that point, there's >> no value in having the peer-id derived from the key because you need >> to certificate to validate the key. You might as well just shove >> the peer-id in the cert. >> -Ekr >> >> >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 08:05:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvSo-0005M6-Hc; Tue, 13 Nov 2007 08:05:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvSm-0005Dl-U7 for p2psip@ietf.org; Tue, 13 Nov 2007 08:05:56 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrvSi-0000jj-OG for p2psip@ietf.org; Tue, 13 Nov 2007 08:05:56 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IrvSf-0002J7-3S; Tue, 13 Nov 2007 14:05:51 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IrvSd-0004wh-SM; Tue, 13 Nov 2007 14:05:48 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IrvSd-0001tO-Jb; Tue, 13 Nov 2007 14:05:47 +0100 Received: from [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4] (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id AB6F92FC00C; Tue, 13 Nov 2007 14:05:46 +0100 (CET) Message-ID: <4739A124.5000201@tm.uka.de> Date: Tue, 13 Nov 2007 14:05:40 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> In-Reply-To: <20071112234139.73AE233C2B@delta.rtfm.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , P2PSIP Mailing List , "Zheng, Harold" , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Rescorla wrote: > The system you describe has a central authority. At that point, there's > no value in having the peer-id derived from the key because you need > to certificate to validate the key. You might as well just shove > the peer-id in the cert. One reason to use H(Kpub) as nodeID even with a central authority is that you can get rid of the central authority as soon as the network is large enough. In this case the central authority is only used to initially bootstrap the overlay. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 08:12:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvYp-0005sm-8t; Tue, 13 Nov 2007 08:12:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvYn-0005nx-SG for p2psip@ietf.org; Tue, 13 Nov 2007 08:12:09 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrvYn-0002d9-A8 for p2psip@ietf.org; Tue, 13 Nov 2007 08:12:09 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IrvYj-0003RS-QE; Tue, 13 Nov 2007 14:12:08 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IrvYi-0008RS-54; Tue, 13 Nov 2007 14:12:05 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IrvYh-0002tf-5A; Tue, 13 Nov 2007 14:12:03 +0100 Received: from [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4] (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2A47C2FC00C; Tue, 13 Nov 2007 14:12:01 +0100 (CET) Message-ID: <4739A29B.3000003@tm.uka.de> Date: Tue, 13 Nov 2007 14:11:55 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: lichun li Subject: Re: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) References: <47349F0A.5090201@tm.uka.de> <7d6b50690711130030y1b8816d2t9106dc342c6bec72@mail.gmail.com> In-Reply-To: <7d6b50690711130030y1b8816d2t9106dc342c6bec72@mail.gmail.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The P2PNS implementation only implements some of the security mechanisms (e.g. routing over disjoint paths, DHT data record ownership). Message authentication is currently not implemented. The only available P2PNS application is P2PSIP, but support for distributed DNS is planed. Regards, Ingmar lichun li wrote: > Great! Does the implementation implement all security mechanisms described > in this draft? And have you implemented P2PNS applications other than > P2PSIP? > > On 11/10/07, Ingmar Baumgart wrote: >> Dear working group, >> >> I've submitted a draft for a Peer-to-Peer Name Service (P2PNS) which can >> be used to resolve AoRs to Contact URIs without using DNS. >> >> The main contribution is on two aspects: One is reusability of the name >> service for things like distributed DNS or HIP. The other is security in >> a completely decentralized environment (without login severs). >> >> Until it is on the official servers, you can get it from here: >> >> http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.txt >> http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.html >> >> Some additional information about the implementation can be found in >> this P2P2007 demo abstract: >> >> http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf >> >> Regards, >> Ingmar >> >> -- >> Dipl.-Inform. Ingmar Baumgart >> Institut für Telematik, Universität Karlsruhe (TH) >> Zirkel 2, 76128 Karlsruhe, Germany >> Phone: +49 721 608 8281, Fax: +49 721 608 6789 >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 08:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irvl8-0005at-Lm; Tue, 13 Nov 2007 08:24:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irvl7-0005YB-Om for p2psip@ietf.org; Tue, 13 Nov 2007 08:24:53 -0500 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irvl7-0003Lp-Bn for p2psip@ietf.org; Tue, 13 Nov 2007 08:24:53 -0500 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Tue, 13 Nov 2007 05:24:51 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lADDOnKn000432; Tue, 13 Nov 2007 05:24:49 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lADDOmFV009736; Tue, 13 Nov 2007 05:24:48 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 05:24:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Nov 2007 05:24:47 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE298@namail5.corp.adobe.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What Makes For a Successful Protocol? Thread-Index: AcglnfmOUBCmiruKQTm6Fvy4gGii0g== From: "Henry Sinnreich" To: "P2PSIP Mailing List" X-OriginalArrivalTime: 13 Nov 2007 13:24:48.0120 (UTC) FILETIME=[902F5F80:01C825F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: bernarda@microsoft.com, dthaler@microsoft.com Subject: [P2PSIP] What Makes For a Successful Protocol? X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org We had a range of options on how generic the requirements for P2PSIP should be. An answer for one end of the spectrum has just been published. The other ends of the spectrum are the technical merits. What Makes For a Successful Protocol? http://www.ietf.org/internet-drafts/draft-iab-protocol-success-00.txt =20 How about using these generic criteria when discussing the various P2PSIP proposals? Are there any other criteria to suggest? Thanks, Henry _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 08:25:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvlD-0005om-WC; Tue, 13 Nov 2007 08:25:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrvlB-0005hO-V5 for p2psip@ietf.org; Tue, 13 Nov 2007 08:24:58 -0500 Received: from chip2og51.obsmtp.com ([64.18.13.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrvlB-0003M0-I9 for p2psip@ietf.org; Tue, 13 Nov 2007 08:24:57 -0500 Received: from source ([192.150.11.134]) by chip2ob51.postini.com ([64.18.5.12]) with SMTP; Tue, 13 Nov 2007 05:24:51 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lADDMjOP027354; Tue, 13 Nov 2007 05:22:46 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lADDOmFV009737; Tue, 13 Nov 2007 05:24:49 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 05:24:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Proposed term: "Responsible Peer" Date: Tue, 13 Nov 2007 05:24:47 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE299@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Proposed term: "Responsible Peer" Thread-Index: AcglWRrc3Q+wvyqXSk2wfLGZJzdR5wAN+jXw References: From: "Henry Sinnreich" To: "Philip Matthews" , "P2PSIP Mailing List" X-OriginalArrivalTime: 13 Nov 2007 13:24:48.0381 (UTC) FILETIME=[905732D0:01C825F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org These definitions look OK. Some references would be useful as well.=20 I may actually give some to the authors if it is helpful. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Monday, November 12, 2007 12:24 PM To: P2PSIP Mailing List Subject: [P2PSIP] Proposed term: "Responsible Peer" Folks: I have been reviewing the mailing list again in preparation to revise =20 the Concepts draft for this IETF cycle. As I said in an earlier e-=20 mail message: http://www1.ietf.org/mail-archive/web/p2psip/current/msg02973.html the authors don't see a big revision this time, preferring to wait =20 until the various active proposals come closer together. However, one change that has been discussed on the mailing list was a =20 term for the peer which is responsible for storing the resource =20 record for a given resource. I saw two terms were proposed on the =20 mailing list and in private e-mails around this topic: "Responsible =20 Peer" and "Root Peer". The authors currently feel that the term "Responsible Peer" would be =20 a better choice, while recogizing that the term "Root Peer" is also =20 used in the literature. So I am proposing the following text for the next revision of the =20 Concepts draft: P2PSIP Responsible Peer: The Peer that is responsible for storing the Resource Record for =20 a Resource. In the literature, the term "Root Peer" is also used for this =20 concept. Comments? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 09:36:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrwsT-0004lJ-Ar; Tue, 13 Nov 2007 09:36:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrwsS-0004l8-Ga for p2psip@lists.ietf.org; Tue, 13 Nov 2007 09:36:32 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrwsN-00040U-R3 for p2psip@lists.ietf.org; Tue, 13 Nov 2007 09:36:32 -0500 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lADEaPU28691 for ; Tue, 13 Nov 2007 14:36:25 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 13 Nov 2007 09:36:24 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Chosen-location attacks, HIP-HOP and central authorities Thread-Index: AcgmApEOtyUl+NcASKa6LLjrObIQqQ== From: "Marcus Leech" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1342275094==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1342275094== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82602.911C3FF3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82602.911C3FF3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In a recent thread, Ekr writes: > Note that this can't be fixed purely by rate limiting at some central=20 > authority (though puzzles can help) because the computation is=20 > performed completely offline. The fix is to have the central authority > dispense peer-ids, but then this breaks the binding between public=20 > keys and identities which is one of the major attractions of HIP. > > -Ekr I guess I don't understand why a central authority helps, except to act as a rate-limiter. If our "attacker" has access to a large pool of source addresses, and assuming models where "joining" the mesh is an anonymous operation, I can't see how you can protect against a barrage of requests (perhaps spread over longer time periods) arriving from a vast flotilla of source addresses, where the idea is that *one* of those requests will yield a topologically "useful" PeerID. If the notion is that *only* authenticated nodes may "join" an overlay, then I can see rate-limiting based on the identity of the requestors, but in the anonymous case, I can't see how you can make this work. ------_=_NextPart_001_01C82602.911C3FF3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chosen-location attacks, HIP-HOP and central authorities

In a recent thread, Ekr writes:

> Note that this can't be = fixed purely by rate limiting at some central
> authority (though puzzles = can help) because the computation is
> performed completely = offline. The fix is to have the central authority
> dispense peer-ids, but then = this breaks the binding between public
> keys and identities which = is one of the major attractions of HIP.
>
> -Ekr

I guess I don't understand why a = central authority helps, except to act as a rate-limiter.

If our "attacker" has access = to a large pool of source addresses, and assuming models where = "joining" the
  mesh is an anonymous operation, = I can't see how you can protect against a barrage of requests (perhaps = spread over
  longer time periods) arriving = from a vast flotilla of source addresses, where the idea is that *one* = of those requests will

  yield a topologically = "useful" PeerID.

If the notion is that *only* = authenticated nodes may "join" an overlay, then I can see = rate-limiting based on the
  identity of the requestors, but = in the anonymous case, I can't see how you can make this work.

------_=_NextPart_001_01C82602.911C3FF3-- --===============1342275094== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1342275094==-- From p2psip-bounces@ietf.org Tue Nov 13 09:47:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx3J-0004ci-Kp; Tue, 13 Nov 2007 09:47:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx3I-0004cY-OP for p2psip@ietf.org; Tue, 13 Nov 2007 09:47:44 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irx3I-0006ZY-Ag for p2psip@ietf.org; Tue, 13 Nov 2007 09:47:44 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id C36F233C57; Tue, 13 Nov 2007 06:42:54 -0800 (PST) Date: Tue, 13 Nov 2007 06:42:54 -0800 From: Eric Rescorla To: "Jani Hautakorpi (JO/LMF)" Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-Reply-To: <47398FB8.2090203@ericsson.com> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> <4739772F.4050200@uni-tuebingen.de> <47398FB8.2090203@ericsson.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071113144254.C36F233C57@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , "Zheng, Harold" , Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 13 Nov 2007 13:51:20 +0200, Jani Hautakorpi (JO/LMF) wrote: > > Hi Ali et all, > > Ali Fessi wrote: > > the peer-ID needs to be chosen by a central authority (in order to avoid > > both Sybil attacks and "chosen location" attacks). In HIP, the public > > key needs to be chosen by the peer itself. So, if you want to use HIP, > > you *can not* use the HIT as peer-ID. You should rather append the > > peer-id in the certificate. > > Well, you *could use* HIT as a peer-ID, because nothing (in HIP) > prevents using such private/public key pair which is generated by > someone else than the peer itself, e.g. by a central authority. > > As I see the peer-ID assignment, there are two separate scenarios: > > 1. There is a central authority: In this case central authority can > assign peer-IDs to peers. This is more secure way of assigning > peer-IDs that the scenario #2, but this has one major downside: If > there are multiple P2PSIP domains, a PKI-like structure is required. This *still* needs a PKI-like structure because there's no way to distinguish valid from invalid key pairs, at least for conventional cryptographic tecniques like RSA. (You can with unconventional techniques like IBE and IBS.) -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 09:48:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx4U-00073E-OW; Tue, 13 Nov 2007 09:48:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx4T-00070z-IZ for p2psip@ietf.org; Tue, 13 Nov 2007 09:48:57 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irx4T-0006bS-8M for p2psip@ietf.org; Tue, 13 Nov 2007 09:48:57 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id DB43B33C58; Tue, 13 Nov 2007 06:44:07 -0800 (PST) Date: Tue, 13 Nov 2007 06:44:07 -0800 From: Eric Rescorla To: Ingmar Baumgart Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-Reply-To: <4739A124.5000201@tm.uka.de> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> <4739A124.5000201@tm.uka.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071113144407.DB43B33C58@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , "Zheng, Harold" , Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 13 Nov 2007 14:05:40 +0100, Ingmar Baumgart wrote: > > Eric Rescorla wrote: > > The system you describe has a central authority. At that point, there's > > no value in having the peer-id derived from the key because you need > > to certificate to validate the key. You might as well just shove > > the peer-id in the cert. > > One reason to use H(Kpub) as nodeID even with a central authority is > that you can get rid of the central authority as soon as the network is > large enough. I don't see why this is true. Even for extraordinarily large networks (2^32) the work factor fo finding a peer-id between two randomly chosen peers is only the size of the network (2^32) which is quite brute forceable. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 09:50:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx6Q-0000pP-9O; Tue, 13 Nov 2007 09:50:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irx6O-0000ou-Ta for p2psip@lists.ietf.org; Tue, 13 Nov 2007 09:50:56 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irx6L-0004Z6-Fc for p2psip@lists.ietf.org; Tue, 13 Nov 2007 09:50:56 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 8CF0733C59; Tue, 13 Nov 2007 06:46:04 -0800 (PST) Date: Tue, 13 Nov 2007 06:46:04 -0800 From: Eric Rescorla To: "Marcus Leech" Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071113144604.8CF0733C59@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 13 Nov 2007 09:36:24 -0500, Marcus Leech wrote: > > In a recent thread, Ekr writes: > > > Note that this can't be fixed purely by rate limiting at some central > > authority (though puzzles can help) because the computation is > > performed completely offline. The fix is to have the central authority > > > dispense peer-ids, but then this breaks the binding between public > > keys and identities which is one of the major attractions of HIP. > > > > -Ekr > > I guess I don't understand why a central authority helps, except to act > as a rate-limiter. > > If our "attacker" has access to a large pool of source addresses, and > assuming models where "joining" the > mesh is an anonymous operation, I can't see how you can protect > against a barrage of requests (perhaps spread over > longer time periods) arriving from a vast flotilla of source > addresses, where the idea is that *one* of those requests will > yield a topologically "useful" PeerID. > > If the notion is that *only* authenticated nodes may "join" an overlay, > then I can see rate-limiting based on the > identity of the requestors, but in the anonymous case, I can't see how > you can make this work. 1. You assign peer-ids at a central location so that each attacker oracle query is quite expensive. 2. You either require authentication or some kind of proof of work to get a peer-id, so this slows down chosen location attacks even more. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:00:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxFz-0005uj-Sy; Tue, 13 Nov 2007 10:00:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxFx-0005ts-Nl for p2psip@ietf.org; Tue, 13 Nov 2007 10:00:49 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrxFx-0007EY-4W for p2psip@ietf.org; Tue, 13 Nov 2007 10:00:49 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrxFu-0007lK-2I; Tue, 13 Nov 2007 10:00:46 -0500 In-Reply-To: <4738CBAA.3000902@tm.uka.de> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 10:01:55 -0500 To: Ingmar Baumgart X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Harold Zheng , Henry Sinnreich , "Cole, Robert G." , "Wang, XiaoXiao \(\(Sherry\)\)" , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org One of the goals of this work is to get many existing applications to work in an overlay without change. The vast majority of applications today use IPv4, so if we can make this work for IPv4, there is a huge win. So for IPv4, the idea is to allocate an address from a special IPv4 address range to identify a remote peer. (HIP implementations today use 1.0.0.0/8 which is currently marked "reserved"; but I suspect that we would only get a /14 or /16 allocated to us for this purpose). In the draft, we call this just an "identifier". Because this range is so small, this identifier cannot be a Peer Id. Instead, this number has only local significance, and identifies a remote peer that the local peer is interested in talking to. The P2P layer stores the mapping of this identifier to the actual Peer ID of the remote peer, and also the real address and port that it can be reached at. When an application sends a packet to the remote peer, the Shim layer replaces the identifier by the real address and port of the destination. For IPv6, the address range we are likely to get is much larger, so we can potentially use a different scheme. With IPv6, there is the option that the identifier could be the same as the Peer ID, or the same as the Host ID. - Philip On 12-Nov-07, at 16:54 , Ingmar Baumgart wrote: > I don't get the point why using only a single ID is a problem: > > - "Local identifier = peer ID": If your choose a random (or > cryptographic) 128 bit (or better 160 bit) ID, it should be globally > unique. Of course there is still the very unlikely chance of a > collision, but this can also happen if you use the ID only within one > overlay. > > - "Host ID = Peer ID": To inhibit a Sybil attack you have to limit the > generation of IDs (e.g. by using a central authority). But this > problem > seems to be independent from the fact "Host ID = Peer ID", or do I > miss > something? > > Regards, > Ingmar > > Philip Matthews wrote: >> >> There are actually three different concepts to deal with, and the >> challenge is to figure out their relationship. >> >> The first is the Peer ID as defined in the Concepts draft. This ID >> uniquely identifies a peer in the overlay. In many DHTs, it also >> describes where in the overlay the peer can be found (e.g., Chord >> arranges peers in a ring based on their peer ids). >> >> The second is the local identifier used inside an application to >> refer >> to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all propose to >> make this identifier look like an IP address, so that applications >> can >> continue to use the Socket API, which allows many existing >> applications >> to operate without change in an overlay. >> >> The third is the Host ID as defined by HIP. This ID uniquely >> identifies >> a host in the Internet, and is especially useful in mobility >> situation >> and when nodes are behind NATs. >> >> >> So what is the relationship between these three concepts? >> o Does local identifier = peer ID? If yes, then Peer IDs probably >> need to be globally unique, not just unique within a overlay, >> otherwise >> you get into problems when a peer is a member of two different >> overlays. >> Globally unique Peer IDs are possible, but present some challenges. >> >> o Does Host ID = Peer ID? This is what HIP-HOP-00 proposes. >> However, >> Eric Rescorla argues that this opens up the overlay to Sybil attacks. >> >> >> Right now, I am personally thinking that three of these are distinct. >> However, these questions are listed in the ID/Loc document as open >> issues. >> >> - Philip >> > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:08:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxNN-0002oW-Kx; Tue, 13 Nov 2007 10:08:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxNM-0002lA-5A for p2psip@ietf.org; Tue, 13 Nov 2007 10:08:28 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxNI-0005AF-V7 for p2psip@ietf.org; Tue, 13 Nov 2007 10:08:28 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrxNG-0005gN-1z; Tue, 13 Nov 2007 10:08:22 -0500 In-Reply-To: References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4D72FD2D-0FA4-4F0F-BABA-13965B4A0CB8@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 10:09:31 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: "Zheng, Harold" , Henry Sinnreich , "Cole, Robert G." , "Wang, XiaoXiao \(Sherry\)" , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12-Nov-07, at 16:00 , Henning Schulzrinne wrote: > The notion of using the IP stack transparently seems dubious, as > this would require quite a few restrictions on the identifier, > leaving issues of how to implement this aside. I'm also doubting > that this is useful, since we really do not want to route all > packets through the overlay, only the first one, for efficiency > reasons. > > On the numbering issue: The numbering space would have to exclude > - the RFC 1918 ranges > - the local address ranges (since routing would likely direct this > to the local interface and bypass routing) > - class E addresses > > The socket call would have to say "this is a real IPv4/IPv6 > address, not an overlay address". How? If you designate this as a > different protocol, in parallel to IPv4 and IPv6, you could just as > well use a node ID of any length. > > Thus, I'm not convinced that this is a useful goal for an overlay > network. Even if it can be done, all it accomplishes is making > packets take ten hops across the Internet instead of one. > > Henning Hi Henning: Sorry for not being clearer in the document. The goal of this work is not to route all packets through the overlay. On the contrary, the goal is to have the vast majority of packets go directly from the originator to the destination, without passing through intermediate peers. The signaling to set up a direct connection needs to be routed through the overlay in many cases. But once that direct connection is set up, packets can flow directly. For IPv4, the identifier is of local significance only, and is mapped to the real address and port of the destination before the packet is transmitted. I have already discussed the numbering issue in a separate reply. But the short answer is that we can probably get away with a /14 or /16 for the IPv4 identifier. This I think we have a reasonable chance of getting allocated to us. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:10:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxPb-0000de-Kq; Tue, 13 Nov 2007 10:10:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxPO-0008Os-Ox for p2psip@lists.ietf.org; Tue, 13 Nov 2007 10:10:34 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxPL-0005FB-HA for p2psip@lists.ietf.org; Tue, 13 Nov 2007 10:10:34 -0500 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id lADF7TQ23624; Tue, 13 Nov 2007 15:07:29 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities Date: Tue, 13 Nov 2007 10:10:27 -0500 Message-ID: In-Reply-To: <20071113144604.8CF0733C59@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities Thread-Index: AcgmBJjO9nRPWqQVSv+4cctJdvhxIAAAXo0w References: <20071113144604.8CF0733C59@delta.rtfm.com> From: "Marcus Leech" To: "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org 1. You assign peer-ids at a central location so that each attacker oracle query is quite expensive. 2. You either require authentication or some kind of proof of work to get a peer-id, so this slows down chosen location attacks even more. -Ekr It would be useful to consider the anonymous case, with proofs-of-work required (presumably asymmetric in favour of the central authority), what constitutes an "adequate" delay mechanism for reasonable projections of overlay size. Pulling numbers out of my butt here, if the network size is O(10**5), and the work function typically takes a second or two to compute, the attacking flotilla needs to be able to expend O(10**5) CPU-seconds to surf the PeerID space to find one that's "useful". It seems to me that for small overlays, the central authority model (assuming anonymity) can't protect against oracle-type attacks unless the work factor of the proof function gets suitably large, correct? Let's pretend that the current Internet is O(2**32) in size. What is a reasonable number for the ratio between total number of nodes, and those that are peers in an overlay. Is 1:1 a reasonable number? Is 10:1 a reasonable number? Is 100:1 a reasonable number? I just don't know, and it would certainly be useful to have reasonable estimates to drive the analysis of whether the central authority model can be made to work for suitably-robust definitions of "work". But perhaps I just have a bullet lodged in my brain, and I'm not thinking things out clearly. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxSN-0007IV-Ul; Tue, 13 Nov 2007 10:13:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxSM-0007IN-OS for p2psip@ietf.org; Tue, 13 Nov 2007 10:13:38 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxSG-0005aA-NS for p2psip@ietf.org; Tue, 13 Nov 2007 10:13:38 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IrxSD-000193-Pe; Tue, 13 Nov 2007 16:13:32 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IrxSC-0005pa-8r; Tue, 13 Nov 2007 16:13:29 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IrxSB-0006lU-SW; Tue, 13 Nov 2007 16:13:27 +0100 Received: from [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4] (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 0E5262FC00C; Tue, 13 Nov 2007 16:13:27 +0100 (CET) Message-ID: <4739BF11.8020105@tm.uka.de> Date: Tue, 13 Nov 2007 16:13:21 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> <4739A124.5000201@tm.uka.de> <20071113144407.DB43B33C58@delta.rtfm.com> In-Reply-To: <20071113144407.DB43B33C58@delta.rtfm.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , P2PSIP Mailing List , "Zheng, Harold" , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Rescorla wrote: > At Tue, 13 Nov 2007 14:05:40 +0100, > Ingmar Baumgart wrote: >> One reason to use H(Kpub) as nodeID even with a central authority is >> that you can get rid of the central authority as soon as the network is >> large enough. > > I don't see why this is true. Even for extraordinarily large networks > (2^32) the work factor fo finding a peer-id between two randomly chosen > peers is only the size of the network (2^32) which is quite brute > forceable. It depends on your attacker model. If your make your crypto puzzle hard enough (lets say 3 hours to generate a valid nodeID on an average desktop PC) 2^32 is hard to brute-force for most attackers. The question is: If there is no central authority, what level of security can we achieve and is this sufficient for our use case? A completely decentralized network will never reach the same level of security that you can achieve with a trustworthy authority. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:14:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxTM-0008Ds-F3; Tue, 13 Nov 2007 10:14:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxTJ-00088v-Ud for p2psip@ietf.org; Tue, 13 Nov 2007 10:14:38 -0500 Received: from py-out-1112.google.com ([64.233.166.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxTG-0005dy-A7 for p2psip@ietf.org; Tue, 13 Nov 2007 10:14:37 -0500 Received: by py-out-1112.google.com with SMTP id d32so3467359pye for ; Tue, 13 Nov 2007 07:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=4kfo38QTn4CP4Y91l8Pngo91cMQTYG7eSWzOlaHJVXY=; b=Kese3/nPjSnWh4rXYM8pJjdxYkIMI80Go5+ES6FtF+PSYirUh3z5DpxdiHBaIWl3Q+9EO0um6qohyrdnNRMiAo3QHRPTk6jWe8e41aPoHNMxETTyIh4XxBbtxUxq4mt8NSWCMheeV/WDNnqpnAiWpfr/Q9X254isg/dfKdEsJMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=LU+dFMuU1gLVsmlMR4KT3k0dWSXzPFfkwrx/uB2xQWW6Mlo6/pIdBHlSePSvOkOywzuqDa01pOXloOPytrmYRGhG525+zHy7k2KA/POYrNaaRqwBs3C+g2/pVrotQFQ9zFsaFaF0C5+rR7aa7TY14LskZ+UVG2A3ZVF+Ve8hYxU= Received: by 10.65.233.16 with SMTP id k16mr16679729qbr.1194966871526; Tue, 13 Nov 2007 07:14:31 -0800 (PST) Received: by 10.65.180.16 with HTTP; Tue, 13 Nov 2007 07:14:31 -0800 (PST) Message-ID: <4d4304a00711130714x32b8aacel4d5bd0a230cbd03f@mail.gmail.com> Date: Tue, 13 Nov 2007 10:14:31 -0500 From: "David A. Bryan" To: "Philip Matthews" Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> X-Google-Sender-Auth: c6f565df84b2b848 X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: "Wang, XiaoXiao \(\(Sherry\)\)" , "Cole, Robert G." , P2PSIP Mailing List , Harold Zheng , Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I read the draft, and the point you touch on below (things using the overlay without the application knowing about it) is actually one of the things I most confused about. I can understand how this can help with overlay routing -- in other words, if you want to route each and every message via the overlay, that could be done with no change to the application. (but I don't think we want to route all messages through the overlay -- that seems very inefficient in cases where a direct connection can be used) However, if the overlay is being used as storage mechanism, I don't get how it is transparent at all. How would this work for the SIP application, for example? It would still want to have an address of a default proxy, would still want to send registrations to a particular registrar, etc. You would still need to know that the lookup/registration process is very different with a P2PSIP deployment. If you are doing file sharing applications, the application would still need to know to hash/do lookup of where the file is, then get the location to fetch the file... I don't see how we really get any applications "for free" in this case. David (as individual) On Nov 13, 2007 10:01 AM, Philip Matthews wrote: > One of the goals of this work is to get many existing applications to > work in an overlay without change. The vast majority of applications > today use IPv4, so if we can make this work for IPv4, there is a huge > win. > > So for IPv4, the idea is to allocate an address from a special IPv4 > address range to identify a remote peer. (HIP implementations today > use 1.0.0.0/8 which is currently marked "reserved"; but I suspect > that we would only get a /14 or /16 allocated to us for this > purpose). In the draft, we call this just an "identifier". > > Because this range is so small, this identifier cannot be a Peer Id. > Instead, this number has only local significance, and identifies a > remote peer that the local peer is interested in talking to. The P2P > layer stores the mapping of this identifier to the actual Peer ID of > the remote peer, and also the real address and port that it can be > reached at. > > When an application sends a packet to the remote peer, the Shim layer > replaces the identifier by the real address and port of the > destination. > > > > For IPv6, the address range we are likely to get is much larger, so > we can potentially use a different scheme. With IPv6, there is the > option that the identifier could be the same as the Peer ID, or the > same as the Host ID. > > - Philip > > > > > On 12-Nov-07, at 16:54 , Ingmar Baumgart wrote: > > > I don't get the point why using only a single ID is a problem: > > > > - "Local identifier = peer ID": If your choose a random (or > > cryptographic) 128 bit (or better 160 bit) ID, it should be globally > > unique. Of course there is still the very unlikely chance of a > > collision, but this can also happen if you use the ID only within one > > overlay. > > > > - "Host ID = Peer ID": To inhibit a Sybil attack you have to limit the > > generation of IDs (e.g. by using a central authority). But this > > problem > > seems to be independent from the fact "Host ID = Peer ID", or do I > > miss > > something? > > > > Regards, > > Ingmar > > > > Philip Matthews wrote: > >> > >> There are actually three different concepts to deal with, and the > >> challenge is to figure out their relationship. > >> > >> The first is the Peer ID as defined in the Concepts draft. This ID > >> uniquely identifies a peer in the overlay. In many DHTs, it also > >> describes where in the overlay the peer can be found (e.g., Chord > >> arranges peers in a ring based on their peer ids). > >> > >> The second is the local identifier used inside an application to > >> refer > >> to a remote peer. Our draft (and HIP-HOP and WITH-HIP) all propose to > >> make this identifier look like an IP address, so that applications > >> can > >> continue to use the Socket API, which allows many existing > >> applications > >> to operate without change in an overlay. > >> > >> The third is the Host ID as defined by HIP. This ID uniquely > >> identifies > >> a host in the Internet, and is especially useful in mobility > >> situation > >> and when nodes are behind NATs. > >> > >> > >> So what is the relationship between these three concepts? > >> o Does local identifier = peer ID? If yes, then Peer IDs probably > >> need to be globally unique, not just unique within a overlay, > >> otherwise > >> you get into problems when a peer is a member of two different > >> overlays. > >> Globally unique Peer IDs are possible, but present some challenges. > >> > >> o Does Host ID = Peer ID? This is what HIP-HOP-00 proposes. > >> However, > >> Eric Rescorla argues that this opens up the overlay to Sybil attacks. > >> > >> > >> Right now, I am personally thinking that three of these are distinct. > >> However, these questions are listed in the ID/Loc document as open > >> issues. > >> > >> - Philip > >> > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:16:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxUi-0003bq-GC; Tue, 13 Nov 2007 10:16:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxUf-0003PJ-OS for p2psip@ietf.org; Tue, 13 Nov 2007 10:16:01 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrxUc-00085V-4z for p2psip@ietf.org; Tue, 13 Nov 2007 10:16:01 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrxUV-0001xk-3A; Tue, 13 Nov 2007 10:15:52 -0500 In-Reply-To: <20071112220620.DAE4733C2B@delta.rtfm.com> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <735C92F8-6E16-4F19-8E75-A4C38B0CAC52@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 10:17:00 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , P2PSIP Mailing List , "Zheng, Harold" , Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12-Nov-07, at 17:06 , Eric Rescorla wrote: > At Mon, 12 Nov 2007 22:54:50 +0100, > Ingmar Baumgart wrote: >> >> - "Host ID = Peer ID": To inhibit a Sybil attack you have to limit >> the >> generation of IDs (e.g. by using a central authority). But this >> problem >> seems to be independent from the fact "Host ID = Peer ID", or do I >> miss >> something? > > The issue isn't a Sybil attack. It's a chosen location attack. > > If you choose peer-ids by hashing public keys, then an attacker > can choose the top X bits of the peer-id by generating > 2^X keys. This doesn't sound bad because the IDs are very > long, but the relevant issue isn't the SIZE of the peer > ID but rather the distance between peer-IDs as a fraction > of the size of the peer-ID space, and that's determined > solely by the number of peers. > > To take a specific case, say you're using 160-bit IDs and the > ring has 2^10 (1024) users. On average, each peer will be a > distance of 2^150 away from the next peer. Say you want to > be between peers X and X+1. If you generate a random key pair > and hash it, your chances of getting a value between X and > X+1 is approximately 2^-10. So, in order 2^10 trials you > can get a value in between those two peers. In general, > the number of trials you need scales with the number of peers, > but consider that 2^30 is an absurdly large p2p network and > yet easily within the brute force limit. > > Note that this can't be fixed purely by rate limiting at some > central authority (though puzzles can help) because > the computation is performed completely offline. The fix is > to have the central authority dispense peer-ids, but then this > breaks the binding between public keys and identities which > is one of the major attractions of HIP. > > -Ekr I have heard some counter-arguments to this, from someone who knows a lot more about security than I do. Never-the-less, this is one of the reasons that I am thinking now that a Host ID should not be the same as the Peer ID. This would allow a node to use, for example, the procedures of HIP to generate a Host ID, but still go to a central authority to allocate a Peer ID to use in a particular overlay. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxgK-00070W-PT; Tue, 13 Nov 2007 10:28:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxgI-00070L-11 for p2psip@lists.ietf.org; Tue, 13 Nov 2007 10:28:02 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxgC-00077r-SA for p2psip@lists.ietf.org; Tue, 13 Nov 2007 10:28:02 -0500 Received: from Henning-Schulzrinnes-Computer (pool-70-21-184-101.nwrk.east.verizon.net [70.21.184.101]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lADFRsGW002440 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Nov 2007 10:27:55 -0500 (EST) Message-Id: <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> From: Henning Schulzrinne To: Marcus Leech In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities Date: Tue, 13 Nov 2007 10:27:54 -0500 References: <20071113144604.8CF0733C59@delta.rtfm.com> X-Mailer: Apple Mail (2.912) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I find the notion of proof of work somewhat dubious for this application. With today's massive botnets, you'd have to impose proof- of-work on the order of days on a fast processor to make any difference. If a single sybil is fatal, even with the assumptions of roughly 10^5 attempts at guessing, it takes a single node a bit more than a day to subvert the DHT. With the typical 100,000 node botnet, it's one second until one of them hits pay dirt. Henning On Nov 13, 2007, at 10:10 AM, Marcus Leech wrote: > > 1. You assign peer-ids at a central location so that each attacker > oracle > query is quite expensive. > 2. You either require authentication or some kind of proof of work to > get a peer-id, so this slows down chosen location attacks even > more. > -Ekr > > > It would be useful to consider the anonymous case, with proofs-of-work > required > (presumably asymmetric in favour of the central authority), what > constitutes > an "adequate" delay mechanism for reasonable projections of overlay > size. > > Pulling numbers out of my butt here, if the network size is O(10**5), > and the > work function typically takes a second or two to compute, the > attacking > flotilla needs to be able to expend O(10**5) CPU-seconds to surf the > PeerID > space to find one that's "useful". > > It seems to me that for small overlays, the central authority model > (assuming > anonymity) can't protect against oracle-type attacks unless the work > factor > of the proof function gets suitably large, correct? > > Let's pretend that the current Internet is O(2**32) in size. What > is a > reasonable > number for the ratio between total number of nodes, and those that > are > peers in > an overlay. Is 1:1 a reasonable number? Is 10:1 a reasonable > number? > Is 100:1 > a reasonable number? I just don't know, and it would certainly be > useful to have > reasonable estimates to drive the analysis of whether the central > authority model > can be made to work for suitably-robust definitions of "work". > > But perhaps I just have a bullet lodged in my brain, and I'm not > thinking things out > clearly. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:29:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irxhw-0007LS-Vc; Tue, 13 Nov 2007 10:29:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irxhv-0007LL-HD for p2psip@ietf.org; Tue, 13 Nov 2007 10:29:43 -0500 Received: from nz-out-0506.google.com ([64.233.162.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irxht-0007CV-Sf for p2psip@ietf.org; Tue, 13 Nov 2007 10:29:43 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1188391nzf for ; Tue, 13 Nov 2007 07:29:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=fQlNWEhFr6K8cPVrfzbN1T2NPktqpLzUEw4TAK0dVbw=; b=l+GioICMaOBdR5lfo64T867hDQs898NW+hJNBKq2PaXj5XUDP2YnIe7NxGZau+FlHpY/qJerZba/jurqmRrZ2hF2uDpJcd4jYowRvncwv+/EZSWP/foj4cVIKQ/oOpfzErODq/sTJ2RBOsNdXoDc1bJA3A6k9srpGPsZsOhsO6w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=apRMJetlr4mqfUmy2CwdcUwrdkVAlUvRjp0ElyUfZM2jT7bqOVE3aiO5zZSeHatgYRecV7i0rT5EO2LnLb9LR4IIs7TLlID0QjDzC6ZGX0W0RgO17ti+0QBF3dILHDiea742bnKVBty9a/MSMjduWo4FshgNy0jRq63S5JO4+ws= Received: by 10.142.221.19 with SMTP id t19mr821072wfg.1194967780677; Tue, 13 Nov 2007 07:29:40 -0800 (PST) Received: by 10.65.180.16 with HTTP; Tue, 13 Nov 2007 07:29:40 -0800 (PST) Message-ID: <4d4304a00711130729g60188b62w7efb6d8c73b84bba@mail.gmail.com> Date: Tue, 13 Nov 2007 10:29:40 -0500 From: "David A. Bryan" To: "Ingmar Baumgart" Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-Reply-To: <4739BF11.8020105@tm.uka.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> <4739A124.5000201@tm.uka.de> <20071113144407.DB43B33C58@delta.rtfm.com> <4739BF11.8020105@tm.uka.de> X-Google-Sender-Auth: eeb72b093aa45c58 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , "Zheng, Harold" , Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > I don't see why this is true. Even for extraordinarily large networks > > (2^32) the work factor fo finding a peer-id between two randomly chosen > > peers is only the size of the network (2^32) which is quite brute > > forceable. > > It depends on your attacker model. If your make your crypto puzzle hard > enough (lets say 3 hours to generate a valid nodeID on an average > desktop PC) 2^32 is hard to brute-force for most attackers. I think you hit the main problem I see with crypto puzzles here. What is an average peer? If you say an "average" desktop PC, then solving a similar puzzle will be very hard for VoIP or wireless handset, or some other embedded device. If you assume it is just PCs, then those of us who have access to super computer clusters of low hundreds of machines (and I suspect there are many people who qualify) can still do it. A similar, and more sinister, argument applies to people who have bot nets. > The question is: If there is no central authority, what level of > security can we achieve and is this sufficient for our use case? I personally think that we allow for a lower security mechanism -- perhaps a simple shared secret -- that can be used for small, ad-hoc deployments, but would argue that finding a good secure distributed security mechanism that assures unique user names is very difficult. So difficult, in fact, it was explicitly excluded from our work in the charter to ensure we were working on solvable, engineering problems. David (as individual) > A completely decentralized network will never reach the same level of > security that you can achieve with a trustworthy authority. > > Regards, > Ingmar > > -- > Dipl.-Inform. Ingmar Baumgart > Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) > Zirkel 2, 76128 Karlsruhe, Germany > Phone: +49 721 608 8281, Fax: +49 721 608 6789 > > _______________________________________________ > > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:41:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxtI-00027U-CI; Tue, 13 Nov 2007 10:41:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxtH-00027J-0a for p2psip@ietf.org; Tue, 13 Nov 2007 10:41:27 -0500 Received: from aplesnation.dom1.jhuapl.edu ([128.244.198.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxtD-0007iQ-Jj for p2psip@ietf.org; Tue, 13 Nov 2007 10:41:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 10:41:22 -0500 Message-ID: <7B95239DDD54E54B9BFA23847142B1EE03065C74@aplesnation.dom1.jhuapl.edu> In-Reply-To: <735C92F8-6E16-4F19-8E75-A4C38B0CAC52@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Thread-Index: AcgmCCP6Qfl2jcjvRAGrTs2OMV1zrgAAGjWw References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <735C92F8-6E16-4F19-8E75-A4C38B0CAC52@magma.ca> From: "Wang, XiaoXiao (Sherry)" To: "Philip Matthews" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: "Zheng, Harold" , Henry Sinnreich , "Cole, Robert G." , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Philip, My understandings are: 1. security has a lifespan, we do not need a life-time protection, instead we only need a mechanism that can update information, e.g. keys, faster enough to keep signaling packets save for the time of a session setup. 2. the goal or appealing feature of the P2P is de-centralize. Usually, P2P is for networks such as ad hoc, wireless, mobile, tactical, etc. a centralized solution is very hard to be successful. =20 3. I agree with you that the overlay is just for signaling to find peers. After that, data packets go to a direct media path, which makes the P2P functions much clear. Please let me know if I went to a wrong direction. Thanks, Sherry =20 =20 -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Tuesday, November 13, 2007 10:17 AM To: Eric Rescorla Cc: Ingmar Baumgart; Wang, XiaoXiao (Sherry); Cole, Robert G.; P2PSIP Mailing List; Zheng, Harold; Henry Sinnreich Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP On 12-Nov-07, at 17:06 , Eric Rescorla wrote: > At Mon, 12 Nov 2007 22:54:50 +0100, > Ingmar Baumgart wrote: >> >> - "Host ID =3D Peer ID": To inhibit a Sybil attack you have to limit=20 >> the generation of IDs (e.g. by using a central authority). But this=20 >> problem seems to be independent from the fact "Host ID =3D Peer ID", = or >> do I miss something? > > The issue isn't a Sybil attack. It's a chosen location attack. > > If you choose peer-ids by hashing public keys, then an attacker can=20 > choose the top X bits of the peer-id by generating 2^X keys. This=20 > doesn't sound bad because the IDs are very long, but the relevant=20 > issue isn't the SIZE of the peer ID but rather the distance between=20 > peer-IDs as a fraction of the size of the peer-ID space, and that's=20 > determined solely by the number of peers. > > To take a specific case, say you're using 160-bit IDs and the ring has > 2^10 (1024) users. On average, each peer will be a distance of 2^150=20 > away from the next peer. Say you want to be between peers X and X+1.=20 > If you generate a random key pair and hash it, your chances of getting > a value between X and > X+1 is approximately 2^-10. So, in order 2^10 trials you > can get a value in between those two peers. In general, the number of=20 > trials you need scales with the number of peers, but consider that=20 > 2^30 is an absurdly large p2p network and yet easily within the brute=20 > force limit. > > Note that this can't be fixed purely by rate limiting at some central=20 > authority (though puzzles can help) because the computation is=20 > performed completely offline. The fix is to have the central authority > dispense peer-ids, but then this breaks the binding between public=20 > keys and identities which is one of the major attractions of HIP. > > -Ekr I have heard some counter-arguments to this, from someone who knows a lot more about security than I do. Never-the-less, this is one of the reasons that I am thinking now that a Host ID should not be the same as the Peer ID. This would allow a node to use, for example, the procedures of HIP to generate a Host ID, but still go to a central authority to allocate a Peer ID to use in a particular overlay. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:42:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxuG-0002Q3-5G; Tue, 13 Nov 2007 10:42:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxuF-0002Pn-2S for p2psip@ietf.org; Tue, 13 Nov 2007 10:42:27 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrxuE-0001km-NY for p2psip@ietf.org; Tue, 13 Nov 2007 10:42:26 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 2DAF333C2B; Tue, 13 Nov 2007 07:37:37 -0800 (PST) Date: Tue, 13 Nov 2007 07:37:36 -0800 From: Eric Rescorla To: Ingmar Baumgart Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-Reply-To: <4739BF11.8020105@tm.uka.de> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> <4739A124.5000201@tm.uka.de> <20071113144407.DB43B33C58@delta.rtfm.com> <4739BF11.8020105@tm.uka.de> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071113153737.2DAF333C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , "Zheng, Harold" , Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 13 Nov 2007 16:13:21 +0100, Ingmar Baumgart wrote: > > Eric Rescorla wrote: > > At Tue, 13 Nov 2007 14:05:40 +0100, > > Ingmar Baumgart wrote: > >> One reason to use H(Kpub) as nodeID even with a central authority is > >> that you can get rid of the central authority as soon as the network is > >> large enough. > > > > I don't see why this is true. Even for extraordinarily large networks > > (2^32) the work factor fo finding a peer-id between two randomly chosen > > peers is only the size of the network (2^32) which is quite brute > > forceable. > > It depends on your attacker model. If your make your crypto puzzle hard > enough (lets say 3 hours to generate a valid nodeID on an average > desktop PC) 2^32 is hard to brute-force for most attackers. With the consequence that nobody on a limited-capability device (like a phone handset) can do the puzzle at all -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxvF-0002jD-JX; Tue, 13 Nov 2007 10:43:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrxvD-0002hZ-5v for p2psip@ietf.org; Tue, 13 Nov 2007 10:43:27 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrxvA-0007mo-PA for p2psip@ietf.org; Tue, 13 Nov 2007 10:43:27 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id D938333C3C; Tue, 13 Nov 2007 07:38:35 -0800 (PST) Date: Tue, 13 Nov 2007 07:38:35 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP In-Reply-To: <735C92F8-6E16-4F19-8E75-A4C38B0CAC52@magma.ca> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <735C92F8-6E16-4F19-8E75-A4C38B0CAC52@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071113153835.D938333C3C@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , "Zheng, Harold" , Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 13 Nov 2007 10:17:00 -0500, Philip Matthews wrote: > > > On 12-Nov-07, at 17:06 , Eric Rescorla wrote: > > > At Mon, 12 Nov 2007 22:54:50 +0100, > > Ingmar Baumgart wrote: > >> > >> - "Host ID = Peer ID": To inhibit a Sybil attack you have to limit > >> the > >> generation of IDs (e.g. by using a central authority). But this > >> problem > >> seems to be independent from the fact "Host ID = Peer ID", or do I > >> miss > >> something? > > > > The issue isn't a Sybil attack. It's a chosen location attack. > > > > If you choose peer-ids by hashing public keys, then an attacker > > can choose the top X bits of the peer-id by generating > > 2^X keys. This doesn't sound bad because the IDs are very > > long, but the relevant issue isn't the SIZE of the peer > > ID but rather the distance between peer-IDs as a fraction > > of the size of the peer-ID space, and that's determined > > solely by the number of peers. > > > > To take a specific case, say you're using 160-bit IDs and the > > ring has 2^10 (1024) users. On average, each peer will be a > > distance of 2^150 away from the next peer. Say you want to > > be between peers X and X+1. If you generate a random key pair > > and hash it, your chances of getting a value between X and > > X+1 is approximately 2^-10. So, in order 2^10 trials you > > can get a value in between those two peers. In general, > > the number of trials you need scales with the number of peers, > > but consider that 2^30 is an absurdly large p2p network and > > yet easily within the brute force limit. > > > > Note that this can't be fixed purely by rate limiting at some > > central authority (though puzzles can help) because > > the computation is performed completely offline. The fix is > > to have the central authority dispense peer-ids, but then this > > breaks the binding between public keys and identities which > > is one of the major attractions of HIP. > > > > -Ekr > > I have heard some counter-arguments to this, from someone who knows a > lot more about security than I do. Well, I'd certainly be interested in hearing them. I could of course be wrong but it's not exactly a complicated line of reasoning. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:51:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iry2g-0005Vg-8l; Tue, 13 Nov 2007 10:51:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iry2e-0005VR-Iq for p2psip@ietf.org; Tue, 13 Nov 2007 10:51:08 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iry2e-00025Y-2T for p2psip@ietf.org; Tue, 13 Nov 2007 10:51:08 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1Iry2Z-000899-9u; Tue, 13 Nov 2007 16:51:07 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1Iry2Y-00075A-06; Tue, 13 Nov 2007 16:51:03 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1Iry2X-00053z-F2; Tue, 13 Nov 2007 16:51:01 +0100 Received: from [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4] (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 68F6E2FC00E; Tue, 13 Nov 2007 16:50:59 +0100 (CET) Message-ID: <4739C7DD.2000100@tm.uka.de> Date: Tue, 13 Nov 2007 16:50:53 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> <4739A124.5000201@tm.uka.de> <20071113144407.DB43B33C58@delta.rtfm.com> <4739BF11.8020105@tm.uka.de> <20071113153737.2DAF333C2B@delta.rtfm.com> In-Reply-To: <20071113153737.2DAF333C2B@delta.rtfm.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: "Wang, XiaoXiao \(Sherry\)" , "Cole, Robert G." , P2PSIP Mailing List , "Zheng, Harold" , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Rescorla wrote: > At Tue, 13 Nov 2007 16:13:21 +0100, > Ingmar Baumgart wrote: >> Eric Rescorla wrote: >>> At Tue, 13 Nov 2007 14:05:40 +0100, >>> Ingmar Baumgart wrote: >>>> One reason to use H(Kpub) as nodeID even with a central authority is >>>> that you can get rid of the central authority as soon as the network is >>>> large enough. >>> I don't see why this is true. Even for extraordinarily large networks >>> (2^32) the work factor fo finding a peer-id between two randomly chosen >>> peers is only the size of the network (2^32) which is quite brute >>> forceable. >> It depends on your attacker model. If your make your crypto puzzle hard >> enough (lets say 3 hours to generate a valid nodeID on an average >> desktop PC) 2^32 is hard to brute-force for most attackers. > > With the consequence that nobody on a limited-capability device > (like a phone handset) can do the puzzle at all You could generate the nodeID on a desktop PC and then transfer the key pair to your phone. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 10:59:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryAG-0000BL-Mw; Tue, 13 Nov 2007 10:59:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryAF-0000BE-Hu for p2psip@ietf.org; Tue, 13 Nov 2007 10:58:59 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IryAF-0002VS-0h for p2psip@ietf.org; Tue, 13 Nov 2007 10:58:59 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IryAE-0007f2-29; Tue, 13 Nov 2007 10:58:58 -0500 In-Reply-To: <4d4304a00711130714x32b8aacel4d5bd0a230cbd03f@mail.gmail.com> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <4d4304a00711130714x32b8aacel4d5bd0a230cbd03f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 11:00:08 -0500 To: "David A. Bryan" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Harold Zheng , "Wang, XiaoXiao \(\(\(\(Sherry\)\)\)\)" , "Cole, Robert G." , Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 13-Nov-07, at 10:14 , David A. Bryan wrote: > I read the draft, and the point you touch on below (things using the > overlay without the application knowing about it) is actually one of > the things I most confused about. > > I can understand how this can help with overlay routing -- in other > words, if you want to route each and every message via the overlay, > that could be done with no change to the application. (but I don't > think we want to route all messages through the overlay -- that seems > very inefficient in cases where a direct connection can be used) > > However, if the overlay is being used as storage mechanism, I don't > get how it is transparent at all. How would this work for the SIP > application, for example? It would still want to have an address of a > default proxy, would still want to send registrations to a particular > registrar, etc. You would still need to know that the > lookup/registration process is very different with a P2PSIP > deployment. > > If you are doing file sharing applications, the application would > still need to know to hash/do lookup of where the file is, then get > the location to fetch the file... > > I don't see how we really get any applications "for free" in this > case. Hi David: First of all, just to be clear, I absolutely DO NOT want to route every packet through the overlay. In fact, I believe that the most common case, by far, will be to set up a direct connection to the remote peer and send packets over that direct connection. The packets I see as being routed through the overlay are: (a) Put and Get operations on the distributed database, (b) other searches (e.g., for the admitting peer), (c) signaling packets to set up direct connections (when other approaches don't work), and (d) perhaps SOME application data in cases where only a small number of packets are needed (details TBD). So the general idea that we had in "NAT Traversal for dSIP" still applies. Second, applications that take advantage of special services that the overlay provides (e.g., the distributed database) will probably need to be modified. In particular, if SIP wants to use the distributed location service, your SIP UA code probably needs modifications (though there may be ways to avoid this). To illustrate an application that would not require any modification, consider the following variation on the example given in the document. In the example, there are three machines (names "venus", "earth", and "mars") which are part of a larger overlay (called "solar-system.p2p"). Assume all three machines are located behind different NATs. Now imagine a web browser on venus and a web server on mars. Ordinarily, the web browser would have no way to contact the web server without using something like dynamic DNS, and even with dynamic DNS, mars's NAT has to have the 'endpoint-independent filtering' property. But with the scheme described in the document, a user on venus can type in "http://mars.solar-system.p2p" into her web browser to contact the web server on mars. No modification to the web browser code is required. The call flow to make this work is very similar to that given in the example. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 11:14:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryPK-00005V-5h; Tue, 13 Nov 2007 11:14:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryPI-00005G-Pn for p2psip@ietf.org; Tue, 13 Nov 2007 11:14:32 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IryPI-0003Bu-FY for p2psip@ietf.org; Tue, 13 Nov 2007 11:14:32 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IryPI-0005FP-0q; Tue, 13 Nov 2007 11:14:32 -0500 In-Reply-To: <20071113153835.D938333C3C@delta.rtfm.com> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <735C92F8-6E16-4F19-8E75-A4C38B0CAC52@magma.ca> <20071113153835.D938333C3C@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3555B349-7F2D-4882-B81A-6B7464EDE50D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 11:15:42 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 13-Nov-07, at 10:38 , Eric Rescorla wrote: >> >> I have heard some counter-arguments to this, from someone who knows a >> lot more about security than I do. > > Well, I'd certainly be interested in hearing them. I could of > course be wrong but it's not exactly a complicated line of > reasoning. It was Marcus Leech who I was having this discussion with. I have copied him so he can chime in. His arguments as I recall went roughly as follows. Even having a central authority to allocate peer ids doesn't prevent this attack. An attacker can go to the central authority, ask for a peer id, and if he doesn't like the results, generate a new identity and go back and ask for a new peer id. The root of the question is: how to you positively identify someone who wants to join? In a large open P2P system, you cannot possibly know the actual identities of everyone who is trying to join. For Skype, for example, all an attacker needs to do is think up a new Skype login name. For other systems, you need a valid e-mail address, but generating lots of e-mail addresses isn't hard either. There was more, but this was the part that I remember. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 11:24:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryYt-0001QY-Sv; Tue, 13 Nov 2007 11:24:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryYs-0001QB-5S for p2psip@ietf.org; Tue, 13 Nov 2007 11:24:26 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IryYr-0004cE-Q7 for p2psip@ietf.org; Tue, 13 Nov 2007 11:24:26 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IryYp-0000Dt-2M; Tue, 13 Nov 2007 11:24:23 -0500 In-Reply-To: <3555B349-7F2D-4882-B81A-6B7464EDE50D@magma.ca> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <735C92F8-6E16-4F19-8E75-A4C38B0CAC52@magma.ca> <20071113153835.D938333C3C@delta.rtfm.com> <3555B349-7F2D-4882-B81A-6B7464EDE50D@magma.ca> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 11:25:35 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org You can ignore this comment. I see that Marcus has already replied in a separate thread. - Philip On 13-Nov-07, at 11:15 , Philip Matthews wrote: > > On 13-Nov-07, at 10:38 , Eric Rescorla wrote: > > >>> >>> I have heard some counter-arguments to this, from someone who >>> knows a >>> lot more about security than I do. >> >> Well, I'd certainly be interested in hearing them. I could of >> course be wrong but it's not exactly a complicated line of >> reasoning. > > It was Marcus Leech who I was having this discussion with. I have > copied him so he can chime in. > > His arguments as I recall went roughly as follows. > > Even having a central authority to allocate peer ids doesn't > prevent this attack. An attacker can go to the central authority, > ask for a peer id, and if he doesn't like the results, generate a > new identity and go back and ask for a new peer id. > > The root of the question is: how to you positively identify someone > who wants to join? In a large open P2P system, you cannot possibly > know the actual identities of everyone who is trying to join. For > Skype, for example, all an attacker needs to do is think up a new > Skype login name. For other systems, you need a valid e-mail > address, but generating lots of e-mail addresses isn't hard either. > > There was more, but this was the part that I remember. > > - Philip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 11:25:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryZa-0001bM-SD; Tue, 13 Nov 2007 11:25:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryZZ-0001b1-0R for p2psip@ietf.org; Tue, 13 Nov 2007 11:25:09 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IryZY-0004eu-OZ for p2psip@ietf.org; Tue, 13 Nov 2007 11:25:08 -0500 Received: from macmini1.cs.columbia.edu (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lADGP7xD000393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Nov 2007 11:25:08 -0500 (EST) Message-Id: <66A12571-D541-43BE-B521-9352CC797CEC@cs.columbia.edu> From: Henning Schulzrinne To: Eric Rescorla In-Reply-To: <20071113153737.2DAF333C2B@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 11:25:08 -0500 References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> <4739A124.5000201@tm.uka.de> <20071113144407.DB43B33C58@delta.rtfm.com> <4739BF11.8020105@tm.uka.de> <20071113153737.2DAF333C2B@delta.rtfm.com> X-Mailer: Apple Mail (2.912) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > This is probably less of concern for this application. Mobile, low- power devices are not likely to make good peers, except in small ad- hoc style networks, where PoW probably isn't the right approach in any event. (Not that I'm defending use of PoW, as per my previous note.) > With the consequence that nobody on a limited-capability device > (like a phone handset) can do the puzzle at all > > -Ekr > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 11:29:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrydH-0002er-Tz; Tue, 13 Nov 2007 11:28:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryWS-0000zH-SX for p2psip@ietf.org; Tue, 13 Nov 2007 11:21:56 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrySd-00019r-BC for p2psip@ietf.org; Tue, 13 Nov 2007 11:18:25 -0500 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lADGHuq13252; Tue, 13 Nov 2007 16:17:56 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 11:17:56 -0500 Message-ID: In-Reply-To: <3555B349-7F2D-4882-B81A-6B7464EDE50D@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Thread-Index: AcgmEEg6sgs147y7QF64CRoRch1xOQAAGPjA References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <735C92F8-6E16-4F19-8E75-A4C38B0CAC52@magma.ca> <20071113153835.D938333C3C@delta.rtfm.com> <3555B349-7F2D-4882-B81A-6B7464EDE50D@magma.ca> From: "Marcus Leech" To: "Philip Matthews" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I sent a message a few messages back on this. =20 -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Tuesday, November 13, 2007 11:16 AM To: Eric Rescorla Cc: P2PSIP Mailing List; Leech, Marcus (CAR:1A12) Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP On 13-Nov-07, at 10:38 , Eric Rescorla wrote: >> >> I have heard some counter-arguments to this, from someone who knows a >> lot more about security than I do. > > Well, I'd certainly be interested in hearing them. I could of course=20 > be wrong but it's not exactly a complicated line of reasoning. It was Marcus Leech who I was having this discussion with. I have copied him so he can chime in. His arguments as I recall went roughly as follows. Even having a central authority to allocate peer ids doesn't prevent this attack. An attacker can go to the central authority, ask for a peer id, and if he doesn't like the results, generate a new identity and go back and ask for a new peer id. The root of the question is: how to you positively identify someone who wants to join? In a large open P2P system, you cannot possibly know the actual identities of everyone who is trying to join. For Skype, for example, all an attacker needs to do is think up a new Skype login name. For other systems, you need a valid e-mail address, but generating lots of e-mail addresses isn't hard either. There was more, but this was the part that I remember. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 11:30:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryeT-00033n-Co; Tue, 13 Nov 2007 11:30:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryeR-00033D-EM for p2psip@ietf.org; Tue, 13 Nov 2007 11:30:11 -0500 Received: from aplesnation.dom1.jhuapl.edu ([128.244.198.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IryeP-0002i7-6T for p2psip@ietf.org; Tue, 13 Nov 2007 11:30:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 11:30:08 -0500 Message-ID: <7B95239DDD54E54B9BFA23847142B1EE03065C93@aplesnation.dom1.jhuapl.edu> In-Reply-To: <66A12571-D541-43BE-B521-9352CC797CEC@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Thread-Index: AcgmEddaqg10uT0HQfOnJHLZyzkEuQAAIvAw References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca><7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu><24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com><7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca><4738CBAA.3000902@tm.uka.de><20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de><20071112234139.73AE233C2B@delta.rtfm.com><4739A124.5000201@tm.uka.de><20071113144407.DB43B33C58@delta.rtfm.com><4739BF11.8020105@tm.uka.de><20071113153737.2DAF333C2B@delta.rtfm.com> <66A12571-D541-43BE-B521-9352CC797CEC@cs.columbia.edu> From: "Wang, XiaoXiao (Sherry)" To: "Henning Schulzrinne" , "Eric Rescorla" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org How about a tank?=20 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Tuesday, November 13, 2007 11:25 AM To: Eric Rescorla Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP > This is probably less of concern for this application. Mobile, low- power devices are not likely to make good peers, except in small ad- hoc style networks, where PoW probably isn't the right approach in any event. (Not that I'm defending use of PoW, as per my previous note.) > With the consequence that nobody on a limited-capability device (like=20 > a phone handset) can do the puzzle at all > > -Ekr > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 11:30:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iryf2-0003Fo-PL; Tue, 13 Nov 2007 11:30:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iryf1-0003FU-EO for p2psip@ietf.org; Tue, 13 Nov 2007 11:30:47 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iryf0-0004tV-GW for p2psip@ietf.org; Tue, 13 Nov 2007 11:30:47 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lADGUiKP028206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Nov 2007 08:30:45 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lADGUhJO022940; Tue, 13 Nov 2007 10:30:44 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lADGUfBr022842; Tue, 13 Nov 2007 10:30:43 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 08:30:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 08:30:37 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049958@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Thread-Index: Acgk5OsatvMaQuLzQqmuzNdAayIhKwBIuRLQ References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> From: "Henderson, Thomas R" To: "Philip Matthews" X-OriginalArrivalTime: 13 Nov 2007 16:30:42.0955 (UTC) FILETIME=[88FC1DB0:01C82612] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Philip, I had a few comments on your draft: > OPEN ISSUE: What is the scope of this identifier (e.g., local node > only, overlay-wide, or global)? The IPv4 identifiers probably > have to be local, since are not enough to be global and maybe not > enough to be overlay-wide. The IPv6 identifiers could be global > (and be either identical to, or similar to, HIP's Host Identity > Tags (HITs)) or they could be just overlay-wide, however, either > would introduce a difference between the IPv4 and IPv6 identifiers > which might be undesirable. It seems to me that the question of what should be the scope of the identifier is determined by its usage and not its size. If they are identifying other peers in this system, I would think that they have to be global (in the context of this system) and not local? > If either X or Y change their real address, then an ICE exchange is > required to determine a new 5-tuple for each connection. For UDP, > this new 5-tuple is simply used in place of the old. > > OPEN ISSUE: For TCP, this doesn't work, since generating the new > 5-tuple requires a new TCP handshake. This seems to imply that > the TCP layer has to be aware of the change in address. So what > do we do? Do we just say "don't use null encapsulation for TCP if > you want mobility to work"? Or do we figure out how to make this > work? > The above (requiring TCP to resend a SYN exchange) seems to be fairly problematic from a deployment perspective. > Briefly, the idea is to define a new top-level domain, called ".p2p". > This domain is reserved for use in peer-to-peer overlays. An overlay > is then given a name underneath this top-level domain: > > .p2p > During recent review of our HIP applications draft* (which, by the way, discusses a lot of issues raised by this draft regarding the usage of identifiers by legacy applications), the above technique (creating a new private TLD) was frowned upon by the DNS directorate because it may cause root queries when leaked out of the system. Thomas Narten suggested that a prefix (rather than suffix) that was terminated by another special character than the dot (such as "p2p-") would be preferable, and we are going with that approach in the revision that will be published shortly. =20 * https://datatracker.ietf.org/drafts/draft-ietf-hip-applications/ > The fundamental concept in this document, that of an identifier for a > node which is distinct from the node's real addresses, has been > adopted from HIP. In HIP, this identifier (known as a HIT > [HIP-Base])is always an IPv6 identifier, and has global scope and > cryptographic properties, making it computationally hard for an > second node to steal a node's identity. (Current HIP implementations > also implement an IPv4 identifier as a local identifier, but the > properties of this IPv4 identifier are not currently specified > anywhere). The IPv4 identifier in HIP (the Local Scope Identifier) is just a 32-bit quantity that can be used as a local alias for a HIT. It should never be sent on the wire but can be used in the APIs and kernel data structures. It is possible also to have the same for IPv6 (a 128-bit LSI) but one might as well use the HIT, and when a HIT is used instead, one can basically support IPsec channel bindings to the application layer, as defined by the BTNS working group.=20 > HIP also introduces a number of other concepts, whose applicability > to p2p overlays is less obvious. > > The first is the use of ESP. In HIP, all data packets flowing > between two nodes use ESP to encrypt and integrity protect the > traffic [HIP-ESP]. At present, this is done for all traffic, even if > the traffic is already protected at a higher layer (e.g., using TLS > or application-level encryption). Does we want to encrypt and > integrity-protect *all* traffic, or should this decision be made on a > per-application basis? Do we want some way to avoid double > encryption: if so, how is this done? There have been previous suggestions to define an SRTP encapsulation for HIP, but not yet taken as a charter item for HIP WG: https://datatracker.ietf.org/drafts/draft-tschofenig-hiprg-hip-srtp/ > The second is the use of computational puzzles to prevent denial of > service attacks. Since all traffic is encrypted, when setting up a > HIP connection the two endpoints do a Diffie-Hellman exchange to > agree on a shared encryption key. Since this is computationally > expensive, the node initiating the connection must first solve a > computational puzzle generated by the destination, in order to make > it more difficult for a hostile initiator to cause the destination to > do a lot of work. However, it is not immediately clear how to extend > this concept to a peer-to-peer overlay where there are many more > connections involved and the different ways of launching denial-of- > service attacks seem larger. I think the above is mixing the discussion of two separate mechanisms: D-H exchange and client puzzles. The client (initiator) puzzles can be easily disabled if the server (responder) does not care about rate-limiting the clients. =20 > Finally, HIP has its own signaling protocol (also called HIP), and > the proper relationship of that protocol to the Peer Protocol is not > immediately clear. Should the functionality of HIP simply be added > to the Peer Protocol? Should HIP signaling be kept as a distinct > protocol and carried inside Peer Protocol messages (as proposed in > [WITH-HIP])? Or should HIP signaling be used to create connections > in the overlay instead of the Peer Protocol (as proposed in > [HIP-HOP])? My view is that the HIP protocol is a means to an end of getting two peers into a state where they have mutually authenticated one another (if they care to do so) and have enough shared secrets to prevent attacks on their network-layer mechanisms. If there is some other preferred means by which to get to this state that makes sense for particular applications, I would not have a problem with adapting or avoiding HIP signalling. However, the property of HIP that seems to have been lost in this proposal is the property that these identifiers cannot be hijacked. It seems like this approach is abandoning the good (security) aspects of HITs while leaving the bad (that they are pseudo-random bit fields and therefore difficult to aggregate, to look up in a hierarchical database, and to type in or remember). In other words, if you want to abandon the crypto properties of HITs, why not have applications use readable strings such as URIs as identifiers and simply define a way to hash such strings to address-sized values for use at the legacy socket APIs? (I think others have been providing similar feedback) Another question I have is what are the incremental deployment considerations of this approach? Does the P2PSIP app have to be able to work on a host that does not implement this shim? If not, could you make the assumption that the P2PSIP app is required to support IPv6 socket API and forget about IPv4? Regards, Tom _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 11:40:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryoJ-0005xc-UI; Tue, 13 Nov 2007 11:40:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryoH-0005x0-QR for p2psip@ietf.org; Tue, 13 Nov 2007 11:40:21 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IryoE-00037x-L6 for p2psip@ietf.org; Tue, 13 Nov 2007 11:40:21 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IryoC-0001xE-1K; Tue, 13 Nov 2007 11:40:16 -0500 In-Reply-To: <7d6b50690711121836r6a2c3e1bm406178233d35e741@mail.gmail.com> References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <4731ED7B.2070901@sip-communicator.org> <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> <009b01c8250e$62a305c0$da07740a@DELLWEI> <7d6b50690711121836r6a2c3e1bm406178233d35e741@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Proposal for progress on protocols Date: Tue, 13 Nov 2007 11:41:27 -0500 To: lichun li , Zheng Hewen , Yao Wang , Wei Gengyu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org As a working group member, I am encouraged by the debate on the existence and nature of the P2PSIP client, and the proposals for a Client Protocol. But as a co-author of the Concepts draft, I think it is premature to modify the discussion on Clients in the draft. It is not that I don't want to do this, it is just that I think there is no consensus yet on the nature or even existence of clients. I think we are coming up to the point where there will be a major revision to the Concepts draft that will focus in on a specific architecture and mechanisms, and that revision may well include a major revision in the section on clients. But I don't think it should be the revision for this cycle. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 11:42:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iryqk-0007QW-LC; Tue, 13 Nov 2007 11:42:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryWT-0000sD-On for p2psip@ietf.org; Tue, 13 Nov 2007 11:21:57 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrySC-00015T-BI for p2psip@ietf.org; Tue, 13 Nov 2007 11:17:54 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IryRh-0006s4-2M; Tue, 13 Nov 2007 11:17:01 -0500 In-Reply-To: <20071113144254.C36F233C57@delta.rtfm.com> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4738CBAA.3000902@tm.uka.de> <20071112220620.DAE4733C2B@delta.rtfm.com> <4738DADB.305@tm.uka.de> <20071112234139.73AE233C2B@delta.rtfm.com> <4739772F.4050200@uni-tuebingen.de> <47398FB8.2090203@ericsson.com> <20071113144254.C36F233C57@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 11:18:41 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 13-Nov-07, at 09:42 , Eric Rescorla wrote: > This *still* needs a PKI-like structure because there's no way to > distinguish valid from invalid key pairs, at least for conventional > cryptographic tecniques like RSA. (You can with unconventional > techniques like IBE and IBS.) Can you provide more detail on this? What do you mean by a valid vs invalid key pair? If I encrypt something with someone's public key, and that person proves to me that he can decrypt it (say by decrypting it and then re-encrypting it with my public key), then doesn't that show the key pair is valid? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 11:44:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irys8-0008FT-VK; Tue, 13 Nov 2007 11:44:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irys6-0008Ej-SR for p2psip@ietf.org; Tue, 13 Nov 2007 11:44:18 -0500 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irys6-0005cZ-F2 for p2psip@ietf.org; Tue, 13 Nov 2007 11:44:18 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lADGi5ZQ018536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Nov 2007 08:44:08 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lADGi4pQ022500; Tue, 13 Nov 2007 10:44:05 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lADGhiQ0021738; Tue, 13 Nov 2007 10:44:03 -0600 (CST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Nov 2007 08:44:03 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 08:43:56 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D04049959@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Thread-Index: Acglbxfyvro1WO08SmqLPkJYxsGGkgAo3kmQ References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca><7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu><24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com><7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> From: "Henderson, Thomas R" To: "Henning Schulzrinne" , "Philip Matthews" X-OriginalArrivalTime: 13 Nov 2007 16:44:03.0377 (UTC) FILETIME=[6612D210:01C82614] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "Zheng, Harold" , Henry Sinnreich , "Cole, Robert G." , "Wang, XiaoXiao \(Sherry\)" , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 > Sent: Monday, November 12, 2007 1:00 PM > To: Philip Matthews > Cc: Zheng, Harold; Henry Sinnreich; Cole,Robert G.;=20 > Wang,XiaoXiao (Sherry); P2PSIP Mailing List > Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP >=20 > The notion of using the IP stack transparently seems dubious,=20 > as this =20 > would require quite a few restrictions on the identifier, leaving =20 > issues of how to implement this aside. I'm also doubting that=20 > this is =20 > useful, since we really do not want to route all packets through the =20 > overlay, only the first one, for efficiency reasons. I did not read that the proposal was to make all packets traverse the overlay. Only the initial-contact and rendezvous-related packets need to traverse the overlay, but ICE is used to find the right addresses and ports to later avoid the overlay. FWIW, HIP implementations work this way and there have been other overlay implementations such as i3, TESLA, and UIP that have successfully worked in this manner. >=20 > On the numbering issue: The numbering space would have to exclude > - the RFC 1918 ranges > - the local address ranges (since routing would likely direct=20 > this to =20 > the local interface and bypass routing) > - class E addresses There has already been an IPv6 prefix assigned for these types of identifiers (see ORCHIDs in RFC 4843). >=20 > The socket call would have to say "this is a real IPv4/IPv6 address, =20 > not an overlay address". How? If you designate this as a different =20 > protocol, in parallel to IPv4 and IPv6, you could just as well use a =20 > node ID of any length. >=20 Either the socket API has to be extended, or the API could be kept the same if such "addresses" can be distinguished from other IPv6 addresses, such as ORCHIDs. Tom _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 12:02:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irz9d-0001GD-3C; Tue, 13 Nov 2007 12:02:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irz9Z-0001Cp-3N for p2psip@ietf.org; Tue, 13 Nov 2007 12:02:21 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irz9Y-0006Zz-LQ for p2psip@ietf.org; Tue, 13 Nov 2007 12:02:21 -0500 Received: from macmini1.cs.columbia.edu (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lADH2Jfj013006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 13 Nov 2007 12:02:19 -0500 (EST) Message-Id: <71930412-F610-49ED-B544-389E072C8593@cs.columbia.edu> From: Henning Schulzrinne To: Philip Matthews In-Reply-To: <4D72FD2D-0FA4-4F0F-BABA-13965B4A0CB8@magma.ca> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 12:02:19 -0500 References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4D72FD2D-0FA4-4F0F-BABA-13965B4A0CB8@magma.ca> X-Mailer: Apple Mail (2.912) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This severely limits the size of the overlay; this also requires modifying the kernel in rather significant ways, which seems to be a lot harder to deploy than a new application. I admit that I find the DNS model, namely treating the DHT as a naming translator, to be far more general than a NAT model. Given the presentations about address shortages, I also don't share your enthusiasm that the RIRs will hand out address blocks for non-routing applications. I admit that I find this whole approach to be a hack, since you're making something look like something that it is not. Since routing packets is only a small fraction of what an IP stack does, you now have to worry about interactions with ipfilter, DHCP, ICMP, ARP and a host of other protocols and stack assumptions. If we want to treat this as equivalent of a VPN, using an IPv6 range seems far more productive. Henning On Nov 13, 2007, at 10:09 AM, Philip Matthews wrote: > > Hi Henning: > > Sorry for not being clearer in the document. The goal of this work > is not to route all packets through the overlay. On the contrary, > the goal is to have the vast majority of packets go directly from > the originator to the destination, without passing through > intermediate peers. > > The signaling to set up a direct connection needs to be routed > through the overlay in many cases. But once that direct connection > is set up, packets can flow directly. > > For IPv4, the identifier is of local significance only, and is > mapped to the real address and port of the destination before the > packet is transmitted. > > I have already discussed the numbering issue in a separate reply. > But the short answer is that we can probably get away with a /14 or / > 16 for the IPv4 identifier. This I think we have a reasonable > chance of getting allocated to us. > > - Philip > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 12:25:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrzWM-0007RY-UT; Tue, 13 Nov 2007 12:25:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrzWL-0007O8-N0 for p2psip@ietf.org; Tue, 13 Nov 2007 12:25:53 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrzWI-0005LP-9O for p2psip@ietf.org; Tue, 13 Nov 2007 12:25:53 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IrzWB-0004zs-2U; Tue, 13 Nov 2007 12:25:44 -0500 In-Reply-To: <000001c8259b$455a17f0$9a00a8c0@mlifewangyao> References: <000001c8259b$455a17f0$9a00a8c0@mlifewangyao> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <217ACF93-FEDB-4047-B048-5EE9FA876077@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Proposal for progress on protocols Date: Tue, 13 Nov 2007 12:26:53 -0500 To: Yao Wang X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 12-Nov-07, at 21:16 , Yao Wang wrote: > Agree on "At least we can reach the agreement about P2PSIP client > character according to the Reference model before completing > standardization of P2PSIP peer protocol" > > In my opinion, a document specifying the exact characters of P2PSIP > Client and the requirements of P2PSIP Client Protocol based on the > consensus of this WG is needed before the standardization of client > protocol and peer protocol. > What I think we need is a client proposal that people feel makes sense - not necessarily in the fine details, but in the overall direction. The new proposals just published may do that -- let's see what people think in Vancouver. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 12:54:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irzxm-0004s1-09; Tue, 13 Nov 2007 12:54:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irzxk-0004qi-3P for p2psip@ietf.org; Tue, 13 Nov 2007 12:54:12 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Irzxj-0000Js-Je for p2psip@ietf.org; Tue, 13 Nov 2007 12:54:11 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Irzxi-0002Lq-2v; Tue, 13 Nov 2007 12:54:10 -0500 In-Reply-To: <71930412-F610-49ED-B544-389E072C8593@cs.columbia.edu> References: <0DB1740B-5C0E-4A9C-AF4B-0E2831D35F68@magma.ca> <7B95239DDD54E54B9BFA23847142B1EE03065B75@aplesnation.dom1.jhuapl.edu> <24CCCC428EFEA2469BF046DB3C7A8D223AE290@namail5.corp.adobe.com> <7474DA56-DD91-43EE-8025-B175E38B95A4@magma.ca> <4D72FD2D-0FA4-4F0F-BABA-13965B4A0CB8@magma.ca> <71930412-F610-49ED-B544-389E072C8593@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <31A123E1-6DEC-428F-9067-008A4F965442@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] New draft: An ID/Locator Architecture for P2PSIP Date: Tue, 13 Nov 2007 12:55:20 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This doesn't limit the size of the overlay, since a peer only needs to assign identifiers to remote peers that it wants to talk to. This is why I think the IPv4 identifier needs to be distinct from the Peer ID. Though a kernel implementation is clearly a desirable long-term approach, two other short-term approaches are possible. One is an approach where the packet is intercepted below the IP layer and sent to a user-space process for modification. Tom Henderson's group at Boeing has implemented HIP on both OS X and Windows using this technique. The other is to use a library implementation of TCP/UDP/... But I agree that IPv6 offers the possibility of a much more architecturally pure solution, and supporting IPv4 identifiers is a bit of a hack. But the IPv4 hacks seem very attractive because of the potential gains. - Philip On 13-Nov-07, at 12:02 , Henning Schulzrinne wrote: > This severely limits the size of the overlay; this also requires > modifying the kernel in rather significant ways, which seems to be > a lot harder to deploy than a new application. I admit that I find > the DNS model, namely treating the DHT as a naming translator, to > be far more general than a NAT model. Given the presentations about > address shortages, I also don't share your enthusiasm that the RIRs > will hand out address blocks for non-routing applications. > > I admit that I find this whole approach to be a hack, since you're > making something look like something that it is not. Since routing > packets is only a small fraction of what an IP stack does, you now > have to worry about interactions with ipfilter, DHCP, ICMP, ARP and > a host of other protocols and stack assumptions. > > If we want to treat this as equivalent of a VPN, using an IPv6 > range seems far more productive. > > Henning > > On Nov 13, 2007, at 10:09 AM, Philip Matthews wrote: > >> >> Hi Henning: >> >> Sorry for not being clearer in the document. The goal of this work >> is not to route all packets through the overlay. On the contrary, >> the goal is to have the vast majority of packets go directly from >> the originator to the destination, without passing through >> intermediate peers. >> >> The signaling to set up a direct connection needs to be routed >> through the overlay in many cases. But once that direct connection >> is set up, packets can flow directly. >> >> For IPv4, the identifier is of local significance only, and is >> mapped to the real address and port of the destination before the >> packet is transmitted. >> >> I have already discussed the numbering issue in a separate reply. >> But the short answer is that we can probably get away with a /14 >> or /16 for the IPv4 identifier. This I think we have a reasonable >> chance of getting allocated to us. >> >> - Philip >> >> >> > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 14:42:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1f0-00045z-CI; Tue, 13 Nov 2007 14:42:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is1ez-00044d-Jc for p2psip@ietf.org; Tue, 13 Nov 2007 14:42:57 -0500 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is1ew-0001Wp-4e for p2psip@ietf.org; Tue, 13 Nov 2007 14:42:57 -0500 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Tue, 13 Nov 2007 11:42:43 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lADJgcKn003990; Tue, 13 Nov 2007 11:42:39 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lADJgVFb016369; Tue, 13 Nov 2007 11:42:37 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 04:42:31 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: client protocol ([P2PSIP] Proposal for progress on protocols) Date: Tue, 13 Nov 2007 11:42:23 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE2A6@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: client protocol ([P2PSIP] Proposal for progress on protocols) Thread-Index: AcgmE+4NnH/c5CnFSFGInPlIVgu/4gAF0t2g References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu><4731ED7B.2070901@sip-communicator.org><3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com><009b01c8250e$62a305c0$da07740a@DELLWEI><7d6b50690711121836r6a2c3e1bm406178233d35e741@mail.gmail.com> From: "Henry Sinnreich" To: "Philip Matthews" , "lichun li" , "Zheng Hewen" , "Yao Wang" , "Wei Gengyu" X-OriginalArrivalTime: 13 Nov 2007 19:42:31.0982 (UTC) FILETIME=[54E644E0:01C8262D] X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I think there is no consensus =20 > yet on the nature or even existence of clients. >From this list I understand there is less a problem with the existence of clients, but rather if there should be a separate client protocol.=20 Also, some folks mentioned that the client protocol should just be a subset of the peer protocol. Is this understanding of the discussions correct? Given the preponderance of mobile devices, this alone would justify a new version of the concepts document. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Tuesday, November 13, 2007 10:41 AM To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols As a working group member, I am encouraged by the debate on the =20 existence and nature of the P2PSIP client, and the proposals for a =20 Client Protocol. But as a co-author of the Concepts draft, I think it is premature to =20 modify the discussion on Clients in the draft. It is not that I =20 don't want to do this, it is just that I think there is no consensus =20 yet on the nature or even existence of clients. I think we are coming up to the point where there will be a major =20 revision to the Concepts draft that will focus in on a specific =20 architecture and mechanisms, and that revision may well include a =20 major revision in the section on clients. But I don't think it should =20 be the revision for this cycle. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 15:55:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2nI-0001CI-94; Tue, 13 Nov 2007 15:55:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is2nG-0001Ac-Ov for p2psip@ietf.org; Tue, 13 Nov 2007 15:55:34 -0500 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is2nD-0004B0-I4 for p2psip@ietf.org; Tue, 13 Nov 2007 15:55:34 -0500 Received: by ug-out-1314.google.com with SMTP id u2so539803uge for ; Tue, 13 Nov 2007 12:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Cgj1Dm9UQETkdpk8+p3fBIYjA6DwCWgcOQsDExpzPBc=; b=Ccn+6jOZHw00OjRbogb/ZaIsPhHCrp86+hoc+FDWV43XzgtdQjx98cbr5Swqu5yNRPVklKjviXHEB0UN1IrEyCBnY499bQhAQrr0lyMRlqivSQckVnhi8mNMJ9HWo0371wpAFgCNQNe+haCvss5dun2I7CLGFcM2W14xQtH7Tng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f0WBB6G2uwIfsxhhdn/rIVgX0eaA5VSFEOZSDxMsSZ31wfU0NDfD2eo2SxPTP7C+NKklaAVhkpsTkF1szzNmSPKm/HJz3/se/V/Pr0XrjZfTh8TYQ6sqQNZdQax3/3kcpMZHeOlWF5pvhe52wHZE1/Jw1y3RsyrxzQ9H1e9da5w= Received: by 10.66.243.2 with SMTP id q2mr367219ugh.1194987330691; Tue, 13 Nov 2007 12:55:30 -0800 (PST) Received: by 10.66.252.5 with HTTP; Tue, 13 Nov 2007 12:55:30 -0800 (PST) Message-ID: <618e24240711131255x5617bc56p7622f981576130f8@mail.gmail.com> Date: Tue, 13 Nov 2007 21:55:30 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: "Henry Sinnreich" Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols) In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE2A6@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <4731ED7B.2070901@sip-communicator.org> <3F18E76823C95E4795181D74BAC7664F0561BEB3@esebe102.NOE.Nokia.com> <009b01c8250e$62a305c0$da07740a@DELLWEI> <7d6b50690711121836r6a2c3e1bm406178233d35e741@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2A6@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 13/11/2007, Henry Sinnreich wrote: > >From this list I understand there is less a problem with the existence > of clients, but rather if there should be a separate client protocol. > > Also, some folks mentioned that the client protocol should just be a > subset of the peer protocol. > > Is this understanding of the discussions correct? This is how I understand the discussions. Considering Peers to offer at least routing and storage capabilities, some of us understand Clients to offer only storage. In this way, as said in previous messages, we should consider three main types of node: peers (nodes to perform the overlay and offer storage and routing capabilities and they are coupled with one or more SIP entities), clients (nodes to contribute its storage capacity to its associated peer and they are coupled with SIP UA) and SIP [RFC3161] (UA with no other capabilities). Clients and SIP UA will reach P2PSIP overlay through peers. While Clients will store some information, peers will store information on behalf of SIP UA. Since Peers and Clients would need to exchange some kind of information, what is a subset of information exchanged between peers + other possible data with other periodicity, requirements for the Client protocol can be considered to be different from the Peer protocol. Thus, Peer <---- Peer Protocol ----> Peer Client <---- Client Protocol ----> Peer SIP UA <---- SIP [RFC3261] ----> Peer As an example, I imagine Peers storing 'general' AoR information and user preferences while Clients would store only 'their buddies' AoR information. Thank you, Victor Pascual _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 16:11:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is32y-0003EY-OR; Tue, 13 Nov 2007 16:11:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is32y-0003ET-8L for p2psip@ietf.org; Tue, 13 Nov 2007 16:11:48 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is32x-00007a-Rr for p2psip@ietf.org; Tue, 13 Nov 2007 16:11:48 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRG00D5TQVN2V@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 13:11:47 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRG00N05QVL2K@usaga01-in.huawei.com> for p2psip@ietf.org; Tue, 13 Nov 2007 13:11:47 -0800 (PST) Date: Tue, 13 Nov 2007 15:10:53 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Proposal for progress on protocols To: P2PSIP Mailing List Message-id: <04e001c82639$ad301520$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <26C1E4C4-20D2-4890-B1C0-7EB22BFFBDC6@cs.columbia.edu> <4735D416.6050400@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Jonathan, >I think Philips presentation and the slides he put together last time were >meant to do exactly this kind of thing - to show in what ways various >proposals were the same, and where they were different. I understood Henning's proposal to be a request for more of the same type of discussion. That's why I agreed with Henning that this would be helpful. > That said, what I do NOT want to do, is to try and work through each and > every issue for a p2p protocol through a group consensus process, and then > assemble the results into a built-from-ground-up working group document. > I've seen that process tried before in other groups (midcom, the impp > protocols), and in each case it has been a dismal failure, taking a long > time and producing results no one liked. You left out http://en.wikipedia.org/wiki/Frankenstein#Plot, but I'm not sure which working group did that one :-) ("I agree with your point here") > I'd prefer to do what we normally do - adopt one of the drafts as a > working group item and make changes from there based on discussions. Note > that, just because a document is adopted as a working group item doesn't > mean it can't be changed. But it does mean that the document is believed > to be on the right track and a "good starting point" for producing the > final deliverable. I'm not sure if we've gotten to this point yet, but I agree that this is where we should be headed. As an example of the kind of discussion we need to finish, we had conversations about running other peer protocols OVER HIPHOP in Chicago. I'd like to better understand our range of choices. Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 21:41:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is8BW-0001gL-Gi; Tue, 13 Nov 2007 21:40:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is8BV-0001fA-1c for p2psip@ietf.org; Tue, 13 Nov 2007 21:40:57 -0500 Received: from rn-out-0910.google.com ([64.233.170.190] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is8BT-0002Rz-GL for p2psip@ietf.org; Tue, 13 Nov 2007 21:40:57 -0500 Received: by rn-out-0102.google.com with SMTP id a46so34875rne for ; Tue, 13 Nov 2007 18:40:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=pUqifij27IJC0+PIdRJZMJKPmUi0yzxb6niAhej4yp8=; b=XnsRFL6DMzz+Sgp7JcHed/69h8GkpI8HVaVRKj56ipAGLk5Bd3oxZE8xDvNsZ3aj8ZqVvkNV8ttaW6zClpnS08Hdg08ZufdMn1cyKwJyIOokAhABaArf/SG5xH7PFa44s8lLQ9Z5VblCf2NVCAmqf/YFy91LlhmAUOy2T6e/tMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lIo7vbRDvIRR4ObRwNt+jpr+CN7G+KR2frd9yPgUYr6bEtTA1nYyp5vyjtU7D6CKLLDy1fdGV/e+K2S1rvwi8a/8pMHnInaDR+2TO1SpwuNg7PWSJtY5hQvJ5esdhQml8mckK5028KxEkN2YCh5sdWI7CAXjMTiUmr8mRAI0AZE= Received: by 10.142.140.14 with SMTP id n14mr636052wfd.1195008053532; Tue, 13 Nov 2007 18:40:53 -0800 (PST) Received: by 10.142.200.16 with HTTP; Tue, 13 Nov 2007 18:40:53 -0800 (PST) Message-ID: <7d6b50690711131840g7a14db16wb4b923a7126ae21a@mail.gmail.com> Date: Wed, 14 Nov 2007 10:40:53 +0800 From: "lichun li" To: "Ingmar Baumgart" Subject: Re: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) In-Reply-To: <47349F0A.5090201@tm.uka.de> MIME-Version: 1.0 References: <47349F0A.5090201@tm.uka.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1658492960==" Errors-To: p2psip-bounces@ietf.org --===============1658492960== Content-Type: multipart/alternative; boundary="----=_Part_31204_15827799.1195008053483" ------=_Part_31204_15827799.1195008053483 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I am a little confused about "5.2.1 Two-stage Name Resolution". I guess the two stages are: 1. resolving P2PName to nodeID in DHT; 2. resolving P2PName to transport address at the node with the nodeID. Is that right? According to concept draft, a peer might be coupled with two or more SIP entities. So different P2PNames might be mapping to the same nodeID? On 11/10/07, Ingmar Baumgart wrote: > > Dear working group, > > I've submitted a draft for a Peer-to-Peer Name Service (P2PNS) which can > be used to resolve AoRs to Contact URIs without using DNS. > > The main contribution is on two aspects: One is reusability of the name > service for things like distributed DNS or HIP. The other is security in > a completely decentralized environment (without login severs). > > Until it is on the official servers, you can get it from here: > > http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.txt > http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.html > > Some additional information about the implementation can be found in > this P2P2007 demo abstract: > > http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf > > Regards, > Ingmar > > -- > Dipl.-Inform. Ingmar Baumgart > Institut f=FCr Telematik, Universit=E4t Karlsruhe (TH) > Zirkel 2, 76128 Karlsruhe, Germany > Phone: +49 721 608 8281, Fax: +49 721 608 6789 > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_31204_15827799.1195008053483 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
I am a little confused about "5.2.1 Two-stage Name Resolutio= n".
I guess the two stages are: 1. resolving P2PName to nodeID in DHT= ; 2. resolving P2PName to transport address at the node with the nodeI= D. Is that right?
According to concept draft, a peer might be coupled with two or m= ore SIP entities. So different P2PNames might be mapping to the same n= odeID? 
 
On 11/10/07, Ingmar Baumgart <baumgart@tm.= uka.de> wrote:
Dear working group,

I'= ;ve submitted a draft for a Peer-to-Peer Name Service (P2PNS) which can
be used to resolve AoRs to Contact URIs without using DNS.

The main = contribution is on two aspects: One is reusability of the name
service f= or things like distributed DNS or HIP. The other is security in
a comple= tely decentralized environment (without login severs).

Until it is on the official servers, you can get it from here:
<= br>http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.txt
http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.html

So= me additional information about the implementation can be found in
this = P2P2007 demo abstract:

http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf

Regards,
Ingma= r

--
Dipl.-Inform. Ingmar Baumgart
Institut f=FCr Telematik, U= niversit=E4t Karlsruhe (TH)
Zirkel 2, 76128 Karlsruhe, Germany
Phone:= +49 721 608 8281, Fax: +49 721 608 6789

_______________________________________________
P2PSIP mailing l= ist
P2PSIP@ietf.org
https://www1.ietf.org/mailm= an/listinfo/p2psip



--
Sincerely yours= ,

Lichun Li
Mobile Life New Media Lab, BUPT=20 ------=_Part_31204_15827799.1195008053483-- --===============1658492960== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1658492960==-- From p2psip-bounces@ietf.org Tue Nov 13 22:21:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is8oI-0005nh-SK; Tue, 13 Nov 2007 22:21:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is8oG-0005jq-U5 for p2psip@ietf.org; Tue, 13 Nov 2007 22:21:00 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is8oG-0000BW-4a for p2psip@ietf.org; Tue, 13 Nov 2007 22:21:00 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH007P17YVV1@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 11:20:55 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH00I0J7YULJ@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 11:20:55 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRH00NFE7YQ0F@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 11:20:54 +0800 (CST) Date: Wed, 14 Nov 2007 11:20:50 +0800 From: Zheng Hewen In-reply-to: <618e24240711131255x5617bc56p7622f981576130f8@mail.gmail.com> To: 'Victor Pascual =?UNKNOWN?B?qKJ2aWxhJw==?= , 'Henry Sinnreich' Message-id: <000601c8266d$5bbb4730$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: AcgmOPdaEgWD5u9jS6++NLJuYmzfDQAMjSag X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: 'Philip Matthews' , 'P2PSIP Mailing List' Subject: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, all, The time in Vancouver is limited and very precious. After those discussion about P2PSIP client in the latest ma= il list, a survey about P2PSIP client charcater/behavior=20 among active members in this work group will be very helpful for the = further discussion in Vancouver. As Victor Pascual =A8=A2vila said, there are mainly three t= ypes of nodes: (1).Peers (nodes to perform the overlay and offer storage a= nd routing capabilities and they are coupled WITH one or=20 more SIP entities or WITHOUT any SIP entity, overlay-routing nodes), (2).Clients (nodes to contribute its storage capacity to it= s associated peer and they are coupled with SIP UA,=20 non-overlay-routing nodes); (3).SIP [RFC3161] (UA with no other capabilities). Any comment? We suggest that the revised Concept document would clarify = the P2PSIP client character if an agreement about P2PSIP=20 client character is reached in the mail list. Best regards, Hewen -----Original Message----- =46rom: Victor Pascual =A8=A2vila [mailto:victor.pascual.avila@gmail.= com] Sent: 2007=C4=EA11=D4=C214=C8=D5 4:56 To: Henry Sinnreich Cc: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu; P2= PSIP Mailing List Subject: Re: client protocol ([P2PSIP] Proposal for progress on proto= cols) On 13/11/2007, Henry Sinnreich wrote: > >From this list I understand there is less a problem with the > >existence > of clients, but rather if there should be a separate client protoco= l. > > Also, some folks mentioned that the client protocol should just be = a > subset of the peer protocol. > > Is this understanding of the discussions correct? This is how I understand the discussions. Considering Peers to offer at least routing and storage capabilities,= some of us understand Clients to offer only storage. In=20 this way, as said in previous messages, we should consider three main= types of node: peers (nodes to perform the overlay and offer storage and routi= ng capabilities and they are coupled with one or more SIP=20 entities), clients (nodes to contribute its storage capacity to its a= ssociated peer and they are coupled with SIP UA) and SIP=20 [RFC3161] (UA with no other capabilities). Clients and SIP UA will reach P2PSIP overlay through peers. While Cli= ents will store some information, peers will store=20 information on behalf of SIP UA. Since Peers and Clients would need to exchange some kind of informati= on, what is a subset of information exchanged between=20 peers + other possible data with other periodicity, requirements for = the Client protocol can be considered to be different=20 =66rom the Peer protocol. Thus, Peer <---- Peer Protocol ----> Peer Client <---- Client Protocol ----> Peer SIP UA <---- SIP [RFC3261] ----> Peer As an example, I imagine Peers storing 'general' AoR information and = user preferences while Clients would store only 'their=20 buddies' AoR information. Thank you, Victor Pascual _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 22:28:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is8vG-0007Pe-SC; Tue, 13 Nov 2007 22:28:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is8vG-0007Ma-4O for p2psip@ietf.org; Tue, 13 Nov 2007 22:28:14 -0500 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is8vD-00034L-Bs for p2psip@ietf.org; Tue, 13 Nov 2007 22:28:14 -0500 Received: by wa-out-1112.google.com with SMTP id k40so61494wah for ; Tue, 13 Nov 2007 19:28:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; bh=vdJJYU+ZVcm4PBfDy782C+irFIMqbqpIOPO1sE4V0f4=; b=txCyqz+I3wLOTYuUyiHyheFqMnCxgak7i5g2+WBCDFh5vFnEeX2ZKr31zPmY6VgEqx7TvJ5h74UNAaRuPldGF4MMbsz/s4B4LfuGC3C5/H8DwMGLot2UHNl9BtmzIwIB1YTBEyo3aIoCsHnKmwZYmbKhI8NIMmZ2KEoGv889iCs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:cc:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:in-reply-to:x-mimeole:thread-index; b=nB63svGWly/wXx0PaUApxzjfeXkE8bnJtzBEZzkl54cpZyYBKfLaukDjRqhTOGjHYVHkt3ecAnBRevDouxjNAIj5AnuO/SfRD6mXhZjYz553e8Xf019J7ISWlSv0ppYX/tooq9Va9fPeUC7nNF0pWD45zlLWp5Of8ViufjYuLDE= Received: by 10.114.174.2 with SMTP id w2mr172747wae.1195010890289; Tue, 13 Nov 2007 19:28:10 -0800 (PST) Received: from mlifewangyao ( [123.116.135.129]) by mx.google.com with ESMTPS id n30sm227070wag.2007.11.13.19.28.07 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Nov 2007 19:28:10 -0800 (PST) From: "Yao Wang" To: "'Henry Sinnreich'" , "'Philip Matthews'" , "'lichun li'" , "'Zheng Hewen'" , "'Wei Gengyu'" Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) Date: Wed, 14 Nov 2007 11:28:58 +0800 Message-ID: <004201c8266e$80ee0640$9a00a8c0@mlifewangyao> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE2A6@namail5.corp.adobe.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgmE+4NnH/c5CnFSFGInPlIVgu/4gAF0t2gAA4MIdA= X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Yes, you are right. Currently, the main difference in the debate comes from how to build the = client protocol, whether it could be based on SIP, whether it could be a = syntax subset of Peer Protocol, or whether it is a separate protocol = different from both SIP and Peer Protocol but its function is subset of = the functions of Peer Protocol.=20 Here are some of my understandings, 1. What services client can get using Client Protocol? In my opinion, there are two kinds of services. Firstly, from the charter of this WG, this WG "is chartered to develop = protocols and mechanisms for the use of the Session Initiation Protocol = (SIP)". It is clearly that SIP service (including locating target user, = forwarding SIP messages) is a basic service that P2PSIP Overlay MUST = provide. Client Protocol MUST enable client to access this services. Secondly, services other than SIP. As mentioned in concept draft, some = individual peers may provide services in addition to storage and = routing, for example STUN services, to the overlay. However, because = clients do not join P2PSIP Overlay, they can not discover these services = directly. Therefore, client protocol MUST provide a mean for client to = know what services are available in the P2PSIP Overlay and the = comprehensive parameters for access these services. After getting these = parameters, the client can use other protocols, for example STUN, to = access the service, which should be out of the scope of client protocol. = To meet the first kind of requirements, SIP is mandatory. When it comes = to the second kind of requirements, both SIP and other protocol (e.g. a = subset of peer protocol) can work.=20 If the subset of peer protocol is adopted as client protocol (supposing = the peer protocol is not SIP-based), the client _has_ _to_ run two = protocol stacks at the same time, which obviously consumes more = resources of client than only running SIP stack. Given the assumption = that clients are resource-limited devices, running one more protocol = stack may cause the degradation of its performances. Thus, why not use SIP and SIP extensions to satisfy both requirements? = why not kill two birds with one stone? Currently, many mobile devices = have been equipped with SIP; the reuse of SIP in client protocol not = only reduces the resource needed on client devices but also reduces the = implementation complexity of client protocol.=20 2. What services peer can get using Client Protocol? It seems that people in this list accept that the client should = contribute its storage capacity to peers. In my opinion, the client can = provide more service than that. Here is one possible example which is = described in our proposed draft ("A SIP-based P2PSIP Client Protocol") "For example, a conferences server wants to provide conference services = to nodes in a P2PSIP system. Because the decoding, mixture and encoding = of multiple media streams can be quite a heavy load for its = computational resources, this conference server may choose not to join = in the P2PSIP overlay. Thus, some extra resources, which would be = used for the maintenance of P2P overlay if the server joined overlay, = can be utilized for providing better conference services." Therefore, the client protocol must be extensible for supporting any = possible services. SIP is a well-developed extensible signal protocol, = thus, we propose to build client protocol based on SIP. Any comments? Sincerely yours, =20 Yao Wang=20 Mobile Life and New Media Lab, BUPT -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, November 14, 2007 3:42 AM To: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu Cc: P2PSIP Mailing List Subject: client protocol ([P2PSIP] Proposal for progress on protocols) > I think there is no consensus =20 > yet on the nature or even existence of clients. >From this list I understand there is less a problem with the existence of clients, but rather if there should be a separate client protocol.=20 Also, some folks mentioned that the client protocol should just be a subset of the peer protocol. Is this understanding of the discussions correct? Given the preponderance of mobile devices, this alone would justify a new version of the concepts document. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Tuesday, November 13, 2007 10:41 AM To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols As a working group member, I am encouraged by the debate on the =20 existence and nature of the P2PSIP client, and the proposals for a =20 Client Protocol. But as a co-author of the Concepts draft, I think it is premature to =20 modify the discussion on Clients in the draft. It is not that I =20 don't want to do this, it is just that I think there is no consensus =20 yet on the nature or even existence of clients. I think we are coming up to the point where there will be a major =20 revision to the Concepts draft that will focus in on a specific =20 architecture and mechanisms, and that revision may well include a =20 major revision in the section on clients. But I don't think it should =20 be the revision for this cycle. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 22:51:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9Hh-0004ZV-Q9; Tue, 13 Nov 2007 22:51:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9Hg-0004Yx-J0 for p2psip@ietf.org; Tue, 13 Nov 2007 22:51:24 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is9Hf-0000fg-Po for p2psip@ietf.org; Tue, 13 Nov 2007 22:51:24 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH0060D9DKSB@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 11:51:20 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH001HO9DI8V@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 11:51:20 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRH00NIS9DF0F@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 11:51:18 +0800 (CST) Date: Wed, 14 Nov 2007 11:51:14 +0800 From: Zheng Hewen Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D223AE2A6@namail5.corp.adobe.com> To: 'Henry Sinnreich' , 'Philip Matthews' , 'lichun li' , 'Yao Wang' , 'Wei Gengyu' Message-id: <000701c82671$9af35f60$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcgmE+4NnH/c5CnFSFGInPlIVgu/4gAF0t2gABC17PA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, all, From current discussion in the mail list, nobody doubts the Reference Model defined the Concept document, nobody doubts the existence of clients. Do I understand it correctly? The Reference model is clear, why do we see the description about P2PSIP client behavior in Section 5.5 of the Concept document? The difference in only about the form of client protocol, P2PP and ASP think that the client protocol is the subset of the peer protocol; RELOAD thinks that unmodified SIP is enough and separate client protocol is not necessary, any other? But those do not impact the try to reach agreement on the P2PSIP client character/behavior. As discussed in IETF69, peers are overlay-routing nodes, clients are non-overlay-routing nodes, it is not feasible that a client has a "Peer-ID" as described in the 3rd alternative in Section 5.5 of the Concept document. Clients couple with SIP UA, peers couple with SIP entity or without any SIP entity as Reference model; the unmodified SIP is enough and a separate client protocol is not needed when the associate peer couple with SIP entity (SIP proxy/registrar) as demonstrated in RELOAD; in the other scenarios, a client protocol is desired as the communication protocol between a client and its associated peer, but the client protocol may emerge as one part of peer protocol, hence we can make a consensus as above, any comment? The biggest problem may be about the function of P2PSIP client protocol, we do not have an explicit agreement yet, in fact, the same thing exists for P2PSIP peer protocol, and then it becomes very difficult to develop peer protocol and client protocol. Sometimes, I think that we really need an I-D about P2PSIP framework to define the functions of P2PSIP peer/client protocols. Best regards, Hewen -----Original Message----- From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: 2007?11?14? 3:42 To: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu Cc: P2PSIP Mailing List Subject: client protocol ([P2PSIP] Proposal for progress on protocols) > I think there is no consensus > yet on the nature or even existence of clients. >From this list I understand there is less a problem with the existence of clients, but rather if there should be a separate client protocol. Also, some folks mentioned that the client protocol should just be a subset of the peer protocol. Is this understanding of the discussions correct? Given the preponderance of mobile devices, this alone would justify a new version of the concepts document. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: Tuesday, November 13, 2007 10:41 AM To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols As a working group member, I am encouraged by the debate on the existence and nature of the P2PSIP client, and the proposals for a Client Protocol. But as a co-author of the Concepts draft, I think it is premature to modify the discussion on Clients in the draft. It is not that I don't want to do this, it is just that I think there is no consensus yet on the nature or even existence of clients. I think we are coming up to the point where there will be a major revision to the Concepts draft that will focus in on a specific architecture and mechanisms, and that revision may well include a major revision in the section on clients. But I don't think it should be the revision for this cycle. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 13 23:04:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9UR-0004U9-Gt; Tue, 13 Nov 2007 23:04:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is9UQ-0004TA-2o for p2psip@ietf.org; Tue, 13 Nov 2007 23:04:34 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is9UO-0001CH-Qn for p2psip@ietf.org; Tue, 13 Nov 2007 23:04:34 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH007PL9ZCSZ@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 12:04:24 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH003TI9ZA6N@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 12:04:24 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRH00N4E9Z70F@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 12:04:22 +0800 (CST) Date: Wed, 14 Nov 2007 12:04:19 +0800 From: Zheng Hewen Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) In-reply-to: <004201c8266e$80ee0640$9a00a8c0@mlifewangyao> To: 'Yao Wang' , 'Henry Sinnreich' , 'Philip Matthews' , 'lichun li' , 'Wei Gengyu' Message-id: <000801c82673$6e5296e0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: AcgmE+4NnH/c5CnFSFGInPlIVgu/4gAF0t2gAA4MIdAAA9lngA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Frankly, I think that reaching an agreement about P2PSIP client b= ehavior/character is necessary before developing P2PSIP=20 client protocol, otherwise it will be very difficult to develop P2PSI= P client protocol. By the way, there are many ways to implement the required service= s such as SIP, SIP-based client protocol is one choice=20 ^_^ Best regards, Hewen -----Original Message----- =46rom: Yao Wang [mailto:yaowang.bupt@gmail.com] Sent: 2007=C4=EA11=D4=C214=C8=D5 11:29 To: 'Henry Sinnreich'; 'Philip Matthews'; 'lichun li'; 'Zheng Hewen';= 'Wei Gengyu' Cc: 'P2PSIP Mailing List' Subject: RE: client protocol ([P2PSIP] Proposal for progress on proto= cols) Yes, you are right. Currently, the main difference in the debate comes from how to build = the client protocol, whether it could be based on SIP,=20 whether it could be a syntax subset of Peer Protocol, or whether it i= s a separate protocol different from both SIP and Peer=20 Protocol but its function is subset of the functions of Peer Protocol= . Here are some of my understandings, 1. What services client can get using Client Protocol? =09In my opinion, there are two kinds of services. =09Firstly, from the charter of this WG, this WG "is chartered to dev= elop protocols and mechanisms for the use of the Session=20 Initiation Protocol (SIP)". It is clearly that SIP service (including= locating target user, forwarding SIP messages) is a=20 basic service that P2PSIP Overlay MUST provide. Client Protocol MUST = enable client to access this services. =09Secondly, services other than SIP. As mentioned in concept draft, = some individual peers may provide services in addition to=20 storage and routing, for example STUN services, to the overlay. Howev= er, because clients do not join P2PSIP Overlay, they can=20 not discover these services directly. Therefore, client protocol MUST= provide a mean for client to know what services are=20 available in the P2PSIP Overlay and the comprehensive parameters for = access these services. After getting these parameters,=20 the client can use other protocols, for example STUN, to access the s= ervice, which should be out of the scope of client=20 protocol. =09To meet the first kind of requirements, SIP is mandatory. When it = comes to the second kind of requirements, both SIP and=20 other protocol (e.g. a subset of peer protocol) can work. =09If the subset of peer protocol is adopted as client protocol (supp= osing the peer protocol is not SIP-based), the client=20 _has_ _to_ run two protocol stacks at the same time, which obviously= consumes more resources of client than only running SIP=20 stack. Given the assumption that clients are resource-limited devices= , running one more protocol stack may cause the=20 degradation of its performances. =09Thus, why not use SIP and SIP extensions to satisfy both requireme= nts? why not kill two birds with one stone? Currently,=20 many mobile devices have been equipped with SIP; the reuse of SIP in = client protocol not only reduces the resource needed on=20 client devices but also reduces the implementation complexity of clie= nt protocol. 2. What services peer can get using Client Protocol? =09It seems that people in this list accept that the client should co= ntribute its storage capacity to peers. In my opinion, the=20 client can provide more service than that. Here is one possible examp= le which is described in our proposed draft ("A SIP-based=20 P2PSIP Client Protocol") =09"For example, a conferences server wants to provide conference ser= vices to nodes in a P2PSIP system. Because the decoding,=20 mixture and encoding of multiple media streams can be quite a heavy l= oad for its computational resources, this conference=20 server may choose not to join in the P2PSIP overlay. Thus, some extra= resources, which would be used for the maintenance of=20 P2P overlay if the server joined overlay, can be utilized for providi= ng better conference services." =09Therefore, the client protocol must be extensible for supporting a= ny possible services. SIP is a well-developed extensible=20 signal protocol, thus, we propose to build client protocol based on S= IP. Any comments? Sincerely yours, Yao Wang Mobile Life and New Media Lab, BUPT -----Original Message----- =46rom: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Wednesday, November 14, 2007 3:42 AM To: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu Cc: P2PSIP Mailing List Subject: client protocol ([P2PSIP] Proposal for progress on protocols= ) > I think there is no consensus > yet on the nature or even existence of clients. =46rom this list I understand there is less a problem with the existe= nce of clients, but rather if there should be a separate=20 client protocol. Also, some folks mentioned that the client protocol should just be a = subset of the peer protocol. Is this understanding of the discussions correct? Given the preponderance of mobile devices, this alone would justify a= new version of the concepts document. Henry -----Original Message----- =46rom: Philip Matthews [mailto:philip_matthews@magma.ca] Sent: Tuesday, November 13, 2007 10:41 AM To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Proposal for progress on protocols As a working group member, I am encouraged by the debate on the exist= ence and nature of the P2PSIP client, and the proposals=20 for a Client Protocol. But as a co-author of the Concepts draft, I think it is premature to = modify the discussion on Clients in the draft. It is not=20 that I don't want to do this, it is just that I think there is no con= sensus yet on the nature or even existence of clients. I think we are coming up to the point where there will be a major rev= ision to the Concepts draft that will focus in on a=20 specific architecture and mechanisms, and that revision may well incl= ude a major revision in the section on clients. But I=20 don't think it should be the revision for this cycle. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 03:16:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDQ0-0001k7-Ar; Wed, 14 Nov 2007 03:16:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDPy-0001gy-Ok for p2psip@ietf.org; Wed, 14 Nov 2007 03:16:14 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsDPv-0000y1-Gf for p2psip@ietf.org; Wed, 14 Nov 2007 03:16:14 -0500 Received: by ug-out-1314.google.com with SMTP id u2so767664uge for ; Wed, 14 Nov 2007 00:16:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=1XK1glPCG25fQ46kzP/4FUHWucO/WIEQKABqiRMwrLI=; b=X5btwbQSpuXKT3B12y+CVxvE9Led7Wap78nZ7Re32s+i5H+nwh2ydYtto65AdVUFQf3XHZM5r8boHHpVGuXlUEUsuOlTYOzk//gAJ0QDbHU5831FxdoaGVoOmMqGyI5BvtDs/9labgHALILaYBaXeQOpCgYSdgQIVj7k2PKH7jU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TApCxARy1IwQ1dySha9JMQ57ySe/hvZ3QR7cf0HEmeDROadvs8cithaMukO2CADDY2KbVuzLvzL28jDEHgxsseH6iFZ8b+RhIn7Mw8SIwbYShSwNF4Lyo5FWquaDdg8qQd5h26ZTg1Jx+zUZLfAc/3RttRiEqtQ2DW6C8PmNSKg= Received: by 10.66.252.18 with SMTP id z18mr253965ugh.1195028168113; Wed, 14 Nov 2007 00:16:08 -0800 (PST) Received: by 10.66.252.5 with HTTP; Wed, 14 Nov 2007 00:16:07 -0800 (PST) Message-ID: <618e24240711140016l41275466s84672aff63f17c49@mail.gmail.com> Date: Wed, 14 Nov 2007 09:16:07 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: "Zheng Hewen" Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols) In-Reply-To: <000801c82673$6e5296e0$5105a40a@china.huawei.com> MIME-Version: 1.0 References: <004201c8266e$80ee0640$9a00a8c0@mlifewangyao> <000801c82673$6e5296e0$5105a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: P2PSIP Mailing List , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0504477879==" Errors-To: p2psip-bounces@ietf.org --===============0504477879== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gMTQvMTEvMjAwNywgWmhlbmcgSGV3ZW4gPGh3emhlbmdAaHVhd2VpLmNvbT4gd3JvdGU6Cj4g RnJhbmtseSwgSSB0aGluayB0aGF0IHJlYWNoaW5nIGFuIGFncmVlbWVudCBhYm91dCBQMlBTSVAg Y2xpZW50IGJlaGF2aW9yL2NoYXJhY3RlciBpcyBuZWNlc3NhcnkgYmVmb3JlIGRldmVsb3Bpbmcg UDJQU0lQIGNsaWVudCBwcm90b2NvbCwgb3RoZXJ3aXNlIGl0IHdpbGwgYmUgdmVyeSBkaWZmaWN1 bHQgdG8gZGV2ZWxvcCBQMlBTSVAgY2xpZW50IHByb3RvY29sLgoKCkknbSBmdWxseSBhZ3JlZSB3 aXRoIHlvdS4KRGVmaW5pbmcgd2hhdCB0YXNrcyBQMlBTSVAgcGVlcnMgcGVyZm9ybSwgd2Ugc2hv dWxkIGJlIGFibGUgdG8gZGVmaW5lCnRoZSBQMlBTSVAgY2xpZW50IGJlaGF2aW91ciBhbmQgcmVx dWlyZW1lbnRzLgpTaW5jZSBhIHBlZXIgc2hvdWxkIGJlIGFibGUgdG8gY2hhbmdlIGl0cyByb2xl IGFuZCBiZWNvbWUgYSBDbGllbnQsIEkKY29uc2lkZXIgdXNpbmcgdGhlIHNhbWUgcHJvdG9jb2wg c3RhY2sgZm9yIFBlZXIgUHJvdG9jb2wgYW5kIENsaWVudApQcm90b2NvbCB3aGF0IGlzIG5vdCBu ZWNlc3NhcnkgU0lQLWJhc2VkIC1kZXBlbmRpbmcgb24gcmVxdWlyZW1lbnRzLS4KClRoYW5rcywK LS0gClZpY3RvciBQYXNjdWFsIMOBdmlsYQo= --===============0504477879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0504477879==-- From p2psip-bounces@ietf.org Wed Nov 14 03:28:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDbQ-0000UF-EZ; Wed, 14 Nov 2007 03:28:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDbO-0000Tw-Lg for p2psip@ietf.org; Wed, 14 Nov 2007 03:28:02 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsDbJ-0008BN-PK for p2psip@ietf.org; Wed, 14 Nov 2007 03:28:02 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH003XDM6EHO@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 16:27:50 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH00EK7M6EDP@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 16:27:50 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRH00BM3M6A6R@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 16:27:50 +0800 (CST) Date: Wed, 14 Nov 2007 16:27:47 +0800 From: Zheng Hewen Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) In-reply-to: <618e24240711140016l41275466s84672aff63f17c49@mail.gmail.com> To: 'Victor Pascual =?UNKNOWN?B?qKJ2aWxhJw==?= Message-id: <000001c82698$3d0c4d40$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: AcgmlrHMEG54c7IVThOZxyxWlRYLTQAATLpQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'P2PSIP Mailing List' , 'Henry Sinnreich' , 'Philip Matthews' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, I do think so, too. The same protocol stack for Peer protocol and Client protocol is = more efficient and simple. Best regards, Hewen > -----Original Message----- > From: Victor Pascual =A8=A2vila [mailto:victor.pascual.avila@gmail.= com] > Sent: 2007=C4=EA11=D4=C214=C8=D5 16:16 > To: Zheng Hewen > Cc: Yao Wang; Henry Sinnreich; Philip Matthews; lichun li; > Wei Gengyu; P2PSIP Mailing List > Subject: Re: client protocol ([P2PSIP] Proposal for progress > on protocols) > > On 14/11/2007, Zheng Hewen wrote: > > Frankly, I think that reaching an agreement about P2PSIP > client behavior/character is necessary before developing > P2PSIP client protocol, otherwise it will be very difficult > to develop P2PSIP client protocol. > > > I'm fully agree with you. > Defining what tasks P2PSIP peers perform, we should be able > to define the P2PSIP client behaviour and requirements. > Since a peer should be able to change its role and become a > Client, I consider using the same protocol stack for Peer > Protocol and Client Protocol what is not necessary SIP-based > -depending on requirements-. > > Thanks, > -- > Victor Pascual =A8=A2vila > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 03:43:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDq3-0004UB-M7; Wed, 14 Nov 2007 03:43:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsDq2-0004TQ-0m for p2psip@ietf.org; Wed, 14 Nov 2007 03:43:10 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsDpy-0001fD-I3 for p2psip@ietf.org; Wed, 14 Nov 2007 03:43:09 -0500 Received: by nz-out-0506.google.com with SMTP id n1so96516nzf for ; Wed, 14 Nov 2007 00:43:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=nL0A+euhEpz4AdkxVeOAuklbFfSO4DQ9JaKdwHQ3NRE=; b=EAw9DI8dlAzO1aDTb5AA/3aErGcEonaxKRt6F2fs7kcesmDjGntRob0TwQv/7ASMMDQM4Rbm/XdyDysv6QTboV/Qnxsfedi6zMidUVhQLaZWxRA51LraYI17M6vUSJGVhZwbvbuNliGmp+QMD7Ukm95HeQT8yyaXdbJe5zzc8HI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=lIvzs/TYKdY8BB3qrxOXRzYpyPunz9wrJmlmi1GgpKdLb1OtsOOMIDKY1CFvD5Zl9B6/awGATB0xUzBuCUexwWTWW6dp4g7lN+wuh3oD0jUjydVSq80kDXKsmhgnd+WJT+E4Skp6Sc2E/F07dx1ol4xAnrMKur0L6FBHwsm49qw= Received: by 10.142.231.7 with SMTP id d7mr1809622wfh.1195029785729; Wed, 14 Nov 2007 00:43:05 -0800 (PST) Received: by 10.142.200.16 with HTTP; Wed, 14 Nov 2007 00:43:05 -0800 (PST) Message-ID: <7d6b50690711140043g546e12bkdfa3717f90704c47@mail.gmail.com> Date: Wed, 14 Nov 2007 16:43:05 +0800 From: "lichun li" To: "Zheng Hewen" Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols) In-Reply-To: <000001c82698$3d0c4d40$5105a40a@china.huawei.com> MIME-Version: 1.0 References: <618e24240711140016l41275466s84672aff63f17c49@mail.gmail.com> <000001c82698$3d0c4d40$5105a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: P2PSIP Mailing List , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1696881569==" Errors-To: p2psip-bounces@ietf.org --===============1696881569== Content-Type: multipart/alternative; boundary="----=_Part_32022_116422.1195029785729" ------=_Part_32022_116422.1195029785729 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline SIP protocol is mandatory. If peer protocol is not SIP based, a peer has to run two protocol stacks. If client protocol is SIP based, a client only need to run one protocol stack. On 11/14/07, Zheng Hewen wrote: > > Hi, > > I do think so, too. > The same protocol stack for Peer protocol and Client protocol is more > efficient and simple. > > Best regards, > Hewen > > > -----Original Message----- > > From: Victor Pascual =A8=A2vila [mailto:victor.pascual.avila@gmail.com] > > Sent: 2007=C4=EA11=D4=C214=C8=D5 16:16 > > To: Zheng Hewen > > Cc: Yao Wang; Henry Sinnreich; Philip Matthews; lichun li; > > Wei Gengyu; P2PSIP Mailing List > > Subject: Re: client protocol ([P2PSIP] Proposal for progress > > on protocols) > > > > On 14/11/2007, Zheng Hewen wrote: > > > Frankly, I think that reaching an agreement about P2PSIP > > client behavior/character is necessary before developing > > P2PSIP client protocol, otherwise it will be very difficult > > to develop P2PSIP client protocol. > > > > > > I'm fully agree with you. > > Defining what tasks P2PSIP peers perform, we should be able > > to define the P2PSIP client behaviour and requirements. > > Since a peer should be able to change its role and become a > > Client, I consider using the same protocol stack for Peer > > Protocol and Client Protocol what is not necessary SIP-based > > -depending on requirements-. > > > > Thanks, > > -- > > Victor Pascual =A8=A2vila > > > > > > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_32022_116422.1195029785729 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
SIP protocol is mandatory.
If peer protocol is not SIP based, a peer has to run two pro= tocol stacks.
If client protocol is SIP based, a client only need to run one protoco= l stack.

 
On 11/14/07, Zheng Hewen <hwzheng@huawei.c= om> wrote:
Hi,

   I do thi= nk so, too.
   The same protocol stack for Peer protocol and C= lient protocol is more efficient and simple.

Best regards,
Hewen

> -----Original Message-----
&g= t; From: Victor Pascual =A8=A2vila [mailto:victor.pascual.avila@gmail.com]
> Sent: 2007=C4= =EA11=D4=C214=C8=D5 16:16
> To: Zheng Hewen
> Cc: Yao Wang; Henry Sinnreich; Philip Matt= hews; lichun li;
> Wei Gengyu; P2PSIP Mailing List
> Subject: R= e: client protocol ([P2PSIP] Proposal for progress
> on protocols)
>
> On 14/11/2007, Zheng Hewen <hwzheng@huawei.com> wrote:
> > Frankly, I think = that reaching an agreement about P2PSIP
> client behavior/character i= s necessary before developing
> P2PSIP client protocol, otherwise it will be very difficult
>= ; to develop P2PSIP client protocol.
>
>
> I'm fully = agree with you.
> Defining what tasks P2PSIP peers perform, we should= be able
> to define the P2PSIP client behaviour and requirements.
> Si= nce a peer should be able to change its role and become a
> Client, I= consider using the same protocol stack for Peer
> Protocol and Clien= t Protocol what is not necessary SIP-based
> -depending on requirements-.
>
> Thanks,
> --> Victor Pascual =A8=A2vila
>



<= br>

--
Sincerely yours,

Lichun Li
Mobile= Life New Media Lab, BUPT=20 ------=_Part_32022_116422.1195029785729-- --===============1696881569== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1696881569==-- From p2psip-bounces@ietf.org Wed Nov 14 03:59:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsE6B-0005At-Cj; Wed, 14 Nov 2007 03:59:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsE68-00059K-ED for p2psip@ietf.org; Wed, 14 Nov 2007 03:59:48 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsE67-0000rr-Aw for p2psip@ietf.org; Wed, 14 Nov 2007 03:59:48 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH0001CNM18I@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 16:58:49 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH001W0NLYWY@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 16:58:49 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRH00IFWNLUCD@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 16:58:46 +0800 (CST) Date: Wed, 14 Nov 2007 16:58:44 +0800 From: Zheng Hewen Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) In-reply-to: <7d6b50690711140043g546e12bkdfa3717f90704c47@mail.gmail.com> To: 'lichun li' Message-id: <000301c8269c$8fa8d7e0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcgmmmwSqMSCRqIvSfeUeVb245L62AAATGfQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Cc: 'P2PSIP Mailing List' , 'Henry Sinnreich' , 'Philip Matthews' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0279287118==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0279287118== Content-type: multipart/alternative; boundary="Boundary_(ID_igOTxbHzvl/t522eM2I/sQ)" This is a multi-part message in MIME format. --Boundary_(ID_igOTxbHzvl/t522eM2I/sQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Hi, =20 In my impression, SIP protocol has never been mandatory for the = communication protocol between any two P2PSIP nodes. I encourage you to read the consensus about the relation of P2PSIP = and SIP from IETF69 P2PSIP WG minute (http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt). Hope that it will be helpful for you. =20 Best regards, Hewen _____ =20 From: lichun li [mailto:lilichun@gmail.com]=20 Sent: 2007?11?14? 16:43 To: Zheng Hewen Cc: Victor Pascual =A8?vila; Yao Wang; Henry Sinnreich; Philip Matthews; = Wei Gengyu; P2PSIP Mailing List Subject: Re: client protocol ([P2PSIP] Proposal for progress on = protocols) SIP protocol is mandatory.=20 If peer protocol is not SIP based, a peer has to run two protocol = stacks. If client protocol is SIP based, a client only need to run one protocol = stack. =20 On 11/14/07, Zheng Hewen wrote:=20 Hi, I do think so, too. The same protocol stack for Peer protocol and Client protocol is more = efficient and simple.=20 Best regards, Hewen > -----Original Message----- > From: Victor Pascual =A8=A2vila = [mailto:victor.pascual.avila@gmail.com] > Sent: 2007=C4=EA11=D4=C214=C8=D5 16:16=20 > To: Zheng Hewen > Cc: Yao Wang; Henry Sinnreich; Philip Matthews; lichun li; > Wei Gengyu; P2PSIP Mailing List > Subject: Re: client protocol ([P2PSIP] Proposal for progress > on protocols)=20 > > On 14/11/2007, Zheng Hewen wrote: > > Frankly, I think that reaching an agreement about P2PSIP > client behavior/character is necessary before developing=20 > P2PSIP client protocol, otherwise it will be very difficult > to develop P2PSIP client protocol. > > > I'm fully agree with you. > Defining what tasks P2PSIP peers perform, we should be able=20 > to define the P2PSIP client behaviour and requirements. > Since a peer should be able to change its role and become a > Client, I consider using the same protocol stack for Peer > Protocol and Client Protocol what is not necessary SIP-based=20 > -depending on requirements-. > > Thanks, > -- > Victor Pascual =A8=A2vila > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT=20 --Boundary_(ID_igOTxbHzvl/t522eM2I/sQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable
Hi,
 
     In my impression, SIP = protocol has=20 never been mandatory for the communication protocol between any two = P2PSIP=20 nodes.
     I encourage you to read the consensus = about=20 the relation of P2PSIP and SIP from IETF69 P2PSIP WG minute (http:/= /www3.ietf.org/proceedings/07jul/minutes/p2psip.txt).
  =   =20 Hope that it will be helpful for you.
 
Best regards,
Hewen

From: lichun li = [mailto:lilichun@gmail.com]=20
Sent: 2007年11月14日 16:43
To: = Zheng Hewen
Cc:=20 Victor Pascual =A8￠vila; Yao Wang; Henry Sinnreich; Philip = Matthews; Wei Gengyu;=20 P2PSIP Mailing List
Subject: Re: client protocol ([P2PSIP] = Proposal=20 for progress on protocols)

SIP protocol is mandatory.
If peer protocol is not SIP based, a peer has to = run two=20 protocol stacks.
If client protocol is SIP based, a client only need to run one = protocol=20 stack.

 
On 11/14/07, Zheng=20 Hewen <hwzheng@huawei.com>=20 wrote:=20
Hi,

  =20 I do think so, too.
   The same protocol stack for Peer = protocol and Client protocol is more efficient and simple. =

Best=20 regards,
Hewen

> -----Original Message-----
> = From:=20 Victor Pascual =A8=A2vila [mailto:victor.pascual.avila@gmail= .com]
>=20 Sent: 2007=C4=EA11=D4=C214=C8=D5 16:16
> To: Zheng = Hewen
> Cc: Yao Wang;=20 Henry Sinnreich; Philip Matthews; lichun li;
> Wei Gengyu; = P2PSIP=20 Mailing List
> Subject: Re: client protocol ([P2PSIP] Proposal = for=20 progress
> on protocols)
>
> On 14/11/2007, Zheng = Hewen=20 <hwzheng@huawei.com> = wrote:
> > Frankly, I think that reaching an agreement = about=20 P2PSIP
> client behavior/character is necessary before = developing=20
> P2PSIP client protocol, otherwise it will be very = difficult
>=20 to develop P2PSIP client protocol.
>
>
> I'm fully = agree=20 with you.
> Defining what tasks P2PSIP peers perform, we = should be=20 able
> to define the P2PSIP client behaviour and=20 requirements.
> Since a peer should be able to change its role = and=20 become a
> Client, I consider using the same protocol stack = for=20 Peer
> Protocol and Client Protocol what is not necessary = SIP-based=20
> -depending on requirements-.
>
> = Thanks,
>=20 --
> Victor Pascual=20 =A8=A2vila
>






--=20
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, = BUPT=20 --Boundary_(ID_igOTxbHzvl/t522eM2I/sQ)-- --===============0279287118== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0279287118==-- From p2psip-bounces@ietf.org Wed Nov 14 04:18:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEOH-0004Lo-1i; Wed, 14 Nov 2007 04:18:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEOE-0004LW-Q0 for p2psip@ietf.org; Wed, 14 Nov 2007 04:18:30 -0500 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEOC-0002iq-1E for p2psip@ietf.org; Wed, 14 Nov 2007 04:18:30 -0500 Received: by nz-out-0506.google.com with SMTP id n1so103211nzf for ; Wed, 14 Nov 2007 01:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=YzdS6L92fG4E3mGAeexrOlhxr5mkDQUwhIZpU3meI78=; b=N5KuTkdAzkpsTUHp77RCUaoNzbjqNfmPoPsWlxpdE03X9mH4Ly/NeYQ908PQ8zjF47D8UzTzbX/DfGyebTQ7UaIq+OgLjxSnsnpdix6LLxAjCeuv8HmkVcUNKoNmkoMIyd/0eanU4QuMI0gbyDoFMktAXpGp+WDMGs+ZnEj++wc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=igCFCL+JdQ7L/nXwTfUPLUCexKF5CXwMwNkBLkFCy2YnOSAb5Gu9tQwkzIdM2Bu0bvqDx6vU8Ro1mwO524ImM4+aTLCdnVgaNW3CAmk+zEhYzescUD4Z8pzy5eFkwHPOKBbC4eQimhvuCrye6X+MjswxPA8PG9ftNUmGsNg1XHc= Received: by 10.142.229.4 with SMTP id b4mr2036872wfh.1195031906038; Wed, 14 Nov 2007 01:18:26 -0800 (PST) Received: by 10.142.200.16 with HTTP; Wed, 14 Nov 2007 01:18:25 -0800 (PST) Message-ID: <7d6b50690711140118g7604dfbbnfeaa5b7135dfd70@mail.gmail.com> Date: Wed, 14 Nov 2007 17:18:25 +0800 From: "lichun li" To: "Zheng Hewen" Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols) In-Reply-To: <000301c8269c$8fa8d7e0$5105a40a@china.huawei.com> MIME-Version: 1.0 References: <7d6b50690711140043g546e12bkdfa3717f90704c47@mail.gmail.com> <000301c8269c$8fa8d7e0$5105a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: P2PSIP Mailing List , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1283323880==" Errors-To: p2psip-bounces@ietf.org --===============1283323880== Content-Type: multipart/alternative; boundary="----=_Part_32117_4796862.1195031905522" ------=_Part_32117_4796862.1195031905522 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline QWNjb3JkaW5nIHRvIGNvbmNlcHQgZHJhZnQsICJTaW5jZSBQMlBTSVAgaXMgYWJvdXQgcGVlci10 by1wZWVyIG5ldHdvcmtzIGZvcgpyZWFsLXRpbWUgY29tbXVuaWNhdGlvbiwgaXQgaXMgZXhwZWN0 ZWQgdGhhdCBtb3N0IChpZiBub3QgYWxsKSBwZWVycyBhbmQKICAgY2xpZW50cyB3aWxsIGJlIGNv dXBsZWQgd2l0aCBTSVAgZW50aXRpZXMuIiBTbyBJIHRoaW5rIFNJUCBwcm90b2NvbCBpcwptYW5k YXRvcnkgaW4gbW9zdCBub2RlcyAoaWYgbm90IGFsbCkuCgoKT24gMTEvMTQvMDcsIFpoZW5nIEhl d2VuIDxod3poZW5nQGh1YXdlaS5jb20+IHdyb3RlOgo+Cj4gIEhpLAo+Cj4gICAgICBJbiBteSBp bXByZXNzaW9uLCBTSVAgcHJvdG9jb2wgaGFzIG5ldmVyIGJlZW4gbWFuZGF0b3J5IGZvciB0aGUK PiBjb21tdW5pY2F0aW9uIHByb3RvY29sIGJldHdlZW4gYW55IHR3byBQMlBTSVAgbm9kZXMuCj4g ICAgICBJIGVuY291cmFnZSB5b3UgdG8gcmVhZCB0aGUgY29uc2Vuc3VzIGFib3V0IHRoZSByZWxh dGlvbiBvZiBQMlBTSVAKPiBhbmQgU0lQIGZyb20gSUVURjY5IFAyUFNJUCBXRyBtaW51dGUgKAo+ IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA3anVsL21pbnV0ZXMvcDJwc2lwLnR4 dCkuCj4gICAgICBIb3BlIHRoYXQgaXQgd2lsbCBiZSBoZWxwZnVsIGZvciB5b3UuCj4KPiBCZXN0 IHJlZ2FyZHMsCj4gSGV3ZW4KPgo+ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiAq RnJvbToqIGxpY2h1biBsaSBbbWFpbHRvOmxpbGljaHVuQGdtYWlsLmNvbV0KPiAqU2VudDoqIDIw MDflubQxMeaciDE05pelIDE2OjQzCj4gKlRvOiogWmhlbmcgSGV3ZW4KPiAqQ2M6KiBWaWN0b3Ig UGFzY3VhbCDCqO+/oHZpbGE7IFlhbyBXYW5nOyBIZW5yeSBTaW5ucmVpY2g7IFBoaWxpcCBNYXR0 aGV3czsKPiBXZWkgR2VuZ3l1OyBQMlBTSVAgTWFpbGluZyBMaXN0Cj4gKlN1YmplY3Q6KiBSZTog Y2xpZW50IHByb3RvY29sIChbUDJQU0lQXSBQcm9wb3NhbCBmb3IgcHJvZ3Jlc3Mgb24KPiBwcm90 b2NvbHMpCj4KPgo+ICBTSVAgcHJvdG9jb2wgaXMgbWFuZGF0b3J5Lgo+IElmIHBlZXIgcHJvdG9j b2wgaXMgbm90IFNJUCBiYXNlZCwgYSBwZWVyIGhhcyB0byBydW4gdHdvIHByb3RvY29sIHN0YWNr cy4KPiBJZiBjbGllbnQgcHJvdG9jb2wgaXMgU0lQIGJhc2VkLCBhIGNsaWVudCBvbmx5IG5lZWQg dG8gcnVuIG9uZSBwcm90b2NvbAo+IHN0YWNrLgo+Cj4KPiBPbiAxMS8xNC8wNywgWmhlbmcgSGV3 ZW4gPGh3emhlbmdAaHVhd2VpLmNvbT4gd3JvdGU6Cj4gPgo+ID4gSGksCj4gPgo+ID4gICAgSSBk byB0aGluayBzbywgdG9vLgo+ID4gICAgVGhlIHNhbWUgcHJvdG9jb2wgc3RhY2sgZm9yIFBlZXIg cHJvdG9jb2wgYW5kIENsaWVudCBwcm90b2NvbCBpcyBtb3JlCj4gPiBlZmZpY2llbnQgYW5kIHNp bXBsZS4KPiA+Cj4gPiBCZXN0IHJlZ2FyZHMsCj4gPiBIZXdlbgo+ID4KPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0KPiA+ID4gRnJvbTogVmljdG9yIFBhc2N1YWwgwqjConZpbGEgW21h aWx0bzp2aWN0b3IucGFzY3VhbC5hdmlsYUBnbWFpbC5jb21dCj4gPiA+IFNlbnQ6IDIwMDfDhMOq MTHDlMOCMTTDiMOVIDE2OjE2Cj4gPiA+IFRvOiBaaGVuZyBIZXdlbgo+ID4gPiBDYzogWWFvIFdh bmc7IEhlbnJ5IFNpbm5yZWljaDsgUGhpbGlwIE1hdHRoZXdzOyBsaWNodW4gbGk7Cj4gPiA+IFdl aSBHZW5neXU7IFAyUFNJUCBNYWlsaW5nIExpc3QKPiA+ID4gU3ViamVjdDogUmU6IGNsaWVudCBw cm90b2NvbCAoW1AyUFNJUF0gUHJvcG9zYWwgZm9yIHByb2dyZXNzCj4gPiA+IG9uIHByb3RvY29s cykKPiA+ID4KPiA+ID4gT24gMTQvMTEvMjAwNywgWmhlbmcgSGV3ZW4gPGh3emhlbmdAaHVhd2Vp LmNvbT4gd3JvdGU6Cj4gPiA+ID4gRnJhbmtseSwgSSB0aGluayB0aGF0IHJlYWNoaW5nIGFuIGFn cmVlbWVudCBhYm91dCBQMlBTSVAKPiA+ID4gY2xpZW50IGJlaGF2aW9yL2NoYXJhY3RlciBpcyBu ZWNlc3NhcnkgYmVmb3JlIGRldmVsb3BpbmcKPiA+ID4gUDJQU0lQIGNsaWVudCBwcm90b2NvbCwg b3RoZXJ3aXNlIGl0IHdpbGwgYmUgdmVyeSBkaWZmaWN1bHQKPiA+ID4gdG8gZGV2ZWxvcCBQMlBT SVAgY2xpZW50IHByb3RvY29sLgo+ID4gPgo+ID4gPgo+ID4gPiBJJ20gZnVsbHkgYWdyZWUgd2l0 aCB5b3UuCj4gPiA+IERlZmluaW5nIHdoYXQgdGFza3MgUDJQU0lQIHBlZXJzIHBlcmZvcm0sIHdl IHNob3VsZCBiZSBhYmxlCj4gPiA+IHRvIGRlZmluZSB0aGUgUDJQU0lQIGNsaWVudCBiZWhhdmlv dXIgYW5kIHJlcXVpcmVtZW50cy4KPiA+ID4gU2luY2UgYSBwZWVyIHNob3VsZCBiZSBhYmxlIHRv IGNoYW5nZSBpdHMgcm9sZSBhbmQgYmVjb21lIGEKPiA+ID4gQ2xpZW50LCBJIGNvbnNpZGVyIHVz aW5nIHRoZSBzYW1lIHByb3RvY29sIHN0YWNrIGZvciBQZWVyCj4gPiA+IFByb3RvY29sIGFuZCBD bGllbnQgUHJvdG9jb2wgd2hhdCBpcyBub3QgbmVjZXNzYXJ5IFNJUC1iYXNlZAo+ID4gPiAtZGVw ZW5kaW5nIG9uIHJlcXVpcmVtZW50cy0uCj4gPiA+Cj4gPiA+IFRoYW5rcywKPiA+ID4gLS0KPiA+ ID4gVmljdG9yIFBhc2N1YWwgwqjConZpbGEKPiA+ID4KPiA+Cj4gPgo+ID4KPiA+Cj4KPgo+IC0t Cj4gU2luY2VyZWx5IHlvdXJzLAo+Cj4gTGljaHVuIExpCj4gTW9iaWxlIExpZmUgTmV3IE1lZGlh IExhYiwgQlVQVAo+Cj4KCgotLSAKU2luY2VyZWx5IHlvdXJzLAoKTGljaHVuIExpCk1vYmlsZSBM aWZlIE5ldyBNZWRpYSBMYWIsIEJVUFQK ------=_Part_32117_4796862.1195031905522 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5BY2NvcmRpbmcgdG8gY29uY2VwdCBkcmFmdCwgJnF1b3Q7U2luY2UgUDJQU0lQIGlzIGFi b3V0IHBlZXItdG8tcGVlciBuZXR3b3JrcyBmb3IgcmVhbC10aW1lIGNvbW11bmljYXRpb24sIGl0 IGlzIGV4cGVjdGVkIHRoYXQgbW9zdCAoaWYgbm90IGFsbCkgcGVlcnMgYW5kPGJyPiZuYnNwOyZu YnNwOyBjbGllbnRzIHdpbGwgYmUgY291cGxlZCB3aXRoIFNJUCBlbnRpdGllcy4mcXVvdDsgU28m bmJzcDtJIHRoaW5rIFNJUCBwcm90b2NvbCBpcyBtYW5kYXRvcnkgaW4gbW9zdCBub2RlcyAoaWYg bm90IGFsbCkuIAo8L2Rpdj4KPGRpdj48YnI+Jm5ic3A7PC9kaXY+CjxkaXY+PHNwYW4gY2xhc3M9 ImdtYWlsX3F1b3RlIj5PbiAxMS8xNC8wNywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5hbWUiPlpo ZW5nIEhld2VuPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh3emhlbmdAaHVhd2VpLmNvbSI+aHd6 aGVuZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPgo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBw eCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4KPGRpdj4KPGRpdiBkaXI9Imx0 ciIgYWxpZ249ImxlZnQiPjxzcGFuPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIg c2l6ZT0iMiI+SGksPC9mb250Pjwvc3Bhbj48L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249Imxl ZnQiPjxzcGFuPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+PC9m b250Pjwvc3Bhbj4mbmJzcDs8L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFu Pjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEluIG15IGltcHJlc3Npb24sIFNJUCBwcm90b2NvbCBoYXMgbmV2ZXIgYmVl biBtYW5kYXRvcnkgZm9yIHRoZSBjb21tdW5pY2F0aW9uIHByb3RvY29sIGJldHdlZW4gYW55IHR3 byBQMlBTSVAgbm9kZXMuPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGVuY291cmFnZSB5 b3UgdG8gcmVhZCB0aGUgY29uc2Vuc3VzIGFib3V0IHRoZSByZWxhdGlvbiBvZiBQMlBTSVAgYW5k IFNJUCBmcm9tIElFVEY2OSBQMlBTSVAgV0cgbWludXRlICgKPGEgb25jbGljaz0icmV0dXJuIHRv cC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Imh0dHA6Ly93d3czLmll dGYub3JnL3Byb2NlZWRpbmdzLzA3anVsL21pbnV0ZXMvcDJwc2lwLnR4dCIgdGFyZ2V0PSJfYmxh bmsiPmh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA3anVsL21pbnV0ZXMvcDJwc2lw LnR4dDwvYT4pLjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSG9wZSB0aGF0IGl0IHdpbGwg YmUgaGVscGZ1bCBmb3IgeW91Lgo8L2ZvbnQ+PC9zcGFuPjwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBh bGlnbj0ibGVmdCI+PHNwYW4+PC9zcGFuPjxzcGFuPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0i IzAwMDBmZiIgc2l6ZT0iMiI+PC9mb250Pjwvc3Bhbj4mbmJzcDs8L2Rpdj4KPGRpdiBkaXI9Imx0 ciIgYWxpZ249ImxlZnQiPjxzcGFuPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIg c2l6ZT0iMiI+QmVzdCByZWdhcmRzLDwvZm9udD48L3NwYW4+PC9kaXY+CjxkaXYgZGlyPSJsdHIi IGFsaWduPSJsZWZ0Ij48c3Bhbj48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNp emU9IjIiPkhld2VuPC9mb250Pjwvc3Bhbj48L2Rpdj48YnI+CjxibG9ja3F1b3RlIHN0eWxlPSJQ QURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYg MnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+CjxkaXYgbGFuZz0iZW4tdXMiIGRpcj0ibHRy IiBhbGlnbj0ibGVmdCI+Cjxocj4KPGZvbnQgZmFjZT0iVGFob21hIiBzaXplPSIyIj48Yj5Gcm9t OjwvYj4gbGljaHVuIGxpIFttYWlsdG86PGEgb25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0 TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhyZWY9Im1haWx0bzpsaWxpY2h1bkBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj5saWxpY2h1bkBnbWFpbC5jb208L2E+XSA8YnI+PGI+U2VudDo8L2I+ IDIwMDflubQxMeaciDE05pelIDE2OjQzCjxicj48Yj5Ubzo8L2I+IFpoZW5nIEhld2VuPGJyPjxi PkNjOjwvYj4gVmljdG9yIFBhc2N1YWwgwqjvv6B2aWxhOyBZYW8gV2FuZzsgSGVucnkgU2lubnJl aWNoOyBQaGlsaXAgTWF0dGhld3M7IFdlaSBHZW5neXU7IFAyUFNJUCBNYWlsaW5nIExpc3QgCjxk aXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzExNjNkNjgzMDgxZGFkMDRfMSI+PGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogY2xpZW50IHByb3RvY29sIChbUDJQU0lQXSBQcm9wb3NhbCBmb3IgcHJvZ3Jl c3Mgb24gcHJvdG9jb2xzKTxicj48L3NwYW4+PC9kaXY+PC9mb250Pjxicj4mbmJzcDs8L2Rpdj4K PGRpdj48c3BhbiBjbGFzcz0iZSIgaWQ9InFfMTE2M2Q2ODMwODFkYWQwNF8zIj4KPGRpdj48L2Rp dj4KPGRpdj5TSVAgcHJvdG9jb2wmbmJzcDtpcyBtYW5kYXRvcnkuIDwvZGl2Pgo8ZGl2PklmIHBl ZXIgcHJvdG9jb2wgaXMgbm90IFNJUCBiYXNlZCwmbmJzcDthIHBlZXIgaGFzIHRvIHJ1biZuYnNw O3R3byBwcm90b2NvbCBzdGFja3MuPC9kaXY+CjxkaXY+SWYgY2xpZW50IHByb3RvY29sIGlzIFNJ UCBiYXNlZCwgYSBjbGllbnQgb25seSBuZWVkIHRvIHJ1biBvbmUgcHJvdG9jb2wgc3RhY2suPGJy Pjxicj4mbmJzcDs8L2Rpdj4KPGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDExLzE0 LzA3LCA8YiBjbGFzcz0iZ21haWxfc2VuZGVybmFtZSI+WmhlbmcgSGV3ZW48L2I+ICZsdDs8YSBv bmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9wZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJl Zj0ibWFpbHRvOmh3emhlbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh3emhlbmdAaHVh d2VpLmNvbTwvYT4KJmd0OyB3cm90ZTo8L3NwYW4+IAo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf cXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBweCAwLjhl eDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj5IaSw8YnI+PGJyPiZuYnNwOyZuYnNwOyBJ IGRvIHRoaW5rIHNvLCB0b28uPGJyPiZuYnNwOyZuYnNwOyBUaGUgc2FtZSBwcm90b2NvbCBzdGFj ayBmb3IgUGVlciBwcm90b2NvbCBhbmQgQ2xpZW50IHByb3RvY29sIGlzIG1vcmUgZWZmaWNpZW50 IGFuZCBzaW1wbGUuIAo8YnI+PGJyPkJlc3QgcmVnYXJkcyw8YnI+SGV3ZW48YnI+PGJyPiZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyBGcm9tOiBWaWN0b3IgUGFzY3VhbCDC qMKidmlsYSBbbWFpbHRvOjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86dmljdG9yLnBhc2N1YWwuYXZpbGFAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+CnZpY3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNvbTwvYT5d PGJyPiZndDsgU2VudDogMjAwN8OEw6oxMcOUw4IxNMOIw5UgMTY6MTYgPGJyPiZndDsgVG86IFpo ZW5nIEhld2VuPGJyPiZndDsgQ2M6IFlhbyBXYW5nOyBIZW5yeSBTaW5ucmVpY2g7IFBoaWxpcCBN YXR0aGV3czsgbGljaHVuIGxpOzxicj4mZ3Q7IFdlaSBHZW5neXU7IFAyUFNJUCBNYWlsaW5nIExp c3Q8YnI+Jmd0OyBTdWJqZWN0OiBSZTogY2xpZW50IHByb3RvY29sIChbUDJQU0lQXSBQcm9wb3Nh bCBmb3IgcHJvZ3Jlc3MKPGJyPiZndDsgb24gcHJvdG9jb2xzKSA8YnI+Jmd0Ozxicj4mZ3Q7IE9u IDE0LzExLzIwMDcsIFpoZW5nIEhld2VuICZsdDs8YSBvbmNsaWNrPSJyZXR1cm4gdG9wLmpzLk9w ZW5FeHRMaW5rKHdpbmRvdyxldmVudCx0aGlzKSIgaHJlZj0ibWFpbHRvOmh3emhlbmdAaHVhd2Vp LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmh3emhlbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxi cj4mZ3Q7ICZndDsgRnJhbmtseSwgSSB0aGluayB0aGF0IHJlYWNoaW5nIGFuIGFncmVlbWVudCBh Ym91dCBQMlBTSVAKPGJyPiZndDsgY2xpZW50IGJlaGF2aW9yL2NoYXJhY3RlciBpcyBuZWNlc3Nh cnkgYmVmb3JlIGRldmVsb3BpbmcgPGJyPiZndDsgUDJQU0lQIGNsaWVudCBwcm90b2NvbCwgb3Ro ZXJ3aXNlIGl0IHdpbGwgYmUgdmVyeSBkaWZmaWN1bHQ8YnI+Jmd0OyB0byBkZXZlbG9wIFAyUFNJ UCBjbGllbnQgcHJvdG9jb2wuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IEkmIzM5O20gZnVsbHkg YWdyZWUgd2l0aCB5b3UuCjxicj4mZ3Q7IERlZmluaW5nIHdoYXQgdGFza3MgUDJQU0lQIHBlZXJz IHBlcmZvcm0sIHdlIHNob3VsZCBiZSBhYmxlIDxicj4mZ3Q7IHRvIGRlZmluZSB0aGUgUDJQU0lQ IGNsaWVudCBiZWhhdmlvdXIgYW5kIHJlcXVpcmVtZW50cy48YnI+Jmd0OyBTaW5jZSBhIHBlZXIg c2hvdWxkIGJlIGFibGUgdG8gY2hhbmdlIGl0cyByb2xlIGFuZCBiZWNvbWUgYTxicj4mZ3Q7IENs aWVudCwgSSBjb25zaWRlciB1c2luZyB0aGUgc2FtZSBwcm90b2NvbCBzdGFjayBmb3IgUGVlcgo8 YnI+Jmd0OyBQcm90b2NvbCBhbmQgQ2xpZW50IFByb3RvY29sIHdoYXQgaXMgbm90IG5lY2Vzc2Fy eSBTSVAtYmFzZWQgPGJyPiZndDsgLWRlcGVuZGluZyBvbiByZXF1aXJlbWVudHMtLjxicj4mZ3Q7 PGJyPiZndDsgVGhhbmtzLDxicj4mZ3Q7IC0tPGJyPiZndDsgVmljdG9yIFBhc2N1YWwgwqjConZp bGE8YnI+Jmd0Ozxicj48YnI+PGJyPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVh cj0iYWxsIj4KPGJyPi0tIDxicj5TaW5jZXJlbHkgeW91cnMsPGJyPjxicj5MaWNodW4gTGk8YnI+ TW9iaWxlIExpZmUgTmV3IE1lZGlhIExhYiwgQlVQVCA8L3NwYW4+PC9kaXY+PC9ibG9ja3F1b3Rl PjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PGJyIGNsZWFyPSJhbGwiPjxicj4tLSA8YnI+ U2luY2VyZWx5IHlvdXJzLDxicj48YnI+TGljaHVuIExpPGJyPk1vYmlsZSBMaWZlIE5ldyBNZWRp YSBMYWIsIEJVUFQgCg== ------=_Part_32117_4796862.1195031905522-- --===============1283323880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1283323880==-- From p2psip-bounces@ietf.org Wed Nov 14 04:20:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEQT-0007l5-MN; Wed, 14 Nov 2007 04:20:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEQT-0007ku-7o for p2psip@ietf.org; Wed, 14 Nov 2007 04:20:49 -0500 Received: from smtp.vip.sina.com ([202.108.3.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEQO-0002mA-3F for p2psip@ietf.org; Wed, 14 Nov 2007 04:20:49 -0500 Received: from DELLWEI (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id E3765A6E97; Wed, 14 Nov 2007 17:20:39 +0800 (CST) Message-ID: <008201c828fb$20010820$da07740a@DELLWEI> From: "Wei Gengyu" To: "Zheng Hewen" References: <000301c8269c$8fa8d7e0$5105a40a@china.huawei.com> Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols) Date: Sat, 17 Nov 2007 17:20:33 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.8 (+++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0097037873==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0097037873== Content-Type: multipart/alternative; boundary="----=_NextPart_000_007F_01C8293E.29430B70" This is a multi-part message in MIME format. ------=_NextPart_000_007F_01C8293E.29430B70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIA0KDQpBcyBmYXIgYXMgSSBrbm93LCANClNJUCBoYXZlIGJlZW4gc3RhbmRhcmRpemVkIGFu ZCBkZXBsb3llZCBpbiBhIGxvdCBvZiBQQ3MgYW5kIG1vYmlsZSB0ZXJtaW5hbHMuDQpTSVAgaXMg YWxyZWFkeSB0aGVyZSB3aGlsZSBQMlBTSVAgY2xpZW50IHByb3RvY29sIGlzIHVuZGVyIGRpc2N1 c3Npb24uDQoNCkFkb3B0aW5nIFNJUCBpcyBtb3JlIGVhc2llciB0byBhbGxvdyBhbnkgdGVybWlu YWwgdG8gYWNjZXNzIFAyUFNJUCBvdmVybGF5IHRoYW4gYW5vdGhlciBuZXcgcHJvdG9jb2xzLg0K QW5kIEkgZG8gbm90IHNlZSBhbnkgaGFybWZ1bCB0byBQMlBTSVAgb3ZlcmxheSBpZiBTSVAgaXMg dXNlZCBpbiBjbGllbnQuDQoNCkkgYWxzbyBhZ3JlZSB3aXRoIFZpY3RvciBQYXNjdWFsIMOBdmls YSBhbmQgdGhlIENvbmNlcHQgZHJhZnQgbmVlZCB1cGRhdGluZy4NCg0KR2VuZ3l1DQoNCiAgLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCiAgRnJvbTogWmhlbmcgSGV3ZW4gDQogIFRvOiAn bGljaHVuIGxpJyANCiAgQ2M6ICdWaWN0b3IgUGFzY3VhbCDCqD92aWxhJyA7ICdZYW8gV2FuZycg OyAnSGVucnkgU2lubnJlaWNoJyA7ICdQaGlsaXAgTWF0dGhld3MnIDsgJ1dlaSBHZW5neXUnIDsg J1AyUFNJUCBNYWlsaW5nIExpc3QnIA0KICBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE0LCAy MDA3IDQ6NTggUE0NCiAgU3ViamVjdDogUkU6IGNsaWVudCBwcm90b2NvbCAoW1AyUFNJUF0gUHJv cG9zYWwgZm9yIHByb2dyZXNzIG9uIHByb3RvY29scykNCg0KDQogIEhpLA0KDQogICAgICAgSW4g bXkgaW1wcmVzc2lvbiwgU0lQIHByb3RvY29sIGhhcyBuZXZlciBiZWVuIG1hbmRhdG9yeSBmb3Ig dGhlIGNvbW11bmljYXRpb24gcHJvdG9jb2wgYmV0d2VlbiBhbnkgdHdvIFAyUFNJUCBub2Rlcy4N CiAgICAgICBJIGVuY291cmFnZSB5b3UgdG8gcmVhZCB0aGUgY29uc2Vuc3VzIGFib3V0IHRoZSBy ZWxhdGlvbiBvZiBQMlBTSVAgYW5kIFNJUCBmcm9tIElFVEY2OSBQMlBTSVAgV0cgbWludXRlICho dHRwOi8vd3d3My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wN2p1bC9taW51dGVzL3AycHNpcC50eHQp Lg0KICAgICAgIEhvcGUgdGhhdCBpdCB3aWxsIGJlIGhlbHBmdWwgZm9yIHlvdS4NCg0KICBCZXN0 IHJlZ2FyZHMsDQogIEhld2VuDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgRnJvbTog bGljaHVuIGxpIFttYWlsdG86bGlsaWNodW5AZ21haWwuY29tXSANCiAgICBTZW50OiAyMDA35bm0 MTHmnIgxNOaXpSAxNjo0Mw0KICAgIFRvOiBaaGVuZyBIZXdlbg0KICAgIENjOiBWaWN0b3IgUGFz Y3VhbCDCqO+/oHZpbGE7IFlhbyBXYW5nOyBIZW5yeSBTaW5ucmVpY2g7IFBoaWxpcCBNYXR0aGV3 czsgV2VpIEdlbmd5dTsgUDJQU0lQIE1haWxpbmcgTGlzdA0KICAgIFN1YmplY3Q6IFJlOiBjbGll bnQgcHJvdG9jb2wgKFtQMlBTSVBdIFByb3Bvc2FsIGZvciBwcm9ncmVzcyBvbiBwcm90b2NvbHMp DQoNCg0KICAgIFNJUCBwcm90b2NvbCBpcyBtYW5kYXRvcnkuIA0KICAgIElmIHBlZXIgcHJvdG9j b2wgaXMgbm90IFNJUCBiYXNlZCwgYSBwZWVyIGhhcyB0byBydW4gdHdvIHByb3RvY29sIHN0YWNr cy4NCiAgICBJZiBjbGllbnQgcHJvdG9jb2wgaXMgU0lQIGJhc2VkLCBhIGNsaWVudCBvbmx5IG5l ZWQgdG8gcnVuIG9uZSBwcm90b2NvbCBzdGFjay4NCg0KICAgICANCiAgICBPbiAxMS8xNC8wNywg WmhlbmcgSGV3ZW4gPGh3emhlbmdAaHVhd2VpLmNvbT4gd3JvdGU6IA0KICAgICAgSGksDQoNCiAg ICAgICAgIEkgZG8gdGhpbmsgc28sIHRvby4NCiAgICAgICAgIFRoZSBzYW1lIHByb3RvY29sIHN0 YWNrIGZvciBQZWVyIHByb3RvY29sIGFuZCBDbGllbnQgcHJvdG9jb2wgaXMgbW9yZSBlZmZpY2ll bnQgYW5kIHNpbXBsZS4gDQoNCiAgICAgIEJlc3QgcmVnYXJkcywNCiAgICAgIEhld2VuDQoNCiAg ICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICAgID4gRnJvbTogVmljdG9yIFBh c2N1YWwgwqjConZpbGEgW21haWx0bzp2aWN0b3IucGFzY3VhbC5hdmlsYUBnbWFpbC5jb21dDQog ICAgICA+IFNlbnQ6IDIwMDfDhMOqMTHDlMOCMTTDiMOVIDE2OjE2IA0KICAgICAgPiBUbzogWmhl bmcgSGV3ZW4NCiAgICAgID4gQ2M6IFlhbyBXYW5nOyBIZW5yeSBTaW5ucmVpY2g7IFBoaWxpcCBN YXR0aGV3czsgbGljaHVuIGxpOw0KICAgICAgPiBXZWkgR2VuZ3l1OyBQMlBTSVAgTWFpbGluZyBM aXN0DQogICAgICA+IFN1YmplY3Q6IFJlOiBjbGllbnQgcHJvdG9jb2wgKFtQMlBTSVBdIFByb3Bv c2FsIGZvciBwcm9ncmVzcw0KICAgICAgPiBvbiBwcm90b2NvbHMpIA0KICAgICAgPg0KICAgICAg PiBPbiAxNC8xMS8yMDA3LCBaaGVuZyBIZXdlbiA8aHd6aGVuZ0BodWF3ZWkuY29tPiB3cm90ZToN CiAgICAgID4gPiBGcmFua2x5LCBJIHRoaW5rIHRoYXQgcmVhY2hpbmcgYW4gYWdyZWVtZW50IGFi b3V0IFAyUFNJUA0KICAgICAgPiBjbGllbnQgYmVoYXZpb3IvY2hhcmFjdGVyIGlzIG5lY2Vzc2Fy eSBiZWZvcmUgZGV2ZWxvcGluZyANCiAgICAgID4gUDJQU0lQIGNsaWVudCBwcm90b2NvbCwgb3Ro ZXJ3aXNlIGl0IHdpbGwgYmUgdmVyeSBkaWZmaWN1bHQNCiAgICAgID4gdG8gZGV2ZWxvcCBQMlBT SVAgY2xpZW50IHByb3RvY29sLg0KICAgICAgPg0KICAgICAgPg0KICAgICAgPiBJJ20gZnVsbHkg YWdyZWUgd2l0aCB5b3UuDQogICAgICA+IERlZmluaW5nIHdoYXQgdGFza3MgUDJQU0lQIHBlZXJz IHBlcmZvcm0sIHdlIHNob3VsZCBiZSBhYmxlIA0KICAgICAgPiB0byBkZWZpbmUgdGhlIFAyUFNJ UCBjbGllbnQgYmVoYXZpb3VyIGFuZCByZXF1aXJlbWVudHMuDQogICAgICA+IFNpbmNlIGEgcGVl ciBzaG91bGQgYmUgYWJsZSB0byBjaGFuZ2UgaXRzIHJvbGUgYW5kIGJlY29tZSBhDQogICAgICA+ IENsaWVudCwgSSBjb25zaWRlciB1c2luZyB0aGUgc2FtZSBwcm90b2NvbCBzdGFjayBmb3IgUGVl cg0KICAgICAgPiBQcm90b2NvbCBhbmQgQ2xpZW50IFByb3RvY29sIHdoYXQgaXMgbm90IG5lY2Vz c2FyeSBTSVAtYmFzZWQgDQogICAgICA+IC1kZXBlbmRpbmcgb24gcmVxdWlyZW1lbnRzLS4NCiAg ICAgID4NCiAgICAgID4gVGhhbmtzLA0KICAgICAgPiAtLQ0KICAgICAgPiBWaWN0b3IgUGFzY3Vh bCDCqMKidmlsYQ0KICAgICAgPg0KDQoNCg0KDQoNCg0KDQogICAgLS0gDQogICAgU2luY2VyZWx5 IHlvdXJzLA0KDQogICAgTGljaHVuIExpDQogICAgTW9iaWxlIExpZmUgTmV3IE1lZGlhIExhYiwg QlVQVCA= ------=_NextPart_000_007F_01C8293E.29430B70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjU3MzAuMTMiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5IaSwg PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05UPiZuYnNw OzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+QXMgZmFyIGFzIEkga25vdywg PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+U0lQIGhhdmUgYmVl biBzdGFuZGFyZGl6ZWQgYW5kIGRlcGxveWVkIGluIGEgbG90IG9mIA0KUENzIGFuZCBtb2JpbGUg dGVybWluYWxzLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPlNJ UCBpcyBhbHJlYWR5IHRoZXJlIHdoaWxlIFAyUFNJUCBjbGllbnQgcHJvdG9jb2wgaXMgDQp1bmRl ciBkaXNjdXNzaW9uLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT3lrovkvZMgc2l6ZT0yPkFkb3B0 aW5nIFNJUCBpcyBtb3JlIGVhc2llciB0byBhbGxvdyBhbnkgdGVybWluYWwgdG8gDQphY2Nlc3Mg UDJQU0lQIG92ZXJsYXkgdGhhbiBhbm90aGVyIG5ldyBwcm90b2NvbHMuPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+QW5kIEkgZG8gbm90IHNlZSBhbnkgaGFybWZ1 bCB0byBQMlBTSVAgb3ZlcmxheSBpZiBTSVAgDQppcyB1c2VkIGluIGNsaWVudC48L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U95a6L5L2TIHNpemU9Mj5JIGFsc28gYWdyZWUgd2l0aCA8Rk9OVCBzaXpl PTM+VmljdG9yIFBhc2N1YWwgw4F2aWxhIA0KYW5kIDwvRk9OVD48Rk9OVCBzaXplPTI+dGhlIENv bmNlcHQgZHJhZnQgbmVlZCB1cGRhdGluZy48L0ZPTlQ+PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNl PeWui+S9kyBzaXplPTI+R2VuZ3l1PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPeWui+S9 kyBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElWPg0KPEJMT0NLUVVPVEUgZGlyPWx0ciANCnN0eWxl PSJQQURESU5HLVJJR0hUOiAwcHg7IFBBRERJTkctTEVGVDogNXB4OyBNQVJHSU4tTEVGVDogNXB4 OyBCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IE1BUkdJTi1SSUdIVDogMHB4Ij4NCiAg PERJViBzdHlsZT0iRk9OVDogOXB0IOWui+S9kyI+LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0t LSA8L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dST1VORDogI2U0ZTRlNDsgRk9OVDogOXB0IOWu i+S9kzsgZm9udC1jb2xvcjogYmxhY2siPjxCPkZyb206PC9CPiANCiAgPEEgdGl0bGU9aHd6aGVu Z0BodWF3ZWkuY29tIGhyZWY9Im1haWx0bzpod3poZW5nQGh1YXdlaS5jb20iPlpoZW5nIEhld2Vu PC9BPiANCiAgPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCDlrovkvZMiPjxCPlRvOjwv Qj4gPEEgdGl0bGU9bGlsaWNodW5AZ21haWwuY29tIA0KICBocmVmPSJtYWlsdG86bGlsaWNodW5A Z21haWwuY29tIj4nbGljaHVuIGxpJzwvQT4gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlw dCDlrovkvZMiPjxCPkNjOjwvQj4gPEEgdGl0bGU9dmljdG9yLnBhc2N1YWwuYXZpbGFAZ21haWwu Y29tIA0KICBocmVmPSJtYWlsdG86dmljdG9yLnBhc2N1YWwuYXZpbGFAZ21haWwuY29tIj4nVmlj dG9yIFBhc2N1YWwgwqg/dmlsYSc8L0E+IDsgPEEgDQogIHRpdGxlPXlhb3dhbmcuYnVwdEBnbWFp bC5jb20gaHJlZj0ibWFpbHRvOnlhb3dhbmcuYnVwdEBnbWFpbC5jb20iPidZYW8gDQogIFdhbmcn PC9BPiA7IDxBIHRpdGxlPWhzaW5ucmVpQGFkb2JlLmNvbSANCiAgaHJlZj0ibWFpbHRvOmhzaW5u cmVpQGFkb2JlLmNvbSI+J0hlbnJ5IFNpbm5yZWljaCc8L0E+IDsgPEEgDQogIHRpdGxlPXBoaWxp cF9tYXR0aGV3c0BtYWdtYS5jYSBocmVmPSJtYWlsdG86cGhpbGlwX21hdHRoZXdzQG1hZ21hLmNh Ij4nUGhpbGlwIA0KICBNYXR0aGV3cyc8L0E+IDsgPEEgdGl0bGU9d2VpZ2VuZ3l1QHZpcC5zaW5h LmNvbSANCiAgaHJlZj0ibWFpbHRvOndlaWdlbmd5dUB2aXAuc2luYS5jb20iPidXZWkgR2VuZ3l1 JzwvQT4gOyA8QSANCiAgdGl0bGU9cDJwc2lwQGlldGYub3JnIGhyZWY9Im1haWx0bzpwMnBzaXBA aWV0Zi5vcmciPidQMlBTSVAgTWFpbGluZyBMaXN0JzwvQT4gDQogIDwvRElWPg0KICA8RElWIHN0 eWxlPSJGT05UOiA5cHQg5a6L5L2TIj48Qj5TZW50OjwvQj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAx NCwgMjAwNyA0OjU4IA0KICBQTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQg5a6L5L2T Ij48Qj5TdWJqZWN0OjwvQj4gUkU6IGNsaWVudCBwcm90b2NvbCAoW1AyUFNJUF0gDQogIFByb3Bv c2FsIGZvciBwcm9ncmVzcyBvbiBwcm90b2NvbHMpPC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT3l rovkvZMgc2l6ZT0yPjwvRk9OVD48Rk9OVCBmYWNlPeWui+S9kyBzaXplPTI+PC9GT05UPjxCUj48 L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzYyNTg1MTA4LTE0 MTEyMDA3PjxGT05UIGZhY2U9QXJpYWwgDQogIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPkhpLDwvRk9O VD48L1NQQU4+PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc2 MjU4NTEwOC0xNDExMjAwNz48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9 Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48 U1BBTiBjbGFzcz03NjI1ODUxMDgtMTQxMTIwMDc+PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9 IzAwMDBmZiBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIG15IGltcHJlc3Npb24s IFNJUCBwcm90b2NvbCANCiAgaGFzIG5ldmVyIGJlZW4gbWFuZGF0b3J5IGZvciB0aGUgY29tbXVu aWNhdGlvbiBwcm90b2NvbCBiZXR3ZWVuIGFueSB0d28gUDJQU0lQIA0KICBub2Rlcy48QlI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgZW5jb3VyYWdlIHlvdSB0byByZWFkIHRoZSBjb25zZW5z dXMgYWJvdXQgDQogIHRoZSByZWxhdGlvbiBvZiBQMlBTSVAgYW5kIFNJUCBmcm9tIElFVEY2OSBQ MlBTSVAgV0cgbWludXRlICg8QSANCiAgaHJlZj0iaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvMDdqdWwvbWludXRlcy9wMnBzaXAudHh0Ij5odHRwOi8vd3d3My5pZXRmLm9yZy9wcm9j ZWVkaW5ncy8wN2p1bC9taW51dGVzL3AycHNpcC50eHQ8L0E+KS48QlI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IA0KICBIb3BlIHRoYXQgaXQgd2lsbCBiZSBoZWxwZnVsIGZvciB5b3UuPC9GT05U PjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NzYy NTg1MTA4LTE0MTEyMDA3PjwvU1BBTj48U1BBTiANCiAgY2xhc3M9NzYyNTg1MTA4LTE0MTEyMDA3 PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiANCiAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+ Jm5ic3A7PC9ESVY+DQogIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTc2MjU4 NTEwOC0xNDExMjAwNz48Rk9OVCBmYWNlPUFyaWFsIA0KICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5C ZXN0IHJlZ2FyZHMsPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgPERJViBkaXI9bHRyIGFsaWduPWxl ZnQ+PFNQQU4gY2xhc3M9NzYyNTg1MTA4LTE0MTEyMDA3PjxGT05UIGZhY2U9QXJpYWwgDQogIGNv bG9yPSMwMDAwZmYgc2l6ZT0yPkhld2VuPC9GT05UPjwvU1BBTj48L0RJVj48QlI+DQogIDxCTE9D S1FVT1RFIA0KICBzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJP UkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAgIDxE SVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxl ZnQ+DQogICAgPEhSIHRhYkluZGV4PS0xPg0KICAgIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48 Qj5Gcm9tOjwvQj4gbGljaHVuIGxpIFttYWlsdG86bGlsaWNodW5AZ21haWwuY29tXSANCiAgICA8 QlI+PEI+U2VudDo8L0I+IDIwMDflubQxMeaciDE05pelIDE2OjQzPEJSPjxCPlRvOjwvQj4gWmhl bmcgSGV3ZW48QlI+PEI+Q2M6PC9CPiANCiAgICBWaWN0b3IgUGFzY3VhbCDCqO+/oHZpbGE7IFlh byBXYW5nOyBIZW5yeSBTaW5ucmVpY2g7IFBoaWxpcCBNYXR0aGV3czsgV2VpIA0KICAgIEdlbmd5 dTsgUDJQU0lQIE1haWxpbmcgTGlzdDxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IGNsaWVudCBwcm90 b2NvbCAoW1AyUFNJUF0gDQogICAgUHJvcG9zYWwgZm9yIHByb2dyZXNzIG9uIHByb3RvY29scyk8 QlI+PC9GT05UPjxCUj48L0RJVj4NCiAgICA8RElWPjwvRElWPg0KICAgIDxESVY+U0lQIHByb3Rv Y29sJm5ic3A7aXMgbWFuZGF0b3J5LiA8L0RJVj4NCiAgICA8RElWPklmIHBlZXIgcHJvdG9jb2wg aXMgbm90IFNJUCBiYXNlZCwmbmJzcDthIHBlZXIgaGFzIHRvIHJ1biZuYnNwO3R3byANCiAgICBw cm90b2NvbCBzdGFja3MuPC9ESVY+DQogICAgPERJVj5JZiBjbGllbnQgcHJvdG9jb2wgaXMgU0lQ IGJhc2VkLCBhIGNsaWVudCBvbmx5IG5lZWQgdG8gcnVuIG9uZSBwcm90b2NvbCANCiAgICBzdGFj ay48QlI+PEJSPiZuYnNwOzwvRElWPg0KICAgIDxESVY+PFNQQU4gY2xhc3M9Z21haWxfcXVvdGU+ T24gMTEvMTQvMDcsIDxCIGNsYXNzPWdtYWlsX3NlbmRlcm5hbWU+WmhlbmcgDQogICAgSGV3ZW48 L0I+ICZsdDs8QSBocmVmPSJtYWlsdG86aHd6aGVuZ0BodWF3ZWkuY29tIj5od3poZW5nQGh1YXdl aS5jb208L0E+Jmd0OyANCiAgICB3cm90ZTo8L1NQQU4+IA0KICAgIDxCTE9DS1FVT1RFIGNsYXNz PWdtYWlsX3F1b3RlIA0KICAgIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHgg MHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj5IaSw8QlI+PEJSPiZu YnNwOyZuYnNwOyANCiAgICAgIEkgZG8gdGhpbmsgc28sIHRvby48QlI+Jm5ic3A7Jm5ic3A7IFRo ZSBzYW1lIHByb3RvY29sIHN0YWNrIGZvciBQZWVyIA0KICAgICAgcHJvdG9jb2wgYW5kIENsaWVu dCBwcm90b2NvbCBpcyBtb3JlIGVmZmljaWVudCBhbmQgc2ltcGxlLiA8QlI+PEJSPkJlc3QgDQog ICAgICByZWdhcmRzLDxCUj5IZXdlbjxCUj48QlI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxCUj4mZ3Q7IEZyb206IA0KICAgICAgVmljdG9yIFBhc2N1YWwgwqjConZpbGEgW21haWx0 bzo8QSANCiAgICAgIGhyZWY9Im1haWx0bzp2aWN0b3IucGFzY3VhbC5hdmlsYUBnbWFpbC5jb20i PnZpY3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNvbTwvQT5dPEJSPiZndDsgDQogICAgICBTZW50 OiAyMDA3w4TDqjExw5TDgjE0w4jDlSAxNjoxNiA8QlI+Jmd0OyBUbzogWmhlbmcgSGV3ZW48QlI+ Jmd0OyBDYzogWWFvIFdhbmc7IA0KICAgICAgSGVucnkgU2lubnJlaWNoOyBQaGlsaXAgTWF0dGhl d3M7IGxpY2h1biBsaTs8QlI+Jmd0OyBXZWkgR2VuZ3l1OyBQMlBTSVAgDQogICAgICBNYWlsaW5n IExpc3Q8QlI+Jmd0OyBTdWJqZWN0OiBSZTogY2xpZW50IHByb3RvY29sIChbUDJQU0lQXSBQcm9w b3NhbCBmb3IgDQogICAgICBwcm9ncmVzczxCUj4mZ3Q7IG9uIHByb3RvY29scykgPEJSPiZndDs8 QlI+Jmd0OyBPbiAxNC8xMS8yMDA3LCBaaGVuZyBIZXdlbiANCiAgICAgICZsdDs8QSBocmVmPSJt YWlsdG86aHd6aGVuZ0BodWF3ZWkuY29tIj5od3poZW5nQGh1YXdlaS5jb208L0E+Jmd0OyANCiAg ICAgIHdyb3RlOjxCUj4mZ3Q7ICZndDsgRnJhbmtseSwgSSB0aGluayB0aGF0IHJlYWNoaW5nIGFu IGFncmVlbWVudCBhYm91dCANCiAgICAgIFAyUFNJUDxCUj4mZ3Q7IGNsaWVudCBiZWhhdmlvci9j aGFyYWN0ZXIgaXMgbmVjZXNzYXJ5IGJlZm9yZSBkZXZlbG9waW5nIA0KICAgICAgPEJSPiZndDsg UDJQU0lQIGNsaWVudCBwcm90b2NvbCwgb3RoZXJ3aXNlIGl0IHdpbGwgYmUgdmVyeSANCiAgICAg IGRpZmZpY3VsdDxCUj4mZ3Q7IHRvIGRldmVsb3AgUDJQU0lQIGNsaWVudCANCiAgICAgIHByb3Rv Y29sLjxCUj4mZ3Q7PEJSPiZndDs8QlI+Jmd0OyBJJ20gZnVsbHkgYWdyZWUgd2l0aCB5b3UuPEJS PiZndDsgDQogICAgICBEZWZpbmluZyB3aGF0IHRhc2tzIFAyUFNJUCBwZWVycyBwZXJmb3JtLCB3 ZSBzaG91bGQgYmUgYWJsZSA8QlI+Jmd0OyB0byANCiAgICAgIGRlZmluZSB0aGUgUDJQU0lQIGNs aWVudCBiZWhhdmlvdXIgYW5kIHJlcXVpcmVtZW50cy48QlI+Jmd0OyBTaW5jZSBhIHBlZXIgDQog ICAgICBzaG91bGQgYmUgYWJsZSB0byBjaGFuZ2UgaXRzIHJvbGUgYW5kIGJlY29tZSBhPEJSPiZn dDsgQ2xpZW50LCBJIGNvbnNpZGVyIA0KICAgICAgdXNpbmcgdGhlIHNhbWUgcHJvdG9jb2wgc3Rh Y2sgZm9yIFBlZXI8QlI+Jmd0OyBQcm90b2NvbCBhbmQgQ2xpZW50IA0KICAgICAgUHJvdG9jb2wg d2hhdCBpcyBub3QgbmVjZXNzYXJ5IFNJUC1iYXNlZCA8QlI+Jmd0OyAtZGVwZW5kaW5nIG9uIA0K ICAgICAgcmVxdWlyZW1lbnRzLS48QlI+Jmd0OzxCUj4mZ3Q7IFRoYW5rcyw8QlI+Jmd0OyAtLTxC Uj4mZ3Q7IFZpY3RvciBQYXNjdWFsIA0KICAgICAgwqjConZpbGE8QlI+Jmd0OzxCUj48QlI+PEJS PjxCUj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPjxCUiBjbGVhcj1hbGw+PEJSPi0tIA0KICAgIDxC Uj5TaW5jZXJlbHkgeW91cnMsPEJSPjxCUj5MaWNodW4gTGk8QlI+TW9iaWxlIExpZmUgTmV3IE1l ZGlhIExhYiwgQlVQVCANCiAgPC9CTE9DS1FVT1RFPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1M Pg0K ------=_NextPart_000_007F_01C8293E.29430B70-- --===============0097037873== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0097037873==-- From p2psip-bounces@ietf.org Wed Nov 14 04:29:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEZA-0006OV-6O; Wed, 14 Nov 2007 04:29:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEZ9-0006OH-P3 for p2psip@ietf.org; Wed, 14 Nov 2007 04:29:47 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEZ2-0002zA-Mm for p2psip@ietf.org; Wed, 14 Nov 2007 04:29:47 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH005MKP0UFQ@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 17:29:18 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH00E06P0O4S@szxga04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 17:29:18 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRH00IVZP0KCD@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 17:29:12 +0800 (CST) Date: Wed, 14 Nov 2007 17:29:11 +0800 From: Zheng Hewen Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) In-reply-to: <7d6b50690711140118g7604dfbbnfeaa5b7135dfd70@mail.gmail.com> To: 'lichun li' Message-id: <001801c826a0$d0b2a2d0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acgmn22SiWEm+I2TR1S5FPasgpn7egAAHNCg X-Spam-Score: 0.0 (/) X-Scan-Signature: d8921dd2ebcb07edebf7bfaf4808c2ad Cc: 'P2PSIP Mailing List' , 'Henry Sinnreich' , 'Philip Matthews' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1217898523==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1217898523== Content-type: multipart/alternative; boundary="Boundary_(ID_3C3L1+00AQnhcD1+bqaDXA)" This is a multi-part message in MIME format. --Boundary_(ID_3C3L1+00AQnhcD1+bqaDXA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Hi, =20 You are right, "Since P2PSIP is about peer-to-peer networks for = real-time communication, it is expected that most (if not all) peers and = clients will be coupled with SIP entities." You also notice the limitation, i.e. "most (if not all) ". Some peers = couple with SIP entity, but some do not, as Reference model, SIP is not = mandatory for those peer without any SIP entity, those peers without any = SIP entity only participate P2PSIP overlay network and contribute its = storage capacity. I do think that SIP is useful as the communication protocol between a = peer with SIP entity(proxy/registrar) and its associated clients with = SIP UA, but it is only one choice. =20 Best regards, Hewen =20 _____ =20 From: lichun li [mailto:lilichun@gmail.com]=20 Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 17:18 To: Zheng Hewen Cc: Victor Pascual =C2=A8?vila; Yao Wang; Henry Sinnreich; Philip = Matthews; Wei Gengyu; P2PSIP Mailing List Subject: Re: client protocol ([P2PSIP] Proposal for progress on = protocols) According to concept draft, "Since P2PSIP is about peer-to-peer networks = for real-time communication, it is expected that most (if not all) peers = and clients will be coupled with SIP entities." So I think SIP protocol = is mandatory in most nodes (if not all).=20 =20 On 11/14/07, Zheng Hewen wrote:=20 Hi, =20 In my impression, SIP protocol has never been mandatory for the = communication protocol between any two P2PSIP nodes. I encourage you to read the consensus about the relation of P2PSIP = and SIP from IETF69 P2PSIP WG minute ( = http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt). Hope that it will be helpful for you.=20 =20 Best regards, Hewen _____ =20 From: lichun li [mailto:lilichun@gmail.com]=20 Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 16:43=20 To: Zheng Hewen Cc: Victor Pascual =C2=A8=EF=BF=A0vila; Yao Wang; Henry Sinnreich; = Philip Matthews; Wei Gengyu; P2PSIP Mailing List=20 Subject: Re: client protocol ([P2PSIP] Proposal for progress on = protocols) =20 SIP protocol is mandatory.=20 If peer protocol is not SIP based, a peer has to run two protocol = stacks. If client protocol is SIP based, a client only need to run one protocol = stack. =20 On 11/14/07, Zheng Hewen wrote:=20 Hi, I do think so, too. The same protocol stack for Peer protocol and Client protocol is more = efficient and simple.=20 Best regards, Hewen > -----Original Message----- > From: Victor Pascual =C2=A8=C2=A2vila [mailto: = victor.pascual.avila@gmail.com] > Sent: 2007=C3=84=C3=AA11=C3=94=C3=8214=C3=88=C3=95 16:16=20 > To: Zheng Hewen > Cc: Yao Wang; Henry Sinnreich; Philip Matthews; lichun li; > Wei Gengyu; P2PSIP Mailing List > Subject: Re: client protocol ([P2PSIP] Proposal for progress=20 > on protocols)=20 > > On 14/11/2007, Zheng Hewen wrote: > > Frankly, I think that reaching an agreement about P2PSIP=20 > client behavior/character is necessary before developing=20 > P2PSIP client protocol, otherwise it will be very difficult > to develop P2PSIP client protocol. > > > I'm fully agree with you.=20 > Defining what tasks P2PSIP peers perform, we should be able=20 > to define the P2PSIP client behaviour and requirements. > Since a peer should be able to change its role and become a > Client, I consider using the same protocol stack for Peer=20 > Protocol and Client Protocol what is not necessary SIP-based=20 > -depending on requirements-. > > Thanks, > -- > Victor Pascual =C2=A8=C2=A2vila > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT=20 --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT=20 --Boundary_(ID_3C3L1+00AQnhcD1+bqaDXA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
Hi,
 
   You are right, "Since P2PSIP is = about=20 peer-to-peer networks for real-time communication, it is expected that = most (if=20 not all) peers and clients will be coupled with SIP=20 entities."
   You also notice the limitation, = i.e. "most=20 (if not all) ". Some peers couple with SIP entity, but some do not, as = Reference=20 model, SIP is not mandatory for those peer without any SIP entity, those = peers=20 without any SIP entity only participate P2PSIP overlay network and = contribute=20 its storage capacity.
   I do think that SIP is useful as = the=20 communication protocol between a peer with SIP entity(proxy/registrar) = and its=20 associated clients with SIP UA, but it is only one = choice.
 
Best regards,
Hewen
 

From: lichun li = [mailto:lilichun@gmail.com]=20
Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 = 17:18
To: Zheng Hewen
Cc:=20 Victor Pascual =C2=A8?vila; Yao Wang; Henry Sinnreich; Philip = Matthews; Wei Gengyu;=20 P2PSIP Mailing List
Subject: Re: client protocol ([P2PSIP] = Proposal=20 for progress on protocols)

According to concept draft, "Since P2PSIP is about peer-to-peer = networks=20 for real-time communication, it is expected that most (if not all) = peers=20 and
   clients will be coupled with SIP entities." = So I=20 think SIP protocol is mandatory in most nodes (if not all).

 
On 11/14/07, Zheng=20 Hewen <hwzheng@huawei.com>=20 wrote:=20
Hi,
 
     In my impression, SIP protocol has = never=20 been mandatory for the communication protocol between any two P2PSIP = nodes.
     I encourage you to read the = consensus=20 about the relation of P2PSIP and SIP from IETF69 P2PSIP WG minute ( = http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt= ).
    =20 Hope that it will be helpful for you.
 
Best=20 regards,
Hewen

From: lichun li [mailto:lilichun@gmail.com]=20
Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 16:43 =
To: Zheng=20 Hewen
Cc: Victor Pascual =C2=A8=EF=BF=A0vila; Yao Wang; = Henry Sinnreich;=20 Philip Matthews; Wei Gengyu; P2PSIP Mailing List=20

Subject: = Re: client=20 protocol ([P2PSIP] Proposal for progress on=20 protocols)

 
SIP protocol is mandatory.
If peer protocol is not SIP based, a peer has to = run two=20 protocol stacks.
If client protocol is SIP based, a client only need to run = one=20 protocol stack.

 
On 11/14/07, Zheng=20 Hewen <hwzheng@huawei.com >=20 wrote:=20
Hi,

  =20 I do think so, too.
   The same protocol stack for = Peer=20 protocol and Client protocol is more efficient and simple. =

Best=20 regards,
Hewen

> -----Original Message-----
> = From:=20 Victor Pascual =C2=A8=C2=A2vila [mailto:=20 victor.pascual.avila@gmail.com]
> Sent: = 2007=C3=84=C3=AA11=C3=94=C3=8214=C3=88=C3=95 16:16=20
> To: Zheng Hewen
> Cc: Yao Wang; Henry Sinnreich; = Philip=20 Matthews; lichun li;
> Wei Gengyu; P2PSIP Mailing = List
>=20 Subject: Re: client protocol ([P2PSIP] Proposal for progress =
> on=20 protocols)
>
> On 14/11/2007, Zheng Hewen <hwzheng@huawei.com> wrote:
> > = Frankly, I=20 think that reaching an agreement about P2PSIP
> client=20 behavior/character is necessary before developing
> = P2PSIP client=20 protocol, otherwise it will be very difficult
> to develop = P2PSIP=20 client protocol.
>
>
> I'm fully agree with = you.=20
> Defining what tasks P2PSIP peers perform, we should be = able=20
> to define the P2PSIP client behaviour and = requirements.
>=20 Since a peer should be able to change its role and become = a
>=20 Client, I consider using the same protocol stack for Peer =
>=20 Protocol and Client Protocol what is not necessary SIP-based =
>=20 -depending on requirements-.
>
> Thanks,
> = --
>=20 Victor Pascual = =C2=A8=C2=A2vila
>





--
Sincerely yours,

Lichun Li
Mobile = Life New=20 Media Lab, BUPT =


--
Sincerely yours,

Lichun Li
Mobile = Life New=20 Media Lab, BUPT --Boundary_(ID_3C3L1+00AQnhcD1+bqaDXA)-- --===============1217898523== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1217898523==-- From p2psip-bounces@ietf.org Wed Nov 14 04:34:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEe1-0004ty-CS; Wed, 14 Nov 2007 04:34:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEe0-0004sn-0b for p2psip@ietf.org; Wed, 14 Nov 2007 04:34:48 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEdu-00035c-Fs for p2psip@ietf.org; Wed, 14 Nov 2007 04:34:47 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH007DKP5K1F@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 17:32:08 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH002PIP5I8C@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 17:32:08 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRH00ICJP5ECD@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 17:32:06 +0800 (CST) Date: Wed, 14 Nov 2007 17:32:05 +0800 From: Zheng Hewen Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) In-reply-to: <008201c828fb$20010820$da07740a@DELLWEI> To: 'Wei Gengyu' Message-id: <001d01c826a1$38671910$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acgmn6iUsQBk9hxZR5ShY+r1ZmEo5wAAUFFQ X-Spam-Score: 0.6 (/) X-Scan-Signature: 4c358d334afcd91b425d436ca5722f22 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0358432208==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0358432208== Content-type: multipart/alternative; boundary="Boundary_(ID_k9pGFqcaO2k32MUXaiBVqA)" This is a multi-part message in MIME format. --Boundary_(ID_k9pGFqcaO2k32MUXaiBVqA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable Hi, =20 In fact, we think that any P2PSIP client couples with SIP UA, SIP is = not harmful for P2PSIP clients. Agree with your opinion that Concept draft needs been updated. =20 Best regards, Hewen _____ =20 From: Wei Gengyu [mailto:weigengyu@vip.sina.com]=20 Sent: 2007=E5=B9=B411=E6=9C=8817=E6=97=A5 17:21 To: Zheng Hewen Cc: 'P2PSIP Mailing List' Subject: Re: client protocol ([P2PSIP] Proposal for progress on = protocols) Hi,=20 =20 As far as I know,=20 SIP have been standardized and deployed in a lot of PCs and mobile = terminals. SIP is already there while P2PSIP client protocol is under discussion. =20 Adopting SIP is more easier to allow any terminal to access P2PSIP = overlay than another new protocols. And I do not see any harmful to P2PSIP overlay if SIP is used in client. =20 I also agree with Victor Pascual =C3=81vila and the Concept draft need = updating. =20 Gengyu =20 ----- Original Message -----=20 From: Zheng Hewen =20 To: 'lichun li' =20 Cc: 'Victor Pascual =C2=A8?vila' = ; 'Yao Wang' ; 'Henry Sinnreich' = ; 'Philip Matthews' = ; 'Wei = Gengyu' ; 'P2PSIP = Mailing List'=20 Sent: Wednesday, November 14, 2007 4:58 PM Subject: RE: client protocol ([P2PSIP] Proposal for progress on = protocols) Hi, =20 In my impression, SIP protocol has never been mandatory for the = communication protocol between any two P2PSIP nodes. I encourage you to read the consensus about the relation of P2PSIP = and SIP from IETF69 P2PSIP WG minute = (http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt). Hope that it will be helpful for you. =20 Best regards, Hewen _____ =20 From: lichun li [mailto:lilichun@gmail.com]=20 Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 16:43 To: Zheng Hewen Cc: Victor Pascual =C2=A8=EF=BF=A0vila; Yao Wang; Henry Sinnreich; = Philip Matthews; Wei Gengyu; P2PSIP Mailing List Subject: Re: client protocol ([P2PSIP] Proposal for progress on = protocols) SIP protocol is mandatory.=20 If peer protocol is not SIP based, a peer has to run two protocol = stacks. If client protocol is SIP based, a client only need to run one protocol = stack. =20 On 11/14/07, Zheng Hewen wrote:=20 Hi, I do think so, too. The same protocol stack for Peer protocol and Client protocol is more = efficient and simple.=20 Best regards, Hewen > -----Original Message----- > From: Victor Pascual =C2=A8=C2=A2vila = [mailto:victor.pascual.avila@gmail.com] > Sent: 2007=C3=84=C3=AA11=C3=94=C3=8214=C3=88=C3=95 16:16=20 > To: Zheng Hewen > Cc: Yao Wang; Henry Sinnreich; Philip Matthews; lichun li; > Wei Gengyu; P2PSIP Mailing List > Subject: Re: client protocol ([P2PSIP] Proposal for progress > on protocols)=20 > > On 14/11/2007, Zheng Hewen wrote: > > Frankly, I think that reaching an agreement about P2PSIP > client behavior/character is necessary before developing=20 > P2PSIP client protocol, otherwise it will be very difficult > to develop P2PSIP client protocol. > > > I'm fully agree with you. > Defining what tasks P2PSIP peers perform, we should be able=20 > to define the P2PSIP client behaviour and requirements. > Since a peer should be able to change its role and become a > Client, I consider using the same protocol stack for Peer > Protocol and Client Protocol what is not necessary SIP-based=20 > -depending on requirements-. > > Thanks, > -- > Victor Pascual =C2=A8=C2=A2vila > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT=20 --Boundary_(ID_k9pGFqcaO2k32MUXaiBVqA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
Hi,
 
    In fact, we think that any = P2PSIP client=20 couples with SIP UA, SIP is not harmful for P2PSIP = clients.
    Agree with your opinion that = Concept=20 draft needs been updated.
 
Best regards,
Hewen

From: Wei Gengyu=20 [mailto:weigengyu@vip.sina.com]
Sent: = 2007=E5=B9=B411=E6=9C=8817=E6=97=A5=20 17:21
To: Zheng Hewen
Cc: 'P2PSIP Mailing=20 List'
Subject: Re: client protocol ([P2PSIP] Proposal for = progress=20 on protocols)

Hi,
 
As far as I know, =
SIP have been = standardized and deployed in a lot of=20 PCs and mobile terminals.
SIP is already there = while P2PSIP client protocol is=20 under discussion.
 
Adopting SIP is more = easier to allow any terminal to=20 access P2PSIP overlay than another new protocols.
And I do not see any = harmful to P2PSIP overlay if=20 SIP is used in client.
 
I also agree with Victor Pascual =C3=81vila=20 and the Concept draft need = updating.
 
Gengyu
 
----- Original Message = -----
From: Zheng = Hewen=20
Sent: Wednesday, = November 14, 2007 4:58=20 PM
Subject: RE: = client protocol ([P2PSIP]=20 Proposal for progress on protocols)

Hi,
 
     In my impression, = SIP protocol=20 has never been mandatory for the communication protocol between any = two=20 P2PSIP nodes.
     I encourage you to read = the=20 consensus about the relation of P2PSIP and SIP from IETF69 P2PSIP WG = minute=20 (http:/= /www3.ietf.org/proceedings/07jul/minutes/p2psip.txt).
  =   =20 Hope that it will be helpful for you.
 
Best regards,
Hewen

From: lichun li=20 [mailto:lilichun@gmail.com]
Sent: = 2007=E5=B9=B411=E6=9C=8814=E6=97=A5=20 16:43
To: Zheng Hewen
Cc: Victor Pascual = =C2=A8=EF=BF=A0vila; Yao=20 Wang; Henry Sinnreich; Philip Matthews; Wei Gengyu; P2PSIP Mailing = List
Subject: Re: client protocol ([P2PSIP] Proposal for = progress on protocols)

SIP protocol is mandatory.
If peer protocol is not SIP based, a peer has to = run two=20 protocol stacks.
If client protocol is SIP based, a client only need to run = one=20 protocol stack.

 
On 11/14/07, Zheng=20 Hewen <hwzheng@huawei.com> = wrote:=20
Hi,

  =20 I do think so, too.
   The same protocol stack for = Peer=20 protocol and Client protocol is more efficient and simple. =

Best=20 regards,
Hewen

> -----Original Message-----
> = From:=20 Victor Pascual =C2=A8=C2=A2vila [mailto:victor.pascual.avila@gmail= .com]
>=20 Sent: 2007=C3=84=C3=AA11=C3=94=C3=8214=C3=88=C3=95 16:16 =
> To: Zheng Hewen
> Cc: Yao=20 Wang; Henry Sinnreich; Philip Matthews; lichun li;
> Wei = Gengyu;=20 P2PSIP Mailing List
> Subject: Re: client protocol = ([P2PSIP]=20 Proposal for progress
> on protocols)
>
> On=20 14/11/2007, Zheng Hewen <hwzheng@huawei.com>=20 wrote:
> > Frankly, I think that reaching an agreement = about=20 P2PSIP
> client behavior/character is necessary before = developing=20
> P2PSIP client protocol, otherwise it will be very=20 difficult
> to develop P2PSIP client=20 protocol.
>
>
> I'm fully agree with = you.
>=20 Defining what tasks P2PSIP peers perform, we should be able =
> to=20 define the P2PSIP client behaviour and requirements.
> = Since a=20 peer should be able to change its role and become a
> = Client, I=20 consider using the same protocol stack for Peer
> Protocol = and=20 Client Protocol what is not necessary SIP-based
> = -depending on=20 requirements-.
>
> Thanks,
> --
> Victor = Pascual=20 = =C2=A8=C2=A2vila
>






--=20
Sincerely yours,

Lichun Li
Mobile Life New Media = Lab, BUPT=20
--Boundary_(ID_k9pGFqcaO2k32MUXaiBVqA)-- --===============0358432208== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0358432208==-- From p2psip-bounces@ietf.org Wed Nov 14 04:40:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEjC-00021w-0P; Wed, 14 Nov 2007 04:40:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEjA-000200-5l for p2psip@ietf.org; Wed, 14 Nov 2007 04:40:08 -0500 Received: from el-out-1112.google.com ([209.85.162.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEj7-0003F1-S7 for p2psip@ietf.org; Wed, 14 Nov 2007 04:40:08 -0500 Received: by el-out-1112.google.com with SMTP id s27so36966ele for ; Wed, 14 Nov 2007 01:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=0S4vjiSynxXDhm4ysHBZaG0+7Ki/xg6rawpxUKEijp4=; b=DyNWpXFeOS5WkFXa2q9RO18hylBS0rLQ9g+jo7UTTC/jXWJm1al/nt6rOY1h4rIuY0YWP1ojq+sg3jwFLFElAKKlUrs9vISk44fMXx0Ch6Gfj5O9r+YFbpiJTUeYhZL3w9CjyLz7eJLpQWBSW3sHqE0IYm5Qcb4RaKWfnzOuTQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=rQtDxuQHllgOn0erFQ3ki1e75AsL4biA+pa8lVEKGiDDiioUmn/qHNrfSgmsKA3e88JNfYFMIR4em66HfKphhCwmXcHshiz26MjugqzQaUjGJ78b2VtXmCHL8kQ28VE3OMxWqUAFW8VD36UFMQNyXEt1D/UXsrBHw8pSs0d6DcI= Received: by 10.143.157.10 with SMTP id j10mr1419538wfo.1195033204574; Wed, 14 Nov 2007 01:40:04 -0800 (PST) Received: by 10.142.200.16 with HTTP; Wed, 14 Nov 2007 01:40:04 -0800 (PST) Message-ID: <7d6b50690711140140x7eb57a1ib480e3186dae9d96@mail.gmail.com> Date: Wed, 14 Nov 2007 17:40:04 +0800 From: "lichun li" To: "Zheng Hewen" Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols) In-Reply-To: <001801c826a0$d0b2a2d0$5105a40a@china.huawei.com> MIME-Version: 1.0 References: <7d6b50690711140118g7604dfbbnfeaa5b7135dfd70@mail.gmail.com> <001801c826a0$d0b2a2d0$5105a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Cc: P2PSIP Mailing List , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1111703021==" Errors-To: p2psip-bounces@ietf.org --===============1111703021== Content-Type: multipart/alternative; boundary="----=_Part_32199_26690997.1195033204568" ------=_Part_32199_26690997.1195033204568 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline WWVzLCBpIG5vdGljZSB0aGUgbGltaXRhdGlvbi4gV2UgaGF2ZSB0byBpZGVudGlmeSB0aGUgcm9s ZSBvZiBjbGllbnQgZmlyc3QuClRoZSBjb25jZXB0IGRyYWZ0IGN1cnJlbnRseSBsaXN0IDMgY2hv aWNlcyBvZiBjbGllbnQgcm9sZXMuIEkgdGhpbmsKbWF5YmUgZGlmZmVyZW50IGNsaWVudHMgd2l0 aCBkaWZmZXJlbnQgcm9sZXMgbWlnaHQgY29leGlzdCBpbiBQMlBTSVAuCgoKT24gMTEvMTQvMDcs IFpoZW5nIEhld2VuIDxod3poZW5nQGh1YXdlaS5jb20+IHdyb3RlOgo+Cj4gIEhpLAo+Cj4gICAg WW91IGFyZSByaWdodCwgIlNpbmNlIFAyUFNJUCBpcyBhYm91dCBwZWVyLXRvLXBlZXIgbmV0d29y a3MgZm9yCj4gcmVhbC10aW1lIGNvbW11bmljYXRpb24sIGl0IGlzIGV4cGVjdGVkIHRoYXQgbW9z dCAoaWYgbm90IGFsbCkgcGVlcnMgYW5kCj4gY2xpZW50cyB3aWxsIGJlIGNvdXBsZWQgd2l0aCBT SVAgZW50aXRpZXMuIgo+ICAgIFlvdSBhbHNvIG5vdGljZSB0aGUgbGltaXRhdGlvbiwgaS5lLiAi bW9zdCAoaWYgbm90IGFsbCkgIi4gU29tZSBwZWVycwo+IGNvdXBsZSB3aXRoIFNJUCBlbnRpdHks IGJ1dCBzb21lIGRvIG5vdCwgYXMgUmVmZXJlbmNlIG1vZGVsLCBTSVAgaXMgbm90Cj4gbWFuZGF0 b3J5IGZvciB0aG9zZSBwZWVyIHdpdGhvdXQgYW55IFNJUCBlbnRpdHksIHRob3NlIHBlZXJzIHdp dGhvdXQgYW55IFNJUAo+IGVudGl0eSBvbmx5IHBhcnRpY2lwYXRlIFAyUFNJUCBvdmVybGF5IG5l dHdvcmsgYW5kIGNvbnRyaWJ1dGUgaXRzIHN0b3JhZ2UKPiBjYXBhY2l0eS4KPiAgICBJIGRvIHRo aW5rIHRoYXQgU0lQIGlzIHVzZWZ1bCBhcyB0aGUgY29tbXVuaWNhdGlvbiBwcm90b2NvbCBiZXR3 ZWVuIGEKPiBwZWVyIHdpdGggU0lQIGVudGl0eShwcm94eS9yZWdpc3RyYXIpIGFuZCBpdHMgYXNz b2NpYXRlZCBjbGllbnRzIHdpdGggU0lQCj4gVUEsIGJ1dCBpdCBpcyBvbmx5IG9uZSBjaG9pY2Uu Cj4KPiBCZXN0IHJlZ2FyZHMsCj4gSGV3ZW4KPgo+Cj4gIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQo+ICpGcm9tOiogbGljaHVuIGxpIFttYWlsdG86bGlsaWNodW5AZ21haWwuY29tXQo+ ICpTZW50OiogMjAwN+W5tDEx5pyIMTTml6UgMTc6MTgKPiAqVG86KiBaaGVuZyBIZXdlbgo+ICpD YzoqIFZpY3RvciBQYXNjdWFsIMKoP3ZpbGE7IFlhbyBXYW5nOyBIZW5yeSBTaW5ucmVpY2g7IFBo aWxpcCBNYXR0aGV3czsKPiBXZWkgR2VuZ3l1OyBQMlBTSVAgTWFpbGluZyBMaXN0Cj4gKlN1Ympl Y3Q6KiBSZTogY2xpZW50IHByb3RvY29sIChbUDJQU0lQXSBQcm9wb3NhbCBmb3IgcHJvZ3Jlc3Mg b24KPiBwcm90b2NvbHMpCj4KPgo+ICBBY2NvcmRpbmcgdG8gY29uY2VwdCBkcmFmdCwgIlNpbmNl IFAyUFNJUCBpcyBhYm91dCBwZWVyLXRvLXBlZXIgbmV0d29ya3MKPiBmb3IgcmVhbC10aW1lIGNv bW11bmljYXRpb24sIGl0IGlzIGV4cGVjdGVkIHRoYXQgbW9zdCAoaWYgbm90IGFsbCkgcGVlcnMg YW5kCj4gICAgY2xpZW50cyB3aWxsIGJlIGNvdXBsZWQgd2l0aCBTSVAgZW50aXRpZXMuIiBTbyBJ IHRoaW5rIFNJUCBwcm90b2NvbCBpcwo+IG1hbmRhdG9yeSBpbiBtb3N0IG5vZGVzIChpZiBub3Qg YWxsKS4KPgo+Cj4gT24gMTEvMTQvMDcsIFpoZW5nIEhld2VuIDxod3poZW5nQGh1YXdlaS5jb20+ IHdyb3RlOgo+ID4KPiA+ICBIaSwKPiA+Cj4gPiAgICAgIEluIG15IGltcHJlc3Npb24sIFNJUCBw cm90b2NvbCBoYXMgbmV2ZXIgYmVlbiBtYW5kYXRvcnkgZm9yIHRoZQo+ID4gY29tbXVuaWNhdGlv biBwcm90b2NvbCBiZXR3ZWVuIGFueSB0d28gUDJQU0lQIG5vZGVzLgo+ID4gICAgICBJIGVuY291 cmFnZSB5b3UgdG8gcmVhZCB0aGUgY29uc2Vuc3VzIGFib3V0IHRoZSByZWxhdGlvbiBvZiBQMlBT SVAKPiA+IGFuZCBTSVAgZnJvbSBJRVRGNjkgUDJQU0lQIFdHIG1pbnV0ZSAoCj4gPiBodHRwOi8v d3d3My5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wN2p1bC9taW51dGVzL3AycHNpcC50eHQpLgo+ID4g ICAgICBIb3BlIHRoYXQgaXQgd2lsbCBiZSBoZWxwZnVsIGZvciB5b3UuCj4gPgo+ID4gQmVzdCBy ZWdhcmRzLAo+ID4gSGV3ZW4KPiA+Cj4gPiAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Cj4gPiAqRnJvbToqIGxpY2h1biBsaSBbbWFpbHRvOmxpbGljaHVuQGdtYWlsLmNvbV0KPiA+ICpT ZW50OiogMjAwN+W5tDEx5pyIMTTml6UgMTY6NDMKPiA+ICpUbzoqIFpoZW5nIEhld2VuCj4gPiAq Q2M6KiBWaWN0b3IgUGFzY3VhbCDCqO+/oHZpbGE7IFlhbyBXYW5nOyBIZW5yeSBTaW5ucmVpY2g7 IFBoaWxpcCBNYXR0aGV3czsKPiA+IFdlaSBHZW5neXU7IFAyUFNJUCBNYWlsaW5nIExpc3QKPiA+ ICpTdWJqZWN0OiogUmU6IGNsaWVudCBwcm90b2NvbCAoW1AyUFNJUF0gUHJvcG9zYWwgZm9yIHBy b2dyZXNzIG9uCj4gPiBwcm90b2NvbHMpCj4gPgo+ID4KPiA+ICBTSVAgcHJvdG9jb2wgaXMgbWFu ZGF0b3J5Lgo+ID4gSWYgcGVlciBwcm90b2NvbCBpcyBub3QgU0lQIGJhc2VkLCBhIHBlZXIgaGFz IHRvIHJ1biB0d28gcHJvdG9jb2wKPiA+IHN0YWNrcy4KPiA+IElmIGNsaWVudCBwcm90b2NvbCBp cyBTSVAgYmFzZWQsIGEgY2xpZW50IG9ubHkgbmVlZCB0byBydW4gb25lIHByb3RvY29sCj4gPiBz dGFjay4KPiA+Cj4gPgo+ID4gT24gMTEvMTQvMDcsIFpoZW5nIEhld2VuIDxod3poZW5nQGh1YXdl aS5jb20gPiB3cm90ZToKPiA+ID4KPiA+ID4gSGksCj4gPiA+Cj4gPiA+ICAgIEkgZG8gdGhpbmsg c28sIHRvby4KPiA+ID4gICAgVGhlIHNhbWUgcHJvdG9jb2wgc3RhY2sgZm9yIFBlZXIgcHJvdG9j b2wgYW5kIENsaWVudCBwcm90b2NvbCBpcwo+ID4gPiBtb3JlIGVmZmljaWVudCBhbmQgc2ltcGxl Lgo+ID4gPgo+ID4gPiBCZXN0IHJlZ2FyZHMsCj4gPiA+IEhld2VuCj4gPiA+Cj4gPiA+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiA+ID4gPiBGcm9tOiBWaWN0b3IgUGFzY3VhbCDCqMKi dmlsYSBbbWFpbHRvOiB2aWN0b3IucGFzY3VhbC5hdmlsYUBnbWFpbC5jb21dCj4gPiA+ID4gU2Vu dDogMjAwN8OEw6oxMcOUw4IxNMOIw5UgMTY6MTYKPiA+ID4gPiBUbzogWmhlbmcgSGV3ZW4KPiA+ ID4gPiBDYzogWWFvIFdhbmc7IEhlbnJ5IFNpbm5yZWljaDsgUGhpbGlwIE1hdHRoZXdzOyBsaWNo dW4gbGk7Cj4gPiA+ID4gV2VpIEdlbmd5dTsgUDJQU0lQIE1haWxpbmcgTGlzdAo+ID4gPiA+IFN1 YmplY3Q6IFJlOiBjbGllbnQgcHJvdG9jb2wgKFtQMlBTSVBdIFByb3Bvc2FsIGZvciBwcm9ncmVz cwo+ID4gPiA+IG9uIHByb3RvY29scykKPiA+ID4gPgo+ID4gPiA+IE9uIDE0LzExLzIwMDcsIFpo ZW5nIEhld2VuIDxod3poZW5nQGh1YXdlaS5jb20+IHdyb3RlOgo+ID4gPiA+ID4gRnJhbmtseSwg SSB0aGluayB0aGF0IHJlYWNoaW5nIGFuIGFncmVlbWVudCBhYm91dCBQMlBTSVAKPiA+ID4gPiBj bGllbnQgYmVoYXZpb3IvY2hhcmFjdGVyIGlzIG5lY2Vzc2FyeSBiZWZvcmUgZGV2ZWxvcGluZwo+ ID4gPiA+IFAyUFNJUCBjbGllbnQgcHJvdG9jb2wsIG90aGVyd2lzZSBpdCB3aWxsIGJlIHZlcnkg ZGlmZmljdWx0Cj4gPiA+ID4gdG8gZGV2ZWxvcCBQMlBTSVAgY2xpZW50IHByb3RvY29sLgo+ID4g PiA+Cj4gPiA+ID4KPiA+ID4gPiBJJ20gZnVsbHkgYWdyZWUgd2l0aCB5b3UuCj4gPiA+ID4gRGVm aW5pbmcgd2hhdCB0YXNrcyBQMlBTSVAgcGVlcnMgcGVyZm9ybSwgd2Ugc2hvdWxkIGJlIGFibGUK PiA+ID4gPiB0byBkZWZpbmUgdGhlIFAyUFNJUCBjbGllbnQgYmVoYXZpb3VyIGFuZCByZXF1aXJl bWVudHMuCj4gPiA+ID4gU2luY2UgYSBwZWVyIHNob3VsZCBiZSBhYmxlIHRvIGNoYW5nZSBpdHMg cm9sZSBhbmQgYmVjb21lIGEKPiA+ID4gPiBDbGllbnQsIEkgY29uc2lkZXIgdXNpbmcgdGhlIHNh bWUgcHJvdG9jb2wgc3RhY2sgZm9yIFBlZXIKPiA+ID4gPiBQcm90b2NvbCBhbmQgQ2xpZW50IFBy b3RvY29sIHdoYXQgaXMgbm90IG5lY2Vzc2FyeSBTSVAtYmFzZWQKPiA+ID4gPiAtZGVwZW5kaW5n IG9uIHJlcXVpcmVtZW50cy0uCj4gPiA+ID4KPiA+ID4gPiBUaGFua3MsCj4gPiA+ID4gLS0KPiA+ ID4gPiBWaWN0b3IgUGFzY3VhbCDCqMKidmlsYQo+ID4gPiA+Cj4gPiA+Cj4gPiA+Cj4gPiA+Cj4g PiA+Cj4gPgo+ID4KPiA+IC0tCj4gPiBTaW5jZXJlbHkgeW91cnMsCj4gPgo+ID4gTGljaHVuIExp Cj4gPiBNb2JpbGUgTGlmZSBOZXcgTWVkaWEgTGFiLCBCVVBUCj4gPgo+ID4KPgo+Cj4gLS0KPiBT aW5jZXJlbHkgeW91cnMsCj4KPiBMaWNodW4gTGkKPiBNb2JpbGUgTGlmZSBOZXcgTWVkaWEgTGFi LCBCVVBUCj4KPgoKCi0tIApTaW5jZXJlbHkgeW91cnMsCgpMaWNodW4gTGkKTW9iaWxlIExpZmUg TmV3IE1lZGlhIExhYiwgQlVQVAo= ------=_Part_32199_26690997.1195033204568 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5ZZXMsIGkgbm90aWNlJm5ic3A7dGhlIGxpbWl0YXRpb24uIFdlIGhhdmUgdG8gaWRlbnRp ZnkgdGhlIHJvbGUgb2YgY2xpZW50IGZpcnN0LiBUaGUgY29uY2VwdCBkcmFmdCBjdXJyZW50bHkm bmJzcDtsaXN0IDMgY2hvaWNlcyBvZiBjbGllbnQgcm9sZXMuIEkgdGhpbmsgbWF5YmUmbmJzcDtk aWZmZXJlbnQgY2xpZW50cyB3aXRoIGRpZmZlcmVudCByb2xlcyBtaWdodCBjb2V4aXN0Jm5ic3A7 aW4gUDJQU0lQLiZuYnNwOzwvZGl2PgoKPGRpdj48YnI+Jm5ic3A7PC9kaXY+CjxkaXY+PHNwYW4g Y2xhc3M9ImdtYWlsX3F1b3RlIj5PbiAxMS8xNC8wNywgPGIgY2xhc3M9ImdtYWlsX3NlbmRlcm5h bWUiPlpoZW5nIEhld2VuPC9iPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh3emhlbmdAaHVhd2VpLmNv bSI+aHd6aGVuZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPgo8YmxvY2txdW90ZSBj bGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHgg MHB4IDBweCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj4KPGRpdj4KPGRpdiBk aXI9Imx0ciIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIg c2l6ZT0iMiI+PHNwYW4+SGksPC9zcGFuPjwvZm9udD48L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxp Z249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+PHNw YW4+PC9zcGFuPjwvZm9udD4mbmJzcDs8L2Rpdj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQi Pjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0iMiI+PHNwYW4+Jm5ic3A7 Jm5ic3A7IFlvdSBhcmUgcmlnaHQsICZxdW90O1NpbmNlIFAyUFNJUCBpcyBhYm91dCBwZWVyLXRv LXBlZXIgbmV0d29ya3MgZm9yIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uLCBpdCBpcyBleHBlY3Rl ZCB0aGF0IG1vc3QgKGlmIG5vdCBhbGwpIHBlZXJzIGFuZCBjbGllbnRzIHdpbGwgYmUgY291cGxl ZCB3aXRoIFNJUCBlbnRpdGllcy4mcXVvdDsKPGJyPjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0i QXJpYWwiIGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIj48c3Bhbj4mbmJzcDsmbmJzcDsgWW91IGFs c28gbm90aWNlIHRoZSBsaW1pdGF0aW9uLCBpLmUuICZxdW90O21vc3QgKGlmIG5vdCBhbGwpICZx dW90Oy4gU29tZSBwZWVycyBjb3VwbGUgd2l0aCBTSVAgZW50aXR5LCBidXQgc29tZSBkbyBub3Qs IGFzIFJlZmVyZW5jZSBtb2RlbCwgU0lQIGlzIG5vdCBtYW5kYXRvcnkgZm9yIHRob3NlIHBlZXIg d2l0aG91dCBhbnkgU0lQIGVudGl0eSwgdGhvc2UgcGVlcnMgd2l0aG91dCBhbnkgU0lQIGVudGl0 eSBvbmx5IHBhcnRpY2lwYXRlIFAyUFNJUCBvdmVybGF5IG5ldHdvcmsgYW5kIGNvbnRyaWJ1dGUg aXRzIHN0b3JhZ2UgY2FwYWNpdHkuCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+CjxkaXYgZGlyPSJsdHIi IGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIi PjxzcGFuPiZuYnNwOyZuYnNwOyBJIGRvIHRoaW5rIHRoYXQgU0lQIGlzIHVzZWZ1bCBhcyB0aGUg Y29tbXVuaWNhdGlvbiBwcm90b2NvbCBiZXR3ZWVuIGEgcGVlciB3aXRoIFNJUCBlbnRpdHkocHJv eHkvcmVnaXN0cmFyKSBhbmQgaXRzIGFzc29jaWF0ZWQgY2xpZW50cyB3aXRoIFNJUCBVQSwgYnV0 IGl0IGlzIG9ubHkgb25lIGNob2ljZS4KPC9zcGFuPjwvZm9udD48L2Rpdj4KPGRpdiBkaXI9Imx0 ciIgYWxpZ249ImxlZnQiPjxmb250IGZhY2U9IkFyaWFsIiBjb2xvcj0iIzAwMDBmZiIgc2l6ZT0i MiI+PHNwYW4+PC9zcGFuPjwvZm9udD48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYi IHNpemU9IjIiPjxzcGFuPjwvc3Bhbj48L2ZvbnQ+Jm5ic3A7PC9kaXY+CjxkaXYgZGlyPSJsdHIi IGFsaWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIi PjxzcGFuPkJlc3QgcmVnYXJkcyw8L3NwYW4+PC9mb250PjwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBh bGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIj48 c3Bhbj5IZXdlbjwvc3Bhbj48L2ZvbnQ+PC9kaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0 Ij48Zm9udCBmYWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPjwvZm9udD4mbmJz cDs8L2Rpdj48YnI+CjxibG9ja3F1b3RlIHN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lO LUxFRlQ6IDVweDsgQk9SREVSLUxFRlQ6ICMwMDAwZmYgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6 IDBweCI+CjxkaXYgbGFuZz0iZW4tdXMiIGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+Cjxocj4KPGZv bnQgZmFjZT0iVGFob21hIiBzaXplPSIyIj48c3BhbiBjbGFzcz0icSI+PGI+RnJvbTo8L2I+IGxp Y2h1biBsaSBbbWFpbHRvOjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2lu ZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86bGlsaWNodW5AZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bGlsaWNodW5AZ21haWwuY29tPC9hPl0gPGJyPjwvc3Bhbj48Yj4KU2VudDo8L2I+ IDIwMDflubQxMeaciDE05pelIDE3OjE4IAo8ZGl2PjxzcGFuIGNsYXNzPSJlIiBpZD0icV8xMTYz ZDdkZmFiNjAyZmJiXzMiPjxicj48Yj5Ubzo8L2I+IFpoZW5nIEhld2VuPGJyPjxiPkNjOjwvYj4g VmljdG9yIFBhc2N1YWwgwqg/dmlsYTsgWWFvIFdhbmc7IEhlbnJ5IFNpbm5yZWljaDsgUGhpbGlw IE1hdHRoZXdzOyBXZWkgR2VuZ3l1OyBQMlBTSVAgTWFpbGluZyBMaXN0PGJyPjxiPlN1YmplY3Q6 PC9iPiBSZTogY2xpZW50IHByb3RvY29sIChbUDJQU0lQXSBQcm9wb3NhbCBmb3IgcHJvZ3Jlc3Mg b24gcHJvdG9jb2xzKQo8YnI+PC9zcGFuPjwvZGl2PjwvZm9udD48YnI+Jm5ic3A7PC9kaXY+Cjxk aXY+PHNwYW4gY2xhc3M9ImUiIGlkPSJxXzExNjNkN2RmYWI2MDJmYmJfNSI+CjxkaXY+PC9kaXY+ CjxkaXY+QWNjb3JkaW5nIHRvIGNvbmNlcHQgZHJhZnQsICZxdW90O1NpbmNlIFAyUFNJUCBpcyBh Ym91dCBwZWVyLXRvLXBlZXIgbmV0d29ya3MgZm9yIHJlYWwtdGltZSBjb21tdW5pY2F0aW9uLCBp dCBpcyBleHBlY3RlZCB0aGF0IG1vc3QgKGlmIG5vdCBhbGwpIHBlZXJzIGFuZDxicj4mbmJzcDsm bmJzcDsgY2xpZW50cyB3aWxsIGJlIGNvdXBsZWQgd2l0aCBTSVAgZW50aXRpZXMuJnF1b3Q7IFNv Jm5ic3A7SSB0aGluayBTSVAgcHJvdG9jb2wgaXMgbWFuZGF0b3J5IGluIG1vc3Qgbm9kZXMgKGlm IG5vdCBhbGwpLiAKPC9kaXY+CjxkaXY+PGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuIGNsYXNz PSJnbWFpbF9xdW90ZSI+T24gMTEvMTQvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5a aGVuZyBIZXdlbjwvYj4gJmx0OzxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmso d2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86aHd6aGVuZ0BodWF3ZWkuY29tIiB0YXJn ZXQ9Il9ibGFuayI+aHd6aGVuZ0BodWF3ZWkuY29tPC9hPgomZ3Q7IHdyb3RlOjwvc3Bhbj4gCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9IlBBRERJTkctTEVGVDogMWV4OyBN QVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQiPgo8 ZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4+PGZvbnQgZmFjZT0iQXJpYWwi IGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIj5IaSw8L2ZvbnQ+PC9zcGFuPjwvZGl2Pgo8ZGl2IGRp cj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjMDAw MGZmIiBzaXplPSIyIj48L2ZvbnQ+PC9zcGFuPiZuYnNwOzwvZGl2Pgo8ZGl2IGRpcj0ibHRyIiBh bGlnbj0ibGVmdCI+PHNwYW4+PGZvbnQgZmFjZT0iQXJpYWwiIGNvbG9yPSIjMDAwMGZmIiBzaXpl PSIyIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW4gbXkgaW1wcmVzc2lvbiwgU0lQIHByb3Rv Y29sIGhhcyBuZXZlciBiZWVuIG1hbmRhdG9yeSBmb3IgdGhlIGNvbW11bmljYXRpb24gcHJvdG9j b2wgYmV0d2VlbiBhbnkgdHdvIFAyUFNJUCBub2Rlcy48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IEkgZW5jb3VyYWdlIHlvdSB0byByZWFkIHRoZSBjb25zZW5zdXMgYWJvdXQgdGhlIHJlbGF0 aW9uIG9mIFAyUFNJUCBhbmQgU0lQIGZyb20gSUVURjY5IFAyUFNJUCBXRyBtaW51dGUgKCAKPGEg b25jbGljaz0icmV0dXJuIHRvcC5qcy5PcGVuRXh0TGluayh3aW5kb3csZXZlbnQsdGhpcykiIGhy ZWY9Imh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA3anVsL21pbnV0ZXMvcDJwc2lw LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA3 anVsL21pbnV0ZXMvcDJwc2lwLnR4dDwvYT4pLjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg SG9wZSB0aGF0IGl0IHdpbGwgYmUgaGVscGZ1bCBmb3IgeW91LiAKPC9mb250Pjwvc3Bhbj48L2Rp dj4KPGRpdiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPjxzcGFuPjwvc3Bhbj48c3Bhbj48Zm9udCBm YWNlPSJBcmlhbCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPjwvZm9udD48L3NwYW4+Jm5ic3A7 PC9kaXY+CjxkaXYgZGlyPSJsdHIiIGFsaWduPSJsZWZ0Ij48c3Bhbj48Zm9udCBmYWNlPSJBcmlh bCIgY29sb3I9IiMwMDAwZmYiIHNpemU9IjIiPkJlc3QgcmVnYXJkcyw8L2ZvbnQ+PC9zcGFuPjwv ZGl2Pgo8ZGl2IGRpcj0ibHRyIiBhbGlnbj0ibGVmdCI+PHNwYW4+PGZvbnQgZmFjZT0iQXJpYWwi IGNvbG9yPSIjMDAwMGZmIiBzaXplPSIyIj5IZXdlbjwvZm9udD48L3NwYW4+PC9kaXY+PGJyPgo8 YmxvY2txdW90ZSBzdHlsZT0iUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJP UkRFUi1MRUZUOiAjMDAwMGZmIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPgo8ZGl2IGxh bmc9ImVuLXVzIiBkaXI9Imx0ciIgYWxpZ249ImxlZnQiPgo8aHI+Cjxmb250IGZhY2U9IlRhaG9t YSIgc2l6ZT0iMiI+PGI+RnJvbTo8L2I+IGxpY2h1biBsaSBbbWFpbHRvOjxhIG9uY2xpY2s9InJl dHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86 bGlsaWNodW5AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bGlsaWNodW5AZ21haWwuY29tPC9h Pl0gPGJyPjxiPlNlbnQ6PC9iPiAyMDA35bm0MTHmnIgxNOaXpSAxNjo0MyAKPGJyPjxiPlRvOjwv Yj4gWmhlbmcgSGV3ZW48YnI+PGI+Q2M6PC9iPiBWaWN0b3IgUGFzY3VhbCDCqO+/oHZpbGE7IFlh byBXYW5nOyBIZW5yeSBTaW5ucmVpY2g7IFBoaWxpcCBNYXR0aGV3czsgV2VpIEdlbmd5dTsgUDJQ U0lQIE1haWxpbmcgTGlzdCAKPGRpdj48c3Bhbj48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBjbGll bnQgcHJvdG9jb2wgKFtQMlBTSVBdIFByb3Bvc2FsIGZvciBwcm9ncmVzcyBvbiBwcm90b2NvbHMp PGJyPjwvc3Bhbj48L2Rpdj48L2ZvbnQ+PGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuPgo8ZGl2 PjwvZGl2Pgo8ZGl2PlNJUCBwcm90b2NvbCZuYnNwO2lzIG1hbmRhdG9yeS4gPC9kaXY+CjxkaXY+ SWYgcGVlciBwcm90b2NvbCBpcyBub3QgU0lQIGJhc2VkLCZuYnNwO2EgcGVlciBoYXMgdG8gcnVu Jm5ic3A7dHdvIHByb3RvY29sIHN0YWNrcy48L2Rpdj4KPGRpdj5JZiBjbGllbnQgcHJvdG9jb2wg aXMgU0lQIGJhc2VkLCBhIGNsaWVudCBvbmx5IG5lZWQgdG8gcnVuIG9uZSBwcm90b2NvbCBzdGFj ay48YnI+PGJyPiZuYnNwOzwvZGl2Pgo8ZGl2PjxzcGFuIGNsYXNzPSJnbWFpbF9xdW90ZSI+T24g MTEvMTQvMDcsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj5aaGVuZyBIZXdlbjwvYj4gJmx0 OzxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMp IiBocmVmPSJtYWlsdG86aHd6aGVuZ0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHd6aGVu Z0BodWF3ZWkuY29tPC9hPgogJmd0OyB3cm90ZTo8L3NwYW4+IAo8YmxvY2txdW90ZSBjbGFzcz0i Z21haWxfcXVvdGUiIHN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHggMHB4IDBw eCAwLjhleDsgQk9SREVSLUxFRlQ6ICNjY2MgMXB4IHNvbGlkIj5IaSw8YnI+PGJyPiZuYnNwOyZu YnNwOyBJIGRvIHRoaW5rIHNvLCB0b28uPGJyPiZuYnNwOyZuYnNwOyBUaGUgc2FtZSBwcm90b2Nv bCBzdGFjayBmb3IgUGVlciBwcm90b2NvbCBhbmQgQ2xpZW50IHByb3RvY29sIGlzIG1vcmUgZWZm aWNpZW50IGFuZCBzaW1wbGUuIAo8YnI+PGJyPkJlc3QgcmVnYXJkcyw8YnI+SGV3ZW48YnI+PGJy PiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyBGcm9tOiBWaWN0b3IgUGFz Y3VhbCDCqMKidmlsYSBbbWFpbHRvOjxhIG9uY2xpY2s9InJldHVybiB0b3AuanMuT3BlbkV4dExp bmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86dmljdG9yLnBhc2N1YWwuYXZpbGFA Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+CiB2aWN0b3IucGFzY3VhbC5hdmlsYUBnbWFpbC5j b208L2E+XTxicj4mZ3Q7IFNlbnQ6IDIwMDfDhMOqMTHDlMOCMTTDiMOVIDE2OjE2IDxicj4mZ3Q7 IFRvOiBaaGVuZyBIZXdlbjxicj4mZ3Q7IENjOiBZYW8gV2FuZzsgSGVucnkgU2lubnJlaWNoOyBQ aGlsaXAgTWF0dGhld3M7IGxpY2h1biBsaTs8YnI+Jmd0OyBXZWkgR2VuZ3l1OyBQMlBTSVAgTWFp bGluZyBMaXN0PGJyPiZndDsgU3ViamVjdDogUmU6IGNsaWVudCBwcm90b2NvbCAoW1AyUFNJUF0g UHJvcG9zYWwgZm9yIHByb2dyZXNzIAo8YnI+Jmd0OyBvbiBwcm90b2NvbHMpIDxicj4mZ3Q7PGJy PiZndDsgT24gMTQvMTEvMjAwNywgWmhlbmcgSGV3ZW4gJmx0OzxhIG9uY2xpY2s9InJldHVybiB0 b3AuanMuT3BlbkV4dExpbmsod2luZG93LGV2ZW50LHRoaXMpIiBocmVmPSJtYWlsdG86aHd6aGVu Z0BodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aHd6aGVuZ0BodWF3ZWkuY29tPC9hPiZndDsg d3JvdGU6PGJyPiZndDsgJmd0OyBGcmFua2x5LCBJIHRoaW5rIHRoYXQgcmVhY2hpbmcgYW4gYWdy ZWVtZW50IGFib3V0IFAyUFNJUCAKPGJyPiZndDsgY2xpZW50IGJlaGF2aW9yL2NoYXJhY3RlciBp cyBuZWNlc3NhcnkgYmVmb3JlIGRldmVsb3BpbmcgPGJyPiZndDsgUDJQU0lQIGNsaWVudCBwcm90 b2NvbCwgb3RoZXJ3aXNlIGl0IHdpbGwgYmUgdmVyeSBkaWZmaWN1bHQ8YnI+Jmd0OyB0byBkZXZl bG9wIFAyUFNJUCBjbGllbnQgcHJvdG9jb2wuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IEkmIzM5 O20gZnVsbHkgYWdyZWUgd2l0aCB5b3UuIAo8YnI+Jmd0OyBEZWZpbmluZyB3aGF0IHRhc2tzIFAy UFNJUCBwZWVycyBwZXJmb3JtLCB3ZSBzaG91bGQgYmUgYWJsZSA8YnI+Jmd0OyB0byBkZWZpbmUg dGhlIFAyUFNJUCBjbGllbnQgYmVoYXZpb3VyIGFuZCByZXF1aXJlbWVudHMuPGJyPiZndDsgU2lu Y2UgYSBwZWVyIHNob3VsZCBiZSBhYmxlIHRvIGNoYW5nZSBpdHMgcm9sZSBhbmQgYmVjb21lIGE8 YnI+Jmd0OyBDbGllbnQsIEkgY29uc2lkZXIgdXNpbmcgdGhlIHNhbWUgcHJvdG9jb2wgc3RhY2sg Zm9yIFBlZXIgCjxicj4mZ3Q7IFByb3RvY29sIGFuZCBDbGllbnQgUHJvdG9jb2wgd2hhdCBpcyBu b3QgbmVjZXNzYXJ5IFNJUC1iYXNlZCA8YnI+Jmd0OyAtZGVwZW5kaW5nIG9uIHJlcXVpcmVtZW50 cy0uPGJyPiZndDs8YnI+Jmd0OyBUaGFua3MsPGJyPiZndDsgLS08YnI+Jmd0OyBWaWN0b3IgUGFz Y3VhbCDCqMKidmlsYTxicj4mZ3Q7PGJyPjxicj48YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48 YnI+PGJyIGNsZWFyPSJhbGwiPgo8YnI+LS0gPGJyPlNpbmNlcmVseSB5b3Vycyw8YnI+PGJyPkxp Y2h1biBMaTxicj5Nb2JpbGUgTGlmZSBOZXcgTWVkaWEgTGFiLCBCVVBUIDwvc3Bhbj48L2Rpdj48 L2Jsb2NrcXVvdGU+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48YnIgY2xlYXI9ImFsbCI+ PGJyPi0tIDxicj5TaW5jZXJlbHkgeW91cnMsPGJyPjxicj5MaWNodW4gTGk8YnI+TW9iaWxlIExp ZmUgTmV3IE1lZGlhIExhYiwgQlVQVCAKPC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48 L2Jsb2NrcXVvdGU+PC9kaXY+PGJyPjxiciBjbGVhcj0iYWxsIj48YnI+LS0gPGJyPlNpbmNlcmVs eSB5b3Vycyw8YnI+PGJyPkxpY2h1biBMaTxicj5Nb2JpbGUgTGlmZSBOZXcgTWVkaWEgTGFiLCBC VVBUIAo= ------=_Part_32199_26690997.1195033204568-- --===============1111703021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1111703021==-- From p2psip-bounces@ietf.org Wed Nov 14 04:48:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEqt-0007bH-Pk; Wed, 14 Nov 2007 04:48:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEqp-0007To-0n for p2psip@lists.ietf.org; Wed, 14 Nov 2007 04:48:03 -0500 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsEqj-0003Pq-N2 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 04:48:02 -0500 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 10:47:55 +0100 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 10:47:54 +0100 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 10:47:53 +0100 Message-ID: <473AC48A.3090503@telecomitalia.it> Date: Wed, 14 Nov 2007 10:48:58 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: Marcus Leech Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: In-Reply-To: X-OriginalArrivalTime: 14 Nov 2007 09:47:54.0339 (UTC) FILETIME=[6DC7BB30:01C826A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0105467402==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0105467402== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020106030303030509070102" This is a cryptographically signed message in MIME format. --------------ms020106030303030509070102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Probably a bit out of scope for this thread, I'd like to note that there are other ways of discouraging peers from trying to get arbitrary positions in the overlay. A notable example is Skype's approach, where ordinary nodes are promoted to super nodes only once in a while by some obscure element higher in the hierarchy. A similar but much less notable approach is what we propose in draft-marocco-p2psip-xpp-pcan, where a client becomes peer only when invited by a peer already in the overlay, and its location (or peerID or whatever) is assigned by the inviting peer . We would really appreciate comments about this as well. Enrico Marcus Leech wrote: > In a recent thread, Ekr writes: > >> Note that this can't be fixed purely by rate limiting at some central >> authority (though puzzles can help) because the computation is >> performed completely offline. The fix is to have the central authority >> dispense peer-ids, but then this breaks the binding between public >> keys and identities which is one of the major attractions of HIP. >> >> -Ekr > > I guess I don't understand why a central authority helps, except to act > as a rate-limiter. > > If our "attacker" has access to a large pool of source addresses, and > assuming models where "joining" the > mesh is an anonymous operation, I can't see how you can protect > against a barrage of requests (perhaps spread over > longer time periods) arriving from a vast flotilla of source > addresses, where the idea is that *one* of those requests will > > yield a topologically "useful" PeerID. > > If the notion is that *only* authenticated nodes may "join" an overlay, > then I can see rate-limiting based on the > identity of the requestors, but in the anonymous case, I can't see how > you can make this work. > --------------ms020106030303030509070102 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcxMTE0MDk0ODU4WjAjBgkqhkiG9w0BCQQxFgQUrcJS7ZRp ePc9m1Wb40Vpx9l72pEwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAG7H7GuZ0ENvLbd70riJRBwN0szCriC+h48yIeDfx5BUkikXYSxY7LIz xzj+lJsja/o20UCvbN2GV8xPKHLbIZIqwTNMp4SNPjtbKpmLAZCw9sbcTPz6q8ioRokUD90S SGpsq5hOXAmSde7rQUv+PnyT1nHTXiy2q0y8WIYRYw+wQBWe/3O9Sro4l7U0w5PeG5/Ru+5e 0OV47JZ+XCie5Ah8FsEcZsswicyAIA5VmXRUPqHa/73+HoCc5cAcnEval2/B9RFrtPlZ97X1 aUx22vo2qbDcFgib1dXHBGB7O8HZb94Q45PqPm3+JFp1XhGJ6Wnt64iim6tV5i46ev76jPQA AAAAAAA= --------------ms020106030303030509070102-- --===============0105467402== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0105467402==-- From p2psip-bounces@ietf.org Wed Nov 14 04:49:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEsN-0001QL-Ps; Wed, 14 Nov 2007 04:49:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEsM-0001PW-75 for p2psip@ietf.org; Wed, 14 Nov 2007 04:49:38 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsEsI-0002KP-F1 for p2psip@ietf.org; Wed, 14 Nov 2007 04:49:38 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH005ZGPYJ01@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 17:49:31 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRH005L0PYHER@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 17:49:31 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRH00JD1PYDED@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 14 Nov 2007 17:49:29 +0800 (CST) Date: Wed, 14 Nov 2007 17:49:28 +0800 From: Zheng Hewen Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) In-reply-to: <7d6b50690711140140x7eb57a1ib480e3186dae9d96@mail.gmail.com> To: 'lichun li' Message-id: <000301c826a3$a62a1680$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcgmomDCZFsD9+6FQASE4GtxBfC1WQAAIsfQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de8c36679aaa17b008853e74231c885 Cc: 'P2PSIP Mailing List' , 'Henry Sinnreich' , 'Philip Matthews' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0953157342==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0953157342== Content-type: multipart/alternative; boundary="Boundary_(ID_S1Jxi2/ui0FCI3Lry4mKyA)" This is a multi-part message in MIME format. --Boundary_(ID_S1Jxi2/ui0FCI3Lry4mKyA) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: quoted-printable "We have to identify the role of client first". Yeah, We come to the same point at last. Are all 3 choice of client role rational? Considering the third = alternative, if a client occupy a "Peer-ID", is the namespace fully = available for peers and resource-records? is there any difference = between a peer and a client? The concept document need updating to clarify P2PSIP client character, = do you think so? =20 _____ =20 From: lichun li [mailto:lilichun@gmail.com]=20 Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 17:40 To: Zheng Hewen Cc: Victor Pascual =C2=A8?vila; Yao Wang; Henry Sinnreich; Philip = Matthews; Wei Gengyu; P2PSIP Mailing List Subject: Re: client protocol ([P2PSIP] Proposal for progress on = protocols) Yes, i notice the limitation. We have to identify the role of client = first. The concept draft currently list 3 choices of client roles. I = think maybe different clients with different roles might coexist in = P2PSIP.=20 =20 On 11/14/07, Zheng Hewen wrote:=20 Hi, =20 You are right, "Since P2PSIP is about peer-to-peer networks for = real-time communication, it is expected that most (if not all) peers and = clients will be coupled with SIP entities."=20 You also notice the limitation, i.e. "most (if not all) ". Some peers = couple with SIP entity, but some do not, as Reference model, SIP is not = mandatory for those peer without any SIP entity, those peers without any = SIP entity only participate P2PSIP overlay network and contribute its = storage capacity.=20 I do think that SIP is useful as the communication protocol between a = peer with SIP entity(proxy/registrar) and its associated clients with = SIP UA, but it is only one choice.=20 =20 Best regards, Hewen =20 _____ =20 From: lichun li [mailto:lilichun@gmail.com]=20 Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 17:18=20 To: Zheng Hewen Cc: Victor Pascual =C2=A8?vila; Yao Wang; Henry Sinnreich; Philip = Matthews; Wei Gengyu; P2PSIP Mailing List Subject: Re: client protocol ([P2PSIP] Proposal for progress on = protocols)=20 =20 According to concept draft, "Since P2PSIP is about peer-to-peer networks = for real-time communication, it is expected that most (if not all) peers = and clients will be coupled with SIP entities." So I think SIP protocol = is mandatory in most nodes (if not all).=20 =20 On 11/14/07, Zheng Hewen wrote:=20 Hi, =20 In my impression, SIP protocol has never been mandatory for the = communication protocol between any two P2PSIP nodes. I encourage you to read the consensus about the relation of P2PSIP = and SIP from IETF69 P2PSIP WG minute ( = http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt). Hope that it will be helpful for you.=20 =20 Best regards, Hewen _____ =20 From: lichun li [mailto:lilichun@gmail.com]=20 Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 16:43=20 To: Zheng Hewen Cc: Victor Pascual =C2=A8=EF=BF=A0vila; Yao Wang; Henry Sinnreich; = Philip Matthews; Wei Gengyu; P2PSIP Mailing List=20 Subject: Re: client protocol ([P2PSIP] Proposal for progress on = protocols) =20 SIP protocol is mandatory.=20 If peer protocol is not SIP based, a peer has to run two protocol = stacks. If client protocol is SIP based, a client only need to run one protocol = stack. =20 On 11/14/07, Zheng Hewen wrote:=20 Hi, I do think so, too. The same protocol stack for Peer protocol and Client protocol is more = efficient and simple.=20 Best regards, Hewen > -----Original Message----- > From: Victor Pascual =C2=A8=C2=A2vila [mailto: = victor.pascual.avila@gmail.com] > Sent: 2007=C3=84=C3=AA11=C3=94=C3=8214=C3=88=C3=95 16:16=20 > To: Zheng Hewen > Cc: Yao Wang; Henry Sinnreich; Philip Matthews; lichun li; > Wei Gengyu; P2PSIP Mailing List > Subject: Re: client protocol ([P2PSIP] Proposal for progress=20 > on protocols)=20 > > On 14/11/2007, Zheng Hewen wrote: > > Frankly, I think that reaching an agreement about P2PSIP=20 > client behavior/character is necessary before developing=20 > P2PSIP client protocol, otherwise it will be very difficult > to develop P2PSIP client protocol. > > > I'm fully agree with you.=20 > Defining what tasks P2PSIP peers perform, we should be able=20 > to define the P2PSIP client behaviour and requirements. > Since a peer should be able to change its role and become a > Client, I consider using the same protocol stack for Peer=20 > Protocol and Client Protocol what is not necessary SIP-based=20 > -depending on requirements-. > > Thanks, > -- > Victor Pascual =C2=A8=C2=A2vila > --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT=20 --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT=20 --=20 Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT=20 --Boundary_(ID_S1Jxi2/ui0FCI3Lry4mKyA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
"We have to identify the role of client=20 first".
Yeah, We come to the same point at=20 last.
Are all 3 choice of client role rational? = Considering the=20 third alternative, if a client occupy a "Peer-ID", is the namespace = fully=20 available for peers and resource-records? is there any difference = between a peer=20 and a client?
The concept document need updating to clarify = P2PSIP client=20 character, do you think so?
 

From: lichun li = [mailto:lilichun@gmail.com]=20
Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 = 17:40
To: Zheng Hewen
Cc:=20 Victor Pascual =C2=A8?vila; Yao Wang; Henry Sinnreich; Philip = Matthews; Wei Gengyu;=20 P2PSIP Mailing List
Subject: Re: client protocol ([P2PSIP] = Proposal=20 for progress on protocols)

Yes, i notice the limitation. We have to identify the role = of client=20 first. The concept draft currently list 3 choices of client = roles. I=20 think maybe different clients with different roles might = coexist in=20 P2PSIP. 

 
On 11/14/07, Zheng=20 Hewen <hwzheng@huawei.com>=20 wrote:=20
Hi,
 
   You are right, "Since P2PSIP is about = peer-to-peer=20 networks for real-time communication, it is expected that most (if = not all)=20 peers and clients will be coupled with SIP entities."=20
  =20 You also notice the limitation, i.e. "most (if not all) ". Some = peers couple=20 with SIP entity, but some do not, as Reference model, SIP is not = mandatory=20 for those peer without any SIP entity, those peers without any SIP = entity=20 only participate P2PSIP overlay network and contribute its storage = capacity.=20
   I do think that SIP is useful as the = communication=20 protocol between a peer with SIP entity(proxy/registrar) and its = associated=20 clients with SIP UA, but it is only one choice.
 
Best=20 regards,
Hewen
 

From: lichun = li [mailto:lilichun@gmail.com]=20
Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 17:18=20

To: = Zheng=20 Hewen
Cc: Victor Pascual =C2=A8?vila; Yao Wang; Henry = Sinnreich;=20 Philip Matthews; Wei Gengyu; P2PSIP Mailing = List
Subject: Re:=20 client protocol ([P2PSIP] Proposal for progress on protocols)=20

 
According to concept draft, "Since P2PSIP is about = peer-to-peer=20 networks for real-time communication, it is expected that most (if = not=20 all) peers and
   clients will be coupled with SIP = entities."=20 So I think SIP protocol is mandatory in most nodes (if not = all).=20

 
On 11/14/07, Zheng=20 Hewen <hwzheng@huawei.com >=20 wrote:=20
Hi,
 
     In my impression, SIP protocol = has never=20 been mandatory for the communication protocol between any two = P2PSIP=20 nodes.
     I encourage you to read the = consensus=20 about the relation of P2PSIP and SIP from IETF69 P2PSIP WG = minute ( http://www3.ietf.org/proceedings/07jul/minutes/p2psip.txt= ).
    =20 Hope that it will be helpful for you.
 
Best=20 regards,
Hewen

From: lichun li [mailto:lilichun@gmail.com]=20
Sent: 2007=E5=B9=B411=E6=9C=8814=E6=97=A5 16:43 =
To: Zheng=20 Hewen
Cc: Victor Pascual =C2=A8=EF=BF=A0vila; Yao = Wang; Henry Sinnreich;=20 Philip Matthews; Wei Gengyu; P2PSIP Mailing List=20

Subject: Re: client protocol ([P2PSIP] = Proposal=20 for progress on = protocols)

 
SIP protocol is mandatory.
If peer protocol is not SIP based, a peer has to=20 run two protocol stacks.
If client protocol is SIP based, a client only need to = run one=20 protocol stack.

 
On 11/14/07, Zheng Hewen <hwzheng@huawei.com=20 > wrote:=20
Hi,

  =20 I do think so, too.
   The same protocol stack = for Peer=20 protocol and Client protocol is more efficient and simple.=20

Best regards,
Hewen

> -----Original=20 Message-----
> From: Victor Pascual =C2=A8=C2=A2vila = [mailto:=20 victor.pascual.avila@gmail.com]
> Sent: = 2007=C3=84=C3=AA11=C3=94=C3=8214=C3=88=C3=95=20 16:16
> To: Zheng Hewen
> Cc: Yao Wang; Henry=20 Sinnreich; Philip Matthews; lichun li;
> Wei Gengyu; = P2PSIP=20 Mailing List
> Subject: Re: client protocol ([P2PSIP] = Proposal=20 for progress
> on protocols)
>
> On = 14/11/2007,=20 Zheng Hewen <hwzheng@huawei.com> wrote:
> = >=20 Frankly, I think that reaching an agreement about P2PSIP =
>=20 client behavior/character is necessary before developing =
>=20 P2PSIP client protocol, otherwise it will be very = difficult
>=20 to develop P2PSIP client protocol.
>
>
> = I'm fully=20 agree with you.
> Defining what tasks P2PSIP peers = perform,=20 we should be able
> to define the P2PSIP client = behaviour and=20 requirements.
> Since a peer should be able to change = its role=20 and become a
> Client, I consider using the same = protocol=20 stack for Peer
> Protocol and Client Protocol what is = not=20 necessary SIP-based
> -depending on=20 requirements-.
>
> Thanks,
> --
> = Victor=20 Pascual = =C2=A8=C2=A2vila
>





--
Sincerely yours,

Lichun = Li
Mobile Life=20 New Media Lab, BUPT=20


--
Sincerely yours,

Lichun Li
Mobile = Life New=20 Media Lab, BUPT =

--
Sincerely yours,

Lichun Li
Mobile = Life New=20 Media Lab, BUPT --Boundary_(ID_S1Jxi2/ui0FCI3Lry4mKyA)-- --===============0953157342== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0953157342==-- From p2psip-bounces@ietf.org Wed Nov 14 05:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFN2-0003v6-8M; Wed, 14 Nov 2007 05:21:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFMy-0003pq-LV for p2psip@ietf.org; Wed, 14 Nov 2007 05:21:16 -0500 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsFMv-0004Di-Cf for p2psip@ietf.org; Wed, 14 Nov 2007 05:21:16 -0500 Received: by py-out-1112.google.com with SMTP id d32so4665208pye for ; Wed, 14 Nov 2007 02:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=penJ3jZRIqUIhX3ijp0a0BxtKikwDTSNPc0pv1cMqe8=; b=i9cfmugFr5XV3pdkvy6sHmyTtd1GzJz2P+4UBS7VHqJaifwPARBBcF0rCl/sWXdRKgGAnro723Dl7Bs1Nc7ghbTexbFolKKX76pOUgg3lql8fHgWofvvwTcRwLDkyPQ15xmHXVILqGe4kIbsp8N11d2Va2J5iyXqLiKJfbxmO5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=tx0qFiHUnCwJlYBDGbppyvTMRPaC//5xqbLGT2I4X8tCRJp3bFLnePE0064sR1rKgC/RJ0ZiraBiQ/GCTB/3ak3Fz5PSKeJK5R3bYvYQCdGOVuAReiHL66gmNBC7ZlXX5kHWfmTxztjsVZ05I8RuYm+iUo3+rlNvagOwUOqonbE= Received: by 10.64.27.13 with SMTP id a13mr3822154qba.1195035672103; Wed, 14 Nov 2007 02:21:12 -0800 (PST) Received: by 10.65.141.8 with HTTP; Wed, 14 Nov 2007 02:21:12 -0800 (PST) Message-ID: Date: Wed, 14 Nov 2007 11:21:12 +0100 From: "Simone Cirani" To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [P2PSIP] New draft: A Kademlia-based DHT for Resource Lookup in P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Luca Veltri (luca.velri@unipr.it) and I have submitted on Octeber 25th a new draft, which is available at http://www.ietf.org/internet-drafts/draft-cirani-p2psip-dsip-dhtkademlia-00.txt The draft describes a Kademlia-based protocol for Resource Lookup based on dSIP (although the authors of dSIP have decided to obsolete it). As a practical demonstration of the feasibility of the solution we have already provided a dSIP implementation (based on mjSip library) of both Chord and Kademlia, available from http://www.mjsip.org/projects/p2psip/p2psip_dsip_071025.zip ------------------ Abstract: This draft describes a Kademlia-based protocol for Resource Lookup in P2PSIP. The proposed protocol is based on dSIP, a SIP-based protocol proposed by other authors as generic framework for a distributed SIP Location Service. Although the dSIP authors have obsoleted the draft by a newer approach based on a binary protocol named RELOAD, we are still considering this SIP-based approach, due to implementation simplicity, possibility of reuse of already available SIP stack implementations, easy integration into existing UAs, minimization of the number of required protocols for a P2P UA, and widespread support for (and relative maturity of) the SIP standard. ------------------ Please feel free to send us your opinions and comments. Kind regards, Simone Cirani _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 05:29:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFUj-0006Yp-VR; Wed, 14 Nov 2007 05:29:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFUf-0006Sx-SI for p2psip@ietf.org; Wed, 14 Nov 2007 05:29:13 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsFUb-0004Nq-Sx for p2psip@ietf.org; Wed, 14 Nov 2007 05:29:13 -0500 Received: by ug-out-1314.google.com with SMTP id u2so797340uge for ; Wed, 14 Nov 2007 02:29:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=xJKT3s2IJwJTD/a+ifO0CRY0mu87MexiiS6D7ytAiI8=; b=m393Q4D0nZrdrW0EVqS2bQGAOZFDBiyoqx82g4U7MVfILu+rwOHbVpguedtpPFFua+JcuFnzzn6OFE/bgss+Pq5PDmvRjaW6zWbn4b/T4bQxUSl/gfbagm50kwmM8wwse20QL6FIolUePIPZBVnmjdMnFvcNjIyXGnrygqrJJn8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=e8LVu5FFo0VGgsjvXuHeORHMFO0iFRA5yvCp6bcDmlTI8S2u5HfSZqecogx7BomZMfBEM3iNJFeffzYDdzPQqXgEQAzDfKXUI3jlBqi+CdKliRGIwwBJQCoDOfdKg7DP8oEZwLkJ/84UoNhCRr498UTTTUCBHxzkTZ7mYKk1DD8= Received: by 10.67.22.14 with SMTP id z14mr1020714ugi.1195036149097; Wed, 14 Nov 2007 02:29:09 -0800 (PST) Received: by 10.66.252.5 with HTTP; Wed, 14 Nov 2007 02:29:09 -0800 (PST) Message-ID: <618e24240711140229l1419ac31m793139a0a0cf3c6e@mail.gmail.com> Date: Wed, 14 Nov 2007 11:29:09 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: "lichun li" Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols) In-Reply-To: <7d6b50690711140118g7604dfbbnfeaa5b7135dfd70@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6b50690711140043g546e12bkdfa3717f90704c47@mail.gmail.com> <000301c8269c$8fa8d7e0$5105a40a@china.huawei.com> <7d6b50690711140118g7604dfbbnfeaa5b7135dfd70@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: P2PSIP Mailing List , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 14/11/2007, lichun li wrote: > According to concept draft, "Since P2PSIP is about peer-to-peer networks for > real-time communication, it is expected that most (if not all) peers and > clients will be coupled with SIP entities." So I think SIP protocol is > mandatory in most nodes (if not all). I understand peers as being full backward compatible with SIP -since SIP RFC3261 UA would join the overlay using peers-, AFAIU It does not mean that SIP should be mandatory used for peers' communication. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 06:30:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGS8-0002Xi-QQ; Wed, 14 Nov 2007 06:30:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGS7-0002VQ-7K for p2psip@lists.ietf.org; Wed, 14 Nov 2007 06:30:39 -0500 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsGS3-0005xK-SE for p2psip@lists.ietf.org; Wed, 14 Nov 2007 06:30:39 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id CAE4A1F8D22; Wed, 14 Nov 2007 12:30:34 +0100 (CET) Message-ID: <473ADC5C.4070101@it.uc3m.es> Date: Wed, 14 Nov 2007 12:30:36 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <20071113144604.8CF0733C59@delta.rtfm.com> <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> In-Reply-To: <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-25.6767 TC:02 TRN:82 TV:5.0.1023(15544.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Henning and all, have deeply investigated the problem presented in this thread ( Even I=20 have some numbers about it). If we consider proof-of-work as crypto-puzzles (or something similar)=20 the attack can be performed in a relative short period of time. In=20 addition, if you use crypto-puzzles you must take into consideration=20 that not all the DHT nodes have the same CPU capacity, and then you=20 should adjust the complexity of the crypto-puzzle in order to allow=20 those less powerful nodes to solve it in a bounded time. What I consider the best option for a proof-of-work is to solicit the=20 user to introduce a CAPTCHA before getting the Peer-ID. The advantages ar= e: - Require the human intervention, and then the attack cannot be=20 automated. - The time spent to get one id is reduced for honest users (just few=20 seconds) but increase linearly with the number of Peer-IDs solicited,=20 making the attack costly in terms of time (for instance in the case of=20 105 nodes in the DHT). - This is a proof-of-work which every user independently on the CPU=20 capacity of his computer can perform. Then, the entry barriers to the=20 system are really low. I hope this could help in somehow and I would like your opinion. All the best, Rub=E9n. Henning Schulzrinne escribi=F3: > I find the notion of proof of work somewhat dubious for this=20 > application. With today's massive botnets, you'd have to impose=20 > proof-of-work on the order of days on a fast processor to make any=20 > difference. If a single sybil is fatal, even with the assumptions of=20 > roughly 10^5 attempts at guessing, it takes a single node a bit more=20 > than a day to subvert the DHT. With the typical 100,000 node botnet,=20 > it's one second until one of them hits pay dirt. > > Henning > > On Nov 13, 2007, at 10:10 AM, Marcus Leech wrote: > >> >> 1. You assign peer-ids at a central location so that each attacker >> oracle >> query is quite expensive. >> 2. You either require authentication or some kind of proof of work to >> get a peer-id, so this slows down chosen location attacks even >> more. >> -Ekr >> >> >> It would be useful to consider the anonymous case, with proofs-of-work >> required >> (presumably asymmetric in favour of the central authority), what >> constitutes >> an "adequate" delay mechanism for reasonable projections of overlay >> size. >> >> Pulling numbers out of my butt here, if the network size is O(10**5), >> and the >> work function typically takes a second or two to compute, the >> attacking >> flotilla needs to be able to expend O(10**5) CPU-seconds to surf the >> PeerID >> space to find one that's "useful". >> >> It seems to me that for small overlays, the central authority model >> (assuming >> anonymity) can't protect against oracle-type attacks unless the work >> factor >> of the proof function gets suitably large, correct? >> >> Let's pretend that the current Internet is O(2**32) in size. What is = a >> reasonable >> number for the ratio between total number of nodes, and those that ar= e >> peers in >> an overlay. Is 1:1 a reasonable number? Is 10:1 a reasonable number= ? >> Is 100:1 >> a reasonable number? I just don't know, and it would certainly be >> useful to have >> reasonable estimates to drive the analysis of whether the central >> authority model >> can be made to work for suitably-robust definitions of "work". >> >> But perhaps I just have a bullet lodged in my brain, and I'm not >> thinking things out >> clearly. >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 06:33:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGUZ-0006Ox-U3; Wed, 14 Nov 2007 06:33:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGUZ-0006Na-Ia for p2psip@lists.ietf.org; Wed, 14 Nov 2007 06:33:11 -0500 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsGUW-000638-Qp for p2psip@lists.ietf.org; Wed, 14 Nov 2007 06:33:11 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id EF2F3203486; Wed, 14 Nov 2007 12:33:07 +0100 (CET) Message-ID: <473ADCF9.2030203@it.uc3m.es> Date: Wed, 14 Nov 2007 12:33:13 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Enrico Marocco Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <473AC48A.3090503@telecomitalia.it> In-Reply-To: <473AC48A.3090503@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-19.6268 TC:02 TRN:63 TV:5.0.1023(15544.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Enrico and all, In the scheme you proposed I find that if a malicious client (i.e. an=20 attacker) gets to be promoted to peer he can invite other malicious=20 clients controlled by him to be peers as well. Even more, if we=20 consider that the malicious peer is the one which assigns the Peer-ID=20 (i.e. the position in the DHT) of the new promoted client it would be=20 easier that an attacker can allocate several peers in the desired=20 positions to perform an attack. What do you think? All the best, Rub=E9n. Enrico Marocco escribi=F3: > Probably a bit out of scope for this thread, I'd like to note that ther= e > are other ways of discouraging peers from trying to get arbitrary > positions in the overlay. A notable example is Skype's approach, where > ordinary nodes are promoted to super nodes only once in a while by some > obscure element higher in the hierarchy. A similar but much less > notable approach is what we propose in > draft-marocco-p2psip-xpp-pcan, where a client becomes peer only when > invited by a peer already in the overlay, and its location (or peerID o= r > whatever) is assigned by the inviting peer . > > We would really appreciate comments about this as well. > > Enrico > > Marcus Leech wrote: > =20 >> In a recent thread, Ekr writes: >> >> =20 >>> Note that this can't be fixed purely by rate limiting at some central >>> authority (though puzzles can help) because the computation is >>> performed completely offline. The fix is to have the central authorit= y >>> dispense peer-ids, but then this breaks the binding between public >>> keys and identities which is one of the major attractions of HIP. >>> >>> -Ekr >>> =20 >> I guess I don't understand why a central authority helps, except to ac= t >> as a rate-limiter. >> >> If our "attacker" has access to a large pool of source addresses, and >> assuming models where "joining" the >> mesh is an anonymous operation, I can't see how you can protect >> against a barrage of requests (perhaps spread over >> longer time periods) arriving from a vast flotilla of source >> addresses, where the idea is that *one* of those requests will >> >> yield a topologically "useful" PeerID. >> >> If the notion is that *only* authenticated nodes may "join" an overlay= , >> then I can see rate-limiting based on the >> identity of the requestors, but in the anonymous case, I can't see h= ow >> you can make this work. >> >> =20 >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> =20 --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 07:49:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHgf-0001u8-UZ; Wed, 14 Nov 2007 07:49:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHge-0001pg-Rz for p2psip@lists.ietf.org; Wed, 14 Nov 2007 07:49:44 -0500 Received: from maill.telecomitalia.it ([217.169.121.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsHga-0000G5-48 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 07:49:44 -0500 Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 13:49:38 +0100 Received: from ptpxch004rm001.idc.cww.telecomitalia.it ([156.54.205.166]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 13:49:38 +0100 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch004rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 13:49:37 +0100 Message-ID: <473AEF22.8020100@telecomitalia.it> Date: Wed, 14 Nov 2007 13:50:42 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: rcuevas@it.uc3m.es Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <473AC48A.3090503@telecomitalia.it> <473ADCF9.2030203@it.uc3m.es> In-Reply-To: <473ADCF9.2030203@it.uc3m.es> X-OriginalArrivalTime: 14 Nov 2007 12:49:37.0425 (UTC) FILETIME=[D086A010:01C826BC] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1561572286==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1561572286== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090402010003080708070507" This is a cryptographically signed message in MIME format. --------------ms090402010003080708070507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rub=E9n Cuevas Rum=EDn wrote: > In the scheme you proposed I find that if a malicious client (i.e. an > attacker) gets to be promoted to peer he can invite other malicious > clients controlled by him to be peers as well. Which is still better than letting any malicious peer happily join the overlay. The problem here is identifying malicious nodes before and/or after they join the overlay: how they join, i.e. actively or passively, doesn't really matter. > Even more, if we > consider that the malicious peer is the one which assigns the Peer-ID > (i.e. the position in the DHT) of the new promoted client it would be > easier that an attacker can allocate several peers in the desired > positions to perform an attack. Well, this is avoided allowing the inviting peer to assign entering nodes only IDs it is authoritative for; this way, any new peer becomes authoritative on a sub-interval of its parent's hash space and cannot make more damage than its parent could before its entrance. --=20 Ciao, Enrico --------------ms090402010003080708070507 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcxMTE0MTI1MDQyWjAjBgkqhkiG9w0BCQQxFgQU4D+PKMeE /M/yLCHxgkHD1xCTGJkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBABLm3mtWk24sG6W3Usw9IxI0HP/VSoO+X2MhR75OJPNxcIMQR04i3FvX yI153ED+1OoF5elHjnVyWoyjqkUj5C+BdMhrHnDs28PtYjWiOyStiPWNM158wWc6X5XQiFW6 B6dn8cOfe0IOyHo+QxsPEiJQYMbAM/hjWFFwBjAQpXXDbbR/sU0N92lKpVUMmRA2gsNgL6qe zLw0UHyq6qz4qazJsYXzJqbr/6AwxWukD2CUKVskDj0VsQbeFniwDkvF4vYCDqdLt/vk6d6i 9te63/xJARn+cED6L3tOIG465juTDwarUOljM4BHjFge5jC0tmv4n5l4meAwYInKDUQnCw0A AAAAAAA= --------------ms090402010003080708070507-- --===============1561572286== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1561572286==-- From p2psip-bounces@ietf.org Wed Nov 14 08:04:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHuu-0008Kb-3s; Wed, 14 Nov 2007 08:04:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHus-0008Jn-Ow for p2psip@lists.ietf.org; Wed, 14 Nov 2007 08:04:26 -0500 Received: from mailf.telecomitalia.it ([156.54.233.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsHun-0000qJ-W4 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 08:04:26 -0500 Received: from ptpxch010ba020.idc.cww.telecomitalia.it ([156.54.240.53]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 14:04:20 +0100 Received: from ptpxch006ba020.idc.cww.telecomitalia.it ([156.54.240.45]) by ptpxch010ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 14:04:20 +0100 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 14:04:18 +0100 Message-ID: <473AF294.6020207@telecomitalia.it> Date: Wed, 14 Nov 2007 14:05:24 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: rcuevas@it.uc3m.es Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <20071113144604.8CF0733C59@delta.rtfm.com> <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> <473ADC5C.4070101@it.uc3m.es> In-Reply-To: <473ADC5C.4070101@it.uc3m.es> X-OriginalArrivalTime: 14 Nov 2007 13:04:19.0367 (UTC) FILETIME=[DE344B70:01C826BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0730606414==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0730606414== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070804040702090805020309" This is a cryptographically signed message in MIME format. --------------ms070804040702090805020309 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rub=E9n Cuevas Rum=EDn wrote: > What I consider the best option for a proof-of-work is to solicit the > user to introduce a CAPTCHA before getting the Peer-ID. The advantages = are: > - Require the human intervention, and then the attack cannot be > automated. Let me be the first one arguing that CAPTCHAs may be automatically solved without the (conscious) human intervention: http://blog.trendmicro.com/captcha-wish-your-girlfriend-was-hot-like-me/ --=20 Ciao, Enrico --------------ms070804040702090805020309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcxMTE0MTMwNTI0WjAjBgkqhkiG9w0BCQQxFgQU1nu+QOy6 2TKXus/xJcGJ/E4YK2kwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAGCAwJ07PjVp63r08eV4F3rXv27x69rkKMAz04zlpgIgltZLF3CTln+o B5ijR7gg+WuVr5yed42sVwXP7jseclWtqErx8S/OklMb0M8EXrcPaeygS3uoWBza+Krz/Onz KsrxveZ/r527+tGgDSH5vUopqwCrijzXL2vgjLbF4xVoNL2OJO0XXz9a7B0mZhHXaSRo+JWv zliggo9jOBAS9UYuVqahs4WTL8qL+6BTviZ5d5ObY8Vuc+rTUKfMre/n7K0uVhLdFccgPtHG lsCIcMd0wkkfTXPAQY9UmvKnWBg9haHKqNiqWog8OiyOA6ZY6PI+te/H5SfwemsO4l+cqjcA AAAAAAA= --------------ms070804040702090805020309-- --===============0730606414== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0730606414==-- From p2psip-bounces@ietf.org Wed Nov 14 08:29:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIIs-0008EH-J6; Wed, 14 Nov 2007 08:29:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIIq-0008Bp-Cg for p2psip@ietf.org; Wed, 14 Nov 2007 08:29:12 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsIIp-0002eO-QJ for p2psip@ietf.org; Wed, 14 Nov 2007 08:29:12 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IsIIm-0006Zq-Gb; Wed, 14 Nov 2007 14:29:10 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IsIIk-0005JC-La; Wed, 14 Nov 2007 14:29:08 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IsIIk-00047T-Bi; Wed, 14 Nov 2007 14:29:06 +0100 Received: from [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4] (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B425F2FC00E; Wed, 14 Nov 2007 14:29:03 +0100 (CET) Message-ID: <473AF819.70300@tm.uka.de> Date: Wed, 14 Nov 2007 14:28:57 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: lichun li Subject: Re: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) References: <47349F0A.5090201@tm.uka.de> <7d6b50690711131840g7a14db16wb4b923a7126ae21a@mail.gmail.com> In-Reply-To: <7d6b50690711131840g7a14db16wb4b923a7126ae21a@mail.gmail.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Yes, in P2PNS several P2PNames could be mapped to the same nodeID. In case you want to connect several SIP UAs to a single peer, this can be done in two ways: 1.) There is a single P2PSIP proxy at the peer that forwards invites to the different UAs. In this case the "Client Protocol" is unmodified SIP. 2.) The UAs register their P2PNames with explicit (UA) IP addresses at the P2PNS layer. In this case the "Client Protocol" is XML-RPC based (register/resolve calls). The first approach is easier to secure, but limited to P2SIP. The second approach is more general and could e.g. also be used for distributed DNS. Regards, Ingmar lichun li wrote: > I am a little confused about "5.2.1 Two-stage Name Resolution". > I guess the two stages are: 1. resolving P2PName to nodeID in DHT; 2. > resolving P2PName to transport address at the node with the nodeID. Is > that right? > According to concept draft, a peer might be coupled with two or more SIP > entities. So different P2PNames might be mapping to the same nodeID? > > On 11/10/07, Ingmar Baumgart wrote: >> Dear working group, >> >> I've submitted a draft for a Peer-to-Peer Name Service (P2PNS) which can >> be used to resolve AoRs to Contact URIs without using DNS. >> >> The main contribution is on two aspects: One is reusability of the name >> service for things like distributed DNS or HIP. The other is security in >> a completely decentralized environment (without login severs). >> >> Until it is on the official servers, you can get it from here: >> >> http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.txt >> http://doc.tm.uka.de/2007/draft-baumgart-p2psip-p2pns-00.html >> >> Some additional information about the implementation can be found in >> this P2P2007 demo abstract: >> >> http://doc.tm.uka.de/2007/OverSimDemo_2007.pdf >> >> Regards, >> Ingmar >> >> -- >> Dipl.-Inform. Ingmar Baumgart >> Institut für Telematik, Universität Karlsruhe (TH) >> Zirkel 2, 76128 Karlsruhe, Germany >> Phone: +49 721 608 8281, Fax: +49 721 608 6789 >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 09:04:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIr0-00005m-US; Wed, 14 Nov 2007 09:04:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsIqy-0008Vx-Sk for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:04:28 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsIqv-0004iL-3a for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:04:28 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRI004MX1RC5R@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Wed, 14 Nov 2007 06:04:24 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRI00NJL1R90H@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Wed, 14 Nov 2007 06:04:24 -0800 (PST) Date: Wed, 14 Nov 2007 08:03:23 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities To: p2psip@lists.ietf.org Message-id: <07cd01c826c7$1f27d270$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <20071113144604.8CF0733C59@delta.rtfm.com> <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> <473ADC5C.4070101@it.uc3m.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Ruben, Ignoring Enrico's point about solving CAPTCHAs without human interven= tion... I (guess I) understand why web servers use CAPTCHAs, because the inte= ntion=20 is that they are accepting input from humans, so "proving" that you a= re a=20 human makes sense. Is it your intention that P2PSIP would not be used for embedded syste= ms=20 (with no human to intervene)? Thanks, Spencer ----- Original Message -----=20 =46rom: "Rub=E9n Cuevas Rum=EDn" What I consider the best option for a proof-of-work is to solicit the user to introduce a CAPTCHA before getting the Peer-ID. The advantage= s are: - Require the human intervention, and then the attack cannot be automated.=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 09:17:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJ3f-0008E3-IG; Wed, 14 Nov 2007 09:17:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJ3d-00089y-FX for p2psip@ietf.org; Wed, 14 Nov 2007 09:17:33 -0500 Received: from mxoutps1.us.army.mil ([143.69.250.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJ3X-0005sn-B5 for p2psip@ietf.org; Wed, 14 Nov 2007 09:17:33 -0500 DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; b=Z7rwIZz/dFIVm6ta603uIWJceoOOh1yi4p25SzKczK8cmRcn4vxFUhbFcKU6IeWW0pT9fikL2zTq0m7McZmJgg==; Received: from mail5.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.36.65]) by mxoutps1.us.army.mil with ESMTP; 14 Nov 2007 14:17:24 +0000 From: "Roy, Radhika R Dr CTR USA USAMC" X-AKO: 81131155:10.224.36.65:14 Nov 2007 14:17:24 +0000:$Webmail:None X-IronPort-AV: i="4.21,417,1188777600"; d="scan'208"; a="81131155:sNHT3136437522" Received: from [10.240.32.176] (Forwarded-For: 134.80.13.193, [10.240.32.176]) by mail5.int.ps1.us.army.mil (mshttpd); Wed, 14 Nov 2007 09:17:21 -0500 To: Ingmar Baumgart Message-ID: Date: Wed, 14 Nov 2007 09:17:21 -0500 X-Mailer: Sun Java(tm) System Messenger Express 6.2-9.04 (built Jun 11 2007) MIME-Version: 1.0 Content-Language: en Subject: Re: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) X-Accept-Language: en Priority: normal In-Reply-To: <473AF819.70300@tm.uka.de> References: <47349F0A.5090201@tm.uka.de> <7d6b50690711131840g7a14db16wb4b923a7126ae21a@mail.gmail.com> <473AF819.70300@tm.uka.de> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Inline [RRR] ----- Original Message ----- From: Ingmar Baumgart Date: Wednesday, November 14, 2007 8:29 Subject: Re: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) To: lichun li Cc: p2psip@ietf.org > Yes, in P2PNS several P2PNames could be mapped to the same nodeID. > > In case you want to connect several SIP UAs to a single peer, this can > be done in two ways: > > 1.) There is a single P2PSIP proxy at the peer that forwards > invites to > the different UAs. In this case the "Client Protocol" is > unmodified SIP. > > 2.) The UAs register their P2PNames with explicit (UA) IP > addresses at > the P2PNS layer. In this case the "Client Protocol" is XML-RPC based > (register/resolve calls). [RRR] Will it be a subset of the P2PSIP protocol? > > The first approach is easier to secure, but limited to P2SIP. The > secondapproach is more general and could e.g. also be used for > distributed DNS. > > Regards, > Ingmar > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 09:26:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJCG-0002HM-LR; Wed, 14 Nov 2007 09:26:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJCF-0002FX-R8 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:26:27 -0500 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJCD-0006on-5k for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:26:27 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id 8DCF02141C2; Wed, 14 Nov 2007 15:26:23 +0100 (CET) Message-ID: <473B0594.6080205@it.uc3m.es> Date: Wed, 14 Nov 2007 15:26:28 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <20071113144604.8CF0733C59@delta.rtfm.com><354B2F73-D7D2-408C-9513-E523863AB2F4@cs .columbia.edu><473ADC5C.4070101@it.uc3m.es> <07cd01c826c7$1f27d270$ad600240@china.huawei.com> In-Reply-To: <07cd01c826c7$1f27d270$ad600240@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-14.6549 TC:1F TRN:41 TV:5.0.1023(15546.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Spencer Dawkins escribi=F3: > Hi, Ruben, > > Ignoring Enrico's point about solving CAPTCHAs without human=20 > intervention... > > I (guess I) understand why web servers use CAPTCHAs, because the=20 > intention is that they are accepting input from humans, so "proving"=20 > that you are a human makes sense. > > Is it your intention that P2PSIP would not be used for embedded=20 > systems (with no human to intervene)? > Hi Spencer, To the best of my knowledge all the SIP-compliant devices must be=20 configured by human intervention (e.g, the URI, the SIP-Registar...).=20 Then, adding the CAPTCHAs does not introduce any new barrier. Maybe I am wrong. Which kind of embedded systems are you thinking about? Thanks, Rub=E9n. > Thanks, > > Spencer > > ----- Original Message ----- From: "Rub=E9n Cuevas Rum=EDn"=20 > > > What I consider the best option for a proof-of-work is to solicit the > user to introduce a CAPTCHA before getting the Peer-ID. The advantages=20 > are: > - Require the human intervention, and then the attack cannot be > automated. > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 09:32:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJIA-0003oQ-Ox; Wed, 14 Nov 2007 09:32:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJI8-0003mY-Nt for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:32:32 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJI6-0007UI-6W for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:32:32 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lAEEWLLY019396; Wed, 14 Nov 2007 08:32:21 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lAEEWKj06126; Wed, 14 Nov 2007 08:32:21 -0600 (CST) Message-ID: <473B06F4.9060904@alcatel-lucent.com> Date: Wed, 14 Nov 2007 08:32:20 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rcuevas@it.uc3m.es Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <20071113144604.8CF0733C59@delta.rtfm.com> <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> <473ADC5C.4070101@it.uc3m.es> In-Reply-To: <473ADC5C.4070101@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail4.lucent.com id lAEEWLLY019396 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Rub=E9n Cuevas Rum=EDn wrote: > What I consider the best option for a proof-of-work is to solicit the=20 > user to introduce a CAPTCHA before getting the Peer-ID. The advantages = are: > - Require the human intervention, and then the attack cannot be=20 > automated. CAPTCHAs have been proven to be broken with results hovering in the >=3D 80% accuracy range. See [1,2]. [1] Luis von Ahn, Manuel Blum, and John Langford, "Telling Computers and Humans Apart," Comm. of ACM, 47(2), pp. 57-60, 2004. [2] Luis von Ahn, Manuel Blum, Nicholas Hopper, and John Langford, "CAPTCHA: Using Hard AI Problems for Security," Proceedings of 2003 Eurocrypt. Both of these papers are available online through a search on Citeseer or Google. Regards, - vijay --=20 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 09:38:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJOA-0007rG-KX; Wed, 14 Nov 2007 09:38:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJO9-0007p2-1t for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:38:45 -0500 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJO5-00086I-NM for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:38:45 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id E3C271D6414; Wed, 14 Nov 2007 15:38:40 +0100 (CET) Message-ID: <473B0876.5050701@it.uc3m.es> Date: Wed, 14 Nov 2007 15:38:46 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Enrico Marocco Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <473AC48A.3090503@telecomitalia.it> <473ADCF9.2030203@it.uc3m.es> <473AEF22.8020100@telecomitalia.it> In-Reply-To: <473AEF22.8020100@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.1048 TC:1F TRN:42 TV:5.0.1023(15546.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Enrico Marocco escribi=F3: > Well, this is avoided allowing the inviting peer to assign entering > nodes only IDs it is authoritative for; this way, any new peer becomes > authoritative on a sub-interval of its parent's hash space and cannot > make more damage than its parent could before its entrance. > > =20 In this case you need to be able to demonstrate that your Peer-ID has=20 been assigned by the /authoritative Peer/ of the interval which is not=20 trivial since we should consider the implicit dynamism on the p2p=20 systems. Then, if the authoritative Peer on the interval (the one who=20 assigned my Peer-ID) leaves the DHT it becomes difficult to demonstrate=20 that my Peer-ID is a valid one. In additon, when a Peer leaves the=20 network and have assigned an interval, we should provide some policy to=20 reassign the authority (the /authoritative Peer/) on the intervals. I think it would be easier the following: When a peer firstly join the=20 network,it ask for a Peer-ID to a central entity which returns a=20 certificate including the Peer-ID. This Peer-ID will be a long term id,=20 then in following join procedures the peer does not need to contact to=20 the central entity. In addition, in order to obtain the Peer-ID the user should solve a=20 captcha (we are discussing about this in parallel). This only prevents=20 the automatization of obtaining a high number of Peer-IDs. In addition, the central entity can deploy some type of Access Control=20 Policy. For instance, it can check if multiples Peer-IDs are being=20 solicited from the same IP or from the same IP prefix and then detect=20 attacks (e.g if the normal solicitation rate is 100 Peer-IDs per hour=20 and at some point the central entity receives 1000 Peer-IDs=20 solicitations in an hour from a given IP prefix it can be intended as an=20 attack). Thanks, Rub=E9n. --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 09:45:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJUb-0000UG-4b; Wed, 14 Nov 2007 09:45:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJUa-0000Sg-6M for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:45:24 -0500 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJUW-0000JG-Ry for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:45:24 -0500 Received: by py-out-1112.google.com with SMTP id u77so2770812pyb for ; Wed, 14 Nov 2007 06:45:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=XMeipaTAFba3AGxzi6wPpEGlFqSf02eIQKaacZy1UvE=; b=NWMuNDLWZpsT/KZG25p6SlGd3ugfIKL6vSRHw9WgW0zqo9wo/tsFAumu/YN0i/dJY9wQOUCpnvgRvcaW9IRtwwzuyr45Kr9EKNN+hGyx/riIbAaafCUkA4mKAjjnWcZYartP+fWFWmVQsP2nYHCZKbSAeAJqMYq33ytUwjsYvLw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pSVZlSTkdcTOIX/psADRM5xGm2Nvv2L3RmCJrnqdTWB+B62HFaM6ae6BJqDJQIzZK+JYb669bWwnTh5vDJJ8HQqLoRK5XUXn/C2wU6zGW1MxHfb/SxQ53EFHywvcQO2iSYJJFSSZsArsDk3NOAUHgGupKJHaxWFT0bQbGwNQ5Hs= Received: by 10.65.138.4 with SMTP id q4mr9511772qbn.1195051518282; Wed, 14 Nov 2007 06:45:18 -0800 (PST) Received: by 10.65.180.16 with HTTP; Wed, 14 Nov 2007 06:45:18 -0800 (PST) Message-ID: <4d4304a00711140645x48c56414g5393ce9a0c668bcf@mail.gmail.com> Date: Wed, 14 Nov 2007 09:45:18 -0500 From: "David A. Bryan" To: rcuevas@it.uc3m.es Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities In-Reply-To: <473B0876.5050701@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <473AC48A.3090503@telecomitalia.it> <473ADCF9.2030203@it.uc3m.es> <473AEF22.8020100@telecomitalia.it> <473B0876.5050701@it.uc3m.es> X-Google-Sender-Auth: 85e745c487e769bc X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The technique described below, (with a central CA issuing IDs, but minus the captcha), is (more or less) what most of the currently proposed protocols have been advocating for a couple of years now. What does the captcha gain? If you are going to rate limit at the server anyway. I can see the captcha being one possible idea, but others (micropayment, proof of identity with an uncharged credit card etc.) have been proposed as well, and I personally think that type of thing is a provisioning/admin decision that is out of scope of the WG. BTW I don't really like the captcha idea for a number of reasons. A simple IP phone may or may not have a screen, and if it does, it might be alphanumeric, so not sure this could be universally deployed in any case. David (as individual) On Nov 14, 2007 9:38 AM, Rub=E9n Cuevas Rum=EDn wrote: > Enrico Marocco escribi=F3: > > Well, this is avoided allowing the inviting peer to assign entering > > nodes only IDs it is authoritative for; this way, any new peer becomes > > authoritative on a sub-interval of its parent's hash space and cannot > > make more damage than its parent could before its entrance. > > > > > In this case you need to be able to demonstrate that your Peer-ID has > been assigned by the /authoritative Peer/ of the interval which is not > trivial since we should consider the implicit dynamism on the p2p > systems. Then, if the authoritative Peer on the interval (the one who > assigned my Peer-ID) leaves the DHT it becomes difficult to demonstrate > that my Peer-ID is a valid one. In additon, when a Peer leaves the > network and have assigned an interval, we should provide some policy to > reassign the authority (the /authoritative Peer/) on the intervals. > > I think it would be easier the following: When a peer firstly join the > network,it ask for a Peer-ID to a central entity which returns a > certificate including the Peer-ID. This Peer-ID will be a long term id, > then in following join procedures the peer does not need to contact to > the central entity. > In addition, in order to obtain the Peer-ID the user should solve a > captcha (we are discussing about this in parallel). This only prevents > the automatization of obtaining a high number of Peer-IDs. > In addition, the central entity can deploy some type of Access Control > Policy. For instance, it can check if multiples Peer-IDs are being > solicited from the same IP or from the same IP prefix and then detect > attacks (e.g if the normal solicitation rate is 100 Peer-IDs per hour > and at some point the central entity receives 1000 Peer-IDs > solicitations in an hour from a given IP prefix it can be intended as an > attack). > > Thanks, > Rub=E9n. > > > -- > Rub=E9n Cuevas Rum=EDn > Universidad Carlos III de Madrid > Departamento Ingenier=EDa Telem=E1tica > Avenida de la Universidad, 30 > 28911-Legan=E9s (Madrid). Espa=F1a > email: rcuevas@it.uc3m.es > Tlf: +34 91-6248859 > Fax: +34 91-6248749 > Web: http://www.it.uc3m.es/~rcuevas > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 09:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJev-0004FW-Kp; Wed, 14 Nov 2007 09:56:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJeu-0004F6-Db for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:56:04 -0500 Received: from maild.telecomitalia.it ([156.54.233.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJep-0001QR-K0 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 09:56:04 -0500 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by maild.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:55:53 +0100 Received: from ptpxch005ba020.idc.cww.telecomitalia.it ([156.54.240.44]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:55:53 +0100 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch005ba020.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:55:52 +0100 Message-ID: <473B0CB7.9030609@telecomitalia.it> Date: Wed, 14 Nov 2007 15:56:55 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: rcuevas@it.uc3m.es Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <473AC48A.3090503@telecomitalia.it> <473ADCF9.2030203@it.uc3m.es> <473AEF22.8020100@telecomitalia.it> <473B0876.5050701@it.uc3m.es> In-Reply-To: <473B0876.5050701@it.uc3m.es> X-OriginalArrivalTime: 14 Nov 2007 14:55:52.0812 (UTC) FILETIME=[73CEF2C0:01C826CE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1198499183==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1198499183== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000201060605040307090506" This is a cryptographically signed message in MIME format. --------------ms000201060605040307090506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Rub=E9n Cuevas Rum=EDn wrote: > Enrico Marocco escribi=F3: >> Well, this is avoided allowing the inviting peer to assign entering >> nodes only IDs it is authoritative for; this way, any new peer becomes= >> authoritative on a sub-interval of its parent's hash space and cannot >> make more damage than its parent could before its entrance. >> =20 > In this case you need to be able to demonstrate that your Peer-ID has > been assigned by the /authoritative Peer/ of the interval which is not > trivial since we should consider the implicit dynamism on the p2p > systems. Then, if the authoritative Peer on the interval (the one who > assigned my Peer-ID) leaves the DHT it becomes difficult to demonstrate= > that my Peer-ID is a valid one. In additon, when a Peer leaves the > network and have assigned an interval, we should provide some policy to= > reassign the authority (the /authoritative Peer/) on the intervals. The point is not the Peer-ID itself, it is telling to all the peers involved in the join procedure -- e.g. successors and predecessors in Chord, neighbors in CAN -- that the new node has been invited by a trusted peer. This is something which may easily be done by the inviting peer (which, btw, in most of DHT algorithms would have to notify other peers about the entrance anyway). --=20 Ciao, Enrico --------------ms000201060605040307090506 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcxMTE0MTQ1NjU1WjAjBgkqhkiG9w0BCQQxFgQUqSXV5DJo BH1PeSBoqJc98s9YkJIwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAGWZvNZVFzu36pQ07PT9bM0sVHcGH+6DKVny+B+7cMU5A/9oNpE58dc8 hQuIjl5Dmm2izZxYoU/9gdIof5Vi8g4tzyvxOGtsMks+v3eHpVbuxNRCSq+gGUuqOauNUgxa w3MLUKSgmW/j8J+QsJA5262q5KOKxqOjhSh+Jkk+vVb0bMJdgwP9leNQZCyHlLcAvks6ka54 +TAyUyFAClP43QcGGMVl2XB1S/oE5Wwahh1y6NxckVpM4WLwuWKHUxU4ByAuyzM5Lm3lT0Pb XxhYvlU/QdHRgoMg4uh0PApJ7WjlPWiZX8mqubZl30eeWqEJqw7J8TpLsIRX7n55aO0hDZ0A AAAAAAA= --------------ms000201060605040307090506-- --===============1198499183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1198499183==-- From p2psip-bounces@ietf.org Wed Nov 14 10:08:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJqW-0007iE-Nc; Wed, 14 Nov 2007 10:08:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJqV-0007hk-Rl for p2psip@ietf.org; Wed, 14 Nov 2007 10:08:03 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJqS-0002lf-D7 for p2psip@ietf.org; Wed, 14 Nov 2007 10:08:03 -0500 Received: by rv-out-0910.google.com with SMTP id l15so170255rvb for ; Wed, 14 Nov 2007 07:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=XD4lBnDYpt4joaNqahAEm5sx6Gs0hO3pTqYgEsXAtko=; b=PROeMxIjElnVYVVk9FG1tf6ZXQKxEZvOpyOi33aw2tnYXT6dlOrbMVdnCbqVhh7IVOPouZ4lcFzh7uyI5RboICsb8SFVFZgOIUbgQrRg+KhIDU2ikAjn1KBPj3R6zwQ39fzn7oZ0a1E+ycgioyGnfHDlaG6riJX3KYBQqpWUboQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AMFEByvA95RqupPtrPoejhhwVATDoJ8lH5tvfB8s6as1i/GEHSQjdi8fdpsYtybK/6JQ9nsvuksW8XTfGrVi9Zz5UJWfC3gy4EMyvV9DGmIFFn9S2lyVQHChapoCsg7S4eDpvf68HZbuJ3AITw0ycFegNhhYorYNMSGRmcMEy4M= Received: by 10.141.41.12 with SMTP id t12mr3493260rvj.1195052879054; Wed, 14 Nov 2007 07:07:59 -0800 (PST) Received: by 10.141.40.3 with HTTP; Wed, 14 Nov 2007 07:07:59 -0800 (PST) Message-ID: <7b683f3f0711140707p627a6d2bwe31bc15e8106c12b@mail.gmail.com> Date: Wed, 14 Nov 2007 10:07:59 -0500 From: "Eunsoo Shim" To: "Zheng Hewen" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <000601c8266d$5bbb4730$5105a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <618e24240711131255x5617bc56p7622f981576130f8@mail.gmail.com> <000601c8266d$5bbb4730$5105a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Henry Sinnreich , Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org My comments are inline. On Nov 13, 2007 10:20 PM, Zheng Hewen wrote: > Hi, all, > > The time in Vancouver is limited and very precious. > After those discussion about P2PSIP client in the latest mail l= ist, a survey about P2PSIP client charcater/behavior > among active members in this work group will be very helpful for the furt= her discussion in Vancouver. > As Victor Pascual =A8=A2vila said, there are mainly three types= of nodes: > (1).Peers (nodes to perform the overlay and offer storage and r= outing capabilities and they are coupled WITH one or > more SIP entities or WITHOUT any SIP entity, overlay-routing nodes), > (2).Clients (nodes to contribute its storage capacity to its as= sociated peer and they are coupled with SIP UA, > non-overlay-routing nodes); Clients may be coupled with one or more SIP entities or none. > (3).SIP [RFC3161] (UA with no other capabilities). > When we talk about the overlay, this kind of node is irrelevant. The overlay (protocol) nodes and SIP entities are independent of each other= . Please don't mix them. > Any comment? > > We suggest that the revised Concept document would clarify the = P2PSIP client character if an agreement about P2PSIP > client character is reached in the mail list. > Thanks. Eunsoo > -----Original Message----- > From: Victor Pascual =A8=A2vila [mailto:victor.pascual.avila@gmail.com] > Sent: 2007=C4=EA11=D4=C214=C8=D5 4:56 > To: Henry Sinnreich > Cc: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu; P2PSIP= Mailing List > Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols= ) > > On 13/11/2007, Henry Sinnreich wrote: > > >From this list I understand there is less a problem with the > > >existence > > of clients, but rather if there should be a separate client protocol. > > > > Also, some folks mentioned that the client protocol should just be a > > subset of the peer protocol. > > > > Is this understanding of the discussions correct? > > This is how I understand the discussions. > > Considering Peers to offer at least routing and storage capabilities, som= e of us understand Clients to offer only storage. In > this way, as said in previous messages, we should consider three main typ= es of > node: peers (nodes to perform the overlay and offer storage and routing c= apabilities and they are coupled with one or more SIP > entities), clients (nodes to contribute its storage capacity to its assoc= iated peer and they are coupled with SIP UA) and SIP > [RFC3161] (UA with no other capabilities). > > Clients and SIP UA will reach P2PSIP overlay through peers. While Clients= will store some information, peers will store > information on behalf of SIP UA. > > Since Peers and Clients would need to exchange some kind of information, = what is a subset of information exchanged between > peers + other possible data with other periodicity, requirements for the = Client protocol can be considered to be different > from the Peer protocol. > > Thus, > Peer <---- Peer Protocol ----> Peer > Client <---- Client Protocol ----> Peer > SIP UA <---- SIP [RFC3261] ----> Peer > > As an example, I imagine Peers storing 'general' AoR information and user= preferences while Clients would store only 'their > buddies' AoR information. > > > Thank you, > Victor Pascual > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 10:08:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJrO-0000Wa-Rv; Wed, 14 Nov 2007 10:08:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJrN-0000Vo-Ct for p2psip@ietf.org; Wed, 14 Nov 2007 10:08:57 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJrI-0002rW-St for p2psip@ietf.org; Wed, 14 Nov 2007 10:08:57 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IsJrD-0000tn-85; Wed, 14 Nov 2007 16:08:49 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IsJrC-0003l7-5P; Wed, 14 Nov 2007 16:08:47 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IsJrB-0003rz-Sj; Wed, 14 Nov 2007 16:08:45 +0100 Received: from [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4] (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 084162FC00E; Wed, 14 Nov 2007 16:08:45 +0100 (CET) Message-ID: <473B0F76.8040600@tm.uka.de> Date: Wed, 14 Nov 2007 16:08:38 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: "Roy, Radhika R Dr CTR USA USAMC" Subject: Re: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) References: <47349F0A.5090201@tm.uka.de> <7d6b50690711131840g7a14db16wb4b923a7126ae21a@mail.gmail.com> <473AF819.70300@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Roy, Radhika R Dr CTR USA USAMC wrote: > ----- Original Message ----- > From: Ingmar Baumgart >> >> 2.) The UAs register their P2PNames with explicit (UA) IP >> addresses at >> the P2PNS layer. In this case the "Client Protocol" is XML-RPC based >> (register/resolve calls). > > [RRR] Will it be a subset of the P2PSIP protocol? For P2PNS I don't see a direct relationship between the Peer Protocol (overlay routing and routing table maintenance) and the Client Protocol (remote access of overlay services). In my opinion the Peer Protocol should be (or at least be based on) a generic protocol for key-based routing and data storage (like the P2PP proposal). Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 10:10:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJsl-0003Ox-7n; Wed, 14 Nov 2007 10:10:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJsj-0003MG-Fz for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:10:21 -0500 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJsg-000313-JC for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:10:21 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id 8C3FB1EA0A1; Wed, 14 Nov 2007 16:06:24 +0100 (CET) Message-ID: <473B0EF5.2060807@it.uc3m.es> Date: Wed, 14 Nov 2007 16:06:29 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <20071113144604.8CF0733C59@delta.rtfm.com> <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> In-Reply-To: <473B06F4.9060904@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-18.8072 TC:1F TRN:32 TV:5.0.1023(15546.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Vijay, I have read [1] and they say that one type of CAPTCHA (reading distorted=20 images) has been broken, but not all types of CAPTCHAs. All the best, Rub=E9n. Vijay K. Gurbani escribi=F3: > Rub=E9n Cuevas Rum=EDn wrote: >> What I consider the best option for a proof-of-work is to solicit the=20 >> user to introduce a CAPTCHA before getting the Peer-ID. The=20 >> advantages are: >> - Require the human intervention, and then the attack cannot be=20 >> automated. > > CAPTCHAs have been proven to be broken with results hovering in > the >=3D 80% accuracy range. See [1,2]. > > [1] Luis von Ahn, Manuel Blum, and John Langford, "Telling Computers > and Humans Apart," Comm. of ACM, 47(2), pp. 57-60, 2004. > [2] Luis von Ahn, Manuel Blum, Nicholas Hopper, and John Langford, > "CAPTCHA: Using Hard AI Problems for Security," Proceedings of > 2003 Eurocrypt. > > Both of these papers are available online through a search on Citeseer > or Google. > > Regards, > > - vijay --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 10:22:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsK4X-0000hP-NH; Wed, 14 Nov 2007 10:22:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsK4W-0000en-UH for p2psip@ietf.org; Wed, 14 Nov 2007 10:22:32 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsK4T-0004Sb-UZ for p2psip@ietf.org; Wed, 14 Nov 2007 10:22:32 -0500 Received: by rv-out-0910.google.com with SMTP id l15so173986rvb for ; Wed, 14 Nov 2007 07:22:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=AHypEkuU/mBcj6Jvts13e1IPHPwiwWsCJSIexHhLRyI=; b=HTZul5vsvGky3uAyFA9IISNvYgii1lwhnhKkIc56PMuPnwpkikvVuDv1/N7tAgUo2qhrC4JIrTZZb+7Y4xEEfRZHlEiQVEhtyKBdjZVwPMSvl27sW0PJ/ylczZDtJQsD4KoGKsxMxRBnMdXtT0wtr2wBCpA2i9KSXIF79COD2sg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gYKkiK8kTEyxI9tOTJceVuYrGn1n46YpsVtlHPQyRjqjkhUoWrhHgB3NFkaruqdJetPy6yK0z1KSPZuupDeDUxkc9JS0yQ+1gVf8nGl/3bR0iGgVPbk/O+U6YTxAttTYCRb0kiWF9hwvHVdFItingaxJhYXLU0XdRoBudVx/Kyw= Received: by 10.141.5.3 with SMTP id h3mr664528rvi.1195053748962; Wed, 14 Nov 2007 07:22:28 -0800 (PST) Received: by 10.141.40.3 with HTTP; Wed, 14 Nov 2007 07:22:28 -0800 (PST) Message-ID: <7b683f3f0711140722n2329f686h9795183962682bac@mail.gmail.com> Date: Wed, 14 Nov 2007 10:22:28 -0500 From: "Eunsoo Shim" To: "Yao Wang" Subject: Re: client protocol ([P2PSIP] Proposal for progress on protocols) In-Reply-To: <004201c8266e$80ee0640$9a00a8c0@mlifewangyao> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <24CCCC428EFEA2469BF046DB3C7A8D223AE2A6@namail5.corp.adobe.com> <004201c8266e$80ee0640$9a00a8c0@mlifewangyao> X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: P2PSIP Mailing List , Henry Sinnreich , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Not at all. The overlay needs to provide just distributed database functionality (== distributed storage and search/lookup functionality) and at most some kind of generic transport/routing functionality. These functionalities can be well summarized as PUT, GET, and SEND functions. Any information about SIP related services such as mapping of SIP URI to a location(IP address) or nodes providing certain application functions/services like conferencing server can be stored and looked up using the Peer (and Client) Protocol. You don't need SIP at all here. That is the idea accepted by the group widely. Now all the proposals about Peer Protocol do not use extensions/variations of SIP. If we all understand that Client Protocol provides only a subset of Peer Protocol's functionality and Peer Protocol can be and better be implemented independently of SIP, why would we need to have SIP for Client Protocol? It does not make sense to me. Thanks. Eunsoo On Nov 13, 2007 10:28 PM, Yao Wang wrote: > Yes, you are right. > > Currently, the main difference in the debate comes from how to build the client protocol, whether it could be based on SIP, whether it could be a syntax subset of Peer Protocol, or whether it is a separate protocol different from both SIP and Peer Protocol but its function is subset of the functions of Peer Protocol. > > Here are some of my understandings, > 1. What services client can get using Client Protocol? > In my opinion, there are two kinds of services. > Firstly, from the charter of this WG, this WG "is chartered to develop protocols and mechanisms for the use of the Session Initiation Protocol (SIP)". It is clearly that SIP service (including locating target user, forwarding SIP messages) is a basic service that P2PSIP Overlay MUST provide. Client Protocol MUST enable client to access this services. > Secondly, services other than SIP. As mentioned in concept draft, some individual peers may provide services in addition to storage and routing, for example STUN services, to the overlay. However, because clients do not join P2PSIP Overlay, they can not discover these services directly. Therefore, client protocol MUST provide a mean for client to know what services are available in the P2PSIP Overlay and the comprehensive parameters for access these services. After getting these parameters, the client can use other protocols, for example STUN, to access the service, which should be out of the scope of client protocol. > To meet the first kind of requirements, SIP is mandatory. When it comes to the second kind of requirements, both SIP and other protocol (e.g. a subset of peer protocol) can work. > If the subset of peer protocol is adopted as client protocol (supposing the peer protocol is not SIP-based), the client _has_ _to_ run two protocol stacks at the same time, which obviously consumes more resources of client than only running SIP stack. Given the assumption that clients are resource-limited devices, running one more protocol stack may cause the degradation of its performances. > Thus, why not use SIP and SIP extensions to satisfy both requirements? why not kill two birds with one stone? Currently, many mobile devices have been equipped with SIP; the reuse of SIP in client protocol not only reduces the resource needed on client devices but also reduces the implementation complexity of client protocol. > > 2. What services peer can get using Client Protocol? > It seems that people in this list accept that the client should contribute its storage capacity to peers. In my opinion, the client can provide more service than that. Here is one possible example which is described in our proposed draft ("A SIP-based P2PSIP Client Protocol") > "For example, a conferences server wants to provide conference services to nodes in a P2PSIP system. Because the decoding, mixture and encoding of multiple media streams can be quite a heavy load for its computational resources, this conference server may choose not to join in the P2PSIP overlay. Thus, some extra resources, which would be used for the maintenance of P2P overlay if the server joined overlay, can be utilized for providing better conference services." > Therefore, the client protocol must be extensible for supporting any possible services. SIP is a well-developed extensible signal protocol, thus, we propose to build client protocol based on SIP. > > Any comments? > > > Sincerely yours, > > Yao Wang > Mobile Life and New Media Lab, BUPT > > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, November 14, 2007 3:42 AM > To: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu > Cc: P2PSIP Mailing List > > Subject: client protocol ([P2PSIP] Proposal for progress on protocols) > > > I think there is no consensus > > yet on the nature or even existence of clients. > > >From this list I understand there is less a problem with the existence > of clients, but rather if there should be a separate client protocol. > > Also, some folks mentioned that the client protocol should just be a > subset of the peer protocol. > > Is this understanding of the discussions correct? > > Given the preponderance of mobile devices, this alone would justify a > new version of the concepts document. > > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Tuesday, November 13, 2007 10:41 AM > To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Proposal for progress on protocols > > As a working group member, I am encouraged by the debate on the > existence and nature of the P2PSIP client, and the proposals for a > Client Protocol. > > But as a co-author of the Concepts draft, I think it is premature to > modify the discussion on Clients in the draft. It is not that I > don't want to do this, it is just that I think there is no consensus > yet on the nature or even existence of clients. > > I think we are coming up to the point where there will be a major > revision to the Concepts draft that will focus in on a specific > architecture and mechanisms, and that revision may well include a > major revision in the section on clients. But I don't think it should > be the revision for this cycle. > > - Philip > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 10:32:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKDt-0003OA-Bp; Wed, 14 Nov 2007 10:32:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKDs-0003Mu-8K for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:32:12 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKDm-0005rF-JR for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:32:12 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAEFVwL3012329; Wed, 14 Nov 2007 09:31:58 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lAEFVtj13095; Wed, 14 Nov 2007 09:31:58 -0600 (CST) Message-ID: <473B14EB.2000905@alcatel-lucent.com> Date: Wed, 14 Nov 2007 09:31:55 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "David A. Bryan" Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <473AC48A.3090503@telecomitalia.it> <473ADCF9.2030203@it.uc3m.es> <473AEF22.8020100@telecomitalia.it> <473B0876.5050701@it.uc3m.es> <4d4304a00711140645x48c56414g5393ce9a0c668bcf@mail.gmail.com> In-Reply-To: <4d4304a00711140645x48c56414g5393ce9a0c668bcf@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail3.lucent.com id lAEFVwL3012329 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David A. Bryan wrote: > BTW I don't really like the captcha idea for a number of reasons. A > simple IP phone may or may not have a screen, and if it does, it might > be alphanumeric, so not sure this could be universally deployed in any > case. In published literature and prevailing systems, there is a notion of audio CAPTCHAs [1,2]. For example, there is a Google plug-in that will speak out the visual CAPTCHA for the sight-impaired users; all they then have to do is to type the numbers they hear. In multi-media communication systems (closer to the P2PSIP domain), audio CAPTCHAs can be used by having the caller hear an announcement and repeat a sequence of digits and words before the called party is alerted. But even this has drawbacks. For one, there has been some work [3] that allows a minimally trained automaton to respond to the voice CAPTCHA with about 33% accuracy. Second, at least for SPIT prevention, audio CAPTCHAs can be mitigated by outsourcing session establishment to low-cost countries where a human army can speak out the audio CAPTCHAs. In the context of the P2PSIP discussion of providing "proof-of-work", audio CAPTCHAs may be a better alternative to traditional text/image based CAPTCHAs. That is until the automaton-based approach in [3] can be trained really well. Furthermore, if we require an audio CAPTCHA to be a pre-requisite for getting a Peer-ID, that would mean that all peers must possess fairly sophisticated capabilities for acting on the results of the audio CAPTCHA tests. [1] Jonathan Holman, Jonathan Lazar, Jinjuan Heidi Feng, and John D'Arcy, "Developing usable CAPTCHAs for blind users," Proceedings of the 9th international ACM SIGACCESS conference on Computers and accessibility Assets, pp245-246, October 2007. [2] Tsz-Yan Chan, "Using a text-to-speech synthesizer to generate a reverse Turing Test," Proceedings of the 15th IEEE International Conference on Tools with Artificial Intelligence (ICTAI=9203), pp. 226-332, November 2003. [3] "Defeating audio (voice) CAPTCHAs," http://vorm.net/captchas/ - vijay --=20 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 10:39:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKKg-0006nS-DP; Wed, 14 Nov 2007 10:39:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKKf-0006l4-AM for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:39:13 -0500 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKKc-0006gW-V2 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:39:13 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id 2DA8F1E9484; Wed, 14 Nov 2007 16:39:10 +0100 (CET) Message-ID: <473B16A3.6010404@it.uc3m.es> Date: Wed, 14 Nov 2007 16:39:15 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: "David A. Bryan" Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <473AC48A.3090503@telecomitalia.it> <473ADCF9.2030203@it.uc3m.es> <473AEF22.8020100@telecomitalia.it> <473B0876.5050701@it.uc3m.es> <4d4304a00711140645x48c56414g5393ce9a0c668bcf@mail.gmail.com> In-Reply-To: <4d4304a00711140645x48c56414g5393ce9a0c668bcf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.1029 TC:02 TRN:41 TV:5.0.1023(15546.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David A. Bryan escribi=F3: > What does the captcha gain? If you are going to rate limit at the > server anyway My point is not to establish a rate limit (this could suppose to=20 increase the entry barriers to the system) , but limit the rate to the=20 prefix from the attack is being performed.=20 > . I can see the captcha being one possible idea, but > others (micropayment, proof of identity with an uncharged credit card > etc.) have been proposed as well, and I personally think that type of > thing is a provisioning/admin decision that is out of scope of the WG. > =20 I agee that the CAPTCHA is not the unique solution and probably we can=20 find a much better one. However, in front of the two solutions you=20 presented CAPTCHAs have some advantages: It is /free/ ( vs.=20 micropayment) and it is anonymous (vs. uncharged credit card). > BTW I don't really like the captcha idea for a number of reasons. A > simple IP phone may or may not have a screen, and if it does, it might > be alphanumeric, so not sure this could be universally deployed in any > case. > =20 Well, there are several types of CAPTCHAs which can be addapted to the=20 device features. For instance, in the case of the phone we can use sound=20 based CAPTCHAs. This is something like you listen to something and you=20 have to type it, then the CA can check if you typed the correct word. Thanks, Rub=E9n. > > =20 --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 10:44:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKPm-0005rR-DT; Wed, 14 Nov 2007 10:44:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKPl-0005n0-G0 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:44:29 -0500 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKPi-0007G3-2U for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:44:29 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lAEFiMmH026180; Wed, 14 Nov 2007 09:44:22 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id lAEFiIj20671; Wed, 14 Nov 2007 09:44:18 -0600 (CST) Message-ID: <473B17D1.6030705@alcatel-lucent.com> Date: Wed, 14 Nov 2007 09:44:17 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rcuevas@it.uc3m.es Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <20071113144604.8CF0733C59@delta.rtfm.com> <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> In-Reply-To: <473B0EF5.2060807@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ihemail3.lucent.com id lAEFiMmH026180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Rub=E9n Cuevas Rum=EDn wrote: > Dear Vijay, >=20 > I have read [1] and they say that one type of CAPTCHA (reading distorte= d=20 > images) has been broken, but not all types of CAPTCHAs. Ruben: Right; see my follow-up email on audio CAPTCHAs. Regarding reading distorted images, that is the technique used most widely on the web even today. I remember reading about another type of CAPTCHA that involves a group of pictures -- three out of four pictures would be rodents and the fourth one would be a lion, say. You would be asked to pick out which image does not mesh with other ones. Such tests are relatively easy for humans to do (we can tell a lion apart from a mouse), but it is hard to provide that much context to a computer. - vijay --=20 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 10:54:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKZv-0004Oh-Bm; Wed, 14 Nov 2007 10:54:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKZt-0004N5-Ut for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:54:57 -0500 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKZr-0008Lc-BG for p2psip@lists.ietf.org; Wed, 14 Nov 2007 10:54:57 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id 407EA1FD794; Wed, 14 Nov 2007 16:54:54 +0100 (CET) Message-ID: <473B1A53.1010405@it.uc3m.es> Date: Wed, 14 Nov 2007 16:54:59 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Enrico Marocco Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities References: <473AC48A.3090503@telecomitalia.it> <473ADCF9.2030203@it.uc3m.es> <473AEF22.8020100@telecomitalia.it> <473B0876.5050701@it.uc3m.es> <473B0CB7.9030609@telecomitalia.it> In-Reply-To: <473B0CB7.9030609@telecomitalia.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-8.8327 TC:1F TRN:50 TV:5.0.1023(15546.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Enrico Marocco escribi=F3: > Rub=E9n Cuevas Rum=EDn wrote: > =20 >> Enrico Marocco escribi=F3: >> =20 >>> Well, this is avoided allowing the inviting peer to assign entering >>> nodes only IDs it is authoritative for; this way, any new peer become= s >>> authoritative on a sub-interval of its parent's hash space and cannot >>> make more damage than its parent could before its entrance. >>> =20 >>> =20 >> In this case you need to be able to demonstrate that your Peer-ID has >> been assigned by the /authoritative Peer/ of the interval which is not >> trivial since we should consider the implicit dynamism on the p2p >> systems. Then, if the authoritative Peer on the interval (the one who >> assigned my Peer-ID) leaves the DHT it becomes difficult to demonstrat= e >> that my Peer-ID is a valid one. In additon, when a Peer leaves the >> network and have assigned an interval, we should provide some policy t= o >> reassign the authority (the /authoritative Peer/) on the intervals. >> =20 > > The point is not the Peer-ID itself, it is telling to all the peers > involved in the join procedure -- e.g. successors and predecessors in > Chord, neighbors in CAN -- that the new node has been invited by a > trusted peer. This is something which may easily be done by the > inviting peer (which, btw, in most of DHT algorithms would have to > notify other peers about the entrance anyway). > > =20 I get you. This is a more philosophical discussion. Is it possible to=20 identify malicious nodes? From my point of view this is a really hard task. First of all, we=20 should consider that it is not possible to distiguish between malicious=20 nodes and misbehaving nodes (for instance, due to a software failure). If we focusin the DHTs, for instance: the Responsible Node of a record=20 (this is the one with the closest Peer-ID) decides not answering (or=20 give wrong responses) to the queries soliciting this record. You=20 should demonstrate that the malicious node is storing the record and it=20 is the only one which actually knows and can confirm this. It is really=20 hard to identify this type of attack. Even more, this node can decide to=20 answer correctly some times making harder to be detected. For the best of my knowledge, the identification of malicious nodes in=20 DHT networks is still an open issue. What do you think? Cheers. Rub=E9n. --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 11:58:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLZb-0002lo-C7; Wed, 14 Nov 2007 11:58:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLZZ-0002kX-EV for p2psip@lists.ietf.org; Wed, 14 Nov 2007 11:58:41 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsLZV-0007zt-Qc for p2psip@lists.ietf.org; Wed, 14 Nov 2007 11:58:41 -0500 Received: from [192.168.189.115] ([192.5.93.132]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAEGwVwC024820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Nov 2007 11:58:31 -0500 (EST) Message-Id: <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> From: Henning Schulzrinne To: "Vijay K. Gurbani" In-Reply-To: <473B17D1.6030705@alcatel-lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities Date: Wed, 14 Nov 2007 11:58:31 -0500 References: <20071113144604.8CF0733C59@delta.rtfm.com> <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> X-Mailer: Apple Mail (2.912) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I remember reading about another type of CAPTCHA that involves > a group of pictures -- three out of four pictures would be > rodents and the fourth one would be a lion, say. You would be > asked to pick out which image does not mesh with other ones. > Such tests are relatively easy for humans to do (we can tell > a lion apart from a mouse), but it is hard to provide that much > context to a computer. It's subject to the same outsourcing attack as all other CAPTCHAs. Plus, this type of image picking game is not too helpful, since it would have a 25% chance of being solvable by random guess. As noted by others, I'm confused as to why this is of concern to this working group. It seems highly unlikely that the working group will recommend a particular Turing test, audio, video or otherwise. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 11:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLab-0003Y6-Dg; Wed, 14 Nov 2007 11:59:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLaa-0003WQ-34 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 11:59:44 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsLaX-000883-NY for p2psip@lists.ietf.org; Wed, 14 Nov 2007 11:59:44 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRI008E99VHFZ@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Wed, 14 Nov 2007 08:59:41 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRI00K659VE9B@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Wed, 14 Nov 2007 08:59:41 -0800 (PST) Date: Wed, 14 Nov 2007 10:58:48 -0600 From: Spencer Dawkins To: p2psip@lists.ietf.org Message-id: <087601c826df$a0736a20$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [P2PSIP] Another thought about ways to move forward X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Just to be clear, I'm not suggesting that we stop work on peer protocol proposals and work on requirements - that wouldn't be helpful or realistic. Having said that... We're having some very interesting requirements discussions on this list, and the two things that concern me as a working group participant is - discussions like this tend to include handwaving ("what about THIS?", "oh, THIS isn't a problem because of THAT", when "THAT" hasn't been mentioned yet), so it's really difficult to understand a proposal and respond to it when the proposal is still being revealed over time, and - even when discussions like this DO converge, the convergence doesn't really count until it appears as draft text that the working group chairs can judge consensus on, and then forward requesting publication. So, it would be lovely to have draft text - and yes, I know we're now in the 00 blackout, but that doesn't prevent people from submitting drafts that WILL be announced (apparently, even during the IETF week, based on recent practice), as the basis for hallway discussions in Vancouver, and as the basis for more focused discussion on this list after Vancouver. ("Please send text" is an IETF slogan going way back in time) Thanks, Spencer, speaking only for myself - the position of Miss Manners for this mailing list is still open, as far as I know _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 12:09:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLkF-0004pP-6Z; Wed, 14 Nov 2007 12:09:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLkD-0004ml-Gf for p2psip@lists.ietf.org; Wed, 14 Nov 2007 12:09:41 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsLkA-0000ij-2B for p2psip@lists.ietf.org; Wed, 14 Nov 2007 12:09:41 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lAEH9T4N028218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Nov 2007 11:09:30 -0600 In-Reply-To: <473ADC5C.4070101@it.uc3m.es> References: <20071113144604.8CF0733C59@delta.rtfm.com> <354B2F73-D7D2-408C-9513-E523863AB2F4@cs.columbia.edu> <473ADC5C.4070101@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5A03E1FC-2B82-41CE-A5EE-CC2BEE63FFAE@softarmor.com> Content-Transfer-Encoding: quoted-printable From: Dean Willis Subject: Re: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities Date: Wed, 14 Nov 2007 11:09:11 -0600 To: p2psip@lists.ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 14, 2007, at 5:30 AM, Rub=E9n Cuevas Rum=EDn wrote: > > What I consider the best option for a proof-of-work is to solicit =20 > the user to introduce a CAPTCHA before getting the Peer-ID. The =20 > advantages are: > - Require the human intervention, and then the attack cannot be =20 > automated. > - The time spent to get one id is reduced for honest users (just =20 > few seconds) but increase linearly with the number of Peer-IDs =20 > solicited, making the attack costly in terms of time (for instance =20 > in the case of 105 nodes in the DHT). > - This is a proof-of-work which every user independently on the =20 > CPU capacity of his computer can perform. Then, the entry barriers =20 > to the system are really low. > I think that, in the US, the agency overseeing the laws dealing with =20 person with disabilities (especially the visually impaired) would =20 not like that very much. There's also an IPR consideration. CAPTCHA is, IIRC, patented. -- Dean= _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 12:50:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMNP-0004h3-TX; Wed, 14 Nov 2007 12:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsMNO-0004gj-51 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 12:50:10 -0500 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsMNK-0004zj-Od for p2psip@lists.ietf.org; Wed, 14 Nov 2007 12:50:10 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id CEAA61EF56B; Wed, 14 Nov 2007 18:39:53 +0100 (CET) Message-ID: <473B32EF.7010909@it.uc3m.es> Date: Wed, 14 Nov 2007 18:39:59 +0100 From: =?windows-1252?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities References: <20071113144604.8CF0733C59@delta.rtfm.com><354B2F73-D7D2-408C-9513-E523863AB 2F 4@cs.columbia.edu><473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com><473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> In-Reply-To: <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> Content-Type: text/plain; charset=windows-1252; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-15.6074 TC:02 TRN:44 TV:5.0.1023(15546.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > As noted by others, I'm confused as to why this is of concern to this=20 > working group. It seems highly unlikely that the working group will=20 > recommend a particular Turing test, audio, video or otherwise. From my point of view we are discussing how to provide a secure=20 assignment of Peer-IDs which I think is something basic for P2PSIP.=20 Since with the existing solutions it is impossible to avoid that one=20 malicious user obtains as many Peer-IDs as he desires, then we have to=20 make the obtention of Peer-IDs costly in somehow (time, CPU...). I agree the WG (probably) will not recomend the proof-of-work to be=20 used. However, we must know if the different proof-of-work defined so=20 far are enough to guarantee a high security level or not. If we find that this is true, then P2PSIP could adopt the scheme with a=20 central entity providing the Peer-IDs. However, if we cannot assure a=20 given security level, we should move to another Peer-ID assignment scheme= . As basis to evaluate the difficulty of this attack in DHTs (if someone=20 is interested) you can have a look on [1] which analyzes mathematically=20 this problem. Thanks, Rub=E9n. [1] R.Cuevas, A.Cuevas, M.Urue=F1a, A.Banchs, C.Guerrero. "Evaluation of=20 the p2p Structured Systems=92 Resistance against the Starvation Attack".=20 Tech.Report. Department of Telematic Engineering, Universidad Carlos III=20 de Madrid. Available at:=20 http://www.it.uc3m.es/~rcuevas/tech_report/tech_report_starvation_attack.= pdf > > Henning > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 14:17:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNjs-0003My-EE; Wed, 14 Nov 2007 14:17:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsNjq-0003MZ-S3 for p2psip@lists.ietf.org; Wed, 14 Nov 2007 14:17:26 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsNjo-0005rN-TW for p2psip@lists.ietf.org; Wed, 14 Nov 2007 14:17:26 -0500 Received: by py-out-1112.google.com with SMTP id u77so2955939pyb for ; Wed, 14 Nov 2007 11:17:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=NPzNxCn1HlxVRBTAhvC88uUojToajuxOGKiNFdSXMfw=; b=KZl92dUBTPGytAlmqdR8ozBU+OlP2GCy6p9+5jjFoeYG8shqfJ7+hTCg1rR+Z9bIm5qDYMt213GqtzvLFrE4tdjhYNx5UDvmCBWN1Qz9MT93E4X8sYTmm+VXyGPWtwqNM05a/9zyMMndi9xihMT5tML3cYSVK9NhzIpQoj75M7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=cYSnBs3Y8uDftJ5niNElBN/av4u0eSx4IbeKAHheTMzrK7+YfCMwW7FT2NPnAlBfDFn/4icVsaCW6Exwjmx5el3cmzYNSouG0kwdBq5rPyiNzM/U69wRA0sZnwstex3oWIkZzCg8Vxyp/COgR3jd3MeLwON866w5cRJdMJoIaZ8= Received: by 10.65.43.5 with SMTP id v5mr19745203qbj.1195067841100; Wed, 14 Nov 2007 11:17:21 -0800 (PST) Received: by 10.65.180.16 with HTTP; Wed, 14 Nov 2007 11:17:20 -0800 (PST) Message-ID: <4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com> Date: Wed, 14 Nov 2007 14:17:20 -0500 From: "David A. Bryan" To: rcuevas@it.uc3m.es Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities In-Reply-To: <473B32EF.7010909@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20071113144604.8CF0733C59@delta.rtfm.com> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> <473B32EF.7010909@it.uc3m.es> X-Google-Sender-Auth: 609763d43829f16c X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I think this is a bit of a red herring. It is true that if we just have a central authority that gives anyone who asks as many certificates and peer ids as they wish, we have the problem you mention. One could similarly argue that in any account-based architecture where an admin gives you an ID is flawed, since you can ask for as many as you want and get them all. The point is that that central authority has an interest in preventing these sorts of things and can (and does) use policies to enforce them. A similar mechanism can be used here. The charter is rather clear that we aren't going to develop decentralized identity schemes, and we will use a central authority, with a mechanism to ensure identities, and that defining that mechanism is outside of the scope of the WG. This decision was made to ensure that this group would be able to produce a protocol draft in a reasonable length of time and didn't get into a rat hole of a "research problem" on making fully distributed identity or no-intervention identity system. (charter text is here: http://www.ietf.org/html.charters/p2psip-charter.html) I think this discussion is interesting, but we are explicitly discussing the mechanism to assure identities here, something that is out of our scope. The person running that central authority can use any mechanism they want. We can discuss this sort of thing of course, but as I see it, this isn't something that will be addressed within the context of the WG, as it falls outside our charter. David On Nov 14, 2007 12:39 PM, Rub=E9n Cuevas Rum=EDn wrote= : > > > As noted by others, I'm confused as to why this is of concern to this > > working group. It seems highly unlikely that the working group will > > recommend a particular Turing test, audio, video or otherwise. > From my point of view we are discussing how to provide a secure > assignment of Peer-IDs which I think is something basic for P2PSIP. > Since with the existing solutions it is impossible to avoid that one > malicious user obtains as many Peer-IDs as he desires, then we have to > make the obtention of Peer-IDs costly in somehow (time, CPU...). > I agree the WG (probably) will not recomend the proof-of-work to be > used. However, we must know if the different proof-of-work defined so > far are enough to guarantee a high security level or not. > If we find that this is true, then P2PSIP could adopt the scheme with a > central entity providing the Peer-IDs. However, if we cannot assure a > given security level, we should move to another Peer-ID assignment scheme= . > > As basis to evaluate the difficulty of this attack in DHTs (if someone > is interested) you can have a look on [1] which analyzes mathematically > this problem. > > > Thanks, > Rub=E9n. > > > [1] R.Cuevas, A.Cuevas, M.Urue=F1a, A.Banchs, C.Guerrero. "Evaluation of > the p2p Structured Systems' Resistance against the Starvation Attack". > Tech.Report. Department of Telematic Engineering, Universidad Carlos III > de Madrid. > Available at: > http://www.it.uc3m.es/~rcuevas/tech_report/tech_report_starvation_attack.= pdf > > > > > > Henning > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > -- > Rub=E9n Cuevas Rum=EDn > Universidad Carlos III de Madrid > Departamento Ingenier=EDa Telem=E1tica > Avenida de la Universidad, 30 > 28911-Legan=E9s (Madrid). Espa=F1a > email: rcuevas@it.uc3m.es > Tlf: +34 91-6248859 > Fax: +34 91-6248749 > Web: http://www.it.uc3m.es/~rcuevas > > > _______________________________________________ > > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 16:09:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPUD-0002Oj-QP; Wed, 14 Nov 2007 16:09:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPUC-0002LV-Jf for p2psip@ietf.org; Wed, 14 Nov 2007 16:09:24 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-08.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsPU9-0008Mr-Mu for p2psip@ietf.org; Wed, 14 Nov 2007 16:09:24 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IsPU9-0007cK-1X; Wed, 14 Nov 2007 16:09:21 -0500 In-Reply-To: <4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com> References: <20071113144604.8CF0733C59@delta.rtfm.com> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> <473B32EF.7010909@it.uc3m.es> <4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Philip Matthews Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities Date: Wed, 14 Nov 2007 16:10:30 -0500 To: David A. Bryan X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I disagree. I think this discussion is very relevant. First of all, I will note that the charter says: The initial work will assume the existence of some enrollment =20 process that provides a unique user name, credentials, and an initial set of bootstrap nodes if that is required by the protocols. Developing a non-centralized enrollment process is not in scope. There is nothing in there that talks about Peer IDs. Then, in Chicago, EKR commented that the system used by HIP-HOP to assign Peer IDs was not secure. Furthermore, he claims that the scheme used by ASP (a central enrollment server) IS secure. As I recall, there was quite a bit of discussion about this at the =20 Monday night meeting. The counter-argument that Marcus is making is that the central =20 enrollment server as envisioned by ASP is NOT secure, and thus HIP-HOP is no worse that =20= ASP. Moreover, I would claim that the scheme used by HIP-HOP is more =20 practical, because it does not depend on a centralized enrollment server. So how do we resolve this debate? Are you saying that the debate is irrelevant and out-of-scope? - Philip On 14-Nov-07, at 14:17 , David A. Bryan wrote: > I think this is a bit of a red herring. > > It is true that if we just have a central authority that gives anyone > who asks as many certificates and peer ids as they wish, we have the > problem you mention. > > One could similarly argue that in any account-based architecture where > an admin gives you an ID is flawed, since you can ask for as many as > you want and get them all. The point is that that central authority > has an interest in preventing these sorts of things and can (and does) > use policies to enforce them. A similar mechanism can be used here. > > The charter is rather clear that we aren't going to develop > decentralized identity schemes, and we will use a central authority, > with a mechanism to ensure identities, and that defining that > mechanism is outside of the scope of the WG. This decision was made to > ensure that this group would be able to produce a protocol draft in a > reasonable length of time and didn't get into a rat hole of a > "research problem" on making fully distributed identity or > no-intervention identity system. (charter text is here: > http://www.ietf.org/html.charters/p2psip-charter.html) > > I think this discussion is interesting, but we are explicitly > discussing the mechanism to assure identities here, something that is > out of our scope. The person running that central authority can use > any mechanism they want. We can discuss this sort of thing of course, > but as I see it, this isn't something that will be addressed within > the context of the WG, as it falls outside our charter. > > David > > > On Nov 14, 2007 12:39 PM, Rub=E9n Cuevas Rum=EDn =20= > wrote: >> >>> As noted by others, I'm confused as to why this is of concern to =20 >>> this >>> working group. It seems highly unlikely that the working group will >>> recommend a particular Turing test, audio, video or otherwise. >> =46rom my point of view we are discussing how to provide a secure >> assignment of Peer-IDs which I think is something basic for P2PSIP. >> Since with the existing solutions it is impossible to avoid that one >> malicious user obtains as many Peer-IDs as he desires, then we =20 >> have to >> make the obtention of Peer-IDs costly in somehow (time, CPU...). >> I agree the WG (probably) will not recomend the proof-of-work to be >> used. However, we must know if the different proof-of-work defined so >> far are enough to guarantee a high security level or not. >> If we find that this is true, then P2PSIP could adopt the scheme =20 >> with a >> central entity providing the Peer-IDs. However, if we cannot assure a >> given security level, we should move to another Peer-ID assignment =20= >> scheme. >> >> As basis to evaluate the difficulty of this attack in DHTs (if =20 >> someone >> is interested) you can have a look on [1] which analyzes =20 >> mathematically >> this problem. >> >> >> Thanks, >> Rub=E9n. >> >> >> [1] R.Cuevas, A.Cuevas, M.Urue=F1a, A.Banchs, C.Guerrero. =20 >> "Evaluation of >> the p2p Structured Systems' Resistance against the Starvation =20 >> Attack". >> Tech.Report. Department of Telematic Engineering, Universidad =20 >> Carlos III >> de Madrid. >> Available at: >> http://www.it.uc3m.es/~rcuevas/tech_report/=20 >> tech_report_starvation_attack.pdf >> >> >>> >>> Henning >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >>> >> >> >> -- >> Rub=E9n Cuevas Rum=EDn >> Universidad Carlos III de Madrid >> Departamento Ingenier=EDa Telem=E1tica >> Avenida de la Universidad, 30 >> 28911-Legan=E9s (Madrid). Espa=F1a >> email: rcuevas@it.uc3m.es >> Tlf: +34 91-6248859 >> Fax: +34 91-6248749 >> Web: http://www.it.uc3m.es/~rcuevas >> >> >> _______________________________________________ >> >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > > --=20 > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 16:35:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPtc-0006YM-Do; Wed, 14 Nov 2007 16:35:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsPta-0006OF-Af for p2psip@ietf.org; Wed, 14 Nov 2007 16:35:38 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsPtZ-0003sw-I9 for p2psip@ietf.org; Wed, 14 Nov 2007 16:35:38 -0500 Received: from [192.168.189.115] ([192.5.93.132]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAELZacL020379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 14 Nov 2007 16:35:36 -0500 (EST) Message-Id: From: Henning Schulzrinne To: Philip Matthews In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v912) Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities Date: Wed, 14 Nov 2007 16:35:34 -0500 References: <20071113144604.8CF0733C59@delta.rtfm.com> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> <473B32EF.7010909@it.uc3m.es> <4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com> X-Mailer: Apple Mail (2.912) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The problem is that we don't define the assumptions. At one extreme, =20 we have "fully anonymous node about which nothing is known and which =20 has a billion brethren that look exactly like it". You can also have =20 "Node that has obtained a Top Secret security clearance and has made a =20= $1M bond deposit." Depending on the assumptions, the problem is either =20= unsolvable or fairly easy. However, there isn't a single set of =20 assumptions that we can all agree on, as they restrict the =20 applicability in various ways. Thus, I think this discussion isn't =20 likely to get very far until we have at least a set of assumptions =20 that are usefully measurable and we have agreed on. As a random example, if you can limit the set of participating nodes =20 to "good" nodes by the effort of some certification node, possibly in =20= some time in the reasonably distant past, you can then likely use a =20 distributed mechanism at some other point in time. Thus, you now have =20= both a centralized and a distributed mechanisms in one system. If somebody can solve the problem by making absolutely no assumptions, =20= I suspect that person should be writing a paper for a major conference =20= pronto, not hang out in this mailing list. Henning On Nov 14, 2007, at 4:10 PM, Philip Matthews wrote: > I disagree. I think this discussion is very relevant. > > First of all, I will note that the charter says: > The initial work will assume the existence of some enrollment =20 > process > that provides a unique user name, credentials, and an initial set of > bootstrap nodes if that is required by the protocols. Developing a > non-centralized enrollment process is not in scope. > There is nothing in there that talks about Peer IDs. > > Then, in Chicago, EKR commented that the system used by HIP-HOP > to assign Peer IDs was not secure. Furthermore, he claims that the > scheme used by ASP (a central enrollment server) IS secure. > As I recall, there was quite a bit of discussion about this at the =20 > Monday night > meeting. > > The counter-argument that Marcus is making is that the central =20 > enrollment server > as envisioned by ASP is NOT secure, and thus HIP-HOP is no worse =20 > that ASP. > Moreover, I would claim that the scheme used by HIP-HOP is more =20 > practical, > because it does not depend on a centralized enrollment server. > > So how do we resolve this debate? > Are you saying that the debate is irrelevant and out-of-scope? > > - Philip > > > > > On 14-Nov-07, at 14:17 , David A. Bryan wrote: > >> I think this is a bit of a red herring. >> >> It is true that if we just have a central authority that gives anyone >> who asks as many certificates and peer ids as they wish, we have the >> problem you mention. >> >> One could similarly argue that in any account-based architecture =20 >> where >> an admin gives you an ID is flawed, since you can ask for as many as >> you want and get them all. The point is that that central authority >> has an interest in preventing these sorts of things and can (and =20 >> does) >> use policies to enforce them. A similar mechanism can be used here. >> >> The charter is rather clear that we aren't going to develop >> decentralized identity schemes, and we will use a central authority, >> with a mechanism to ensure identities, and that defining that >> mechanism is outside of the scope of the WG. This decision was made =20= >> to >> ensure that this group would be able to produce a protocol draft in a >> reasonable length of time and didn't get into a rat hole of a >> "research problem" on making fully distributed identity or >> no-intervention identity system. (charter text is here: >> http://www.ietf.org/html.charters/p2psip-charter.html) >> >> I think this discussion is interesting, but we are explicitly >> discussing the mechanism to assure identities here, something that is >> out of our scope. The person running that central authority can use >> any mechanism they want. We can discuss this sort of thing of course, >> but as I see it, this isn't something that will be addressed within >> the context of the WG, as it falls outside our charter. >> >> David >> >> >> On Nov 14, 2007 12:39 PM, Rub=E9n Cuevas Rum=EDn = =20 >> wrote: >>> >>>> As noted by others, I'm confused as to why this is of concern to =20= >>>> this >>>> working group. It seems highly unlikely that the working group will >>>> recommend a particular Turing test, audio, video or otherwise. >>> =46rom my point of view we are discussing how to provide a secure >>> assignment of Peer-IDs which I think is something basic for P2PSIP. >>> Since with the existing solutions it is impossible to avoid that one >>> malicious user obtains as many Peer-IDs as he desires, then we =20 >>> have to >>> make the obtention of Peer-IDs costly in somehow (time, CPU...). >>> I agree the WG (probably) will not recomend the proof-of-work to be >>> used. However, we must know if the different proof-of-work defined =20= >>> so >>> far are enough to guarantee a high security level or not. >>> If we find that this is true, then P2PSIP could adopt the scheme =20 >>> with a >>> central entity providing the Peer-IDs. However, if we cannot =20 >>> assure a >>> given security level, we should move to another Peer-ID assignment =20= >>> scheme. >>> >>> As basis to evaluate the difficulty of this attack in DHTs (if =20 >>> someone >>> is interested) you can have a look on [1] which analyzes =20 >>> mathematically >>> this problem. >>> >>> >>> Thanks, >>> Rub=E9n. >>> >>> >>> [1] R.Cuevas, A.Cuevas, M.Urue=F1a, A.Banchs, C.Guerrero. =20 >>> "Evaluation of >>> the p2p Structured Systems' Resistance against the Starvation =20 >>> Attack". >>> Tech.Report. Department of Telematic Engineering, Universidad =20 >>> Carlos III >>> de Madrid. >>> Available at: >>> = http://www.it.uc3m.es/~rcuevas/tech_report/tech_report_starvation_attack.p= df >>> >>> >>>> >>>> Henning >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/p2psip >>>> >>> >>> >>> -- >>> Rub=E9n Cuevas Rum=EDn >>> Universidad Carlos III de Madrid >>> Departamento Ingenier=EDa Telem=E1tica >>> Avenida de la Universidad, 30 >>> 28911-Legan=E9s (Madrid). Espa=F1a >>> email: rcuevas@it.uc3m.es >>> Tlf: +34 91-6248859 >>> Fax: +34 91-6248749 >>> Web: http://www.it.uc3m.es/~rcuevas >>> >>> >>> _______________________________________________ >>> >>> P2PSIP mailing list >>> P2PSIP@ietf.org >>> https://www1.ietf.org/mailman/listinfo/p2psip >>> >> >> >> >> --=20 >> David A. Bryan >> dbryan@SIPeerior.com >> +1.757.565.0101 x101 >> +1.757.565.0088 (fax) >> www.SIPeerior.com >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 16:57:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQEN-0007MQ-Dz; Wed, 14 Nov 2007 16:57:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQEL-0007LW-Mm for p2psip@ietf.org; Wed, 14 Nov 2007 16:57:05 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsQEL-0004jI-8n for p2psip@ietf.org; Wed, 14 Nov 2007 16:57:05 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id A3F3033C21; Wed, 14 Nov 2007 13:52:12 -0800 (PST) Date: Wed, 14 Nov 2007 13:52:12 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities In-Reply-To: References: <20071113144604.8CF0733C59@delta.rtfm.com> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> <473B32EF.7010909@it.uc3m.es> <4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071114215212.A3F3033C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Wed, 14 Nov 2007 16:10:30 -0500, Philip Matthews wrote: > > I disagree. I think this discussion is very relevant. > > First of all, I will note that the charter says: > The initial work will assume the existence of some enrollment > process > that provides a unique user name, credentials, and an initial set of > bootstrap nodes if that is required by the protocols. Developing a > non-centralized enrollment process is not in scope. > There is nothing in there that talks about Peer IDs. > > Then, in Chicago, EKR commented that the system used by HIP-HOP > to assign Peer IDs was not secure. Furthermore, he claims that the > scheme used by ASP (a central enrollment server) IS secure. > As I recall, there was quite a bit of discussion about this at the > Monday night > meeting. > > The counter-argument that Marcus is making is that the central > enrollment server > as envisioned by ASP is NOT secure, and thus HIP-HOP is no worse that > ASP. I don't think the term "secure" is very useful here. Let's rather talk about how hard it is to mount various attacks. In a centralized system, where the peer-ids are centrally assigned, in order to get a peer-id in a portion of the overlay 1/N the size of the overlay requires N queries to the central enrollment server. In a decentralized system where you get to generate your own peer-ids--even if you have no control over the peer-ids you generate other than being able to generate a new random one, it requires one query. That's just the basic math of the situation. The implication here is that: 1. Decentralized systems and centralized systems with no rate limiting are vulnerable to both chosen peer ID and Sybil attacks, but decentralized systems are moreso. 2. Centralized systems with even moderate rate limiting are vulnerable to Sybil but not chosen peer ID attacks. 3. Centralized systems with good rate limiting are not vulnerable to either attack. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 20:55:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsTww-000722-G9; Wed, 14 Nov 2007 20:55:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsTwv-0006zk-Au for p2psip@ietf.org; Wed, 14 Nov 2007 20:55:21 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsTwu-0004Ax-8S for p2psip@ietf.org; Wed, 14 Nov 2007 20:55:21 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRI000ITYO5V3@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 09:55:17 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRI004DDYO48K@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 09:55:17 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRI00FI6YO05X@szxml03-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 09:55:16 +0800 (CST) Date: Thu, 15 Nov 2007 09:55:14 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <7b683f3f0711140707p627a6d2bwe31bc15e8106c12b@mail.gmail.com> To: 'Eunsoo Shim' Message-id: <00e501c8272a$905b2060$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: QUOTED-PRINTABLE Thread-index: Acgm0nNVAKZZT1XRQeqmzQAnwi235gAVhj1A X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: 'Henry Sinnreich' , 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, In Reference model defined in the Concept document, there are main= ly two types of nodes: peers and clients with SIP UA. Further, there are two types of peers: peers with some SIP entity and= peers without any SIP entity. But from the contribution to P2PSIP overlay network, we can think = that there are mainly three types of nodes: peers (participating in overlay, contributing storage capacity), clients (o= nly contributing storage capacity to their associated peers) and ordinary SIP UAs (without any contribution), is my underst= anding correct? Certainly, ordinary SIP UAs usually are regarded as P2PSIP clients= , and essentially SIP usually is regarded one type of service over P2PSIP overlay layer. I think that we need update the Section 5.3 if we reach the agreem= ent about P2PSIP client character according to the Reference model, any comment? Best regards, Hewen > -----Original Message----- > From: Eunsoo Shim [mailto:eunsooshim@gmail.com] > Sent: 2007?11?14? 23:08 > To: Zheng Hewen > Cc: Victor Pascual =A8?vila; Henry Sinnreich; Philip Matthews; > P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behav= ior > > My comments are inline. > > On Nov 13, 2007 10:20 PM, Zheng Hewen wrote: > > Hi, all, > > > > The time in Vancouver is limited and very precious. > > After those discussion about P2PSIP client in the lates= t > > mail list, a survey about P2PSIP client charcater/behavior > among active members in this work group will be very helpful > for the further discussion in Vancouver. > > As Victor Pascual =A8=A2vila said, there are mainly > three types of nodes: > > (1).Peers (nodes to perform the overlay and offer stora= ge > > and routing capabilities and they are coupled WITH one or > more SIP entities or WITHOUT any SIP entity, overlay-routing nodes)= , > > (2).Clients (nodes to contribute its storage > capacity to its > > associated peer and they are coupled with SIP UA, > non-overlay-routing > > nodes); > > Clients may be coupled with one or more SIP entities or none. > > > (3).SIP [RFC3161] (UA with no other capabilities). > > > When we talk about the overlay, this kind of node is irrelevant. > The overlay (protocol) nodes and SIP entities are independent > of each other. > Please don't mix them. > > > Any comment? > > > > We suggest that the revised Concept document > would clarify > > the P2PSIP client character if an agreement about P2PSIP > client character is reached in the mail list. > > > > Thanks. > > Eunsoo > > > -----Original Message----- > > From: Victor Pascual =A8=A2vila [mailto:victor.pascual.avila@gmai= l.com] > > Sent: 2007=C4=EA11=D4=C214=C8=D5 4:56 > > To: Henry Sinnreich > > Cc: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu= ; > > P2PSIP Mailing List > > Subject: Re: client protocol ([P2PSIP] Proposal for progress on > > protocols) > > > > On 13/11/2007, Henry Sinnreich wrote: > > > >From this list I understand there is less a problem with the > > > >existence > > > of clients, but rather if there should be a separate > client protocol. > > > > > > Also, some folks mentioned that the client protocol > should just be a > > > subset of the peer protocol. > > > > > > Is this understanding of the discussions correct? > > > > This is how I understand the discussions. > > > > Considering Peers to offer at least routing and storage > capabilities, > > some of us understand Clients to offer only storage. In > this way, as > > said in previous messages, we should consider three main types of > > node: peers (nodes to perform the overlay and offer storage and > > routing capabilities and they are coupled with one or more SIP > > entities), clients (nodes to contribute its storage > capacity to its associated peer and they are coupled with SIP > UA) and SIP [RFC3161] (UA with no other capabilities). > > > > Clients and SIP UA will reach P2PSIP overlay through peers. While > > Clients will store some information, peers will store > information on behalf of SIP UA. > > > > Since Peers and Clients would need to exchange some kind of > > information, what is a subset of information exchanged > between peers + > > other possible data with other periodicity, requirements > for the Client protocol can be considered to be different > from the Peer protocol. > > > > Thus, > > Peer <---- Peer Protocol ----> Peer > > Client <---- Client Protocol ----> Peer SIP UA <---- SIP [RFC3261= ] > > ----> Peer > > > > As an example, I imagine Peers storing 'general' AoR > information and > > user preferences while Clients would store only 'their > buddies' AoR information. > > > > > > Thank you, > > Victor Pascual > > > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > Eunsoo > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 14 21:47:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsUlZ-0005wW-Iv; Wed, 14 Nov 2007 21:47:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsUlX-0005on-2G for p2psip@ietf.org; Wed, 14 Nov 2007 21:47:39 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsUlV-0005qV-5o for p2psip@ietf.org; Wed, 14 Nov 2007 21:47:38 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRJ006LN130MN@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 10:47:24 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRJ005S012ZET@szxga04-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 10:47:24 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRJ00F4M12YPY@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 10:47:23 +0800 (CST) Date: Thu, 15 Nov 2007 10:47:22 +0800 From: JiangXingFeng To: 'P2PSIP Mailing List' Message-id: <002f01c82731$d917de40$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/mixed; boundary="Boundary_(ID_6Z5zMc8rsEiHLb+rPH/s5w)" Thread-index: AcgnMdjBlvlt16GGSSy0lJTDuQ8eow== X-Spam-Score: 0.0 (/) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 Subject: [P2PSIP] Service discovery in P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_6Z5zMc8rsEiHLb+rPH/s5w) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, all: In the draft-ietf-p2psip-concepts-00, there is a definition for the P2PSIP Service. As described in this definition, P2PSIP needs a service locator function, here, which I call service discovery function. I've got an idea about how to get service peers which provide one specific service and are distributed through the overlay. Now I introduce the idea here briefly and I prepare two slides to give more detail. We try to make full use of the chance when a request sent by the source peer is forward by several intermediate peers through the overlay. So if the source peer wants to get peers of a specific service, it could indicates its willing in the request and ask for the intermediate peers and the destination peer to help it collect the information. And later the information will be return to the source peer in the response. But how do the intermediate peer and the destination peer knows which peers could provide which type of service. IMO, it could rely on the overlay maintenance mechanism inherent in DHT algorithms. It may be done like this. If the peers have some additional service capability, it may encode it in its information so that other peers who choose it as P2PSIP neighbors could learn the information. While a peer receive a request for discovering a peer, it could check its locally stored information about its neighbors and if there are some matched peers, it could put it in the message. Any comments are appreciated. -- Jiang XingFeng --Boundary_(ID_6Z5zMc8rsEiHLb+rPH/s5w) Content-type: application/vnd.ms-powerpoint; name="service discovery.ppt" Content-transfer-encoding: base64 Content-disposition: attachment; filename="service discovery.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAOQAAAAAAAAAA EAAAGAAAAAEAAAD+////AAAAADoAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////9 ////KgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAADgAAAA8A AAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAACsAAAD+////KQAAABsAAAAcAAAAHQAA AB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAA/v////7////+//// LAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAAAP7///// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////1IA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAWAAUA//////////8BAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAGCY1I0xJ8gB GQAAAMACAAAAAAAAUABvAHcAZQByAFAAbwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAAAwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAACAAAAWUcAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0 AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQQAAAD//////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAAAsHAAAAAAAAAUARABvAGMAdQBtAGUAbgB0 AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADwCAAAAAAAADwDo A5cEAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPID YAEAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5gAAAAAALcPRAAAAEEAcgBpAGEAbAAAANSDEwBf Pgsw1IMTAAAAAAAwANIPbJYTAGyWEwAgMGIQ9IMTAHg6CzD0gxMAAAAAAA8A1QcAAAQAEAC3D0QA AACLW1NPAABhAGwAAADUgxMAXz4LMNSDEwAAAAAAMADSD2yWEwBslhMAIDBiEPSDEwB4Ogsw9IMT AAAAAAAPANUHhgAEAgAApA8IAAAAgABAAAAAAAAAAKUPDAAAAAAAAAguAAAABwAAAAAAqQ8KAAAA BwAAAAIABAgJBEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAAAAAAAAAAAAQAIAAAAABwAA AP//7wAAAAAAAQAAAP//EgAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAA AAAABQAAgASABAAAAAAPAAsExAAAAA8AAPC8AAAAAAAG8FgAAAAEJAAACgAAAC4AAAADAAAAAQAA AAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAQAAABgAAAABQAAACMAAAAAAAAA GwAAAAAAAAAEAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiGQQAAAAC/ARAAEADAAQEAAAjFQQAAAAD/ AQgACAABAgIAAAgQABrxBAAAAMwzAABAAB7xEAAAAAQAAAjMMwAAAgAACPcAABAfAPAPHAAAAAAA 8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHMwEAAB8AFAQcAAAAAAAVBBQAAAC6k7D2AMqa O60HlMcAypo7AQEAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEYAAABkAAAARgAAAGQAAAAA AAAAxDJiEAyEEwB4OgswAAAAAAAAAAA+/v//EAIAAAEAEwBwAPsDCAAAAAAAAABwCAAAcAD7AwgA AAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfABMEPAAAAAAA/QM0AAAAZAAA AGQAAABkAAAAZAAAAAIAAAA4hBMA/PgKMGyWEwAAAAAAAAAAAAAAAAAAAAAAAAATAA8AiBM4AAAA DwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAADQQIAAAAAMAAAADAAAA/ ANkPDAAAAAAA2g8EAAAADQAlAA8A8A+wAAAAAADzAxQAAAAEAAAABAAAAAIAAAABAQAAAAAAAAAA nw8EAAAAAAAAAAAAqg8KAAAAAQAAAAEAAAAAABAAnw8EAAAAAQAAAAAAqg8KAAAAAQAAAAEAAAAA AAAA8wMUAAAABQAAAAQAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKoPCgAAAAEAAAABAAAA AAAQAJ8PBAAAAAEAAAAAAKoPCgAAAAEAAAABAAAAAAAAAOoDAAAAAA8A+APACQAAAgDvAxgAAAAB AAAAAQIHCQgAAAAAAAAAAAAAAAAACzBgAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZ mQCZzAAAYADwByAAAAD///8AAAAAAJaWlgAAAAAA+99TAP+ZZgDMMwAAmWYAAGAA8AcgAAAA//// AAAAAACAgIAAAAAAAJnM/wDMzP8AMzPMAK9n/wBgAPAHIAAAAN728QAAAAAAlpaWAAAAAAD///8A jcb/AABmzAAAqAAAYADwByAAAAD//9kAAAAAAHd3dwAAAAAA///3ADPMzAD/UFAA/5kAAGAA8Acg AAAAAICAAP///wAAWlgA//+ZAABkYgBtb8cAAP//AAD/AABgAPAHIAAAAIAAAAD///8AXB8AAN/S kwDMMwAAvnlgAP//mQDTohkAYADwByAAAAAAAJkA////AAAzZgDM//8AM2bMAACwAABmzP8A/+cB AGAA8AcgAAAAAAAAAP///wAzZpkA4+vxAAAzmQBGiksAZsz/APDlAABgAPAHIAAAAGhrXQD///8A d3d3ANHRywCQkIIAgJ6oAP/MZgDp3LkAYADwByAAAABmZpkA////AD4+XAD///8AYFl7AGZm/wCZ zP8A//+ZAGAA8AcgAAAAUj4mAP///wAtIBUA38CNAIx7cACPXy8AzLQAAIyeoAAAAKMPPgAAAAEA //0/AAAAIiAAAGQAAAAA/wEAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAAEAAAD//ywAAAAA AwAAEACjD3wAAAAFAP/9PwABACIgAABkAAAAAP8AAGQAFAAAANgAAABAAgAAAAAHAAAA///vAAAA AAABAAAA//8gAAAAAAEAAIAFAAATINQBIAEAAAIAHACABQAAIiDQAkACAAACABgAgAUAABMg8ANg AwAAAgAUAIAFAAC7ABAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIgAABkAAAAAP8AAGQAHgAAAAAA AABAAgAAAAAHAAAA///vAAAAAAABAAAA//8MAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEJAAAAAAEAAAAAAAAAAQABCQAA AAABACABAAAAAAIAAQkAAAAAAQBAAgAAAAADAAEJAAAAAAEAYAMAAAAABAABCQAAAAABAIAEAAAA AGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAAAgAcAAEAAAAAAAAAAgAYAAIA AAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAAow8+AAAABQAAAAAAAAAAAAIAGAAB AAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIAEAAEAAAAAAAAAAIAEAAPAAwEAgUAAA8A AvD6BAAAEAAI8AgAAAAGAAAABgQAAA8AA/CSBAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA AAAAAAACAArwCAAAAAAEAAAFAAAADwAE8MoAAAASAArwCAAAAAIEAAAACgAAkwAL8DYAAAB/AAEA BQCAALBmYhCHAAEAAACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAA AK0AIAFgFX0DDwAR8BAAAAAAAMMLCAAAAAAAAAABAGIQDwAN8EwAAAAAAJ8PBAAAAAAAAAAAAKAP GAAAAFVT+1FkawRZFn+Rj81rSHIHaJiYN2gPXwAAog8GAAAADQAAAAAAAACqDwoAAAANAAAAAQAA AAAADwAE8PwAAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEABQCAAHRpYhCBAQQAAAiDAQAA AAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAA AAEAAAACAGIQDwAN8IQAAAAAAJ8PBAAAAAEAAAAAAKAPOAAAAFVT+1FkawRZFn+Rj81rSHKHZSxn N2gPXw0ALHuMTqd+DQAsewlOp34NACx721anfg0ALHuUTqd+AACiDx4AAAANAAAAAAAEAAAAAQAE AAAAAgAEAAAAAwAEAAAABAAAAKoPCgAAAB0AAAABAAAAAAAPAATw0AAAABIACvAIAAAABAQAAAAK AACDAAvwMAAAAH8AAQAFAIAAvG9iEIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAA CAAAEPAIAAAAXg8gAWAGihAPABHwEAAAAAAAwwsIAAAAAgAAAAcBYhAPAA3wWAAAAAAAnw8EAAAA BAAAAAAAoA8CAAAAKgAAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAA4AAAD4DwQAAAAAAAAAAACq DxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATw0gAAABIACvAIAAAABQQAAAAKAACDAAvwMAAAAH8A AQAFAIAArHZiEIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAXg+w B9AOihAPABHwEAAAAAAAwwsIAAAAAwAAAAkCYhAPAA3wWgAAAAAAnw8EAAAABAAAAAAAoA8CAAAA KgAAAKEPFgAAAAIAAAAAAAAIAAABAAIAAAAAAAIADgAAAPoPBAAAAAAAAAAAAKoPEgAAAAEAAAAB AAAAAAABAAAAAAAAAA8ABPDSAAAAEgAK8AgAAAAGBAAAAAoAAIMAC/AwAAAAfwABAAUAgADMeGIQ gQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyAQYBWKEA8AEfAQ AAAAAADDCwgAAAAEAAAACAJiEA8ADfBaAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAA AgAAAAAAAAgAAAIAAgAAAAAAAgAOAAAA2A8EAAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEAAAAA AAAADwAE8EgAAAASAArwCAAAAAEEAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69 aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZ AACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAA AADrLggAAAD388IBcDYtTyAAug8MAAAA2J6ki76LoYshan9nDwDuAxcLAAACAO8DGAAAAAEAAAAN DgAAAAAAAAAAAIAAAAAABwALMA8ADASHCgAADwAC8H8KAABAAAjwCAAAAA0AAABfGAAAEAAY8QQA AAABAAAADwAD8AsKAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABgA AAUAAAAPAAPwigYAAA8ABPA4AAAAAQAJ8BAAAACgAgAAoAsAANARAACAEAAAAgAK8AgAAABdGAAA AQIAAAAAEPAIAAAAsAEwA2ASkAYPAAPwvgEAAA8ABPBAAAAAAQAJ8BAAAACAAQAA4AEAAJAJAADN AgAAAgAK8AgAAABRGAAAAwIAAAAAD/AQAAAAoAIAABAOAACwCgAA/Q4AAA8ABPCtAAAAogwK8AgA AABNGAAAAgoAAIMAC/AwAAAAgADUxGIQvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEI AAgAAQICAAAIEwAi8QYAAAC/AQAAYAAAAA/wEAAAAIABAADgAQAA8AMAAM0CAAAPAA3wNwAAAAAA nw8EAAAABAAAAAAAqA8HAAAAUGVlciBJRAAAoQ8UAAAACAAAAAAAACAAADIACAAAAAAAAAAPAATw uQAAAKIMCvAIAAAAUBgAAAIKAACDAAvwMAAAAIAA8MhiEL8AAgACAIEBBAAACIMBAAAACL8BEAAQ AMABAQAACP8BCAAIAAECAgAACBMAIvEGAAAAvwEAAGAAAAAP8BAAAADwAwAA4AEAAJAJAADNAgAA DwAN8EMAAAAAAJ8PBAAAAAQAAAAAAKgPEwAAAEFzc29jaWF0ZWQgRmVhdHVyZXMAAKEPFAAAABQA AAAAAAAgAAAyABQAAAAAAAAADwAE8GAAAAByBQrwCAAAAFQYAAACCgAAgwAL8DAAAACFAAIAAACH AAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAAKALAABgDAAA AAwAAIAQAAAPAAPwzAEAAA8ABPBOAAAAAQAJ8BAAAACAAQAA4AEAAJAJAADNAgAAAgAK8AgAAABV GAAAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAACgAgAAEA4AALAKAAD9DgAADwAE8K0AAACiDArw CAAAAFYYAAACCgAAgwAL8DAAAACAAMw1yAe/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQgACAABAgIAAAgTACLxBgAAAL8BAABgAAAAD/AQAAAAgAEAAOABAADwAwAAzQIAAA8ADfA3AAAA AACfDwQAAAAEAAAAAACoDwcAAABQZWVyIElEAAChDxQAAAAIAAAAAAAAIAAAMgAIAAAAAAAAAA8A BPC5AAAAogwK8AgAAABXGAAAAgoAAIMAC/AwAAAAgACUz2IQvwACAAIAgQEEAAAIgwEAAAAIvwEQ ABAAwAEBAAAI/wEIAAgAAQICAAAIEwAi8QYAAAC/AQAAYAAAAA/wEAAAAPADAADgAQAAkAkAAM0C AAAPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8TAAAAQXNzb2NpYXRlZCBGZWF0dXJlcwAAoQ8UAAAA FAAAAAAAACAAADIAFAAAAAAAAAAPAATwvQAAAKIMCvAIAAAAWhgAAAIKAACTAAvwNgAAAIAAsNJi EL8AAgACAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACIgDAQAAABMAIvEGAAAA vwEAAGAAAAAP8BAAAACQDAAAoAsAANARAACNDAAADwAN8EEAAAAAAJ8PBAAAAAQAAAAAAKgPEQAA AFRyYW5zcG9ydCBBZGRyZXNzAAChDxQAAAASAAAAAAAAIAAAMgASAAAAAAAAAA8ABPC8AAAAogwK 8AgAAABbGAAAAgoAAIMAC/AwAAAAgABs1mIQvwACAAIAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIEwAi8QYAAAC/AQAAYAAAAA/wEAAAAJAMAACADQAA0BEAAG0OAAAPAA3wRgAA AAAAnw8EAAAABAAAAAAAqA8SAAAAU2VydmljZSBDYXBhYmlsaXR5AAChDxgAAAATAAAAAAAAIAAA MgATAAAAAAAEAMwzAP4PAATwtwAAAKIMCvAIAAAAXBgAAAIKAACDAAvwMAAAAIAA3M1iEL8AAgAC AIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACBMAIvEGAAAAvwEAAGAAAAAP8BAA AACQDAAAYA8AANARAABNEAAADwAN8EEAAAAAAJ8PBAAAAAQAAAAAAKgPEQAAAFByb2Nlc3Npbmcg U3RhdHVzAAChDxQAAAASAAAAAAAAIAAAMgASAAAAAAAAAA8ABPBBAwAAogwK8AgAAABfGAAAAAoA AIMAC/AwAAAAgABs3WIQvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI AAAQ8AgAAADwBiABABX1Dw8ADfDhAgAAAACfDwQAAAAEAAAAAACoD48CAABFYWNoIHBlZXIgTVVT VCBrbm93IGEgZmV3IG90aGVyIHBlZXJzIGluIHRoZSBzYW1lIG92ZXJsYXkgYW5kIHRoZXkgd29y ayB0b2dldGhlciB0byBwcm92aWRlIHVuaWZvcm0gcm91dGluZyBhbmQgc3RvcmFnZSBzZXJ2aWNl Lg0NVGhlIGluZm9ybWF0aW9uICBhYm91dCBvdGhlciBwZWVycyBtYXkgbG9vayBsaWtlIHdoYXQg dGhlIGFib3ZlIGZpZ3VyZSBzaG93OiBpbmRleGVkIGJ5IHRoZSBQZWVyIElEIGFuZCBzb21lIGFz c29jaWF0ZWQgZmVhdHVyZXMgdW5kZXIgdGhlIFBlZXIgSUQuICBJbiB0ZXJtIG9mIHNlcnZpY2Ug ZGlzY292ZXJ5LCB0aGUgZmVhdHVyZSBuYW1lZCBTZXJ2aWNlIENhcGFiaWxpdHkgbWF5IGhlbHAu DQ1TbyBlYWNoIHBlZXIgY291bGQgZ2V0IGl0cyBzZXJ2aWNlIGNhcGFiaWxpdGllcyBvbiBpdHMg b3duLCBmb3IgZXhhbXBsZSwgaXQgY291bGQgcHJvdmlkZSBTVFVOIG9yIFRVUk4gb3Igc29tZXRo aW5nIGVsc2UuIEl0IGNvdWxkIGRpc3RyaWJ1dGUgdGhlc2UgaW5mb3JtYXRpb24gYnkgdXNpbmcg b3ZlcmxheSBtYWludGVuYW5jZSBtZWNoYW5pc20gaW4gREhUIGFsZ29yaXRobSBhbmQga2VlcCBp dCBhY2N1cmF0ZSBieSB1c2luZyBrZWVwYWxpdmUgYmV0d2VlbiBpdCBhbmQgcGVlcnMgaW4gaXRz IHJvdXRpbmcgc3RhdGUuAAChDxQAAACQAgAAAAAAIAAAMgCQAgAAAAAAAAAAqg8aAAAAWwIAAAAA AAAJAAAAAQAAAAMALAAAAAAAAAAPAATwSAAAABIACvAIAAAAARgAAAAMAACDAAvwMAAAAIEBAAAA CIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAA AACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQ AFAAVAAxADAAAACLExAAAAAAAOsuCAAAAL8lyAEQ2dJ2DwDuA/oRAAACAO8DGAAAAAEAAAANDgAA AAAAAAAAAIAAAAAABwALMA8ADAQREQAADwAC8AkRAABQAAjwCAAAABsAAAAiHAAADwAD8KEQAAAP AATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABwAAAUAAAAPAAPwUgYAAA8A BPA4AAAAAQAJ8BAAAAAwAwAAQAIAAJASAAAADwAAAgAK8AgAAAARHAAAAQIAAAAAEPAIAAAAEAJw CMAVrw0PAATwbgAAADIACvAIAAAABBwAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMB AAAACL8BAAAQAMABAQAACP8BCAAIAAECAgAACBMAIvEGAAAAvwEAAGAAAAAP8BAAAADwAwAAQAIA AJASAADQDgAADwAD8F8BAAAPAATwTgAAAAEACfAQAAAAMAMAAEAIAADgBAAAkAkAAAIACvAIAAAA BRwAAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAMAMAAEAIAADgBAAAkAkAAA8ABPBgAAAAEgAK 8AgAAAAGHAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIAAAP8BAAAAAwAwAAQAgAAOAEAACQCQAADwAE8JkAAACiDArwCAAAAAccAAAC CgAAgwAL8DAAAACAAFyMlQe/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIA AAgAAA/wEAAAAJADAABwCAAArwQAAG4JAAAPAA3wMQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAQQAA oQ8UAAAAAgAAAAAAACAAADIAAgAAAAAAAAAPAAPwXwEAAA8ABPBOAAAAAQAJ8BAAAAAwAwAAQAgA AOAEAACQCQAAAgAK8AgAAAAIHAAAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAADgEAAAEAUAAJAS AABgBgAADwAE8GAAAAASAArwCAAAAAkcAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiD AQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAAA/wEAAAADADAABACAAA4AQAAJAJAAAPAATw mQAAAKIMCvAIAAAAChwAAAIKAACDAAvwMAAAAIAA5JBiEL8AAgACAIEBBAAACIMBAAAACL8BAAAQ AMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAAkAMAAHAIAACvBAAAbgkAAA8ADfAxAAAAAACfDwQA AAAEAAAAAACoDwEAAABCAAChDxQAAAACAAAAAAAAIAAAMgACAAAAAAAAAA8AA/BfAQAADwAE8E4A AAABAAnwEAAAADADAABACAAA4AQAAJAJAAACAArwCAAAAAscAAADAgAAEwAL8AYAAACIAwAAAAAA AA/wEAAAAOAQAAAQCwAAkBIAAGAMAAAPAATwYAAAABIACvAIAAAADBwAAAIKAACDAAvwMAAAAIUA AgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAMAMA AEAIAADgBAAAkAkAAA8ABPCZAAAAogwK8AgAAAANHAAAAgoAAIMAC/AwAAAAgAColGIQvwACAAIA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAACQAwAAcAgAAK8EAABu CQAADwAN8DEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAEMAAKEPFAAAAAIAAAAAAAAgAAAyAAIAAAAA AAAADwAD8F8BAAAPAATwTgAAAAEACfAQAAAAMAMAAEAIAADgBAAAkAkAAAIACvAIAAAADhwAAAMC AAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAIA0AALANAADQDgAAAA8AAA8ABPBgAAAAEgAK8AgAAAAP HAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgA AQICAAAIAAAP8BAAAAAwAwAAQAgAAOAEAACQCQAADwAE8JkAAACiDArwCAAAABAcAAACCgAAgwAL 8DAAAACAAHiZYhC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/w EAAAAJADAABwCAAArwQAAG4JAAAPAA3wMQAAAAAAnw8EAAAABAAAAAAAqA8BAAAARAAAoQ8UAAAA AgAAAAAAACAAADIAAgAAAAAAAAAPAATwWAAAAEIBCvAIAAAAFBwAAIAKAACDAAvwMAAAAEQBBAAA AH8BAAABAL8BAAAQAMABBQAACMsBn28AANEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAEAXwCUAU 4AcPAATwtAAAAEIBCvAIAAAAFRwAAAAKAADjAAvwVAAAAL8AAAAPAD8BAAAGAEQBBAAAAH8BAAAB AL8BAAAQAMABBQAACMsBn28AANEBAQAAAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPAIMAIvEwAAAAPwEAAEAA/wEAAIABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYG AA4AAAAQ8AgAAADQBQAVABUgCg8ABPC0AAAAQgEK8AgAAAAWHAAAQAoAAOMAC/BUAAAAvwAAAA8A PwEAAAYARAEEAAAAfwEAAAEAvwEAABAAwAEFAAAIywGfbwAA0QEBAAAA/wEeAB4AAQICAAAIPwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8AgwAi8TAAAAA/AQAAQAD/AQAAgAG/AwCCAIJ/BQYATgC/BQYA TgD/BQYATgA/BgYATgB/BgYADgAAABDwCAAAAOAKYBJAFJAMDwAE8FgAAABCAQrwCAAAABccAADA CgAAgwAL8DAAAABEAQQAAAB/AQAAAQC/AQAAEADAAcwzAADLAZ9vAADRAQEAAAD/ARgAGAABAgIA AAgAABDwCAAAAHAI8AkQEcAMDwAE8FIAAABCAQrwCAAAABgcAAAACgAAcwAL8CoAAABEAQQAAAB/ AQAAAQC/AQAAEADAAQUAAAjLAZ9vAAD/ARgAGAABAgIAAAgAABDwCAAAAHAOIApgDHAODwAE8JcA AACiDArwCAAAABkcAAAACgAAgwAL8DAAAACAANydYhC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADA AQEAAAj/AQAACAABAgIAAAgAABDwCAAAABAOIA3wD/cODwAN8DcAAAAAAJ8PBAAAAAQAAAAAAKgP BwAAAFJlcXVlc3QAAKEPFAAAAAgAAAAAAAAgAAAyAAgAAAAAAAAADwAE8FIAAABCAQrwCAAAABoc AAAACgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAcwzAADLAZ9vAAD/ARgAGAABAgIAAAgA ABDwCAAAAMAPIApgDMAPDwAE8JgAAACiDArwCAAAABscAAAACgAAgwAL8DAAAACAAACgYhC/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAADAPIA0gEBcQDwAN 8DgAAAAAAJ8PBAAAAAQAAAAAAKgPCAAAAFJlc3BvbnNlAAChDxQAAAAJAAAAAAAAIAAAMgAJAAAA AAAAAA8ABPCyAwAAogwK8AgAAAAeHAAAAAoAAIMAC/AwAAAAgAA8pGIQvwACAAIAgQEEAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABwAsAAQAhpFA8AEfBEAAAADwCIEzwA AAAPAIoTNAAAAAAAug8OAAAAXwBfAF8AUABQAFQAOQAAAIsTFgAAAAAArA8OAAAAAAAAAgEAAAAA AAAAAAAPAA3wBgMAAAAAnw8EAAAABAAAAAAAqA+aAgAASWYgdGhlcmUgaXMgYSByZXF1ZXN0IGZv ciBhIGtleSBzZW50IGJ5IFBlZXIgQSwgd2UgYXNzdW1lIHRoYXQgdGhlIGRlc3RpbmF0aW9uIG9m IHRoaXMgcmVxdWVzdCBpcyBQZWVyIEQgYW5kIGl0IHdpbGwgdHJhdmVyc2UgUGVlciBCIGFuZCBQ ZWVyIEMuDVRoZSBpZGVhIGZvciBzZXJ2aWNlIGRpc2NvdmVyeSBjb21lcyBmcm9tOiBtZXNzYWdl cyBpbiBQMlAgd2lsbCB0cmF2ZXJzZSBhIGZldyBwZWVycyBhbmQgdGhlc2UgcGVlcnMga25vdyBt b3JlIGluZm9ybWF0aW9uIGFib3V0IG90aGVyIHBlZXJzIGluIGl0cyByb3V0aW5nIHN0YXRlcy4N U28gaWYgYSBwZWVyIHdhbnQgdG8gZmluZCB3aGljaCBwZWVycyBjb3VsZCBwcm92aWRlIHdoaWNo IHR5cGUgb2Ygc2VydmljZSwgaXQgY291bGQgc2VuZHMgYSBtZXNzYWdlIHRvIHRoZSBvdmVybGF5 IGFuZCBjYXJyeSBpbmZvcm1hdGlvbiBieSB3aGljaCB0aGUgaW1tZWRpYXRlIHBlZXJzIGtub3cg d2hhdCBpdCB3YW50IGFuZCBjb2xsZWN0IGluZm9ybWF0aW9uIGl0IG5lZWRzLg1BcyB0aGUgZmln dXJlIG9uIHRoZSByaWdodCwgd2UgYXNzdW1lIFgsWSBhbmQgWiBjb3VsZCBwcm92aWRlIGEga2lu ZCBvZiBzZXJ2aWNlIHdoaWNoIEEgbmVlZHMuIEluIHRoZSBlbmQsIFggYW5kIFkgYW5kIFogYXJl IGxlYXJuZWQgYnkgQS4gAAChDxgAAACbAgAAAAABIAAAAQAyAJsCAAAAAAIAEAAAAKoPGgAAAIwC AAAAAAAADgAAAAEAAAAAAAEAAAAAAAAAAACmDw4AAAD4AAAA2AD4ARgDOARYBQ8ABPC+AAAAogwK 8AgAAAAfHAAAAAoAAJMAC/A2AAAABAAK6vH/gAAYs2IQvwACAAIAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABNBcEJkQ/hBg8ADfBYAAAAAACfDwQAAAAEAAAAAACo DyQAAABmaW5kIHBlZXJzIHdpdGggVFJVTiBzZXJ2aWNlIGZvciBtZT8AAKEPGAAAACUAAAAAAAAg AAAyACUAAAAAAAQAzDMA/g8ABPCsAAAAogwK8AgAAAAhHAAAAAoAAIMAC/AwAAAAgABMt2IQvwAC AAIAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIEwAi8QYAAAC/AQAAYAAAABDw CAAAAIAKUBCwE20LDwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKgPCgAAAFBlZXIgWCB8IFkAAKEPGAAA AAsAAAAAAAAgAAAyAAsAAAAAAAQAzDMA/g8ABPCwAAAAogwK8AgAAAAiHAAAAAoAAIMAC/AwAAAA gADYumIQvwACAAIAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIEwAi8QYAAAC/ AQAAYAAAABDwCAAAAJAJsAqgDn0KDwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFBlZXIgWCB8 IFkgfCBaAAChDxgAAAAPAAAAAAAAIAAAMgAPAAAAAAAEAMwzAP4PAATwSAAAABIACvAIAAAAARwA AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJ AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAMAlyAEg1b54AAAAKwQA AAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAADfEP////8SAAAADwA9 8Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAAAHIXGAAAAAEAIAAAAAAAnwQAAAQAIABnDgAAhhkA AAAA9Q8cAAAAAgEAAKQZAAMAAAAAiCsAAAEAAAAHAAAAAQD3dw8A6AOXBAAAAQDpAygAAACAFgAA 4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAH AAAACAAAAP7///8KAAAA/v////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAIA AAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a74AQAAtAEAABAAAAABAAAAiAAA AAMAAACQAAAADwAAAKgAAAAEAAAAtAAAAAYAAAC8AAAABwAAAMQAAAAIAAAAzAAAAAkAAADUAAAA CgAAANwAAAAXAAAA5AAAAAsAAADsAAAAEAAAAPQAAAATAAAA/AAAABYAAAAEAQAADQAAAAwBAAAM AAAAUgEAAAIAAACoAwAAHgAAABAAAADU2sbBxLvJz8/Uyr4AAAAAHgAAAAQAAAAAAAAAAwAAAFlH AAADAAAAGQAAAAMAAAACAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAAAAAAAwAAAGQfCwALAAAAAAAA AAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAFAAAABgAAAEFyaWFsAAUAAADLzszlAA0AAADE rMjPyei8xsSjsOUACQAAALvDtcbGrCAxAAkAAAC7w7XGxqwgMgAMEAAABgAAAB4AAAALAAAA0tHT w7XE19bM5QADAAAAAgAAAB4AAAARAAAA0d3Kvs7EuOXJ6LzGxKOw5QADAAAAAQAAAB4AAAALAAAA u8O1xsasserM4gADAAAAAgAAAAAAAEQAAAADAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAA AOCFn/L5T2gQq5EIACsns9kwAAAA/BsAAA0AAAABAAAAcAAAAAIAAAB4AAAABAAAAJgAAAAHAAAA pAAAAAgAAACwAAAACQAAAMgAAAASAAAA1AAAAAoAAAD0AAAACwAAAAABAAAMAAAADAEAAA0AAAAY AQAADwAAACQBAAARAAAALAEAAAIAAACoAwAAHgAAABgAAABQb3dlclBvaW50IFByZXNlbnRhdGlv bgAeAAAABAAAAAAAAAAeAAAABAAAAAAAAAAeAAAAEAAAAGppYW5neGluZ2ZlbmcAAAAeAAAABAAA ADE3NgAeAAAAGAAAAE1pY3Jvc29mdCBQb3dlclBvaW50AAAAAEAAAACQbHSOIwAAAEAAAAAAAAAA AAAAAEAAAAAAAAAAAAAAAEAAAABwbM2NMSfIAQMAAAAVAQAARwAAAMgaAAD/////AwAAAAgAiRBn DAAAAQAJAAADXA0AAAcAZwAAAAAABAAAAAMBCAAFAAAACwIAAAAABQAAAAwCeQChAAMAAAAeAAcA AAD8AgAA////AAAABAAAAC0BAAAIAAAA+gIFAAAAAAD///8ABAAAAC0BAQAOAAAAJAMFAP////// /3gAoAB4AKAA////////CAAAAPoCAAAAAAAAAAAAAAQAAAAtAQIABAAAAC0BAAAEAAAAJwH//wMA AAAeAAgAAAD6AgAAAQAAAAAAAAAEAAAALQEDAAcAAAD8AgEAAAAAAAAABAAAAC0BBAAMAAAAJAME ABYAHQAWACMAKAAjACgAHQAEAAAALQECAAQAAAAtAQAABAAAAPABAwAEAAAAJwH//xwAAAD7Avz/ AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAE AAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhIAAAAyCiIAGAAHAAAAUGVlciBJRCADAAIAAgABAAEA AQADAAQAAAAuAQAAHAAAAPsCEAAHAAAAAAC8AgAAAIYBAgIiU3lzdGVtAAAAAAAAAAAAABgAAAAB AAAA+DYVAOQEAAAEAAAALQEFAAQAAADwAQMAAwAAAB4ABwAAAPwCAAC74OMAAAAEAAAALQEDAAQA AAAtAQEADgAAACQDBQAoAB0AKAAjAFAAIwBQAB0AKAAdAAQAAAAtAQIABAAAAC0BAAAIAAAA+gIA AAEAAAAAAAAABAAAAC0BBgAEAAAALQEEAAwAAAAkAwQAKAAdACgAIwBQACMAUAAdAAQAAAAtAQIA BAAAAC0BAAAEAAAA8AEGAAQAAAAnAf//HAAAAPsC/P8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEGAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAAC JAAAADIKIgAqABMAAABBc3NvY2lhdGVkIEZlYXR1cmVzAAMAAgACAAIAAgABAAIAAQACAAIAAQAC AAMAAgABAAIAAQACAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQYAAwAAAB4ACAAAAPoCAAABAAAA AAAAAAQAAAAtAQYABAAAAC0BBAAqAAAAJQMTAFkAEQBYABEAWAASAFgAEgBYABMAWAAdAFcAHgBX AB8AVwAfAFYAIABXACAAVwAgAFcAIQBYACIAWAAsAFgALQBYAC4AWAAuAFkALgAEAAAALQECAAQA AAAtAQAABAAAAPABBgAEAAAAJwH//wMAAAAeAAgAAAD6AgAAAQAAAAAAAAAEAAAALQEGAAQAAAAt AQQADAAAACQDBAAWAB0AFgAjACgAIwAoAB0ABAAAAC0BAgAEAAAALQEAAAQAAADwAQYABAAAACcB //8cAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAQAAAAtAQYABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAISAAAAMgoiABgABwAAAFBlZXIgSUQg AwACAAIAAQABAAEAAwAEAAAALgEAAAQAAAAtAQUABAAAAPABBgADAAAAHgAEAAAALQEDAAQAAAAt AQEADgAAACQDBQAoAB0AKAAjAFAAIwBQAB0AKAAdAAQAAAAtAQIABAAAAC0BAAAIAAAA+gIAAAEA AAAAAAAABAAAAC0BBgAEAAAALQEEAAwAAAAkAwQAKAAdACgAIwBQACMAUAAdAAQAAAAtAQIABAAA AC0BAAAEAAAA8AEGAAQAAAAnAf//HAAAAPsC/P8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEGAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACJAAA ADIKIgAqABMAAABBc3NvY2lhdGVkIEZlYXR1cmVzAAMAAgACAAIAAgABAAIAAQACAAIAAQACAAMA AgABAAIAAQACAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQYAAwAAAB4ABAAAAC0BAwAEAAAALQEB AA4AAAAkAwUAXQAMAF0AEgCCABIAggAMAF0ADAAEAAAALQECAAQAAAAtAQAACAAAAPoCAAABAAAA AAAAAAQAAAAtAQYABAAAAC0BBAAMAAAAJAMEAF0ADABdABIAggASAIIADAAEAAAALQECAAQAAAAt AQAABAAAAPABBgAEAAAAJwH//xwAAAD7Avz/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBgAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAiEAAAAy ChEAXwARAAAAVHJhbnNwb3J0IEFkZHJlc3NlAgABAAIAAgACAAMAAgABAAEAAQADAAIAAwABAAIA AgACAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEGAAMAAAAeAAQAAAAtAQMABAAAAC0BAQAOAAAAJAMF AF0AGQBdAB8AggAfAIIAGQBdABkABAAAAC0BAgAEAAAALQEAAAgAAAD6AgAAAQAAAAAAAAAEAAAA LQEGAAQAAAAtAQQADAAAACQDBABdABkAXQAfAIIAHwCCABkABAAAAC0BAgAEAAAALQEAAAQAAADw AQYABAAAACcB//8cAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAQAAAAtAQYABAAAAC4BGAAEAAAAAgEBAAUAAAAJAswzAAIiAAAAMgoeAF8AEgAA AFNlcnZpY2UgQ2FwYWJpbGl0eQMAAgABAAIAAQACAAIAAQADAAIAAgACAAIAAQABAAEAAQACAAQA AAAuAQAABAAAAC0BBQAEAAAA8AEGAAMAAAAeAAQAAAAtAQMABAAAAC0BAQAOAAAAJAMFAF0AJgBd AC0AggAtAIIAJgBdACYABAAAAC0BAgAEAAAALQEAAAgAAAD6AgAAAQAAAAAAAAAEAAAALQEGAAQA AAAtAQQADAAAACQDBABdACYAXQAtAIIALQCCACYABAAAAC0BAgAEAAAALQEAAAQAAADwAQYABAAA ACcB//8cAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQYABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIhAAAAMgorAF8AEQAAAFByb2Nl c3NpbmcgU3RhdHVzeQMAAQACAAIAAgACAAIAAQACAAIAAQADAAEAAgABAAIAAgAEAAAALgEAAAQA AAAtAQUABAAAAPABBgAcAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQAAAAtAQYABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAJnAAAAMgo2AAoA QAAAAEVhY2ggcGVlciBNVVNUIGtub3cgYSBmZXcgb3RoZXIgcGVlcnMgaW4gdGhlIHNhbWUgb3Zl cmxheSBhbmQgdGgDAAIAAgACAAEAAgACAAIAAQACAAMAAwADAAIAAQACAAIAAgADAAEAAwABAAEA AgADAAEAAgABAAMAAgABAAEAAwACAAIAAQACAAEAAQACAAIAAQACAAIAAQACAAMAAwACAAEAAgAC AAMAAQABAAIAAgABAAIAAwACAAEAAQACAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEGABwAAAD7Avz/ AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBgAE AAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhMAAAAyCjYAggAIAAAAZXkgd29yayACAAIAAQAEAAIA AQACAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQYAHAAAAPsC/P8AAAAAAACQAQAAAAAAQAAAQXJp YWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEGAAQAAAAuARgABAAAAAIBAQAFAAAA CQIAAAACWwAAADIKOwAKADgAAAB0b2dldGhlciB0byBwcm92aWRlIHVuaWZvcm0gcm91dGluZyBh bmQgc3RvcmFnZSBzZXJ2aWNlLgEAAgACAAIAAQACAAMAAQABAAEAAgABAAMAAQACAAIAAQACAAIA AgACAAIAAQABAAIAAgADAAEAAQADAAIAAQABAAIAAgABAAMAAgACAAEAAgABAAMAAQACAAIAAgAB AAMAAgABAAIAAQACAAIAAQAEAAAALgEAAAQAAAAtAQUABAAAAPABBgAcAAAA+wL8/wAAAAAAAJAB AAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQYABAAAAC4BGAAE AAAAAgEBAAUAAAAJAgAAAAJnAAAAMgpJAAoAQAAAAFRoZSBpbmZvcm1hdGlvbiAgYWJvdXQgb3Ro ZXIgcGVlcnMgbWF5IGxvb2sgbGlrZSB3aGF0IHRoZSBhYm92ZSACAAIAAgABAAEAAgABAAMAAQAD AAIAAQACAAIAAgABAAEAAgADAAIAAgABAAEAAgACAAIAAgABAAIAAgACAAIAAQACAAIAAwACAAIA AQABAAIAAgADAAEAAQABAAIAAgABAAMAAgACAAEAAQACAAIAAgABAAIAAwACAAIAAgABAAQAAAAu AQAABAAAAC0BBQAEAAAA8AEGABwAAAD7Avz/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBgAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhsAAAAy CkkAfAANAAAAZmlndXJlIHNob3c6IAMBAAEAAgADAAEAAgABAAIAAgACAAMAAgACAAQAAAAuAQAA BAAAAC0BBQAEAAAA8AEGABwAAAD7Avz/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABAAAAC0BBgAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAmcAAAAyCk4A CgBAAAAAaW5kZXhlZCBieSB0aGUgUGVlciBJRCBhbmQgc29tZSBhc3NvY2lhdGVkIGZlYXR1cmVz IHVuZGVyIHRoZSBQZQEAAgACAAIAAgACAAIAAQACAAIAAgABAAIAAgABAAMAAgADAAEAAQABAAMA AQACAAIAAwABAAIAAgADAAIAAgACAAIAAgACAAIAAQACAAEAAwACAAEAAQACAAIAAgACAAEAAgAC AAEAAwACAAIAAgACAAEAAQACAAIAAQADAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQYAHAAAAPsC /P8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEG AAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACGAAAADIKTgCAAAsAAABlciBJRC4gIEluIDoDAAEA AQABAAMAAQABAAEAAQADAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQYAHAAAAPsC/P8AAAAAAACQ AQAAAAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEGAAQAAAAuARgA BAAAAAIBAQAFAAAACQIAAAACZwAAADIKUwAKAEAAAAB0ZXJtIG9mIHNlcnZpY2UgZGlzY292ZXJ5 LCB0aGUgZmVhdHVyZSBuYW1lZCBTZXJ2aWNlIENhcGFiaWxpdHkgAQACAAEAAwABAAIAAgABAAIA AgABAAIAAQACAAIAAgACAAEAAgACAAIAAgACAAEAAgABAAIAAQACAAIAAQABAAMAAgABAAIAAgAC AAEAAgACAAQAAgACAAEAAwACAAEAAgABAAIAAgABAAQAAgACAAIAAgABAAEAAQABAAIAAQAEAAAA LgEAAAQAAAAtAQUABAAAAPABBgAcAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQYABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIVAAAA MgpTAHoACQAAAG1heSBoZWxwLm4EAAIAAgABAAIAAgABAAIAAQAEAAAALgEAAAQAAAAtAQUABAAA APABBgAcAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAQAAAAtAQYABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAJnAAAAMgphAAoAQAAAAFNvIGVh Y2ggcGVlciBjb3VsZCBnZXQgaXRzIHNlcnZpY2UgY2FwYWJpbGl0aWVzIG9uIGl0cyBvd24sIGZv ciADAAIAAQACAAIAAgACAAEAAgACAAMAAQABAAIAAgACAAEAAwABAAIAAgABAAEAAQABAAIAAQAD AAIAAQACAAEAAgACAAEAAgADAAIAAgACAAEAAQABAAEAAQACAAIAAQACAAMAAQABAAEAAgABAAIA AwACAAEAAQACAAIAAQABAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEGABwAAAD7Avz/AAAAAAAAkAEA AAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBgAEAAAALgEYAAQA AAACAQEABQAAAAkCAAAAAiIAAAAyCmEAdQASAAAAZXhhbXBsZSwgaXQgY291bGQgAgACAAMAAwAC AAEAAgABAAEAAQABAAEAAwACAAIAAQACAAIABAAAAC4BAAAEAAAALQEFAAQAAADwAQYAHAAAAPsC /P8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEG AAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACZwAAADIKZgAKAEAAAABwcm92aWRlIFNUVU4gb3Ig VFVSTiBvciBzb21ldGhpbmcgZWxzZS4gSXQgY291bGQgZGlzdHJpYnV0ZSB0aGVzAgABAAIAAgAB AAIAAgABAAMAAgADAAMAAQADAAEAAQACAAMAAwADAAEAAwABAAEAAgACAAQAAgABAAIAAQACAAIA AgACAAEAAgACAAEAAQABAAEAAQACAAMAAgABAAIAAQACAAEAAgABAAEAAgACAAIAAQACAAEAAgAC AAIAAgAEAAAALgEAAAQAAAAtAQUABAAAAPABBgAcAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlh bAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQYABAAAAC4BGAAEAAAAAgEBAAUAAAAJ AgAAAAIKAAAAMgpmAH0AAgAAAGUgAgACAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEGABwAAAD7Avz/ AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBgAE AAAALgEYAAQAAAACAQEABQAAAAkCAAAAAmcAAAAyCmsACgBAAAAAaW5mb3JtYXRpb24gYnkgdXNp bmcgb3ZlcmxheSBtYWludGVuYW5jZSBtZWNoYW5pc20gaW4gREhUIGFsZ29yaQEAAgABAAIAAQAD AAIAAQACAAIAAgABAAIAAgABAAIAAgACAAIAAgABAAIAAgADAAEAAQACAAIAAQADAAIAAgACAAEA AgACAAMAAgACAAIAAQADAAIAAwACAAIAAgABAAIAAwABAAIAAgABAAMAAwACAAEAAgABAAMAAgAB AAEABAAAAC4BAAAEAAAALQEFAAQAAADwAQYAHAAAAPsC/P8AAAAAAACQAQAAAAAAQAAAQXJpYWwA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEGAAQAAAAuARgABAAAAAIBAQAFAAAACQIA AAACEwAAADIKawCBAAgAAAB0aG0gYW5kIAEAAgAEAAEAAgACAAIAAgAEAAAALgEAAAQAAAAtAQUA BAAAAPABBgAcAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAQAAAAtAQYABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIuAAAAMgpwAAoAGgAAAGtl ZXAgaXQgYWNjdXJhdGUgYnkgdXNpbmcgAgACAAIAAgABAAEAAQABAAIAAgACAAMAAQACAAEAAgAC AAIAAgABAAIAAgABAAIAAgABAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEGABwAAAD7Avz/AAAAAAAA kAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBgAEAAAALgEY AAQAAAACAQEABQAAAAkCAAAAAhUAAAAyCnAANgAJAAAAa2VlcGFsaXZlbgMAAgACAAIAAgABAAEA AgACAAQAAAAuAQAABAAAAC0BBQAEAAAA8AEGABwAAAD7Avz/AAAAAAAAkAEAAAAAAEAAAEFyaWFs AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BBgAEAAAALgEYAAQAAAACAQEABQAAAAkC AAAAAkYAAAAyCnAASQAqAAAAYmV0d2VlbiBpdCBhbmQgcGVlcnMgaW4gaXRzIHJvdXRpbmcgc3Rh dGUuAgACAAEAAwACAAIAAwABAAEAAQABAAIAAgACAAIAAgACAAIAAQADAAEAAQACAAEAAQABAAIA AQABAAMAAgABAAEAAgACAAEAAgACAAIAAQACAAEABAAAAC4BAAAEAAAALQEFAAQAAADwAQYAAwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAACAAAAABAAAANAAAAAIAAAA8AAAAAQAAAAIAAAAIAAAAVmVyc2lv bgACAAAAqAMAAAMAAAABAAAAAAAAAAAA9g8lAAAAFAAAAF/AkeM1RwAADQD0AwMAEwBqaWFuZ3hp bmdmZW5nCAAAAGoAaQBhAG4AZwB4AGkAbgBnAGYAZQBuAGcAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAkAAABHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEPAPIDYAEAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB5gAAAAAALcP RAAAAEEAcgBpAGEAbAAAANSDEwBfPgsw1IMTAAAAAAAwANIPbJYTAGyWEwAgMGIQ9IMTAHg6CzD0 gxMAAAAAAA8A1QcAAAQAEAC3D0QAAACLW1NPAABhAGwAAADUgxMAXz4LMNSDEwAAAAAAMADSD2yW EwBslhMAIDBiEPSDEwB4Ogsw9IMTAAAAAAAPANUHhgAEAgAApA8IAAAAgABAAAAAAAAAAKUPDAAA AAAAAAguAAAABwAAAAAAqQ8KAAAABwAAAAIABAgJBEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/ AABkAAAAAAAAAAAAQAIAAAAABwAAAP//7wAAAAAAAQAAAP//EgAAAAABAAAABQAAIAEgAQAAAAAA BQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsExAAAAA8AAPC8AAAAAAAG8FgA AAAEJAAACgAAAC4AAAADAAAAAQAAAAcAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAQAAABgAAAABQAAACMAAAAAAAAAGwAAAAAAAAAEAAAAgwAL8DAAAACBAQQAAAiDAQAAAAiGQQAA AAC/ARAAEADAAQEAAAjFQQAAAAD/AQgACAABAgIAAAgQABrxBAAAAMwzAABAAB7xEAAAAAQAAAjM MwAAAgAACPcAABAfAPAPHAAAAAAA8wMUAAAAAgAAAAAAAAAAAAAAAAAAgAAAAAAPANAHMwEAAB8A FAQcAAAAAAAVBBQAAAC6k7D2AMqaO60HlMcAypo7AQEAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0D NAAAAEYAAABkAAAARgAAAGQAAAAAAAAAxDJiEAyEEwB4OgswAAAAAAAAAAA+/v//rP///wEAEwBw APsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIA AAAfABMEPAAAAAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAAAIAAAA4hBMA/PgKMGyWEwAAAAAAAAAA AAAAAAAAAAAAAAATAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsT EAAAAAAADQQIAAAAAMAAAADAAAA/ANkPDAAAAAAA2g8EAAAADQAlAA8A8A+wAAAAAADzAxQAAAAE AAAABAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqg8KAAAAAQAAAAEAAAAAABAAnw8EAAAA AQAAAAAAqg8KAAAAAQAAAAEAAAAAAAAA8wMUAAAABQAAAAQAAAACAAAAAgEAAAAAAAAAAJ8PBAAA AAAAAAAAAKoPCgAAAAEAAAABAAAAAAAQAJ8PBAAAAAEAAAAAAKoPCgAAAAEAAAABAAAAAAAAAOoD AAAAAA8A7gPXEQAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACAAAAAAAcACzAPAAwE7hAAAA8AAvDm EAAAUAAI8AgAAAAbAAAAIhwAAA8AA/B+EAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAAAcAAAFAAAADwAD8FIGAAAPAATwOAAAAAEACfAQAAAAMAMAAEACAACQEgAAAA8A AAIACvAIAAAAERwAAAECAAAAABDwCAAAABACcAjAFa8NDwAE8G4AAAAyAArwCAAAAAQcAAACCgAA gwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQgACAABAgIAAAgT ACLxBgAAAL8BAABgAAAAD/AQAAAA8AMAAEACAACQEgAA0A4AAA8AA/BfAQAADwAE8E4AAAABAAnw EAAAADADAABACAAA4AQAAJAJAAACAArwCAAAAAUcAAADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAA ADADAABACAAA4AQAAJAJAAAPAATwYAAAABIACvAIAAAABhwAAAIKAACDAAvwMAAAAIUAAgAAAIcA AQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAMAMAAEAIAADg BAAAkAkAAA8ABPCZAAAAogwK8AgAAAAHHAAAAgoAAIMAC/AwAAAAgABcjJUHvwACAAIAgQEEAAAI gwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAACQAwAAcAgAAK8EAABuCQAADwAN 8DEAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAEEAAKEPFAAAAAIAAAAAAAAgAAAyAAIAAAAAAAAADwAD 8F8BAAAPAATwTgAAAAEACfAQAAAAMAMAAEAIAADgBAAAkAkAAAIACvAIAAAACBwAAAMCAAATAAvw BgAAAIgDAAAAAAAAD/AQAAAA4BAAABAFAACQEgAAYAYAAA8ABPBgAAAAEgAK8AgAAAAJHAAAAgoA AIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAI AAAP8BAAAAAwAwAAQAgAAOAEAACQCQAADwAE8JkAAACiDArwCAAAAAocAAACCgAAgwAL8DAAAACA AOSQYhC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAAJAD AABwCAAArwQAAG4JAAAPAA3wMQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAQgAAoQ8UAAAAAgAAAAAA ACAAADIAAgAAAAAAAAAPAAPwXwEAAA8ABPBOAAAAAQAJ8BAAAAAwAwAAQAgAAOAEAACQCQAAAgAK 8AgAAAALHAAAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAADgEAAAEAsAAJASAABgDAAADwAE8GAA AAASAArwCAAAAAwcAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADA AQEAAAj/AQgACAABAgIAAAgAAA/wEAAAADADAABACAAA4AQAAJAJAAAPAATwmQAAAKIMCvAIAAAA DRwAAAIKAACDAAvwMAAAAIAAqJRiEL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAI AAECAgAACAAAD/AQAAAAkAMAAHAIAACvBAAAbgkAAA8ADfAxAAAAAACfDwQAAAAEAAAAAACoDwEA AABDAAChDxQAAAACAAAAAAAAIAAAMgACAAAAAAAAAA8AA/BfAQAADwAE8E4AAAABAAnwEAAAADAD AABACAAA4AQAAJAJAAACAArwCAAAAA4cAAADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAACANAACw DQAA0A4AAAAPAAAPAATwYAAAABIACvAIAAAADxwAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEB BAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAD/AQAAAAMAMAAEAIAADgBAAAkAkA AA8ABPCZAAAAogwK8AgAAAAQHAAAAgoAAIMAC/AwAAAAgAB4mWIQvwACAAIAgQEEAAAIgwEAAAAI vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAACQAwAAcAgAAK8EAABuCQAADwAN8DEAAAAA AJ8PBAAAAAQAAAAAAKgPAQAAAEQAAKEPFAAAAAIAAAAAAAAgAAAyAAIAAAAAAAAADwAE8FgAAABC AQrwCAAAABQcAACACgAAgwAL8DAAAABEAQQAAAB/AQAAAQC/AQAAEADAAQUAAAjLAZ9vAADRAQEA AAD/ARgAGAABAgIAAAgAABDwCAAAABAF8AlAFOAHDwAE8LQAAABCAQrwCAAAABUcAAAACgAA4wAL 8FQAAAC/AAAADwA/AQAABgBEAQQAAAB/AQAAAQC/AQAAEADAAQUAAAjLAZ9vAADRAQEAAAD/AR4A HgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCDACLxMAAAAD8BAABAAP8BAACAAb8DAIIA gn8FBgBOAL8FBgBOAP8FBgBOAD8GBgBOAH8GBgAOAAAAEPAIAAAA0AUAFQAVIAoPAATwtAAAAEIB CvAIAAAAFhwAAEAKAADjAAvwVAAAAL8AAAAPAD8BAAAGAEQBBAAAAH8BAAABAL8BAAAQAMABBQAA CMsBn28AANEBAQAAAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIMAIvEwAAAA PwEAAEAA/wEAAIABvwMAggCCfwUGAE4AvwUGAE4A/wUGAE4APwYGAE4AfwYGAA4AAAAQ8AgAAADg CmASQBSQDA8ABPBYAAAAQgEK8AgAAAAXHAAAwAoAAIMAC/AwAAAARAEEAAAAfwEAAAEAvwEAABAA wAHMMwAAywGfbwAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAABwCPAJEBHADA8ABPBSAAAAQgEK 8AgAAAAYHAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEAABAAwAEFAAAIywGfbwAA/wEYABgA AQICAAAIAAAQ8AgAAABwDiAKYAxwDg8ABPCXAAAAogwK8AgAAAAZHAAAAAoAAIMAC/AwAAAAgADc nWIQvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAQDiAN 8A/3Dg8ADfA3AAAAAACfDwQAAAAEAAAAAACoDwcAAABSZXF1ZXN0AAChDxQAAAAIAAAAAAAAIAAA MgAIAAAAAAAAAA8ABPBSAAAAQgEK8AgAAAAaHAAAAAoAAHMAC/AqAAAARAEEAAAAfwEAAAEAvwEA ABAAwAHMMwAAywGfbwAA/wEYABgAAQICAAAIAAAQ8AgAAADADyAKYAzADw8ABPCYAAAAogwK8AgA AAAbHAAAAAoAAIMAC/AwAAAAgAAAoGIQvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEA AAgAAQICAAAIAAAQ8AgAAAAwDyANIBAXEA8ADfA4AAAAAACfDwQAAAAEAAAAAACoDwgAAABSZXNw b25zZQAAoQ8UAAAACQAAAAAAACAAADIACQAAAAAAAAAPAATwjwMAAKIMCvAIAAAAHhwAAAAKAACD AAvwMAAAAIAAPKRiEL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAA EPAIAAAAcALAAEAIAxAPABHwRAAAAA8AiBM8AAAADwCKEzQAAAAAALoPDgAAAF8AXwBfAFAAUABU ADkAAACLExYAAAAAAKwPDgAAAAAAAAIBAAAAAAAAAAAADwAN8OMCAAAAAJ8PBAAAAAQAAAAAAKgP mQIAAElmIHRoZXJlIGlzIGEgcmVxdWVzdCBmb3IgYSBrZXkgc2VudCBieSBQZWVyIEEsIHdlIGFz c3VtZSB0aGF0IHRoZSBkZXN0aW5hdGlvbiBvZiB0aGlzIHJlcXVlc3QgaXMgUGVlciBEIGFuZCBp dCB3aWxsIHRyYXZlcnNlIFBlZXIgQiBhbmQgUGVlciBDLg1UaGUgaWRlYSBmb3Igc2VydmljZSBk aXNjb3ZlcnkgY29tZXMgZnJvbTogbWVzc2FnZXMgaW4gUDJQIHdpbGwgdHJhdmVyc2UgYSBmZXcg cGVlcnMgYW5kIHRoZXNlIHBlZXJzIGtub3cgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBvdGhlciBw ZWVycyBpbiBpdHMgcm91dGluZyBzdGF0ZXMuDVNvIGlmIGEgcGVlciB3YW50IHRvIGZpbmQgd2hp Y2ggcGVlcnMgY291bGQgcHJvdmlkZSB3aGljaCB0eXBlIG9mIHNlcnZpY2UsIGl0IGNvdWxkIHNl bmRzIGEgbWVzc2FnZSB0byB0aGUgb3ZlcmxheSBhbmQgY2FycnkgaW5mb3JtYXRpb24gYnkgd2hp Y2ggdGhlIGltbWVkaWF0ZSBwZWVycyBrbm93IHdoYXQgaXQgd2FudCBhbmQgY29sbGVjdCBpbmZv cm1hdGlvbiBpdCBuZWVkcy4NQXMgdGhlIGZpZ3VyZSBvbiB0aGUgcmlnaHQsIHdlIGFzc3VtZSBY LFkgYW5kIFogY291bGQgcHJvdmlkZSBhIGtpbmQgb2Ygc2VydmljZSB3aGljaCBBIG5lZWRzLiBJ biB0aGUgZW5kLCBYIGFuZCBZIGFuZCBaIGFyZSBsZWFybmVkIGJ5IEEuAAChDxgAAACaAgAAAAAB IAAAAQAyAJoCAAAAAAIADgAAAKYPDgAAAPgAAADYAPgBGAM4BFgFDwAE8L4AAACiDArwCAAAAB8c AAAACgAAkwAL8DYAAAAEAArq8f+AABizYhC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAgAABDwCAAAAE0FwQmRD+EGDwAN8FgAAAAAAJ8PBAAAAAQAAAAAAKgPJAAAAGZp bmQgcGVlcnMgd2l0aCBUUlVOIHNlcnZpY2UgZm9yIG1lPwAAoQ8YAAAAJQAAAAAAACAAADIAJQAA AAAABADMMwD+DwAE8KwAAACiDArwCAAAACEcAAAACgAAgwAL8DAAAACAAEy3YhC/AAIAAgCBAQQA AAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgTACLxBgAAAL8BAABgAAAAEPAIAAAAgApQ ELATbQsPAA3wPgAAAAAAnw8EAAAABAAAAAAAqA8KAAAAUGVlciBYIHwgWQAAoQ8YAAAACwAAAAAA ACAAADIACwAAAAAABADMMwD+DwAE8LAAAACiDArwCAAAACIcAAAACgAAgwAL8DAAAACAANi6YhC/ AAIAAgCBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgTACLxBgAAAL8BAABgAAAA EPAIAAAAkAmwCqAOfQoPAA3wQgAAAAAAnw8EAAAABAAAAAAAqA8OAAAAUGVlciBYIHwgWSB8IFoA AKEPGAAAAA8AAAAAAAAgAAAyAA8AAAAAAAQAzDMA/g8ABPBIAAAAEgAK8AgAAAABHAAAAAwAAIMA C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBORAAAADwCKE4kAAAAAALoP EAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAAwCXIASDVvngAAAArBAAAAAAAAAAf AETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAN8Q/////xIAAAAPAD3xDQAAAEAB QvEFAAAAAQkAAAAPAAIrAAAAAAAAchcQAAAAAQAQAMwrAAAFABAAazAAAAAA9Q8cAAAAAgEAAKQZ AAOoKwAASkIAAAEAAAAHAAAAAQD3dw8A6AOXBAAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAA AAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyA2ABAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QeYAAAA AAC3D0QAAABBAHIAaQBhAGwAAADUgxMAXz4LMNSDEwAAAAAAMADSD2yWEwBslhMAIDBiEPSDEwB4 Ogsw9IMTAAAAAAAPANUHAAAEABAAtw9EAAAAi1tTTwAAYQBsAAAA1IMTAF8+CzDUgxMAAAAAADAA 0g9slhMAbJYTACAwYhD0gxMAeDoLMPSDEwAAAAAADwDVB4YABAIAAKQPCAAAAIAAQAAAAAAAAACl DwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAQICQRAAKMPbgAAAAUA//0/AAAAIiAAAGQA AAAA/wAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAAEAAAD//xIAAAAAAQAAAAUAACABIAEA AAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBMQAAAAPAADwvAAAAAAA BvBYAAAABCQAAAoAAAAuAAAAAwAAAAEAAAAHAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AAQAAAAEAAAAYAAAAAUAAAAjAAAAAAAAABsAAAAAAAAABAAAAIMAC/AwAAAAgQEEAAAIgwEAAAAI hkEAAAAAvwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIEAAa8QQAAADMMwAAQAAe8RAAAAAE AAAIzDMAAAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQBzMB AAAfABQEHAAAAAAAFQQUAAAAupOw9gDKmjutB5THAMqaOwEBAAAPAPoDZwAAAAAA/gMDAAAAAAEA AAD9AzQAAABGAAAAZAAAAEYAAABkAAAAAAAAAMQyYhAMhBMAeDoLMAAAAAAAAAAAPv7//6z///8B ABMAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAA AAACAAAAHwATBDwAAAAAAP0DNAAAAGQAAABkAAAAZAAAAGQAAAACAAAAOIQTAPz4CjBslhMAAAAA AAAAAAAAAAAAAAAAAAAAEwAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAA AACLExAAAAAAAA0ECAAAAADAAAAAwAAAPwDZDwwAAAAAANoPBAAAAA0AJQAPAPAPsAAAAAAA8wMU AAAABAAAAAQAAAACAAAAAQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKoPCgAAAAEAAAABAAAAAAAQAJ8P BAAAAAEAAAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAAUAAAAEAAAAAgAAAAIBAAAAAAAAAACf DwQAAAAAAAAAAACqDwoAAAABAAAAAQAAAAAAEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAA AADqAwAAAAAAAHIXCAAAAAEAEACGQgAAAAD1DxwAAAACAQAApBkAA2JCAAAlRwAAAQAAAAcAAAAB APd3AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABS AG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAFgAFAP//////////AQAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAAAQ9sHYMSfI ATsAAADAAgAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAMAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAgAAAFlHAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEA dABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEEAAAA//////////8AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAAALBwAAAAAAAAFAEQAbwBjAHUAbQBlAG4A dABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAOAACAf////// /////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8AgAAAAAAAP// ////////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAA ABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAKwAAAP7/////////GwAAABwAAAAdAAAA HgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAD+//////////7///8s AAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAA/v///yoA AAD9////PAAAAP7///////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////v8A AAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgA Kyz5rvgBAAC0AQAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAAC0AAAABgAAALwAAAAH AAAAxAAAAAgAAADMAAAACQAAANQAAAAKAAAA3AAAABcAAADkAAAACwAAAOwAAAAQAAAA9AAAABMA AAD8AAAAFgAAAAQBAAANAAAADAEAAAwAAABSAQAAAgAAAKgDAAAeAAAAEAAAANTaxsHEu8nPz9TK vgAAAAAeAAAABAAAAAAAAAADAAAAWUcAAAMAAAAZAAAAAwAAAAIAAAADAAAAAAAAAAMAAAAAAAAA AwAAAAAAAAADAAAAZB8LAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAUAAAAG AAAAQXJpYWwABQAAAMvOzOUADQAAAMSsyM/J6LzGxKOw5QAJAAAAu8O1xsasIDEACQAAALvDtcbG rCAyAAwQAAAGAAAAHgAAAAsAAADS0dPDtcTX1szlAAMAAAACAAAAHgAAABEAAADR3cq+zsS45cno vMbEo7DlAAMAAAABAAAAHgAAAAsAAAC7w7XGxqyx6sziAAMAAAACAAAAAAAARAAAAAMAAAAAAAAA IAAAAAEAAAA0AAAAAgAAADwAAAABAAAAAgAAAAgAAABWZXJzaW9uAAIAAACoAwAAAwAAAAEAAAAA AAAAAAD2DyUAAAAUAAAAX8CR4zVHAAANAPQDAwATAGppYW5neGluZ2ZlbmcIAAAAagBpAGEAbgBn AHgAaQBuAGcAZgBlAG4AZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --Boundary_(ID_6Z5zMc8rsEiHLb+rPH/s5w) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --Boundary_(ID_6Z5zMc8rsEiHLb+rPH/s5w)-- From p2psip-bounces@ietf.org Thu Nov 15 07:47:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ise85-0001oa-Sb; Thu, 15 Nov 2007 07:47:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ise84-0001oS-LO for p2psip@ietf.org; Thu, 15 Nov 2007 07:47:32 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ise84-0001V3-9w for p2psip@ietf.org; Thu, 15 Nov 2007 07:47:32 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Ise82-00030g-1r; Thu, 15 Nov 2007 07:47:30 -0500 In-Reply-To: <00e501c8272a$905b2060$5105a40a@china.huawei.com> References: <00e501c8272a$905b2060$5105a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Thu, 15 Nov 2007 07:48:41 -0500 To: Zheng Hewen X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'Henry Sinnreich' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 14-Nov-07, at 20:55 , Zheng Hewen wrote: > Hi, > > In Reference model defined in the Concept document, there are > mainly two types of nodes: peers and clients with SIP UA. > Further, there are two types of peers: peers with some SIP entity > and peers without any SIP entity. > But from the contribution to P2PSIP overlay network, we can > think that there are mainly three types of nodes: peers > (participating in overlay, contributing storage capacity), clients > (only contributing storage capacity to their associated > peers) and ordinary SIP UAs (without any contribution), is my > understanding correct? Right now, the reference model identifies three types of nodes: (a) peers, (b) clients, and (c) SIP UAs that attach via an proxy. > Certainly, ordinary SIP UAs usually are regarded as P2PSIP > clients, and essentially SIP usually is regarded one type of > service over P2PSIP overlay layer. This is not actually true. Right now, the concepts draft says that defines the client protocol as something OTHER than SIP, in order to distinguish (b) and (c) above. > I think that we need update the Section 5.3 if we reach the > agreement about P2PSIP client character according to the > Reference model, any comment? Yes. Once we reach agreement on what a client should be, a number of sections in the Concepts draft will be to be rewritten. I am still waiting for that agreement. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 07:58:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IseIy-00055N-NE; Thu, 15 Nov 2007 07:58:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IseIx-00054m-RW for p2psip@ietf.org; Thu, 15 Nov 2007 07:58:47 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IseIx-0001uD-HO for p2psip@ietf.org; Thu, 15 Nov 2007 07:58:47 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IseIx-0002Af-0l for p2psip@ietf.org; Thu, 15 Nov 2007 07:58:47 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: P2PSIP Mailing List From: Philip Matthews Date: Thu, 15 Nov 2007 07:59:59 -0500 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [P2PSIP] To those interested in P2PSIP clients X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org A word of advice to all those interested in P2PSIP clients: Please write an internet-draft saying why you want clients. State the problem(s) that clients solve that peers do not. More specifically: * Describe a problem that you want to solve using clients. * Present a convincing argument why that problem is interesting. * Present a convincing argument why that problem cannot be solved using peers. DO NOT go into the technical minutia of a client protocol. Just focus on convincing people that the problem is worthwhile solving and that some model of clients would be the best way to solve it. The WG chairs requested this document at the Prague meeting in the spring, but I have yet to see it. - Philip PS. If someone thinks a recently posted draft meets this criteria, then I would appreciate a pointer to it. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 08:24:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isehr-0008Bn-9z; Thu, 15 Nov 2007 08:24:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isehq-0008BP-G8 for p2psip@ietf.org; Thu, 15 Nov 2007 08:24:30 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isehp-0002wB-R7 for p2psip@ietf.org; Thu, 15 Nov 2007 08:24:30 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRJ00MX8UKQTG@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 05:24:27 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRJ00IGZUKMF7@usaga01-in.huawei.com> for p2psip@ietf.org; Thu, 15 Nov 2007 05:24:26 -0800 (PST) Date: Thu, 15 Nov 2007 07:23:29 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior To: 'P2PSIP Mailing List' Message-id: <0aef01c8278a$b68ad0e0$ad600240@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00e501c8272a$905b2060$5105a40a@china.huawei.com> <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Great minds think alike. Philip just posted a request for a draft on client requirements. Just to agree with Philip on a couple of specifics... From: "Philip Matthews" > On 14-Nov-07, at 20:55 , Zheng Hewen wrote: > >> Hi, >> >> In Reference model defined in the Concept document, there are mainly >> two types of nodes: peers and clients with SIP UA. >> Further, there are two types of peers: peers with some SIP entity and >> peers without any SIP entity. >> But from the contribution to P2PSIP overlay network, we can think >> that there are mainly three types of nodes: peers >> (participating in overlay, contributing storage capacity), clients (only >> contributing storage capacity to their associated >> peers) and ordinary SIP UAs (without any contribution), is my >> understanding correct? > > Right now, the reference model identifies three types of nodes: (a) > peers, (b) clients, and (c) SIP UAs that attach via an proxy. We discussed the "clients contributing storage capacity" idea just before the Prague IETF. I'm still not sure we have agreement on what clients are (beyond "nodes that speak a logical subset of the peer protocol"), and I'm pretty sure that we don't have agreement that clients contribute storage capacity. >> Certainly, ordinary SIP UAs usually are regarded as P2PSIP clients, >> and essentially SIP usually is regarded one type of >> service over P2PSIP overlay layer. > > This is not actually true. Right now, the concepts draft says that > defines the client protocol as something OTHER than SIP, in order to > distinguish (b) and (c) above. Philip is correct here. The current version of the application scenarios draft (http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt) distinguishes between these cases as follows: P2P Client Support: Whether the overlay need to support a P2P Client protocol, i.e., whether the overlay contains P2P Clients as well as Peers. Interoperation with CS-SIP: Whether the overlay must also interact with legacy SIP clients and SIP proxies. Note that one or more peers in the overlay may also act as PSTN gateways. (HINT: the application scenarios draft includes analysis about whether each scenario seems to require "P2P Client Support" and/or "Interoperation with CS-SIP" - I don't think any of the draft authors are prejudiced against clients, but none of us are strong advocates of clients, so it would be good to have client advocates develop opinions about whether that analysis is reasonable or not) >> I think that we need update the Section 5.3 if we reach the agreement >> about P2PSIP client character according to the >> Reference model, any comment? > > Yes. Once we reach agreement on what a client should be, a number of > sections in the Concepts draft will be to be rewritten. > > I am still waiting for that agreement. David and Brian asked me to lead discussion on clients in Prague (my slides are at http://www3.ietf.org/proceedings/07mar/slides/p2psip-6.pdf, meeting minutes are at http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html). I'd summarize the sense of the room was in Prague as (1) at that time, we did not have creditable use cases ("application scenarios") for clients contributing storage apacity, and (2) we didn't have agreement within the working group on what clients were. I don't believe the chairs tried to verify the sense of the room on the mailing list after the meeting, so we can't say "the working group has consensus" about these points, but that's the way things were headed in the face-to-face meeting. Several people in the room at Prague raised their hands and said they would discuss clients privately. Did that happen? If it did, we need to see text. If it didn't, we need to postpone discussion of clients until it does happen. IMO. Thanks, Spencer >From the Prague meeting minutes: P2PSIP Client Discussion, Spencer Dawkins What are Clients? Not garden variety SIP UACs, nor the equivalent of "peers." Issue: Clients as storage nodes. No credible use case so far; deferred. [ Discussion ensued at mic. Philip: Why do we need P2PSIP clients? The answer will drive whether or not we use them. Brian Rosen (as individual): I don't understand P2PSIP clients. We need to get rid of it and focus on normal SIP clients. Philip: Those that want P2PSIP Clients need to come up with a good use case by Chicago IETF. If they do not come up by then, the P2PSIP Clients go away. ] Hum - Should the wg work on the normal garden variety SIP UA connected to the DHT via some box (a SIP proxy coupled to a peer)? [ Hum indicated yes. Those that want a P2PSIP Client distinct from a normal SIP client need to get together and work on use cases. ] _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 09:55:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isg7v-0005OT-CF; Thu, 15 Nov 2007 09:55:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isg7t-0005NC-DZ for p2psip@ietf.org; Thu, 15 Nov 2007 09:55:29 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isg7s-0007tC-Vp for p2psip@ietf.org; Thu, 15 Nov 2007 09:55:29 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Isg7s-00065Q-0Q for p2psip@ietf.org; Thu, 15 Nov 2007 09:55:28 -0500 In-Reply-To: <0aef01c8278a$b68ad0e0$ad600240@china.huawei.com> References: <00e501c8272a$905b2060$5105a40a@china.huawei.com> <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> <0aef01c8278a$b68ad0e0$ad600240@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9C8C25BD-E1C7-4940-9A42-5261CA150950@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Thu, 15 Nov 2007 09:56:40 -0500 To: P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 15-Nov-07, at 08:23 , Spencer Dawkins wrote: > > (HINT: the application scenarios draft includes analysis about > whether each scenario seems to require "P2P Client Support" and/or > "Interoperation with CS-SIP" - I don't think any of the draft > authors are prejudiced against clients, but none of us are strong > advocates of clients, so it would be good to have client advocates > develop opinions about whether that analysis is reasonable or not) I agree. Right now, I think that most of the most active participants in the group are in the "Show me the money" camp. That is, we are not opposed to them, but we want to see a good argument for them. Some people have said "Mobile devices (e.g., handsets) cannot be peers for battery reasons or storage reasons or ...". But these are just words in the corridor, and not written down. And I keep hearing others say "Nonsense, we CAN have mobile peers". > >> From the Prague meeting minutes: > > P2PSIP Client Discussion, Spencer Dawkins > > What are Clients? Not garden variety SIP UACs, nor the equivalent of > "peers." > > Issue: Clients as storage nodes. No credible use case so far; > deferred. > > [ Discussion ensued at mic. > > Philip: Why do we need P2PSIP clients? The answer will drive > whether or > not we use them. > > Brian Rosen (as individual): I don't understand P2PSIP clients. > We need > to get rid of it and focus on normal SIP clients. > > Philip: Those that want P2PSIP Clients need to come up with a good > use > case by Chicago IETF. If they do not come up by then, the P2PSIP > Clients > go away. ] > > Hum - Should the wg work on the normal garden variety SIP UA > connected to > the DHT via some box (a SIP proxy coupled to a peer)? > > [ Hum indicated yes. > Those that want a P2PSIP Client distinct from a normal SIP client > need to > get together and work on use cases. ] > Yup. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 09:57:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isg9o-0000Qi-3a; Thu, 15 Nov 2007 09:57:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isg9m-0000NW-N6 for p2psip@ietf.org; Thu, 15 Nov 2007 09:57:26 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isg9j-0007he-5n for p2psip@ietf.org; Thu, 15 Nov 2007 09:57:26 -0500 Received: by rv-out-0910.google.com with SMTP id l15so468076rvb for ; Thu, 15 Nov 2007 06:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=JmVmrIOtl7WaYEHim8GBNQWO5YOXeBjp+k78yIGx2Y0=; b=GpOqEXPPmZ9wxQpczesy61t2YpLaaUy1+/W9mzia5AskcFJedL3HCiEo4Kg5FVudv6dV6CSBULb6fNMv6ecKvS3JuwgwDbrQAgC9prO9ttHarXYOu7+8w+gXr31XTb00l22P0DYQ6/8Y3LkVtQbEX7/4gceQgwXI4RAjNFHFHGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S0bHRgWrDJ+el1byjOW6XlwfEFrt3WgQV+H5M5q4DlOkQG6z7ha9Ed9hbuQ5jVl5KJgNP5CmPgqKlOroyDUQtyqPPjeHE7Po6XpOUWt4ZgN/lNk8PooxMuJVAA9nQF5rHowPQjuAY5SXcjrzzL41ot3JZeg7TiRChCIHKGkhjEo= Received: by 10.142.47.6 with SMTP id u6mr102355wfu.1195138642554; Thu, 15 Nov 2007 06:57:22 -0800 (PST) Received: by 10.142.245.15 with HTTP; Thu, 15 Nov 2007 06:57:22 -0800 (PST) Message-ID: <7b683f3f0711150657g4165f4f1j439480cde4c96d8a@mail.gmail.com> Date: Thu, 15 Nov 2007 09:57:22 -0500 From: "Eunsoo Shim" To: "Philip Matthews" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00e501c8272a$905b2060$5105a40a@china.huawei.com> <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 15, 2007 7:48 AM, Philip Matthews wrote: > > On 14-Nov-07, at 20:55 , Zheng Hewen wrote: > > > Hi, > > > > In Reference model defined in the Concept document, there are > > mainly two types of nodes: peers and clients with SIP UA. > > Further, there are two types of peers: peers with some SIP entity > > and peers without any SIP entity. > > But from the contribution to P2PSIP overlay network, we can > > think that there are mainly three types of nodes: peers > > (participating in overlay, contributing storage capacity), clients > > (only contributing storage capacity to their associated > > peers) and ordinary SIP UAs (without any contribution), is my > > understanding correct? > > Right now, the reference model identifies three types of nodes: (a) > peers, (b) clients, and (c) SIP UAs that attach via an proxy. Peers and Clients are components of the overlay. SIP UA node is just an example of non-overlay node. There can be other non-overlay nodes like SIP Proxy node, SIP registrar node, conferencing server node, etc. If the current concepts draft suggests that SIP UA node is a fundamental component of overlay equivalent to Peer and Client, the description should be modified. The reference model diagram in the concepts draft is just an illustration of a possible composition of P2PSIP overlays. P2PSIP overlay may contain only a subset of the illustrated node types (if you count non-overlay node types) or more types. > > > Certainly, ordinary SIP UAs usually are regarded as P2PSIP > > clients, and essentially SIP usually is regarded one type of > > service over P2PSIP overlay layer. > > This is not actually true. Right now, the concepts draft says that > defines the client protocol as something OTHER than SIP, in order to > distinguish (b) and (c) above. > > > I think that we need update the Section 5.3 if we reach the > > agreement about P2PSIP client character according to the > > Reference model, any comment? > > Yes. Once we reach agreement on what a client should be, a number of > sections in the Concepts draft will be to be rewritten. > > I am still waiting for that agreement. > > - Philip > > > Thanks. -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 10:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgWN-0002RO-Gh; Thu, 15 Nov 2007 10:20:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgWM-0002RH-Uf for p2psip@ietf.org; Thu, 15 Nov 2007 10:20:46 -0500 Received: from rn-out-0910.google.com ([64.233.170.190] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsgWK-0000Az-4X for p2psip@ietf.org; Thu, 15 Nov 2007 10:20:46 -0500 Received: by rn-out-0102.google.com with SMTP id a46so469303rne for ; Thu, 15 Nov 2007 07:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=WD+f63FM5BovxwIV7V/dpaZyDEK6h+h4pldFtuM5voc=; b=JxELlcNdt0b9AhtaKIbGuDYg16EDdABSkDuy00z5bOvScAfWh0ixa4gOYB8p/dRbbHJ42DmPeqzrPxd87Md9aZBsFA7YCvonMHmK5byGMvziJFGI0PdwtqG96fcaCKdBXsBMFLa6IdawOrqyouh7zAuYNPuXBOrRY6SlsFvcY6A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J0LPwV7ZK6jAO9kAE26sN/Rhdj1GbfwvslSrF55jD0nIMqqxqwMmghCVL53e/TmRBjr5XjXXsHiBUtNMYQKtWQ1nYwlBaeeKNEL7KBaz33H3f2RDLGMfeuI/6ivl6PZozGLR7hVz+3lUC1uuKHh7Dug69xmIwNmLA8NknciGuRw= Received: by 10.142.179.12 with SMTP id b12mr120652wff.1195140042321; Thu, 15 Nov 2007 07:20:42 -0800 (PST) Received: by 10.142.245.15 with HTTP; Thu, 15 Nov 2007 07:20:42 -0800 (PST) Message-ID: <7b683f3f0711150720p300362fdg25aebe9a8377ac38@mail.gmail.com> Date: Thu, 15 Nov 2007 10:20:42 -0500 From: "Eunsoo Shim" To: "Spencer Dawkins" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <0aef01c8278a$b68ad0e0$ad600240@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00e501c8272a$905b2060$5105a40a@china.huawei.com> <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> <0aef01c8278a$b68ad0e0$ad600240@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I read that some people think we don't need Client node types. Removing Client node types has the following consequences I can think of now: - A SIP UA node that is not a Peer must be attached to a Peer that is coupled to SIP Proxy entity. (please see the difference between 'node' and 'entity'.). In other words, to support SIP UA nodes to access the overlay, many (probably most) Peers should be coupled to SIP Proxy entities. It is an unnecessary requirement for Peers if we define Client node types. Furthermore, I'd prefer to use the overlay just for looking up the location of my callee rather than transport my INVITE messages through the overlay considering the a Proxy entity running on a Peer may not be so trustworthy. By removing the possibility of a node to be a Client coupled with SIP UA entity, we are enforcing any non-Peer SIP UA node to transport INVITE messages through Proxies running on Peers. - If we want other types of non-Peer nodes to be able to access the overlay, we will have to require Peers to implement other entities. Even though we want to focus on scenarios using SIP, we already agreed that it would be better to make the overlay generic enough to support non-SIP applications as long as the overlay can support SIP applications well. Here is a non-SIP application scenario where Client node type is useful. A mobile device that uses the overlay for asynchronous messaging or small file (eg. small resolution photos) sharing. None of the applications use SIP UA. Such mobile device would better be a Client than a Peer. Why would we want to prohibit this kind of application scenarios? Thanks. Eunsoo On Nov 15, 2007 8:23 AM, Spencer Dawkins wrote: > Great minds think alike. Philip just posted a request for a draft on client > requirements. > > Just to agree with Philip on a couple of specifics... > > From: "Philip Matthews" > > > On 14-Nov-07, at 20:55 , Zheng Hewen wrote: > > > >> Hi, > >> > >> In Reference model defined in the Concept document, there are mainly > >> two types of nodes: peers and clients with SIP UA. > >> Further, there are two types of peers: peers with some SIP entity and > >> peers without any SIP entity. > >> But from the contribution to P2PSIP overlay network, we can think > >> that there are mainly three types of nodes: peers > >> (participating in overlay, contributing storage capacity), clients (only > >> contributing storage capacity to their associated > >> peers) and ordinary SIP UAs (without any contribution), is my > >> understanding correct? > > > > Right now, the reference model identifies three types of nodes: (a) > > peers, (b) clients, and (c) SIP UAs that attach via an proxy. > > We discussed the "clients contributing storage capacity" idea just before > the Prague IETF. I'm still not sure we have agreement on what clients are > (beyond "nodes that speak a logical subset of the peer protocol"), and I'm > pretty sure that we don't have agreement that clients contribute storage > capacity. > > >> Certainly, ordinary SIP UAs usually are regarded as P2PSIP clients, > >> and essentially SIP usually is regarded one type of > >> service over P2PSIP overlay layer. > > > > This is not actually true. Right now, the concepts draft says that > > defines the client protocol as something OTHER than SIP, in order to > > distinguish (b) and (c) above. > > Philip is correct here. The current version of the application scenarios > draft > (http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt) > distinguishes between these cases as follows: > > P2P Client Support: Whether the overlay need to support a P2P Client > protocol, i.e., whether the overlay contains P2P Clients as > well as Peers. > Interoperation with CS-SIP: Whether the overlay must also interact > with legacy SIP clients and SIP proxies. > Note that one or more peers in the overlay may also act as PSTN > gateways. > > (HINT: the application scenarios draft includes analysis about whether each > scenario seems to require "P2P Client Support" and/or "Interoperation with > CS-SIP" - I don't think any of the draft authors are prejudiced against > clients, but none of us are strong advocates of clients, so it would be good > to have client advocates develop opinions about whether that analysis is > reasonable or not) > > >> I think that we need update the Section 5.3 if we reach the agreement > >> about P2PSIP client character according to the > >> Reference model, any comment? > > > > Yes. Once we reach agreement on what a client should be, a number of > > sections in the Concepts draft will be to be rewritten. > > > > I am still waiting for that agreement. > > David and Brian asked me to lead discussion on clients in Prague (my slides > are at http://www3.ietf.org/proceedings/07mar/slides/p2psip-6.pdf, meeting > minutes are at http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html). > > I'd summarize the sense of the room was in Prague as (1) at that time, we > did not have creditable use cases ("application scenarios") for clients > contributing storage apacity, and (2) we didn't have agreement within the > working group on what clients were. > > I don't believe the chairs tried to verify the sense of the room on the > mailing list after the meeting, so we can't say "the working group has > consensus" about these points, but that's the way things were headed in the > face-to-face meeting. > > Several people in the room at Prague raised their hands and said they would > discuss clients privately. Did that happen? If it did, we need to see text. > If it didn't, we need to postpone discussion of clients until it does > happen. > > IMO. > > Thanks, > > Spencer > > >From the Prague meeting minutes: > > P2PSIP Client Discussion, Spencer Dawkins > > What are Clients? Not garden variety SIP UACs, nor the equivalent of > "peers." > > Issue: Clients as storage nodes. No credible use case so far; deferred. > > [ Discussion ensued at mic. > > Philip: Why do we need P2PSIP clients? The answer will drive whether or > not we use them. > > Brian Rosen (as individual): I don't understand P2PSIP clients. We need > to get rid of it and focus on normal SIP clients. > > Philip: Those that want P2PSIP Clients need to come up with a good use > case by Chicago IETF. If they do not come up by then, the P2PSIP Clients > go away. ] > > Hum - Should the wg work on the normal garden variety SIP UA connected to > the DHT via some box (a SIP proxy coupled to a peer)? > > [ Hum indicated yes. > Those that want a P2PSIP Client distinct from a normal SIP client need to > get together and work on use cases. ] > > > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 10:26:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgbU-0002fa-LP; Thu, 15 Nov 2007 10:26:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgbT-0002ec-FT for p2psip@ietf.org; Thu, 15 Nov 2007 10:26:03 -0500 Received: from nz-out-0506.google.com ([64.233.162.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsgbR-0000Na-58 for p2psip@ietf.org; Thu, 15 Nov 2007 10:26:03 -0500 Received: by nz-out-0506.google.com with SMTP id n1so524401nzf for ; Thu, 15 Nov 2007 07:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=bUVpICYP0d+bfFlTfVdVypHQ472S/X3uhw9c+Q3iP08=; b=m0YAGpeBa2yqAmwFi3f2eHhGhcS2Oe1kYH4svzhZWMWFVWxK6QSIBWUYIbXfZeIfqhvdfYAq0g5HF+MaR61J7+pJHLbYaVMXzWgtE80eDnMVhiP1G83VhgUcAyQ3ceNwiwWOlCf5X664HcWRC+Y0aSX4gFd3ZGRKkc06WVV3pD8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LSEX+WVWGTT/D21YM2dFLPBsvO08/XmkVuGJLdxe4hFwktB2tBQx5aagt6K52bt9D7+09mxgfBn2VivCPqjUsVR+yiBDXEXEdTnWg7xYIkIpiTQXtZg4gNB1scFbM4S3zr2WkH9bOCcMLi4f9DwLtNxuKUqrn26FRibLg9uCQZw= Received: by 10.142.215.5 with SMTP id n5mr128208wfg.1195140359938; Thu, 15 Nov 2007 07:25:59 -0800 (PST) Received: by 10.142.245.15 with HTTP; Thu, 15 Nov 2007 07:25:59 -0800 (PST) Message-ID: <7b683f3f0711150725ofe9eea5j69a77905dc557f58@mail.gmail.com> Date: Thu, 15 Nov 2007 10:25:59 -0500 From: "Eunsoo Shim" To: "Philip Matthews" Subject: Re: [P2PSIP] To those interested in P2PSIP clients In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hmm, the need for the Client type has been said since November 2005. Looks like the clock went back to the time in the group. I may write a draft a couple of pages long if necessary. Please see one of my previous emails I wrote today about this subject. Thanks. Eunsoo On Nov 15, 2007 7:59 AM, Philip Matthews wrote: > A word of advice to all those interested in P2PSIP clients: > > Please write an internet-draft saying why you want clients. State the > problem(s) that clients solve that peers do not. > > More specifically: > * Describe a problem that you want to solve using clients. > * Present a convincing argument why that problem is interesting. > * Present a convincing argument why that problem cannot be solved > using peers. > > DO NOT go into the technical minutia of a client protocol. Just focus > on convincing people that the problem is worthwhile solving and that > some model of clients would be the best way to solve it. > > The WG chairs requested this document at the Prague meeting in the > spring, but I have yet to see it. > > - Philip > > PS. If someone thinks a recently posted draft meets this criteria, > then I would appreciate a pointer to it. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 10:27:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgdL-0005dl-EA; Thu, 15 Nov 2007 10:27:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgdK-0005c8-OE for p2psip@ietf.org; Thu, 15 Nov 2007 10:27:58 -0500 Received: from exprod6og51.obsmtp.com ([64.18.1.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsgdI-0000Sf-8w for p2psip@ietf.org; Thu, 15 Nov 2007 10:27:58 -0500 Received: from source ([192.150.20.142]) by exprod6ob51.postini.com ([64.18.5.12]) with SMTP; Thu, 15 Nov 2007 07:27:53 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAFFRpKn003966; Thu, 15 Nov 2007 07:27:51 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAFFRoFV024321; Thu, 15 Nov 2007 07:27:51 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 07:27:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] To those interested in P2PSIP clients Date: Thu, 15 Nov 2007 07:27:49 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE2C8@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] To those interested in P2PSIP clients Thread-Index: Acgnh03D7eBKVsKMTAG94WtwbAF+LgAEC44Q References: From: "Henry Sinnreich" To: "Philip Matthews" , "P2PSIP Mailing List" X-OriginalArrivalTime: 15 Nov 2007 15:27:50.0264 (UTC) FILETIME=[151CA780:01C8279C] X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Phil, I completely agree with both you and Spencer and would like to add we need a complete tool set and not work only with the one hammer (the Concept paper). I am troubled seeing only references to a single I-D as the ultimate authority, no matter how good it is.=20 There is a vast work on P2P out there (besides dominating Internet traffic) that must be used by and reflected in P2PSIP. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Thursday, November 15, 2007 5:00 AM To: P2PSIP Mailing List Subject: [P2PSIP] To those interested in P2PSIP clients A word of advice to all those interested in P2PSIP clients: Please write an internet-draft saying why you want clients. State the =20 problem(s) that clients solve that peers do not. More specifically: * Describe a problem that you want to solve using clients. * Present a convincing argument why that problem is interesting. * Present a convincing argument why that problem cannot be solved =20 using peers. DO NOT go into the technical minutia of a client protocol. Just focus =20 on convincing people that the problem is worthwhile solving and that =20 some model of clients would be the best way to solve it. The WG chairs requested this document at the Prague meeting in the =20 spring, but I have yet to see it. - Philip PS. If someone thinks a recently posted draft meets this criteria, =20 then I would appreciate a pointer to it. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 11:14:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshMH-0001Se-EY; Thu, 15 Nov 2007 11:14:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshMG-0001Rw-Cu for p2psip@ietf.org; Thu, 15 Nov 2007 11:14:24 -0500 Received: from [195.235.93.200] (helo=correo.tid.es) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IshMF-0002zS-Af for p2psip@ietf.org; Thu, 15 Nov 2007 11:14:24 -0500 Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRK0028V2ENUH@tid.hi.inet> for p2psip@ietf.org; Thu, 15 Nov 2007 17:13:35 +0100 (MET) Received: from N90 ([10.95.50.7]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRK00EKG2EMAP@tid.hi.inet> for p2psip@ietf.org; Thu, 15 Nov 2007 17:13:35 +0100 (MET) Date: Thu, 15 Nov 2007 17:13:36 +0100 From: Gustavo Garcia Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <7b683f3f0711150720p300362fdg25aebe9a8377ac38@mail.gmail.com> To: 'Eunsoo Shim' Message-id: <029c01c827a2$7a54c460$07325f0a@N90> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgnmyErG3c7oNajTXuCh3ewSsCnIwAAsC1w X-Spam-Score: 0.1 (/) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with the need of Clients, although I disagree with your first point. > I read that some people think we don't need Client node types. > Removing Client node types has the following consequences I can think of > now: > - A SIP UA node that is not a Peer must be attached to a Peer that is > coupled to SIP Proxy entity. (please see the difference between 'node' > and 'entity'.). In other words, to support SIP UA nodes to access the > overlay, many (probably most) Peers should be coupled to SIP Proxy > entities. It is an unnecessary requirement for Peers if we define > Client node types. It is still a requirement to support non-P2PSIP SIP UAs and probably also to provide interconnection with other SIP networks. > Furthermore, I'd prefer to use the overlay just for > looking up the location of my callee rather than transport my INVITE > messages through the overlay The INVITE only needs to go from your SIP UA to the first SIP Proxy. It doesn't need to be routed through the overlay. > considering the a Proxy entity running on > a Peer may not be so trustworthy. It should be as trustworthy as the peer you have to connect to when you need to send a lookup if you are a client, isn't it? > By removing the possibility of a > node to be a Client coupled with SIP UA entity, we are enforcing any > non-Peer SIP UA node to transport INVITE messages through Proxies > running on Peers. > - If we want other types of non-Peer nodes to be able to access the > overlay, we will have to require Peers to implement other entities. > Even though we want to focus on scenarios using SIP, we already agreed > that it would be better to make the overlay generic enough to support > non-SIP applications as long as the overlay can support SIP > applications well. Here is a non-SIP application scenario where Client > node type is useful. A mobile device that uses the overlay for > asynchronous messaging or small file (eg. small resolution photos) > sharing. None of the applications use SIP UA. Such mobile device would > better be a Client than a Peer. Why would we want to prohibit this > kind of application scenarios? Fully agree. I tried to explain the same idea with the example of the Buddy List storage which would probably require XCAP proxies attached to the peers if we don't have a Client Protocol. In my opinion, having a Client Protocol should simplify the deployment of future services like those (we are somehow putting more intelligence in the endpoints instead of in the network). Thanks, G. > > Thanks. > > Eunsoo > > On Nov 15, 2007 8:23 AM, Spencer Dawkins wrote: > > Great minds think alike. Philip just posted a request for a draft on > client > > requirements. > > > > Just to agree with Philip on a couple of specifics... > > > > From: "Philip Matthews" > > > > > On 14-Nov-07, at 20:55 , Zheng Hewen wrote: > > > > > >> Hi, > > >> > > >> In Reference model defined in the Concept document, there are > mainly > > >> two types of nodes: peers and clients with SIP UA. > > >> Further, there are two types of peers: peers with some SIP entity > and > > >> peers without any SIP entity. > > >> But from the contribution to P2PSIP overlay network, we can think > > >> that there are mainly three types of nodes: peers > > >> (participating in overlay, contributing storage capacity), clients > (only > > >> contributing storage capacity to their associated > > >> peers) and ordinary SIP UAs (without any contribution), is my > > >> understanding correct? > > > > > > Right now, the reference model identifies three types of nodes: (a) > > > peers, (b) clients, and (c) SIP UAs that attach via an proxy. > > > > We discussed the "clients contributing storage capacity" idea just > before > > the Prague IETF. I'm still not sure we have agreement on what clients > are > > (beyond "nodes that speak a logical subset of the peer protocol"), and > I'm > > pretty sure that we don't have agreement that clients contribute storage > > capacity. > > > > >> Certainly, ordinary SIP UAs usually are regarded as P2PSIP > clients, > > >> and essentially SIP usually is regarded one type of > > >> service over P2PSIP overlay layer. > > > > > > This is not actually true. Right now, the concepts draft says that > > > defines the client protocol as something OTHER than SIP, in order to > > > distinguish (b) and (c) above. > > > > Philip is correct here. The current version of the application scenarios > > draft > > (http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios- > 00.txt) > > distinguishes between these cases as follows: > > > > P2P Client Support: Whether the overlay need to support a P2P Client > > protocol, i.e., whether the overlay contains P2P Clients as > > well as Peers. > > Interoperation with CS-SIP: Whether the overlay must also interact > > with legacy SIP clients and SIP proxies. > > Note that one or more peers in the overlay may also act as PSTN > > gateways. > > > > (HINT: the application scenarios draft includes analysis about whether > each > > scenario seems to require "P2P Client Support" and/or "Interoperation > with > > CS-SIP" - I don't think any of the draft authors are prejudiced against > > clients, but none of us are strong advocates of clients, so it would be > good > > to have client advocates develop opinions about whether that analysis is > > reasonable or not) > > > > >> I think that we need update the Section 5.3 if we reach the > agreement > > >> about P2PSIP client character according to the > > >> Reference model, any comment? > > > > > > Yes. Once we reach agreement on what a client should be, a number of > > > sections in the Concepts draft will be to be rewritten. > > > > > > I am still waiting for that agreement. > > > > David and Brian asked me to lead discussion on clients in Prague (my > slides > > are at http://www3.ietf.org/proceedings/07mar/slides/p2psip-6.pdf, > meeting > > minutes are at > http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html). > > > > I'd summarize the sense of the room was in Prague as (1) at that time, > we > > did not have creditable use cases ("application scenarios") for clients > > contributing storage apacity, and (2) we didn't have agreement within > the > > working group on what clients were. > > > > I don't believe the chairs tried to verify the sense of the room on the > > mailing list after the meeting, so we can't say "the working group has > > consensus" about these points, but that's the way things were headed in > the > > face-to-face meeting. > > > > Several people in the room at Prague raised their hands and said they > would > > discuss clients privately. Did that happen? If it did, we need to see > text. > > If it didn't, we need to postpone discussion of clients until it does > > happen. > > > > IMO. > > > > Thanks, > > > > Spencer > > > > >From the Prague meeting minutes: > > > > P2PSIP Client Discussion, Spencer Dawkins > > > > What are Clients? Not garden variety SIP UACs, nor the equivalent of > > "peers." > > > > Issue: Clients as storage nodes. No credible use case so far; deferred. > > > > [ Discussion ensued at mic. > > > > Philip: Why do we need P2PSIP clients? The answer will drive whether > or > > not we use them. > > > > Brian Rosen (as individual): I don't understand P2PSIP clients. We > need > > to get rid of it and focus on normal SIP clients. > > > > Philip: Those that want P2PSIP Clients need to come up with a good use > > case by Chicago IETF. If they do not come up by then, the P2PSIP > Clients > > go away. ] > > > > Hum - Should the wg work on the normal garden variety SIP UA connected > to > > the DHT via some box (a SIP proxy coupled to a peer)? > > > > [ Hum indicated yes. > > Those that want a P2PSIP Client distinct from a normal SIP client need > to > > get together and work on use cases. ] > > > > > > > > > > > > -- > Eunsoo > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 11:25:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshXK-0006m7-UI; Thu, 15 Nov 2007 11:25:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshXI-0006lZ-8v for p2psip@lists.ietf.org; Thu, 15 Nov 2007 11:25:48 -0500 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IshXE-0003bP-RX for p2psip@lists.ietf.org; Thu, 15 Nov 2007 11:25:48 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id 04DEF21381Bfor ; Thu, 15 Nov 2007 17:25:44 +0100 (CET) Message-ID: <473C730E.1080004@it.uc3m.es> Date: Thu, 15 Nov 2007 17:25:50 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: p2psip@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-7.1435 TC:1F TRN:41 TV:5.0.1023(15548.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -4.0 (----) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [P2PSIP] Identity vs Identifier X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi everyone, I have been following the list from some time ago, and finally after expo= se some ideas to Henry Sinnreich I decided to participate since I think it could be useful. Something that I miss on the discussion so far is the concept of "Identit= y" and "Identifier". An identity is who I am. For instance, if we consider the Skype model =20 Rub=E9n.Cuevas is an identity which will be represented=20 in the DHT in somehow. It make fully sense that in the DHT the=20 hash(Ruben.Cuevas) will be stored. I think the=20 WG call this /record/. Then, we have records representing identities.=20 We can define identities as those things someone wants to find in the DHT= . On the other hand, we have Identifiers (I don't know if Identifiers is=20 the right name) which could be paired with identities or not ( usually,=20 identifiers will be paired with identities). Identifiers are representing= /entities/=20 which are going to look for information in the P2PSIP systems and likely = they also are storing records. Then I (Rub=E9n.Cuevas) can have one identifier associated. =20 E.g. I am on my office with my desktop connected to the p2psip system. In= =20 that case we have the situation of paired identitiy and identifier. However, I can also have several identifiers paired to an unique=20 identity. For instance, I am on my office and I have my laptop, my PDA,=20 my mobile phone and all of them are joined to the p2psip system. In this = case maybe I don't want that all my devices were=20 part from the p2psip system (since all of them would be consuming=20 resources), I would like that only one of them (hopefully the most=20 powefull) belongs to the DHT, then it would be a peer. The rest will be=20 only clients which will be connected through my peer. In addition, we should consider that in the current DHT systems my=20 identity (record) and identifiers are placed in different points of the=20 system, then my record does not depend on my indentifiers but in other=20 identifier which I don't know who is. A question: It would be possible to= =20 make that my identity depends on any of my identifiers instead of a=20 third party?? If this is possible, the system would be more secure. I=20 have some ideas in this case, but my solution is really dependant on the=20 scenario (I don't know if this makes sense for the WG). On the other hand we can have the case of public telephones, or p2psip=20 devices in a public library or in an university. These devices can be=20 used to make calls and look for identities by using the p2psip. However, = in this=20 case there is not any identity associated to this identifier. Regards, Rub=E9n. --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 11:35:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishh8-0004Eh-DD; Thu, 15 Nov 2007 11:35:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishh7-0004EU-NP for p2psip@ietf.org; Thu, 15 Nov 2007 11:35:57 -0500 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ishh4-0004In-Me for p2psip@ietf.org; Thu, 15 Nov 2007 11:35:57 -0500 Received: by nz-out-0506.google.com with SMTP id n1so544135nzf for ; Thu, 15 Nov 2007 08:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=90hAutpShV9BsYoIsgiVQQu32UP9I9/udllxSYCM6JU=; b=InFrMNqK+7W79bpTgZ2vyl+/XtV3PurXp8IT8HUqOQAuHeAdjqI6MCg4Crn9TaETAZbD3oJGi5OqpiLHbDkuAVG6qQ7Edow7+YcGYrS/ii5NCN3/AcyzVtihX3p7uFoJRVo8aHrOkgBEMKVXdnHLftwlbjdU1tDYdmC9wPARrvU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dIhQGlVKbyzet7oDjju+u8Rqsee3PgiXbu82Wi89TBpfk+z4d1HiAsAfQr7ryJB8HWxeoebJeX5KPLngDH7qhfeTsh5wbfMA/E+rd2b2KznwJaU1bMp4ILsIwe4mcdpHyEi57PUNwBonqp31Ts/iJAuVMRGpNawEw8DngPnD204= Received: by 10.142.237.20 with SMTP id k20mr171980wfh.1195144552556; Thu, 15 Nov 2007 08:35:52 -0800 (PST) Received: by 10.142.245.15 with HTTP; Thu, 15 Nov 2007 08:35:52 -0800 (PST) Message-ID: <7b683f3f0711150835s12d6aef7vd95ffddf254c13a5@mail.gmail.com> Date: Thu, 15 Nov 2007 11:35:52 -0500 From: "Eunsoo Shim" To: "Gustavo Garcia" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <029c01c827a2$7a54c460$07325f0a@N90> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7b683f3f0711150720p300362fdg25aebe9a8377ac38@mail.gmail.com> <029c01c827a2$7a54c460$07325f0a@N90> X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 15, 2007 11:13 AM, Gustavo Garcia wrote: > I agree with the need of Clients, although I disagree with your first point. > > > I read that some people think we don't need Client node types. > > Removing Client node types has the following consequences I can think of > > now: > > - A SIP UA node that is not a Peer must be attached to a Peer that is > > coupled to SIP Proxy entity. (please see the difference between 'node' > > and 'entity'.). In other words, to support SIP UA nodes to access the > > overlay, many (probably most) Peers should be coupled to SIP Proxy > > entities. It is an unnecessary requirement for Peers if we define > > Client node types. > It is still a requirement to support non-P2PSIP SIP UAs and probably also to > provide interconnection with other SIP networks. > Neither of the above requirement means many or all of the Peers must be coupled with SIP Proxy entity. > > Furthermore, I'd prefer to use the overlay just for > > looking up the location of my callee rather than transport my INVITE > > messages through the overlay > The INVITE only needs to go from your SIP UA to the first SIP Proxy. It > doesn't need to be routed through the overlay. > Right. The first SIP Proxy is on a Peer in this case. I meant what you wrote but put it wrongly. > > considering the a Proxy entity running on > > a Peer may not be so trustworthy. > It should be as trustworthy as the peer you have to connect to when you need > to send a lookup if you are a client, isn't it? > Interesting point. Location data can be signed by the callee easily. No Peer has right to modify it. SIP Proxy generally has right to modify SIP messages it forwards. (I think Jonathan mentioned this in this mailing list some time ago.) So concern on getting location data through another Peer is less than having your SIP INVITE messages routed by another Peer's Proxy entity, I think. > > By removing the possibility of a > > node to be a Client coupled with SIP UA entity, we are enforcing any > > non-Peer SIP UA node to transport INVITE messages through Proxies > > running on Peers. > > > - If we want other types of non-Peer nodes to be able to access the > > overlay, we will have to require Peers to implement other entities. > > Even though we want to focus on scenarios using SIP, we already agreed > > that it would be better to make the overlay generic enough to support > > non-SIP applications as long as the overlay can support SIP > > applications well. Here is a non-SIP application scenario where Client > > node type is useful. A mobile device that uses the overlay for > > asynchronous messaging or small file (eg. small resolution photos) > > sharing. None of the applications use SIP UA. Such mobile device would > > better be a Client than a Peer. Why would we want to prohibit this > > kind of application scenarios? > Fully agree. I tried to explain the same idea with the example of the Buddy > List storage which would probably require XCAP proxies attached to the peers > if we don't have a Client Protocol. In my opinion, having a Client > Protocol should simplify the deployment of future services like those (we > are somehow putting more intelligence in the endpoints instead of in the > network). > I am glad to know that I am not alone. :-) Thanks. Eunsoo > > On Nov 15, 2007 8:23 AM, Spencer Dawkins wrote: > > > Great minds think alike. Philip just posted a request for a draft on > > client > > > requirements. > > > > > > Just to agree with Philip on a couple of specifics... > > > > > > From: "Philip Matthews" > > > > > > > On 14-Nov-07, at 20:55 , Zheng Hewen wrote: > > > > > > > >> Hi, > > > >> > > > >> In Reference model defined in the Concept document, there are > > mainly > > > >> two types of nodes: peers and clients with SIP UA. > > > >> Further, there are two types of peers: peers with some SIP entity > > and > > > >> peers without any SIP entity. > > > >> But from the contribution to P2PSIP overlay network, we can think > > > >> that there are mainly three types of nodes: peers > > > >> (participating in overlay, contributing storage capacity), clients > > (only > > > >> contributing storage capacity to their associated > > > >> peers) and ordinary SIP UAs (without any contribution), is my > > > >> understanding correct? > > > > > > > > Right now, the reference model identifies three types of nodes: (a) > > > > peers, (b) clients, and (c) SIP UAs that attach via an proxy. > > > > > > We discussed the "clients contributing storage capacity" idea just > > before > > > the Prague IETF. I'm still not sure we have agreement on what clients > > are > > > (beyond "nodes that speak a logical subset of the peer protocol"), and > > I'm > > > pretty sure that we don't have agreement that clients contribute storage > > > capacity. > > > > > > >> Certainly, ordinary SIP UAs usually are regarded as P2PSIP > > clients, > > > >> and essentially SIP usually is regarded one type of > > > >> service over P2PSIP overlay layer. > > > > > > > > This is not actually true. Right now, the concepts draft says that > > > > defines the client protocol as something OTHER than SIP, in order to > > > > distinguish (b) and (c) above. > > > > > > Philip is correct here. The current version of the application scenarios > > > draft > > > (http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios- > > 00.txt) > > > distinguishes between these cases as follows: > > > > > > P2P Client Support: Whether the overlay need to support a P2P Client > > > protocol, i.e., whether the overlay contains P2P Clients as > > > well as Peers. > > > Interoperation with CS-SIP: Whether the overlay must also interact > > > with legacy SIP clients and SIP proxies. > > > Note that one or more peers in the overlay may also act as PSTN > > > gateways. > > > > > > (HINT: the application scenarios draft includes analysis about whether > > each > > > scenario seems to require "P2P Client Support" and/or "Interoperation > > with > > > CS-SIP" - I don't think any of the draft authors are prejudiced against > > > clients, but none of us are strong advocates of clients, so it would be > > good > > > to have client advocates develop opinions about whether that analysis is > > > reasonable or not) > > > > > > >> I think that we need update the Section 5.3 if we reach the > > agreement > > > >> about P2PSIP client character according to the > > > >> Reference model, any comment? > > > > > > > > Yes. Once we reach agreement on what a client should be, a number of > > > > sections in the Concepts draft will be to be rewritten. > > > > > > > > I am still waiting for that agreement. > > > > > > David and Brian asked me to lead discussion on clients in Prague (my > > slides > > > are at http://www3.ietf.org/proceedings/07mar/slides/p2psip-6.pdf, > > meeting > > > minutes are at > > http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html). > > > > > > I'd summarize the sense of the room was in Prague as (1) at that time, > > we > > > did not have creditable use cases ("application scenarios") for clients > > > contributing storage apacity, and (2) we didn't have agreement within > > the > > > working group on what clients were. > > > > > > I don't believe the chairs tried to verify the sense of the room on the > > > mailing list after the meeting, so we can't say "the working group has > > > consensus" about these points, but that's the way things were headed in > > the > > > face-to-face meeting. > > > > > > Several people in the room at Prague raised their hands and said they > > would > > > discuss clients privately. Did that happen? If it did, we need to see > > text. > > > If it didn't, we need to postpone discussion of clients until it does > > > happen. > > > > > > IMO. > > > > > > Thanks, > > > > > > Spencer > > > > > > >From the Prague meeting minutes: > > > > > > P2PSIP Client Discussion, Spencer Dawkins > > > > > > What are Clients? Not garden variety SIP UACs, nor the equivalent of > > > "peers." > > > > > > Issue: Clients as storage nodes. No credible use case so far; deferred. > > > > > > [ Discussion ensued at mic. > > > > > > Philip: Why do we need P2PSIP clients? The answer will drive whether > > or > > > not we use them. > > > > > > Brian Rosen (as individual): I don't understand P2PSIP clients. We > > need > > > to get rid of it and focus on normal SIP clients. > > > > > > Philip: Those that want P2PSIP Clients need to come up with a good use > > > case by Chicago IETF. If they do not come up by then, the P2PSIP > > Clients > > > go away. ] > > > > > > Hum - Should the wg work on the normal garden variety SIP UA connected > > to > > > the DHT via some box (a SIP proxy coupled to a peer)? > > > > > > [ Hum indicated yes. > > > Those that want a P2PSIP Client distinct from a normal SIP client need > > to > > > get together and work on use cases. ] > > > > > > > > > > > > > > > > > > > > > -- > > Eunsoo > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 12:35:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isict-00015X-5y; Thu, 15 Nov 2007 12:35:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isicr-00013r-E5 for p2psip@lists.ietf.org; Thu, 15 Nov 2007 12:35:37 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isico-0007gj-2p for p2psip@lists.ietf.org; Thu, 15 Nov 2007 12:35:37 -0500 Received: by ug-out-1314.google.com with SMTP id z38so513744ugc for ; Thu, 15 Nov 2007 09:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ghrkF57NVTgZv61vgko+wJQnLVKcCspHa8L2ro4KBM8=; b=NQRsB4MWFXvMVWPflfIQ9r0KNKgsRkIBhF5TuxB5IE4YaZfBIwnFTAiK0dcAvn8zcGMrFUwHEa3TYFkvggVD+NxIxxl7/b7cUHJj89XC7uZi7v8X7cyG3ywKMMZ7kiQA+ajRlm7DrgTd5hPblqLT4iYPdAwC76a5KcEn9HQdFfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eW8E75pU5BfVbUruOi4l3/mWcBO9GYiGCpBgtHIluOVv8EPAiQ79W2tjwN20HW3fWMPHiYlxlXdKnN2V0TXQEY92lkifDVovvGx8w/te1AIt1Vegwa9qmF0jn1+JkLpNlMtv8IDMWvifg9eZkAWzDwlXe/fztpnIOtxgDr2rvyQ= Received: by 10.66.255.7 with SMTP id c7mr399651ugi.1195148133355; Thu, 15 Nov 2007 09:35:33 -0800 (PST) Received: by 10.66.252.5 with HTTP; Thu, 15 Nov 2007 09:35:33 -0800 (PST) Message-ID: <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> Date: Thu, 15 Nov 2007 18:35:33 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: rcuevas@it.uc3m.es Subject: Re: [P2PSIP] Identity vs Identifier In-Reply-To: <473C730E.1080004@it.uc3m.es> MIME-Version: 1.0 References: <473C730E.1080004@it.uc3m.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1084413792==" Errors-To: p2psip-bounces@ietf.org --===============1084413792== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gMTUvMTEvMjAwNywgUnViw6luIEN1ZXZhcyBSdW3DrW4gPHJjdWV2YXNAaXQudWMzbS5lcz4g d3JvdGU6Cj4gU29tZXRoaW5nIHRoYXQgSSBtaXNzIG9uIHRoZSBkaXNjdXNzaW9uIHNvIGZhciBp cyB0aGUgY29uY2VwdCBvZiAiSWRlbnRpdHkiIGFuZCAiSWRlbnRpZmllciIuCgpJbiBteSB1bmRl cnN0YW5kaW5nIC1jb25zaWRlcmluZyBjb25jZXB0cyBkb2N1bWVudAooZHJhZnQtaWV0Zi1wMnBz aXAtY29uY2VwdHMtMDApLCBzZWN0aW9uIDQtIHlvdXIgY29uY2VwdCBvZiAiaWRlbnRpdHkiCmlz IHJlcHJlc2VudGVkIGJ5ICJVc2VyIE5hbWUiIG9yICJTZXJ2aWNlIE5hbWUiLCB3aGlsZSBjb25j ZXB0IG9mCiJJZGVudGlmaWVyIiBpcyByZXByZXNlbnRlZCBieSAiTm9kZS1JRCIuCgo+IEhvd2V2 ZXIsIEkgY2FuIGFsc28gaGF2ZSBzZXZlcmFsIGlkZW50aWZpZXJzIHBhaXJlZCB0byBhbiB1bmlx dWUKPiBpZGVudGl0eS4gRm9yIGluc3RhbmNlLCBJIGFtIG9uIG15IG9mZmljZSBhbmQgSSBoYXZl IG15IGxhcHRvcCwgbXkgUERBLAo+IG15IG1vYmlsZSBwaG9uZSBhbmQgYWxsIG9mIHRoZW0gYXJl IGpvaW5lZCB0byB0aGUgcDJwc2lwIHN5c3RlbS4gSW4gdGhpcyBjYXNlIG1heWJlIEkgZG9uJ3Qg d2FudCB0aGF0IGFsbCBteSBkZXZpY2VzIHdlcmUKPiBwYXJ0IGZyb20gdGhlIHAycHNpcCBzeXN0 ZW0gKHNpbmNlIGFsbCBvZiB0aGVtIHdvdWxkIGJlIGNvbnN1bWluZwo+IHJlc291cmNlcyksIEkg d291bGQgbGlrZSB0aGF0IG9ubHkgb25lIG9mIHRoZW0gKGhvcGVmdWxseSB0aGUgbW9zdAo+IHBv d2VmdWxsKSBiZWxvbmdzIHRvIHRoZSBESFQsIHRoZW4gaXQgd291bGQgYmUgYSBwZWVyLiBUaGUg cmVzdCB3aWxsIGJlCj4gb25seSBjbGllbnRzIHdoaWNoIHdpbGwgYmUgY29ubmVjdGVkIHRocm91 Z2ggbXkgcGVlci4KCkluIG15IG9waW5pb24geW91IGFyZSBtaXhpbmcgREhUICh0cmFuc3BvcnQg YW5kIHJvdXRpbmcpIGFuZCBTSVAKY29uY2VwdHMgKHJlZ2lzdGVyaW5nIGZyb20gJ24nIFVBcyku IEl0J3MgdHJ1ZSBib3RoIHBlZXIgYW5kIGNsaWVudApjb3VsZCBiZSBjb3VwbGVkIHdpdGggU0lQ IFVBLCBidXQgdGhpcyBzaG91bGQgYmUgaW5kZXBlbmRlbnQgb2YgdGhlaXIKUDJQIHJvbGUuCgpQ bGVhc2UgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmcsCi0tIApWaWN0b3IgUGFzY3VhbCDDgXZpbGEK --===============1084413792== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1084413792==-- From p2psip-bounces@ietf.org Thu Nov 15 12:47:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ision-0004Bs-17; Thu, 15 Nov 2007 12:47:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isiom-0004A4-5t for p2psip@ietf.org; Thu, 15 Nov 2007 12:47:56 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isiol-0000Vg-U4 for p2psip@ietf.org; Thu, 15 Nov 2007 12:47:56 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id C16EC2AC6B; Thu, 15 Nov 2007 17:47:25 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IsioH-0003BV-I0; Thu, 15 Nov 2007 12:47:25 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: philip_matthews@magma.ca From: IETF I-D Submission Tool Message-Id: Date: Thu, 15 Nov 2007 12:47:25 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: bryan@sipeerior.com, p2psip@ietf.org Subject: [P2PSIP] New Version Notification for draft-ietf-p2psip-concepts-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org A new version of I-D, draft-ietf-p2psip-concepts-01.txt has been successfuly submitted by Philip Matthews and posted to the IETF repository. Filename: draft-ietf-p2psip-concepts Revision: 01 Title: Concepts and Terminology for Peer to Peer SIP Creation_date: 2007-11-15 WG ID: p2psip Number_of_pages: 30 Abstract: This document defines concepts and terminology for use of the Session Initiation Protocol in a peer-to-peer environment where the traditional proxy-registrar and message routing functions are replaced by a distributed mechanism that might be implemented using a distributed hash table or other distributed data mechanism with similar external properties. This document includes a high-level view of the functional relationships between the network elements defined herein, a conceptual model of operations, and an outline of the related open problems being addressed by the P2PSIP working group. As this document matures, it is expected to define the general framework for P2PSIP. The IETF Secretariat. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 13:03:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isj3t-00047O-IC; Thu, 15 Nov 2007 13:03:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isj3r-000473-8E for p2psip@ietf.org; Thu, 15 Nov 2007 13:03:31 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isj3q-0001Ba-Tw for p2psip@ietf.org; Thu, 15 Nov 2007 13:03:31 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Isj3L-00036t-2s for p2psip@ietf.org; Thu, 15 Nov 2007 13:02:59 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: P2PSIP Mailing List From: Philip Matthews Date: Thu, 15 Nov 2007 13:04:43 -0500 X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [P2PSIP] New version of Concepts draft X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I have just posted the -01 version of the Concepts draft. This changes this time were minor: * Added the term "Responsible Peer" to the terminology section. * Added a new section that talks about protocol architecture. For now, the primary contribution of this section is to say that we have decided not to follow the route of extending SIP to handle all the overlay and distributed database operations. The section gives a short list of reasons why the WG took this decision. As a consequence, I removed a section in the Open Questions section that talks about this very question. * Added a couple of sentences clarifying that the Reference Architecture diagram does not illustrate every possible combination of nodes and interactions. We are coming up to another major rewrite of this document. This rewrite will likely specify in much more detail how an overlay works. However, I personally want to see how the meeting in Vancouver turns out before starting this revision. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 13:12:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsjCZ-0004Ao-CH; Thu, 15 Nov 2007 13:12:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsjCX-00048T-Tr for p2psip@ietf.org; Thu, 15 Nov 2007 13:12:29 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsjCU-0000jZ-Hg for p2psip@ietf.org; Thu, 15 Nov 2007 13:12:29 -0500 Received: by ug-out-1314.google.com with SMTP id u2so1527613uge for ; Thu, 15 Nov 2007 10:12:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=QWm6DyWnuT26Sd3sjWsYIuuZObRufmarOXlEsE1g9So=; b=YCuZWaY7O43oyIV0nQJVwynbdJ9KIbPdSf6hGKARbZXtJ/yMpbQHQ5om7MjzmsQ234V/WWDYa/gRY1aL26S9OxnVv58gzbZQxjNNuAYEC1DCt7AkM7DcXiDEdfmr6buvDRM95K6WciO9KjEh5MXnPCQIRZU5vGY0D9Twgl1fEDE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DKXqs7ymBgV/Y1oSVNb/C4m7PlOIyDZ/fXciF3nQ2KLdiu1pFH1bBBRFSFxS5N9TESEhqZP3lo97tNxh4kZ+134JFp/coitMtket7gl5UZbpAbl5GlnxcBl17xpvQQBVlob6ZHlR2+itvH/8ErTnZ9DNGeV34JwMMkKVZ3hbvoM= Received: by 10.67.29.12 with SMTP id g12mr318419ugj.1195150345442; Thu, 15 Nov 2007 10:12:25 -0800 (PST) Received: by 10.66.252.5 with HTTP; Thu, 15 Nov 2007 10:12:25 -0800 (PST) Message-ID: <618e24240711151012l317cb06u8816d444d0fd517a@mail.gmail.com> Date: Thu, 15 Nov 2007 19:12:25 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: "Philip Matthews" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> MIME-Version: 1.0 References: <00e501c8272a$905b2060$5105a40a@china.huawei.com> <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: P2PSIP Mailing List , Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1690071822==" Errors-To: p2psip-bounces@ietf.org --===============1690071822== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gMTUvMTEvMjAwNywgUGhpbGlwIE1hdHRoZXdzIDxwaGlsaXBfbWF0dGhld3NAbWFnbWEuY2E+ IHdyb3RlOgo+IFJpZ2h0IG5vdywgdGhlIHJlZmVyZW5jZSBtb2RlbCBpZGVudGlmaWVzIHRocmVl IHR5cGVzIG9mIG5vZGVzOiAoYSkKPiBwZWVycywgKGIpIGNsaWVudHMsIGFuZCAoYykgU0lQIFVB cyB0aGF0IGF0dGFjaCB2aWEgYW4gcHJveHkuCgpJIHRoaW5rIHdlIHNob3VsZCBub3QgbWl4IFAy UCByb2xlIChzdG9yYWdlLHJvdXRpbmcpIGFuZCBTSVAgZW50aXRpZXMKd2hlbiBkZWZpbmluZyBy b2xlcyBzaW5jZSBhIHBlZXIgY291bGQgYmUgY291cGxlZCB3aXRoIFNJUCBVQS4KCkZyb20gdGhl IFAyUCBwb2ludCBvZiB2aWV3LCB3ZSBjb3VsZCBjb25zaWRlcjogKGEpIG5vZGVzIG9mZmVyaW5n CnN0b3JhZ2UgYW5kIHJvdXRpbmcgLWFrYSBQZWVycy0gKGIpIG5vZGVzIG9mZmVyaW5nIHN0b3Jh Z2UgLWFrYQpDbGllbnRzLSAoYykgY29uc3VtZXJzCgpOb3csIEkgc3VnZ2VzdCBob3cgSSBpbWFn aW5lIG1hcHBpbmcgUDJQIHJvbGVzIGFuZCBTSVAgZW50aXRpZXM6CgpDb25zdW1lcnM6IFZlcnkg YmFzaWMgbm9kZXMgLWUuZy4gbW9iaWxlIHBob25lLSBjb3VwbGVkIHdpdGggU0lQIFVBLgoKQ2xp ZW50czogQmFzaWMgbm9kZXMgb2ZmZXJpbmcgc3RvcmFnZSBjYXBhYmlsaXRpZXMuIEluZm9ybWF0 aW9uIHN0b3JlZAppbiBDbGllbnRzIHdpbGwgYmUgb25seSBpbXBvcnRhbnQgaW5mb3JtYXRpb24g Zm9yIENsaWVudHMgU2Vzc2lvbgotc29tZXRoaW5nIGxpa2UgY2FjaGluZy0gKGUuZyB3aGVyZSBp cyBteSBidWRkeSBjb25uZWN0ZWQgZnJvbT8gd2hvIGlzCm15IGJvb3RzdHJhcCBhbmQgYWRtaXR0 aW5nIG5vZGUgdG9kYXk/IEkgZG93bmxvYWQgbXkgdm9pY2VtYWlscyBmcm9tCnRoZSBvdmVybGF5 IHdoZW4gSSBqb2luIHRoZSBuZXR3b3JrLCBldGMpLiBDb3VwbGVkIHdpdGggU0lQIFVBLiAoZS5n LgpDb21wdXRlcikuIEluIGNhc2Ugb2YgQ29uc3VtZXIsIHRoaXMgJ2NhY2hpbmcgaW5mb3JtYXRp b24nIHdvdWxkIGJlCnN0b3JlZCBieSBpdCdzIHJlc3BvbnNpYmxlIHBlZXIuCgpQZWVyczogQWR2 YW5jZWQgbm9kZXMgcHJvdmlkaW5nIHJvdXRpbmcgYW5kIHN0b3JhZ2UgY2FwYWJpbGl0aWVzLgpJ bmZvcm1hdGlvbiBzdG9yZWQgaW4gcGVlcnMgY291bGQgYmUgJ2hvdyB0byBsb2NhdGUgYSBnaXZl biB1c2VyJywKJ2dpdmVuIHVzZXIga2V5IGlzIFgnLCAnZ2l2ZW4gdXNlciBidWRkeSBsaXN0IGlz IFknIGFsbG93aW5nIHVzZXJzIHRvCnJlZ2lzdGVyIGZyb20gZGlmZmVyZW50IG5vZGVzLiBDb3Vw bGVkIHdpdGggTk9ORSBvciBBTlkgU0lQIGVudGl0eS4KKGUuZy4gd2lyZWxlc3MgbWVzaCByb3V0 ZXJzIGluIFdNTnMgaHlicmlkIHRvcG9sb2d5LCBhZHZhbmNlZCBBUCwKc3dpdGNoLCBldGMuKQoK Q2xpZW50cyBhbmQgY29uc3VtZXJzIHdpbGwgcmVhY2ggUDJQU0lQIG92ZXJsYXkgdGhyb3VnaCBw ZWVycy4gV2hpbGUKQ2xpZW50cyB3aWxsIHN0b3JlIHNvbWUgaW5mb3JtYXRpb24sIHBlZXJzIHdp bGwgc3RvcmUgaW5mb3JtYXRpb24gb24KYmVoYWxmIG9mIGNvbnN1bWVycy4KCkNvbnN1bWVycyB3 b3VsZCBOT1QgdXNlIGNsaWVudHMgdG8gZ2V0IHJlZ2lzdGVyZWQgc2luY2UgcGVlcnMgY291cGxl ZAp3aXRoIFNJUCBwcm94eSB3b3VsZCBiZSB1c2VkLgoKPiBJIGFtIHN0aWxsIHdhaXRpbmcgZm9y IHRoYXQgYWdyZWVtZW50LgoKRm9yIHN1cmUgd2Ugd2lsbCBkbyA6LSkKCgpUaGFua3MsCi0tIApW aWN0b3IgUGFzY3VhbCDDgXZpbGEK --===============1690071822== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1690071822==-- From p2psip-bounces@ietf.org Thu Nov 15 13:39:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isjcn-00069B-AH; Thu, 15 Nov 2007 13:39:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isjcl-00065w-PT for p2psip@ietf.org; Thu, 15 Nov 2007 13:39:35 -0500 Received: from chip2og53.obsmtp.com ([64.18.13.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isjcl-0002mE-BH for p2psip@ietf.org; Thu, 15 Nov 2007 13:39:35 -0500 Received: from source ([192.150.11.134]) by chip2ob53.postini.com ([64.18.5.12]) with SMTP; Thu, 15 Nov 2007 10:39:28 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAFIbMOP000793; Thu, 15 Nov 2007 10:37:22 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAFIdPFV016844; Thu, 15 Nov 2007 10:39:26 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 10:39:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] To those interested in P2PSIP clients Date: Thu, 15 Nov 2007 10:39:24 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE2D0@namail5.corp.adobe.com> In-Reply-To: <7b683f3f0711150725ofe9eea5j69a77905dc557f58@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] To those interested in P2PSIP clients Thread-Index: Acgnm+I1UQVIurD9R8mZANdfY3UocAAGL8uA References: <7b683f3f0711150725ofe9eea5j69a77905dc557f58@mail.gmail.com> From: "Henry Sinnreich" To: "Eunsoo Shim" , "Philip Matthews" X-OriginalArrivalTime: 15 Nov 2007 18:39:25.0204 (UTC) FILETIME=[D8A14D40:01C827B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eunsoo, >Hmm, the need for the Client type has been said since November 2005. >I may write a draft a couple of pages long if necessary. This would be a great contribution! Henry -----Original Message----- From: Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 Sent: Thursday, November 15, 2007 7:26 AM To: Philip Matthews Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] To those interested in P2PSIP clients Hmm, the need for the Client type has been said since November 2005. Looks like the clock went back to the time in the group. I may write a draft a couple of pages long if necessary. Please see one of my previous emails I wrote today about this subject. Thanks. Eunsoo On Nov 15, 2007 7:59 AM, Philip Matthews wrote: > A word of advice to all those interested in P2PSIP clients: > > Please write an internet-draft saying why you want clients. State the > problem(s) that clients solve that peers do not. > > More specifically: > * Describe a problem that you want to solve using clients. > * Present a convincing argument why that problem is interesting. > * Present a convincing argument why that problem cannot be solved > using peers. > > DO NOT go into the technical minutia of a client protocol. Just focus > on convincing people that the problem is worthwhile solving and that > some model of clients would be the best way to solve it. > > The WG chairs requested this document at the Prague meeting in the > spring, but I have yet to see it. > > - Philip > > PS. If someone thinks a recently posted draft meets this criteria, > then I would appreciate a pointer to it. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 13:39:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isjcw-0006aG-Kc; Thu, 15 Nov 2007 13:39:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isjcu-0006Us-NU for p2psip@ietf.org; Thu, 15 Nov 2007 13:39:44 -0500 Received: from chip2og51.obsmtp.com ([64.18.13.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isjco-0001tH-9G for p2psip@ietf.org; Thu, 15 Nov 2007 13:39:44 -0500 Received: from source ([192.150.11.134]) by chip2ob51.postini.com ([64.18.5.12]) with SMTP; Thu, 15 Nov 2007 10:39:29 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAFIbNOP000809; Thu, 15 Nov 2007 10:37:23 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAFIdPFX016844; Thu, 15 Nov 2007 10:39:27 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 10:39:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Thu, 15 Nov 2007 10:39:24 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE2D1@namail5.corp.adobe.com> In-Reply-To: <9C8C25BD-E1C7-4940-9A42-5261CA150950@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Thread-Index: Acgnl5hNR6IuZgYPSzeHfWvLQXIIZAAHXNrg References: <00e501c8272a$905b2060$5105a40a@china.huawei.com><7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca><0aef01c8278a$b68ad0e0$ad600240@china.huawei.com> <9C8C25BD-E1C7-4940-9A42-5261CA150950@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" , "P2PSIP Mailing List" X-OriginalArrivalTime: 15 Nov 2007 18:39:25.0861 (UTC) FILETIME=[D9058D50:01C827B6] X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Phil, > but none of us are strong advocates of clients, Wrong! Some of us are strong advocates of clients. Your earlier proposal was however very good: * Describe a problem that you want to solve using clients. * Present a convincing argument why that problem is interesting. * Present a convincing argument why that problem cannot be solved using peers. Henry -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Thursday, November 15, 2007 6:57 AM To: P2PSIP Mailing List Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior On 15-Nov-07, at 08:23 , Spencer Dawkins wrote: > > (HINT: the application scenarios draft includes analysis about =20 > whether each scenario seems to require "P2P Client Support" and/or =20 > "Interoperation with CS-SIP" - I don't think any of the draft =20 > authors are prejudiced against clients, but none of us are strong =20 > advocates of clients, so it would be good to have client advocates =20 > develop opinions about whether that analysis is reasonable or not) I agree. Right now, I think that most of the most active participants =20 in the group are in the "Show me the money" camp. That is, we are not =20 opposed to them, but we want to see a good argument for them. Some people have said "Mobile devices (e.g., handsets) cannot be =20 peers for battery reasons or storage reasons or ...". But these are =20 just words in the corridor, and not written down. And I keep hearing =20 others say "Nonsense, we CAN have mobile peers". > >> From the Prague meeting minutes: > > P2PSIP Client Discussion, Spencer Dawkins > > What are Clients? Not garden variety SIP UACs, nor the equivalent of > "peers." > > Issue: Clients as storage nodes. No credible use case so far; =20 > deferred. > > [ Discussion ensued at mic. > > Philip: Why do we need P2PSIP clients? The answer will drive =20 > whether or > not we use them. > > Brian Rosen (as individual): I don't understand P2PSIP clients. =20 > We need > to get rid of it and focus on normal SIP clients. > > Philip: Those that want P2PSIP Clients need to come up with a good =20 > use > case by Chicago IETF. If they do not come up by then, the P2PSIP =20 > Clients > go away. ] > > Hum - Should the wg work on the normal garden variety SIP UA =20 > connected to > the DHT via some box (a SIP proxy coupled to a peer)? > > [ Hum indicated yes. > Those that want a P2PSIP Client distinct from a normal SIP client =20 > need to > get together and work on use cases. ] > Yup. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 14:59:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iskrg-0005rZ-MX; Thu, 15 Nov 2007 14:59:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iskrf-0005pz-IB for p2psip@ietf.org; Thu, 15 Nov 2007 14:59:03 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-08.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iskrc-0004dI-0s for p2psip@ietf.org; Thu, 15 Nov 2007 14:59:03 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Iskrb-0002nk-1C; Thu, 15 Nov 2007 14:58:59 -0500 In-Reply-To: <20071114215212.A3F3033C21@delta.rtfm.com> References: <20071113144604.8CF0733C59@delta.rtfm.com> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> <473B32EF.7010909@it.uc3m.es> <4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com> <20071114215212.A3F3033C21@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8818C006-8EF5-4E6D-97B2-D0E176469201@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities Date: Thu, 15 Nov 2007 15:00:11 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 14-Nov-07, at 16:52 , Eric Rescorla wrote: > > I don't think the term "secure" is very useful here. Let's rather > talk about how hard it is to mount various attacks. > > In a centralized system, where the peer-ids are centrally assigned, in > order to get a peer-id in a portion of the overlay 1/N the size of the > overlay requires N queries to the central enrollment server. In a > decentralized system where you get to generate your own peer-ids--even > if you have no control over the peer-ids you generate other than being > able to generate a new random one, it requires one query. That's just > the basic math of the situation. > > The implication here is that: > 1. Decentralized systems and centralized systems with no rate > limiting are vulnerable to both chosen peer ID and Sybil attacks, > but decentralized systems are moreso. > > 2. Centralized systems with even moderate rate limiting are > vulnerable to Sybil but not chosen peer ID attacks. > > 3. Centralized systems with good rate limiting are not vulnerable > to either attack. What about a system where a node: * Creates a public/private key pair and generates an associated identifier, say a HIT, * Makes a one-time call to a central system to get a certificate for that HIT providing some sort of proof of identity, * Uses the certificate to join various overlays, * Uses the HIT as its peer id in each overlay. In this way, the node demonstrates that it has this identity (the HIT) which it is consistently using as its peer id in all overlays that it joins. However, we don't need a central enrollment server for each overlay. In fact, the central server doesn't even need to be accessible when the node joins the overlay. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 15:15:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isl7F-0001Us-OT; Thu, 15 Nov 2007 15:15:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isl7E-0001UI-8Y for p2psip@ietf.org; Thu, 15 Nov 2007 15:15:08 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isl7A-00059v-Uw for p2psip@ietf.org; Thu, 15 Nov 2007 15:15:08 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E0F1533C21; Thu, 15 Nov 2007 12:10:12 -0800 (PST) Date: Thu, 15 Nov 2007 12:10:11 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities In-Reply-To: <8818C006-8EF5-4E6D-97B2-D0E176469201@magma.ca> References: <20071113144604.8CF0733C59@delta.rtfm.com> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> <473B32EF.7010909@it.uc3m.es> <4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com> <20071114215212.A3F3033C21@delta.rtfm.com> <8818C006-8EF5-4E6D-97B2-D0E176469201@magma.ca> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071115201012.E0F1533C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Thu, 15 Nov 2007 15:00:11 -0500, Philip Matthews wrote: > > > On 14-Nov-07, at 16:52 , Eric Rescorla wrote: > > > > > I don't think the term "secure" is very useful here. Let's rather > > talk about how hard it is to mount various attacks. > > > > In a centralized system, where the peer-ids are centrally assigned, in > > order to get a peer-id in a portion of the overlay 1/N the size of the > > overlay requires N queries to the central enrollment server. In a > > decentralized system where you get to generate your own peer-ids--even > > if you have no control over the peer-ids you generate other than being > > able to generate a new random one, it requires one query. That's just > > the basic math of the situation. > > > > The implication here is that: > > 1. Decentralized systems and centralized systems with no rate > > limiting are vulnerable to both chosen peer ID and Sybil attacks, > > but decentralized systems are moreso. > > > > 2. Centralized systems with even moderate rate limiting are > > vulnerable to Sybil but not chosen peer ID attacks. > > > > 3. Centralized systems with good rate limiting are not vulnerable > > to either attack. > > > What about a system where a node: > * Creates a public/private key pair and generates an associated > identifier, say a HIT, > * Makes a one-time call to a central system to get a certificate for > that HIT > providing some sort of proof of identity, > * Uses the certificate to join various overlays, > * Uses the HIT as its peer id in each overlay. > > In this way, the node demonstrates that it has this identity (the > HIT) which it > is consistently using as its peer id in all overlays that it joins. > However, we don't need a central enrollment server for each overlay. > In fact, the central server doesn't even need to be accessible > when the node joins the overlay. Unfortunately, this doesn't change the parameters of the attack: i.e., you can still offline compute any HIT you want and then make a one-time call to the central system. In order to stop that, you need the peer-id to be unpredictable from the perspective of the attacker. That turns it into an n-query problem. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 15:40:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslVM-0008JD-J7; Thu, 15 Nov 2007 15:40:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IslVK-0008Cd-MS for p2psip@ietf.org; Thu, 15 Nov 2007 15:40:02 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-06.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IslVE-0005mk-PQ for p2psip@ietf.org; Thu, 15 Nov 2007 15:40:02 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-06.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IslVE-0007NZ-1n; Thu, 15 Nov 2007 15:39:56 -0500 In-Reply-To: <20071115201012.E0F1533C21@delta.rtfm.com> References: <20071113144604.8CF0733C59@delta.rtfm.com> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> <473B32EF.7010909@it.uc3m.es> <4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com> <20071114215212.A3F3033C21@delta.rtfm.com> <8818C006-8EF5-4E6D-97B2-D0E176469201@magma.ca> <20071115201012.E0F1533C21@delta.rtfm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities Date: Thu, 15 Nov 2007 15:41:09 -0500 To: Eric Rescorla X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 15-Nov-07, at 15:10 , Eric Rescorla wrote: >> >> What about a system where a node: >> * Creates a public/private key pair and generates an associated >> identifier, say a HIT, >> * Makes a one-time call to a central system to get a certificate for >> that HIT >> providing some sort of proof of identity, >> * Uses the certificate to join various overlays, >> * Uses the HIT as its peer id in each overlay. >> >> In this way, the node demonstrates that it has this identity (the >> HIT) which it >> is consistently using as its peer id in all overlays that it joins. >> However, we don't need a central enrollment server for each overlay. >> In fact, the central server doesn't even need to be accessible >> when the node joins the overlay. > > Unfortunately, this doesn't change the parameters of the attack: i.e., > you can still offline compute any HIT you want and then make a > one-time call to the central system. > > In order to stop that, you need the peer-id to be unpredictable > from the perspective of the attacker. That turns it into an n-query > problem. The point is that the node has _one_ HIT which it uses in multiple overlays. So this HIT might be in a sensitive position for some time in one overlay, but in a non-sensitive position in the next overlay (or later on in the first). Say "A" is the attacker. He has his HIT (also "A"), and can join various overlays. He can join with B and C, or he can join with C,D,E and F. But in both overlays he has to use his HIT "A". (Enforced by the certificate, which has the HIT inside it). - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 16:13:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ism1j-0003hk-Uu; Thu, 15 Nov 2007 16:13:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ism1j-0003fC-3A for p2psip@ietf.org; Thu, 15 Nov 2007 16:13:31 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ism1i-0008Ps-LK for p2psip@ietf.org; Thu, 15 Nov 2007 16:13:31 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id AF46733C21; Thu, 15 Nov 2007 13:08:38 -0800 (PST) Date: Thu, 15 Nov 2007 13:08:37 -0800 From: Eric Rescorla To: Philip Matthews Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities In-Reply-To: References: <20071113144604.8CF0733C59@delta.rtfm.com> <473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com> <473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com> <1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu> <473B32EF.7010909@it.uc3m.es> <4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com> <20071114215212.A3F3033C21@delta.rtfm.com> <8818C006-8EF5-4E6D-97B2-D0E176469201@magma.ca> <20071115201012.E0F1533C21@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071115210838.AF46733C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Thu, 15 Nov 2007 15:41:09 -0500, Philip Matthews wrote: > > > On 15-Nov-07, at 15:10 , Eric Rescorla wrote: > > >> > >> What about a system where a node: > >> * Creates a public/private key pair and generates an associated > >> identifier, say a HIT, > >> * Makes a one-time call to a central system to get a certificate for > >> that HIT > >> providing some sort of proof of identity, > >> * Uses the certificate to join various overlays, > >> * Uses the HIT as its peer id in each overlay. > >> > >> In this way, the node demonstrates that it has this identity (the > >> HIT) which it > >> is consistently using as its peer id in all overlays that it joins. > >> However, we don't need a central enrollment server for each overlay. > >> In fact, the central server doesn't even need to be accessible > >> when the node joins the overlay. > > > > Unfortunately, this doesn't change the parameters of the attack: i.e., > > you can still offline compute any HIT you want and then make a > > one-time call to the central system. > > > > In order to stop that, you need the peer-id to be unpredictable > > from the perspective of the attacker. That turns it into an n-query > > problem. > > The point is that the node has _one_ HIT which it uses in multiple > overlays. > So this HIT might be in a sensitive position for some time in one > overlay, > but in a non-sensitive position in the next overlay (or later on in > the first). > > Say "A" is the attacker. He has his HIT (also "A"), and can join > various overlays. > He can join with B and C, or he can join with C,D,E and F. > But in both overlays he has to use his HIT "A". (Enforced by the > certificate, > which has the HIT inside it). Yes, I understand this point, but it doesn't really help, since there's nothing stopping the node from getting multiple HITs, one for each overlay. It still only requires one query per overlay the node wishes to attack. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 17:07:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsmsH-0008Fs-Ez; Thu, 15 Nov 2007 17:07:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsmsF-0007yf-HT for p2psip@ietf.org; Thu, 15 Nov 2007 17:07:47 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsmsF-00020X-3d for p2psip@ietf.org; Thu, 15 Nov 2007 17:07:47 -0500 X-IronPort-AV: E=Sophos;i="4.21,422,1188792000"; d="scan'208";a="78967072" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 15 Nov 2007 17:07:44 -0500 X-IronPort-AV: E=Sophos;i="4.21,422,1188792000"; d="scan'208";a="125319155" Received: from unknown (HELO 306181ANEX3.global.avaya.com) ([135.9.6.104]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 15 Nov 2007 17:07:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities Date: Thu, 15 Nov 2007 15:07:01 -0700 Message-ID: <166476A2803C3B4994D744DFD57A942F561B2A@306181ANEX3.global.avaya.com> In-Reply-To: <20071115210838.AF46733C21@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities Thread-Index: AcgnzGspu7E27d1oSc6Tg/2vYGQEIAABPwBQ References: <20071113144604.8CF0733C59@delta.rtfm.com><473ADC5C.4070101@it.uc3m.es> <473B06F4.9060904@alcatel-lucent.com><473B0EF5.2060807@it.uc3m.es> <473B17D1.6030705@alcatel-lucent.com><1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu><473B32EF.7010909@it.uc3m.es><4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com><20071114215212.A3F3033C21@delta.rtfm.com><8818C006-8EF5-4E6D-97B2-D0E176469201@magma.ca><20071115201012.E0F1533C21@delta.rtfm.com> <20071115210838.AF46733C21@delta.rtfm.com> From: "Palanisamy, Kandasamy (Kandasamy)" To: "P2PSIP Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The central enrollment server that verifies the identity of the node and issues the certificate should prevent it from getting multiple HITs (should that be the policy). If chain of trust of the joiner's certificate is verified to the root certificate of the central enrollment at the time of joining, it would make sure the joiner is authentic. Kand -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Thursday, November 15, 2007 1:09 PM To: Philip Matthews Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities At Thu, 15 Nov 2007 15:41:09 -0500, Philip Matthews wrote: >=20 >=20 > On 15-Nov-07, at 15:10 , Eric Rescorla wrote: >=20 > >> > >> What about a system where a node: > >> * Creates a public/private key pair and generates an associated=20 > >> identifier, say a HIT, > >> * Makes a one-time call to a central system to get a certificate=20 > >> for that HIT > >> providing some sort of proof of identity, > >> * Uses the certificate to join various overlays, > >> * Uses the HIT as its peer id in each overlay. > >> > >> In this way, the node demonstrates that it has this identity (the > >> HIT) which it > >> is consistently using as its peer id in all overlays that it joins. > >> However, we don't need a central enrollment server for each overlay. > >> In fact, the central server doesn't even need to be accessible when > >> the node joins the overlay. > > > > Unfortunately, this doesn't change the parameters of the attack:=20 > > i.e., you can still offline compute any HIT you want and then make a > > one-time call to the central system. > > > > In order to stop that, you need the peer-id to be unpredictable from > > the perspective of the attacker. That turns it into an n-query=20 > > problem. >=20 > The point is that the node has _one_ HIT which it uses in multiple=20 > overlays. > So this HIT might be in a sensitive position for some time in one=20 > overlay, but in a non-sensitive position in the next overlay (or later > on in the first). >=20 > Say "A" is the attacker. He has his HIT (also "A"), and can join=20 > various overlays. > He can join with B and C, or he can join with C,D,E and F. > But in both overlays he has to use his HIT "A". (Enforced by the=20 > certificate, which has the HIT inside it). Yes, I understand this point, but it doesn't really help, since there's nothing stopping the node from getting multiple HITs, one for each overlay. It still only requires one query per overlay the node wishes to attack. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 15 17:10:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ismua-0005Cs-6t; Thu, 15 Nov 2007 17:10:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsmuY-0005Aw-FZ for p2psip@ietf.org; Thu, 15 Nov 2007 17:10:10 -0500 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsmuT-0000Ee-IT for p2psip@ietf.org; Thu, 15 Nov 2007 17:10:10 -0500 Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp.uc3m.es (Postfix) with ESMTP id 4E9AC2101E4; Thu, 15 Nov 2007 23:08:59 +0100 (CET) Received: from 88.pool85-52-161.static.orange.es(88.pool85-52-161.static.orange.es [85.52.161.88]) by webcartero01.uc3m.es(Horde MIME library) with HTTP; Thu, 15 Nov 2007 23:08:56 +0100 Message-ID: <20071115230856.levyxbvl8oskcs4c@webcartero01.uc3m.es> Date: Thu, 15 Nov 2007 23:08:56 +0100 From: RUBEN CUEVAS RUMIN To: Eric Rescorla Subject: Re: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities References: <20071113144604.8CF0733C59@delta.rtfm.com><473ADC5C.4070101@it.u c3m.es><473B06F4.9060904@alcatel-lucent.com><473B0EF5.2060807@it.uc3m.es>< 473B17D1.6030705@alcatel-lucent.com><1D674D8A-9EBC-4000-96E8-5479D2AD4743@c s.columbia.edu><473B32EF.7010909@it.uc3m.es><4d4304a00711141117n553f85e9j4a e8c7dcca7034ac@mail.gmail.com><20071114215212.A3F3033C21@delta.rtfm.com><8818C006-8EF5-4E6D-97B2-D0E176 469201@magma.ca><20071115201012.E0F1533C21@delta.rtfm.com><20071115210838.AF46733C21@delta.rtfm.com> In-Reply-To: <20071115210838.AF46733C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-15.1121 TC:02 TRN:66 TV:5.0.1023(15548.001) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Rescorla dijo: > At Thu, 15 Nov 2007 15:41:09 -0500, > Philip Matthews wrote: >> >> >> On 15-Nov-07, at 15:10 , Eric Rescorla wrote: >> >> >> >> >> What about a system where a node: >> >> * Creates a public/private key pair and generates an associated >> >> identifier, say a HIT, >> >> * Makes a one-time call to a central system to get a certificate for >> >> that HIT >> >> providing some sort of proof of identity, >> >> * Uses the certificate to join various overlays, >> >> * Uses the HIT as its peer id in each overlay. >> >> >> >> In this way, the node demonstrates that it has this identity (the >> >> HIT) which it >> >> is consistently using as its peer id in all overlays that it joins. >> >> However, we don't need a central enrollment server for each overlay. >> >> In fact, the central server doesn't even need to be accessible >> >> when the node joins the overlay. >> > >> > Unfortunately, this doesn't change the parameters of the attack: i.e., >> > you can still offline compute any HIT you want and then make a >> > one-time call to the central system. >> > >> > In order to stop that, you need the peer-id to be unpredictable >> > from the perspective of the attacker. That turns it into an n-query >> > problem. >> >> The point is that the node has _one_ HIT which it uses in multiple >> overlays. >> So this HIT might be in a sensitive position for some time in one >> overlay, >> but in a non-sensitive position in the next overlay (or later on in >> the first). >> >> Say "A" is the attacker. He has his HIT (also "A"), and can join >> various overlays. >> He can join with B and C, or he can join with C,D,E and F. >> But in both overlays he has to use his HIT "A". (Enforced by the >> certificate, >> which has the HIT inside it). > > Yes, I understand this point, but it doesn't really help, since > there's nothing stopping the node from getting multiple HITs, > one for each overlay. It still only requires one query per > overlay the node wishes to attack. > > -Ekr I agree. The use of HITs (or other autogenerated Peer-ID) makes the attack easier (than in the case of central entity) since the attacker can calculate the HITs offline (which is something really fast with the current CPU capacity) until get the neccesary HIT to perform the attack. Then, it asks for the certificate and the attack is succesfull. On the other hand, in the central solution the attacker needs to obtain multiples (lets say N) Peer-IDs from the CA until get the valid one. If the process to obtain the Peer-ID takes s second. The attacker needs N*s seconds to perform the attack. In the case of the HITs, the calculation of N pairs Public/Private case would be a matter of one second or few seconds and just one s second to obtain the certificate from the CA. I can just identify one scheme where the autogenerated Peer-IDs can be useful. This is if the Peer-ID is related to some verifiable and unique external data as could be the user-name. I mean, if you have a user-name and your Peer-ID is the hash(user-name) you cannot obtain more Peer-IDs with this user-name, since you cannot match a different user name with this Peer-ID and any other node can discover you if try to use a different Peer-ID than the one assigned to your user-name. However this have many implications depending on the proposed scenarios. If user-names are obtained after paying some amount of money, then this scheme could be considered. But if the user-name can be freely obtained, then we are in the same case as before. Rub=E9n. > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Universidad Carlos III de Madrid _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 01:44:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsuwD-0003XC-RQ; Fri, 16 Nov 2007 01:44:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsuwB-0003Rs-6r for p2psip@ietf.org; Fri, 16 Nov 2007 01:44:23 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsuwA-0000Oc-Fj for p2psip@ietf.org; Fri, 16 Nov 2007 01:44:23 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL009BG6PWFU@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 14:44:20 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL006BF6PW4N@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 14:44:20 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRL0024B6PSDE@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 14:44:20 +0800 (CST) Date: Fri, 16 Nov 2007 14:44:16 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> To: 'Philip Matthews' Message-id: <01b501c8281c$1b655440$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcgnhbDGT+vhk4vuTweHniaeWvDybgAki+SQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: 'Henry Sinnreich' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline... Best regards, Hewen > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: 2007?11?15? 20:49 > To: Zheng Hewen > Cc: 'Eunsoo Shim'; 'Victor Pascual ??vila'; 'Henry > Sinnreich'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > On 14-Nov-07, at 20:55 , Zheng Hewen wrote: > > > Hi, > > > > In Reference model defined in the Concept document, there are > > mainly two types of nodes: peers and clients with SIP UA. > > Further, there are two types of peers: peers with some SIP > entity and > > peers without any SIP entity. > > But from the contribution to P2PSIP overlay network, we > can think > > that there are mainly three types of nodes: peers (participating in > > overlay, contributing storage capacity), clients (only contributing > > storage capacity to their associated > > peers) and ordinary SIP UAs (without any contribution), is my > > understanding correct? > > Right now, the reference model identifies three types of > nodes: (a) peers, (b) clients, and (c) SIP UAs that attach > via an proxy. > [Hewen] "Clients" and "SIP UAs" are nodes with SIP UA, the only difference between them is that clients attach peers WITHOUT any SIP entity but "SIP UAs" attach peers WITH SIP entity (proxy/registrar), but I do agree with your opinion. > > Certainly, ordinary SIP UAs usually are regarded as > P2PSIP clients, > > and essentially SIP usually is regarded one type of service over > > P2PSIP overlay layer. > > This is not actually true. Right now, the concepts draft says > that defines the client protocol as something OTHER than SIP, > in order to distinguish (b) and (c) above. > [Hewen] Support to use clients to distinguish the attachment relations. > > I think that we need update the Section 5.3 if we reach the > > agreement about P2PSIP client character according to the Reference > > model, any comment? > > Yes. Once we reach agreement on what a client should be, a > number of sections in the Concepts draft will be to be rewritten. > > I am still waiting for that agreement. [Hewen] Hope we can reach agreement in mail list or in Vancouver. I personally think that it is time to clarify P2PSIP clients' characters. I do not see any doubt about the existence of P2PSIP clients in the mail list, any comment? Do you think that the third alternative is rational when we think that P2PSIP clients are non-overlay-routing nodes in IETF69? > > - Philip > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 02:31:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isvfg-0002Hm-RI; Fri, 16 Nov 2007 02:31:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isvfg-0002Hb-8M for p2psip@ietf.org; Fri, 16 Nov 2007 02:31:24 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isvfe-0002qp-Sr for p2psip@ietf.org; Fri, 16 Nov 2007 02:31:24 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL00L068W5OT@szxga01-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 15:31:17 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL000QF8W37H@szxga01-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 15:31:17 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRL00E5I8VZ6F@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 15:31:15 +0800 (CST) Date: Fri, 16 Nov 2007 15:31:11 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <7b683f3f0711150720p300362fdg25aebe9a8377ac38@mail.gmail.com> To: 'Eunsoo Shim' , 'Spencer Dawkins' Message-id: <01c601c82822$a9bdda90$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acgnmy96JHlycePXRBiN48DCUq+lsgAhTthg X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Great, essentially there are some nodes which are not eligible or willing to act as peers. From the viewpoint of P2PSIP overlay network stableness, it is very helpful when regarding those nodes frequently joining/leaving overlay as P2PSIP clients. Further, it is more convenient to manage P2PSIP overlay network and provision services over the overlay network when regarding nodes from some users as P2PSIP clients. We can have mobile peers, but we have more mobile clients, here is a practical example of P2PSIP in mobile communication, please check the URL for the detailed info (http://www3.informatik.uni-wuerzburg.de/mp2p2007/slides/mp2p_5.pdf). Best regards, Hewen > -----Original Message----- > From: Eunsoo Shim [mailto:eunsooshim@gmail.com] > Sent: 2007?11?15? 23:21 > To: Spencer Dawkins > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > I read that some people think we don't need Client node types. > Removing Client node types has the following consequences I > can think of now: > - A SIP UA node that is not a Peer must be attached to a Peer > that is coupled to SIP Proxy entity. (please see the > difference between 'node' > and 'entity'.). In other words, to support SIP UA nodes to > access the overlay, many (probably most) Peers should be > coupled to SIP Proxy entities. It is an unnecessary > requirement for Peers if we define Client node types. > Furthermore, I'd prefer to use the overlay just for looking > up the location of my callee rather than transport my INVITE > messages through the overlay considering the a Proxy entity > running on a Peer may not be so trustworthy. By removing the > possibility of a node to be a Client coupled with SIP UA > entity, we are enforcing any non-Peer SIP UA node to > transport INVITE messages through Proxies running on Peers. > - If we want other types of non-Peer nodes to be able to > access the overlay, we will have to require Peers to > implement other entities. > Even though we want to focus on scenarios using SIP, we > already agreed that it would be better to make the overlay > generic enough to support non-SIP applications as long as the > overlay can support SIP applications well. Here is a non-SIP > application scenario where Client node type is useful. A > mobile device that uses the overlay for asynchronous > messaging or small file (eg. small resolution photos) > sharing. None of the applications use SIP UA. Such mobile > device would better be a Client than a Peer. Why would we > want to prohibit this kind of application scenarios? > > Thanks. > > Eunsoo > > On Nov 15, 2007 8:23 AM, Spencer Dawkins > wrote: > > Great minds think alike. Philip just posted a request for a > draft on > > client requirements. > > > > Just to agree with Philip on a couple of specifics... > > > > From: "Philip Matthews" > > > > > On 14-Nov-07, at 20:55 , Zheng Hewen wrote: > > > > > >> Hi, > > >> > > >> In Reference model defined in the Concept document, > there are > > >> mainly two types of nodes: peers and clients with SIP UA. > > >> Further, there are two types of peers: peers with some > SIP entity > > >> and peers without any SIP entity. > > >> But from the contribution to P2PSIP overlay network, we can > > >> think that there are mainly three types of nodes: peers > > >> (participating in overlay, contributing storage > capacity), clients > > >> (only contributing storage capacity to their associated > > >> peers) and ordinary SIP UAs (without any contribution), is my > > >> understanding correct? > > > > > > Right now, the reference model identifies three types of > nodes: (a) > > > peers, (b) clients, and (c) SIP UAs that attach via an proxy. > > > > We discussed the "clients contributing storage capacity" idea just > > before the Prague IETF. I'm still not sure we have > agreement on what > > clients are (beyond "nodes that speak a logical subset of the peer > > protocol"), and I'm pretty sure that we don't have agreement that > > clients contribute storage capacity. > > > > >> Certainly, ordinary SIP UAs usually are regarded as P2PSIP > > >> clients, and essentially SIP usually is regarded one type of > > >> service over P2PSIP overlay layer. > > > > > > This is not actually true. Right now, the concepts draft > says that > > > defines the client protocol as something OTHER than SIP, > in order to > > > distinguish (b) and (c) above. > > > > Philip is correct here. The current version of the application > > scenarios draft > > > (http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.t > > xt) distinguishes between these cases as follows: > > > > P2P Client Support: Whether the overlay need to support > a P2P Client > > protocol, i.e., whether the overlay contains P2P Clients as > > well as Peers. > > Interoperation with CS-SIP: Whether the overlay must > also interact > > with legacy SIP clients and SIP proxies. > > Note that one or more peers in the overlay may > also act as PSTN > > gateways. > > > > (HINT: the application scenarios draft includes analysis > about whether > > each scenario seems to require "P2P Client Support" and/or > > "Interoperation with CS-SIP" - I don't think any of the > draft authors > > are prejudiced against clients, but none of us are strong > advocates of > > clients, so it would be good to have client advocates > develop opinions > > about whether that analysis is reasonable or not) > > > > >> I think that we need update the Section 5.3 if we reach the > > >> agreement about P2PSIP client character according to the > Reference > > >> model, any comment? > > > > > > Yes. Once we reach agreement on what a client should be, > a number of > > > sections in the Concepts draft will be to be rewritten. > > > > > > I am still waiting for that agreement. > > > > David and Brian asked me to lead discussion on clients in > Prague (my > > slides are at > > http://www3.ietf.org/proceedings/07mar/slides/p2psip-6.pdf, > meeting minutes are at > http://www3.ietf.org/proceedings/07mar/minutes/p2psip.html). > > > > I'd summarize the sense of the room was in Prague as (1) at > that time, > > we did not have creditable use cases ("application scenarios") for > > clients contributing storage apacity, and (2) we didn't > have agreement > > within the working group on what clients were. > > > > I don't believe the chairs tried to verify the sense of the room on > > the mailing list after the meeting, so we can't say "the > working group > > has consensus" about these points, but that's the way things were > > headed in the face-to-face meeting. > > > > Several people in the room at Prague raised their hands and > said they > > would discuss clients privately. Did that happen? If it > did, we need to see text. > > If it didn't, we need to postpone discussion of clients > until it does > > happen. > > > > IMO. > > > > Thanks, > > > > Spencer > > > > >From the Prague meeting minutes: > > > > P2PSIP Client Discussion, Spencer Dawkins > > > > What are Clients? Not garden variety SIP UACs, nor the > equivalent of > > "peers." > > > > Issue: Clients as storage nodes. No credible use case so > far; deferred. > > > > [ Discussion ensued at mic. > > > > Philip: Why do we need P2PSIP clients? The answer will > drive whether or > > not we use them. > > > > Brian Rosen (as individual): I don't understand P2PSIP > clients. We need > > to get rid of it and focus on normal SIP clients. > > > > Philip: Those that want P2PSIP Clients need to come up > with a good use > > case by Chicago IETF. If they do not come up by then, > the P2PSIP Clients > > go away. ] > > > > Hum - Should the wg work on the normal garden variety SIP > UA connected to > > the DHT via some box (a SIP proxy coupled to a peer)? > > > > [ Hum indicated yes. > > Those that want a P2PSIP Client distinct from a normal > SIP client need to > > get together and work on use cases. ] > > > > > > > > > > > > -- > Eunsoo > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 02:34:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsviP-0007U2-2Q; Fri, 16 Nov 2007 02:34:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsviO-0007Rz-96 for p2psip@ietf.org; Fri, 16 Nov 2007 02:34:12 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isvi8-0007w4-PF for p2psip@ietf.org; Fri, 16 Nov 2007 02:34:12 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL00A9K907N8@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 15:33:44 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL006O9907HG@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 15:33:43 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRL002X3903DE@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 15:33:43 +0800 (CST) Date: Fri, 16 Nov 2007 15:33:39 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] To those interested in P2PSIP clients In-reply-to: <7b683f3f0711150725ofe9eea5j69a77905dc557f58@mail.gmail.com> To: 'Eunsoo Shim' , 'Philip Matthews' Message-id: <01c701c82823$01f021a0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acgnm/OTY4AOpRvVRj6c5qne2+W9EQAhs+gA X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, It's a great work. It seems that we need such a I-D ASAP. Hope to make some contribution. Best regards, Hewen > -----Original Message----- > From: Eunsoo Shim [mailto:eunsooshim@gmail.com] > Sent: 2007?11?15? 23:26 > To: Philip Matthews > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] To those interested in P2PSIP clients > > Hmm, the need for the Client type has been said since November 2005. > Looks like the clock went back to the time in the group. > I may write a draft a couple of pages long if necessary. > Please see one of my previous emails I wrote today about this subject. > Thanks. > > Eunsoo > > On Nov 15, 2007 7:59 AM, Philip Matthews > wrote: > > A word of advice to all those interested in P2PSIP clients: > > > > Please write an internet-draft saying why you want clients. > State the > > problem(s) that clients solve that peers do not. > > > > More specifically: > > * Describe a problem that you want to solve using clients. > > * Present a convincing argument why that problem is interesting. > > * Present a convincing argument why that problem cannot be solved > > using peers. > > > > DO NOT go into the technical minutia of a client protocol. > Just focus > > on convincing people that the problem is worthwhile solving > and that > > some model of clients would be the best way to solve it. > > > > The WG chairs requested this document at the Prague meeting in the > > spring, but I have yet to see it. > > > > - Philip > > > > PS. If someone thinks a recently posted draft meets this criteria, > > then I would appreciate a pointer to it. > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > Eunsoo > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 02:44:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsvsT-0004qP-Gc; Fri, 16 Nov 2007 02:44:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsvsN-0004fq-J5 for p2psip@ietf.org; Fri, 16 Nov 2007 02:44:32 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsvsE-0008QR-Ho for p2psip@ietf.org; Fri, 16 Nov 2007 02:44:31 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL009A19HNFU@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 15:44:11 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL0016Z9HMCO@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 15:44:11 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRL006Z49HFF9@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 15:44:10 +0800 (CST) Date: Fri, 16 Nov 2007 15:44:02 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D223AE2D1@namail5.corp.adobe.com> To: 'Henry Sinnreich' , 'Philip Matthews' , 'P2PSIP Mailing List' Message-id: <01ce01c82824$77b5dc80$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acgnl5hNR6IuZgYPSzeHfWvLQXIIZAAHXNrgABuqE+A= X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline... Best regards, Hewen > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: 2007?11?16? 2:39 > To: Philip Matthews; P2PSIP Mailing List > Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > Phil, > > > but none of us are strong advocates of clients, > > Wrong! > > Some of us are strong advocates of clients. [Hewen] Support. > > Your earlier proposal was however very good: > > * Describe a problem that you want to solve using clients. > * Present a convincing argument why that problem is interesting. [Hewen] Agree. > * Present a convincing argument why that problem cannot be > solved using peers. > [Hewen] IMHO, it seems strange, Peers is stronger than clients in P2PSIP overlay network. Do you think that there is something clients can do but peers can't? Those are some nodes which are not able and/or eligible to act as peers in fact. > Henry > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Thursday, November 15, 2007 6:57 AM > To: P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > On 15-Nov-07, at 08:23 , Spencer Dawkins wrote: > > > > > (HINT: the application scenarios draft includes analysis about > > whether each scenario seems to require "P2P Client Support" and/or > > "Interoperation with CS-SIP" - I don't think any of the draft > > authors are prejudiced against clients, but none of us are strong > > advocates of clients, so it would be good to have client advocates > > develop opinions about whether that analysis is reasonable or not) > > I agree. Right now, I think that most of the most active > participants > in the group are in the "Show me the money" camp. That is, we > are not > opposed to them, but we want to see a good argument for them. > > Some people have said "Mobile devices (e.g., handsets) cannot be > peers for battery reasons or storage reasons or ...". But these are > just words in the corridor, and not written down. And I keep hearing > others say "Nonsense, we CAN have mobile peers". > > > > > > > > >> From the Prague meeting minutes: > > > > P2PSIP Client Discussion, Spencer Dawkins > > > > What are Clients? Not garden variety SIP UACs, nor the > equivalent of > > "peers." > > > > Issue: Clients as storage nodes. No credible use case so far; > > deferred. > > > > [ Discussion ensued at mic. > > > > Philip: Why do we need P2PSIP clients? The answer will drive > > whether or > > not we use them. > > > > Brian Rosen (as individual): I don't understand P2PSIP clients. > > We need > > to get rid of it and focus on normal SIP clients. > > > > Philip: Those that want P2PSIP Clients need to come up > with a good > > use > > case by Chicago IETF. If they do not come up by then, the P2PSIP > > Clients > > go away. ] > > > > Hum - Should the wg work on the normal garden variety SIP UA > > connected to > > the DHT via some box (a SIP proxy coupled to a peer)? > > > > [ Hum indicated yes. > > Those that want a P2PSIP Client distinct from a normal SIP client > > need to > > get together and work on use cases. ] > > > > Yup. > > - Philip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 05:00:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isxze-0002wd-W5; Fri, 16 Nov 2007 05:00:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isxzd-0002tz-Oe for p2psip@lists.ietf.org; Fri, 16 Nov 2007 05:00:09 -0500 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsxzZ-0007UT-9E for p2psip@lists.ietf.org; Fri, 16 Nov 2007 05:00:09 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id 08A9F2327B3; Fri, 16 Nov 2007 10:52:10 +0100 (CET) Message-ID: <473D684A.1060502@it.uc3m.es> Date: Fri, 16 Nov 2007 10:52:10 +0100 From: =?UTF-8?B?UnViw6luIEN1ZXZhcyBSdW3DrW4=?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: =?UTF-8?B?VmljdG9yIFBhc2N1YWwgw4F2aWxh?= Subject: Re: [P2PSIP] Identity vs Identifier References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> In-Reply-To: <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-22.4065 TC:1F TRN:70 TV:5.0.1023(15548.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Victor Pascual =C3=81vila escribi=C3=B3: > On 15/11/2007, Rub=C3=A9n Cuevas Rum=C3=ADn wrote: > =20 >> Something that I miss on the discussion so far is the concept of "Iden= tity" and "Identifier". >> =20 > > In my understanding -considering concepts document > (draft-ietf-p2psip-concepts-00), section 4- your concept of "identity" > is represented by "User Name" or "Service Name", while concept of > "Identifier" is represented by "Node-ID". > > =20 You are right. The identity is actually the concept referred as=20 "resource" in the draft and the "Identifier" is the "Node-ID" or "Peer-ID= ". My point is that in the discussion is not clear (at least for me) the=20 relationship and implications of this basic parts (from my point of view= ). But, it is just my feeling . >> However, I can also have several identifiers paired to an unique >> identity. For instance, I am on my office and I have my laptop, my PDA= , >> my mobile phone and all of them are joined to the p2psip system. In th= is case maybe I don't want that all my devices were >> part from the p2psip system (since all of them would be consuming >> resources), I would like that only one of them (hopefully the most >> powefull) belongs to the DHT, then it would be a peer. The rest will b= e >> only clients which will be connected through my peer. >> =20 > > In my opinion you are mixing DHT (transport and routing) and SIP > concepts (registering from 'n' UAs). It's true both peer and client > could be coupled with SIP UA, but this should be independent of their > P2P role. > > Please correct me if I'm wrong, > =20 Of course, the concepts are mixed but not because I like but because =20 p2psip architecture requires it. If you have several UA associated to the same user. If I am right, it is=20 pretty likely that all of them are going to use the service offered by=20 the p2psip overlay which are defined in the concepts draft. And we=20 should solve this problem, how several devices (i.e. UA) associated to=20 the same user are going to participate/use the p2psip system. The easiest way is that all of them becomes peers inside the p2psip=20 system. But maybe ithis is not the best solution. I just proposed the=20 possibility of use one of them as Peer and let the others be Clients.=20 This is not new, the new part is that I propose the Peer allowing the=20 rest to access to the p2psip system is not a third one but this=20 associated to the same user. On the other hand, IMO an important problem in the p2psip overlay is=20 that my "resource-ID" (or "resource-IDs") is going to be stored by=20 someone I don't know and (with the solution defined so far) I cannot=20 trust in. This introduce trust and security threads. It would be nice to=20 define a new mechanism which allows the users to store its own=20 "resource-IDs". It is something I am thinking about and I have some=20 ideas if you are interested. Rub=C3=A9n. --=20 Rub=C3=A9n Cuevas Rum=C3=ADn Universidad Carlos III de Madrid Departamento Ingenier=C3=ADa Telem=C3=A1tica Avenida de la Universidad, 30 28911-Legan=C3=A9s (Madrid). Espa=C3=B1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 05:05:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isy58-0005rz-PO; Fri, 16 Nov 2007 05:05:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isy57-0005p0-Q7 for p2psip@ietf.org; Fri, 16 Nov 2007 05:05:49 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isy53-0007nW-Ln for p2psip@ietf.org; Fri, 16 Nov 2007 05:05:49 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL00GUKFZIA6@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 18:04:30 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL006H9FZFHG@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 18:04:30 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRL00CBKFZBGG@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 18:04:27 +0800 (CST) Date: Fri, 16 Nov 2007 18:04:23 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <9C8C25BD-E1C7-4940-9A42-5261CA150950@magma.ca> To: 'Philip Matthews' , 'P2PSIP Mailing List' Message-id: <021d01c82838$107ff500$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acgnl57t6KuTW9TQQpOn7SdpkLsG9wAjkFOw X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline... Best regards, Hewen > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: 2007?11?15? 22:57 > To: P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > On 15-Nov-07, at 08:23 , Spencer Dawkins wrote: > > > > > (HINT: the application scenarios draft includes analysis > about whether > > each scenario seems to require "P2P Client Support" and/or > > "Interoperation with CS-SIP" - I don't think any of the > draft authors > > are prejudiced against clients, but none of us are strong > advocates of > > clients, so it would be good to have client advocates > develop opinions > > about whether that analysis is reasonable or not) > > I agree. Right now, I think that most of the most active > participants in the group are in the "Show me the money" > camp. That is, we are not opposed to them, but we want to see > a good argument for them. > [Hewen]We are only frank engineers. Sorry for the latest straight discussion if it caused some uncomfortable. I always think that Concept document is a great work. Thanks for the hard efforts from the editors with my sincere respect. > Some people have said "Mobile devices (e.g., handsets) cannot > be peers for battery reasons or storage reasons or ...". But > these are just words in the corridor, and not written down. > And I keep hearing others say "Nonsense, we CAN have mobile peers". > [Hewen] It seems that a formal I-D about P2PSIP clients requirement/character is important and desired, is my understanding correct? > > > > > > > >> From the Prague meeting minutes: > > > > P2PSIP Client Discussion, Spencer Dawkins > > > > What are Clients? Not garden variety SIP UACs, nor the > equivalent of > > "peers." > > > > Issue: Clients as storage nodes. No credible use case so far; > > deferred. > > > > [ Discussion ensued at mic. > > > > Philip: Why do we need P2PSIP clients? The answer will > drive whether > > or not we use them. > > > > Brian Rosen (as individual): I don't understand P2PSIP clients. > > We need > > to get rid of it and focus on normal SIP clients. > > > > Philip: Those that want P2PSIP Clients need to come up with a good > > use case by Chicago IETF. If they do not come up by then, > the P2PSIP > > Clients go away. ] > > > > Hum - Should the wg work on the normal garden variety SIP > UA connected > > to > > the DHT via some box (a SIP proxy coupled to a peer)? > > > > [ Hum indicated yes. > > Those that want a P2PSIP Client distinct from a normal SIP client > > need to get together and work on use cases. ] > > > > Yup. > > - Philip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 05:18:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyGu-0001Hi-V5; Fri, 16 Nov 2007 05:18:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyGp-00014n-E0 for p2psip@ietf.org; Fri, 16 Nov 2007 05:17:55 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsyGl-0008VP-EO for p2psip@ietf.org; Fri, 16 Nov 2007 05:17:55 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL004GKGLKVA@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 18:17:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRL005V6GLHE6@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 18:17:44 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRL00FZQGLE2A@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 18:17:41 +0800 (CST) Date: Fri, 16 Nov 2007 18:17:37 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] To those interested in P2PSIP clients In-reply-to: <7b683f3f0711150725ofe9eea5j69a77905dc557f58@mail.gmail.com> To: 'Eunsoo Shim' , 'Philip Matthews' Message-id: <021e01c82839$e9ebc9d0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acgnm/OTY4AOpRvVRj6c5qne2+W9EQAnPzZg X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, It seems that a formal I-D about P2PSIP clients requirement/character is important and desired. Are you ready to attend IETF70? I think that we can form a draft about P2PSIP client requirements/characters and make a presentation in Vancouver, do you think so? I submitted an I-D about P2PSIP client protocol, you can get it from http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt, any comment is appreciated. Best regards, Hewen > -----Original Message----- > From: Eunsoo Shim [mailto:eunsooshim@gmail.com] > Sent: 2007?11?15? 23:26 > To: Philip Matthews > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] To those interested in P2PSIP clients > > Hmm, the need for the Client type has been said since November 2005. > Looks like the clock went back to the time in the group. > I may write a draft a couple of pages long if necessary. > Please see one of my previous emails I wrote today about this subject. > Thanks. > > Eunsoo > > On Nov 15, 2007 7:59 AM, Philip Matthews > wrote: > > A word of advice to all those interested in P2PSIP clients: > > > > Please write an internet-draft saying why you want clients. > State the > > problem(s) that clients solve that peers do not. > > > > More specifically: > > * Describe a problem that you want to solve using clients. > > * Present a convincing argument why that problem is interesting. > > * Present a convincing argument why that problem cannot be solved > > using peers. > > > > DO NOT go into the technical minutia of a client protocol. > Just focus > > on convincing people that the problem is worthwhile solving > and that > > some model of clients would be the best way to solve it. > > > > The WG chairs requested this document at the Prague meeting in the > > spring, but I have yet to see it. > > > > - Philip > > > > PS. If someone thinks a recently posted draft meets this criteria, > > then I would appreciate a pointer to it. > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > Eunsoo > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 09:58:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2eg-0003OC-Go; Fri, 16 Nov 2007 09:58:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It2ee-0003M4-W8 for p2psip@lists.ietf.org; Fri, 16 Nov 2007 09:58:48 -0500 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It2ed-0000Qv-As for p2psip@lists.ietf.org; Fri, 16 Nov 2007 09:58:48 -0500 Received: by py-out-1112.google.com with SMTP id u77so4237097pyb for ; Fri, 16 Nov 2007 06:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=d2OsHfNLUTeMpy8fA/yj/1VUKTSzYL/cGhZtrw/t+8Q=; b=Yd73ULpsvxglOdxed/SzcDgufQP+PX3lr8WnPQnNtAm9VsU5Hjm0VR8NYLiFzh30Dejc+8+oF2Xlmxnp3/GQOyC87a8Xch3Ue8ZzGTu1M9AeWVOViDX7iSDeEdKC/cLFcuHxhYtu6UO9JBFOCgb9L5RP4xyClUjHlLCotnDIFug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=IJ//QFn/YzOiYvtunWc6E3/neM9NaWqGXPr/ed/M9PNqsxPgTXDWiXtKufA06rZxpMyoV6dKYZQ99Zz9fIPxk/7VUuRkMHsvRsDZlPWyEHqX8+SrbuZd/cnyVMkkm9SBXWAZkMhrIzUPtvqsDdJefhj1G2/1vfUXi+62ZqOXfa0= Received: by 10.65.59.11 with SMTP id m11mr4314011qbk.1195225126698; Fri, 16 Nov 2007 06:58:46 -0800 (PST) Received: by 10.65.180.16 with HTTP; Fri, 16 Nov 2007 06:58:46 -0800 (PST) Message-ID: <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> Date: Fri, 16 Nov 2007 09:58:46 -0500 From: "David A. Bryan" To: rcuevas@it.uc3m.es Subject: Re: [P2PSIP] Identity vs Identifier In-Reply-To: <473D684A.1060502@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> X-Google-Sender-Auth: f29193eedb04e175 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Comments inline: > If you have several UA associated to the same user. If I am right, it is > pretty likely that all of them are going to use the service offered by > the p2psip overlay which are defined in the concepts draft. And we > should solve this problem, how several devices (i.e. UA) associated to > the same user are going to participate/use the p2psip system. > The easiest way is that all of them becomes peers inside the p2psip > system. But maybe ithis is not the best solution. I just proposed the > possibility of use one of them as Peer and let the others be Clients. > This is not new, the new part is that I propose the Peer allowing the > rest to access to the p2psip system is not a third one but this > associated to the same user. I think this is not the right way to layer here -- we are mixing an application level issue (is more than one UA associated with a user) with a routing level issue (is this a peer or client). The two should be independent. Personally, I think as many things as possible should be peers, and if all the devices you are associated with can be peers, they all should act as so, rather than being clients. There is another problem with the approach of a user with multiple devices having one as a peer and the rest as clients. The only reasons that I have seen presented for why a device should be a client rather than a peer in the first place are either the device is behind a NAT and cannot be a good peer, or has some limitation (processor, battery life, etc.) that would motivate being a client instead. Making the assumption that one is a peer and the rest clients assumes that the device becoming a peer is reachable by all the devices. In a LAN this may be true, but I might have 3 UAs, one at home, one at the office, and one a mobile device. All may be on separate networks. Letting each determine if it has adequate connectivity and resources to be a peer makes better sense than imposing an application level decision, in my mind. > On the other hand, IMO an important problem in the p2psip overlay is > that my "resource-ID" (or "resource-IDs") is going to be stored by > someone I don't know and (with the solution defined so far) I cannot > trust in. This introduce trust and security threads. It would be nice to > define a new mechanism which allows the users to store its own > "resource-IDs". It is something I am thinking about and I have some > ideas if you are interested. It would be interesting to hear what you had in mind. In proposals like this people have made here and elsewhere over the last few years, there are numerous problems that arise when each user becomes responsible for their own resources as well. How do you handle replication? How would you maintain information when the user is offline? A meta question would be how clients would work in this scenario, since they are, by definition, not directly accessible. Personally, I think distributed storage, with replication and encrypted, signed resources is the best idea, but I would be interested to hear what you have in mind. David (as individual) > > Rub=E9n. > > -- > Rub=E9n Cuevas Rum=EDn > Universidad Carlos III de Madrid > Departamento Ingenier=EDa Telem=E1tica > Avenida de la Universidad, 30 > 28911-Legan=E9s (Madrid). Espa=F1a > email: rcuevas@it.uc3m.es > Tlf: +34 91-6248859 > Fax: +34 91-6248749 > Web: http://www.it.uc3m.es/~rcuevas > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 10:49:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3RK-0007Lk-Lj; Fri, 16 Nov 2007 10:49:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It3RG-0007IF-UN for p2psip@lists.ietf.org; Fri, 16 Nov 2007 10:49:02 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It3RE-0005dY-2T for p2psip@lists.ietf.org; Fri, 16 Nov 2007 10:49:02 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1It4NB-0001u9-JK; Fri, 16 Nov 2007 10:48:53 -0600 From: "Brian Rosen" To: "'David A. Bryan'" , References: <473C730E.1080004@it.uc3m.es><618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com><473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> Subject: RE: [P2PSIP] Identity vs Identifier Date: Fri, 16 Nov 2007 10:48:19 -0500 Message-ID: <055701c82868$33564220$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgoYTcDBjmYkcoUT/2KSw/mKYlfvwAAqkgg In-Reply-To: <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - lists.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Looks to me like we are having some semantic differences that are = causing us to get wrapped around the axle. I think the concept document describes one kind of entity, a peer, which = is aware of the DHT and participates in it, and two kinds of entities: SIP = UAs and clients that do not directly participate in the DHT, but rather do = so through a peer. The SIP UA uses SIP to communicate with the peer that interworks SIP rendezvous operations to the DHT. We were looking for examples of clients that needed some other protocol to interwork their rendezvous operations to the DHT. It would seem that some want to redefine a client into a subset of a = peer: a entity who is aware of and participates in the DHT, but doesn't store = data, for example. It would seem that most of the proponents of such a notion think that a subset of the base p2p protocol is what such entities use. I think we will have to have two terms that differentiate an entity that = is aware of, and participates directly in the DHT from an entity that does = not. I still don't see an example of a client as in my interpretation of the definition of an entity that is not aware of, and does not directly participate in the DHT. Brian > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com] > Sent: Friday, November 16, 2007 9:59 AM > To: rcuevas@it.uc3m.es > Cc: p2psip@lists.ietf.org > Subject: Re: [P2PSIP] Identity vs Identifier >=20 > Comments inline: >=20 > > If you have several UA associated to the same user. If I am right, = it is > > pretty likely that all of them are going to use the service offered = by > > the p2psip overlay which are defined in the concepts draft. And we > > should solve this problem, how several devices (i.e. UA) associated = to > > the same user are going to participate/use the p2psip system. > > The easiest way is that all of them becomes peers inside the p2psip > > system. But maybe ithis is not the best solution. I just proposed = the > > possibility of use one of them as Peer and let the others be = Clients. > > This is not new, the new part is that I propose the Peer allowing = the > > rest to access to the p2psip system is not a third one but this > > associated to the same user. >=20 > I think this is not the right way to layer here -- we are mixing an > application level issue (is more than one UA associated with a user) > with a routing level issue (is this a peer or client). The two should > be independent. Personally, I think as many things as possible should > be peers, and if all the devices you are associated with can be peers, > they all should act as so, rather than being clients. >=20 > There is another problem with the approach of a user with multiple > devices having one as a peer and the rest as clients. The only reasons > that I have seen presented for why a device should be a client rather > than a peer in the first place are either the device is behind a NAT > and cannot be a good peer, or has some limitation (processor, battery > life, etc.) that would motivate being a client instead. Making the > assumption that one is a peer and the rest clients assumes that the > device becoming a peer is reachable by all the devices. In a LAN this > may be true, but I might have 3 UAs, one at home, one at the office, > and one a mobile device. All may be on separate networks. Letting each > determine if it has adequate connectivity and resources to be a peer > makes better sense than imposing an application level decision, in my > mind. >=20 > > On the other hand, IMO an important problem in the p2psip overlay is > > that my "resource-ID" (or "resource-IDs") is going to be stored by > > someone I don't know and (with the solution defined so far) I cannot > > trust in. This introduce trust and security threads. It would be = nice to > > define a new mechanism which allows the users to store its own > > "resource-IDs". It is something I am thinking about and I have some > > ideas if you are interested. >=20 > It would be interesting to hear what you had in mind. In proposals > like this people have made here and elsewhere over the last few years, > there are numerous problems that arise when each user becomes > responsible for their own resources as well. How do you handle > replication? How would you maintain information when the user is > offline? A meta question would be how clients would work in this > scenario, since they are, by definition, not directly accessible. > Personally, I think distributed storage, with replication and > encrypted, signed resources is the best idea, but I would be > interested to hear what you have in mind. >=20 > David (as individual) >=20 > > > > Rub=E9n. > > > > -- > > Rub=E9n Cuevas Rum=EDn > > Universidad Carlos III de Madrid > > Departamento Ingenier=EDa Telem=E1tica > > Avenida de la Universidad, 30 > > 28911-Legan=E9s (Madrid). Espa=F1a > > email: rcuevas@it.uc3m.es > > Tlf: +34 91-6248859 > > Fax: +34 91-6248749 > > Web: http://www.it.uc3m.es/~rcuevas > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > >=20 >=20 >=20 > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 11:25:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It40Y-0002h5-Hb; Fri, 16 Nov 2007 11:25:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It40X-0002au-A8 for p2psip@lists.ietf.org; Fri, 16 Nov 2007 11:25:29 -0500 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It40S-0000rm-Q4 for p2psip@lists.ietf.org; Fri, 16 Nov 2007 11:25:29 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id C5E8E23A678; Fri, 16 Nov 2007 17:25:23 +0100 (CET) Message-ID: <473DC47C.5030003@it.uc3m.es> Date: Fri, 16 Nov 2007 17:25:32 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: "David A. Bryan" Subject: Re: [P2PSIP] Identity vs Identifier References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> In-Reply-To: <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-18.8014 TC:1F TRN:93 TV:5.0.1023(15550.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org David A. Bryan escribi=F3: > Comments inline: > > =20 >> If you have several UA associated to the same user. If I am right, it = is >> pretty likely that all of them are going to use the service offered by >> the p2psip overlay which are defined in the concepts draft. And we >> should solve this problem, how several devices (i.e. UA) associated to >> the same user are going to participate/use the p2psip system. >> The easiest way is that all of them becomes peers inside the p2psip >> system. But maybe ithis is not the best solution. I just proposed the >> possibility of use one of them as Peer and let the others be Clients. >> This is not new, the new part is that I propose the Peer allowing the >> rest to access to the p2psip system is not a third one but this >> associated to the same user. >> =20 > > I think this is not the right way to layer here -- we are mixing an > application level issue (is more than one UA associated with a user) > with a routing level issue (is this a peer or client). The two should > be independent. Personally, I think as many things as possible should > be peers, and if all the devices you are associated with can be peers, > they all should act as so, rather than being clients. > > There is another problem with the approach of a user with multiple > devices having one as a peer and the rest as clients. The only reasons > that I have seen presented for why a device should be a client rather > than a peer in the first place are either the device is behind a NAT > and cannot be a good peer, or has some limitation (processor, battery > life, etc.) that would motivate being a client instead. Making the > assumption that one is a peer and the rest clients assumes that the > device becoming a peer is reachable by all the devices. In a LAN this > may be true, but I might have 3 UAs, one at home, one at the office, > and one a mobile device. All may be on separate networks. Letting each > determine if it has adequate connectivity and resources to be a peer > makes better sense than imposing an application level decision, in my > mind. > > =20 I agree in almost everything. As you said limited deviced are the candidates to not be a Peer. Then,=20 imagine a simple scenario with two devices associated to the same user=20 name, a non-limited device, e.g. a desktop, and a limited device, e.g. a=20 mobile phone. Then, we can identify the desktop as a potential peer and=20 the mobile phone as a potential client. Lets analyze the different=20 situations: 1- The desktop is reachable (i.e. not firewalled or behind a NAT). It=20 registers in the p2psystem and becomes a Peer. After that, the mobile=20 phone registers on the p2psystems. Since this is a limited device it=20 needs to lookfor a peer to conect with. Then, it can randonmly selects a=20 Peer with the adequate properties (i.e. globally reachable). However,=20 why not try first to select a trustable one? I mean, the mobile phone=20 can launches a search for the resource-id associated to its user-name,=20 and then, it would discover that there is a Peer associated to this user=20 name already registered and which is reachable. Then it would select=20 this one. 2- The desktop is behind a NAT. Then, the mobile phone could choose=20 between connect to this (fully trustable) peer by using some=20 NAT-Traversal strategy or connects to one offering global reachabilty=20 but in principle, not trustable. 3- If it is the mobile phone who registers firstly, then it obviously=20 would choose one globally reachable Peer. And maybe can develop some=20 periodic discovery mechanism in order to discover if the trustable Peer=20 (that is, the desktop on the example) appears at some point. Well, it is just an idea. Why not use trustable Peers if we can do it?. >> On the other hand, IMO an important problem in the p2psip overlay is >> that my "resource-ID" (or "resource-IDs") is going to be stored by >> someone I don't know and (with the solution defined so far) I cannot >> trust in. This introduce trust and security threads. It would be nice = to >> define a new mechanism which allows the users to store its own >> "resource-IDs". It is something I am thinking about and I have some >> ideas if you are interested. >> =20 > > It would be interesting to hear what you had in mind. In proposals > like this people have made here and elsewhere over the last few years, > there are numerous problems that arise when each user becomes > responsible for their own resources as well. How do you handle > replication? How would you maintain information when the user is > offline? A meta question would be how clients would work in this > scenario, since they are, by definition, not directly accessible. > Personally, I think distributed storage, with replication and > encrypted, signed resources is the best idea, but I would be > interested to hear what you have in mind. > > David (as individual) > > =20 Let me explain my idea with an example. If my user-name is Ruben.Cuevas, I (likely) will store in the DHT as=20 resource-id the hash(Ruben.Cuevas), lets say this resource-id is X. If=20 we consider the use of a DHT system, the Responsible Node for X will be=20 the Peer with the closest Peer-ID to X. Then, if I want to be the=20 Responsible Node for X, I have to obtain the closest Peer-ID. Thus, I=20 can ask to the Central Entity (in case of use a Central Entity scheme)=20 for the closest Peer-ID to the resource-key associated to Ruben.Cuevas. =20 I can demonstrate I am Ruben.Cuevas (by a passwd or other credentials)=20 and the Peer-ID would be assigned. It could be for instance X+1. Then I=20 becomes the Responsible Node for my own resource-id. If all the users has to do the same and demonstrate their credentials,=20 all the users obtain Peer-IDs close to their own resource-ids and anyone=20 could obtain Peer-IDs with the intention to starve other resources. As you said we have to deal with seveal issues: Replication. You can still keep the same replication scheme than in the=20 regular DHT schemes: the N closest Peer-IDs. However, in this case it is=20 easier to identify the good or bad behaviour of my neighbourgs since I=20 am the one which does this task. Even more, your neighbourg should be=20 careful in make something wrong with your resource-id, since you also=20 have stored his resource-id, then you can also make the same wrong thing. I am off-line. Again the same. The same scheme which you use in the=20 regular DHT schemes can be applied here. If in regular DHT your info is=20 kept alive on the replicas, here you can do the same. Clients: You have also the same problem as in regular DHTs. This scheme=20 does not modifies anything regarding to the clients. I have not yet going into the detail of this idea, and maybe it has=20 several problems I have not yet identified. Then, it is really=20 interesing to hear from you. Cheers, Rub=E9n. >> Rub=E9n. >> >> -- >> Rub=E9n Cuevas Rum=EDn >> Universidad Carlos III de Madrid >> Departamento Ingenier=EDa Telem=E1tica >> Avenida de la Universidad, 30 >> 28911-Legan=E9s (Madrid). Espa=F1a >> email: rcuevas@it.uc3m.es >> Tlf: +34 91-6248859 >> Fax: +34 91-6248749 >> Web: http://www.it.uc3m.es/~rcuevas >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> =20 > > > > =20 --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 11:30:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It45o-0007ma-E3; Fri, 16 Nov 2007 11:30:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It45i-0007fD-MY for p2psip@lists.ietf.org; Fri, 16 Nov 2007 11:30:51 -0500 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It45e-0001SE-5Q for p2psip@lists.ietf.org; Fri, 16 Nov 2007 11:30:50 -0500 Received: from [163.117.139.165] (acordeon.it.uc3m.es [163.117.139.165])by smtp.uc3m.es (Postfix) with ESMTP id 82DE423AC0A; Fri, 16 Nov 2007 17:30:45 +0100 (CET) Message-ID: <473DC5BD.2060304@it.uc3m.es> Date: Fri, 16 Nov 2007 17:30:53 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: Universidad Carlos III de Madrid User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [P2PSIP] Identity vs Identifier References: <473C730E.1080004@it.uc3m.es><618e24240711150935v6164ae0lf7bede7 e06770c99@mail.gmail.com><473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <055701c82868$33564220$640fa8c0@cis.neustar.com> In-Reply-To: <055701c82868$33564220$640fa8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-11.4231 TC:1F TRN:29 TV:5.0.1023(15550.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rcuevas@it.uc3m.es List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Brian Rosen escribi=F3: > Looks to me like we are having some semantic differences that are causi= ng us > to get wrapped around the axle. > > I think the concept document describes one kind of entity, a peer, whic= h is > aware of the DHT and participates in it, and two kinds of entities: SIP= UAs > and clients that do not directly participate in the DHT, but rather do = so > through a peer. The SIP UA uses SIP to communicate with the peer that > interworks SIP rendezvous operations to the DHT. We were looking for > examples of clients that needed some other protocol to interwork their > rendezvous operations to the DHT. > > It would seem that some want to redefine a client into a subset of a pe= er: a > entity who is aware of and participates in the DHT, but doesn't store d= ata, > for example. It would seem that most of the proponents of such a notio= n > think that a subset of the base p2p protocol is what such entities use. > =20 I agree with this definition of client. In addition, it is close related to what David wrote in some recent mail=20 that Clients only makes sense in those devices which are in somehow limited. Then, we will allow=20 them to take advantage from the p2psip system (that is, retrive information) without=20 overloading them with tasks as storage, routing or maintenance. Rub=E9n. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 12:45:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It5FY-0006iF-92; Fri, 16 Nov 2007 12:45:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It5FW-0006ha-AL for p2psip@ietf.org; Fri, 16 Nov 2007 12:45:02 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It5FS-0000z6-KO for p2psip@ietf.org; Fri, 16 Nov 2007 12:45:02 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lAGHiuBV009792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Nov 2007 09:44:57 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lAGHiuae003561; Fri, 16 Nov 2007 09:44:56 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lAGHiodG003252; Fri, 16 Nov 2007 09:44:56 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 09:44:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Chosen-location attacks,HIP-HOP and central authorities Date: Fri, 16 Nov 2007 09:44:53 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D0404998D@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: <166476A2803C3B4994D744DFD57A942F561B2A@306181ANEX3.global.avaya.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Chosen-location attacks, HIP-HOP and central authorities Thread-Index: AcgnzGspu7E27d1oSc6Tg/2vYGQEIAABPwBQACk3PZA= References: <20071113144604.8CF0733C59@delta.rtfm.com><473ADC5C.4070101@it.uc3m.es><473B06F4.9060904@alcatel-lucent.com><473B0EF5.2060807@it.uc3m.es><473B17D1.6030705@alcatel-lucent.com><1D674D8A-9EBC-4000-96E8-5479D2AD4743@cs.columbia.edu><473B32EF.7010909@it.uc3m.es><4d4304a00711141117n553f85e9j4ae8c7dcca7034ac@mail.gmail.com><20071114215212.A3F3033C21@delta.rtfm.com><8818C006-8EF5-4E6D-97B2-D0E176469201@magma.ca><20071115201012.E0F1533C21@delta.rtfm.com><20071115210838.AF46733C21@delta.rtfm.com> <166476A2803C3B4994D744DFD57A942F561B2A@306181ANEX3.global.avaya.com> From: "Henderson, Thomas R" To: "Palanisamy, Kandasamy (Kandasamy)" , "P2PSIP Mailing List" X-OriginalArrivalTime: 16 Nov 2007 17:44:53.0839 (UTC) FILETIME=[65285DF0:01C82878] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org =20 > -----Original Message----- > From: Palanisamy, Kandasamy (Kandasamy) [mailto:kandyp@avaya.com]=20 > Sent: Thursday, November 15, 2007 2:07 PM > To: P2PSIP Mailing List > Subject: RE: [P2PSIP] Chosen-location attacks,HIP-HOP and=20 > central authorities >=20 > The central enrollment server that verifies the identity of=20 > the node and > issues the certificate should prevent it from getting multiple HITs > (should that > be the policy). >=20 > If chain of trust of the joiner's certificate is verified to the root > certificate of the central enrollment at the time of joining, it would > make sure > the joiner is authentic. Another possibility would be to allow, during registration with the central authority, the option of the central authority assigning a different Peer-ID than the HIT. It could then bind this alternate Peer-ID to the HIT in the certificate, providing proof-of-ownership for the joiner. In the deployments where central authority doesn't care or there is no central authority, the HIT could be used as the Peer-ID. Tom _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 14:33:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6vt-0005nx-9N; Fri, 16 Nov 2007 14:32:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It6vr-0005nF-JX for p2psip@ietf.org; Fri, 16 Nov 2007 14:32:51 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It6vn-0005eB-Bw for p2psip@ietf.org; Fri, 16 Nov 2007 14:32:51 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRM00B8A6ALFQ@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 11:32:46 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRM0042D6AIFR@usaga01-in.huawei.com> for p2psip@ietf.org; Fri, 16 Nov 2007 11:32:45 -0800 (PST) Date: Fri, 16 Nov 2007 13:32:30 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior To: P2PSIP Mailing List Message-id: <042a01c82887$6e30d850$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <00e501c8272a$905b2060$5105a40a@china.huawei.com> <7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca> <0aef01c8278a$b68ad0e0$ad600240@china.huawei.com> <9C8C25BD-E1C7-4940-9A42-5261CA150950@magma.ca> <24CCCC428EFEA2469BF046DB3C7A8D223AE2D1@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org If I have confused Henry and other people - in Philip's note that Henry replied to, the text was "but none of us are strong advocates of clients". This was from MY earlier posting, on 15-Nov-07, at 08:23, where the context was > (HINT: the application scenarios draft includes analysis about > whether each scenario seems to require "P2P Client Support" and/or > "Interoperation with CS-SIP" - I don't think any of the draft > authors are prejudiced against clients, but none of us are strong > advocates of clients, so it would be good to have client advocates > develop opinions about whether that analysis is reasonable or not) I was referring to the draft authors for a specific draft, not to the entire working group, or the entire P2P community :-) What I meant by this was that the draft authors had gone through each application scenario, looking for the scenarios that seemed to require more users than peers, assuming that the way you support more users than peers is through SOME kind of client, either CS-SIP or "a client protocol", and trying to visualize whether CS-SIP would be sufficient in these scenarios, but none of the authors had expressed strong opinions about the need for a non-SIP client protocol during our work on the draft. When this draft was submitted, none of us had written a draft advocating non-SIP clients, although Eunsoo said earlier this week that he will do that. That's ALL I meant, and if people would like to express opinions about application scenarios in http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt, we would be thrilled to hear them. Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 17:05:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It9JB-0004wd-9i; Fri, 16 Nov 2007 17:05:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It9JA-0004wY-CB for p2psip@ietf.org; Fri, 16 Nov 2007 17:05:04 -0500 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1It9J9-0003q5-Qw for p2psip@ietf.org; Fri, 16 Nov 2007 17:05:04 -0500 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Fri, 16 Nov 2007 14:05:01 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAGM4xKn011920; Fri, 16 Nov 2007 14:05:00 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAGM4gRE017058; Fri, 16 Nov 2007 14:04:58 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 14:04:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Fri, 16 Nov 2007 14:04:41 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE2EB@namail5.corp.adobe.com> In-Reply-To: <042a01c82887$6e30d850$6601a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Thread-Index: Acgoh4fvGJSDOQgYQQKjBp2n3x3GRAAE3EmA References: <00e501c8272a$905b2060$5105a40a@china.huawei.com><7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca><0aef01c8278a$b68ad0e0$ad600240@china.huawei.com><9C8C25BD-E1C7-4940-9A42-5261CA150950@magma.ca><24CCCC428EFEA2469BF046DB3C7A8D223AE2D1@namail5.corp.adobe.com> <042a01c82887$6e30d850$6601a8c0@china.huawei.com> From: "Henry Sinnreich" To: "Spencer Dawkins" , "P2PSIP Mailing List" X-OriginalArrivalTime: 16 Nov 2007 22:04:42.0486 (UTC) FILETIME=[B0B72160:01C8289C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org It's OK and please don't worry about the difficulties of completely clear mail communications. If anything, they only point to how more difficult tight protocol specifications are :-) Henry -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Friday, November 16, 2007 11:33 AM To: P2PSIP Mailing List Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior If I have confused Henry and other people - in Philip's note that Henry=20 replied to, the text was "but none of us are strong advocates of clients". This was from MY earlier posting, on 15-Nov-07, at 08:23, where the context=20 was > (HINT: the application scenarios draft includes analysis about > whether each scenario seems to require "P2P Client Support" and/or > "Interoperation with CS-SIP" - I don't think any of the draft > authors are prejudiced against clients, but none of us are strong > advocates of clients, so it would be good to have client advocates > develop opinions about whether that analysis is reasonable or not) I was referring to the draft authors for a specific draft, not to the entire=20 working group, or the entire P2P community :-) What I meant by this was that the draft authors had gone through each=20 application scenario, looking for the scenarios that seemed to require more=20 users than peers, assuming that the way you support more users than peers is=20 through SOME kind of client, either CS-SIP or "a client protocol", and=20 trying to visualize whether CS-SIP would be sufficient in these scenarios,=20 but none of the authors had expressed strong opinions about the need for a=20 non-SIP client protocol during our work on the draft. When this draft was submitted, none of us had written a draft advocating non-SIP clients, although Eunsoo said earlier this week that he will do=20 that. That's ALL I meant, and if people would like to express opinions about=20 application scenarios in=20 http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt, we=20 would be thrilled to hear them. Thanks, Spencer=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 16 17:34:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1It9ln-0008Mz-9L; Fri, 16 Nov 2007 17:34:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1It9ll-0008JU-Gt for p2psip@lists.ietf.org; Fri, 16 Nov 2007 17:34:37 -0500 Received: from chip2og56.obsmtp.com ([64.18.13.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1It9lg-00053W-Ub for p2psip@lists.ietf.org; Fri, 16 Nov 2007 17:34:37 -0500 Received: from source ([192.150.11.134]) by chip2ob56.postini.com ([64.18.5.12]) with SMTP; Fri, 16 Nov 2007 14:34:27 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAGMWGOP002870; Fri, 16 Nov 2007 14:32:16 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAGMXbFX014211; Fri, 16 Nov 2007 14:34:20 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 07:33:38 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Nov 2007 14:33:38 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> In-Reply-To: <473DC47C.5030003@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Abusive and trustable peers and clients Thread-Index: AcgobVihtxMLonQ0TaS3aQ3ytmbClgAMoSpQ References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> From: "Henry Sinnreich" To: , "David A. Bryan" X-OriginalArrivalTime: 16 Nov 2007 22:33:38.0434 (UTC) FILETIME=[BB6BC620:01C828A0] X-Spam-Score: -4.0 (----) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: p2psip@lists.ietf.org Subject: [P2PSIP] Abusive and trustable peers and clients X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I have changed the title, since the attached points to a new issue:=20 Abusive and trustable peers and clients Besides the fact that these terms must be better defined in some = document, along with fairness, etc., it also raises the point that = trustable nodes must have the software encrypted and signed by a central = authority. At least Skype does it and it works well for them. What do you think? Henry -----Original Message----- From: Rub=E9n Cuevas Rum=EDn [mailto:rcuevas@it.uc3m.es]=20 Sent: Friday, November 16, 2007 8:26 AM To: David A. Bryan Cc: p2psip@lists.ietf.org Subject: Re: [P2PSIP] Identity vs Identifier David A. Bryan escribi=F3: > Comments inline: > > =20 >> If you have several UA associated to the same user. If I am right, it = is >> pretty likely that all of them are going to use the service offered = by >> the p2psip overlay which are defined in the concepts draft. And we >> should solve this problem, how several devices (i.e. UA) associated = to >> the same user are going to participate/use the p2psip system. >> The easiest way is that all of them becomes peers inside the p2psip >> system. But maybe ithis is not the best solution. I just proposed the >> possibility of use one of them as Peer and let the others be Clients. >> This is not new, the new part is that I propose the Peer allowing = the >> rest to access to the p2psip system is not a third one but this >> associated to the same user. >> =20 > > I think this is not the right way to layer here -- we are mixing an > application level issue (is more than one UA associated with a user) > with a routing level issue (is this a peer or client). The two should > be independent. Personally, I think as many things as possible should > be peers, and if all the devices you are associated with can be peers, > they all should act as so, rather than being clients. > > There is another problem with the approach of a user with multiple > devices having one as a peer and the rest as clients. The only reasons > that I have seen presented for why a device should be a client rather > than a peer in the first place are either the device is behind a NAT > and cannot be a good peer, or has some limitation (processor, battery > life, etc.) that would motivate being a client instead. Making the > assumption that one is a peer and the rest clients assumes that the > device becoming a peer is reachable by all the devices. In a LAN this > may be true, but I might have 3 UAs, one at home, one at the office, > and one a mobile device. All may be on separate networks. Letting each > determine if it has adequate connectivity and resources to be a peer > makes better sense than imposing an application level decision, in my > mind. > > =20 I agree in almost everything. As you said limited deviced are the candidates to not be a Peer. Then,=20 imagine a simple scenario with two devices associated to the same user=20 name, a non-limited device, e.g. a desktop, and a limited device, e.g. a = mobile phone. Then, we can identify the desktop as a potential peer and=20 the mobile phone as a potential client. Lets analyze the different=20 situations: 1- The desktop is reachable (i.e. not firewalled or behind a NAT). It=20 registers in the p2psystem and becomes a Peer. After that, the mobile=20 phone registers on the p2psystems. Since this is a limited device it=20 needs to lookfor a peer to conect with. Then, it can randonmly selects a = Peer with the adequate properties (i.e. globally reachable). However,=20 why not try first to select a trustable one? I mean, the mobile phone=20 can launches a search for the resource-id associated to its user-name,=20 and then, it would discover that there is a Peer associated to this user = name already registered and which is reachable. Then it would select=20 this one. 2- The desktop is behind a NAT. Then, the mobile phone could choose=20 between connect to this (fully trustable) peer by using some=20 NAT-Traversal strategy or connects to one offering global reachabilty=20 but in principle, not trustable. 3- If it is the mobile phone who registers firstly, then it obviously=20 would choose one globally reachable Peer. And maybe can develop some=20 periodic discovery mechanism in order to discover if the trustable Peer=20 (that is, the desktop on the example) appears at some point. Well, it is just an idea. Why not use trustable Peers if we can do it?. >> On the other hand, IMO an important problem in the p2psip overlay is >> that my "resource-ID" (or "resource-IDs") is going to be stored by >> someone I don't know and (with the solution defined so far) I cannot >> trust in. This introduce trust and security threads. It would be nice = to >> define a new mechanism which allows the users to store its own >> "resource-IDs". It is something I am thinking about and I have some >> ideas if you are interested. >> =20 > > It would be interesting to hear what you had in mind. In proposals > like this people have made here and elsewhere over the last few years, > there are numerous problems that arise when each user becomes > responsible for their own resources as well. How do you handle > replication? How would you maintain information when the user is > offline? A meta question would be how clients would work in this > scenario, since they are, by definition, not directly accessible. > Personally, I think distributed storage, with replication and > encrypted, signed resources is the best idea, but I would be > interested to hear what you have in mind. > > David (as individual) > > =20 Let me explain my idea with an example. If my user-name is Ruben.Cuevas, I (likely) will store in the DHT as=20 resource-id the hash(Ruben.Cuevas), lets say this resource-id is X. If=20 we consider the use of a DHT system, the Responsible Node for X will be=20 the Peer with the closest Peer-ID to X. Then, if I want to be the=20 Responsible Node for X, I have to obtain the closest Peer-ID. Thus, I=20 can ask to the Central Entity (in case of use a Central Entity scheme)=20 for the closest Peer-ID to the resource-key associated to Ruben.Cuevas. = I can demonstrate I am Ruben.Cuevas (by a passwd or other credentials)=20 and the Peer-ID would be assigned. It could be for instance X+1. Then I = becomes the Responsible Node for my own resource-id. If all the users has to do the same and demonstrate their credentials,=20 all the users obtain Peer-IDs close to their own resource-ids and anyone = could obtain Peer-IDs with the intention to starve other resources. As you said we have to deal with seveal issues: Replication. You can still keep the same replication scheme than in the=20 regular DHT schemes: the N closest Peer-IDs. However, in this case it is = easier to identify the good or bad behaviour of my neighbourgs since I=20 am the one which does this task. Even more, your neighbourg should be=20 careful in make something wrong with your resource-id, since you also=20 have stored his resource-id, then you can also make the same wrong = thing. I am off-line. Again the same. The same scheme which you use in the=20 regular DHT schemes can be applied here. If in regular DHT your info is=20 kept alive on the replicas, here you can do the same. Clients: You have also the same problem as in regular DHTs. This scheme=20 does not modifies anything regarding to the clients. I have not yet going into the detail of this idea, and maybe it has=20 several problems I have not yet identified. Then, it is really=20 interesing to hear from you. Cheers, Rub=E9n. >> Rub=E9n. >> >> -- >> Rub=E9n Cuevas Rum=EDn >> Universidad Carlos III de Madrid >> Departamento Ingenier=EDa Telem=E1tica >> Avenida de la Universidad, 30 >> 28911-Legan=E9s (Madrid). Espa=F1a >> email: rcuevas@it.uc3m.es >> Tlf: +34 91-6248859 >> Fax: +34 91-6248749 >> Web: http://www.it.uc3m.es/~rcuevas >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> =20 > > > > =20 --=20 Rub=E9n Cuevas Rum=EDn Universidad Carlos III de Madrid Departamento Ingenier=EDa Telem=E1tica Avenida de la Universidad, 30 28911-Legan=E9s (Madrid). Espa=F1a email: rcuevas@it.uc3m.es Tlf: +34 91-6248859 Fax: +34 91-6248749 Web: http://www.it.uc3m.es/~rcuevas _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Nov 17 11:54:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItQvx-0006Zc-EA; Sat, 17 Nov 2007 11:54:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItQvw-0006Yt-Jf for p2psip@ietf.org; Sat, 17 Nov 2007 11:54:16 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-09.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItQvw-0007KP-1E for p2psip@ietf.org; Sat, 17 Nov 2007 11:54:16 -0500 Received: from [207.61.233.78] (helo=[192.168.0.142]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1ItQvu-0006IR-0q; Sat, 17 Nov 2007 11:54:14 -0500 In-Reply-To: <01b501c8281c$1b655440$5105a40a@china.huawei.com> References: <01b501c8281c$1b655440$5105a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Sat, 17 Nov 2007 11:55:31 -0500 To: Zheng Hewen X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([192.168.0.142]) [207.61.233.78] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 'Henry Sinnreich' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > [Hewen] Hope we can reach agreement in mail list or in Vancouver. I > personally think that it is time to clarify P2PSIP > clients' characters. I do not see any doubt about the existence of > P2PSIP clients in the mail list, any comment? Before the working group was formed, there were various people talking about ideas related to P2PSIP. Hence the Concepts draft was originally written to unite these various groups around a rough vision of what we wanted to do. Some of the people wanted clients, while others didn't see the need for them. Hence the concept of clients was put into the Concepts draft, but with a note that they may or may not exist. Various ideas for what a client might be have put forth, and have been documented in the Concept draft. However, what has always been lacking is a strong argument for why we cannot just have peers. Hence the request in Prague for an I-D that would put forth this argument, and hence my repeat of this request on the mailing list a few days ago. > [Hewen] Do you think that there is > something clients can do but peers can't? Those are some nodes > which are not able and/or eligible to act as peers in fact. Why are clients not able to act as peers? Is there a technical reason, or some other reason? Some people have suggested that they might not have enough processing capability or battery life, but we don't yet know what processing capability or battery life a peer will need. Are their strong technical reasons why we won't be able to design a peer protocol that will run on devices such as this? If a strong argument can be made that any reasonable peer protocol design could not run on a certain class of devices, then this would be a good argument for clients. However, just saying "It cannot be done" is not sufficient. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Nov 17 12:06:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItR83-0004ki-H9; Sat, 17 Nov 2007 12:06:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItR81-0004gn-NX for p2psip@ietf.org; Sat, 17 Nov 2007 12:06:45 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItR7z-0004v6-9a for p2psip@ietf.org; Sat, 17 Nov 2007 12:06:45 -0500 Received: from Henning-Schulzrinnes-Computer (pool-70-21-184-101.nwrk.east.verizon.net [70.21.184.101]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAHH6e2P026458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 17 Nov 2007 12:06:41 -0500 (EST) Message-Id: <369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu> From: Henning Schulzrinne To: Philip Matthews In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Sat, 17 Nov 2007 12:06:40 -0500 References: <01b501c8281c$1b655440$5105a40a@china.huawei.com> X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> > > Why are clients not able to act as peers? Is there a technical > reason, or some other reason? Some people have suggested that they > might not have enough processing capability or battery life, but we > don't yet know what processing capability or battery life a peer > will need. Are their strong technical reasons why we won't be able > to design a peer protocol that will run on devices such as this? > For typical DHTs, the bandwidth needs are dramatically higher for peers than for clients, at least for all the DHTs that we are currently considering. Simple calculation: For a 1000 node DHT, roughly 1% of all queries will traverse any given peer, i.e., one in a hundred calls. For a busy network, that could be tens to hundreds of calls a second. That's a lot of network activity for a battery- operated node - or one that pays for bandwidth by the byte. Thus, it doesn't matter how high the absolute cost, as there will be networks where 1% of the calls exceeds the capacity of mobile nodes. Clients can go off-line, which happens fairly frequently for wireless devices; peers shouldn't (unless you like to deal with lots of churn, which then requires much higher replication). > If a strong argument can be made that any reasonable peer protocol > design could not run on a certain class of devices, then this would > be a good argument for clients. However, just saying "It cannot be > done" is not sufficient. Your raising the bar to the impossible. You can never prove that something cannot be done; for all we know, we can exceed the speed of light. We do know what can and cannot be done with current DHT algorithm proposals. For those, I see clients as necessary and easy to support. Frankly, I don't understand your reluctance to deal with clients. All protocol proposals trivially accommodate them, as far as I can tell, so it's not like this is going to cause dramatic scope creep. Let me turn this around. I'd like to hear from people who have an argument as to why clients are not needed or why they cause significant increases in complexity. > > > - Philip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Nov 17 12:36:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItRac-0001kh-Bu; Sat, 17 Nov 2007 12:36:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItRab-0001kC-5D for p2psip@lists.ietf.org; Sat, 17 Nov 2007 12:36:17 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItRaY-00068S-RL for p2psip@lists.ietf.org; Sat, 17 Nov 2007 12:36:17 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 1C3D933C21; Sat, 17 Nov 2007 09:31:15 -0800 (PST) Date: Sat, 17 Nov 2007 09:31:14 -0800 From: Eric Rescorla To: "Henry Sinnreich" Subject: Re: [P2PSIP] Abusive and trustable peers and clients In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071117173115.1C3D933C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Fri, 16 Nov 2007 14:33:38 -0800, Henry Sinnreich wrote: > > I have changed the title, since the attached points to a new issue: > > Abusive and trustable peers and clients > > Besides the fact that these terms must be better defined in some document, along with fairness, etc., it also raises the point that trustable nodes must have the software encrypted and signed by a central authority. At least Skype does it and it works well for them. > > What do you think? How do you propose that other nodes determine whether a peer is running such software? -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Nov 17 13:27:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItSOP-0002CS-SM; Sat, 17 Nov 2007 13:27:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItSOP-0002CL-1D for p2psip@lists.ietf.org; Sat, 17 Nov 2007 13:27:45 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItSOL-0007Zo-Mm for p2psip@lists.ietf.org; Sat, 17 Nov 2007 13:27:45 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAHIRcS10267; Sat, 17 Nov 2007 18:27:38 GMT Received: from marcus2.localdomain ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Nov 2007 13:27:38 -0500 Message-ID: <473F328D.1000203@nortel.com> Date: Sat, 17 Nov 2007 13:27:25 -0500 From: "Marcus Leech" User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [P2PSIP] Abusive and trustable peers and clients References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> In-Reply-To: <20071117173115.1C3D933C21@delta.rtfm.com> X-Enigmail-Version: 0.95.5 OpenPGP: id=4EC1F1F4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 17 Nov 2007 18:27:38.0411 (UTC) FILETIME=[882CBFB0:01C82947] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: p2psip@lists.ietf.org, Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Rescorla wrote: > > How do you propose that other nodes determine whether a peer is > running such software? > > -Ekr > =20 The snide answer would be "Why TCG/NEA/NAC/NAP or course, they fix *everything*". But I think that's a rat-hole that should be gone down somewhere else, and not here. Asking the question "how can we be sure the other side is running so-called good code" is not meaningful for a sufficiently-robust definition of "meaningful". One might as well ask "how can we be sure that the operator at the other end has taken his anti-psychotics today, and thus can be trusted to use the software in a rational way". The only robustly-meaningful answer is "you can't". _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Nov 17 13:45:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItSfa-000708-44; Sat, 17 Nov 2007 13:45:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItSfY-0006xV-Mu for p2psip@lists.ietf.org; Sat, 17 Nov 2007 13:45:28 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItSfV-00086g-E5 for p2psip@lists.ietf.org; Sat, 17 Nov 2007 13:45:28 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E126E33C21; Sat, 17 Nov 2007 10:40:29 -0800 (PST) Date: Sat, 17 Nov 2007 10:40:29 -0800 From: Eric Rescorla To: "Marcus Leech" Subject: Re: [P2PSIP] Abusive and trustable peers and clients In-Reply-To: <473F328D.1000203@nortel.com> References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <473F328D.1000203@nortel.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071117184029.E126E33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: p2psip@lists.ietf.org, Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Sat, 17 Nov 2007 13:27:25 -0500, Marcus Leech wrote: > > Eric Rescorla wrote: > > > > How do you propose that other nodes determine whether a peer is > > running such software? > > > > -Ekr > > > The snide answer would be "Why TCG/NEA/NAC/NAP or course, they fix > *everything*". > > But I think that's a rat-hole that should be gone down somewhere else, > and not here. Asking the question "how can we be sure > the other side is running so-called good code" is not meaningful for a > sufficiently-robust definition of "meaningful". One might > as well ask "how can we be sure that the operator at the other end has > taken his anti-psychotics today, and thus can be > trusted to use the software in a rational way". The only > robustly-meaningful answer is "you can't". I agree. Which is why security mechanisms which depend on the correct behavior of peers are not OK. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Nov 17 17:26:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItW7I-0004gn-JJ; Sat, 17 Nov 2007 17:26:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItW7G-0004ci-Va for p2psip@lists.ietf.org; Sat, 17 Nov 2007 17:26:18 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItW7D-0006he-Lp for p2psip@lists.ietf.org; Sat, 17 Nov 2007 17:26:18 -0500 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAHMQAwm005899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Nov 2007 17:26:13 -0500 (EST) Date: Sat, 17 Nov 2007 17:26:10 -0500 (EST) From: Salman Abdul Baset To: Eric Rescorla Subject: Re: [P2PSIP] Abusive and trustable peers and clients In-Reply-To: <20071117184029.E126E33C21@delta.rtfm.com> Message-ID: References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <473F328D.1000203@nortel.com> <20071117184029.E126E33C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: p2psip@lists.ietf.org, Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> Eric Rescorla wrote: >>> >>> How do you propose that other nodes determine whether a peer is >>> running such software? >>> >>> -Ekr >>> >> The snide answer would be "Why TCG/NEA/NAC/NAP or course, they fix >> *everything*". >> >> But I think that's a rat-hole that should be gone down somewhere else, >> and not here. Asking the question "how can we be sure >> the other side is running so-called good code" is not meaningful for a >> sufficiently-robust definition of "meaningful". One might >> as well ask "how can we be sure that the operator at the other end has >> taken his anti-psychotics today, and thus can be >> trusted to use the software in a rational way". The only >> robustly-meaningful answer is "you can't". > > I agree. Which is why security mechanisms which depend on the correct > behavior of peers are not OK. This means that nodes should try to detect malicious behavior of other nodes and peer protocol should provide mechanisms for nodes to exchange this information. A node that had its identifier certified by a CA can also misbehave. Think of a hacked version of Skype executable which allows users to obtain a certified ID, but prevents nodes from sharing its bandwidth. Users can also put a bandwidth cap on their p2p application that does not require any modification to the p2p executable. One such example is relay detect and block (RDB), developed at Columbia. http://rdb.sourceforge.net/ There are more than one published mechanisms to detect malicious behavior of nodes. The question is should peer protocol incorporate those mechanisms, or leave it up to the overlay implementer. -s _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Nov 17 23:15:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItbZ0-0006YB-DH; Sat, 17 Nov 2007 23:15:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItbYx-0006VB-PN for p2psip@lists.ietf.org; Sat, 17 Nov 2007 23:15:15 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItbYu-0007Ru-Br for p2psip@lists.ietf.org; Sat, 17 Nov 2007 23:15:15 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 2DC6C33C2B; Sat, 17 Nov 2007 20:10:14 -0800 (PST) Date: Sat, 17 Nov 2007 20:10:13 -0800 From: Eric Rescorla To: Salman Abdul Baset Subject: Re: [P2PSIP] Abusive and trustable peers and clients In-Reply-To: References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <473F328D.1000203@nortel.com> <20071117184029.E126E33C21@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071118041014.2DC6C33C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: p2psip@lists.ietf.org, Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Sat, 17 Nov 2007 17:26:10 -0500 (EST), Salman Abdul Baset wrote: > > >> Eric Rescorla wrote: > >>> > >>> How do you propose that other nodes determine whether a peer is > >>> running such software? > >>> > >>> -Ekr > >>> > >> The snide answer would be "Why TCG/NEA/NAC/NAP or course, they fix > >> *everything*". > >> > >> But I think that's a rat-hole that should be gone down somewhere else, > >> and not here. Asking the question "how can we be sure > >> the other side is running so-called good code" is not meaningful for a > >> sufficiently-robust definition of "meaningful". One might > >> as well ask "how can we be sure that the operator at the other end has > >> taken his anti-psychotics today, and thus can be > >> trusted to use the software in a rational way". The only > >> robustly-meaningful answer is "you can't". > > > > I agree. Which is why security mechanisms which depend on the correct > > behavior of peers are not OK. > > This means that nodes should try to detect malicious behavior of other > nodes and peer protocol should provide mechanisms for nodes to exchange > this information. This opens up a whole can of worms: how do you detect false reports of malicious behavior?! This is a persistent problem with all reputation systems. > There are more than one published mechanisms to detect malicious behavior > of nodes. The question is should peer protocol incorporate those > mechanisms, or leave it up to the overlay implementer. I think that trying to standardize that would be extremely inadvisable at this time. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 18 08:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItkGa-0004LV-Hb; Sun, 18 Nov 2007 08:32:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItkGY-0004LH-Rd for p2psip@lists.ietf.org; Sun, 18 Nov 2007 08:32:50 -0500 Received: from smtp02.uc3m.es ([163.117.176.132] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItkGU-0003bf-1s for p2psip@lists.ietf.org; Sun, 18 Nov 2007 08:32:50 -0500 Received: from localhost (webcartero01.uc3m.es [163.117.136.131])by smtp.uc3m.es (Postfix) with ESMTP id E17982321BF; Sun, 18 Nov 2007 14:32:44 +0100 (CET) Received: from 88.pool85-52-161.static.orange.es(88.pool85-52-161.static.orange.es [85.52.161.88]) by webcartero01.uc3m.es(Horde MIME library) with HTTP; Sun, 18 Nov 2007 14:32:43 +0100 Message-ID: <20071118143243.p1k2f4mfa8kkko4s@webcartero01.uc3m.es> Date: Sun, 18 Nov 2007 14:32:43 +0100 From: RUBEN CUEVAS RUMIN To: Eric Rescorla Subject: Re: [P2PSIP] Abusive and trustable peers and clients References: <473C730E.1080004@it.uc3m.es><618e24240711150935v6164ae0lf7bede7 e06770c99@mail.gmail.com><473D684A.1060502@it.uc3m.es><4d4304a00711160658h5 3e725a9tf98018d86353a944@mail.gmail.com><473DC47C.5030003@it.uc3m.es><24CCC C428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com><20071117173115.1C 3D933C21@delta.rtfm.com><473F328D.1000203@nortel.com><20071117184029.E126E3 3C21@delta.rtfm.com><20071118041014.2DC6C33C2B@delta.rtfm.com> In-Reply-To: <20071118041014.2DC6C33C2B@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-20.1760 TC:1F TRN:55 TV:5.0.1023(15552.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: -1.9 (-) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: p2psip@lists.ietf.org, Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric Rescorla dijo: > At Sat, 17 Nov 2007 17:26:10 -0500 (EST), > Salman Abdul Baset wrote: >> >> >> Eric Rescorla wrote: >> >>> >> >>> How do you propose that other nodes determine whether a peer is >> >>> running such software? >> >>> >> >>> -Ekr >> >>> >> >> The snide answer would be "Why TCG/NEA/NAC/NAP or course, they fix >> >> *everything*". >> >> >> >> But I think that's a rat-hole that should be gone down somewhere else= , >> >> and not here. Asking the question "how can we be sure >> >> the other side is running so-called good code" is not meaningful fo= r a >> >> sufficiently-robust definition of "meaningful". One might >> >> as well ask "how can we be sure that the operator at the other end = has >> >> taken his anti-psychotics today, and thus can be >> >> trusted to use the software in a rational way". The only >> >> robustly-meaningful answer is "you can't". >> > >> > I agree. Which is why security mechanisms which depend on the correct >> > behavior of peers are not OK. >> >> This means that nodes should try to detect malicious behavior of other >> nodes and peer protocol should provide mechanisms for nodes to exchange >> this information. > > This opens up a whole can of worms: how do you detect false reports > of malicious behavior?! This is a persistent problem with all reputation > systems. > I agree that it is impossible to detect a malcious behaviour. Then, the only solution is to make the peers collaborate and properly behave. We can do it if we define the suitable incentive mechanism. For instance, Bittorrent works because of tit-for-tat which is a perfect strategy "as much as you uploads as much as you can download" (I know several people have implemented some free rider clients on Bittorrent by exploting some weaknesses). Therefore, IMO instead of focusing on the detection of malicious behaviour, we should focus on defining an incentive mechanism which rewards those peers with a good behaviour. In addition, I still think that a secure Peer-ID assignment mechanism is essential. Without this mechanism the system would be highly vulnerable. Rub=E9n. > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Universidad Carlos III de Madrid _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 18 09:55:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItlY0-0001wx-M5; Sun, 18 Nov 2007 09:54:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItlXz-0001ws-1W for p2psip@lists.ietf.org; Sun, 18 Nov 2007 09:54:55 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItlXv-0005j3-Ia for p2psip@lists.ietf.org; Sun, 18 Nov 2007 09:54:55 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id C665833C57; Sun, 18 Nov 2007 06:49:53 -0800 (PST) Date: Sun, 18 Nov 2007 06:49:53 -0800 From: Eric Rescorla To: RUBEN CUEVAS RUMIN Subject: Re: [P2PSIP] Abusive and trustable peers and clients In-Reply-To: <20071118143243.p1k2f4mfa8kkko4s@webcartero01.uc3m.es> References: <473C730E.1080004@it.uc3m.es> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071118144953.C665833C57@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: p2psip@lists.ietf.org, Henry Sinnreich X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Sun, 18 Nov 2007 14:32:43 +0100, RUBEN CUEVAS RUMIN wrote: > > Eric Rescorla dijo: > > > At Sat, 17 Nov 2007 17:26:10 -0500 (EST), > > Salman Abdul Baset wrote: > >> > >> >> Eric Rescorla wrote: > >> >>> > >> >>> How do you propose that other nodes determine whether a peer is > >> >>> running such software? > >> >>> > >> >>> -Ekr > >> >>> > >> >> The snide answer would be "Why TCG/NEA/NAC/NAP or course, they fix > >> >> *everything*". > >> >> > >> >> But I think that's a rat-hole that should be gone down somewhere else, > >> >> and not here. Asking the question "how can we be sure > >> >> the other side is running so-called good code" is not meaningful for a > >> >> sufficiently-robust definition of "meaningful". One might > >> >> as well ask "how can we be sure that the operator at the other end has > >> >> taken his anti-psychotics today, and thus can be > >> >> trusted to use the software in a rational way". The only > >> >> robustly-meaningful answer is "you can't". > >> > > >> > I agree. Which is why security mechanisms which depend on the correct > >> > behavior of peers are not OK. > >> > >> This means that nodes should try to detect malicious behavior of other > >> nodes and peer protocol should provide mechanisms for nodes to exchange > >> this information. > > > > This opens up a whole can of worms: how do you detect false reports > > of malicious behavior?! This is a persistent problem with all reputation > > systems. > > > > I agree that it is impossible to detect a malcious behaviour. Then, the > only solution is to make the peers collaborate and properly behave. We > can do it if we define the suitable incentive mechanism. For instance, > Bittorrent works because of tit-for-tat which is a perfect strategy "as > much as you uploads as much as you can download" (I know several people > have implemented some free rider clients on Bittorrent by exploting > some weaknesses). Unfortunately, incentive mechanism design is also an open research problem. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 18 10:17:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itlu9-0003e3-GM; Sun, 18 Nov 2007 10:17:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itlu8-0003ZP-0j for p2psip@lists.ietf.org; Sun, 18 Nov 2007 10:17:48 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itlu4-0006K4-RE for p2psip@lists.ietf.org; Sun, 18 Nov 2007 10:17:47 -0500 Received: from Henning-Schulzrinnes-Computer (pool-70-21-184-101.nwrk.east.verizon.net [70.21.184.101]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAIFHh64013818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 18 Nov 2007 10:17:44 -0500 (EST) Message-Id: From: Henning Schulzrinne To: Eric Rescorla In-Reply-To: <20071118144953.C665833C57@delta.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [P2PSIP] Abusive and trustable peers and clients Date: Sun, 18 Nov 2007 10:17:42 -0500 References: <473C730E.1080004@it.uc3m.es> <20071118144953.C665833C57@delta.rtfm.com> X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I hope we can agree on three things: - Incentives don't deal with truly malicious users, just selfish ones. - There is no general, assumption-free mechanism for securely assigning peer IDs. - There is no general way to detect misbehaving nodes. There may well be set of assumptions that are reasonable in certain circumstances and that allow you to qualify the statements above. It seems unlikely that this will affect the design of the protocol itself. Thus, I think we should declare defeat on those three items and move on. We just have to make sure that reasonable techniques, be they escrowing a million dollars, remote malicious user execution or just having a central enrollment server, are not prevented by our design. In many cases, techniques outside the P2P system will be used to ensure security. For example, if you have an L3 network with strong admission control and strong network user authentication, you may not need to worry about protecting the overlay itself against malicious users. Henning > Unfortunately, incentive mechanism design is also an open research > problem. > > -Ekr > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 18 17:08:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItsJk-00070S-Hs; Sun, 18 Nov 2007 17:08:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItsJj-00070N-0v for p2psip@lists.ietf.org; Sun, 18 Nov 2007 17:08:39 -0500 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItsJf-0001JK-KP for p2psip@lists.ietf.org; Sun, 18 Nov 2007 17:08:39 -0500 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Sun, 18 Nov 2007 14:08:24 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAIM8BNT005495; Sun, 18 Nov 2007 14:08:16 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAIM7nFb012190; Sun, 18 Nov 2007 14:08:11 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 07:07:56 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Abusive and trustable peers and clients Date: Sun, 18 Nov 2007 14:05:45 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> In-Reply-To: <20071117173115.1C3D933C21@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Abusive and trustable peers and clients Thread-Index: AcgpQFlv/hZtwa77Ra2P2CEJzUG+dwA7UKtg References: <473C730E.1080004@it.uc3m.es><618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com><473D684A.1060502@it.uc3m.es><4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com><473DC47C.5030003@it.uc3m.es><24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> From: "Henry Sinnreich" To: "Eric Rescorla" X-OriginalArrivalTime: 18 Nov 2007 22:07:56.0040 (UTC) FILETIME=[78E8A080:01C82A2F] X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >>trustable nodes must have the software encrypted and signed by a=20 >>central authority >How do you propose that other nodes determine whether a peer is >running such software? My assumption is the p2p overlay is run by an owner with a vested interest of protecting the overlay, just like Skype does.=20 For Interdomain p2p security some work must be done on "the security of "peering", though "peering" would have here a very different meaning from what is meant at present. This may fall under such specific design assumptions that Henning has mentioned in this thread. Henry -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Saturday, November 17, 2007 9:31 AM To: Henry Sinnreich Cc: rcuevas@it.uc3m.es; David A. Bryan; p2psip@lists.ietf.org Subject: Re: [P2PSIP] Abusive and trustable peers and clients At Fri, 16 Nov 2007 14:33:38 -0800, Henry Sinnreich wrote: >=20 > I have changed the title, since the attached points to a new issue:=20 >=20 > Abusive and trustable peers and clients >=20 > Besides the fact that these terms must be better defined in some document, along with fairness, etc., it also raises the point that trustable nodes must have the software encrypted and signed by a central authority. At least Skype does it and it works well for them. >=20 > What do you think? How do you propose that other nodes determine whether a peer is running such software? -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 18 21:08:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itw42-0005je-NE; Sun, 18 Nov 2007 21:08:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itw40-0005jI-OO for p2psip@lists.ietf.org; Sun, 18 Nov 2007 21:08:40 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itw3x-0000aD-B4 for p2psip@lists.ietf.org; Sun, 18 Nov 2007 21:08:40 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 9D7DF33C2B; Sun, 18 Nov 2007 18:03:39 -0800 (PST) Date: Sun, 18 Nov 2007 18:03:38 -0800 From: Eric Rescorla To: "Henry Sinnreich" Subject: Re: [P2PSIP] Abusive and trustable peers and clients In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071119020339.9D7DF33C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Sun, 18 Nov 2007 14:05:45 -0800, Henry Sinnreich wrote: > > >>trustable nodes must have the software encrypted and signed by a > >>central authority > > >How do you propose that other nodes determine whether a peer is > >running such software? > > My assumption is the p2p overlay is run by an owner with a vested > interest of protecting the overlay, just like Skype does. But this only works for Skype because Skype's protocol and implementation are closed and therefore it's very difficult for an attacker to implement the protocol themselves and/or extract the keying material used by Skype clients to authenticate. The first property will clearly not be true of any P2PSIP imploemetnation and the second is not going to be true of any open source implementation. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 18 21:09:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itw4f-0005xZ-6p; Sun, 18 Nov 2007 21:09:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itw4e-0005xU-Jx for p2psip@ietf.org; Sun, 18 Nov 2007 21:09:20 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itw4b-0000a7-CF for p2psip@ietf.org; Sun, 18 Nov 2007 21:09:20 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRQ00148DY924@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 19 Nov 2007 10:08:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRQ00LFADY89F@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 19 Nov 2007 10:08:33 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRQ00F9YDY4CY@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 19 Nov 2007 10:08:32 +0800 (CST) Date: Mon, 19 Nov 2007 10:08:28 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: To: 'Philip Matthews' Message-id: <032801c82a51$13740fb0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcgpOoB03RC1M0NFRx+CY6fJVTy5OQBE2Ufw X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: 'Henry Sinnreich' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline... ... Best regards, Hewen > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: 2007?11?18? 0:56 > To: Zheng Hewen > Cc: 'Eunsoo Shim'; 'Victor Pascual ??vila'; 'Henry > Sinnreich'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > > > > [Hewen] Hope we can reach agreement in mail list or in Vancouver. I > > personally think that it is time to clarify P2PSIP clients' > > characters. I do not see any doubt about the existence of P2PSIP > > clients in the mail list, any comment? > > Before the working group was formed, there were various > people talking about ideas related to P2PSIP. Hence the > Concepts draft was originally written to unite these various > groups around a rough vision of what we wanted to do. Some of > the people wanted clients, while others didn't see the need > for them. Hence the concept of clients was put into the > Concepts draft, but with a note that they may or may not exist. > > Various ideas for what a client might be have put forth, and > have been documented in the Concept draft. However, what has > always been lacking is a strong argument for why we cannot > just have peers. Hence the request in Prague for an I-D that > would put forth this argument, and hence my repeat of this > request on the mailing list a few days ago. > [Hewen]Thanks for your information, agree with you that such an I-D is desirable. > > > [Hewen] Do you think that there is > > something clients can do but peers can't? Those are some > nodes which > > are not able and/or eligible to act as peers in fact. > > Why are clients not able to act as peers? Is there a > technical reason, or some other reason? Some people have > suggested that they might not have enough processing > capability or battery life, but we don't yet know what > processing capability or battery life a peer will need. Are > their strong technical reasons why we won't be able to design > a peer protocol that will run on devices such as this? > > If a strong argument can be made that any reasonable peer > protocol design could not run on a certain class of devices, > then this would be a good argument for clients. However, just > saying "It cannot be done" is not sufficient. > [Hewen]Oh, frankly, it is a very smart question. Nobody can prove that something is impossible; can I say "the reason is Nothing Is Impossible"? Essentially, we potentially have some predetermined assumption in P2PSIP, for example, as one discussion in the mail list, we already assume that peers have infinite storage capacity, what happens on those nodes with limited storage capacity or without contributable storage capacity? Those nodes should not act as peers according to our assumption, but those nodes wants P2PSIP service though those nodes only have thin storage capacity, what then will those nodes be? Peer? No. Those nodes will be clients. We seldom see some technical reason about why P2PSIP clients do not exist. We need to face the existence of clients and clarify clients character/behaviors even when a thin peer protocol or unmodified SIP is enough to act as the communication protocol between peers and clients, this work will be very helpful to P2PSIP deployment in real world. Would someone tell us why clients can or shall not exist in P2PSIP? > - Philip > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 18 21:19:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwEP-0006GX-Hb; Sun, 18 Nov 2007 21:19:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwEO-0006GS-Ig for p2psip@ietf.org; Sun, 18 Nov 2007 21:19:24 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItwEN-0006CD-Tn for p2psip@ietf.org; Sun, 18 Nov 2007 21:19:24 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRQ00KR6E6671@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 19 Nov 2007 10:13:18 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRQ00CRFE62FX@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 19 Nov 2007 10:13:18 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRQ00COBE5Y6G@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 19 Nov 2007 10:13:14 +0800 (CST) Date: Mon, 19 Nov 2007 10:13:10 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu> To: 'Henning Schulzrinne' , 'Philip Matthews' Message-id: <035301c82a51$bbb1d310$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcgpPHSJszL6j6KFTXKbQ24rvdGbNwBFL9LQ X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline... ... Best regards, Hewen > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 2007?11?18? 1:07 > To: Philip Matthews > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > >> > > > > Why are clients not able to act as peers? Is there a > technical reason, > > or some other reason? Some people have suggested that they > might not > > have enough processing capability or battery life, but we don't yet > > know what processing capability or battery life a peer will > need. Are > > their strong technical reasons why we won't be able to > design a peer > > protocol that will run on devices such as this? > > > > For typical DHTs, the bandwidth needs are dramatically higher > for peers than for clients, at least for all the DHTs that we > are currently considering. Simple calculation: For a 1000 > node DHT, roughly 1% of all queries will traverse any given > peer, i.e., one in a hundred calls. For a busy network, that > could be tens to hundreds of calls a second. That's a lot of > network activity for a battery- operated node - or one that > pays for bandwidth by the byte. Thus, it doesn't matter how > high the absolute cost, as there will be networks where 1% of > the calls exceeds the capacity of mobile nodes. > > Clients can go off-line, which happens fairly frequently for > wireless devices; peers shouldn't (unless you like to deal > with lots of churn, which then requires much higher replication). > [Hewen] Support. It is very real. > > > If a strong argument can be made that any reasonable peer protocol > > design could not run on a certain class of devices, then > this would be > > a good argument for clients. However, just saying "It > cannot be done" > > is not sufficient. > > Your raising the bar to the impossible. You can never prove > that something cannot be done; for all we know, we can exceed > the speed of light. We do know what can and cannot be done > with current DHT algorithm proposals. For those, I see > clients as necessary and easy to support. > > Frankly, I don't understand your reluctance to deal with > clients. All protocol proposals trivially accommodate them, > as far as I can tell, so it's not like this is going to cause > dramatic scope creep. > > Let me turn this around. I'd like to hear from people who > have an argument as to why clients are not needed or why they > cause significant increases in complexity. > [Hewen] I have no more words, just "Agree". As your said, nobody tell us "why clients are not needed or why they cause significant increases in complexity". > > > > > > > - Philip > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 18 21:41:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwZn-0008K1-Jq; Sun, 18 Nov 2007 21:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwZm-0008Jw-PS for p2psip@lists.ietf.org; Sun, 18 Nov 2007 21:41:30 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItwZh-0001Uq-Nv for p2psip@lists.ietf.org; Sun, 18 Nov 2007 21:41:30 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRQ0076XFFQCI@szxga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:40:39 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRQ006IAFFQSH@szxga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:40:38 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRQ00F9ZFFPCY@szxml04-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:40:38 +0800 (CST) Date: Mon, 19 Nov 2007 10:40:37 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Abusive and trustable peers and clients In-reply-to: To: 'Henning Schulzrinne' Message-id: <005001c82a55$917686f0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acgp9k/xzM6YntS/RoWvitxVbVrFaQAW2Lcg X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > I hope we can agree on three things: > > - Incentives don't deal with truly malicious users, just selfish ones. > > - There is no general, assumption-free mechanism for securely > assigning peer IDs. > > - There is no general way to detect misbehaving nodes. > > There may well be set of assumptions that are reasonable in certain > circumstances and that allow you to qualify the statements above. It > seems unlikely that this will affect the design of the protocol > itself. Thus, I think we should declare defeat on those three items > and move on. We just have to make sure that reasonable techniques, be > they escrowing a million dollars, remote malicious user execution or > just having a central enrollment server, are not prevented by our > design. > > In many cases, techniques outside the P2P system will be used to > ensure security. For example, if you have an L3 network with strong > admission control and strong network user authentication, you may not > need to worry about protecting the overlay itself against malicious > users. Maybe you point another direction to the solution of the security of P2P system. If the service providers of P2P system would collaborate with Network operators, some advantages may be got: 1. Through the agreement between ISP and its subscribers, p2p system may know who the peers or clients really are and where they are with the help of the ISP. 2. P2P service providers may delegate the ISP to enforce some security mechanisms. 3. If the ISP could bill for the P2P system, it will be a proof by which ISP and P2P service provider could incent the peer to share resources. These are just my two cents. It must be outside the scope of P2PSIP WG. But it may be the future work of the P2P community. Regards! ---------------- JiangXingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 00:17:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itz0z-0007hy-Eh; Mon, 19 Nov 2007 00:17:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itz0w-0007WQ-A3 for p2psip@ietf.org; Mon, 19 Nov 2007 00:17:42 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itz0t-0006r5-S4 for p2psip@ietf.org; Mon, 19 Nov 2007 00:17:42 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Nov 2007 21:17:39 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAJ5Hds2024285 for ; Sun, 18 Nov 2007 21:17:39 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAJ5Hb41024930 for ; Mon, 19 Nov 2007 05:17:37 GMT Mime-Version: 1.0 (Apple Message framework v752.3) References: Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Sun, 18 Nov 2007 21:17:04 -0800 To: P2PSIP WG X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2002; t=1195449459; x=1196313459; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Merge=20of=20ASP=20and=20RELOAD=20-=20Version=20Notification= 20for=20draft-bryan-p2psip-reload-02=20 |Sender:=20; bh=+xlRiOur2KgA1+B2UG02ZY82E02bMK5bqdNMV71gXZA=; b=AVCJcUW+asmVgivKo2/4J6AqJSv2i5xj7G8zuWeO6QMlA7lhEHW8rtv3lV1OIh8/kcy0Ll1E y/PE0kAcHydRczqD6gLQ1NvUf1C2xPZbLUgx8AwpFcmp8laGCFPwP3u+; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [P2PSIP] Merge of ASP and RELOAD - Version Notification for draft-bryan-p2psip-reload-02 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The various authors of ASP and RELOAD have managed to get these two proposal merged together into one and we are pretty happy with the result. You can find it at http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-02.txt Begin forwarded message: > From: IETF I-D Submission Tool > Date: November 18, 2007 8:57:03 PM PST > To: fluffy@cisco.com > Cc: lowekamp@sipeerior.com, ekr@networkresonance.com, > jdrosen@cisco.com > Subject: New Version Notification for draft-bryan-p2psip-reload-02 > > > A new version of I-D, draft-bryan-p2psip-reload-02.txt has been > successfuly submitted by Cullen Jennings and posted to the IETF > repository. > > Filename: draft-bryan-p2psip-reload > Revision: 02 > Title: REsource LOcation And Discovery (RELOAD) > Creation_date: 2007-11-18 > WG ID: Independent Submission > Number_of_pages: 96 > > Abstract: > This document defines REsource LOcation And Discovery (RELOAD), a > peer-to-peer (P2P) binary signaling protocol for usage on the > Internet. A P2P signaling protocol provides its clients with an > abstract hash table service between a set of cooperating peers that > form the overlay network. RELOAD is designed to support a P2P > Session Initiation Protocol (P2PSIP) network, but it can be utilized > by other applications with similar requirements by defining new > usages that specify the data types that must be stored for a > particular application, such as location for SIP. RELOAD defines a > security model based on a certificate enrollment service that > provides unique identities. NAT traversal is a fundamental service > of the protocol. > > This draft represents a concrete proposal for the P2PSIP Peer > Protocol. The protocol described here builds on the lessons and > experiences from designing and implementing the dSIP, ASP, and RELOAD > protocols and is a merge of features from RELOAD-01 and ASP. > > > > The IETF Secretariat. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 06:23:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4j8-00006z-T7; Mon, 19 Nov 2007 06:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4j8-00006t-5Y for p2psip@ietf.org; Mon, 19 Nov 2007 06:23:42 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu4j5-0002hM-8L for p2psip@ietf.org; Mon, 19 Nov 2007 06:23:42 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9C068204DE; Mon, 19 Nov 2007 12:23:38 +0100 (CET) X-AuditID: c1b4fb3e-ae831bb0000007e1-d4-4741723a6fc1 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 9259B2049F; Mon, 19 Nov 2007 12:23:38 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 12:23:38 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 12:23:38 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id EE04A2461; Mon, 19 Nov 2007 13:23:37 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CE24B4DC3B; Mon, 19 Nov 2007 13:23:35 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 715334DC2F; Mon, 19 Nov 2007 13:23:35 +0200 (EET) Message-ID: <4741729F.7070902@ericsson.com> Date: Mon, 19 Nov 2007 13:25:19 +0200 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: p2psip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 19 Nov 2007 11:23:38.0163 (UTC) FILETIME=[A16E7830:01C82A9E] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: gonzalo.camarillo@ericsson.com Subject: [P2PSIP] New version from the with-hip draft (Utilizing HIP for P2PSIP) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, We just submitted a new version from the with-hip draft to the IETF. Here's the abstract of the draft: This document specifies how Host Identity Protocol (HIP) can be utilized in Peer-to-Peer Session Initiation Protocol (P2PSIP) networks. Peers in a P2PSIP network need to have long-lived connections to other peers in the network, and HIP can be utilized to setup and maintain those connections. HIP is a good choice for connection maintenance, because it provides functionalities like Network Address Translation (NAT) traversal, mobility, multi-homing, and enhanced security properties. The draft can be found from: http://www.ietf.org/internet-drafts/draft-hautakorpi-p2psip-with-hip-01.txt All kind of feedback would be appreciated! -- Jani _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 07:19:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5as-0007vp-Fg; Mon, 19 Nov 2007 07:19:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu5aq-0007uH-OT for p2psip@lists.ietf.org; Mon, 19 Nov 2007 07:19:12 -0500 Received: from mx05.uni-tuebingen.de ([134.2.3.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu5am-0004wb-F1 for p2psip@lists.ietf.org; Mon, 19 Nov 2007 07:19:12 -0500 Received: from smtp.cs.uni-tuebingen.de (u-173-c156.cs.uni-tuebingen.de [134.2.173.156]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id lAJCIYMI020461; Mon, 19 Nov 2007 13:18:34 +0100 Received: from u-172-c174.cs.uni-tuebingen.de ([134.2.172.174]) by smtp.cs.uni-tuebingen.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Iu5aE-0002Cu-8K; Mon, 19 Nov 2007 13:18:34 +0100 Message-ID: <47417F19.2000800@uni-tuebingen.de> Date: Mon, 19 Nov 2007 13:18:33 +0100 From: Ali Fessi User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: JiangXingFeng Subject: Re: [P2PSIP] Abusive and trustable peers and clients References: <005001c82a55$917686f0$6905a40a@china.huawei.com> In-Reply-To: <005001c82a55$917686f0$6905a40a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by AntiVir MailGate (version: 2.1.2-11; AVE: 7.6.0.34; VDF: 7.0.0.231; host: mx05) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Henning, all, IMHO, I think it is not reasonable to rely on some security services on a different layer. This would limit the practicability of P2PSIP. The IMS, e.g., implements its own security mechanisms independently of the underlying layer. Also, if you are in Europe, and u want to join your P2P network in US, you may not want to do any VPN, or something like this, to be able to join your "home" P2P network. However, for the P2PSIP WG, it is probably reasonable to assume that the assignment of a node-id is done by means out-of-scope. For real deployment scenario, you might have 2 use-cases: - large-scale P2PSIP networks, where u need a central authority that provides the IDs. - small P2PSIP networks, where self-signed certificates (with the node-id in the certificate) can be sufficient and u don't need all the burden with setting up a CA Also, i agree with the point, that there is no general way to detect misbehaving nodes, in particular it is not possible to exclude attacks on the routing in the P2PSIP network. hope this help to move forward. Cheers, Ali JiangXingFeng wrote: >> I hope we can agree on three things: >> >> - Incentives don't deal with truly malicious users, just selfish ones. >> >> - There is no general, assumption-free mechanism for securely >> assigning peer IDs. >> >> - There is no general way to detect misbehaving nodes. >> >> There may well be set of assumptions that are reasonable in certain >> circumstances and that allow you to qualify the statements above. It >> seems unlikely that this will affect the design of the protocol >> itself. Thus, I think we should declare defeat on those three items >> and move on. We just have to make sure that reasonable techniques, be >> they escrowing a million dollars, remote malicious user execution or >> just having a central enrollment server, are not prevented by our >> design. >> >> In many cases, techniques outside the P2P system will be used to >> ensure security. For example, if you have an L3 network with strong >> admission control and strong network user authentication, you may not >> need to worry about protecting the overlay itself against malicious >> users. > > Maybe you point another direction to the solution of the security of P2P > system. If the service providers of P2P system would collaborate with > Network operators, some advantages may be got: > 1. Through the agreement between ISP and its subscribers, p2p system may > know who the peers or clients really are and where they are with the help of > the ISP. > 2. P2P service providers may delegate the ISP to enforce some security > mechanisms. > 3. If the ISP could bill for the P2P system, it will be a proof by which ISP > and P2P service provider could incent the peer to share resources. > > These are just my two cents. It must be outside the scope of P2PSIP WG. But > it may be the future work of the P2P community. > > Regards! > ---------------- > JiangXingFeng > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Ali Fessi Computer Networks and Internet University of Tuebingen, Germany Phone: +49 7071 29-70576 / Fax: +49 7071 29-5220 EMail: ali.fessi@uni-tuebingen.de Web: http://net.informatik.uni-tuebingen.de/~fessi/ _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 08:40:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6rf-00035Q-5i; Mon, 19 Nov 2007 08:40:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6rc-00031V-Dv for p2psip@ietf.org; Mon, 19 Nov 2007 08:40:36 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-02.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu6rc-0007fo-3p for p2psip@ietf.org; Mon, 19 Nov 2007 08:40:36 -0500 Received: from [207.61.233.78] (helo=[192.168.0.142]) by mail-02.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Iu6ra-0007zF-23; Mon, 19 Nov 2007 08:40:34 -0500 In-Reply-To: <369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu> References: <01b501c8281c$1b655440$5105a40a@china.huawei.com> <369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Mon, 19 Nov 2007 08:41:47 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([192.168.0.142]) [207.61.233.78] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 17-Nov-07, at 12:06 , Henning Schulzrinne wrote: > > Frankly, I don't understand your reluctance to deal with clients. > All protocol proposals trivially accommodate them, as far as I can > tell, so it's not like this is going to cause dramatic scope creep. > > Let me turn this around. I'd like to hear from people who have an > argument as to why clients are not needed or why they cause > significant increases in complexity. 1) The usual desire not to introduce a concept that is not needed. 2) No clear idea why people want clients. So far, the only agreed- upon description of a client is that they do something less than a peer. 3) No clear description of what a client is. Concepts-01 lists three different alternatives that have been proposed by people, and so far there seems to be no WG consensus around any of these. Your e-mail is a good start to an argument why there might be nodes that can and might want to be clients, but cannot be peers, though it still doesn't describe WHAT a client is. Let me be clear. Given a good argument, I am quite willing to have the concept of a client. I just need to know what it is and why I need it. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 08:43:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6u5-0007QJ-UC; Mon, 19 Nov 2007 08:43:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6u4-0007Nq-EB for p2psip@ietf.org; Mon, 19 Nov 2007 08:43:08 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu6u4-00080O-5n for p2psip@ietf.org; Mon, 19 Nov 2007 08:43:08 -0500 Received: from Henning-Schulzrinnes-Computer (pool-70-21-184-101.nwrk.east.verizon.net [70.21.184.101]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAJDh6gu020981 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Nov 2007 08:43:07 -0500 (EST) Message-Id: <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> From: Henning Schulzrinne To: Philip Matthews In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Mon, 19 Nov 2007 08:43:06 -0500 References: <01b501c8281c$1b655440$5105a40a@china.huawei.com> <369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu> X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > Your e-mail is a good start to an argument why there might be nodes > that can and might want to be clients, but cannot be peers, though > it still doesn't describe WHAT a client is. That's simple: For the current definition of the protocols, P2PSIP protocols do a key-to-value lookup. A client can perform a get and put operation (and other related data manipulation operations), but does not route P2PSIP protocol requests. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 08:51:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71r-0005Eu-Uq; Mon, 19 Nov 2007 08:51:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71l-0004v2-Ux for p2psip@ietf.org; Mon, 19 Nov 2007 08:51:06 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu71l-0000A5-1J for p2psip@ietf.org; Mon, 19 Nov 2007 08:51:05 -0500 Received: from [207.61.233.78] (helo=[192.168.0.142]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Iu71k-0001UW-0x; Mon, 19 Nov 2007 08:51:04 -0500 In-Reply-To: <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> References: <01b501c8281c$1b655440$5105a40a@china.huawei.com> <369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu> <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Mon, 19 Nov 2007 08:52:11 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([192.168.0.142]) [207.61.233.78] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 19-Nov-07, at 08:43 , Henning Schulzrinne wrote: >> >> Your e-mail is a good start to an argument why there might be >> nodes that can and might want to be clients, but cannot be peers, >> though it still doesn't describe WHAT a client is. > > That's simple: For the current definition of the protocols, P2PSIP > protocols do a key-to-value lookup. A client can perform a get and > put operation (and other related data manipulation operations), but > does not route P2PSIP protocol requests. > Write it up in short I-D! Seriously: having a clear description written down in an I-D with good arguments for why this is interesting and why there are nodes that can do this but cannot be a peer would be immensely helpful to the WG. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 10:16:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8Lj-0000jx-QN; Mon, 19 Nov 2007 10:15:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8Lg-0000jf-S2 for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:15:44 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu8Lc-0008Kv-Ub for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:15:44 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRR00GN5EE3J4@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 07:15:39 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRR00921EE29Q@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 07:15:39 -0800 (PST) Date: Mon, 19 Nov 2007 09:15:06 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Abusive and trustable peers and clients To: p2psip@lists.ietf.org Message-id: <076901c82abe$f7edf8a0$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> <20071119020339.9D7DF33C2B@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Eric, From: "Eric Rescorla" > At Sun, 18 Nov 2007 14:05:45 -0800, > Henry Sinnreich wrote: >> >> >>trustable nodes must have the software encrypted and signed by a >> >>central authority >> >> >How do you propose that other nodes determine whether a peer is >> >running such software? >> >> My assumption is the p2p overlay is run by an owner with a vested >> interest of protecting the overlay, just like Skype does. > > But this only works for Skype because Skype's protocol and > implementation are closed and therefore it's very difficult > for an attacker to implement the protocol themselves and/or > extract the keying material used by Skype clients to > authenticate. The first property will clearly not be true > of any P2PSIP imploemetnation and the second is not going > to be true of any open source implementation. When you say "extract the keying material", do you mean "extract the keying material from a packet that you overhear", or something else? I'm trying to grok the last half of the last sentence. I know it's the morning of I-D cutoff, so I'm probably not at the top of my game (and we can talk about what that might mean in Vancouver :-) ... but I'm not connecting all the dots. Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 10:22:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8SP-0001WH-54; Mon, 19 Nov 2007 10:22:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8SN-0001Vz-T4 for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:22:39 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu8SL-0000O4-Ju for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:22:39 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRR00G5CEPPJ4@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 07:22:37 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRR009CCEPO9Q@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 07:22:37 -0800 (PST) Date: Mon, 19 Nov 2007 09:22:05 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Abusive and trustable peers and clients To: p2psip@lists.ietf.org Message-id: <077f01c82abf$f11d0470$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >>>trustable nodes must have the software encrypted and signed by a >>>central authority >>How do you propose that other nodes determine whether a peer is >>running such software? >My assumption is the p2p overlay is run by an owner with a vested >interest of protecting the overlay, just like Skype does. I note that http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt explicitly calls this application scenario out in Section 4.4.1 (and the associated attributes in Table 1). The authors of this draft would love to see some discussion of this particular scenario on-list, since it seems that some people are assuming this scenario while others are assuming other scenarios. And if we can't frame the discussion in a specific scenario, this turns into a "baby beauty contest" where everyone says "MY baby is the most beautiful"... Thanks, Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 10:48:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8rl-0007xY-Kd; Mon, 19 Nov 2007 10:48:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8rk-0007wX-Cj for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:48:52 -0500 Received: from chip2og50.obsmtp.com ([64.18.13.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu8rf-0002ty-U8 for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:48:52 -0500 Received: from source ([192.150.11.134]) by chip2ob50.postini.com ([64.18.5.12]) with SMTP; Mon, 19 Nov 2007 07:48:33 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAJFkQOP027733; Mon, 19 Nov 2007 07:46:26 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAJFmVRC024348; Mon, 19 Nov 2007 07:48:32 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 00:48:31 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Abusive and trustable peers and clients Date: Mon, 19 Nov 2007 07:48:16 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE305@namail5.corp.adobe.com> In-Reply-To: <20071119020339.9D7DF33C2B@delta.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Abusive and trustable peers and clients Thread-Index: AcgqUSJ9clU9vHd7RHWsEFfbCWNqaQAb0Skg References: <473C730E.1080004@it.uc3m.es><618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com><473D684A.1060502@it.uc3m.es><4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com><473DC47C.5030003@it.uc3m.es><24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com><20071117173115.1C3D933C21@delta.rtfm.com><24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> <20071119020339.9D7DF33C2B@delta.rtfm.com> From: "Henry Sinnreich" To: "Eric Rescorla" X-OriginalArrivalTime: 19 Nov 2007 15:48:31.0170 (UTC) FILETIME=[A266E220:01C82AC3] X-Spam-Score: -4.0 (----) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Eric, >The first property will clearly not be true Eric, >of any P2PSIP imploemetnation and the second is not going >to be true of any open source implementation. I would like to arm wrestle you on these statements. Can you elaborate? 1. Trustable nodes must have the software encrypted and signed be a central authority, the same that provides the strong authentications for the peers. Please help me understand why this "will clearly not be true of any P2PSIP implementation". 2. The encrypted software is not compatible with open source implementations. Please help me understand why open source code with some added "salt" cannot be encrypted. >This is fundamentally incompatible with either open protocols or open source (in your companion message). This post is really for a better understanding of these issues, so I would appreciate some more clarification from you and any other folks who would like to pitch in. >But this only works for Skype because Skype's protocol Same: It would help if this can be explained: Why does encryption and signing work only for Skype and some similar and _creative_ approach would not work for P2PSIP, no matter if it is OS or commercial. Henry -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Sunday, November 18, 2007 8:04 PM To: Henry Sinnreich Cc: Eric Rescorla; rcuevas@it.uc3m.es; David A. Bryan; p2psip@lists.ietf.org Subject: Re: [P2PSIP] Abusive and trustable peers and clients At Sun, 18 Nov 2007 14:05:45 -0800, Henry Sinnreich wrote: >=20 > >>trustable nodes must have the software encrypted and signed by a=20 > >>central authority >=20 > >How do you propose that other nodes determine whether a peer is > >running such software? >=20 > My assumption is the p2p overlay is run by an owner with a vested > interest of protecting the overlay, just like Skype does.=20 But this only works for Skype because Skype's protocol and implementation are closed and therefore it's very difficult for an attacker to implement the protocol themselves and/or extract the keying material used by Skype clients to authenticate. The first property will clearly not be true of any P2PSIP imploemetnation and the second is not going to be true of any open source implementation. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 10:56:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8zP-00043S-RY; Mon, 19 Nov 2007 10:56:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8zO-00042u-Ik for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:56:46 -0500 Received: from chip2og51.obsmtp.com ([64.18.13.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu8zK-0003dZ-Gv for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:56:46 -0500 Received: from source ([192.150.11.134]) by chip2ob51.postini.com ([64.18.5.12]) with SMTP; Mon, 19 Nov 2007 07:56:41 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAJFsVOP028704; Mon, 19 Nov 2007 07:54:32 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAJFuLG1021358; Mon, 19 Nov 2007 07:56:37 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 07:56:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Abusive and trustable peers and clients Date: Mon, 19 Nov 2007 07:56:11 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE306@namail5.corp.adobe.com> In-Reply-To: <077f01c82abf$f11d0470$6601a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Abusive and trustable peers and clients Thread-Index: AcgqwAwZAux1SKaRSUGs5bmBm3ge9wABCq+w References: <473C730E.1080004@it.uc3m.es><618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com><473D684A.1060502@it.uc3m.es><4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com><473DC47C.5030003@it.uc3m.es><24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com><20071117173115.1C3D933C21@delta.rtfm.com><24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> <077f01c82abf$f11d0470$6601a8c0@china.huawei.com> From: "Henry Sinnreich" To: "Spencer Dawkins" , X-OriginalArrivalTime: 19 Nov 2007 15:56:33.0637 (UTC) FILETIME=[C1F98150:01C82AC4] X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Spencer, Thanks for the question! The section is actually: "4.1.1. Public P2P VoIP Service Providers". As mentioned, why can encryption and signing of the software in the device or endpoint work only for a proprietary protocol like Skype and not for P2PSIP, even when the SW is OS? Henry -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Monday, November 19, 2007 9:22 AM To: p2psip@lists.ietf.org Subject: Re: [P2PSIP] Abusive and trustable peers and clients >>>trustable nodes must have the software encrypted and signed by a >>>central authority >>How do you propose that other nodes determine whether a peer is >>running such software? >My assumption is the p2p overlay is run by an owner with a vested >interest of protecting the overlay, just like Skype does. I note that=20 http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt=20 explicitly calls this application scenario out in Section 4.4.1 (and the associated attributes in Table 1). The authors of this draft would love to see some discussion of this=20 particular scenario on-list, since it seems that some people are assuming=20 this scenario while others are assuming other scenarios. And if we can't frame the discussion in a specific scenario, this turns into=20 a "baby beauty contest" where everyone says "MY baby is the most=20 beautiful"... Thanks, Spencer=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 10:58:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu90g-0004mW-LU; Mon, 19 Nov 2007 10:58:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu90f-0004mM-OE for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:58:05 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu90c-0003jF-Fc for p2psip@lists.ietf.org; Mon, 19 Nov 2007 10:58:05 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6FA7833C2B; Mon, 19 Nov 2007 07:53:04 -0800 (PST) Date: Mon, 19 Nov 2007 07:53:03 -0800 From: Eric Rescorla To: Spencer Dawkins Subject: Re: [P2PSIP] Abusive and trustable peers and clients In-Reply-To: <076901c82abe$f7edf8a0$6601a8c0@china.huawei.com> References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> <20071119020339.9D7DF33C2B@delta.rtfm.com> <076901c82abe$f7edf8a0$6601a8c0@china.huawei.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071119155304.6FA7833C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 19 Nov 2007 09:15:06 -0600, Spencer Dawkins wrote: > > Hi, Eric, > > From: "Eric Rescorla" > > > > At Sun, 18 Nov 2007 14:05:45 -0800, > > Henry Sinnreich wrote: > >> > >> >>trustable nodes must have the software encrypted and signed by a > >> >>central authority > >> > >> >How do you propose that other nodes determine whether a peer is > >> >running such software? > >> > >> My assumption is the p2p overlay is run by an owner with a vested > >> interest of protecting the overlay, just like Skype does. > > > > But this only works for Skype because Skype's protocol and > > implementation are closed and therefore it's very difficult > > for an attacker to implement the protocol themselves and/or > > extract the keying material used by Skype clients to > > authenticate. The first property will clearly not be true > > of any P2PSIP imploemetnation and the second is not going > > to be true of any open source implementation. > > When you say "extract the keying material", do you mean "extract the keying > material from a packet that you overhear", or something else? > > I'm trying to grok the last half of the last sentence. I know it's the > morning of I-D cutoff, so I'm probably not at the top of my game (and we can > talk about what that might mean in Vancouver :-) ... but I'm not connecting > all the dots. OK, let's take a step back: You're the operator of some service. It could be a P2P network, but actually the context in which this comes up the most is DRM for digital media. Your customers use your software to access the service and part of your security depends on the software functioning correctly. In the case of a P2P network this may mean storing whatever data it's supposed to store. In the case of DRM, it generally means not exporting the media in raw form. In order to enforce this, you write your own software that behaves the way you want and this is the only software you allow on your network. Now, when the operator's server receives a message/connection/PDU from a client, it needs to determine whether the client is running the right software. Otherwise, the user can simply download software which *pretends* to be your software but actually cheats (doesn't store data, exports media in raw form, whatever). So, you need one way to verify the software running on the other end. This problem is called attestation, and it's believed to be quite difficult. All the known solutions that really work involve trusted hardware on the client side. (cf. TCG). If you're not going to use trusted hardware, then you end up falling back on obfuscation. There are two things you can obfuscate: - The protocol. - The program binary. If you use a proprietary protocol, then you make it difficult for a third party to pretend to be one of your clients because the first thing they need to do is reverse engineer your protocol. The implicit theory here is that anyone who speaks your protocol is one of your clients. If you want to use an open protocol, then you can't use this method, so you end up falling back on cryptography. You use an open protocol but then somehow issue each client a cryptographic key which it uses to authenticate. But of course the client needs access to the key, so the attacker can reverse engineer the client to extract the key. And since the protocol is open, they can then write their own implementation using the key. In order to block this, you generally obfuscate/encrypt the program binary to make key extraction more difficult. But this is obviously incompatible with the client program being open source. Skype uses both of these techniques: the protocol is proprietary *and* each client is issued a key at startup which is used by an obfuscated binary. Nevertheless, both countermeasures have been successfully attacked. Again, there is no known way of solving this problem without using trusted hardware. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 11:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu94k-0000Oz-5B; Mon, 19 Nov 2007 11:02:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu94j-0000Ot-0z for p2psip@lists.ietf.org; Mon, 19 Nov 2007 11:02:17 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu94g-00046F-5i for p2psip@lists.ietf.org; Mon, 19 Nov 2007 11:02:17 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5980A33C2B; Mon, 19 Nov 2007 07:57:17 -0800 (PST) Date: Mon, 19 Nov 2007 07:57:16 -0800 From: Eric Rescorla To: Spencer Dawkins Subject: Re: [P2PSIP] Abusive and trustable peers and clients In-Reply-To: <20071119155304.6FA7833C2B@delta.rtfm.com> References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> <20071119020339.9D7DF33C2B@delta.rtfm.com> <076901c82abe$f7edf8a0$6601a8c0@china.huawei.com> <20071119155304.6FA7833C2B@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071119155717.5980A33C2B@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Oh, I forgot to mention, there's one more thing you can do: constantly change the protocol and force users to download new clients with different obfuscation. This creates an arms race with the attacker, because each time you change the protocol, the fake clients break and the attacker has to reverse engineer your implementation anew. This means that people using the attackers software get a lower quality of service because there are outage periods with each software release. A related (though slightly different) example of this type of situation is the repeated cracking and then fixing of the iPhone. -Ekr At Mon, 19 Nov 2007 07:53:03 -0800, Eric Rescorla wrote: > > At Mon, 19 Nov 2007 09:15:06 -0600, > Spencer Dawkins wrote: > > > > Hi, Eric, > > > > From: "Eric Rescorla" > > > > > > > At Sun, 18 Nov 2007 14:05:45 -0800, > > > Henry Sinnreich wrote: > > >> > > >> >>trustable nodes must have the software encrypted and signed by a > > >> >>central authority > > >> > > >> >How do you propose that other nodes determine whether a peer is > > >> >running such software? > > >> > > >> My assumption is the p2p overlay is run by an owner with a vested > > >> interest of protecting the overlay, just like Skype does. > > > > > > But this only works for Skype because Skype's protocol and > > > implementation are closed and therefore it's very difficult > > > for an attacker to implement the protocol themselves and/or > > > extract the keying material used by Skype clients to > > > authenticate. The first property will clearly not be true > > > of any P2PSIP imploemetnation and the second is not going > > > to be true of any open source implementation. > > > > When you say "extract the keying material", do you mean "extract the keying > > material from a packet that you overhear", or something else? > > > > I'm trying to grok the last half of the last sentence. I know it's the > > morning of I-D cutoff, so I'm probably not at the top of my game (and we can > > talk about what that might mean in Vancouver :-) ... but I'm not connecting > > all the dots. > > OK, let's take a step back: > You're the operator of some service. It could be a P2P network, but > actually the context in which this comes up the most is DRM for > digital media. Your customers use your software to access the service > and part of your security depends on the software functioning > correctly. In the case of a P2P network this may mean storing > whatever data it's supposed to store. In the case of DRM, it generally > means not exporting the media in raw form. In order to enforce this, > you write your own software that behaves the way you want and this is > the only software you allow on your network. > > Now, when the operator's server receives a message/connection/PDU > from a client, it needs to determine whether the client is running > the right software. Otherwise, the user can simply download software > which *pretends* to be your software but actually cheats (doesn't > store data, exports media in raw form, whatever). So, you need > one way to verify the software running on the other end. This > problem is called attestation, and it's believed to be quite > difficult. All the known solutions that really work involve trusted > hardware on the client side. (cf. TCG). > > If you're not going to use trusted hardware, then you end up falling > back on obfuscation. There are two things you can obfuscate: > > - The protocol. > - The program binary. > > If you use a proprietary protocol, then you make it difficult for > a third party to pretend to be one of your clients because the > first thing they need to do is reverse engineer your protocol. > The implicit theory here is that anyone who speaks your protocol > is one of your clients. > > If you want to use an open protocol, then you can't use this method, > so you end up falling back on cryptography. You use an open > protocol but then somehow issue each client a cryptographic key > which it uses to authenticate. But of course the client needs > access to the key, so the attacker can reverse engineer the client > to extract the key. And since the protocol is open, they can then > write their own implementation using the key. In order to block > this, you generally obfuscate/encrypt the program binary to make > key extraction more difficult. But this is obviously incompatible > with the client program being open source. > > Skype uses both of these techniques: the protocol is proprietary > *and* each client is issued a key at startup which is used by > an obfuscated binary. Nevertheless, both countermeasures have been > successfully attacked. Again, there is no known way of solving > this problem without using trusted hardware. > > -Ekr > > > > > > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 11:14:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9Fz-0007JG-PA; Mon, 19 Nov 2007 11:13:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu9Fy-00077J-BW for p2psip@lists.ietf.org; Mon, 19 Nov 2007 11:13:54 -0500 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu9Fu-0004zL-Hy for p2psip@lists.ietf.org; Mon, 19 Nov 2007 11:13:54 -0500 Received: from [163.117.139.215] (unknown [163.117.139.215])by smtp.uc3m.es (Postfix) with ESMTP id 6B2AB243C87; Mon, 19 Nov 2007 17:13:49 +0100 (CET) Message-ID: <4741B64A.9020208@it.uc3m.es> Date: Mon, 19 Nov 2007 17:14:02 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: =?iso-8859-1?Q?Departamento_I?= =?iso-8859-1?Q?ngenier=EDa_Telem=E1ti?= =?iso-8859-1?Q?ca=2E_Universidad_Ca?= =?iso-8859-1?Q?rlos_III_de_Madrid?= User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] Abusive and trustable peers and clients References: <473C730E.1080004@it.uc3m.es><618e24240711150935v6164ae0lf7bede7 e06770c99@mail.gmail.com><473D684A.1060502@it.uc3m.es><4d4304a00711160658h 5 3e725a9tf98018d86353a944@mail.gmail.com><473DC47C.5030003@it.uc3m.es><24C CC C428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com><20071117173115 .1C 3D933C21@delta.rtfm.com><24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5 .cor p.adobe.com><077f01c82abf$f11d0470$6601a8c0@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE306@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE306@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-17.5998 TC:1F TRN:56 TV:5.0.1023(15556.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Henry Sinnreich escribi=F3: > Spencer, > > Thanks for the question! > The section is actually: "4.1.1. Public P2P VoIP Service Providers". > > As mentioned, why can encryption and signing of the software in the > device or endpoint work only for a proprietary protocol like Skype and > not for P2PSIP, even when the SW is OS? > =20 In this case I agree with Eric. He possed some argument I support. I=20 would like to add a new argument. We are trying to standarize a p2psip protocol. However, if latter we are=20 going to allow every ISP or other company using their own p2psip overlay to encrypt and obfuscate the code we cannot assure if this code is or=20 not compliant with the defined standard. Then the standard would not be=20 anymore an standard but a set of rule to follow. And now imagine two different ISPs deploy their softwares and encrypt=20 them and at some point the want to make inter-domain communications, if=20 they are using different encryption schemes (and what would be worse, they have=20 slightly modified the standard) how their clients are going to communicat= e?. I think encryption/obfuscation works for private solution as Skype, but=20 IMO is an error consider this as part of a standard protocol. What do you think? Rub=E9n. > Henry > > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 > Sent: Monday, November 19, 2007 9:22 AM > To: p2psip@lists.ietf.org > Subject: Re: [P2PSIP] Abusive and trustable peers and clients > > =20 >>>> trustable nodes must have the software encrypted and signed by a >>>> central authority >>>> =20 > > =20 >>> How do you propose that other nodes determine whether a peer is >>> running such software? >>> =20 > > =20 >> My assumption is the p2p overlay is run by an owner with a vested >> interest of protecting the overlay, just like Skype does. >> =20 > > I note that=20 > http://tools.ietf.org/wg/p2psip/draft-bryan-p2psip-app-scenarios-00.txt= =20 > explicitly calls this application scenario out in Section 4.4.1 (and th= e > > associated attributes in Table 1). > > The authors of this draft would love to see some discussion of this=20 > particular scenario on-list, since it seems that some people are > assuming=20 > this scenario while others are assuming other scenarios. > > And if we can't frame the discussion in a specific scenario, this turns > into=20 > a "baby beauty contest" where everyone says "MY baby is the most=20 > beautiful"... > > Thanks, > > Spencer=20 > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 15:06:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCsq-0006Bu-P3; Mon, 19 Nov 2007 15:06:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCsp-0006Bm-Ci for p2psip@lists.ietf.org; Mon, 19 Nov 2007 15:06:15 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCsk-0000q6-MO for p2psip@lists.ietf.org; Mon, 19 Nov 2007 15:06:15 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRR0080WRU97G@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 12:06:09 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRR0036ORU6SE@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 12:06:09 -0800 (PST) Date: Mon, 19 Nov 2007 14:05:59 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Abusive and trustable peers and clients To: =?iso-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= , Henry Sinnreich Message-id: <07ed01c82ae7$9a7ca0d0$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; reply-type=response; charset=iso-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <473C730E.1080004@it.uc3m.es> <"618e24240711150935v6164ae0lf7bede7 e06770c99"@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <"4d4304a00711160658h5 3e725a9tf98018d86353a944"@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <"24CCC C428EFEA2469BF046DB3C7A8D223AE2F0"@namail5.corp.adobe.com> <"20071117173115.1C 3D933C21"@delta.rtfm.com> <077f01c82abf$f11d0470$6601a8c0@china.huawei.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE306@namail5.corp.adobe.com> <4741B64A.9020208@it.uc3m.es> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org ----- Original Message -----=20 =46rom: "Rub=E9n Cuevas Rum=EDn" To: "Henry Sinnreich" Cc: "Spencer Dawkins" ; Sent: Monday, November 19, 2007 10:14 AM Subject: Re: [P2PSIP] Abusive and trustable peers and clients > > > Henry Sinnreich escribi=F3: >> Spencer, >> >> Thanks for the question! >> The section is actually: "4.1.1. Public P2P VoIP Service Provider= s". >> >> As mentioned, why can encryption and signing of the software in th= e >> device or endpoint work only for a proprietary protocol like Skype= and >> not for P2PSIP, even when the SW is OS? >> > In this case I agree with Eric. He possed some argument I support. = I would=20 > like to add a new argument. > > We are trying to standarize a p2psip protocol. However, if latter w= e are=20 > going to allow every ISP or other company using their own p2psip ov= erlay > to encrypt and obfuscate the code we cannot assure if this code is = or not=20 > compliant with the defined standard. Then the standard would not be= =20 > anymore > an standard but a set of rule to follow. > > And now imagine two different ISPs deploy their softwares and encry= pt them=20 > and at some point the want to make inter-domain communications, if = they=20 > are > using different encryption schemes (and what would be worse, they h= ave=20 > slightly modified the standard) how their clients are going to=20 > communicate?. > > I think encryption/obfuscation works for private solution as Skype,= but=20 > IMO is an error consider this as part of a standard protocol. > > What do you think? > > Rub=E9n. The thing is, IETF standardizes protocols, and you're including a pro= tocol=20 implementation as part of the standard. For IETF, the standard IS a s= et of=20 rules to follow, in a protocol implementation, not the protocol=20 implementation itself. So I don't think we're in any danger of standardizing this in IETF. W= e don't=20 even standardize APIs (in most protocols), much less the applications= that=20 would use those APIs. Thanks, Spencer=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 15:07:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCti-0006my-Lp; Mon, 19 Nov 2007 15:07:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCth-0006mh-0G for p2psip@lists.ietf.org; Mon, 19 Nov 2007 15:07:09 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCtd-0000re-Ac for p2psip@lists.ietf.org; Mon, 19 Nov 2007 15:07:08 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRR00836RVS7G@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 12:07:05 -0800 (PST) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRR0037SRVRSE@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Mon, 19 Nov 2007 12:07:04 -0800 (PST) Date: Mon, 19 Nov 2007 14:06:55 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Abusive and trustable peers and clients To: Eric Rescorla Message-id: <07f601c82ae7$bbefdc50$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> <20071119020339.9D7DF33C2B@delta.rtfm.com> <076901c82abe$f7edf8a0$6601a8c0@china.huawei.com> <20071119155304.6FA7833C2B@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Eric, This was a great help - thanks for taking the time to write it down. Spencer > At Mon, 19 Nov 2007 09:15:06 -0600, > Spencer Dawkins wrote: >> >> Hi, Eric, >> >> From: "Eric Rescorla" >> >> >> > At Sun, 18 Nov 2007 14:05:45 -0800, >> > Henry Sinnreich wrote: >> >> >> >> >>trustable nodes must have the software encrypted and signed by a >> >> >>central authority >> >> >> >> >How do you propose that other nodes determine whether a peer is >> >> >running such software? >> >> >> >> My assumption is the p2p overlay is run by an owner with a vested >> >> interest of protecting the overlay, just like Skype does. >> > >> > But this only works for Skype because Skype's protocol and >> > implementation are closed and therefore it's very difficult >> > for an attacker to implement the protocol themselves and/or >> > extract the keying material used by Skype clients to >> > authenticate. The first property will clearly not be true >> > of any P2PSIP imploemetnation and the second is not going >> > to be true of any open source implementation. >> >> When you say "extract the keying material", do you mean "extract the >> keying >> material from a packet that you overhear", or something else? >> >> I'm trying to grok the last half of the last sentence. I know it's the >> morning of I-D cutoff, so I'm probably not at the top of my game (and we >> can >> talk about what that might mean in Vancouver :-) ... but I'm not >> connecting >> all the dots. > > OK, let's take a step back: > You're the operator of some service. It could be a P2P network, but > actually the context in which this comes up the most is DRM for > digital media. Your customers use your software to access the service > and part of your security depends on the software functioning > correctly. In the case of a P2P network this may mean storing > whatever data it's supposed to store. In the case of DRM, it generally > means not exporting the media in raw form. In order to enforce this, > you write your own software that behaves the way you want and this is > the only software you allow on your network. > > Now, when the operator's server receives a message/connection/PDU > from a client, it needs to determine whether the client is running > the right software. Otherwise, the user can simply download software > which *pretends* to be your software but actually cheats (doesn't > store data, exports media in raw form, whatever). So, you need > one way to verify the software running on the other end. This > problem is called attestation, and it's believed to be quite > difficult. All the known solutions that really work involve trusted > hardware on the client side. (cf. TCG). > > If you're not going to use trusted hardware, then you end up falling > back on obfuscation. There are two things you can obfuscate: > > - The protocol. > - The program binary. > > If you use a proprietary protocol, then you make it difficult for > a third party to pretend to be one of your clients because the > first thing they need to do is reverse engineer your protocol. > The implicit theory here is that anyone who speaks your protocol > is one of your clients. > > If you want to use an open protocol, then you can't use this method, > so you end up falling back on cryptography. You use an open > protocol but then somehow issue each client a cryptographic key > which it uses to authenticate. But of course the client needs > access to the key, so the attacker can reverse engineer the client > to extract the key. And since the protocol is open, they can then > write their own implementation using the key. In order to block > this, you generally obfuscate/encrypt the program binary to make > key extraction more difficult. But this is obviously incompatible > with the client program being open source. > > Skype uses both of these techniques: the protocol is proprietary > *and* each client is issued a key at startup which is used by > an obfuscated binary. Nevertheless, both countermeasures have been > successfully attacked. Again, there is no known way of solving > this problem without using trusted hardware. > > -Ekr > > > > > > > > > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 16:33:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEF4-0001dR-Gl; Mon, 19 Nov 2007 16:33:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEF2-0001XF-6f for p2psip@ietf.org; Mon, 19 Nov 2007 16:33:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuEF1-00043y-RP for p2psip@ietf.org; Mon, 19 Nov 2007 16:33:16 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Nov 2007 13:33:15 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAJLXFWh025617; Mon, 19 Nov 2007 13:33:15 -0800 Received: from [128.107.139.111] (dhcp-128-107-139-111.cisco.com [128.107.139.111]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAJLXFGc022482; Mon, 19 Nov 2007 21:33:15 GMT In-Reply-To: <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> References: <01b501c8281c$1b655440$5105a40a@china.huawei.com> <369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu> <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59ED452D-A7D1-4F66-8342-9759089F5538@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Mon, 19 Nov 2007 13:33:09 -0800 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1068; t=1195507995; x=1196371995; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20[P2PSIP=3ASurvey]=20P2PSIP=20Client=20Char acter/Behavior |Sender:=20; bh=yipG4n0YL3nrDWe4iQyEskbFiaUtdwfe1qr+ZD9bMCs=; b=nio+qfMpCsBKdDYuQoa1UwCdPYGQQadbLny14FsFSq5ptEzuuTYi6EYaIXFbABmv9vR5+ooh bZLf1vxukWy+3h2MXOngQZypfYF2trBWH39MoOl6FYL+zhPxchppN0pc; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 19, 2007, at 5:43 AM, Henning Schulzrinne wrote: >> >> Your e-mail is a good start to an argument why there might be >> nodes that can and might want to be clients, but cannot be peers, >> though it still doesn't describe WHAT a client is. > > That's simple: For the current definition of the protocols, P2PSIP > protocols do a key-to-value lookup. A client can perform a get and > put operation (and other related data manipulation operations), but > does not route P2PSIP protocol requests. > > Henning I would probably add that it does not store information that is saved in the DHT. (i.e. other nodes can not sent a PUT or GET to the client, clearly the client and PUT some information into the DHT by sending a PUT to another node). One of the interesting questions about Clients to me is if a given overlay allows Clients to connect, what is the incentive for anyone to be a Peer. I'm not sure we will ever come to a good answer to this other than to deploy and see. Cullen _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 16:58:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEdJ-0002zf-9K; Mon, 19 Nov 2007 16:58:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuEdI-0002z9-8v for p2psip@ietf.org; Mon, 19 Nov 2007 16:58:20 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuEdD-0005pN-U2 for p2psip@ietf.org; Mon, 19 Nov 2007 16:58:20 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113]) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lAJLw6OR014077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 19 Nov 2007 15:58:07 -0600 In-Reply-To: <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> References: <01b501c8281c$1b655440$5105a40a@china.huawei.com> <369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu> <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0B80FCAE-B2B8-4FE7-9D89-8F9D1277418B@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 19 Nov 2007 15:57:31 -0600 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Philip Matthews , P2PSIP Mailing List Subject: [P2PSIP] Why just "peer" and "client"? (was Re: P2PSIP Client Character/Behavior) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 19, 2007, at 7:43 AM, Henning Schulzrinne wrote: >> >> Your e-mail is a good start to an argument why there might be >> nodes that can and might want to be clients, but cannot be peers, >> though it still doesn't describe WHAT a client is. > > That's simple: For the current definition of the protocols, P2PSIP > protocols do a key-to-value lookup. A client can perform a get and > put operation (and other related data manipulation operations), but > does not route P2PSIP protocol requests. Does a client store stuff for other users in the overlay? If not, that's another difference between clients and peers. Personally, I'm now thinking of "client" and "peer" nodes as hypothetical points in a continuum of functionality. I expect real systems to slide around in that continuum based on their current circumstances. They might be high bandwidth or low bandwidth, plugged in or battery operated, charged by byte or all-you-can-eat, have no free memory or terabytes of it, be stuck behind an obnoxious firewall or full-exposed. They might be very busy, or operating with no load at all. They might have STUN capacity to offer, and they might not. There are probably more axes of freedom in this continuum than we have yet imagined. And many devices will shift where the are, from time to time. Mobile devices will move between access points and access technologies. Devices in data centers will get busy. Voice mail boxes will fill up. Any device might be affected by maintenance, peripheral death, and so on. So I'd really like to see some way that nodes can adapt to their changing situations without having to make an all-or-nothing commitment. Even for nodes that are "fully committed", I'd like to se a way for them to back off gracefully so they're not "fully committed" the same way a goose is to foie gras -- that is, stuffed beyond capacity and then turned into pate'. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 20:40:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuI6F-0005za-L5; Mon, 19 Nov 2007 20:40:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuI6E-0005tT-2r for p2psip@ietf.org; Mon, 19 Nov 2007 20:40:26 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuI6D-0001ei-QE for p2psip@ietf.org; Mon, 19 Nov 2007 20:40:26 -0500 Received: from flame.cs.columbia.edu (flame.cs.columbia.edu [128.59.16.145]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAK1eHUf000053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 19 Nov 2007 20:40:22 -0500 (EST) Date: Mon, 19 Nov 2007 20:40:17 -0500 (EST) From: Salman Abdul Baset To: P2PSIP Mailing List In-Reply-To: <0B80FCAE-B2B8-4FE7-9D89-8F9D1277418B@softarmor.com> Message-ID: References: <01b501c8281c$1b655440$5105a40a@china.huawei.com> <369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu> <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> <0B80FCAE-B2B8-4FE7-9D89-8F9D1277418B@softarmor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [P2PSIP] P2PP-01 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org is available at: http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-01.txt This document defines the Peer-to-Peer Protocol (P2PP), an application-layer binary protocol, for creating and maintaining an overlay of participant nodes. The overlay can be created using various structured and unstructured peer-to-peer protocols such as Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a secure transport, supports an application API, has mechanisms for NAT and firewall traversal, exchanging node capabilities, and diagnostic information. P2PP is designed to support a P2P Session Initiation Protocol (SIP) network, but it can be used for other applications as well. Comments are welcome. -salman _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 21:19:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIi4-0006iI-PS; Mon, 19 Nov 2007 21:19:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIi3-0006i8-Vb for p2psip@ietf.org; Mon, 19 Nov 2007 21:19:32 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuIi3-0002xG-9N for p2psip@ietf.org; Mon, 19 Nov 2007 21:19:31 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRS0075J93E8S@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 10:18:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRS00IQR93DL6@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 10:18:50 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRS00BLA93A3R@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 10:18:49 +0800 (CST) Date: Tue, 20 Nov 2007 10:18:46 +0800 From: Zheng Hewen In-reply-to: <59ED452D-A7D1-4F66-8342-9759089F5538@cisco.com> To: 'Cullen Jennings' , 'Henning Schulzrinne' Message-id: <033101c82b1b$ae37c120$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acgq89ITSMlytt08TMm9eASbA5vXlgAJIzXg X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 'Philip Matthews' , 'P2PSIP Mailing List' Subject: [P2PSIP] RE: [P2PSIP:Survey] P2PSIP Client Character/Behavior X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, In my understanding, P2PSIP client is a node which gets P2PSIP overlay services (e.g., distributed storage and distributed transport) from an associated P2PSIP peer without any SIP entity. P2PSIP clients are non-overlay-routing nodes, and P2PSIP peers are overlay-routing nodes, P2PSIP overlay network is transparent to P2PSIP clients (i.e. P2PSIP clients are not aware of the topology of P2PSIP overlay network). Some nodes acts as P2PSIP clients due to limited capability (e.g., limited power/lifetime, thin storage capacity), some nodes acts as P2PSIP clients due to considering the performance and burden of P2PSIP network (e.g., more peers mean that more P2PSIP traffic consume rare and costly bandwidth of mobile nodes and potentially bigger delay), some nodes acts as P2PSIP clients due to considering the security and management (e.g., P2PSIP communication network deployed in an autonomous environment such as enterprises' VPN), We will detail the use cases about P2PSIP clients in an new I-D. For your question, P2PSIP clients can contribute its storage capacity to earn encouragement points, which can be regarded as one incentive mechanism. Essentially, in some scenarios (e.g., in an autonomous P2PSIP communication network), such an incentive mechanism is not necessary. But here is one issue about the merged RELOAD-01, if P2PSIP clients own Peer-ID, will this violate DHT algorithm when P2PSIP clients never are used to store any DHT data? Will the namespace of P2PSIP overlay not be fully available for peers? Personally, I do not think that it will impact the other P2PSIP clients application scenarios, but I wonder the answers for those above questions. Certainly, if P2PSIP clients use the other namespace than P2PSIP peers, then all is OK. Best regards, Hewen > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 2007?11?20? 5:33 > To: Henning Schulzrinne > Cc: Philip Matthews; P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > On Nov 19, 2007, at 5:43 AM, Henning Schulzrinne wrote: > > >> > >> Your e-mail is a good start to an argument why there might > be nodes > >> that can and might want to be clients, but cannot be > peers, though it > >> still doesn't describe WHAT a client is. > > > > That's simple: For the current definition of the protocols, P2PSIP > > protocols do a key-to-value lookup. A client can perform a > get and put > > operation (and other related data manipulation operations), > but does > > not route P2PSIP protocol requests. > > > > Henning > > I would probably add that it does not store information that > is saved in the DHT. (i.e. other nodes can not sent a PUT or > GET to the client, clearly the client and PUT some > information into the DHT by sending a PUT to another node). > > One of the interesting questions about Clients to me is if a > given overlay allows Clients to connect, what is the > incentive for anyone to be a Peer. I'm not sure we will ever > come to a good answer to this other than to deploy and see. > > Cullen > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 21:21:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIjf-0000EQ-RG; Mon, 19 Nov 2007 21:21:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIje-00009x-WA for p2psip@lists.ietf.org; Mon, 19 Nov 2007 21:21:11 -0500 Received: from exprod6og52.obsmtp.com ([64.18.1.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuIjb-0003uO-6s for p2psip@lists.ietf.org; Mon, 19 Nov 2007 21:21:10 -0500 Received: from source ([192.150.20.142]) by exprod6ob52.postini.com ([64.18.5.12]) with SMTP; Mon, 19 Nov 2007 18:21:04 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAK2KpNT012075; Mon, 19 Nov 2007 18:20:56 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAK2KiFb018338; Mon, 19 Nov 2007 18:20:51 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 11:20:46 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Abusive and trustable peers and clients Date: Mon, 19 Nov 2007 18:20:37 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE309@namail5.corp.adobe.com> In-Reply-To: <07f601c82ae7$bbefdc50$6601a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Abusive and trustable peers and clients Thread-Index: Acgq59Cn04lH8bFiTVe3ACn1RsnXYwAK+qog References: <473C730E.1080004@it.uc3m.es><618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com><473D684A.1060502@it.uc3m.es><4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com><473DC47C.5030003@it.uc3m.es><24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com><20071117173115.1C3D933C21@delta.rtfm.com><24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com><20071119020339.9D7DF33C2B@delta.rtfm.com><076901c82abe$f7edf8a0$6601a8c0@china.huawei.com><20071119155304.6FA7833C2B@delta.rtfm.com> <07f601c82ae7$bbefdc50$6601a8c0@china.huawei.com> From: "Henry Sinnreich" To: "Spencer Dawkins" , "Eric Rescorla" X-OriginalArrivalTime: 20 Nov 2007 02:20:46.0239 (UTC) FILETIME=[F5770AF0:01C82B1B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Thanks Eric and Spencer for taking time to discuss this. > Again, there is no known way of solving > this problem without using trusted hardware. I agree. Thanks again, Henry -----Original Message----- From: Spencer Dawkins [mailto:spencer@mcsr-labs.org]=20 Sent: Monday, November 19, 2007 2:07 PM To: Eric Rescorla Cc: p2psip@lists.ietf.org Subject: Re: [P2PSIP] Abusive and trustable peers and clients Hi, Eric, This was a great help - thanks for taking the time to write it down. Spencer > At Mon, 19 Nov 2007 09:15:06 -0600, > Spencer Dawkins wrote: >> >> Hi, Eric, >> >> From: "Eric Rescorla" >> >> >> > At Sun, 18 Nov 2007 14:05:45 -0800, >> > Henry Sinnreich wrote: >> >> >> >> >>trustable nodes must have the software encrypted and signed by a >> >> >>central authority >> >> >> >> >How do you propose that other nodes determine whether a peer is >> >> >running such software? >> >> >> >> My assumption is the p2p overlay is run by an owner with a vested >> >> interest of protecting the overlay, just like Skype does. >> > >> > But this only works for Skype because Skype's protocol and >> > implementation are closed and therefore it's very difficult >> > for an attacker to implement the protocol themselves and/or >> > extract the keying material used by Skype clients to >> > authenticate. The first property will clearly not be true >> > of any P2PSIP imploemetnation and the second is not going >> > to be true of any open source implementation. >> >> When you say "extract the keying material", do you mean "extract the=20 >> keying >> material from a packet that you overhear", or something else? >> >> I'm trying to grok the last half of the last sentence. I know it's the >> morning of I-D cutoff, so I'm probably not at the top of my game (and we=20 >> can >> talk about what that might mean in Vancouver :-) ... but I'm not=20 >> connecting >> all the dots. > > OK, let's take a step back: > You're the operator of some service. It could be a P2P network, but > actually the context in which this comes up the most is DRM for > digital media. Your customers use your software to access the service > and part of your security depends on the software functioning > correctly. In the case of a P2P network this may mean storing > whatever data it's supposed to store. In the case of DRM, it generally > means not exporting the media in raw form. In order to enforce this, > you write your own software that behaves the way you want and this is > the only software you allow on your network. > > Now, when the operator's server receives a message/connection/PDU > from a client, it needs to determine whether the client is running > the right software. Otherwise, the user can simply download software > which *pretends* to be your software but actually cheats (doesn't > store data, exports media in raw form, whatever). So, you need > one way to verify the software running on the other end. This > problem is called attestation, and it's believed to be quite > difficult. All the known solutions that really work involve trusted > hardware on the client side. (cf. TCG). > > If you're not going to use trusted hardware, then you end up falling > back on obfuscation. There are two things you can obfuscate: > > - The protocol. > - The program binary. > > If you use a proprietary protocol, then you make it difficult for > a third party to pretend to be one of your clients because the > first thing they need to do is reverse engineer your protocol. > The implicit theory here is that anyone who speaks your protocol > is one of your clients. > > If you want to use an open protocol, then you can't use this method, > so you end up falling back on cryptography. You use an open > protocol but then somehow issue each client a cryptographic key > which it uses to authenticate. But of course the client needs > access to the key, so the attacker can reverse engineer the client > to extract the key. And since the protocol is open, they can then > write their own implementation using the key. In order to block > this, you generally obfuscate/encrypt the program binary to make > key extraction more difficult. But this is obviously incompatible > with the client program being open source. > > Skype uses both of these techniques: the protocol is proprietary > *and* each client is issued a key at startup which is used by > an obfuscated binary. Nevertheless, both countermeasures have been > successfully attacked. Again, there is no known way of solving > this problem without using trusted hardware. > > -Ekr > > > > > > > > > > > >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 21:29:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIre-0002Tv-Bd; Mon, 19 Nov 2007 21:29:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIrc-0002TP-Qo for p2psip@lists.ietf.org; Mon, 19 Nov 2007 21:29:24 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuIrZ-00044y-9I for p2psip@lists.ietf.org; Mon, 19 Nov 2007 21:29:24 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAK2THP24019; Tue, 20 Nov 2007 02:29:17 GMT Received: from marcus2.localdomain ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 21:29:02 -0500 Message-ID: <47424669.6000807@nortel.com> Date: Mon, 19 Nov 2007 21:28:57 -0500 From: "Marcus Leech" User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [P2PSIP] Abusive and trustable peers and clients References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> <20071119020339.9D7DF33C2B@delta.rtfm.com> <076901c82abe$f7edf8a0$6601a8c0@china.huawei.com> <20071119155304.6FA7833C2B@delta.rtfm.com> In-Reply-To: <20071119155304.6FA7833C2B@delta.rtfm.com> X-Enigmail-Version: 0.95.5 OpenPGP: id=4EC1F1F4 X-OriginalArrivalTime: 20 Nov 2007 02:29:02.0160 (UTC) FILETIME=[1D0E9500:01C82B1D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1990720835==" Errors-To: p2psip-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1990720835== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0ECB58A8A27E26167458345D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0ECB58A8A27E26167458345D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > > Skype uses both of these techniques: the protocol is proprietary > *and* each client is issued a key at startup which is used by > an obfuscated binary. Nevertheless, both countermeasures have been > successfully attacked. Again, there is no known way of solving > this problem without using trusted hardware. > > -Ekr > > =20 Even then, I'm not convinced that the problem can be solved for a sufficiently robust definition of "solved". In the TCG approach, a tiny little piece of *something* runs in the TPM, and it has to rely on a very large, complicated, inherently-untrustable "blob" (the OS and all its applications) to hand it things to attest to. Dicey. --------------enig0ECB58A8A27E26167458345D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHQkZp9kpZq07B8fQRAvnMAKC1NyqapaaUrU7QOvqzSsFn2gkKsACglsu/ rFQ8yMgV3PYGOS1BOzFJQ3Y= =vk2E -----END PGP SIGNATURE----- --------------enig0ECB58A8A27E26167458345D-- --===============1990720835== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1990720835==-- From p2psip-bounces@ietf.org Mon Nov 19 21:32:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIuR-000401-Tn; Mon, 19 Nov 2007 21:32:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuIuQ-0003zd-SD for p2psip@ietf.org; Mon, 19 Nov 2007 21:32:18 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuIuM-00048V-Qw for p2psip@ietf.org; Mon, 19 Nov 2007 21:32:18 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRS00E9A9OGSK@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 10:31:28 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRS00E6V9OFJG@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 10:31:28 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRS00B6L9OF3R@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 10:31:27 +0800 (CST) Date: Tue, 20 Nov 2007 10:31:27 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> To: 'Henning Schulzrinne' , 'Philip Matthews' Message-id: <007001c82b1d$73bcd420$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acgqsi29WBUflS6GT1G85el0eF5p/gAaVGjQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Another case where acting as a client may be better than acting as a peer for a node. In some cases, there are some nodes providing services which are useful to the overlay, for example, STUN, TURN service, etc. If these nodes are put into the overlay as a peer, it should participate in the overlay maintenance work, store pair on behalf the overlay and forward the packet for other peers. These works will account for part of resource they have. Moreover, if these nodes play Peer role in addition to service provider, it may be under the threats which comes from its peer role. So from the stability of the provided service, the best role they play may be clients, not peer, even they have strong processing power, high bandwidth, on the public Internet, etc. Regards! -- Jiang XingFeng > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, November 19, 2007 9:43 PM > To: Philip Matthews > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > > > Your e-mail is a good start to an argument why there might be nodes > > that can and might want to be clients, but cannot be peers, though > > it still doesn't describe WHAT a client is. > > That's simple: For the current definition of the protocols, P2PSIP > protocols do a key-to-value lookup. A client can perform a get and put > operation (and other related data manipulation operations), but does > not route P2PSIP protocol requests. > > Henning > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 21:44:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJ5s-00044E-TA; Mon, 19 Nov 2007 21:44:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJ5r-000449-7Z for p2psip@lists.ietf.org; Mon, 19 Nov 2007 21:44:07 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuJ5o-0004PH-PS for p2psip@lists.ietf.org; Mon, 19 Nov 2007 21:44:07 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 18A9233C21; Mon, 19 Nov 2007 18:39:04 -0800 (PST) Date: Mon, 19 Nov 2007 18:39:03 -0800 From: Eric Rescorla To: "Marcus Leech" Subject: Re: [P2PSIP] Abusive and trustable peers and clients In-Reply-To: <47424669.6000807@nortel.com> References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> <20071119020339.9D7DF33C2B@delta.rtfm.com> <076901c82abe$f7edf8a0$6601a8c0@china.huawei.com> <20071119155304.6FA7833C2B@delta.rtfm.com> <47424669.6000807@nortel.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071120023904.18A9233C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 19 Nov 2007 21:28:57 -0500, Marcus Leech wrote: > > [1 ] > Eric Rescorla wrote: > > > > Skype uses both of these techniques: the protocol is proprietary > > *and* each client is issued a key at startup which is used by > > an obfuscated binary. Nevertheless, both countermeasures have been > > successfully attacked. Again, there is no known way of solving > > this problem without using trusted hardware. > > > > -Ekr > > > > > Even then, I'm not convinced that the problem can be solved for a > sufficiently robust definition of "solved". > > In the TCG approach, a tiny little piece of *something* runs in the TPM, > and it has to rely on a very large, > complicated, inherently-untrustable "blob" (the OS and all its > applications) to hand it things to attest to. > Dicey. Yes, I'm not convinced as well, but I figured it was easier to withhold judgement on that point, since I don't expect us to require trusted hardware. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 19 22:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJaJ-0005gk-FM; Mon, 19 Nov 2007 22:15:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuJaG-0005gf-Mf for p2psip@lists.ietf.org; Mon, 19 Nov 2007 22:15:32 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuJaD-0004vP-Dl for p2psip@lists.ietf.org; Mon, 19 Nov 2007 22:15:32 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id lAK3FPT22012; Tue, 20 Nov 2007 03:15:26 GMT Received: from marcus2.localdomain ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 22:15:25 -0500 Message-ID: <47425141.6000701@nortel.com> Date: Mon, 19 Nov 2007 22:15:13 -0500 From: "Marcus Leech" User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [P2PSIP] Abusive and trustable peers and clients References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <24CCCC428EFEA2469BF046DB3C7A8D223AE2F0@namail5.corp.adobe.com> <20071117173115.1C3D933C21@delta.rtfm.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE2FC@namail5.corp.adobe.com> <20071119020339.9D7DF33C2B@delta.rtfm.com> <076901c82abe$f7edf8a0$6601a8c0@china.huawei.com> <20071119155304.6FA7833C2B@delta.rtfm.com> <47424669.6000807@nortel.com> <20071120023904.18A9233C21@delta.rtfm.com> In-Reply-To: <20071120023904.18A9233C21@delta.rtfm.com> X-Enigmail-Version: 0.95.5 OpenPGP: id=4EC1F1F4 X-OriginalArrivalTime: 20 Nov 2007 03:15:25.0736 (UTC) FILETIME=[98329280:01C82B23] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1872645779==" Errors-To: p2psip-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1872645779== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig082DDD24BED173ACD9688919" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig082DDD24BED173ACD9688919 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Eric Rescorla wrote: > > Yes, I'm not convinced as well, but I figured it was easier to > withhold judgement on that point, since I don't expect us to > require trusted hardware. > > =20 Fair enough. I shall not mention it again. --------------enig082DDD24BED173ACD9688919 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHQlFF9kpZq07B8fQRAocXAKCQ+169tjjFoTzpimmNQerruu0NPACcDyB5 /dGoVN257Qac2y2fUgZSqDo= =DbFD -----END PGP SIGNATURE----- --------------enig082DDD24BED173ACD9688919-- --===============1872645779== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1872645779==-- From p2psip-bounces@ietf.org Mon Nov 19 23:01:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuKIs-0002G7-EM; Mon, 19 Nov 2007 23:01:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuKIr-0002Fy-2E for p2psip@ietf.org; Mon, 19 Nov 2007 23:01:37 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuKIo-00053v-9y for p2psip@ietf.org; Mon, 19 Nov 2007 23:01:34 -0500 Received: from [72.87.190.172] (helo=[10.9.0.1]) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IuKIn-0002br-FA; Mon, 19 Nov 2007 23:01:33 -0500 Message-ID: <47425BEC.4070908@idssoftware.com> Date: Mon, 19 Nov 2007 20:00:44 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification for draft-bryan-p2psip-reload-02 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da940f64f0df8536904e39b5cf200b4abe21f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.87.190.172 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Compared to the classic Chord, the modified Chord algorithm mentioned in this draft advocates an inverted finger table in which n.finger[1] is the successor of n + (2^(m-1)), where m is the size of the ID address space. Is there a formal paper presenting this modified algorithm? Thank you --Michael Cullen Jennings wrote: > > The various authors of ASP and RELOAD have managed to get these two > proposal merged together into one and we are pretty happy with the > result. > > You can find it at > http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-02.txt > > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: November 18, 2007 8:57:03 PM PST >> To: fluffy@cisco.com >> Cc: lowekamp@sipeerior.com, ekr@networkresonance.com, jdrosen@cisco.com >> Subject: New Version Notification for draft-bryan-p2psip-reload-02 >> >> >> A new version of I-D, draft-bryan-p2psip-reload-02.txt has been >> successfuly submitted by Cullen Jennings and posted to the IETF >> repository. >> >> Filename: draft-bryan-p2psip-reload >> Revision: 02 >> Title: REsource LOcation And Discovery (RELOAD) >> Creation_date: 2007-11-18 >> WG ID: Independent Submission >> Number_of_pages: 96 >> >> Abstract: >> This document defines REsource LOcation And Discovery (RELOAD), a >> peer-to-peer (P2P) binary signaling protocol for usage on the >> Internet. A P2P signaling protocol provides its clients with an >> abstract hash table service between a set of cooperating peers that >> form the overlay network. RELOAD is designed to support a P2P >> Session Initiation Protocol (P2PSIP) network, but it can be utilized >> by other applications with similar requirements by defining new >> usages that specify the data types that must be stored for a >> particular application, such as location for SIP. RELOAD defines a >> security model based on a certificate enrollment service that >> provides unique identities. NAT traversal is a fundamental service >> of the protocol. >> >> This draft represents a concrete proposal for the P2PSIP Peer >> Protocol. The protocol described here builds on the lessons and >> experiences from designing and implementing the dSIP, ASP, and RELOAD >> protocols and is a merge of features from RELOAD-01 and ASP. >> >> >> >> The IETF Secretariat. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 00:02:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuLFv-0002NX-Ac; Tue, 20 Nov 2007 00:02:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuLFt-0002NO-FG for p2psip@ietf.org; Tue, 20 Nov 2007 00:02:37 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuLFs-0006JE-N6 for p2psip@ietf.org; Tue, 20 Nov 2007 00:02:37 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2007 21:02:36 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAK52Z2r027978; Mon, 19 Nov 2007 21:02:35 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id lAK52UUW012320; Tue, 20 Nov 2007 05:02:35 GMT In-Reply-To: <47425BEC.4070908@idssoftware.com> References: <47425BEC.4070908@idssoftware.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <947D2987-B9C7-4842-871E-299983DD1180@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification for draft-bryan-p2psip-reload-02 Date: Mon, 19 Nov 2007 21:01:42 -0800 To: Michael Chen X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4138; t=1195534955; x=1196398955; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Merge=20of=20ASP=20and=20RELOAD=20-=20Vers ion=20Notification=20for=09draft-bryan-p2psip-reload-02 |Sender:=20; bh=7E2oHwK0iCXs/Q6II2LTStF4MiUoT8MqIpPVf8A4bK8=; b=u0MxA+tHriK4ThbnVq9pV107Sd9+z3gUuh/F3OAf0ZHtDvCTJrm32Zl68HNSDgaN+tb0IMzk B+CcHg+iGLEzsgl2inAt/hjgaKKN9YIB0NoG1Xx6W2ydECrjUZk6hgsV; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org So classic cord has the finger table entries set as (all math is mod 2^m here so I will omit the mod 2^m parts) finger[k] = n+2^(k-1) for 1 <= k <= m we have the same entries but in the reverse order in the finger table. The chord algorithm is still the same in that the same peer is still the one used next - i.e. we search the array in the opposite order as chord did so as to keep the algorithm the same as chord. The only thing that really changed is the layout of bits in memory not the algorithm. The reason this was done is that when you want to truncate the finger table and have less finger table entries than the value of m, then the original chord required you to remove entries from the beginning of the finger table while if with the reverse order removes entries from the end of the table. In implementing it, we found removing from the beginning with offset seemed fairly confusing and reversing it made it easier to not have weird off by one bugs and such. It's really not a big deal as it is only an implementation detail and not something that changes any of the over the wire behavior. If folks felt we should write up the other way we could easily do that - we were just trying to make it easy for implementations with truncated tables. Cullen On Nov 19, 2007, at 8:00 PM, Michael Chen wrote: > Hi, > > Compared to the classic Chord, the modified Chord algorithm > mentioned in > this draft advocates an inverted finger table in which n.finger[1] is > the successor of n + (2^(m-1)), where m is the size of the ID address > space. Is there a formal paper presenting this modified algorithm? > > Thank you > > --Michael > > Cullen Jennings wrote: > > > > The various authors of ASP and RELOAD have managed to get these two > > proposal merged together into one and we are pretty happy with the > > result. > > > > You can find it at > > http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-02.txt > > > > > > Begin forwarded message: > > > >> From: IETF I-D Submission Tool > >> Date: November 18, 2007 8:57:03 PM PST > >> To: fluffy@cisco.com > >> Cc: lowekamp@sipeerior.com, ekr@networkresonance.com, > jdrosen@cisco.com > >> Subject: New Version Notification for draft-bryan-p2psip-reload-02 > >> > >> > >> A new version of I-D, draft-bryan-p2psip-reload-02.txt has been > >> successfuly submitted by Cullen Jennings and posted to the IETF > >> repository. > >> > >> Filename: draft-bryan-p2psip-reload > >> Revision: 02 > >> Title: REsource LOcation And Discovery (RELOAD) > >> Creation_date: 2007-11-18 > >> WG ID: Independent Submission > >> Number_of_pages: 96 > >> > >> Abstract: > >> This document defines REsource LOcation And Discovery (RELOAD), a > >> peer-to-peer (P2P) binary signaling protocol for usage on the > >> Internet. A P2P signaling protocol provides its clients with an > >> abstract hash table service between a set of cooperating peers that > >> form the overlay network. RELOAD is designed to support a P2P > >> Session Initiation Protocol (P2PSIP) network, but it can be > utilized > >> by other applications with similar requirements by defining new > >> usages that specify the data types that must be stored for a > >> particular application, such as location for SIP. RELOAD defines a > >> security model based on a certificate enrollment service that > >> provides unique identities. NAT traversal is a fundamental service > >> of the protocol. > >> > >> This draft represents a concrete proposal for the P2PSIP Peer > >> Protocol. The protocol described here builds on the lessons and > >> experiences from designing and implementing the dSIP, ASP, and > RELOAD > >> protocols and is a merge of features from RELOAD-01 and ASP. > >> > >> > >> > >> The IETF Secretariat. > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 00:13:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuLQB-0003E6-ET; Tue, 20 Nov 2007 00:13:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuLQ9-0003Du-SO for p2psip@ietf.org; Tue, 20 Nov 2007 00:13:13 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuLQ9-0006WS-HD for p2psip@ietf.org; Tue, 20 Nov 2007 00:13:13 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 19 Nov 2007 21:13:13 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAK5DCCB006377; Mon, 19 Nov 2007 21:13:12 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAK5DB41018641; Tue, 20 Nov 2007 05:13:11 GMT In-Reply-To: <033101c82b1b$ae37c120$5105a40a@china.huawei.com> References: <033101c82b1b$ae37c120$5105a40a@china.huawei.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83E64480-F040-4913-8CD1-845A1EB96282@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 19 Nov 2007 21:12:23 -0800 To: Zheng Hewen X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1061; t=1195535592; x=1196399592; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP=3ASurvey]=20P2PSIP=20Client=20Character/Behav ior |Sender:=20; bh=SIb52oY08eeiy9hJp7b5picNTfmXLYxyO7py3Q7BFns=; b=HW1hbn36i9HARxfmIw5Wd4TkJN32oPf8FOyJS03b68FYE3Y3a2cUvQ5S0DYs4nFikDRV4K2C zHQaoXE9Vp3VWLYMMpF6hQgXEJ29DMhfA8HzDCicoNMNVZ2fQbVMabzNnEsI+u+USrymF/u24C KQ6eM12dXUljvjGelu8RIZAak=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: P2PSIP Mailing List Subject: [P2PSIP] Re: [P2PSIP:Survey] P2PSIP Client Character/Behavior X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 19, 2007, at 6:18 PM, Zheng Hewen wrote: > But here is one issue about the merged RELOAD-01, if P2PSIP > clients own Peer-ID, will this violate DHT algorithm when > P2PSIP clients never are used to store any DHT data? Will the > namespace of P2PSIP overlay not be fully available for peers? > Personally, I do not think that it will impact the other P2PSIP > clients application scenarios, but I wonder the answers for > those above questions. Certainly, if P2PSIP clients use the other > namespace than P2PSIP peers, then all is OK. Let's say some peer-id, X is being used by a client. From the perspective of the the peers for routing and storage, this is the same as if X had been allocated to some peer but that peer was not currently online. The client never does a join to insert X into the DHT topology. The whole space of resource-id is still available for use by the DHT. The advantage of this design is that unifies the authorization model for clients and peer. Cullen _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 00:55:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuM4j-00087n-8x; Tue, 20 Nov 2007 00:55:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuM4h-00087f-Py for p2psip@ietf.org; Tue, 20 Nov 2007 00:55:07 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuM4h-0007Pe-3Y for p2psip@ietf.org; Tue, 20 Nov 2007 00:55:07 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRS00DRYJ2O35@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 13:54:24 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRS00LA9J2O0C@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 13:54:24 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRS00IEWJ2KNK@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 13:54:24 +0800 (CST) Date: Tue, 20 Nov 2007 13:54:20 +0800 From: Zheng Hewen In-reply-to: <83E64480-F040-4913-8CD1-845A1EB96282@cisco.com> To: 'Cullen Jennings' Message-id: <035301c82b39$cb90bdd0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcgrNA3Ou6YDDm2PSMWMTQIDWBpf1gAA6v9w X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'P2PSIP Mailing List' Subject: [P2PSIP] RE: [P2PSIP:Survey] P2PSIP Client Character/Behavior X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline ... ... Best regards, Hewen > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: 2007?11?20? 13:12 > To: Zheng Hewen > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > On Nov 19, 2007, at 6:18 PM, Zheng Hewen wrote: > > > But here is one issue about the merged RELOAD-01, if > P2PSIP clients > > own Peer-ID, will this violate DHT algorithm when P2PSIP > clients never > > are used to store any DHT data? Will the namespace of > P2PSIP overlay > > not be fully available for peers? > > Personally, I do not think that it will impact the other P2PSIP > > clients application scenarios, but I wonder the answers for those > > above questions. Certainly, if P2PSIP clients use the other > namespace > > than P2PSIP peers, then all is OK. > > Let's say some peer-id, X is being used by a client. From the > perspective of the the peers for routing and storage, this is > the same as if X had been allocated to some peer but that > peer was not currently online. The client never does a join > to insert X into the DHT topology. The whole space of > resource-id is still available for use by the DHT. The > advantage of this design is that unifies the authorization > model for clients and peer. > [Hewen] In my understanding to your description above, the "Peer-IDs" of P2PSIP clients never emerge in DHT topology of P2PSIP overlay network, the design of RELOAD-01 only use them to identify clients and reuse the authorization model which already is used in enrollment or peers' joining procedure. Further, the "Peer-IDs" above are in fact some type of identifiers of P2PSIP clients, some peers in P2PSIP overlay network can use "Peer-IDs" which have the same value with "Peer-IDs" owned by P2PSIP clients because those "Peer-IDs" of P2PSIP clients never appear in the overlay network (i.e., Node-IDs never conflict due to repeat). In summary, essentially, the "Peer-IDs" of P2PSIP clients sit in the completely different and separate namespace with "Peer-IDs" of P2PSIP peers, is my understanding correct? > Cullen > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 01:07:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuMH6-0008Td-BZ; Tue, 20 Nov 2007 01:07:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuMH5-0008TY-2a for p2psip@ietf.org; Tue, 20 Nov 2007 01:07:55 -0500 Received: from nz-out-0506.google.com ([64.233.162.239]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuMH2-0008Ia-BK for p2psip@ietf.org; Tue, 20 Nov 2007 01:07:55 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1466838nzf for ; Mon, 19 Nov 2007 22:07:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=nZxAw5nSQvjFTe3yqpg89D4fnImus6MCDS+/7jVt/0o=; b=o9izAaZb7leUYm1FJ1DezCKBhL6zOERbQgX13/eF5sEgpFYtrbP1Eg4hbPkKuT19x+5YPlLcoakQT+c5HwDhatlVLhM9ld6b1BhJ+fET7/XAGE9fnyvT3GOWGt8ybNS9kP0Czvo1ozmclJYA6ZLZQ+I2K9vOpcwmd5cnDrxkSjU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MA4cAToVEsyQZf6QMqPoTa7tkrWEfmLstG1CMBnAZxTgpBTNrmPIUrMJcp9b5RG6lwr7Ka/R6zTDCP8+945s1rPmB1bcoyV3IqxNL/r2gArVlyrcRSH2vo6HVa3PRQaY+UcCFZjMTS/tn6/vUzU5r+BBhxXJ2ABcEa9aFHa5vPs= Received: by 10.142.215.5 with SMTP id n5mr1399790wfg.1195538871426; Mon, 19 Nov 2007 22:07:51 -0800 (PST) Received: by 10.142.200.16 with HTTP; Mon, 19 Nov 2007 22:07:51 -0800 (PST) Message-ID: <7d6b50690711192207h5451ee42k689728eb1a713e26@mail.gmail.com> Date: Tue, 20 Nov 2007 14:07:51 +0800 From: "lichun li" To: JiangXingFeng Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <007001c82b1d$73bcd420$6905a40a@china.huawei.com> MIME-Version: 1.0 References: <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> <007001c82b1d$73bcd420$6905a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0030143578==" Errors-To: p2psip-bounces@ietf.org --===============0030143578== Content-Type: multipart/alternative; boundary="----=_Part_19637_29435386.1195538871354" ------=_Part_19637_29435386.1195538871354 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Agree. We also analyze the necessity of P2PSIP Client. IMHO, P2PSIP Client is needed in four kinds of cases as described in " http://tools.ietf.org/wg/p2psip/draft-li-p2psip-client-protocol-00.txt". One kind of cases is usually overlooked: "Firstly, the heterogeneity of P2P overlays makes P2PSIP Client necessary. For example, a P2PSIP node which only supports Chord algorithm, needs to access services of P2PSIP overlay which uses Bamboo as P2P algorithm. Due to the incompatible P2P algorithms, the Chord-based node can not join in the Bamboo-based DHT overlay. Thus the Chord-based node has to work as P2PSIP Client." On 11/20/07, JiangXingFeng wrote: > > Another case where acting as a client may be better than acting as a peer > for a node. > > In some cases, there are some nodes providing services which are useful to > the overlay, for example, STUN, TURN service, etc. If these nodes are put > into the overlay as a peer, it should participate in the overlay > maintenance > work, store pair on behalf the overlay and forward the packet > for other peers. These works will account for part of resource they have. > Moreover, if these nodes play Peer role in addition to service provider, > it > may be under the threats which comes from its peer role. So from the > stability of the provided service, the best role they play may be clients, > not peer, even they have strong processing power, high bandwidth, on the > public Internet, etc. > > Regards! > -- > Jiang XingFeng > > > -----Original Message----- > > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Monday, November 19, 2007 9:43 PM > > To: Philip Matthews > > Cc: P2PSIP Mailing List > > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > > > > > > Your e-mail is a good start to an argument why there might be nodes > > > that can and might want to be clients, but cannot be peers, though > > > it still doesn't describe WHAT a client is. > > > > That's simple: For the current definition of the protocols, P2PSIP > > protocols do a key-to-value lookup. A client can perform a get and put > > operation (and other related data manipulation operations), but does > > not route P2PSIP protocol requests. > > > > Henning > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_19637_29435386.1195538871354 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Agree. We also analyze the necessity of P2PSIP Client. IMHO, P2PSIP Client is needed in four kinds of cases
One kind of cases is usually overlooked:
   "Firstly, the heterogeneity of P2P overlays makes P2PSIP Client
   necessary.  For example, a P2PSIP node which only supports Chord
   algorithm, needs to access services of P2PSIP overlay which uses
   Bamboo as P2P algorithm.  Due to the incompatible P2P algorithms, the
   Chord-based node can not join in the Bamboo-based DHT overlay.  Thus
   the Chord-based node has to work as P2PSIP Client."

 
On 11/20/07, JiangXingFeng <jiang.x.f@huawei.com> wrote:
Another case where acting as a client may be better than acting as a peer
for a node.

In some cases, there are some nodes providing services which are useful to
the overlay, for example, STUN, TURN service, etc. If these nodes are put
into the overlay as a peer, it should participate in the overlay maintenance
work, store <key, value> pair on behalf the overlay and forward the packet
for other peers. These works will account for part of resource they have.
Moreover, if these nodes play Peer role in addition to service provider, it
may be under the threats which comes from its peer role.  So from the
stability of the provided service, the best role they play may be clients,
not peer, even they have strong processing power, high bandwidth, on the
public Internet, etc.

Regards!
--
Jiang XingFeng

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Monday, November 19, 2007 9:43 PM
> To: Philip Matthews
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior
>
> >
> > Your e-mail is a good start to an argument why there might be nodes
> > that can and might want to be clients, but cannot be peers, though
> > it still doesn't describe WHAT a client is.
>
> That's simple: For the current definition of the protocols, P2PSIP
> protocols do a key-to-value lookup. A client can perform a get and put
> operation (and other related data manipulation operations), but does
> not route P2PSIP protocol requests.
>
> Henning
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



--
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT ------=_Part_19637_29435386.1195538871354-- --===============0030143578== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0030143578==-- From p2psip-bounces@ietf.org Tue Nov 20 02:50:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNsc-0004la-Mq; Tue, 20 Nov 2007 02:50:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuNsb-0004lP-FX for p2psip@ietf.org; Tue, 20 Nov 2007 02:50:45 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuNsa-0001WO-VB for p2psip@ietf.org; Tue, 20 Nov 2007 02:50:45 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Nov 2007 23:50:44 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAK7oiWZ006784; Mon, 19 Nov 2007 23:50:44 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id lAK7ofUW011097; Tue, 20 Nov 2007 07:50:42 GMT In-Reply-To: <035301c82b39$cb90bdd0$5105a40a@china.huawei.com> References: <035301c82b39$cb90bdd0$5105a40a@china.huawei.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <29695830-716D-41B2-AE49-EBECE3CD313E@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 19 Nov 2007 23:49:54 -0800 To: Zheng Hewen X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2984; t=1195545044; x=1196409044; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP=3ASurvey]=20P2PSIP=20Client=20Character/Behav ior |Sender:=20; bh=2Uoa+Xp3sPLR/pEySdQktQp8BW1GadGBuoeRykWlvxk=; b=lAyUu1DsERkEX9iFMOzrdAllN5dLpwcJkShMsx2kJ/gBbix5AouG50+hXBc8Ayt+0tHUJsCb XDopuyAnjRPw27WIsafhfGnNf8tkkQOkQTllh38GCoTXVuzFjHlZYnSk; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: P2PSIP Mailing List Subject: [P2PSIP] Re: [P2PSIP:Survey] P2PSIP Client Character/Behavior X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 19, 2007, at 9:54 PM, Zheng Hewen wrote: > Hi, > > Please see inline ... ... > > Best regards, > Hewen > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: 2007?11?20? 13:12 > > To: Zheng Hewen > > Cc: P2PSIP Mailing List > > Subject: Re: [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > > > > On Nov 19, 2007, at 6:18 PM, Zheng Hewen wrote: > > > > > But here is one issue about the merged RELOAD-01, if > > P2PSIP clients > > > own Peer-ID, will this violate DHT algorithm when P2PSIP > > clients never > > > are used to store any DHT data? Will the namespace of > > P2PSIP overlay > > > not be fully available for peers? > > > Personally, I do not think that it will impact the other P2PSIP > > > clients application scenarios, but I wonder the answers for those > > > above questions. Certainly, if P2PSIP clients use the other > > namespace > > > than P2PSIP peers, then all is OK. > > > > Let's say some peer-id, X is being used by a client. From the > > perspective of the the peers for routing and storage, this is > > the same as if X had been allocated to some peer but that > > peer was not currently online. The client never does a join > > to insert X into the DHT topology. The whole space of > > resource-id is still available for use by the DHT. The > > advantage of this design is that unifies the authorization > > model for clients and peer. > > > > [Hewen] In my understanding to your description above, the "Peer- > IDs" of P2PSIP clients never emerge in DHT topology of > P2PSIP overlay network, the design of RELOAD-01 only use them to > identify clients and reuse the authorization model which > already is used in enrollment or peers' joining procedure. Further, > the "Peer-IDs" above are in fact some type of > identifiers of P2PSIP clients, some peers in P2PSIP overlay network > can use "Peer-IDs" which have the same value with > "Peer-IDs" owned by P2PSIP clients because those "Peer-IDs" of > P2PSIP clients never appear in the overlay network (i.e., > Node-IDs never conflict due to repeat). In summary, essentially, > the "Peer-IDs" of P2PSIP clients sit in the completely > different and separate namespace with "Peer-IDs" of P2PSIP peers, > is my understanding correct? It is mostly correct. The place where a client's peer-id would be look at in the DHT was if there was a usage where some data type needed to be signed by the peer-id. If the client signed with their peer-id, some peer in the DHT may end up checking that signature. So you would not the enrollment process to assign the same peer-id to a client and also to a peer that were not associated with the same user. There could also be some confusion if a peer with ID X directly connected to peer with id Y and Y was also directly connected to a client with peer X. > > > > Cullen > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 03:25:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuOQR-0004Xj-H9; Tue, 20 Nov 2007 03:25:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuOQQ-0004Rt-Kx for p2psip@ietf.org; Tue, 20 Nov 2007 03:25:42 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuOQN-0002mw-AZ for p2psip@ietf.org; Tue, 20 Nov 2007 03:25:42 -0500 Received: by ug-out-1314.google.com with SMTP id u2so3549259uge for ; Tue, 20 Nov 2007 00:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=nmPFmEMJ3e/u9G70waoyedTR8evRCjeSS17iXkfBoEw=; b=dX+RCDeg4f/Ac+Y4iI4TjzVxfDIA2HvvmbMX7RtBvCerE6XLU17Xj0TpcEYtUFzv2uzesJT4GqpLlyUC8tSM5rvHlSoVN3sC9AhxB/xVqJAtT8BCOMRBrXIee8LNo+2e3Csf970g7Mf80V7l4xeD6Zyl5PyMrXwjA64CsxORVTU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mTcZjOTFa2LalhytLr29AZWTE8/TY4tm1tXjYzVEj5TIX6up8wAHBYsOVHpt4DMz729lEu89DTmbwWSKnbXs5fVZqNUuR8Uvo7WHtfqG5I8UMCU6D5Sb9Nc5MBZg1lrrSBasLEFb4oX+HxN6ClImDZGc2typYUPq0l/iCulvYXY= Received: by 10.66.255.7 with SMTP id c7mr333369ugi.1195547129172; Tue, 20 Nov 2007 00:25:29 -0800 (PST) Received: by 10.66.252.5 with HTTP; Tue, 20 Nov 2007 00:25:29 -0800 (PST) Message-ID: <618e24240711200025t54df902aibe4321f9da6341ed@mail.gmail.com> Date: Tue, 20 Nov 2007 09:25:29 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: JiangXingFeng Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <007001c82b1d$73bcd420$6905a40a@china.huawei.com> MIME-Version: 1.0 References: <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> <007001c82b1d$73bcd420$6905a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1731256532==" Errors-To: p2psip-bounces@ietf.org --===============1731256532== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gMjAvMTEvMjAwNywgSmlhbmdYaW5nRmVuZyA8amlhbmcueC5mQGh1YXdlaS5jb20+IHdyb3Rl Ogo+IEluIHNvbWUgY2FzZXMsIHRoZXJlIGFyZSBzb21lIG5vZGVzIHByb3ZpZGluZyBzZXJ2aWNl cyB3aGljaCBhcmUgdXNlZnVsIHRvCj4gdGhlIG92ZXJsYXksIGZvciBleGFtcGxlLCBTVFVOLCBU VVJOIHNlcnZpY2UsIGV0Yy4gSWYgdGhlc2Ugbm9kZXMgYXJlIHB1dAo+IGludG8gdGhlIG92ZXJs YXkgYXMgYSBwZWVyLCBpdCBzaG91bGQgcGFydGljaXBhdGUgaW4gdGhlIG92ZXJsYXkgbWFpbnRl bmFuY2UKPiB3b3JrLCBzdG9yZSA8a2V5LCB2YWx1ZT4gcGFpciBvbiBiZWhhbGYgdGhlIG92ZXJs YXkgYW5kIGZvcndhcmQgdGhlIHBhY2tldAo+IGZvciBvdGhlciBwZWVycy4gVGhlc2Ugd29ya3Mg d2lsbCBhY2NvdW50IGZvciBwYXJ0IG9mIHJlc291cmNlIHRoZXkgaGF2ZS4KPiBNb3Jlb3Zlciwg aWYgdGhlc2Ugbm9kZXMgcGxheSBQZWVyIHJvbGUgaW4gYWRkaXRpb24gdG8gc2VydmljZSBwcm92 aWRlciwgaXQKPiBtYXkgYmUgdW5kZXIgdGhlIHRocmVhdHMgd2hpY2ggY29tZXMgZnJvbSBpdHMg cGVlciByb2xlLiAgU28gZnJvbSB0aGUKPiBzdGFiaWxpdHkgb2YgdGhlIHByb3ZpZGVkIHNlcnZp Y2UsIHRoZSBiZXN0IHJvbGUgdGhleSBwbGF5IG1heSBiZSBjbGllbnRzLAo+IG5vdCBwZWVyLCBl dmVuIHRoZXkgaGF2ZSBzdHJvbmcgcHJvY2Vzc2luZyBwb3dlciwgaGlnaCBiYW5kd2lkdGgsIG9u IHRoZQo+IHB1YmxpYyBJbnRlcm5ldCwgZXRjLgoKSSBmdWxseSBhZ3JlZS4KUGVlcnMgKG92ZXJs YXkpIHdvdWxkIGJlIHVzZWQgdG8gbG9jYXRlIHNlcnZpY2VzIGFuZCBDbGllbnRzIHdvdWxkCmlt cGxlbWVudCB0aGVzZSBzZXJ2aWNlcy4gVGh1cywgbmV3IHNlcnZpY2VzIGludHJvZHVjdGlvbiB3 b3VsZCBiZQplYXNpZXIsIHNjYWxhYmxlIGFuZCB3ZSBzaG91bGQgbm90IG1vZGlmeSB0aGUgb3Zl cmxheSBldmVyeSB0aW1lIGEgbmV3CnNlcnZpY2UgaXMgaW50cm9kdWNlZC4KVXNpbmcgU2Vydmlj ZSBPcmllbnRlZCBBcmNoaXRlY3R1cmUgKFNPQSksIFBlZXJzIGNvdWxkIGJlIGNvbnNpZGVyZWQK YXMgJ1NlcnZpY2UgUHJvdmlkZXJzJyBhbmQgQ2xpZW50cyBhcyAnU2VydmljZSBpbXBsZW1lbnRv cnMnLgoKVGhhbmtzLAotLSAKVmljdG9yIFBhc2N1YWwgw4F2aWxhCg== --===============1731256532== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1731256532==-- From p2psip-bounces@ietf.org Tue Nov 20 05:29:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQM0-0007g4-3c; Tue, 20 Nov 2007 05:29:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQLy-0007fy-N1 for p2psip@ietf.org; Tue, 20 Nov 2007 05:29:14 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuQLy-0005jF-6x for p2psip@ietf.org; Tue, 20 Nov 2007 05:29:14 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRS00BHWVQG0S@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 18:27:52 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRS00KN9VQFLN@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 18:27:52 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRS00C2JVQFTA@szxml04-in.huawei.com> for p2psip@ietf.org; Tue, 20 Nov 2007 18:27:51 +0800 (CST) Date: Tue, 20 Nov 2007 18:27:51 +0800 From: JiangXingFeng To: 'P2PSIP Mailing List' Message-id: <008201c82b60$012054d0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgrYACtIgJTQM7aSyiWqpJpnH7jaQ== X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [P2PSIP] Routing mode in P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, There are four routing mode described in the draft-bryan-p2psip-reload-01. After reading P2PP and RELOAD revision 2, only the iterative routing mode and recursive mode are supported. Why doesn't P2PSIP peer protocol support semi-recursive mode? IMHO, semi-recursive mode at least has two following advantages over other routing mode: 1. Semi-recursive mode is more resilient from failures of intermediate peers than recursive mode. In recursive mode, if any of the intermediate peers fails, the response could not return back in the reverse path the request has traversed. 2. Semi-recursive mode has lower latency than recursive and iterative mode. The response in semi-recursive mode could go back to the request originator by forwarding based on its transport address. IMHO, the major issue that semi-recursive mode should face is how the response goes to the request originator if the request originator is behind NAT. I think there must be solution to this issue. Comments? -- Jiang XingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 06:29:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRHu-0003Ml-PP; Tue, 20 Nov 2007 06:29:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRHs-0003MI-PK for p2psip@ietf.org; Tue, 20 Nov 2007 06:29:04 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuRHp-00078R-Dk for p2psip@ietf.org; Tue, 20 Nov 2007 06:29:04 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1527999rvb for ; Tue, 20 Nov 2007 03:29:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=SnTKSw25ZMQLljveU07DJvVm2puZL6WImCX7xEZ36vs=; b=On3+f38Bq5lZ1pRixZ0aZSw9z3WNbyPbhjfiLEltcAMLnCqkPlxD73X6weB9RKIRUn2BsQxKeQUiNPzATn8pC6Z28lq0D36adfxYPNBV9/DxnvzuWDeysSagUVUjwr3c5FNaDTEd3AorHhNliD66d1+9m/ZwiJiycz4VZTSCmFg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ipZJPoHsyYjULhhuLjUsJ7rKBQSXJ3Bzm5RfGLGr214Jh+Hy4G8z22OEdchqgQUoWSnlxEU1yhCv0MQmyxN97U2PoGr7AXLW0m2exB7ykr2iksum7a0++TvuXsaZrMJE2WsZobAIFEhDa57avdfoF6Z2oRKQeZqKm4lpnxOCCEY= Received: by 10.141.197.8 with SMTP id z8mr2619802rvp.1195558140769; Tue, 20 Nov 2007 03:29:00 -0800 (PST) Received: by 10.141.177.20 with HTTP; Tue, 20 Nov 2007 03:29:00 -0800 (PST) Message-ID: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com> Date: Tue, 20 Nov 2007 06:29:00 -0500 From: "Eunsoo Shim" To: "=?ISO-8859-1?Q?Victor_Pascual_=C1vila?=" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <618e24240711200025t54df902aibe4321f9da6341ed@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> <007001c82b1d$73bcd420$6905a40a@china.huawei.com> <618e24240711200025t54df902aibe4321f9da6341ed@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 20, 2007 3:25 AM, Victor Pascual =C1vila wrote: > On 20/11/2007, JiangXingFeng wrote: > > In some cases, there are some nodes providing services which are useful= to > > the overlay, for example, STUN, TURN service, etc. If these nodes are p= ut > > into the overlay as a peer, it should participate in the overlay mainte= nance > > work, store pair on behalf the overlay and forward the pac= ket > > for other peers. These works will account for part of resource they hav= e. > > Moreover, if these nodes play Peer role in addition to service provider= , it > > may be under the threats which comes from its peer role. So from the > > stability of the provided service, the best role they play may be clien= ts, > > not peer, even they have strong processing power, high bandwidth, on th= e > > public Internet, etc. > > I fully agree. > Peers (overlay) would be used to locate services and Clients would > implement these services. This is too general a statement. It is true that a Client may implement/provide a service. But same for a Peer. Whether a node becomes a Peer or a Client is independent of whether it provides a particular service other than routing of overlay messages and maintaining the overlay. Thus, new services introduction would be > easier, scalable and we should not modify the overlay every time a new > service is introduced. > Using Service Oriented Architecture (SOA), Peers could be considered > as 'Service Providers' and Clients as 'Service implementors'. > Thanks. Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 06:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRLT-0008Bl-80; Tue, 20 Nov 2007 06:32:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRLR-00083H-9Z for p2psip@ietf.org; Tue, 20 Nov 2007 06:32:45 -0500 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuRLO-0007DY-Ps for p2psip@ietf.org; Tue, 20 Nov 2007 06:32:45 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1528694rvb for ; Tue, 20 Nov 2007 03:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=yf+fZteVtOnzOb6HXzePrwmCvf5gZknjkB1U7DzuQe4=; b=QMKRD1shp/rPT2412AuMjPF/wkcu73mRhQvbAJRDPCYevQPiA7dIG9d1iDXQ2iW7+xgov/1Zsmhq2vxRzbcWmS34LSLTC8gO4TDiHFE9YKRyhPPf056my59KIH5zIARcGfHEOSfGPjm+9h73yRBZ7gycozYuNttUsVkfuaaN5fY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=lJT3VJOK2uIL8V51qRXpwipgDicqFGdiT+Y6RG/Ikf32HbWMHqSxyqAJuN2MSFUNRSAfQBr6WZrs0U1HL4FF6BJcVv5sKnWbud8AzDE81kwVR/TwywslLCc5AEdtK1N1RH4Np5kyA7w5rJlY4XJJ6vTPfNiFxmTzpkzpWnr10Jg= Received: by 10.140.225.19 with SMTP id x19mr780679rvg.1195558362265; Tue, 20 Nov 2007 03:32:42 -0800 (PST) Received: by 10.141.177.20 with HTTP; Tue, 20 Nov 2007 03:32:42 -0800 (PST) Message-ID: <7b683f3f0711200332y6352dec6oe192000b3a257b0f@mail.gmail.com> Date: Tue, 20 Nov 2007 06:32:42 -0500 From: "Eunsoo Shim" To: "Zheng Hewen" Subject: Re: [P2PSIP] RE: [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <035301c82b39$cb90bdd0$5105a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <83E64480-F040-4913-8CD1-845A1EB96282@cisco.com> <035301c82b39$cb90bdd0$5105a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 20, 2007 12:54 AM, Zheng Hewen wrote: > Hi, > > Please see inline ... ... > > Best regards, > Hewen > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: 2007?11?20? 13:12 > > To: Zheng Hewen > > Cc: P2PSIP Mailing List > > > Subject: Re: [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > > > > On Nov 19, 2007, at 6:18 PM, Zheng Hewen wrote: > > > > > But here is one issue about the merged RELOAD-01, if > > P2PSIP clients > > > own Peer-ID, will this violate DHT algorithm when P2PSIP > > clients never > > > are used to store any DHT data? Will the namespace of > > P2PSIP overlay > > > not be fully available for peers? > > > Personally, I do not think that it will impact the other P2PSIP > > > clients application scenarios, but I wonder the answers for those > > > above questions. Certainly, if P2PSIP clients use the other > > namespace > > > than P2PSIP peers, then all is OK. > > > > Let's say some peer-id, X is being used by a client. From the > > perspective of the the peers for routing and storage, this is > > the same as if X had been allocated to some peer but that > > peer was not currently online. The client never does a join > > to insert X into the DHT topology. The whole space of > > resource-id is still available for use by the DHT. The > > advantage of this design is that unifies the authorization > > model for clients and peer. > > > > [Hewen] In my understanding to your description above, the "Peer-IDs" of P2PSIP clients never emerge in DHT topology of > P2PSIP overlay network, the design of RELOAD-01 only use them to identify clients and reuse the authorization model which > already is used in enrollment or peers' joining procedure. Further, the "Peer-IDs" above are in fact some type of > identifiers of P2PSIP clients, some peers in P2PSIP overlay network can use "Peer-IDs" which have the same value with > "Peer-IDs" owned by P2PSIP clients because those "Peer-IDs" of P2PSIP clients never appear in the overlay network (i.e., > Node-IDs never conflict due to repeat). In summary, essentially, the "Peer-IDs" of P2PSIP clients sit in the completely > different and separate namespace with "Peer-IDs" of P2PSIP peers, is my understanding correct? > > > I don't know the intention of the RELOAD draft authors. But I have been thinking that a Client gets a Node ID as a Peer does. In my picture, there is no difference between the Node ID assigned to a Peer and Node ID assigned to a Client. You have only one Node ID space. If an ID is taken, the ID is used. The ID won't be assigned (should not be assigned) to any node regardless of the node type. Thanks. -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 07:09:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRv5-0005gS-LP; Tue, 20 Nov 2007 07:09:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRv3-0005gI-Sf for p2psip@ietf.org; Tue, 20 Nov 2007 07:09:33 -0500 Received: from nz-out-0506.google.com ([64.233.162.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuRuz-0008D8-8z for p2psip@ietf.org; Tue, 20 Nov 2007 07:09:33 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1531152nzf for ; Tue, 20 Nov 2007 04:09:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=XxOPOcksnHh/3+XU2kBHiD4y1sJgJLdxx53vqWFwmcA=; b=X6OTiGZk/Yi77dA1Q0eh/c1aR3dAy5Mkr3ipeLvQBGOOO91yZpURjlK+V0sIG3JnuD5x85XPCDYjjdY89XDZUWVK0qwqZGZeuexGB1LFZckAwNbWl2RKz1z1yubG2PVVKvSN32lAneB6BcqO3eVIoDfzAXXx93ISUTOqtchJQuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=p8+l0uuZ8Or7tA1zrv5hKXN0WaG5vJEOiFDx8qsDrGKn+ZTqaFBDGu88BQqPfgB9RWHqatIGbyltRC9+JZkluAnOk+nQg7v715+eMbIltSKSAOq7jLRIe8ArPLNQ7YZbDK5hsvruB+aUPVljKfnent8QRgFk2MbQTHyNE6EciS4= Received: by 10.142.255.14 with SMTP id c14mr1425997wfi.1195560568028; Tue, 20 Nov 2007 04:09:28 -0800 (PST) Received: by 10.142.132.18 with HTTP; Tue, 20 Nov 2007 04:09:27 -0800 (PST) Message-ID: <20d2bdfb0711200409v379fdae1s8a7209bc131db5c7@mail.gmail.com> Date: Tue, 20 Nov 2007 07:09:27 -0500 From: "Bruce Lowekamp" To: JiangXingFeng Subject: Re: [P2PSIP] Routing mode in P2PSIP In-Reply-To: <008201c82b60$012054d0$6905a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <008201c82b60$012054d0$6905a40a@china.huawei.com> X-Google-Sender-Auth: e0a56aa8ad99b370 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 11/20/07, JiangXingFeng wrote: > Hi, > > There are four routing mode described in the draft-bryan-p2psip-reload-01. > After reading P2PP and RELOAD revision 2, only the iterative routing mode > and recursive mode are supported. > > Why doesn't P2PSIP peer protocol support semi-recursive mode? IMHO, > semi-recursive mode at least has two following advantages over other routing > mode: > 1. Semi-recursive mode is more resilient from failures of intermediate peers > than recursive mode. In recursive mode, if any of the intermediate peers > fails, the response could not return back in the reverse path the request > has traversed. > 2. Semi-recursive mode has lower latency than recursive and iterative mode. > The response in semi-recursive mode could go back to the request originator > by forwarding based on its transport address. These two statements are both true if the requesting peer is not behind a NAT or a firewall. The reload-01 protocol embedded a "default" IP addr that could be contacted directly and then specified how to make things work if the default wasn't accessible (NAT or firewall problem). The problem with that approach is that it takes a lot longer when the default doesn't work, because you have to let it timeout before you realize it won't work. > > IMHO, the major issue that semi-recursive mode should face is how the > response goes to the request originator if the request originator is behind > NAT. I think there must be solution to this issue. Yes, the solution is to use recursive routing. If somehow a peer can learn that an incoming response won't be blocked (it knows it has no NAT or firewall, or the NAT or firewall does address independent mapping and filtering) then semi-recursive would work. Maybe it's worth extending the protocol to support that, but it isn't clear it would work and would complicate the protocol tremendously. (Minimally, it adds state at the responder to notice that its response must have been lost and to route it recursively instead.) Having the responder do ICE to open a direct connection for the response isn't really feasible because ICE would take longer than the recursive response. There is another optimization to allow the two peers to open a direct connection with ICE if they're going to be sending a lot of messages back and forth. That's the one I would pick to improve performance of message routing. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 07:14:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRzS-00051a-0G; Tue, 20 Nov 2007 07:14:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRzR-00051V-1m for p2psip@ietf.org; Tue, 20 Nov 2007 07:14:05 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuRzM-0008Ie-BK for p2psip@ietf.org; Tue, 20 Nov 2007 07:14:05 -0500 Received: by ug-out-1314.google.com with SMTP id u2so3637774uge for ; Tue, 20 Nov 2007 04:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=DRPQ1mqOB+1CKWV3+JWWjR4Wvs1zdsHZKcrTXXbVzd8=; b=ajPqqIMiJcOUgX11zp+MGHudxz9IEymdcQZJACbhfZ3QDiZtdFb5q5IY3kUVKRTnglzJYzsFllfslsUwx2VjNOHVhcknCTaeHENT+YVaNmZ5HoDUP2SR0ebOdYacJgp6Q+Sl8755r3Os/KSFEn1+1Xff+OFxcHFVwmQ2DjHRa74= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JK+wlY1VxsAFCDmu5ZK3a0hLaSWcAWUAz6rY1bSTLrOdmuu+fv5Lbt7579I++Qe3l8/79oyFMAX6XSyeCVTfawj8QEQt/Hj0YkXFKrvpS7J3l/geGoZP3XQ2Q3ctirZJAvMUokRn40VMWtPqct2ngLZVk9o0fi1Qh6l5XL5jCu8= Received: by 10.66.233.14 with SMTP id f14mr497830ugh.1195560839546; Tue, 20 Nov 2007 04:13:59 -0800 (PST) Received: by 10.66.252.5 with HTTP; Tue, 20 Nov 2007 04:13:59 -0800 (PST) Message-ID: <618e24240711200413h567036a9pcb017585a8aaac62@mail.gmail.com> Date: Tue, 20 Nov 2007 13:13:59 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: "Eunsoo Shim" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com> MIME-Version: 1.0 References: <0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> <007001c82b1d$73bcd420$6905a40a@china.huawei.com> <618e24240711200025t54df902aibe4321f9da6341ed@mail.gmail.com> <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1865838640==" Errors-To: p2psip-bounces@ietf.org --===============1865838640== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline T24gMjAvMTEvMjAwNywgRXVuc29vIFNoaW0gPGV1bnNvb3NoaW1AZ21haWwuY29tPiB3cm90ZToK PiBPbiBOb3YgMjAsIDIwMDcgMzoyNSBBTSwgVmljdG9yIFBhc2N1YWwgw4F2aWxhCj4gPHZpY3Rv ci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNvbT4gd3JvdGU6Cj4gPiBPbiAyMC8xMS8yMDA3LCBKaWFu Z1hpbmdGZW5nIDxqaWFuZy54LmZAaHVhd2VpLmNvbT4gd3JvdGU6Cj4gPiA+IEluIHNvbWUgY2Fz ZXMsIHRoZXJlIGFyZSBzb21lIG5vZGVzIHByb3ZpZGluZyBzZXJ2aWNlcyB3aGljaCBhcmUgdXNl ZnVsIHRvCj4gPiA+IHRoZSBvdmVybGF5LCBmb3IgZXhhbXBsZSwgU1RVTiwgVFVSTiBzZXJ2aWNl LCBldGMuIElmIHRoZXNlIG5vZGVzIGFyZSBwdXQKPiA+ID4gaW50byB0aGUgb3ZlcmxheSBhcyBh IHBlZXIsIGl0IHNob3VsZCBwYXJ0aWNpcGF0ZSBpbiB0aGUgb3ZlcmxheSBtYWludGVuYW5jZQo+ ID4gPiB3b3JrLCBzdG9yZSA8a2V5LCB2YWx1ZT4gcGFpciBvbiBiZWhhbGYgdGhlIG92ZXJsYXkg YW5kIGZvcndhcmQgdGhlIHBhY2tldAo+ID4gPiBmb3Igb3RoZXIgcGVlcnMuIFRoZXNlIHdvcmtz IHdpbGwgYWNjb3VudCBmb3IgcGFydCBvZiByZXNvdXJjZSB0aGV5IGhhdmUuCj4gPiA+IE1vcmVv dmVyLCBpZiB0aGVzZSBub2RlcyBwbGF5IFBlZXIgcm9sZSBpbiBhZGRpdGlvbiB0byBzZXJ2aWNl IHByb3ZpZGVyLCBpdAo+ID4gPiBtYXkgYmUgdW5kZXIgdGhlIHRocmVhdHMgd2hpY2ggY29tZXMg ZnJvbSBpdHMgcGVlciByb2xlLiAgU28gZnJvbSB0aGUKPiA+ID4gc3RhYmlsaXR5IG9mIHRoZSBw cm92aWRlZCBzZXJ2aWNlLCB0aGUgYmVzdCByb2xlIHRoZXkgcGxheSBtYXkgYmUgY2xpZW50cywK PiA+ID4gbm90IHBlZXIsIGV2ZW4gdGhleSBoYXZlIHN0cm9uZyBwcm9jZXNzaW5nIHBvd2VyLCBo aWdoIGJhbmR3aWR0aCwgb24gdGhlCj4gPiA+IHB1YmxpYyBJbnRlcm5ldCwgZXRjLgo+ID4KPiA+ IEkgZnVsbHkgYWdyZWUuCj4gPiBQZWVycyAob3ZlcmxheSkgd291bGQgYmUgdXNlZCB0byBsb2Nh dGUgc2VydmljZXMgYW5kIENsaWVudHMgd291bGQKPiA+IGltcGxlbWVudCB0aGVzZSBzZXJ2aWNl cy4KPgo+IFRoaXMgaXMgdG9vIGdlbmVyYWwgYSBzdGF0ZW1lbnQuCj4gSXQgaXMgdHJ1ZSB0aGF0 IGEgQ2xpZW50IG1heSBpbXBsZW1lbnQvcHJvdmlkZSBhIHNlcnZpY2UuCj4gQnV0IHNhbWUgZm9y IGEgUGVlci4KPiBXaGV0aGVyIGEgbm9kZSBiZWNvbWVzIGEgUGVlciBvciBhIENsaWVudCBpcyBp bmRlcGVuZGVudCBvZiB3aGV0aGVyIGl0Cj4gcHJvdmlkZXMgYSBwYXJ0aWN1bGFyIHNlcnZpY2Ug b3RoZXIgdGhhbiByb3V0aW5nIG9mIG92ZXJsYXkgbWVzc2FnZXMKPiBhbmQgbWFpbnRhaW5pbmcg dGhlIG92ZXJsYXkuCgpbdnBdIFRoZW4sIGNsaWVudHMgYXJlIG5vbi1vdmVybGF5LXJvdXRpbmcg bm9kZXMgYW5kIGF0IHRoZSBzYW1lIHRpbWUKdGhleSBjb250cmlidXRlIHRoZWlyIHN0b3JhZ2Ug Y2FwYWNpdHkgX2FuZC9vcl8gdGhlaXIgLXNwZWNpYWxpemVkCnJlc291cmNlIGNvbnN1bWluZy0g c2VydmljZXMgKGUuZyBtaXhpbmcgc2VydmVyKSB0byBQMlBTSVAgb3ZlcmxheQpuZXR3b3JrLgoK VGhhbmsgeW91LAotLSAKVmljdG9yIFBhc2N1YWwgw4F2aWxhCg== --===============1865838640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1865838640==-- From p2psip-bounces@ietf.org Tue Nov 20 08:34:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTEw-0002sF-5p; Tue, 20 Nov 2007 08:34:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTEv-0002s5-1t for p2psip@lists.ietf.org; Tue, 20 Nov 2007 08:34:09 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuTEs-00022J-Dr for p2psip@lists.ietf.org; Tue, 20 Nov 2007 08:34:09 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BFDDE2800034D; Tue, 20 Nov 2007 14:34:05 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NW+c8528z05f; Tue, 20 Nov 2007 14:34:05 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9C9E228000340; Tue, 20 Nov 2007 14:33:55 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Identity vs Identifier X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 20 Nov 2007 14:33:54 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD6960193D928@mx1.office> In-Reply-To: <473DC47C.5030003@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Identity vs Identifier Thread-Index: AcgobVhvHVZK9CpERZuhhQg6PE9ChwDCXqaw References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> From: "Jan Seedorf" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Ruben, > Let me explain my idea with an example. > If my user-name is Ruben.Cuevas, I (likely) will store in the=20 > DHT as resource-id the hash(Ruben.Cuevas), lets say this=20 > resource-id is X. If we consider the use of a DHT system, the=20 > Responsible Node for X will be the Peer with the closest=20 > Peer-ID to X. Then, if I want to be the Responsible Node for=20 > X, I have to obtain the closest Peer-ID. Thus, I can ask to=20 > the Central Entity (in case of use a Central Entity scheme)=20 > for the closest Peer-ID to the resource-key associated to=20 > Ruben.Cuevas. =20 > I can demonstrate I am Ruben.Cuevas (by a passwd or other=20 > credentials) and the Peer-ID would be assigned. It could be=20 > for instance X+1. Then I becomes the Responsible Node for my=20 > own resource-id. > If all the users has to do the same and demonstrate their=20 > credentials, all the users obtain Peer-IDs close to their own=20 > resource-ids and anyone could obtain Peer-IDs with the=20 > intention to starve other resources. I see a couple of problems with what you propose above: - first, if the user can choose its user-ID (the identity), in your = proposal the user could indirectly choose the location of the node-ID = (the identifier). As discussed on this list, chosen-location attacks are = a threat that needs to be avoided (as much as possible). I see the = problem that an attacker could generate an "identity" specifically to = target (e.g., cut off) some other "identity" in the network. In your = example, assuming that Chord is used as the DHT, I would need to = generate an identity Y such that hash(Y) would be smaller but very close = to hash(Ruben.Cuevas) to be able to deny any request for the resource = object (transport address) stored for your identity in the DHT. - second, your scheme assumes that there is an equal number of peers = (identifiers) and users (identities). This may or may not be the case. = If not, the question arises where to store my second identity if I only = have one peer? - Jan > -----Original Message----- > From: Rub=E9n Cuevas Rum=EDn [mailto:rcuevas@it.uc3m.es]=20 > Sent: Friday, November 16, 2007 5:26 PM > To: David A. Bryan > Cc: p2psip@lists.ietf.org > Subject: Re: [P2PSIP] Identity vs Identifier >=20 > David A. Bryan escribi=F3: > > Comments inline: > > > > =20 > >> If you have several UA associated to the same user. If I=20 > am right, it=20 > >> is pretty likely that all of them are going to use the service=20 > >> offered by the p2psip overlay which are defined in the concepts=20 > >> draft. And we should solve this problem, how several devices (i.e.=20 > >> UA) associated to the same user are going to=20 > participate/use the p2psip system. > >> The easiest way is that all of them becomes peers inside=20 > the p2psip=20 > >> system. But maybe ithis is not the best solution. I just=20 > proposed the=20 > >> possibility of use one of them as Peer and let the others=20 > be Clients. > >> This is not new, the new part is that I propose the Peer allowing=20 > >> the rest to access to the p2psip system is not a third one=20 > but this=20 > >> associated to the same user. > >> =20 > > > > I think this is not the right way to layer here -- we are mixing an=20 > > application level issue (is more than one UA associated=20 > with a user)=20 > > with a routing level issue (is this a peer or client). The=20 > two should=20 > > be independent. Personally, I think as many things as=20 > possible should=20 > > be peers, and if all the devices you are associated with=20 > can be peers,=20 > > they all should act as so, rather than being clients. > > > > There is another problem with the approach of a user with multiple=20 > > devices having one as a peer and the rest as clients. The=20 > only reasons=20 > > that I have seen presented for why a device should be a=20 > client rather=20 > > than a peer in the first place are either the device is=20 > behind a NAT=20 > > and cannot be a good peer, or has some limitation=20 > (processor, battery=20 > > life, etc.) that would motivate being a client instead. Making the=20 > > assumption that one is a peer and the rest clients assumes that the=20 > > device becoming a peer is reachable by all the devices. In=20 > a LAN this=20 > > may be true, but I might have 3 UAs, one at home, one at=20 > the office,=20 > > and one a mobile device. All may be on separate networks.=20 > Letting each=20 > > determine if it has adequate connectivity and resources to=20 > be a peer=20 > > makes better sense than imposing an application level=20 > decision, in my=20 > > mind. > > > > =20 > I agree in almost everything. > As you said limited deviced are the candidates to not be a=20 > Peer. Then, imagine a simple scenario with two devices=20 > associated to the same user name, a non-limited device, e.g.=20 > a desktop, and a limited device, e.g. a mobile phone. Then,=20 > we can identify the desktop as a potential peer and the=20 > mobile phone as a potential client. Lets analyze the different > situations: > 1- The desktop is reachable (i.e. not firewalled or behind a=20 > NAT). It registers in the p2psystem and becomes a Peer. After=20 > that, the mobile phone registers on the p2psystems. Since=20 > this is a limited device it needs to lookfor a peer to conect=20 > with. Then, it can randonmly selects a Peer with the adequate=20 > properties (i.e. globally reachable). However, why not try=20 > first to select a trustable one? I mean, the mobile phone can=20 > launches a search for the resource-id associated to its=20 > user-name, and then, it would discover that there is a Peer=20 > associated to this user name already registered and which is=20 > reachable. Then it would select this one. >=20 > 2- The desktop is behind a NAT. Then, the mobile phone could=20 > choose between connect to this (fully trustable) peer by=20 > using some NAT-Traversal strategy or connects to one offering=20 > global reachabilty but in principle, not trustable. >=20 > 3- If it is the mobile phone who registers firstly, then it=20 > obviously would choose one globally reachable Peer. And maybe=20 > can develop some periodic discovery mechanism in order to=20 > discover if the trustable Peer (that is, the desktop on the=20 > example) appears at some point. >=20 > Well, it is just an idea. Why not use trustable Peers if we=20 > can do it?. >=20 > >> On the other hand, IMO an important problem in the p2psip=20 > overlay is=20 > >> that my "resource-ID" (or "resource-IDs") is going to be stored by=20 > >> someone I don't know and (with the solution defined so=20 > far) I cannot=20 > >> trust in. This introduce trust and security threads. It=20 > would be nice=20 > >> to define a new mechanism which allows the users to store its own=20 > >> "resource-IDs". It is something I am thinking about and I=20 > have some=20 > >> ideas if you are interested. > >> =20 > > > > It would be interesting to hear what you had in mind. In proposals=20 > > like this people have made here and elsewhere over the last=20 > few years,=20 > > there are numerous problems that arise when each user becomes=20 > > responsible for their own resources as well. How do you handle=20 > > replication? How would you maintain information when the user is=20 > > offline? A meta question would be how clients would work in this=20 > > scenario, since they are, by definition, not directly accessible. > > Personally, I think distributed storage, with replication and=20 > > encrypted, signed resources is the best idea, but I would be=20 > > interested to hear what you have in mind. > > > > David (as individual) > > > > =20 > Let me explain my idea with an example. > If my user-name is Ruben.Cuevas, I (likely) will store in the=20 > DHT as resource-id the hash(Ruben.Cuevas), lets say this=20 > resource-id is X. If we consider the use of a DHT system, the=20 > Responsible Node for X will be the Peer with the closest=20 > Peer-ID to X. Then, if I want to be the Responsible Node for=20 > X, I have to obtain the closest Peer-ID. Thus, I can ask to=20 > the Central Entity (in case of use a Central Entity scheme)=20 > for the closest Peer-ID to the resource-key associated to=20 > Ruben.Cuevas. =20 > I can demonstrate I am Ruben.Cuevas (by a passwd or other=20 > credentials) and the Peer-ID would be assigned. It could be=20 > for instance X+1. Then I becomes the Responsible Node for my=20 > own resource-id. > If all the users has to do the same and demonstrate their=20 > credentials, all the users obtain Peer-IDs close to their own=20 > resource-ids and anyone could obtain Peer-IDs with the=20 > intention to starve other resources. >=20 > As you said we have to deal with seveal issues: >=20 > Replication. You can still keep the same replication scheme=20 > than in the regular DHT schemes: the N closest Peer-IDs.=20 > However, in this case it is easier to identify the good or=20 > bad behaviour of my neighbourgs since I am the one which does=20 > this task. Even more, your neighbourg should be careful in=20 > make something wrong with your resource-id, since you also=20 > have stored his resource-id, then you can also make the same=20 > wrong thing. >=20 > I am off-line. Again the same. The same scheme which you use=20 > in the regular DHT schemes can be applied here. If in regular=20 > DHT your info is kept alive on the replicas, here you can do the same. >=20 > Clients: You have also the same problem as in regular DHTs.=20 > This scheme does not modifies anything regarding to the clients. >=20 > I have not yet going into the detail of this idea, and maybe=20 > it has several problems I have not yet identified. Then, it=20 > is really interesing to hear from you. >=20 > Cheers, > Rub=E9n. >=20 > >> Rub=E9n. > >> > >> -- > >> Rub=E9n Cuevas Rum=EDn > >> Universidad Carlos III de Madrid > >> Departamento Ingenier=EDa Telem=E1tica > >> Avenida de la Universidad, 30 > >> 28911-Legan=E9s (Madrid). Espa=F1a > >> email: rcuevas@it.uc3m.es > >> Tlf: +34 91-6248859 > >> Fax: +34 91-6248749 > >> Web: http://www.it.uc3m.es/~rcuevas > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > >> =20 > > > > > > > > =20 >=20 >=20 > -- > Rub=E9n Cuevas Rum=EDn > Universidad Carlos III de Madrid > Departamento Ingenier=EDa Telem=E1tica > Avenida de la Universidad, 30 > 28911-Legan=E9s (Madrid). Espa=F1a > email: rcuevas@it.uc3m.es > Tlf: +34 91-6248859 > Fax: +34 91-6248749 > Web: http://www.it.uc3m.es/~rcuevas >=20 >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 08:35:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTFk-0003JA-2Q; Tue, 20 Nov 2007 08:35:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTFi-0003J0-O0 for p2psip@ietf.org; Tue, 20 Nov 2007 08:34:58 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuTFe-00023E-C0 for p2psip@ietf.org; Tue, 20 Nov 2007 08:34:58 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAKDYRsO008491; Tue, 20 Nov 2007 15:34:46 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 15:34:44 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 15:34:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) Date: Tue, 20 Nov 2007 15:37:21 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F056EA9D0@esebe102.NOE.Nokia.com> In-Reply-To: <7b683f3f0711140722n2329f686h9795183962682bac@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: client protocol ([P2PSIP] Proposal for progress on protocols) Thread-Index: Acgm0jXSBOuWKC3tTYei7m4Ci5o0SAEpL/pg References: <24CCCC428EFEA2469BF046DB3C7A8D223AE2A6@namail5.corp.adobe.com><004201c8266e$80ee0640$9a00a8c0@mlifewangyao> <7b683f3f0711140722n2329f686h9795183962682bac@mail.gmail.com> From: To: , X-OriginalArrivalTime: 20 Nov 2007 13:34:44.0731 (UTC) FILETIME=[1CAF3CB0:01C82B7A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: hsinnrei@adobe.com, p2psip@ietf.org, philip_matthews@magma.ca X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, I agree with Eunsoo. The client protocol must support PUT, GET, JOIN and Bootstrap methods. Clients do not need to store any data on behalf of other P2PSIP nodes (but they may decide otherwise). The client discovers services and users' location and publishes its own information in the overlay using a client protocol. When a SIP UA is collocated with a client software the client requests an IP address and port of callee and establishes a SIP session directly (or through a relay) to the other end. Client don't need to implement a SIP stack. It can be a node that advertises non-SIP services to the overlay e.g. media relaying services. Definitely the client protocol can be a subset of a peer protocol as it is shown in the P2PP draft. Marcin =20 >-----Original Message----- >From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com]=20 >Sent: 14 November, 2007 17:22 >To: Yao Wang >Cc: P2PSIP Mailing List; Henry Sinnreich; Philip Matthews >Subject: Re: client protocol ([P2PSIP] Proposal for progress=20 >on protocols) > >Not at all. >The overlay needs to provide just distributed database=20 >functionality (=3D=3D distributed storage and search/lookup=20 >functionality) and at most some kind of generic=20 >transport/routing functionality. These functionalities can be=20 >well summarized as PUT, GET, and SEND functions. > >Any information about SIP related services such as mapping of=20 >SIP URI to a location(IP address) or nodes providing certain=20 >application functions/services like conferencing server can be=20 >stored and looked up using the Peer (and Client) Protocol. You=20 >don't need SIP at all here. > >That is the idea accepted by the group widely. Now all the=20 >proposals about Peer Protocol do not use extensions/variations of SIP. > >If we all understand that Client Protocol provides only a=20 >subset of Peer Protocol's functionality and Peer Protocol can=20 >be and better be implemented independently of SIP, why would=20 >we need to have SIP for Client Protocol? It does not make sense to me. > >Thanks. > >Eunsoo > >On Nov 13, 2007 10:28 PM, Yao Wang wrote: >> Yes, you are right. >> >> Currently, the main difference in the debate comes from how=20 >to build the client protocol, whether it could be based on=20 >SIP, whether it could be a syntax subset of Peer Protocol, or=20 >whether it is a separate protocol different from both SIP and=20 >Peer Protocol but its function is subset of the functions of=20 >Peer Protocol. >> >> Here are some of my understandings, >> 1. What services client can get using Client Protocol? >> In my opinion, there are two kinds of services. >> Firstly, from the charter of this WG, this WG "is=20 >chartered to develop protocols and mechanisms for the use of=20 >the Session Initiation Protocol (SIP)". It is clearly that SIP=20 >service (including locating target user, forwarding SIP=20 >messages) is a basic service that P2PSIP Overlay MUST provide.=20 >Client Protocol MUST enable client to access this services. >> Secondly, services other than SIP. As mentioned in=20 >concept draft, some individual peers may provide services in=20 >addition to storage and routing, for example STUN services, to=20 >the overlay. However, because clients do not join P2PSIP=20 >Overlay, they can not discover these services directly.=20 >Therefore, client protocol MUST provide a mean for client to=20 >know what services are available in the P2PSIP Overlay and the=20 >comprehensive parameters for access these services. After=20 >getting these parameters, the client can use other protocols,=20 >for example STUN, to access the service, which should be out=20 >of the scope of client protocol. >> To meet the first kind of requirements, SIP is mandatory. > > > > When it comes to the second kind of requirements, both SIP=20 >and other protocol (e.g. a subset of peer protocol) can work. >> If the subset of peer protocol is adopted as client=20 >protocol (supposing the peer protocol is not SIP-based), the=20 >client _has_ _to_ run two protocol stacks at the same time,=20 >which obviously consumes more resources of client than only=20 >running SIP stack. Given the assumption that clients are=20 >resource-limited devices, running one more protocol stack may=20 >cause the degradation of its performances. >> Thus, why not use SIP and SIP extensions to satisfy=20 >both requirements? why not kill two birds with one stone? =20 >Currently, many mobile devices have been equipped with SIP;=20 >the reuse of SIP in client protocol not only reduces the=20 >resource needed on client devices but also reduces the=20 >implementation complexity of client protocol. >> >> 2. What services peer can get using Client Protocol? >> It seems that people in this list accept that the=20 >client should contribute its storage capacity to peers. In my=20 >opinion, the client can provide more service than that. Here=20 >is one possible example which is described in our proposed=20 >draft ("A SIP-based P2PSIP Client Protocol") >> "For example, a conferences server wants to provide=20 >conference services to nodes in a P2PSIP system. Because the=20 >decoding, mixture and encoding of multiple media streams can=20 >be quite a heavy load for its computational resources, this=20 >conference server may choose not to join in the P2PSIP=20 >overlay. Thus, some extra resources, which would be used=20 >for the maintenance of P2P overlay if the server joined=20 >overlay, can be utilized for providing better conference services." >> Therefore, the client protocol must be extensible=20 >for supporting any possible services. SIP is a well-developed=20 >extensible signal protocol, thus, we propose to build client=20 >protocol based on SIP. >> >> Any comments? >> >> >> Sincerely yours, >> >> Yao Wang >> Mobile Life and New Media Lab, BUPT >> >> -----Original Message----- >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, November 14, 2007 3:42 AM >> To: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu >> Cc: P2PSIP Mailing List >> >> Subject: client protocol ([P2PSIP] Proposal for progress on=20 >protocols) >> >> > I think there is no consensus >> > yet on the nature or even existence of clients. >> >> >From this list I understand there is less a problem with the=20 >> >existence >> of clients, but rather if there should be a separate client protocol. >> >> Also, some folks mentioned that the client protocol should just be a=20 >> subset of the peer protocol. >> >> Is this understanding of the discussions correct? >> >> Given the preponderance of mobile devices, this alone would=20 >justify a=20 >> new version of the concepts document. >> >> Henry >> >> -----Original Message----- >> From: Philip Matthews [mailto:philip_matthews@magma.ca] >> Sent: Tuesday, November 13, 2007 10:41 AM >> To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu >> Cc: P2PSIP Mailing List >> Subject: Re: [P2PSIP] Proposal for progress on protocols >> >> As a working group member, I am encouraged by the debate on the=20 >> existence and nature of the P2PSIP client, and the proposals for a=20 >> Client Protocol. >> >> But as a co-author of the Concepts draft, I think it is premature to=20 >> modify the discussion on Clients in the draft. It is not=20 >that I don't=20 >> want to do this, it is just that I think there is no=20 >consensus yet on=20 >> the nature or even existence of clients. >> >> I think we are coming up to the point where there will be a major=20 >> revision to the Concepts draft that will focus in on a specific=20 >> architecture and mechanisms, and that revision may well include a=20 >> major revision in the section on clients. But I don't think=20 >it should=20 >> be the revision for this cycle. >> >> - Philip >> >> >> >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > >-- >Eunsoo > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 08:57:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTbU-0005wD-IA; Tue, 20 Nov 2007 08:57:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTbT-0005f7-3q for p2psip@ietf.org; Tue, 20 Nov 2007 08:57:27 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuTbS-0003Jh-DV for p2psip@ietf.org; Tue, 20 Nov 2007 08:57:27 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAKDv7cZ014992; Tue, 20 Nov 2007 15:57:23 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 15:56:49 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 15:56:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Tue, 20 Nov 2007 15:59:26 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F056EA9FB@esebe102.NOE.Nokia.com> In-Reply-To: <9C8C25BD-E1C7-4940-9A42-5261CA150950@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Thread-Index: Acgnl5fwYLXFtyP+R/SybTr0G6ltTQD4z9AA References: <00e501c8272a$905b2060$5105a40a@china.huawei.com><7F42DC87-4271-4E9C-A11F-C91123B59D15@magma.ca><0aef01c8278a$b68ad0e0$ad600240@china.huawei.com> <9C8C25BD-E1C7-4940-9A42-5261CA150950@magma.ca> From: To: , X-OriginalArrivalTime: 20 Nov 2007 13:56:49.0903 (UTC) FILETIME=[328C6FF0:01C82B7D] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Philip and all, >Some people have said "Mobile devices (e.g., handsets) cannot=20 >be peers for battery reasons or storage reasons or ...". But=20 >these are just words in the corridor, and not written down.=20 >And I keep hearing others say "Nonsense, we CAN have mobile peers". Both are true. Everything depends on a deployment scenario. Some mobiles are quite static, some frequently change an access network, some mobiles are behind a firewall and nat others have a public IP, some users pay flat rate charges some don't, some mobiles are not enough powerful to become a peer but some have enough fast CPU, large memory, etc.. I am against writing a draft describing all of the possibilities, this group produced enough documents that none reads (but if it is required I can allocate some time to write such as a draft but I need a reason why do you need this) Do you think that we want to waste out time standardizing a client protocol that we think is useless? Marcin=20 =20 >-----Original Message----- >From: ext Philip Matthews [mailto:philip_matthews@magma.ca]=20 >Sent: 15 November, 2007 16:57 >To: P2PSIP Mailing List >Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > >On 15-Nov-07, at 08:23 , Spencer Dawkins wrote: > >> >> (HINT: the application scenarios draft includes analysis=20 >about whether=20 >> each scenario seems to require "P2P Client Support" and/or=20 >> "Interoperation with CS-SIP" - I don't think any of the=20 >draft authors=20 >> are prejudiced against clients, but none of us are strong=20 >advocates of=20 >> clients, so it would be good to have client advocates=20 >develop opinions=20 >> about whether that analysis is reasonable or not) > >I agree. Right now, I think that most of the most active=20 >participants in the group are in the "Show me the money" camp.=20 >That is, we are not opposed to them, but we want to see a good=20 >argument for them. > >Some people have said "Mobile devices (e.g., handsets) cannot=20 >be peers for battery reasons or storage reasons or ...". But=20 >these are just words in the corridor, and not written down.=20 >And I keep hearing others say "Nonsense, we CAN have mobile peers". > > > > > >> >>> From the Prague meeting minutes: >> >> P2PSIP Client Discussion, Spencer Dawkins >> >> What are Clients? Not garden variety SIP UACs, nor the=20 >equivalent of=20 >> "peers." >> >> Issue: Clients as storage nodes. No credible use case so far;=20 >> deferred. >> >> [ Discussion ensued at mic. >> >> Philip: Why do we need P2PSIP clients? The answer will=20 >drive whether=20 >> or not we use them. >> >> Brian Rosen (as individual): I don't understand P2PSIP clients. =20 >> We need >> to get rid of it and focus on normal SIP clients. >> >> Philip: Those that want P2PSIP Clients need to come up with a good=20 >> use case by Chicago IETF. If they do not come up by then,=20 >the P2PSIP=20 >> Clients go away. ] >> >> Hum - Should the wg work on the normal garden variety SIP UA=20 >connected=20 >> to >> the DHT via some box (a SIP proxy coupled to a peer)? >> >> [ Hum indicated yes. >> Those that want a P2PSIP Client distinct from a normal SIP client=20 >> need to get together and work on use cases. ] >> > >Yup. > >- Philip > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 08:57:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTbj-0006Q7-IL; Tue, 20 Nov 2007 08:57:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTbi-0006Pf-Da for p2psip@lists.ietf.org; Tue, 20 Nov 2007 08:57:42 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuTbf-0002kT-L4 for p2psip@lists.ietf.org; Tue, 20 Nov 2007 08:57:42 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 3617128000392; Tue, 20 Nov 2007 14:57:39 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cr3speeqmwyO; Tue, 20 Nov 2007 14:57:39 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 17D622800034D; Tue, 20 Nov 2007 14:57:29 +0100 (CET) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 20 Nov 2007 14:57:28 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 Thread-Index: Acgqa7LreOox92NcSa++GTwp9P1LkgBDmVGQ References: From: "Jan Seedorf" To: "Cullen Jennings" X-Spam-Score: 1.8 (+) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear authors of the new RELOAD draft (02), I have some comments on the security section: - In section 7.3. it is specified that the root-node of some resource ID = (i.e., the node responsible for storing the resource) is responsible for = replication. In section 10.5.4. "residual attacks" you mention that a = query node can check at replica roots for some resource if the root-node = does not respond. I see the following security problem: if the root-node = is originally faulty at storage time (e.g., compromised), it will likely = store invalid (though detectable) or no resources at all at the replica = roots. As you well describe the only issue here is availability. = However, I think that any countermeasure involving replication must = involve distributed storage done by the query node itself (for reasons = described above). Replication should not be the responsibility of the = root-node. - Section 10.6.1.: You assume a central authority and indeed this solves = many security problems. It limits Sybil attacks and Eclipse attacks. = This is well-described in the draft. However, there are other attacks on = DHT routing. Join-leave attacks can be used by the attacker to chose its = location in the DHT despite a central node-ID assignment authority (see = C. Scheideler, "How to Spread Adversarial Nodes?: Rotate!," Proc. 37th = Annual ACM Symp. Theory of Comp., Baltimore, MD,pp. 704-13, for a formal = analysis of the node-ID assignment problem in DHTs and join-leave = attacks). Additionally, even if there are no Sybil or Eclipse attacks, = adversary nodes (though well certified through the admission authority, = e.g., because they have been compromised) can simply drop messages. This = severely degrades the lookup success rate in a DHT. Countermeasures = against these attacks may well be out-of-scope for P2PSIP = standardisation, I just feel the section is misleading in the sense that = it suggests that a central authority protects against all threats on DHT = routing. - Jan > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Monday, November 19, 2007 6:17 AM > To: P2PSIP WG > Subject: [P2PSIP] Merge of ASP and RELOAD - Version=20 > Notification fordraft-bryan-p2psip-reload-02=20 >=20 >=20 > The various authors of ASP and RELOAD have managed to get=20 > these two proposal merged together into one and we are pretty=20 > happy with the result. >=20 > You can find it at > http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-02.txt >=20 >=20 > Begin forwarded message: >=20 > > From: IETF I-D Submission Tool > > Date: November 18, 2007 8:57:03 PM PST > > To: fluffy@cisco.com > > Cc: lowekamp@sipeerior.com, ekr@networkresonance.com,=20 > > jdrosen@cisco.com > > Subject: New Version Notification for draft-bryan-p2psip-reload-02 > > > > > > A new version of I-D, draft-bryan-p2psip-reload-02.txt has been=20 > > successfuly submitted by Cullen Jennings and posted to the IETF=20 > > repository. > > > > Filename: draft-bryan-p2psip-reload > > Revision: 02 > > Title: REsource LOcation And Discovery (RELOAD) > > Creation_date: 2007-11-18 > > WG ID: Independent Submission > > Number_of_pages: 96 > > > > Abstract: > > This document defines REsource LOcation And Discovery (RELOAD), a=20 > > peer-to-peer (P2P) binary signaling protocol for usage on the=20 > > Internet. A P2P signaling protocol provides its clients with an=20 > > abstract hash table service between a set of cooperating peers that=20 > > form the overlay network. RELOAD is designed to support a=20 > P2P Session=20 > > Initiation Protocol (P2PSIP) network, but it can be=20 > utilized by other=20 > > applications with similar requirements by defining new usages that=20 > > specify the data types that must be stored for a particular=20 > > application, such as location for SIP. RELOAD defines a security=20 > > model based on a certificate enrollment service that=20 > provides unique=20 > > identities. NAT traversal is a fundamental service of the protocol. > > > > This draft represents a concrete proposal for the P2PSIP Peer=20 > > Protocol. The protocol described here builds on the lessons and=20 > > experiences from designing and implementing the dSIP, ASP,=20 > and RELOAD=20 > > protocols and is a merge of features from RELOAD-01 and ASP. > > > > > > > > The IETF Secretariat. >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 10:07:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUhS-0007tf-07; Tue, 20 Nov 2007 10:07:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUhR-0007qh-2v for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:07:41 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuUhO-0004gD-4E for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:07:41 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRT00DQ98OPIN@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Tue, 20 Nov 2007 07:07:37 -0800 (PST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRT00DQR8ONEA@usaga01-in.huawei.com> for p2psip@lists.ietf.org; Tue, 20 Nov 2007 07:07:37 -0800 (PST) Date: Tue, 20 Nov 2007 09:07:25 -0600 From: Spencer Dawkins Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notificationfordraft-bryan-p2psip-reload-02 To: p2psip@lists.ietf.org Message-id: <0a0a01c82b87$0f3d15e0$6601a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> X-Spam-Score: 1.8 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I agree with Jan's first point below, and it's broader than RELOAD-02 - I don't see how replication works if the root node is responsible for all aspects of replication, and if the query node has to understand replication in order to locate replica roots, I'm not sure what problem is being solved by making the root node responsible for replication in the first place. Thanks, Spencer From: "Jan Seedorf" Dear authors of the new RELOAD draft (02), I have some comments on the security section: - In section 7.3. it is specified that the root-node of some resource ID (i.e., the node responsible for storing the resource) is responsible for replication. In section 10.5.4. "residual attacks" you mention that a query node can check at replica roots for some resource if the root-node does not respond. I see the following security problem: if the root-node is originally faulty at storage time (e.g., compromised), it will likely store invalid (though detectable) or no resources at all at the replica roots. As you well describe the only issue here is availability. However, I think that any countermeasure involving replication must involve distributed storage done by the query node itself (for reasons described above). Replication should not be the responsibility of the root-node. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 10:19:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUsO-0004Wy-DO; Tue, 20 Nov 2007 10:19:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUsN-0004Vo-0H for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:18:59 -0500 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuUsI-00052x-1m for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:18:58 -0500 Received: from [163.117.139.215] (unknown [163.117.139.215])by smtp.uc3m.es (Postfix) with ESMTP id 04CF62460DF; Tue, 20 Nov 2007 16:18:52 +0100 (CET) Message-ID: <4742FAE5.1040605@it.uc3m.es> Date: Tue, 20 Nov 2007 16:19:01 +0100 From: =?ISO-8859-1?Q?Rub=E9n_Cuevas_Rum=EDn?= Organization: =?iso-8859-1?Q?Departamento_I?= =?iso-8859-1?Q?ngenier=EDa_Telem=E1ti?= =?iso-8859-1?Q?ca=2E_Universidad_Ca?= =?iso-8859-1?Q?rlos_III_de_Madrid?= User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jan Seedorf Subject: Re: [P2PSIP] Identity vs Identifier References: <473C730E.1080004@it.uc3m.es> <618e24240711150935v6164ae0lf7bede7e06770c99@mail.gmail.com> <473D684A.1060502@it.uc3m.es> <4d4304a00711160658h53e725a9tf98018d86353a944@mail.gmail.com> <473DC47C.5030003@it.uc3m.es> <113091BD57179D4491C19DA7E10CD6960193D928@mx1.office> In-Reply-To: <113091BD57179D4491C19DA7E10CD6960193D928@mx1.office> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:B L:E SM:2 X-imss-tmaseResult: TT:1 TS:-24.1528 TC:02 TRN:93 TV:5.0.1023(15558.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Jan, thanks for your response. Some coments in line Jan Seedorf escribi=F3: > Dear Ruben, > > =20 >> Let me explain my idea with an example. >> If my user-name is Ruben.Cuevas, I (likely) will store in the=20 >> DHT as resource-id the hash(Ruben.Cuevas), lets say this=20 >> resource-id is X. If we consider the use of a DHT system, the=20 >> Responsible Node for X will be the Peer with the closest=20 >> Peer-ID to X. Then, if I want to be the Responsible Node for=20 >> X, I have to obtain the closest Peer-ID. Thus, I can ask to=20 >> the Central Entity (in case of use a Central Entity scheme)=20 >> for the closest Peer-ID to the resource-key associated to=20 >> Ruben.Cuevas. =20 >> I can demonstrate I am Ruben.Cuevas (by a passwd or other=20 >> credentials) and the Peer-ID would be assigned. It could be=20 >> for instance X+1. Then I becomes the Responsible Node for my=20 >> own resource-id. >> If all the users has to do the same and demonstrate their=20 >> credentials, all the users obtain Peer-IDs close to their own=20 >> resource-ids and anyone could obtain Peer-IDs with the=20 >> intention to starve other resources. >> =20 > > I see a couple of problems with what you propose above: > > - first, if the user can choose its user-ID (the identity), in your pro= posal the user could indirectly choose the location of the node-ID (the i= dentifier). As discussed on this list, chosen-location attacks are a thre= at that needs to be avoided (as much as possible). I see the problem that= an attacker could generate an "identity" specifically to target (e.g., c= ut off) some other "identity" in the network. In your example, assuming t= hat Chord is used as the DHT, I would need to generate an identity Y such= that hash(Y) would be smaller but very close to hash(Ruben.Cuevas) to be= able to deny any request for the resource object (transport address) sto= red for your identity in the DHT. > =20 You are right. In some scenarios the user-name can be freely selected. =20 However, how long takes the obtention of a user-id? This is the key=20 point. In other proposals we had to evaluate how long takes to get a=20 Peer-ID from a CA or how long takes to autogenarete a Peer-ID. IMHO, the=20 obtention of a user-id would consume more time than the other cases.=20 E.g. if we suppose some of the current registration processes where you=20 ask for a user name and you have to wait until receive some confirmation=20 in your email address and then confirmate the registration. I think,=20 this takes more time than obtaining a Peer-ID from a CA or=20 autogenerating a Peer-ID. If the time on the assignment of the User-ID is enough large (dozens of=20 seconds), since the attack cannot be automatized, I think we are=20 increasing the /security/ (the difficulty) of the attack. > - second, your scheme assumes that there is an equal number of peers (i= dentifiers) and users (identities). This may or may not be the case. If n= ot, the question arises where to store my second identity if I only have = one peer? > =20 Again you are right. As I said this is for the moment just an idea and I=20 have to go into more detail. For the moment, the only thing I observe=20 you can do is to register yourshelf as many peers as identities you=20 have. If the number of identites that you have is reduced (two or three)=20 this could be ok. However, if the number of identites you have is large=20 (100 or 1000) this solution is not valid. In addition, we can consider the possibility to have a Peer and some=20 clients to solve the problem. Another open issue is what happens if you only want to participate as a=20 Peer (identifier) but not as a Resource-ID (identity) in the p2psip=20 system. That is, if you only wants to look for information but not to be=20 reachable. For this cases, a possible solution is that those nodes which don't have=20 an associated user-id are not going to store Resource-IDs to avoid=20 security problems. > - Jan > =20 I would appreciate your (Jan and all the WG) comments about this idea. Thanks in advance. Rub=E9n. > =20 >> -----Original Message----- >> From: Rub=E9n Cuevas Rum=EDn [mailto:rcuevas@it.uc3m.es]=20 >> Sent: Friday, November 16, 2007 5:26 PM >> To: David A. Bryan >> Cc: p2psip@lists.ietf.org >> Subject: Re: [P2PSIP] Identity vs Identifier >> >> David A. Bryan escribi=F3: >> =20 >>> Comments inline: >>> >>> =20 >>> =20 >>>> If you have several UA associated to the same user. If I=20 >>>> =20 >> am right, it=20 >> =20 >>>> is pretty likely that all of them are going to use the service=20 >>>> offered by the p2psip overlay which are defined in the concepts=20 >>>> draft. And we should solve this problem, how several devices (i.e.=20 >>>> UA) associated to the same user are going to=20 >>>> =20 >> participate/use the p2psip system. >> =20 >>>> The easiest way is that all of them becomes peers inside=20 >>>> =20 >> the p2psip=20 >> =20 >>>> system. But maybe ithis is not the best solution. I just=20 >>>> =20 >> proposed the=20 >> =20 >>>> possibility of use one of them as Peer and let the others=20 >>>> =20 >> be Clients. >> =20 >>>> This is not new, the new part is that I propose the Peer allowing=20 >>>> the rest to access to the p2psip system is not a third one=20 >>>> =20 >> but this=20 >> =20 >>>> associated to the same user. >>>> =20 >>>> =20 >>> I think this is not the right way to layer here -- we are mixing an=20 >>> application level issue (is more than one UA associated=20 >>> =20 >> with a user)=20 >> =20 >>> with a routing level issue (is this a peer or client). The=20 >>> =20 >> two should=20 >> =20 >>> be independent. Personally, I think as many things as=20 >>> =20 >> possible should=20 >> =20 >>> be peers, and if all the devices you are associated with=20 >>> =20 >> can be peers,=20 >> =20 >>> they all should act as so, rather than being clients. >>> >>> There is another problem with the approach of a user with multiple=20 >>> devices having one as a peer and the rest as clients. The=20 >>> =20 >> only reasons=20 >> =20 >>> that I have seen presented for why a device should be a=20 >>> =20 >> client rather=20 >> =20 >>> than a peer in the first place are either the device is=20 >>> =20 >> behind a NAT=20 >> =20 >>> and cannot be a good peer, or has some limitation=20 >>> =20 >> (processor, battery=20 >> =20 >>> life, etc.) that would motivate being a client instead. Making the=20 >>> assumption that one is a peer and the rest clients assumes that the=20 >>> device becoming a peer is reachable by all the devices. In=20 >>> =20 >> a LAN this=20 >> =20 >>> may be true, but I might have 3 UAs, one at home, one at=20 >>> =20 >> the office,=20 >> =20 >>> and one a mobile device. All may be on separate networks.=20 >>> =20 >> Letting each=20 >> =20 >>> determine if it has adequate connectivity and resources to=20 >>> =20 >> be a peer=20 >> =20 >>> makes better sense than imposing an application level=20 >>> =20 >> decision, in my=20 >> =20 >>> mind. >>> >>> =20 >>> =20 >> I agree in almost everything. >> As you said limited deviced are the candidates to not be a=20 >> Peer. Then, imagine a simple scenario with two devices=20 >> associated to the same user name, a non-limited device, e.g.=20 >> a desktop, and a limited device, e.g. a mobile phone. Then,=20 >> we can identify the desktop as a potential peer and the=20 >> mobile phone as a potential client. Lets analyze the different >> situations: >> 1- The desktop is reachable (i.e. not firewalled or behind a=20 >> NAT). It registers in the p2psystem and becomes a Peer. After=20 >> that, the mobile phone registers on the p2psystems. Since=20 >> this is a limited device it needs to lookfor a peer to conect=20 >> with. Then, it can randonmly selects a Peer with the adequate=20 >> properties (i.e. globally reachable). However, why not try=20 >> first to select a trustable one? I mean, the mobile phone can=20 >> launches a search for the resource-id associated to its=20 >> user-name, and then, it would discover that there is a Peer=20 >> associated to this user name already registered and which is=20 >> reachable. Then it would select this one. >> >> 2- The desktop is behind a NAT. Then, the mobile phone could=20 >> choose between connect to this (fully trustable) peer by=20 >> using some NAT-Traversal strategy or connects to one offering=20 >> global reachabilty but in principle, not trustable. >> >> 3- If it is the mobile phone who registers firstly, then it=20 >> obviously would choose one globally reachable Peer. And maybe=20 >> can develop some periodic discovery mechanism in order to=20 >> discover if the trustable Peer (that is, the desktop on the=20 >> example) appears at some point. >> >> Well, it is just an idea. Why not use trustable Peers if we=20 >> can do it?. >> >> =20 >>>> On the other hand, IMO an important problem in the p2psip=20 >>>> =20 >> overlay is=20 >> =20 >>>> that my "resource-ID" (or "resource-IDs") is going to be stored by=20 >>>> someone I don't know and (with the solution defined so=20 >>>> =20 >> far) I cannot=20 >> =20 >>>> trust in. This introduce trust and security threads. It=20 >>>> =20 >> would be nice=20 >> =20 >>>> to define a new mechanism which allows the users to store its own=20 >>>> "resource-IDs". It is something I am thinking about and I=20 >>>> =20 >> have some=20 >> =20 >>>> ideas if you are interested. >>>> =20 >>>> =20 >>> It would be interesting to hear what you had in mind. In proposals=20 >>> like this people have made here and elsewhere over the last=20 >>> =20 >> few years,=20 >> =20 >>> there are numerous problems that arise when each user becomes=20 >>> responsible for their own resources as well. How do you handle=20 >>> replication? How would you maintain information when the user is=20 >>> offline? A meta question would be how clients would work in this=20 >>> scenario, since they are, by definition, not directly accessible. >>> Personally, I think distributed storage, with replication and=20 >>> encrypted, signed resources is the best idea, but I would be=20 >>> interested to hear what you have in mind. >>> >>> David (as individual) >>> >>> =20 >>> =20 >> Let me explain my idea with an example. >> If my user-name is Ruben.Cuevas, I (likely) will store in the=20 >> DHT as resource-id the hash(Ruben.Cuevas), lets say this=20 >> resource-id is X. If we consider the use of a DHT system, the=20 >> Responsible Node for X will be the Peer with the closest=20 >> Peer-ID to X. Then, if I want to be the Responsible Node for=20 >> X, I have to obtain the closest Peer-ID. Thus, I can ask to=20 >> the Central Entity (in case of use a Central Entity scheme)=20 >> for the closest Peer-ID to the resource-key associated to=20 >> Ruben.Cuevas. =20 >> I can demonstrate I am Ruben.Cuevas (by a passwd or other=20 >> credentials) and the Peer-ID would be assigned. It could be=20 >> for instance X+1. Then I becomes the Responsible Node for my=20 >> own resource-id. >> If all the users has to do the same and demonstrate their=20 >> credentials, all the users obtain Peer-IDs close to their own=20 >> resource-ids and anyone could obtain Peer-IDs with the=20 >> intention to starve other resources. >> >> As you said we have to deal with seveal issues: >> >> Replication. You can still keep the same replication scheme=20 >> than in the regular DHT schemes: the N closest Peer-IDs.=20 >> However, in this case it is easier to identify the good or=20 >> bad behaviour of my neighbourgs since I am the one which does=20 >> this task. Even more, your neighbourg should be careful in=20 >> make something wrong with your resource-id, since you also=20 >> have stored his resource-id, then you can also make the same=20 >> wrong thing. >> >> I am off-line. Again the same. The same scheme which you use=20 >> in the regular DHT schemes can be applied here. If in regular=20 >> DHT your info is kept alive on the replicas, here you can do the same. >> >> Clients: You have also the same problem as in regular DHTs.=20 >> This scheme does not modifies anything regarding to the clients. >> >> I have not yet going into the detail of this idea, and maybe=20 >> it has several problems I have not yet identified. Then, it=20 >> is really interesing to hear from you. >> >> Cheers, >> Rub=E9n. >> >> =20 >>>> Rub=E9n. >>>> >>>> -- >>>> Rub=E9n Cuevas Rum=EDn >>>> Universidad Carlos III de Madrid >>>> Departamento Ingenier=EDa Telem=E1tica >>>> Avenida de la Universidad, 30 >>>> 28911-Legan=E9s (Madrid). Espa=F1a >>>> email: rcuevas@it.uc3m.es >>>> Tlf: +34 91-6248859 >>>> Fax: +34 91-6248749 >>>> Web: http://www.it.uc3m.es/~rcuevas >>>> >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/p2psip >>>> >>>> =20 >>>> =20 >>> >>> =20 >>> =20 >> -- >> Rub=E9n Cuevas Rum=EDn >> Universidad Carlos III de Madrid >> Departamento Ingenier=EDa Telem=E1tica >> Avenida de la Universidad, 30 >> 28911-Legan=E9s (Madrid). Espa=F1a >> email: rcuevas@it.uc3m.es >> Tlf: +34 91-6248859 >> Fax: +34 91-6248749 >> Web: http://www.it.uc3m.es/~rcuevas >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> >> =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 10:21:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUuk-0004x9-Dr; Tue, 20 Nov 2007 10:21:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUui-0004wd-EY for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:21:24 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuUue-00056S-VJ for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:21:24 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id D1F2533C21; Tue, 20 Nov 2007 07:16:20 -0800 (PST) Date: Tue, 20 Nov 2007 07:16:20 -0800 From: Eric Rescorla To: "Jan Seedorf" Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 In-Reply-To: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071120151620.D1F2533C21@delta.rtfm.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 20 Nov 2007 14:57:28 +0100, Jan Seedorf wrote: > Dear authors of the new RELOAD draft (02), > I have some comments on the security section: > > section 7.3. it is specified that the root-node of some resource ID > (i.e., the node responsible for storing the resource) is > responsible for replication. In section 10.5.4. "residual attacks" > you mention that a query node can check at replica roots for some > resource if the root-node does not respond. I see the following > security problem: if the root-node is originally faulty at storage > time (e.g., compromised), it will likely store invalid (though > detectable) or no resources at all at the replica roots. As you > well describe the only issue here is availability. However, I think > that any countermeasure involving replication must involve > distributed storage done by the query node itself (for reasons > described above). Replication should not be the responsibility of > the root-node. Yeah, this is sort of a thinko in our writeup. We intend to move to explicit writes to each replica by the storing node and just ran out of pre-draft time :) > Section 10.6.1.: You assume a central authority and indeed this > solves many security problems. It limits Sybil attacks and Eclipse > attacks. This is well-described in the draft. However, there are > other attacks on DHT routing. Join-leave attacks can be used by > the attacker to chose its location in the DHT despite a central > node-ID assignment authority (see C. Scheideler, "How to Spread > Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM Symp. Theory > of Comp., Baltimore, MD,pp. 704-13, for a formal analysis of the > node-ID assignment problem in DHTs and join-leave > attacks). Additionally, even if there are no Sybil or Eclipse > attacks, adversary nodes (though well certified through the > admission authority, e.g., because they have been compromised) can > simply drop messages. This severely degrades the lookup success > rate in a DHT. Countermeasures against these attacks may well be > out-of-scope for P2PSIP standardisation, I just feel the section > is misleading in the sense that it suggests that a central > authority protects against all threats on DHT routing. I agree tha there are significant residual attacks. We'll see whwat we can do to make this text clearer. IF you wanted to suggest some text that would be great. Thanks, -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 10:22:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUvy-00058d-KT; Tue, 20 Nov 2007 10:22:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUvx-00058X-S1 for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:22:41 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuUvu-00057r-JV for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:22:41 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 88F5F33C47; Tue, 20 Nov 2007 07:17:38 -0800 (PST) Date: Tue, 20 Nov 2007 07:17:38 -0800 From: Eric Rescorla To: Spencer Dawkins Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notificationfordraft-bryan-p2psip-reload-02 In-Reply-To: <0a0a01c82b87$0f3d15e0$6601a8c0@china.huawei.com> References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> <0a0a01c82b87$0f3d15e0$6601a8c0@china.huawei.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071120151738.88F5F33C47@delta.rtfm.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 20 Nov 2007 09:07:25 -0600, Spencer Dawkins wrote: > I agree with Jan's first point below, and it's broader than RELOAD-02 - I > don't see how replication works if the root node is responsible for all > aspects of replication, and if the query node has to understand replication > in order to locate replica roots, I'm not sure what problem is being solved > by making the root node responsible for replication in the first place. Well, the replication strategy described in RELOAD-02 is very efficient from the perspective of storing overhead. It's also transparent to failures of the root node after replication is finished. It's just not very secure. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 10:27:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuV0B-0006Xw-G4; Tue, 20 Nov 2007 10:27:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuV0A-0006XP-6m for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:27:02 -0500 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuV09-0005F5-ES for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:27:02 -0500 Received: by nz-out-0506.google.com with SMTP id i28so1615382nzi for ; Tue, 20 Nov 2007 07:27:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=AC0qZG5ocf/riHVJ01R1ENiNT9rS6ABuA0e2bEeF+Bk=; b=VXYpuare3XYTTDKDQ98ARZk3QBRfXbgFQfQ+SobCU7AxC5isdabjly6BuFlbfdRb0Rrl+py0j9BeeDazIzUxf0V6cB57KLIDc8toLdAxNhGrjZdGtu3G+ILn4rLWQZNFHr6ymuGAu160TK/6ps+tBu8CfYAklYX+wKH2SXBQmhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=iuSRKsuMSwOPkzHkM1VSPWwuqGTMi9VR7ApJXjUzf5+HhxjO3rumVzlw0tRjdtu9oEqI0jP8x/ZQi6Q2DGWXzE74YlI0sfBRdJoRh/K9+vfJAHiYaK6y6j8QRVXnJbd5vBWXcD+F8qAJfcflO+zKVu9ArOwWPRENnxum8OED9J8= Received: by 10.142.77.11 with SMTP id z11mr1545992wfa.1195572420400; Tue, 20 Nov 2007 07:27:00 -0800 (PST) Received: by 10.65.180.16 with HTTP; Tue, 20 Nov 2007 07:27:00 -0800 (PST) Message-ID: <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> Date: Tue, 20 Nov 2007 10:27:00 -0500 From: "David A. Bryan" To: "Eric Rescorla" Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 In-Reply-To: <20071120151620.D1F2533C21@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> <20071120151620.D1F2533C21@delta.rtfm.com> X-Google-Sender-Auth: 72b448d2583a45d8 X-Spam-Score: 1.8 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: p2psip@lists.ietf.org, Jan Seedorf X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org One problem with having the just the source place the replicas is what happens when the source is offline. For example, I am the source. I send out the data to the original and the replica. Then log off. If one peer fails, then that replica is gone for good unless I come back up to refresh them, so over time, offline information could "decay" in the presence of a slow peer failure rate. Some sort of hybrid might make more sense...but there is (clearly) a security point that needs to be considered here. David (as individual) On Nov 20, 2007 10:16 AM, Eric Rescorla wrote: > At Tue, 20 Nov 2007 14:57:28 +0100, > Jan Seedorf wrote: > > Dear authors of the new RELOAD draft (02), > > I have some comments on the security section: > > > > section 7.3. it is specified that the root-node of some resource ID > > (i.e., the node responsible for storing the resource) is > > responsible for replication. In section 10.5.4. "residual attacks" > > you mention that a query node can check at replica roots for some > > resource if the root-node does not respond. I see the following > > security problem: if the root-node is originally faulty at storage > > time (e.g., compromised), it will likely store invalid (though > > detectable) or no resources at all at the replica roots. As you > > well describe the only issue here is availability. However, I think > > that any countermeasure involving replication must involve > > distributed storage done by the query node itself (for reasons > > described above). Replication should not be the responsibility of > > the root-node. > > Yeah, this is sort of a thinko in our writeup. We intend to > move to explicit writes to each replica by the storing > node and just ran out of pre-draft time :) > > > > Section 10.6.1.: You assume a central authority and indeed this > > solves many security problems. It limits Sybil attacks and Eclipse > > attacks. This is well-described in the draft. However, there are > > other attacks on DHT routing. Join-leave attacks can be used by > > the attacker to chose its location in the DHT despite a central > > node-ID assignment authority (see C. Scheideler, "How to Spread > > Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM Symp. Theory > > of Comp., Baltimore, MD,pp. 704-13, for a formal analysis of the > > node-ID assignment problem in DHTs and join-leave > > attacks). Additionally, even if there are no Sybil or Eclipse > > attacks, adversary nodes (though well certified through the > > admission authority, e.g., because they have been compromised) can > > simply drop messages. This severely degrades the lookup success > > rate in a DHT. Countermeasures against these attacks may well be > > out-of-scope for P2PSIP standardisation, I just feel the section > > is misleading in the sense that it suggests that a central > > authority protects against all threats on DHT routing. > > I agree tha there are significant residual attacks. We'll see > whwat we can do to make this text clearer. IF you wanted to > suggest some text that would be great. > > Thanks, > -Ekr > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 10:27:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuV0g-0006sn-Ra; Tue, 20 Nov 2007 10:27:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuV0g-0006rm-B7 for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:27:34 -0500 Received: from wr-out-0506.google.com ([64.233.184.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuV0b-0005Fu-5P for p2psip@lists.ietf.org; Tue, 20 Nov 2007 10:27:34 -0500 Received: by wr-out-0506.google.com with SMTP id 68so895020wra for ; Tue, 20 Nov 2007 07:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=3YyhrYnCAvhFD0zhjqgeybsAvvL1V8pefF7BjINZ4/M=; b=cjVpoRHmwkZpyUGg97qQg138KPpl5u04SwxQgM0yLLYjuac+1KT/kKOV2xEFleKhteByNiVm2eDpoGBx5rEI9Hx/a15WCt38e8PkNcMIhWKsWqzzVvnzIT6shcDjx1CM0RGuvXlXezJUeiaowtkpJ+9pbgD3J0R664IILIM5stk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=N+GBfb0+HcA8cJ9Y5Mk8SeCn5T3uO7oclrgIcRfhmhZaTikICYQHw2xbRrS2xjMjWeDvhZzpW1kryARcb9nlo258ibQIb+1TQomwB+XA+3g/TECSO9Kf7ao7MOsJaBprMYb/QiXmy07sY0K38ZjVb7BoB1lMkYjt1BhObFDy08U= Received: by 10.142.178.13 with SMTP id a13mr1543722wff.1195572447387; Tue, 20 Nov 2007 07:27:27 -0800 (PST) Received: by 10.142.132.18 with HTTP; Tue, 20 Nov 2007 07:27:27 -0800 (PST) Message-ID: <20d2bdfb0711200727m419a14dmaadfecdf11ad8f28@mail.gmail.com> Date: Tue, 20 Nov 2007 10:27:27 -0500 From: "Bruce Lowekamp" To: "Jan Seedorf" Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 In-Reply-To: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> X-Google-Sender-Auth: db99d3255207ed8a X-Spam-Score: 1.8 (+) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: p2psip@lists.ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 20, 2007 8:57 AM, Jan Seedorf wrote: > Dear authors of the new RELOAD draft (02), > > I have some comments on the security section: > > - In section 7.3. it is specified that the root-node of some resource ID = (i.e., the node responsible for storing the resource) is responsible for re= plication. In section 10.5.4. "residual attacks" you mention that a query n= ode can check at replica roots for some resource if the root-node does not = respond. I see the following security problem: if the root-node is original= ly faulty at storage time (e.g., compromised), it will likely store invalid= (though detectable) or no resources at all at the replica roots. As you we= ll describe the only issue here is availability. However, I think that any = countermeasure involving replication must involve distributed storage done = by the query node itself (for reasons described above). Replication should = not be the responsibility of the root-node. > Jan and Spencer, We agree. 7.3 has this note at the end: This redundancy algorithm breaks if the storing node is malicious and does not store the data in the replica set. Applications which wish to have defenses against that must explicitly store multiple copies of the data with separate peers. [[OPEN ISSUE: Where should a replication algorithm of this type be described? The DHT? The storage layer? The usage?]] Basically, we're aware that this form of redundancy only solves the problem where the responsible peer fails by ensuring that the new responsible peer (once it realizes the failed peer is gone) has a copy of the resource. It doesn't protect against a wide variety of other attacks, including routing. We fully agree there is a need for additional replication, and reload-01 specified to create random replicas by appending a replica number to the resource name, but we were unable to decide what layer should be responsible for that service in the current architecture, so we left it listed as an open issue. It's certainly not an open issue implying there's a question of whether it needs to be solved, it's just a question of what layer should be responsible for solving it. Bruce > - Section 10.6.1.: You assume a central authority and indeed this solves = many security problems. It limits Sybil attacks and Eclipse attacks. This i= s well-described in the draft. However, there are other attacks on DHT rout= ing. Join-leave attacks can be used by the attacker to chose its location i= n the DHT despite a central node-ID assignment authority (see C. Scheideler= , "How to Spread Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM Symp. = Theory of Comp., Baltimore, MD,pp. 704-13, for a formal analysis of the nod= e-ID assignment problem in DHTs and join-leave attacks). Additionally, even= if there are no Sybil or Eclipse attacks, adversary nodes (though well cer= tified through the admission authority, e.g., because they have been compro= mised) can simply drop messages. This severely degrades the lookup success = rate in a DHT. Countermeasures against these attacks may well be out-of-sco= pe for P2PSIP standardisation, I just feel the section is misleading in the= sense that it suggests that a central authority protects against all threa= ts on DHT routing. > Certainly we don't want to imply that the central authority protects against all routing attacks. Better replication helps, among other things. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 10:45:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVHX-0004Kn-Iy; Tue, 20 Nov 2007 10:44:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVHV-0004Ki-OB for p2psip@ietf.org; Tue, 20 Nov 2007 10:44:57 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuVHS-0005wI-5s for p2psip@ietf.org; Tue, 20 Nov 2007 10:44:57 -0500 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IuVHC-00038z-F8; Tue, 20 Nov 2007 09:44:38 -0600 From: "Brian Rosen" To: "'Dean Willis'" , "'Henning Schulzrinne'" References: <01b501c8281c$1b655440$5105a40a@china.huawei.com><369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu><0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu> <0B80FCAE-B2B8-4FE7-9D89-8F9D1277418B@softarmor.com> Subject: RE: [P2PSIP] Why just "peer" and "client"? (was Re: P2PSIP ClientCharacter/Behavior) Date: Tue, 20 Nov 2007 10:44:44 -0500 Message-ID: <027901c82b8c$4797ddd0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acgq91WDsch8wFjVS52kfdkDpvvwTQAkQXrA In-Reply-To: <0B80FCAE-B2B8-4FE7-9D89-8F9D1277418B@softarmor.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org There are some good ideas here. What if the protocol could adapt based on measurement metrics, to bandwidth, computer power, and storage capability variations? A poorly connected device might store some data and do some routing, but only for very "local" peers, for example. It's likely subject to abuse, but it might work pretty well as long as most implementations followed the rules. Any implementation of clients has that problem. Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, November 19, 2007 4:58 PM > To: Henning Schulzrinne > Cc: Philip Matthews; P2PSIP Mailing List > Subject: [P2PSIP] Why just "peer" and "client"? (was Re: P2PSIP > ClientCharacter/Behavior) > > > On Nov 19, 2007, at 7:43 AM, Henning Schulzrinne wrote: > > >> > >> Your e-mail is a good start to an argument why there might be > >> nodes that can and might want to be clients, but cannot be peers, > >> though it still doesn't describe WHAT a client is. > > > > That's simple: For the current definition of the protocols, P2PSIP > > protocols do a key-to-value lookup. A client can perform a get and > > put operation (and other related data manipulation operations), but > > does not route P2PSIP protocol requests. > > Does a client store stuff for other users in the overlay? If not, > that's another difference between clients and peers. > > Personally, I'm now thinking of "client" and "peer" nodes as > hypothetical points in a continuum of functionality. I expect real > systems to slide around in that continuum based on their current > circumstances. They might be high bandwidth or low bandwidth, plugged > in or battery operated, charged by byte or all-you-can-eat, have no > free memory or terabytes of it, be stuck behind an obnoxious firewall > or full-exposed. They might be very busy, or operating with no load > at all. They might have STUN capacity to offer, and they might not. > There are probably more axes of freedom in this continuum than we > have yet imagined. > > And many devices will shift where the are, from time to time. Mobile > devices will move between access points and access technologies. > Devices in data centers will get busy. Voice mail boxes will fill up. > Any device might be affected by maintenance, peripheral death, and so > on. > > So I'd really like to see some way that nodes can adapt to their > changing situations without having to make an all-or-nothing > commitment. Even for nodes that are "fully committed", I'd like to se > a way for them to back off gracefully so they're not "fully > committed" the same way a goose is to foie gras -- that is, stuffed > beyond capacity and then turned into pate'. > > > -- > Dean > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 11:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVq3-0005wv-IP; Tue, 20 Nov 2007 11:20:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVq3-0005tW-0T for p2psip@ietf.org; Tue, 20 Nov 2007 11:20:39 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuVpy-00075u-Gk for p2psip@ietf.org; Tue, 20 Nov 2007 11:20:38 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAKGI52P024995; Tue, 20 Nov 2007 10:18:53 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 18:17:37 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 18:17:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Nov 2007 18:20:13 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F056EAA79@esebe102.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Implementation of P2PP in mobile devices Thread-Index: AcgrFnDtYBsPSD11TaqG4HZa65FJVQAdaUVA References: <01b501c8281c$1b655440$5105a40a@china.huawei.com><369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu><0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu><0B80FCAE-B2B8-4FE7-9D89-8F9D1277418B@softarmor.com> From: To: X-OriginalArrivalTime: 20 Nov 2007 16:17:36.0682 (UTC) FILETIME=[DD38A0A0:01C82B90] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [P2PSIP] Implementation of P2PP in mobile devices X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, Together with the University of Oulu we implemented the P2PP protocol on the S60 platform. The P2PP is designed to work both on PCs and mobile phones. The current implementation allows mobile phones to act both as P2PSIP peers and P2PSIP clients. The demo of P2PP on Nokia phones will be presented at CCNC in Las Vegas in January 2008. Everyone is welcome to visit our stand! If you are interested in P2P for handheld devices you may consider visiting the P2PHD workshop: http://cms.comsoc.org/CCNC_2008/Content/Home/Call_for_Papers_/P2P_HD_Wor kshop.html =20 You may find a link to the second version of the P2PP draft below. Marcin =20 >-----Original Message----- >From: ext Salman Abdul Baset [mailto:salman@cs.columbia.edu]=20 >Sent: 20 November, 2007 03:40 >To: P2PSIP Mailing List >Subject: [P2PSIP] P2PP-01 > > >is available at: >http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-01.txt > > This document defines the Peer-to-Peer Protocol (P2PP), an > application-layer binary protocol, for creating and maintaining an > overlay of participant nodes. The overlay can be created using > various structured and unstructured peer-to-peer protocols such as > Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a > secure transport, supports an application API, has=20 >mechanisms for NAT > and firewall traversal, exchanging node capabilities, and=20 >diagnostic > information. P2PP is designed to support a P2P Session Initiation > Protocol (SIP) network, but it can be used for other=20 >applications as > well. > >Comments are welcome. > >-salman > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 12:50:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXEs-0002hg-PZ; Tue, 20 Nov 2007 12:50:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXEr-0002h9-9H for p2psip@ietf.org; Tue, 20 Nov 2007 12:50:21 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuXEq-0002Yg-Ls for p2psip@ietf.org; Tue, 20 Nov 2007 12:50:21 -0500 Received: from irams2.ira.uni-karlsruhe.de ([141.3.10.82]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IuXEn-0008Mq-La; Tue, 20 Nov 2007 18:50:19 +0100 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by irams2.ira.uni-karlsruhe.de with esmtps id 1IuXEm-0008Ab-8C; Tue, 20 Nov 2007 18:50:17 +0100 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1IuXEl-000554-T7; Tue, 20 Nov 2007 18:50:16 +0100 Received: from wooky.tm.uka.de (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 7204F2FC00E; Tue, 20 Nov 2007 18:50:15 +0100 (CET) Message-ID: <47431E5F.50405@tm.uka.de> Date: Tue, 20 Nov 2007 18:50:23 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: marcin.matuszewski@nokia.com Subject: Re: [P2PSIP] Implementation of P2PP in mobile devices References: <01b501c8281c$1b655440$5105a40a@china.huawei.com><369F224D-2F0E-43BD-A30D-393A2A37EBA9@cs.columbia.edu><0CB3EE77-4837-4CA6-8DDF-F1AE4B0B94D7@cs.columbia.edu><0B80FCAE-B2B8-4FE7-9D89-8F9D1277418B@softarmor.com> <3F18E76823C95E4795181D74BAC7664F056EAA79@esebe102.NOE.Nokia.com> In-Reply-To: <3F18E76823C95E4795181D74BAC7664F056EAA79@esebe102.NOE.Nokia.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: irams2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, this sounds really interesting. Is the implementation open-source? And what overlay protocols are currently implemented? Regards, Ingmar marcin.matuszewski@nokia.com wrote: > Hi all, > > Together with the University of Oulu we implemented the P2PP protocol on > the S60 platform. The P2PP is designed to work both on PCs and mobile > phones. The current implementation allows mobile phones to act both as > P2PSIP peers and P2PSIP clients. The demo of P2PP on Nokia phones will > be presented at CCNC in Las Vegas in January 2008. Everyone is welcome > to visit our stand! > > If you are interested in P2P for handheld devices you may consider > visiting the P2PHD workshop: > http://cms.comsoc.org/CCNC_2008/Content/Home/Call_for_Papers_/P2P_HD_Wor > kshop.html > > You may find a link to the second version of the P2PP draft below. > > Marcin > > >> -----Original Message----- >> From: ext Salman Abdul Baset [mailto:salman@cs.columbia.edu] >> Sent: 20 November, 2007 03:40 >> To: P2PSIP Mailing List >> Subject: [P2PSIP] P2PP-01 >> >> >> is available at: >> http://www.ietf.org/internet-drafts/draft-baset-p2psip-p2pp-01.txt >> >> This document defines the Peer-to-Peer Protocol (P2PP), an >> application-layer binary protocol, for creating and maintaining an >> overlay of participant nodes. The overlay can be created using >> various structured and unstructured peer-to-peer protocols such as >> Bamboo, Chord, Pastry, Kademlia, Gnutella, and Gia. P2PP uses a >> secure transport, supports an application API, has >> mechanisms for NAT >> and firewall traversal, exchanging node capabilities, and >> diagnostic >> information. P2PP is designed to support a P2P Session Initiation >> Protocol (SIP) network, but it can be used for other >> applications as >> well. >> >> Comments are welcome. >> >> -salman >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 13:11:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXZ9-000271-7i; Tue, 20 Nov 2007 13:11:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuXZ7-00026c-6j for p2psip@ietf.org; Tue, 20 Nov 2007 13:11:17 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuXZ4-0002OS-QI for p2psip@ietf.org; Tue, 20 Nov 2007 13:11:17 -0500 Received: by ug-out-1314.google.com with SMTP id u2so3899905uge for ; Tue, 20 Nov 2007 10:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=rE4y9WnX8SG2scmKi7YvL+ADICj0jhah+hMM1oZguh0=; b=QSK9VSiBOoIJdSGEwxtAEDpk9QHpy0oq3Fsr2+U2CFOZNNmCpgX7j9jtAU6WwTSIT3FmDubiQIO7klO4z3dTXHWXb3Hi/pIndr07LPC8Z/fED5h+NLKggqpLEs33QBbGeJHjwf/4nn+k2NUywoDTdOXLP6+ZD48Smzx0zphkFSk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=gjDfvWmWsXYlquoC3wxQfZigYDXgKVu2sFl0BImnIYtHTUyWPCWpvoyLdBkLffBGigpv387ZPDAbgScD71eOWG0fBOottwGWrETqabQOctfW8AgCuwleqRquRhWDib+pe6aifCMYiedHM2wGfxIdTup3HNv6JXp0hx5LygKbBgE= Received: by 10.66.249.11 with SMTP id w11mr880191ugh.1195582273991; Tue, 20 Nov 2007 10:11:13 -0800 (PST) Received: by 10.66.252.5 with HTTP; Tue, 20 Nov 2007 10:11:13 -0800 (PST) Message-ID: <618e24240711201011n547370bag5556ed3f9d9c958b@mail.gmail.com> Date: Tue, 20 Nov 2007 19:11:13 +0100 From: "=?UTF-8?Q?Victor_Pascual_=C3=81vila?=" To: p2psip@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [P2PSIP] comments on using DHTs in wireless ad hoc networks X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0728277533==" Errors-To: p2psip-bounces@ietf.org --===============0728277533== Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgYWxsLApJbiAiZHJhZnQtYnJ5YW4tcDJwc2lwLWFwcC1zY2VuYXJpb3MtMDAudHh0Iiwgc2Vj dGlvbiA0LjIgYW5kIDQuMi4xLgppZGVudGlmaWVzICAiQWQtSG9jIGFuZCBFcGhlbWVyYWwgR3Jv dXBzIiBhcHBsaWNhdGlvbiBzY2VuYXJpb3MsIGFuZApjYW4gYmUgcmVhZDoKCiJFeGFtcGxlcyBv ZiBzdWNoIGVudmlyb25tZW50IGFyZSBpc29sYXRlZCB3aXJlbGVzcyBhZC1ob2MgbmV0d29ya3MK d2l0aCBubyBjb25uZWN0aW9uIHRvIHRoZSBJbnRlcm5ldCBvciBhZC1ob2MgbmV0d29ya3Mgd2l0 aCBsaW1pdGVkCmNvbm5lY3Rpdml0eSB0byB0aGUgSW50ZXJuZXQgaW4gc2l0dWF0aW9ucyBsaWtl IG91dGRvb3IgcHVibGljIGV2ZW50cywKZW1lcmdlbmNpZXMsIGFuZCBiYXR0bGVmaWVsZHMuIgoK SW4gImRyYWZ0LWlldGYtcDJwc2lwLWNvbmNlcHRzLTAxIiwgc2VjdGlvbiA1LjEgZGVzY3JpYmVz ICJUaGUKRGlzdHJpYnV0ZWQgRGF0YWJhc2UgRnVuY3Rpb24iLCBhbmQgY2FuIGJlIHJlYWQ6Cgoi QSBjbGFzcyBvZiBhbGdvcml0aG1zIGtub3duIGFzIERpc3RyaWJ1dGVkIEhhc2ggVGFibGVzCjxo dHRwOi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL1AyUF9vdmVybGF5PiBhcmUgb25lIHdheSB0byBp bXBsZW1lbnQKdGhlIERpc3RyaWJ1dGVkIERhdGFiYXNlLiAgSW4gcGFydGljdWxhciwgYm90aCB0 aGUgQ2hvcmQgYW5kIEJhbWJvbwphbGdvcml0aG1zIGhhdmUgYmVlbiBzdWdnZXN0ZWQgYXMgZ29v ZCBjaG9pY2VzIGZvciB0aGUgZGlzdHJpYnV0ZWQKZGF0YWJhc2UgYWxnb3JpdGhtLiAgSG93ZXZl ciwgbm8gZGVjaXNpb24gaGFzIGJlZW4gdGFrZW4gc28gZmFyLiIKClByb2JsZW0gb2YgaW1wbGVt ZW50aW5nIGEgZGlzdHJpYnV0ZWQgaGFzaCB0YWJsZSBpbiB3aXJlbGVzcyBhZCBob2MKbmV0d29y a3MgaXMgd2VsbC1rbm93bi4gU2NhcmNlbmVzcyBvZiByZXNvdXJjZXMgYW5kIG5vZGUgbW9iaWxp dHkgdHVybgpyb3V0aW5nIGludG8gYSBwcm9ibGVtLgoKSXMgdGhlcmUgYSBjb25zZW5zdXMgb24g dXNpbmcgdGhlIHNhbWUgdHlwZSBvZiAiRGlzdHJpYnV0ZWQgRGF0YWJhc2UKRnVuY3Rpb24iIChl LmcuIERIVCkgaW4gYWxsIGFwcGxpY2F0aW9uIHNjZW5hcmlvcz8gQXJlIG90aGVyIHNvbHV0aW9u cwpvciBESFQgYWRhcHRhdGlvbnMgKGUuZy4gQ0hSKSBjb25zaWRlcmVkIGRlcGVuZGluZyBvbiBh cHBsaWNhdGlvbgpzY2VuYXJpbyByZXF1aXJlbWVudHM/CgpUaGFua3MgYW5kIHNvcnJ5IGlmIHRo aXMgd2FzIGFscmVhZHkgZGlzY3Vzc2VkLAotLSAKVmljdG9yIFBhc2N1YWwgw4F2aWxhCg== --===============0728277533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0728277533==-- From p2psip-bounces@ietf.org Tue Nov 20 14:24:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYhh-0002Us-6w; Tue, 20 Nov 2007 14:24:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuYhf-0002Ub-Cm for p2psip@ietf.org; Tue, 20 Nov 2007 14:24:11 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuYhb-0005yC-Mj for p2psip@ietf.org; Tue, 20 Nov 2007 14:24:11 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2007 11:24:07 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAKJO7WK027109; Tue, 20 Nov 2007 11:24:07 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-3.cisco.com (8.12.10/8.12.6) with SMTP id lAKJO5XW014168; Tue, 20 Nov 2007 19:24:05 GMT In-Reply-To: <7b683f3f0711200332y6352dec6oe192000b3a257b0f@mail.gmail.com> References: <83E64480-F040-4913-8CD1-845A1EB96282@cisco.com> <035301c82b39$cb90bdd0$5105a40a@china.huawei.com> <7b683f3f0711200332y6352dec6oe192000b3a257b0f@mail.gmail.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B4932AA-C70D-4B74-92F8-2EAB1232A823@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] RE: [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Tue, 20 Nov 2007 11:23:32 -0800 To: Eunsoo Shim X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3152; t=1195586647; x=1196450647; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20RE=3A=20[P2PSIP=3ASurvey]=20P2PSIP=20Clien t=20Character/Behavior |Sender:=20; bh=4n8c5M96bKZW9lJVNQF7hQH8LUHymMQIzMf+5yq5t/Q=; b=CMW3pxysMSkUgPaD+tbulIrY27gSnexagvZJA7GVB6g7vQFjRSynJEM41D0XxnFvuJB5NGAw b4mXI9YJTkokt7r/Bup/dT6ynYFJHJXbBcaRsirFkjYnE9lYAUS9FjbEUo2CS4UBD5Mv0jG0QH Yolr4sThTUv52XJ6Hf83VSwY4=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 20, 2007, at 3:32 AM, Eunsoo Shim wrote: > On Nov 20, 2007 12:54 AM, Zheng Hewen wrote: >> Hi, >> >> Please see inline ... ... >> >> Best regards, >> Hewen >> >>> -----Original Message----- >>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>> Sent: 2007?11?20? 13:12 >>> To: Zheng Hewen >>> Cc: P2PSIP Mailing List >> >>> Subject: Re: [P2PSIP:Survey] P2PSIP Client Character/Behavior >>> >>> >>> On Nov 19, 2007, at 6:18 PM, Zheng Hewen wrote: >>> >>>> But here is one issue about the merged RELOAD-01, if >>> P2PSIP clients >>>> own Peer-ID, will this violate DHT algorithm when P2PSIP >>> clients never >>>> are used to store any DHT data? Will the namespace of >>> P2PSIP overlay >>>> not be fully available for peers? >>>> Personally, I do not think that it will impact the other P2PSIP >>>> clients application scenarios, but I wonder the answers for those >>>> above questions. Certainly, if P2PSIP clients use the other >>> namespace >>>> than P2PSIP peers, then all is OK. >>> >>> Let's say some peer-id, X is being used by a client. From the >>> perspective of the the peers for routing and storage, this is >>> the same as if X had been allocated to some peer but that >>> peer was not currently online. The client never does a join >>> to insert X into the DHT topology. The whole space of >>> resource-id is still available for use by the DHT. The >>> advantage of this design is that unifies the authorization >>> model for clients and peer. >>> >> >> [Hewen] In my understanding to your description above, the "Peer- >> IDs" of P2PSIP clients never emerge in DHT topology of >> P2PSIP overlay network, the design of RELOAD-01 only use them to >> identify clients and reuse the authorization model which >> already is used in enrollment or peers' joining procedure. >> Further, the "Peer-IDs" above are in fact some type of >> identifiers of P2PSIP clients, some peers in P2PSIP overlay >> network can use "Peer-IDs" which have the same value with >> "Peer-IDs" owned by P2PSIP clients because those "Peer-IDs" of >> P2PSIP clients never appear in the overlay network (i.e., >> Node-IDs never conflict due to repeat). In summary, essentially, >> the "Peer-IDs" of P2PSIP clients sit in the completely >> different and separate namespace with "Peer-IDs" of P2PSIP peers, >> is my understanding correct? >> >> >> > > I don't know the intention of the RELOAD draft authors. > But I have been thinking that a Client gets a Node ID as a Peer does. > In my picture, there is no difference between the Node ID assigned to > a Peer and Node ID assigned to a Client. > You have only one Node ID space. > If an ID is taken, the ID is used. The ID won't be assigned (should > not be assigned) to any node regardless of the node type. > > Thanks. > -- > Eunsoo Yes - that is how RELOAD is. I think we occasionally get into a bit of confused about what we mean when we say and id is "used". I tried to separate that out a bit in my original email because, as Mr. Hewen is pointing out, they can be used many ways. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 15:56:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iua9D-0007no-9M; Tue, 20 Nov 2007 15:56:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iua9B-0007nb-Kb for p2psip@ietf.org; Tue, 20 Nov 2007 15:56:41 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iua97-0001wT-9P for p2psip@ietf.org; Tue, 20 Nov 2007 15:56:41 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2007 12:56:36 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAKKuaqK010318 for ; Tue, 20 Nov 2007 12:56:36 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAKKua41000614 for ; Tue, 20 Nov 2007 20:56:36 GMT Mime-Version: 1.0 (Apple Message framework v752.3) References: Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Tue, 20 Nov 2007 12:56:03 -0800 To: P2PSIP WG X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=567; t=1195592196; x=1196456196; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Fwd=3A=20P2PSIP=20-=20session=20has=20been=20scheduled=20for= 20IETF=2070=20 |Sender:=20; bh=JFnh/gfb1adfQQ5IQf9HZ1dc1n0IqzYfkmWd3+AiFr4=; b=D7G0s6a7a6JKgiHN52id19vOdN59Dm9qmSwDb9ZGbIYNrXgq/yVUbNP+ZO1YUO2RaBl878my gpnHm8KOZ2RO7dFS/ZDSzkz+yCGDkj4Ne8sHoAinQnWwlRGVQIIenivh; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [P2PSIP] Fwd: P2PSIP - session has been scheduled for IETF 70 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Folks, we managed to rescheduled P2P SIP so it did not have a conflict with other RAI meetings. We could not do this earlier because chairs need to see the the agenda requests for the various RAI WGs before we could sort out the time required for each WG. The P2PSIP WG meeting will now be at > P2PSIP Session 1 (2.5 hours) > Wednesday, Afternoon Session I 1300-1500 > Room Name: Salon D/E > ---------------------------------------------- > The second sipping meeting that was at this has been canceled. Thanks, Cullen _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 18:43:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuckv-0004dq-QG; Tue, 20 Nov 2007 18:43:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iucku-0004dW-MR for p2psip@lists.ietf.org; Tue, 20 Nov 2007 18:43:48 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuckr-00009P-S4 for p2psip@lists.ietf.org; Tue, 20 Nov 2007 18:43:48 -0500 Received: from dynasty.cs.columbia.edu (dynasty.cs.columbia.edu [128.59.16.5]) (user=sa2086 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAKNhinP014431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Nov 2007 18:43:44 -0500 (EST) Date: Tue, 20 Nov 2007 18:43:44 -0500 (EST) From: Salman Abdul Baset To: "David A. Bryan" Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 In-Reply-To: <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> Message-ID: References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> <20071120151620.D1F2533C21@delta.rtfm.com> <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.8 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: p2psip@lists.ietf.org, Jan Seedorf X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org As pointed, the replication mechanisms can be classified as: 1) Publisher (source) oriented 2) Responsible peer (root node) oriented Both publisher and responsible nodes can determine the node replica set, i.e., the list of nodes on which to replicate. In addition to security, factors such as churn rate, uptime and load of a node also impact the choice of replica set. An artifact of using DHTs is that the publisher and responsible peers are generally different. Since nodes churn, the responsible peer may change. In an unstructured (non-DHT) overlay, the publisher node will likely be responsible for determining the replica set. The question of how many replicas to maintain is best left to the overlay operator. As mentioned above, the number of replicas depends on the churn rate, availability guarantees, and security among others. The question whether to maintain replicas after source node fails is best left to the overlay operator. -salman On Tue, 20 Nov 2007, David A. Bryan wrote: > One problem with having the just the source place the replicas is what > happens when the source is offline. > > For example, I am the source. I send out the data to the original and > the replica. Then log off. > > If one peer fails, then that replica is gone for good unless I come > back up to refresh them, so over time, offline information could > "decay" in the presence of a slow peer failure rate. > > Some sort of hybrid might make more sense...but there is (clearly) a > security point that needs to be considered here. > > David (as individual) > > > On Nov 20, 2007 10:16 AM, Eric Rescorla wrote: >> At Tue, 20 Nov 2007 14:57:28 +0100, >> Jan Seedorf wrote: >>> Dear authors of the new RELOAD draft (02), >>> I have some comments on the security section: >>> >>> section 7.3. it is specified that the root-node of some resource ID >>> (i.e., the node responsible for storing the resource) is >>> responsible for replication. In section 10.5.4. "residual attacks" >>> you mention that a query node can check at replica roots for some >>> resource if the root-node does not respond. I see the following >>> security problem: if the root-node is originally faulty at storage >>> time (e.g., compromised), it will likely store invalid (though >>> detectable) or no resources at all at the replica roots. As you >>> well describe the only issue here is availability. However, I think >>> that any countermeasure involving replication must involve >>> distributed storage done by the query node itself (for reasons >>> described above). Replication should not be the responsibility of >>> the root-node. >> >> Yeah, this is sort of a thinko in our writeup. We intend to >> move to explicit writes to each replica by the storing >> node and just ran out of pre-draft time :) >> >> >>> Section 10.6.1.: You assume a central authority and indeed this >>> solves many security problems. It limits Sybil attacks and Eclipse >>> attacks. This is well-described in the draft. However, there are >>> other attacks on DHT routing. Join-leave attacks can be used by >>> the attacker to chose its location in the DHT despite a central >>> node-ID assignment authority (see C. Scheideler, "How to Spread >>> Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM Symp. Theory >>> of Comp., Baltimore, MD,pp. 704-13, for a formal analysis of the >>> node-ID assignment problem in DHTs and join-leave >>> attacks). Additionally, even if there are no Sybil or Eclipse >>> attacks, adversary nodes (though well certified through the >>> admission authority, e.g., because they have been compromised) can >>> simply drop messages. This severely degrades the lookup success >>> rate in a DHT. Countermeasures against these attacks may well be >>> out-of-scope for P2PSIP standardisation, I just feel the section >>> is misleading in the sense that it suggests that a central >>> authority protects against all threats on DHT routing. >> >> I agree tha there are significant residual attacks. We'll see >> whwat we can do to make this text clearer. IF you wanted to >> suggest some text that would be great. >> >> Thanks, >> -Ekr >> >> >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 21:05:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuey3-0003tx-JH; Tue, 20 Nov 2007 21:05:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuey1-0003ts-Jb for p2psip@ietf.org; Tue, 20 Nov 2007 21:05:29 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iuexz-0006Rj-1O for p2psip@ietf.org; Tue, 20 Nov 2007 21:05:29 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRU00EKP345M1@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 10:04:53 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRU007A7344WC@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 10:04:53 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRU00E7S344VB@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 10:04:52 +0800 (CST) Date: Wed, 21 Nov 2007 10:04:52 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com> To: 'Eunsoo Shim' , =?iso-8859-1?Q?'Victor_Pascual_=E1vila'?= Message-id: <003001c82be2$e7914640$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-index: AcgraJXOY99UFVxbTai8qnIBG/2jggAeaW8Q X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'P2PSIP Mailing List' , 'Philip Matthews' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > This is too general a statement. > It is true that a Client may implement/provide a service. > But same for a Peer. > Whether a node becomes a Peer or a Client is independent of whether it > provides a particular service other than routing of overlay messages > and maintaining the overlay. I agree with you that the role of peers or clients is independent of the services what they intends to provide. What I really suggest is that if a node wants to provide service, acting as a client may be better than acting as peer, so that it could avoid the influence from the overlay. This is a reason why we need a client. Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 21:41:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IufX9-0004Ru-Kk; Tue, 20 Nov 2007 21:41:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IufX7-0004RX-3N for p2psip@ietf.org; Tue, 20 Nov 2007 21:41:45 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IufX4-0007Wr-6q for p2psip@ietf.org; Tue, 20 Nov 2007 21:41:45 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRU00B834S7A8@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 10:40:55 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRU00MSJ4S60R@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 10:40:55 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRU00KIM4S5GW@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 10:40:54 +0800 (CST) Date: Wed, 21 Nov 2007 10:40:53 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Routing mode in P2PSIP In-reply-to: <20d2bdfb0711200409v379fdae1s8a7209bc131db5c7@mail.gmail.com> To: 'Bruce Lowekamp' Message-id: <003701c82be7$efb363d0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgrbjXaQjDyF7v/SA6euPbsMiS8dAAdL0Vw X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Bruce: Response is inline. Regards! -- Jiang XingFeng > -----Original Message----- > From: lowekamp@gmail.com [mailto:lowekamp@gmail.com] On Behalf Of Bruce > Lowekamp > Sent: Tuesday, November 20, 2007 8:09 PM > To: JiangXingFeng > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] Routing mode in P2PSIP > > On 11/20/07, JiangXingFeng wrote: > > Hi, > > > > There are four routing mode described in the draft-bryan-p2psip-reload-01. > > After reading P2PP and RELOAD revision 2, only the iterative routing mode > > and recursive mode are supported. > > > > Why doesn't P2PSIP peer protocol support semi-recursive mode? IMHO, > > semi-recursive mode at least has two following advantages over other routing > > mode: > > 1. Semi-recursive mode is more resilient from failures of intermediate peers > > than recursive mode. In recursive mode, if any of the intermediate peers > > fails, the response could not return back in the reverse path the request > > has traversed. > > 2. Semi-recursive mode has lower latency than recursive and iterative mode. > > The response in semi-recursive mode could go back to the request originator > > by forwarding based on its transport address. > > These two statements are both true if the requesting peer is not > behind a NAT or a firewall. The reload-01 protocol embedded a > "default" IP addr that could be contacted directly and then specified > how to make things work if the default wasn't accessible (NAT or > firewall problem). The problem with that approach is that it takes a > lot longer when the default doesn't work, because you have to let it > timeout before you realize it won't work. > > > > > IMHO, the major issue that semi-recursive mode should face is how the > > response goes to the request originator if the request originator is behind > > NAT. I think there must be solution to this issue. > > Yes, the solution is to use recursive routing. I have some idea about this issue: how does the responder send the response back to the source peer directly if the source peer is behind NAT? I present it here and ask for your comments. Maybe we could choose some peers which are on the public Internet and the responder could ask them to relay the response to the source peer. Because the chosen relaying peer is on the public internet, so the response could arrive at these relaying peer. So the problem is reduced to how the relaying peer knows how to relay the response to the source peer. IMHO, there are two candidate solutions: 1. The source peer could find in its routing states some neighbor peers with public address. Since the source peer and the relaying peer are neighbors, so there must be at least a pre-established connection between them. So if the relaying peer receives the response from the responder, it will check whether it has a pre-established connection with the source peer. if there is, forward the response over the connection. If there is none, maybe it discards the response for security consideration. It is like what the TURN does. TURN relays the packet from the peer only if there is permission for the peer. 2. If there is no such neighbor peers in its routing states, the source peer could use an alternative method. It could find a public peer and send the request to this peer. Upon receiving the request, the public peer could learn the source transport address of the request and put it in the request. Later the request will be processed by the responder and the response will be returned to the public relaying peer. The relaying peer could check whether the source peer's transport address in the response, if it is, the public relaying peer uses this transport address to forward the response to the source peer. Hope to get some comments from you and the community. Thanks in advance. >If somehow a peer can > learn that an incoming response won't be blocked (it knows it has no > NAT or firewall, or the NAT or firewall does address independent > mapping and filtering) then semi-recursive would work. I think it is easy to know whether a peer is behind NAT or not. We could achieve this by encoding it in the info describing the characteristic of the source peer, such as transport address, etc. It is easy for the destination peer to get this information and send it back directly. > Maybe it's > worth extending the protocol to support that, but it isn't clear it > would work and would complicate the protocol tremendously. > (Minimally, it adds state at the responder to notice that its response > must have been lost and to route it recursively instead.) Maybe you are right. It is not easy for the responder to make sure that the response has been arrived at the source peer reliability. But could you share with me how the recursive mode achieves this goal? IMHO, the state is also unavoidable in recursive mode if you realize it by keeping state at intermediate peer. > > Having the responder do ICE to open a direct connection for the > response isn't really feasible because ICE would take longer than the > recursive response. It is not a right time to use ICE, because the response has not returned to the source peer, and then the source peer has not got the destination peer's candidates. > > There is another optimization to allow the two peers to open a direct > connection with ICE if they're going to be sending a lot of messages > back and forth. That's the one I would pick to improve performance > of message routing. > > Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 20 22:46:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IugXH-0008Pg-TY; Tue, 20 Nov 2007 22:45:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IugXG-0008Pa-Ac for p2psip@ietf.org; Tue, 20 Nov 2007 22:45:58 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IugXA-0006QF-ND for p2psip@ietf.org; Tue, 20 Nov 2007 22:45:58 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRU007AG7R4WQ@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 11:45:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRU007UM7R4WC@szxga01-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 11:45:04 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRU00KJI7R4GZ@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 11:45:04 +0800 (CST) Date: Wed, 21 Nov 2007 11:45:03 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Fwd: P2PSIP - session has been scheduled for IETF 70 In-reply-to: To: 'Cullen Jennings' , 'P2PSIP WG' Message-id: <003f01c82bf0$e6aafc90$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acgrt+H14duUlsAgSQ2CiWXsEkgMOQAOI/uQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi: Has the agenda of the P2PSIP WG been fixed? I have not seen any mail about the agenda. I am sorry if I overlook it. Regards! -- Jiang XingFeng > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, November 21, 2007 4:56 AM > To: P2PSIP WG > Subject: [P2PSIP] Fwd: P2PSIP - session has been scheduled for IETF 70 > > > Folks, we managed to rescheduled P2P SIP so it did not have a > conflict with other RAI meetings. We could not do this earlier > because chairs need to see the the agenda requests for the various > RAI WGs before we could sort out the time required for each WG. > > The P2PSIP WG meeting will now be at > > > P2PSIP Session 1 (2.5 hours) > > Wednesday, Afternoon Session I 1300-1500 > > Room Name: Salon D/E > > ---------------------------------------------- > > > > The second sipping meeting that was at this has been canceled. > > Thanks, Cullen > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 01:57:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IujWU-0003bi-Ey; Wed, 21 Nov 2007 01:57:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IujWS-0003RJ-Gz for p2psip@ietf.org; Wed, 21 Nov 2007 01:57:20 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IujWN-0002Up-HX for p2psip@ietf.org; Wed, 21 Nov 2007 01:57:20 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRU00EB6GEZOF@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 14:52:11 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRU008O6GEUZC@szxga02-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 14:52:11 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRU00JN1GEQT4@szxml03-in.huawei.com> for p2psip@ietf.org; Wed, 21 Nov 2007 14:52:06 +0800 (CST) Date: Wed, 21 Nov 2007 14:52:02 +0800 From: Zheng Hewen Subject: RE: client protocol ([P2PSIP] Proposal for progress on protocols) In-reply-to: <3F18E76823C95E4795181D74BAC7664F056EA9D0@esebe102.NOE.Nokia.com> To: marcin.matuszewski@nokia.com, eunsooshim@gmail.com, yaowang.bupt@gmail.com Message-id: <022601c82c0b$056bc370$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acgm0jXSBOuWKC3tTYei7m4Ci5o0SAEpL/pgACThgzA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990 Cc: hsinnrei@adobe.com, p2psip@ietf.org, philip_matthews@magma.ca X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline... ... Best regards, Hewen > -----Original Message----- > From: marcin.matuszewski@nokia.com > [mailto:marcin.matuszewski@nokia.com] > Sent: 2007?11?20? 21:37 > To: eunsooshim@gmail.com; yaowang.bupt@gmail.com > Cc: hsinnrei@adobe.com; p2psip@ietf.org; philip_matthews@magma.ca > Subject: RE: client protocol ([P2PSIP] Proposal for progress > on protocols) > > Hi all, > > I agree with Eunsoo. The client protocol must support PUT, > GET, JOIN and Bootstrap methods. Clients do not need to store > any data on behalf of other P2PSIP nodes (but they may decide > otherwise). The client discovers services and users' location > and publishes its own information in the overlay using a > client protocol. When a SIP UA is collocated with a client > software the client requests an IP address and port of callee > and establishes a SIP session directly (or through a relay) > to the other end. Client don't need to implement a SIP stack. > It can be a node that advertises non-SIP services to the > overlay e.g. media relaying services. > [Hewen] Agree. The client protocol is a light-weight protocol, a P2PSIP client may contribute its storage capacity to its associated peer or provide services to overlay network and publish the discovered services info into the overlay through its associated peer. > Definitely the client protocol can be a subset of a peer > protocol as it is shown in the P2PP draft. > > Marcin > > >-----Original Message----- > >From: ext Eunsoo Shim [mailto:eunsooshim@gmail.com] > >Sent: 14 November, 2007 17:22 > >To: Yao Wang > >Cc: P2PSIP Mailing List; Henry Sinnreich; Philip Matthews > >Subject: Re: client protocol ([P2PSIP] Proposal for progress on > >protocols) > > > >Not at all. > >The overlay needs to provide just distributed database functionality > >(== distributed storage and search/lookup > >functionality) and at most some kind of generic transport/routing > >functionality. These functionalities can be well summarized as PUT, > >GET, and SEND functions. > > > >Any information about SIP related services such as mapping > of SIP URI > >to a location(IP address) or nodes providing certain application > >functions/services like conferencing server can be stored > and looked up > >using the Peer (and Client) Protocol. You don't need SIP at all here. > > > >That is the idea accepted by the group widely. Now all the proposals > >about Peer Protocol do not use extensions/variations of SIP. > > > >If we all understand that Client Protocol provides only a subset of > >Peer Protocol's functionality and Peer Protocol can be and better be > >implemented independently of SIP, why would we need to have SIP for > >Client Protocol? It does not make sense to me. > > > >Thanks. > > > >Eunsoo > > > >On Nov 13, 2007 10:28 PM, Yao Wang wrote: > >> Yes, you are right. > >> > >> Currently, the main difference in the debate comes from how > >to build the client protocol, whether it could be based on > SIP, whether > >it could be a syntax subset of Peer Protocol, or whether it is a > >separate protocol different from both SIP and Peer Protocol but its > >function is subset of the functions of Peer Protocol. > >> > >> Here are some of my understandings, > >> 1. What services client can get using Client Protocol? > >> In my opinion, there are two kinds of services. > >> Firstly, from the charter of this WG, this WG "is > >chartered to develop protocols and mechanisms for the use of the > >Session Initiation Protocol (SIP)". It is clearly that SIP service > >(including locating target user, forwarding SIP > >messages) is a basic service that P2PSIP Overlay MUST provide. > >Client Protocol MUST enable client to access this services. > >> Secondly, services other than SIP. As mentioned in > >concept draft, some individual peers may provide services in > addition > >to storage and routing, for example STUN services, to the overlay. > >However, because clients do not join P2PSIP Overlay, they can not > >discover these services directly. > >Therefore, client protocol MUST provide a mean for client to > know what > >services are available in the P2PSIP Overlay and the comprehensive > >parameters for access these services. After getting these > parameters, > >the client can use other protocols, for example STUN, to access the > >service, which should be out of the scope of client protocol. > >> To meet the first kind of requirements, SIP is mandatory. > > > > > > > > When it comes to the second kind of requirements, both SIP > and other > >protocol (e.g. a subset of peer protocol) can work. > >> If the subset of peer protocol is adopted as client > >protocol (supposing the peer protocol is not SIP-based), the client > >_has_ _to_ run two protocol stacks at the same time, which > obviously > >consumes more resources of client than only running SIP stack. Given > >the assumption that clients are resource-limited devices, > running one > >more protocol stack may cause the degradation of its performances. > >> Thus, why not use SIP and SIP extensions to satisfy > >both requirements? why not kill two birds with one stone? > >Currently, many mobile devices have been equipped with SIP; > the reuse > >of SIP in client protocol not only reduces the resource needed on > >client devices but also reduces the implementation > complexity of client > >protocol. > >> > >> 2. What services peer can get using Client Protocol? > >> It seems that people in this list accept that the > >client should contribute its storage capacity to peers. In > my opinion, > >the client can provide more service than that. Here is one possible > >example which is described in our proposed draft ("A > SIP-based P2PSIP > >Client Protocol") > >> "For example, a conferences server wants to provide > >conference services to nodes in a P2PSIP system. Because > the decoding, > >mixture and encoding of multiple media streams can be quite a heavy > >load for its computational resources, this conference server > may choose > >not to join in the P2PSIP > >overlay. Thus, some extra resources, which would be used > >for the maintenance of P2P overlay if the server joined > overlay, can be > >utilized for providing better conference services." > >> Therefore, the client protocol must be extensible > >for supporting any possible services. SIP is a well-developed > >extensible signal protocol, thus, we propose to build client > protocol > >based on SIP. > >> > >> Any comments? > >> > >> > >> Sincerely yours, > >> > >> Yao Wang > >> Mobile Life and New Media Lab, BUPT > >> > >> -----Original Message----- > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Wednesday, November 14, 2007 3:42 AM > >> To: Philip Matthews; lichun li; Zheng Hewen; Yao Wang; Wei Gengyu > >> Cc: P2PSIP Mailing List > >> > >> Subject: client protocol ([P2PSIP] Proposal for progress on > >protocols) > >> > >> > I think there is no consensus > >> > yet on the nature or even existence of clients. > >> > >> >From this list I understand there is less a problem with the > >> >existence > >> of clients, but rather if there should be a separate > client protocol. > >> > >> Also, some folks mentioned that the client protocol should > just be a > >> subset of the peer protocol. > >> > >> Is this understanding of the discussions correct? > >> > >> Given the preponderance of mobile devices, this alone would > >justify a > >> new version of the concepts document. > >> > >> Henry > >> > >> -----Original Message----- > >> From: Philip Matthews [mailto:philip_matthews@magma.ca] > >> Sent: Tuesday, November 13, 2007 10:41 AM > >> To: lichun li; Zheng Hewen; Yao Wang; Wei Gengyu > >> Cc: P2PSIP Mailing List > >> Subject: Re: [P2PSIP] Proposal for progress on protocols > >> > >> As a working group member, I am encouraged by the debate on the > >> existence and nature of the P2PSIP client, and the proposals for a > >> Client Protocol. > >> > >> But as a co-author of the Concepts draft, I think it is > premature to > >> modify the discussion on Clients in the draft. It is not > >that I don't > >> want to do this, it is just that I think there is no > >consensus yet on > >> the nature or even existence of clients. > >> > >> I think we are coming up to the point where there will be a major > >> revision to the Concepts draft that will focus in on a specific > >> architecture and mechanisms, and that revision may well include a > >> major revision in the section on clients. But I don't think > >it should > >> be the revision for this cycle. > >> > >> - Philip > >> > >> > >> > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > > > > > >-- > >Eunsoo > > > >_______________________________________________ > >P2PSIP mailing list > >P2PSIP@ietf.org > >https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 08:16:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupRl-0001CC-87; Wed, 21 Nov 2007 08:16:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IupRk-0001C7-8u for p2psip@ietf.org; Wed, 21 Nov 2007 08:16:52 -0500 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IupRh-0004Ui-PZ for p2psip@ietf.org; Wed, 21 Nov 2007 08:16:52 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1867141nzf for ; Wed, 21 Nov 2007 05:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=65H0cTPCl0Yaj/hxOvlFbxSuH1k8cuHobXHJWJ/8Gz0=; b=IvNm9DrG4gMyGwZS6QTEfxsnkbEpy9B4R9X2rgvPsAongnvOFuEw8Tm6Od76GdLGzCnFApCn/sRlH0lQyko9pZgzlVS5cuO0vGIciUIOmkImbicxKKghnbwmfumE8iPNOYAUf3Ro/8eBHHtobgaaAS7BCyD/7tm+MrwW2WpjtIM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=p9XoadLsDz26AxLdMMF75fg4Y2YNe0w8+Pkmyqdba7jGnP3cUurxuYXe3dTa0ZXKMtUk8pZAjJfMe+6IkTZwSb7t2UBI4qvbeYHIrtE89SMQDafH9H/1oFxccG5+/i6IwQ1FP6r+Rl3jUJlDHzTRzUyHQ6DBb1gJQKc5DEBwVms= Received: by 10.143.36.15 with SMTP id o15mr1903328wfj.1195651008337; Wed, 21 Nov 2007 05:16:48 -0800 (PST) Received: by 10.142.132.18 with HTTP; Wed, 21 Nov 2007 05:16:48 -0800 (PST) Message-ID: <20d2bdfb0711210516h29407727m1f1312789bbeeb64@mail.gmail.com> Date: Wed, 21 Nov 2007 08:16:48 -0500 From: "Bruce Lowekamp" To: JiangXingFeng Subject: Re: [P2PSIP] Routing mode in P2PSIP In-Reply-To: <003701c82be7$efb363d0$6905a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0711200409v379fdae1s8a7209bc131db5c7@mail.gmail.com> <003701c82be7$efb363d0$6905a40a@china.huawei.com> X-Google-Sender-Auth: a2dde28ddddaed30 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 20, 2007 9:40 PM, JiangXingFeng wrote: > > Maybe we could choose some peers which are on the public Internet and the > responder could ask them to relay the response to the source peer. Because > the chosen relaying peer is on the public internet, so the response could > arrive at these relaying peer. So the problem is reduced to how the relaying > peer knows how to relay the response to the source peer. IMHO, there are two > candidate solutions: This idea works fine if a significant number of the peers have unfirewalled, public addresses, but one of the goals of reload-02 (as well as reload-01, asp, and most of the other proposals) is to work in an environment where there are few to none of the peers with such addresses. While I understand your desire to improve routing efficiency, if it makes the routing protocol more complicated because different things are done in different conditions, I would be opposed to it. It's also very important, I think, to ensure that the load on every peer is as equal as it can be. Recursive routing does that for the peer protocol. > >If somehow a peer can > > learn that an incoming response won't be blocked (it knows it has no > > NAT or firewall, or the NAT or firewall does address independent > > mapping and filtering) then semi-recursive would work. > I think it is easy to know whether a peer is behind NAT or not. We could > achieve this by encoding it in the info describing the characteristic of the > source peer, such as transport address, etc. It is easy for the destination > peer to get this information and send it back directly. > The recipient of a message can know whether the sending peer was behind a NAT, but a peer itself can't necessarily know if it's behind a NAT (until it talks with a node that is outside its NAT). Detecting that you're behind a firewall is even harder. It can be done, but I would hate to base a protocol on its success. > > Maybe it's > > worth extending the protocol to support that, but it isn't clear it > > would work and would complicate the protocol tremendously. > > (Minimally, it adds state at the responder to notice that its response > > must have been lost and to route it recursively instead.) > Maybe you are right. It is not easy for the responder to make sure that the > response has been arrived at the source peer reliability. But could you > share with me how the recursive mode achieves this goal? IMHO, the state is > also unavoidable in recursive mode if you realize it by keeping state at > intermediate peer. > The reload-02 messages keep the state in the message itself (the via/route list). Retransmission is handled end-to-end. So the responder still doesn't have a way of knowing for sure if the response got back, but it can assume that it was just random packet loss and keep sending the response whenever it gets a retransmission until the sender receives it. If you try to send it back directly, the responder has to have some heuristic like if it sends the response back twice and then receives a third retransmission, there must be a nat or firewall issue. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 09:49:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqtV-0006hr-0g; Wed, 21 Nov 2007 09:49:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqtT-0006ad-Mz for p2psip@lists.ietf.org; Wed, 21 Nov 2007 09:49:35 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqtQ-0007F1-MF for p2psip@lists.ietf.org; Wed, 21 Nov 2007 09:49:35 -0500 Received: by rv-out-0910.google.com with SMTP id k20so2078383rvb for ; Wed, 21 Nov 2007 06:49:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=22xdW3V5AwAL2l0ntgxhpd7h45y0QX2ce2fLuxKB80w=; b=iVXK4NLMsHWTHZoXrKORp7CaCSiO6bfzLdoDYw04iMme9syDQMM539XtgOUQid4IkLX2nBiAAV9rN+Ml62zlzWbujpyAC364/pNmKNXu20l2DdKCZH2nCVQBuCP7TE6jutvH03JlWI3O5Lv7HOphuaoyqVqwNk/KY+EqjA9lrFM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=EMrbSaL67y3Q3qDzQy7M72RqodpfbRmj5XUifR5c8oqstfJzfJvm54M9guIIjXm+4uM+v7RO4TvM+VzO60T4fxzI527EWyDjVEKly0by+VdhE57858LKQl6mm+L/9f0AN0OI8SOXxwIho7zZuq9LvrK0tOKR/rHte8PyiQWnXDU= Received: by 10.141.185.3 with SMTP id m3mr3334089rvp.1195656572101; Wed, 21 Nov 2007 06:49:32 -0800 (PST) Received: by 10.65.180.16 with HTTP; Wed, 21 Nov 2007 06:49:31 -0800 (PST) Message-ID: <4d4304a00711210649o7d305e7dh9dc3e399920532f5@mail.gmail.com> Date: Wed, 21 Nov 2007 09:49:32 -0500 From: "David A. Bryan" To: "Salman Abdul Baset" Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> <20071120151620.D1F2533C21@delta.rtfm.com> <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> X-Google-Sender-Auth: 3a054976e3676a4a X-Spam-Score: 1.8 (+) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: p2psip@lists.ietf.org, Jan Seedorf X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Sort of related to this discussion is the open question of what layer does replication occur? There are several alternatives: * Do it on a per-pluggable DHT level. In otherwords, each DHT that is defined specifies a replication mechanism. This may be very desirable if someone has a very clever DHT design with a specific replication scheme, but might remove operator flexibility and make it difficult for specific applications to have alternate schemes (although they could layer it on top of the DHT provided scheme) * Do it at the application level instead. Each usage specifies what replication it would like (how many, where, do you do source node replication if the source node fails, etc.) The advantage to this is that it can be much more tailored for the use of the application, but if one overlay is supporting multiple usages, then things stored in common to each usage (maybe the user's public key, for example, which different applications may want) could conceivably be replicated in more places than really needed. It also means a clever DHT replication idea isn't as useful, since there would still be replication above it at the app level anyway (although I guess you could just turn off the application level replication in that case anyway) * There might be other options... This is definitely a good open issue...I'd love to see a bit of discussion about what others think the pros and cons are here... --David (as individual) On Nov 20, 2007 6:43 PM, Salman Abdul Baset wrote: > As pointed, the replication mechanisms can be classified as: > > 1) Publisher (source) oriented > 2) Responsible peer (root node) oriented > > Both publisher and responsible nodes can determine the node replica set, > i.e., the list of nodes on which to replicate. In addition to security, > factors such as churn rate, uptime and load of a node also impact the > choice of replica set. > > An artifact of using DHTs is that the publisher and responsible peers are > generally different. Since nodes churn, the responsible peer may change. > In an unstructured (non-DHT) overlay, the publisher node will likely be > responsible for determining the replica set. > > The question of how many replicas to maintain is best left to the overlay > operator. As mentioned above, the number of replicas depends on the > churn rate, availability guarantees, and security among others. > > The question whether to maintain replicas after source node fails is best > left to the overlay operator. > > -salman > > > On Tue, 20 Nov 2007, David A. Bryan wrote: > > > One problem with having the just the source place the replicas is what > > happens when the source is offline. > > > > For example, I am the source. I send out the data to the original and > > the replica. Then log off. > > > > If one peer fails, then that replica is gone for good unless I come > > back up to refresh them, so over time, offline information could > > "decay" in the presence of a slow peer failure rate. > > > > Some sort of hybrid might make more sense...but there is (clearly) a > > security point that needs to be considered here. > > > > David (as individual) > > > > > > On Nov 20, 2007 10:16 AM, Eric Rescorla wrote: > >> At Tue, 20 Nov 2007 14:57:28 +0100, > >> Jan Seedorf wrote: > >>> Dear authors of the new RELOAD draft (02), > >>> I have some comments on the security section: > >>> > >>> section 7.3. it is specified that the root-node of some resource ID > >>> (i.e., the node responsible for storing the resource) is > >>> responsible for replication. In section 10.5.4. "residual attacks" > >>> you mention that a query node can check at replica roots for some > >>> resource if the root-node does not respond. I see the following > >>> security problem: if the root-node is originally faulty at storage > >>> time (e.g., compromised), it will likely store invalid (though > >>> detectable) or no resources at all at the replica roots. As you > >>> well describe the only issue here is availability. However, I think > >>> that any countermeasure involving replication must involve > >>> distributed storage done by the query node itself (for reasons > >>> described above). Replication should not be the responsibility of > >>> the root-node. > >> > >> Yeah, this is sort of a thinko in our writeup. We intend to > >> move to explicit writes to each replica by the storing > >> node and just ran out of pre-draft time :) > >> > >> > >>> Section 10.6.1.: You assume a central authority and indeed this > >>> solves many security problems. It limits Sybil attacks and Eclipse > >>> attacks. This is well-described in the draft. However, there are > >>> other attacks on DHT routing. Join-leave attacks can be used by > >>> the attacker to chose its location in the DHT despite a central > >>> node-ID assignment authority (see C. Scheideler, "How to Spread > >>> Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM Symp. Theory > >>> of Comp., Baltimore, MD,pp. 704-13, for a formal analysis of the > >>> node-ID assignment problem in DHTs and join-leave > >>> attacks). Additionally, even if there are no Sybil or Eclipse > >>> attacks, adversary nodes (though well certified through the > >>> admission authority, e.g., because they have been compromised) can > >>> simply drop messages. This severely degrades the lookup success > >>> rate in a DHT. Countermeasures against these attacks may well be > >>> out-of-scope for P2PSIP standardisation, I just feel the section > >>> is misleading in the sense that it suggests that a central > >>> authority protects against all threats on DHT routing. > >> > >> I agree tha there are significant residual attacks. We'll see > >> whwat we can do to make this text clearer. IF you wanted to > >> suggest some text that would be great. > >> > >> Thanks, > >> -Ekr > >> > >> > >> > >> _______________________________________________ > >> P2PSIP mailing list > >> P2PSIP@ietf.org > >> https://www1.ietf.org/mailman/listinfo/p2psip > >> > > > > > > > > -- > > David A. Bryan > > dbryan@SIPeerior.com > > +1.757.565.0101 x101 > > +1.757.565.0088 (fax) > > www.SIPeerior.com > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 10:39:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurfQ-0007ck-Rn; Wed, 21 Nov 2007 10:39:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurfO-0007QS-Tl for p2psip@ietf.org; Wed, 21 Nov 2007 10:39:06 -0500 Received: from py-out-1112.google.com ([64.233.166.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IurfN-0000SG-ES for p2psip@ietf.org; Wed, 21 Nov 2007 10:39:06 -0500 Received: by py-out-1112.google.com with SMTP id d32so13448864pye for ; Wed, 21 Nov 2007 07:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Kc5QKe+o7MwgRs/kPtPMgZyfF8ao/B1YexaZ+JEDcUQ=; b=A/Bcj4MRlkVSeSueen1C6YW6oupqU24Or+ae5yiQSiuZrEza9hvgDhIS7wcx/nI9BSMZgyDk55B1mn4zdcKRgqtkKNBfkHR+z++37oBh3a9ML4nRZN/NwlsmMeT8gdmSg5lTv76xfv+qkJDfJmuyX5MFc9EcZWc1cSMjZd9URBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mc0PFVGitLANni2feNDAg5HKQ7WBi6Bw8cWDdF5Sx/+G6uyMotShpKKzr4DyJZJrz6NaignrWZP3tnCa905wxDg6Sei7wz1S426av1dtCdnSgRf/B7tC/jFmffqAnF3F4sla2cg2TxNTRnBc0Hs2irbPHwbNbeb5bAdbUBDdr40= Received: by 10.65.53.3 with SMTP id f3mr16938175qbk.1195659541073; Wed, 21 Nov 2007 07:39:01 -0800 (PST) Received: by 10.65.180.16 with HTTP; Wed, 21 Nov 2007 07:39:00 -0800 (PST) Message-ID: <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> Date: Wed, 21 Nov 2007 10:39:00 -0500 From: "David A. Bryan" To: JiangXingFeng Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <003001c82be2$e7914640$6905a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com> <003001c82be2$e7914640$6905a40a@china.huawei.com> X-Google-Sender-Auth: 9a6bfadd0efcbac9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 20, 2007 9:04 PM, JiangXingFeng wrote: > > This is too general a statement. > > It is true that a Client may implement/provide a service. > > But same for a Peer. > > Whether a node becomes a Peer or a Client is independent of whether it > > provides a particular service other than routing of overlay messages > > and maintaining the overlay. > I agree with you that the role of peers or clients is independent of the > services what they intends to provide. What I really suggest is that if a > node wants to provide service, acting as a client may be better than acting > as peer, so that it could avoid the influence from the overlay. This is a > reason why we need a client. To me, this argument seems completely backward from what I think makes sense for a client. The only good reason for a client I've heard is that it has some limited capacity and/or bandwidth. If the capacity or bandwidth is limited, it seems it would *not* be a good choice to offer services. Why would being in the overlay be a bad influence? Personally, I really don't like the direction this is going, if we say that offering a service is a good reason not to be a peer. One of the biggest problems with P2P is everyone wanting to be a client and not participate in the overlay. If a device has enough bandwidth or power to offer services, then it *definitely* should be a peer. The more reasons we allow to cause a node to be a client rather than a peer, the less peers, which means those need to be very powerful, and it will be painful to be one, so they will want to be clients, so there will be less peers....it spirals. If it can possibly be a peer, I think it should be... David (as individual) > > Regards! > > JiangXingFeng > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 10:42:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuriO-0004Au-Jh; Wed, 21 Nov 2007 10:42:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuriM-0004A6-Vi for p2psip@ietf.org; Wed, 21 Nov 2007 10:42:10 -0500 Received: from rv-out-0910.google.com ([209.85.198.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuriJ-0000WW-L1 for p2psip@ietf.org; Wed, 21 Nov 2007 10:42:10 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1876506rvb for ; Wed, 21 Nov 2007 07:42:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=wPCh93Jud44C5mYcfo2ZmTam0ASJYjrILZwouh5BLkk=; b=nW8evWvRuEw+ZBBhh1xt19pJ3JYaAIrYl+hfoyah1+W+CPPTw6w6Ar8PVsZph47Qv6VYEGAeppIscxgCt7Pap2A2F/ysF6e5Y8cIn+9EsJIZofer9GsGR/g0scR9ofWVq5r2rI3DKCAbC/h+wEd4GlUHjTvrhGVFBFqnw+XIE88= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NguEmo3pTjnUJmB+z/YC6IWt5zD8X68yAdCZ/zhZ16tJB7S/annQBL1DzH2tZvvhYqmrJMlMTG0eWGXUUs/iWORvIK3MlHMWknb/m5+8gZcSZvn7t3O+Xro8sT+Z8/LTjfwPwiDdiGNRidRBnNw11T6af7sI70d+gfMZA1vPnrw= Received: by 10.140.207.2 with SMTP id e2mr3365914rvg.1195659724815; Wed, 21 Nov 2007 07:42:04 -0800 (PST) Received: by 10.141.177.20 with HTTP; Wed, 21 Nov 2007 07:42:04 -0800 (PST) Message-ID: <7b683f3f0711210742i37901173ye9212afc3cb64695@mail.gmail.com> Date: Wed, 21 Nov 2007 10:42:04 -0500 From: "Eunsoo Shim" To: "David A. Bryan" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com> <003001c82be2$e7914640$6905a40a@china.huawei.com> <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > If it can possibly be a peer, I think it should be... Yes. -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 11:00:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iurzo-0001tm-0P; Wed, 21 Nov 2007 11:00:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iurzn-0001Uv-0Z for p2psip@ietf.org; Wed, 21 Nov 2007 11:00:11 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iurzk-0005t8-A5 for p2psip@ietf.org; Wed, 21 Nov 2007 11:00:08 -0500 Received: from [72.87.190.78] (helo=[10.9.0.1]) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1Iurzf-0005HB-6a; Wed, 21 Nov 2007 11:00:03 -0500 Message-ID: <474455CD.2040200@idssoftware.com> Date: Wed, 21 Nov 2007 07:59:09 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification for draft-bryan-p2psip-reload-02 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da94099d0effd8ec83c81e6180343b468b7b5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.87.190.78 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, I have a practical suggestion for the forwarding header. The last two paragraphs of section 4.1 of the draft describe how the Route-List shrinks while Via-List grow as the Reload message passes through intermediate peers. If you flip the order of these two lists such that Via-List comes first followed by the Route-list: 24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Via | Route | | | List | List | Flags | | Length | Length | | 28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Via List // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Route List // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Route Log // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Then as the message passes the pre-selected list of peers in Route-list, intermediate peer can simply increment the via-list-length field and decrement the route-list-length field, in effect shrink the route-list by 1 while growing the via-list by 1 without touching the actual Via-List and Route-list that follows. By the way, I do believe the header should indicate the size of the IDs. Thanks --Michael Cullen Jennings wrote: > > The various authors of ASP and RELOAD have managed to get these two > proposal merged together into one and we are pretty happy with the > result. > > You can find it at > http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-02.txt > > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: November 18, 2007 8:57:03 PM PST >> To: fluffy@cisco.com >> Cc: lowekamp@sipeerior.com, ekr@networkresonance.com, jdrosen@cisco.com >> Subject: New Version Notification for draft-bryan-p2psip-reload-02 >> >> >> A new version of I-D, draft-bryan-p2psip-reload-02.txt has been >> successfuly submitted by Cullen Jennings and posted to the IETF >> repository. >> >> Filename: draft-bryan-p2psip-reload >> Revision: 02 >> Title: REsource LOcation And Discovery (RELOAD) >> Creation_date: 2007-11-18 >> WG ID: Independent Submission >> Number_of_pages: 96 >> >> Abstract: >> This document defines REsource LOcation And Discovery (RELOAD), a >> peer-to-peer (P2P) binary signaling protocol for usage on the >> Internet. A P2P signaling protocol provides its clients with an >> abstract hash table service between a set of cooperating peers that >> form the overlay network. RELOAD is designed to support a P2P >> Session Initiation Protocol (P2PSIP) network, but it can be utilized >> by other applications with similar requirements by defining new >> usages that specify the data types that must be stored for a >> particular application, such as location for SIP. RELOAD defines a >> security model based on a certificate enrollment service that >> provides unique identities. NAT traversal is a fundamental service >> of the protocol. >> >> This draft represents a concrete proposal for the P2PSIP Peer >> Protocol. The protocol described here builds on the lessons and >> experiences from designing and implementing the dSIP, ASP, and RELOAD >> protocols and is a merge of features from RELOAD-01 and ASP. >> >> >> >> The IETF Secretariat. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 11:56:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iusry-0007YM-QK; Wed, 21 Nov 2007 11:56:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iusrw-0007Y9-Mn for p2psip@ietf.org; Wed, 21 Nov 2007 11:56:08 -0500 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iusrv-0003RX-A8 for p2psip@ietf.org; Wed, 21 Nov 2007 11:56:08 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1932328nzf for ; Wed, 21 Nov 2007 08:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=RmqzorklyyoSQ/8GtAnKn1YcspD0fEedIRQBJADAqVc=; b=tncpqHsxSKggcgK88F/kPRNEq6C8xemf/3Ja46+yywXG5Rmj58/x3UM/VGk0/yamV6fjGE/M3B5BjVPXvgY4iEa7+LDDYTWZDCM59vNATtkazLSpFC6swFE6rxt4Jy7F31BW6Hqd5RQu21dNUT/pg1qECCi+MuNmyNON92UVwfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mtQxykblp4vqEKyqqeEVMk80m0C5uheFHddpeg6iz6j/P4sP3iRnvARWQiz7U6upWocWg6BAWXvs3Oan/o6HLqlLKrG6lNgPe5m7i+OTPt+TxCdQXc3XgMU1Y1BCRuSsFtN6dP/8bkuIrZm4rSP4KkWMRxwawoe9tYOZnT3TVDY= Received: by 10.65.159.19 with SMTP id l19mr17174993qbo.1195664165549; Wed, 21 Nov 2007 08:56:05 -0800 (PST) Received: by 10.65.180.16 with HTTP; Wed, 21 Nov 2007 08:56:05 -0800 (PST) Message-ID: <4d4304a00711210856i762e5fcchd43e6d5b01148cf2@mail.gmail.com> Date: Wed, 21 Nov 2007 11:56:05 -0500 From: "David A. Bryan" To: JiangXingFeng Subject: Re: [P2PSIP] Fwd: P2PSIP - session has been scheduled for IETF 70 In-Reply-To: <003f01c82bf0$e6aafc90$6905a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <003f01c82bf0$e6aafc90$6905a40a@china.huawei.com> X-Google-Sender-Auth: e0f6efc1d891a170 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The specifics are still being ironed out -- including the speakers. We plan to discuss a few open issues we hope to make progress on, the concepts draft, and perhaps (very, very) short proposals on specific protocols, but we are still debating the agenda, so that can change. More to follow shortly... David On Nov 20, 2007 10:45 PM, JiangXingFeng wrote: > Hi: > > Has the agenda of the P2PSIP WG been fixed? I have not seen any mail about > the agenda. I am sorry if I overlook it. > > Regards! > -- > Jiang XingFeng > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Wednesday, November 21, 2007 4:56 AM > > To: P2PSIP WG > > Subject: [P2PSIP] Fwd: P2PSIP - session has been scheduled for IETF 70 > > > > > > > Folks, we managed to rescheduled P2P SIP so it did not have a > > conflict with other RAI meetings. We could not do this earlier > > because chairs need to see the the agenda requests for the various > > RAI WGs before we could sort out the time required for each WG. > > > > The P2PSIP WG meeting will now be at > > > > > P2PSIP Session 1 (2.5 hours) > > > Wednesday, Afternoon Session I 1300-1500 > > > Room Name: Salon D/E > > > ---------------------------------------------- > > > > > > > The second sipping meeting that was at this has been canceled. > > > > Thanks, Cullen > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 14:41:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvRO-0006nb-51; Wed, 21 Nov 2007 14:40:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuvRM-0006mv-Od for p2psip@ietf.org; Wed, 21 Nov 2007 14:40:52 -0500 Received: from exprod6og50.obsmtp.com ([64.18.1.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuvRM-0005N7-57 for p2psip@ietf.org; Wed, 21 Nov 2007 14:40:52 -0500 Received: from source ([192.150.20.142]) by exprod6ob50.postini.com ([64.18.5.12]) with SMTP; Wed, 21 Nov 2007 11:40:46 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lALJeiNT010845; Wed, 21 Nov 2007 11:40:44 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lALJebRC024356; Wed, 21 Nov 2007 11:40:37 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 04:40:37 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Wed, 21 Nov 2007 11:40:34 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> In-Reply-To: <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Thread-Index: AcgsVK15vpatHXTCSG+6BshkZMgFewAHa74g References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com><003001c82be2$e7914640$6905a40a@china.huawei.com> <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> From: "Henry Sinnreich" To: "David A. Bryan" , "JiangXingFeng" X-OriginalArrivalTime: 21 Nov 2007 19:40:37.0006 (UTC) FILETIME=[63AC52E0:01C82C76] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org A. Client Rationale =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Why would being in the overlay be a bad influence? A mobile client is more likely to change its IP address and thus force a new stabilization process (Chord terminology) every time in the overlay. B. Who Can Be A Peer =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The more reasons we allow to cause a node to be a client rather than a > peer=20 Which nodes can declare themselves a peer and which are (mobile) clients is a matter of policy by the overlay operator. The nodes that can declare themselves a peer, within policy, will need to meet certain criteria such as: - Some security checks (which is TBD) - NAT traversal scenario says it's behind no NAT or p2p-friendly NAT - BW as seen by the node. This topic (B.) deserves a memo written by a design team with input from looking first at the existing p2p networks; and there are plenty of them. My two cents,=20 Henry -----Original Message----- From: David A. Bryan [mailto:dbryan@sipeerior.com]=20 Sent: Wednesday, November 21, 2007 9:39 AM To: JiangXingFeng Cc: Philip Matthews; P2PSIP Mailing List Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior On Nov 20, 2007 9:04 PM, JiangXingFeng wrote: > > This is too general a statement. > > It is true that a Client may implement/provide a service. > > But same for a Peer. > > Whether a node becomes a Peer or a Client is independent of whether it > > provides a particular service other than routing of overlay messages > > and maintaining the overlay. > I agree with you that the role of peers or clients is independent of the > services what they intends to provide. What I really suggest is that if a > node wants to provide service, acting as a client may be better than acting > as peer, so that it could avoid the influence from the overlay. This is a > reason why we need a client. To me, this argument seems completely backward from what I think makes sense for a client. The only good reason for a client I've heard is that it has some limited capacity and/or bandwidth. If the capacity or bandwidth is limited, it seems it would *not* be a good choice to offer services. Why would being in the overlay be a bad influence? Personally, I really don't like the direction this is going, if we say that offering a service is a good reason not to be a peer. One of the biggest problems with P2P is everyone wanting to be a client and not participate in the overlay. If a device has enough bandwidth or power to offer services, then it *definitely* should be a peer. The more reasons we allow to cause a node to be a client rather than a peer, the less peers, which means those need to be very powerful, and it will be painful to be one, so they will want to be clients, so there will be less peers....it spirals. If it can possibly be a peer, I think it should be... David (as individual) > > Regards! > > JiangXingFeng > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 17:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxfQ-0001kZ-7Y; Wed, 21 Nov 2007 17:03:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuxfP-0001fV-BM for p2psip@ietf.org; Wed, 21 Nov 2007 17:03:31 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuxfL-0007NT-K1 for p2psip@ietf.org; Wed, 21 Nov 2007 17:03:31 -0500 Received: from [192.168.1.4] (65-65-155-30.dsl.bigbend.net [65.65.155.30] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lALM3P11004764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 21 Nov 2007 16:03:26 -0600 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: P2PSIP Mailing List From: Dean Willis Date: Wed, 21 Nov 2007 16:03:17 -0600 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [P2PSIP] More thoughts on clients, peers, and services, and service routing X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org In the voluminous discussion of the last 36 hours, I think I'm seeing an alternative emerge that I will try and restate. One way to divide the problem space is to differentiate the tasks of "finding", "routing", and "everything else". Several people have proposed that peers exclusively provide "finding and routing" services. Clients use the "finding and routing" services of peers. Both clients and peers can also offer other services, such as STUN relay (although some might say that peers offering other services are acting as clients when they do so). I think this model works fairly well, and it continues in the principle that peers are a superset of clients -- that is, that clients and peers are pretty much similar, but peers do a few things that clients can't. For each service that a client or peer provides, that node would "put" a service entry in to the database, and these services are completely distinct from the nodes role as peer or client Is this the only way to divide the problem? Maybe clients and peers are very different things, neither subsets nor supersets of each other. What if peers deal exclusively with "finding", and we think of message routing as a separate service entirely? In this approach, one could ask a peer "Please store this resource record" or "Please fetch this resource record", but not "Please send this message to alice@example.com". How would this facilitate setting up SIP sessions? Alice might request that the overlay store as a resource record, a route to "alice@example.com", where that route might include not only Alice's "contact", but also hops for nodes that have agreed to serve as relays for sending messages to Alice. This is somewhat analogous to the "path" and "service route" terminology in SIP. We can think of this as a "put" operation against the distributed database. To call Alice, Bob would then simply do a "get" operation, requesting a route to "alice@example.com". He would then use the result as a SIP route vector to send an INVITE request to Alice. Both of these require some sort of convention for constructing the resource-ID for the route record, but that's fairly trivial. The harder parts: How would Alice discover an appropriate vector? And how do we compensate for the fact the ideal route between Bob and Alice might be different than the route between Charlie and Alice? Of course, before Alice can find "routing" nodes in the database, those nodes have to list themselves. Each one might start by finding a primal node (a "routing bootstrap", if you will) and making ICE checks against that node. If they can reach it and it can reach them, they consider themselves "tier-1" nodes, and "put" resource records listing themselves as tier-1 nodes. If not, then they query the database for tier-1 nodes, perform ICE checks against them, and add resource records listing themselves as tier-2 nodes adjacent to the tier-1 nodes which which they have mutual reachability. If they aren't adjacent to any tier-1 nodes, then they repeat for tier-2, then tier-3, and so on. Of course, it would be nice if the distributed database offered some technique for automagically scoping the candidates, but it isn't required for the algorithm to terminate. Optionally, routing nodes could do persistent "outbound"-like bindings with some higher-tier node selected as the most-adjacent node they can reach, thereby either short-circuiting the search process or achieving connectivity across NAT/FW boundaries that block reverse-path checks. One could further short-circuit the process by using broadcast and multicast to find neighbors that have already established their vectors, then copying those vectors rather than finding new ones. Alice might begin by querying the distributed database for nodes offering the "routing" service, thereby obtaining a list of candidate nodes. She might then do something like an ICE-like evaluation to find one or more acceptable candidates, and would select the lowest- tiered node she could reach. Of course it would be nice if the distributed database could help narrow this search, but it isn't absolutely required. Alice would continue working up the tiers until reaching tier-1, then "put" a vector or into the database, where that vector lists Alice's contact plus the URIs of each routing node up to and including her tier-1 contact. Bob, when calling Alice, would "get: her vector, then run a shortest- path calculation between his vector and her vector, then use the result as a SIP route to reach Alice. What we get out of this is a system where the distributed database can be any off-the-shelf DHT (such as OpenDHT), and where SIP messages are routed according to what is in effect a minimum spanning tree calculation against the sip-routing topology of the network. Alternatively, we could do subtree and named-subtree (dynamic aggregation) approaches that would provide absolutely optimal routes but have higher overheads. Think OSPF, but where aggregations (OSPF areas) are defined dynamically vice ICE-like adjacency checks. This is a little different from the current proposals, which seem to require a customized DHT algorithm and and routes messages across that DHT based on the dynamic topology of the DHT itself and is likely to give a much less efficient a route. Of course, the route discovery process (especially in the event of a topology change) is much easier. On the other hand, the DHT topology tells us little or nothing about net-path efficient routing, which is CRITICAL for media- path relay, and the model proposed here would provide much better selection mechanisms for net-path efficient media relays. But haven't we, for all practical purposes, developed a net-path optimized routing database that we bootstrapped into using a conventional DHT? Do we need to reinvent path-efficient routing for messaging, media relay, and every service? Would it have been more efficient just to start with a path-efficient DHT to start with? I don't know yet. I do know that thinking about application-aware routing at Internet scales is giving me a severe head pain, and historically, the complexity of this is why we have the "thin- waisted" routing model of the Internet. I just wished it worked in the real world of NATs and firewalls and other annoying stuff. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 20:02:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv0SO-0002wY-PB; Wed, 21 Nov 2007 20:02:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv0SN-0002pT-6p for p2psip@ietf.org; Wed, 21 Nov 2007 20:02:15 -0500 Received: from wa-out-1112.google.com ([209.85.146.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv0SL-0007Q8-94 for p2psip@ietf.org; Wed, 21 Nov 2007 20:02:15 -0500 Received: by wa-out-1112.google.com with SMTP id k40so4295033wah for ; Wed, 21 Nov 2007 17:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Aw+0GQaKFs3x8ZN4a2rm0dQ2VD4PncutfUn8NsiK3AM=; b=ari3I+yk1Kw9NprpPA/3asWplkvcUDC//RLOMAUuw1vwnPJ3n1BT9RYCSmDFEF/NGA241xYX/Sq8i+yaCucuIYz3I2zn+VX3jG5FBWgaBahp2ra+ViS+nyC+f77Z2T7Hg+Kgqbyq98lx8gXgA4cbsakznVyGDXZpci506w0CHnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=iefLEqxvkQw2yLsHWp5ePIYJkt8nibsW/DFoDf9vh5C/39f0WyLhQLxzZLefVls8W4LKQOvNI3YOdkbMQAO3kEujC4tmdltAk/lv+sIgDiiLmaoJ4+4EhioIVNidIUGLttWQ0jO30HgTWByF0kD785OYME79j5ltHou4aJYkiko= Received: by 10.114.167.2 with SMTP id p2mr1553086wae.1195693331539; Wed, 21 Nov 2007 17:02:11 -0800 (PST) Received: by 10.114.203.14 with HTTP; Wed, 21 Nov 2007 17:02:10 -0800 (PST) Message-ID: <7d6b50690711211702v267220fcl8a209cdda4516174@mail.gmail.com> Date: Thu, 22 Nov 2007 09:02:10 +0800 From: "lichun li" To: "David A. Bryan" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> MIME-Version: 1.0 References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com> <003001c82be2$e7914640$6905a40a@china.huawei.com> <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1553224800==" Errors-To: p2psip-bounces@ietf.org --===============1553224800== Content-Type: multipart/alternative; boundary="----=_Part_26026_33003989.1195693331529" ------=_Part_26026_33003989.1195693331529 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/21/07, David A. Bryan wrote: > > On Nov 20, 2007 9:04 PM, JiangXingFeng wrote: > > > This is too general a statement. > > > It is true that a Client may implement/provide a service. > > > But same for a Peer. > > > Whether a node becomes a Peer or a Client is independent of whether it > > > provides a particular service other than routing of overlay messages > > > and maintaining the overlay. > > I agree with you that the role of peers or clients is independent of the > > services what they intends to provide. What I really suggest is that if > a > > node wants to provide service, acting as a client may be better than > acting > > as peer, so that it could avoid the influence from the overlay. This is > a > > reason why we need a client. > > To me, this argument seems completely backward from what I think makes > sense for a client. The only good reason for a client I've heard is > that it has some limited capacity and/or bandwidth. If the capacity or > bandwidth is limited, it seems it would *not* be a good choice to > offer services. I think there is another good reason: a node doesn't support the DHT algorithm used in overlay. Why would being in the overlay be a bad influence? > > Personally, I really don't like the direction this is going, if we say > that offering a service is a good reason not to be a peer. One of the > biggest problems with P2P is everyone wanting to be a client and not > participate in the overlay. If a device has enough bandwidth or power > to offer services, then it *definitely* should be a peer. The more > reasons we allow to cause a node to be a client rather than a peer, > the less peers, which means those need to be very powerful, and it > will be painful to be one, so they will want to be clients, so there > will be less peers....it spirals. > > If it can possibly be a peer, I think it should be... I agree. But there might be some exceptions. David (as individual) > > > > > Regards! > > > > JiangXingFeng > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_26026_33003989.1195693331529 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 11/21/07, David A. Bryan <dbryan@sipeerior.com> wrote:
On Nov 20, 2007 9:04 PM, JiangXingFeng <jiang.x.f@huawei.com> wrote:
> > This is too general a statement.
> > It is true that a Client may implement/provide a service.
> > But same for a Peer.
> > Whether a node becomes a Peer or a Client is independent of whether it
> > provides a particular service other than routing of overlay messages
> > and maintaining the overlay.
> I agree with you that the role of peers or clients is independent of the
> services what they intends to provide. What I really suggest is that if a
> node wants to provide service, acting as a client may be better than acting
> as peer, so that it could avoid the influence from the overlay. This is a
> reason why we need a client.

To me, this argument seems completely backward from what I think makes
sense for a client. The only good reason for a client I've heard is
that it has some limited capacity and/or bandwidth. If the capacity or
bandwidth is limited, it seems it would *not* be a good choice to
offer services.
 
I think there is another good reason: a node doesn't support the DHT algorithm used in overlay.

Why would being in the overlay be a bad influence?

Personally, I really don't like the direction this is going, if we say
that offering a service is a good reason not to be a peer. One of the
biggest problems with P2P is everyone wanting to be a client and not
participate in the overlay. If a device has enough bandwidth or power
to offer services, then it *definitely* should be a peer. The more
reasons we allow to cause a node to be a client rather than a peer,
the less peers, which means those need to be very powerful, and it
will be painful to be one, so they will want to be clients, so there
will be less peers....it spirals.

If it can possibly be a peer, I think it should be...
 
I agree. But there might be some exceptions.

David (as individual)

>
> Regards!
>
> JiangXingFeng
>
>
>
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>



--
David A. Bryan
dbryan@SIPeerior.com
+1.757.565.0101 x101
+1.757.565.0088 (fax)
www.SIPeerior.com

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



--
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT ------=_Part_26026_33003989.1195693331529-- --===============1553224800== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1553224800==-- From p2psip-bounces@ietf.org Wed Nov 21 20:34:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv0xi-0006W7-IP; Wed, 21 Nov 2007 20:34:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv0xh-0006W2-Em for p2psip@ietf.org; Wed, 21 Nov 2007 20:34:37 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv0xd-0000Eq-Ak for p2psip@ietf.org; Wed, 21 Nov 2007 20:34:37 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRV003VWWCAE9@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 09:33:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRV006SHWC8CN@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 09:33:46 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRV001G3WC4ST@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 09:33:44 +0800 (CST) Date: Thu, 22 Nov 2007 09:33:40 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> To: "'David A. Bryan'" , 'JiangXingFeng' Message-id: <006a01c82ca7$b63d9970$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcgsVLGvw3RZWnCARTSPrdPtFnJmqQAUFOyg X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline ... ... Best regards, Hewen > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com] > Sent: 2007?11?21? 23:39 > To: JiangXingFeng > Cc: Philip Matthews; P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > On Nov 20, 2007 9:04 PM, JiangXingFeng wrote: > > > This is too general a statement. > > > It is true that a Client may implement/provide a service. > > > But same for a Peer. > > > Whether a node becomes a Peer or a Client is independent > of whether > > > it provides a particular service other than routing of overlay > > > messages and maintaining the overlay. > > I agree with you that the role of peers or clients is > independent of > > the services what they intends to provide. What I really suggest is > > that if a node wants to provide service, acting as a client may be > > better than acting as peer, so that it could avoid the > influence from > > the overlay. This is a reason why we need a client. > > To me, this argument seems completely backward from what I > think makes sense for a client. The only good reason for a > client I've heard is that it has some limited capacity and/or > bandwidth. If the capacity or bandwidth is limited, it seems > it would *not* be a good choice to offer services. > > Why would being in the overlay be a bad influence? > > Personally, I really don't like the direction this is going, > if we say that offering a service is a good reason not to be > a peer. One of the biggest problems with P2P is everyone > wanting to be a client and not participate in the overlay. If > a device has enough bandwidth or power to offer services, > then it *definitely* should be a peer. The more reasons we > allow to cause a node to be a client rather than a peer, the > less peers, which means those need to be very powerful, and > it will be painful to be one, so they will want to be > clients, so there will be less peers....it spirals. > [Hewen]Agree. Incentive measure is important, but it is dependent the application scenarios in the real world. In P2PSIP overlay network consisting of hosts from unknown Internet, security consideration and incentive measure are mandatory and must be considered first; but in P2PSIP overlay network consisting of nodes from autonomous system (e.g., Mobile communication system of an ISP, or enterprises' communication in VPN), incentive measure is not mandatory but optional. I do also think that we need a smart incentive measure but the incentive measure would be flexible and separate from nodes' capability, certainly the incentive measure is dependent on nodes' contribution to P2PSIP overlay network. In fact, it is very difficult (even impossible) to declare that which node has the competency to act as a peer until we have a similar mechanism like MPLS-TE to be aware of every node's capacity and contribution willing or we use a central server to execute admission control in P2PSIP overlay network, but any strict (even harsh) admission control will keep many users/nodes far away from P2PSIP overlay network, it will block P2PSIP deployment in many autonomous systems. > If it can possibly be a peer, I think it should be... [Hewen] I also hope so, it will make the P2PSIP overlay network simple, personally, but it is not feasible in some application scenarios as above description, do you think so? We will detail the P2PSIP client use cases in an I-D named with "P2PSIP client requirements" which was mentioned days ago in the mail list. > > David (as individual) > > > > > Regards! > > > > JiangXingFeng > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 20:42:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv15f-0003P8-NC; Wed, 21 Nov 2007 20:42:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv15d-0003Fd-Kc for p2psip@ietf.org; Wed, 21 Nov 2007 20:42:49 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv15c-0005ZP-Cb for p2psip@ietf.org; Wed, 21 Nov 2007 20:42:49 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRV000L0WQCSA@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 09:42:13 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRV00B9LWQB34@szxga01-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 09:42:12 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRV004YXWQ7FT@szxml03-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 09:42:11 +0800 (CST) Date: Thu, 22 Nov 2007 09:42:07 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> To: 'Henry Sinnreich' , "'David A. Bryan'" , 'JiangXingFeng' Message-id: <006b01c82ca8$e452ab10$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcgsVK15vpatHXTCSG+6BshkZMgFewAHa74gAA1yKAA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline ... ... Best regards, Hewen > -----Original Message----- > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: 2007?11?22? 3:41 > To: David A. Bryan; JiangXingFeng > Cc: Philip Matthews; P2PSIP Mailing List > Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > A. Client Rationale > =================== > > > Why would being in the overlay be a bad influence? > > A mobile client is more likely to change its IP address and > thus force a new stabilization process (Chord terminology) > every time in the overlay. > > B. Who Can Be A Peer > ==================== > > The more reasons we allow to cause a node to be a client > rather than a > > > peer > > Which nodes can declare themselves a peer and which are > (mobile) clients is a matter of policy by the overlay operator. > > The nodes that can declare themselves a peer, within policy, > will need to meet certain criteria such as: > > - Some security checks (which is TBD) > - NAT traversal scenario says it's behind no NAT or p2p-friendly NAT > - BW as seen by the node. > > This topic (B.) deserves a memo written by a design team with > input from looking first at the existing p2p networks; and > there are plenty of them. > [Hewen] It seems that we need a feasible admission control mechanism. This mechanism may be central policy-based (e.g., using central policy server + COPS) or distributed individual (e.g. using flood to synchronizing each nodes' capability and willing, but it seems not good). This mechanism can work a smart contribution incentive measure. > My two cents, > > Henry > > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com] > Sent: Wednesday, November 21, 2007 9:39 AM > To: JiangXingFeng > Cc: Philip Matthews; P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > On Nov 20, 2007 9:04 PM, JiangXingFeng wrote: > > > This is too general a statement. > > > It is true that a Client may implement/provide a service. > > > But same for a Peer. > > > Whether a node becomes a Peer or a Client is independent > of whether > it > > > provides a particular service other than routing of > overlay messages > > > and maintaining the overlay. > > I agree with you that the role of peers or clients is independent of > the > > services what they intends to provide. What I really suggest is that > if a > > node wants to provide service, acting as a client may be better than > acting > > as peer, so that it could avoid the influence from the overlay. This > is a > > reason why we need a client. > > To me, this argument seems completely backward from what I > think makes sense for a client. The only good reason for a > client I've heard is that it has some limited capacity and/or > bandwidth. If the capacity or bandwidth is limited, it seems > it would *not* be a good choice to offer services. > > Why would being in the overlay be a bad influence? > > Personally, I really don't like the direction this is going, > if we say that offering a service is a good reason not to be > a peer. One of the biggest problems with P2P is everyone > wanting to be a client and not participate in the overlay. If > a device has enough bandwidth or power to offer services, > then it *definitely* should be a peer. The more reasons we > allow to cause a node to be a client rather than a peer, the > less peers, which means those need to be very powerful, and > it will be painful to be one, so they will want to be > clients, so there will be less peers....it spirals. > > If it can possibly be a peer, I think it should be... > > David (as individual) > > > > > Regards! > > > > JiangXingFeng > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 21:41:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv20L-0004wU-R3; Wed, 21 Nov 2007 21:41:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv20L-0004s4-3h for p2psip@ietf.org; Wed, 21 Nov 2007 21:41:25 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iv20J-0007y7-NP for p2psip@ietf.org; Wed, 21 Nov 2007 21:41:25 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRV00AQAZFKEV@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 10:40:32 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRV008AGZFJG3@szxga03-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 10:40:32 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRV00C34ZFJBV@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 10:40:31 +0800 (CST) Date: Thu, 22 Nov 2007 10:40:31 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Routing mode in P2PSIP In-reply-to: <20d2bdfb0711210516h29407727m1f1312789bbeeb64@mail.gmail.com> To: 'Bruce Lowekamp' Message-id: <008d01c82cb1$0cb485d0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgsQMtGVXzgtPjoRvaZUthyT8bNOAAaFvGw X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org HI, Bruce: Response inline. The reason why I want to introduce semi-recursive routing mode is that it has some advantages over other routing mode and it is has the best routing efficiency. And I also think it could be complementary with the iterative routing mode and iterative mode. I also admit there are some problems in semi-recursive mode, but there are also some other problems to be solved in other routing mode. Now, I think it is not the right time to exclude the semi-recursive routing mode. I also want to get some advice and comments from the other guys in the community. Regards! JiangXingFeng > On Nov 20, 2007 9:40 PM, JiangXingFeng wrote: > > > > Maybe we could choose some peers which are on the public Internet and the > > responder could ask them to relay the response to the source peer. Because > > the chosen relaying peer is on the public internet, so the response could > > arrive at these relaying peer. So the problem is reduced to how the relaying > > peer knows how to relay the response to the source peer. IMHO, there are two > > candidate solutions: > > This idea works fine if a significant number of the peers have > unfirewalled, public addresses, but one of the goals of reload-02 (as > well as reload-01, asp, and most of the other proposals) is to work in > an environment where there are few to none of the peers with such > addresses. Sorry, I have not read the reload-02 entirely. And I will go on reading it. I have a concern here: how does the RELOAD support the situation where all the peers are behind NAT? How do the peers who are behind NAT, maybe p2p-unfriendly NAT, communicate with each other? Could you give more details here? Thanks! > While I understand your desire to improve routing > efficiency, if it makes the routing protocol more complicated because > different things are done in different conditions, I would be opposed > to it. I don't think introducing semi-recursive routing mode will make the routing protocol more complicated. There are two routing mode, iterative mode and recursive mode proposed in RELOAD-2. They have different processing routine, so the things to be done must be different in the two routing modes. Semi-recursive could have a separate one, I think. > It's also very important, I think, to ensure that the load on > every peer is as equal as it can be. Recursive routing does that for > the peer protocol. IMHO, if there must be some relays for communication between peers, it could use external relay servers outside of the overlay, and I also think it could use the peers who could help. I think the essence of the P2P technology is helping each other. > > > >If somehow a peer can > > > learn that an incoming response won't be blocked (it knows it has no > > > NAT or firewall, or the NAT or firewall does address independent > > > mapping and filtering) then semi-recursive would work. > > I think it is easy to know whether a peer is behind NAT or not. We could > > achieve this by encoding it in the info describing the characteristic of the > > source peer, such as transport address, etc. It is easy for the destination > > peer to get this information and send it back directly. > > > > The recipient of a message can know whether the sending peer was > behind a NAT, but a peer itself can't necessarily know if it's behind > a NAT (until it talks with a node that is outside its NAT). I am not an expert of NAT. but I know there are some methods for a node to know whether it is behind NAT or not. STUN is an example. Do I leave something behind? >Detecting > that you're behind a firewall is even harder. Yes, I agree. > It can be done, but I would hate to base a protocol on its success. If the peer does not know where it is, behind NAT or not, does it mean the ICE should be used even if the two public guys wants to communicate with each other directly. From my point of view, it is time-consuming and unnecessary. > > > > > Maybe it's > > > worth extending the protocol to support that, but it isn't clear it > > > would work and would complicate the protocol tremendously. > > > (Minimally, it adds state at the responder to notice that its response > > > must have been lost and to route it recursively instead.) > > Maybe you are right. It is not easy for the responder to make sure that the > > response has been arrived at the source peer reliability. But could you > > share with me how the recursive mode achieves this goal? IMHO, the state is > > also unavoidable in recursive mode if you realize it by keeping state at > > intermediate peer. > > > > The reload-02 messages keep the state in the message itself (the > via/route list). Could you ensure when the response is forward back on the reverse path, all peers in via or route list did not fail or leave the overlay simultaneously? IMHO, if any one in the list fails or leaves the overlay, the recursive routing will fail. We should consider churn in P2P network while designing peer protocol, after all churn is nature of P2P network. >Retransmission is handled end-to-end. So the > responder still doesn't have a way of knowing for sure if the response > got back, but it can assume that it was just random packet loss and > keep sending the response whenever it gets a retransmission until the > sender receives it. Due to the same reason as above, we should consider the possible loss from overlay churn, not only just assume it is a random packet loss. There is another issue I am also interested: how do the RELOAD-2 determine the end-to-end timeout period? > If you try to send it back directly, the > responder has to have some heuristic like if it sends the response > back twice and then receives a third retransmission, there must be a > nat or firewall issue. To be honest, I am not totally understood. Could you give more explanations? Thanks! _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 22:15:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv2XB-0002N4-Ef; Wed, 21 Nov 2007 22:15:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv2XA-0002IT-27 for p2psip@ietf.org; Wed, 21 Nov 2007 22:15:20 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv2X8-0004UZ-U9 for p2psip@ietf.org; Wed, 21 Nov 2007 22:15:20 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2028169rvb for ; Wed, 21 Nov 2007 19:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=NCGR3I/QdYsVFgHZkVcHq2/x5UcRtv1LWPmDJYPgK0U=; b=PjWsIbrtNK7i3t7wc5NVVf8Z1UO2cKOxLoJ7fcdIJrcD5jS+pIF5Bqfm4IPy9j5VndBrDfEleWCWuQbPEKhFjeYurdzpfeC81Ea74QqXyheEVGc5KqwO1xBzOTZOBkwhfJR0NhIgS4jGuv2ZYMLblwzeCplqyyIEltaudONrf1k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Fe9ekeW0JxDm1KJ3G20aCRj7oY4Pmg3pRv1KQQMjo5DHqtELQ2np1vAIWjhLnERydJ0ZWG42qE27WaEoo3zRaDzI+F89nVTmD57ctfVtXzRfDCUbqddE1fzRmhf7KOPsrnCPxuiVADsT87CX/etqVWhkVDVi+p1QeadVWRm6RJc= Received: by 10.140.180.13 with SMTP id c13mr3334254rvf.1195701315163; Wed, 21 Nov 2007 19:15:15 -0800 (PST) Received: by 10.141.177.20 with HTTP; Wed, 21 Nov 2007 19:15:15 -0800 (PST) Message-ID: <7b683f3f0711211915r1749052fge6844826354ee11@mail.gmail.com> Date: Wed, 21 Nov 2007 22:15:15 -0500 From: "Eunsoo Shim" To: "Henry Sinnreich" Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com> <003001c82be2$e7914640$6905a40a@china.huawei.com> <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 21, 2007 2:40 PM, Henry Sinnreich wrote: > A. Client Rationale > =================== > > > Why would being in the overlay be a bad influence? > > A mobile client is more likely to change its IP address and thus force a > new stabilization process (Chord terminology) every time in the overlay. A good point! > > B. Who Can Be A Peer > ==================== > > The more reasons we allow to cause a node to be a client rather than a > > > peer > > Which nodes can declare themselves a peer and which are (mobile) clients > is a matter of policy by the overlay operator. > > The nodes that can declare themselves a peer, within policy, will need > to meet certain criteria such as: > > - Some security checks (which is TBD) > - NAT traversal scenario says it's behind no NAT or p2p-friendly NAT > - BW as seen by the node. > Again a good point! > This topic (B.) deserves a memo written by a design team with input from > looking first at the existing p2p networks; and there are plenty of > them. > > My two cents, > > Henry > Thanks. Eunsoo > > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com] > Sent: Wednesday, November 21, 2007 9:39 AM > To: JiangXingFeng > Cc: Philip Matthews; P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > On Nov 20, 2007 9:04 PM, JiangXingFeng wrote: > > > This is too general a statement. > > > It is true that a Client may implement/provide a service. > > > But same for a Peer. > > > Whether a node becomes a Peer or a Client is independent of whether > it > > > provides a particular service other than routing of overlay messages > > > and maintaining the overlay. > > I agree with you that the role of peers or clients is independent of > the > > services what they intends to provide. What I really suggest is that > if a > > node wants to provide service, acting as a client may be better than > acting > > as peer, so that it could avoid the influence from the overlay. This > is a > > reason why we need a client. > > To me, this argument seems completely backward from what I think makes > sense for a client. The only good reason for a client I've heard is > that it has some limited capacity and/or bandwidth. If the capacity or > bandwidth is limited, it seems it would *not* be a good choice to > offer services. > > Why would being in the overlay be a bad influence? > > Personally, I really don't like the direction this is going, if we say > that offering a service is a good reason not to be a peer. One of the > biggest problems with P2P is everyone wanting to be a client and not > participate in the overlay. If a device has enough bandwidth or power > to offer services, then it *definitely* should be a peer. The more > reasons we allow to cause a node to be a client rather than a peer, > the less peers, which means those need to be very powerful, and it > will be painful to be one, so they will want to be clients, so there > will be less peers....it spirals. > > If it can possibly be a peer, I think it should be... > > David (as individual) > > > > > Regards! > > > > JiangXingFeng > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 21 22:18:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv2aB-00007A-IF; Wed, 21 Nov 2007 22:18:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv2a9-000070-I0 for p2psip@ietf.org; Wed, 21 Nov 2007 22:18:25 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv2a6-0004cx-AN for p2psip@ietf.org; Wed, 21 Nov 2007 22:18:25 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRW00DYX156RI@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 11:17:30 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRW000OC156FH@szxga02-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 11:17:30 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRW00CWB1551Y@szxml04-in.huawei.com> for p2psip@ietf.org; Thu, 22 Nov 2007 11:17:30 +0800 (CST) Date: Thu, 22 Nov 2007 11:17:29 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> To: "'David A. Bryan'" Message-id: <000001c82cb6$37125f00$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Thread-index: AcgsVKP5G9nc1cblRrmE8NQHeRcHPAAYKYcw X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > Why would being in the overlay be a bad influence? Here, what I really concerns is the security threat arising from the role of peer. It is hard to realize high level security in P2P situation. The peer may at the risk of several kinds of DoS attack which will influence the service provided by the node. Maybe I did not express clearly. The nodes which provide service may be deployed by operators to provide better performance and stability of the overlay. The operator could reuse existing security methods to protect the nodes and keep them stable as long as possible. Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 22 08:38:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCFy-0002zo-Nl; Thu, 22 Nov 2007 08:38:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCFw-0002qS-OG for p2psip@ietf.org; Thu, 22 Nov 2007 08:38:12 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-08.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvCFw-0006w6-Fm for p2psip@ietf.org; Thu, 22 Nov 2007 08:38:12 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IvCFu-00011z-2k; Thu, 22 Nov 2007 08:38:10 -0500 In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com><003001c82be2$e7914640$6905a40a@china.huawei.com> <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Thu, 22 Nov 2007 08:39:34 -0500 To: Henry Sinnreich X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > The nodes that can declare themselves a peer, within policy, will need > to meet certain criteria such as: > > - Some security checks (which is TBD) > - NAT traversal scenario says it's behind no NAT or p2p-friendly NAT > - BW as seen by the node. Work by various people has shown how to almost completely eliminate the second criteria so that even nodes behind NATs with endpoint- dependent mapping can fully participate as peers. I am less qualified to comment on the first, but wonder whether a node that is considered a security risk should be allowed to join the overlay as a client (whatever that means). - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 22 08:48:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCPh-0001TC-Ks; Thu, 22 Nov 2007 08:48:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCPg-0001T6-Nx for p2psip@ietf.org; Thu, 22 Nov 2007 08:48:16 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-07.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvCPg-0007Gj-DV for p2psip@ietf.org; Thu, 22 Nov 2007 08:48:16 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-07.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IvCPa-0005ZL-0e; Thu, 22 Nov 2007 08:48:11 -0500 In-Reply-To: <7b683f3f0711211915r1749052fge6844826354ee11@mail.gmail.com> References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com> <003001c82be2$e7914640$6905a40a@china.huawei.com> <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> <7b683f3f0711211915r1749052fge6844826354ee11@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Thu, 22 Nov 2007 08:49:41 -0500 To: Eunsoo Shim X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >> >> A mobile client is more likely to change its IP address and thus >> force a >> new stabilization process (Chord terminology) every time in the >> overlay. Using any of the HIP-inspired techniques in a make-before-break scenario (= where a node gains a new address before losing its old address), this does not seem to be necessarily true. It seems quite possible to keep all connections up through an address transition. In fact, I see this as one of the big advantages of the HIP-inspired techniques for P2PSIP. The situation for break-before-make is still under investigation. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 22 08:49:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCQq-0001mh-Dk; Thu, 22 Nov 2007 08:49:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCQo-0001mN-TF for p2psip@ietf.org; Thu, 22 Nov 2007 08:49:26 -0500 Received: from maill.telecomitalia.it ([217.169.121.52]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvCQo-0007In-BT for p2psip@ietf.org; Thu, 22 Nov 2007 08:49:26 -0500 Received: from ptpxch008rm001.idc.cww.telecomitalia.it ([156.54.205.170]) by maill.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 14:49:17 +0100 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch008rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 14:49:17 +0100 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 14:49:15 +0100 Message-ID: <47458927.8060608@telecomitalia.it> Date: Thu, 22 Nov 2007 14:50:31 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com><003001c82be2$e7914640$6905a40a@china.huawei.com> <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> In-Reply-To: X-OriginalArrivalTime: 22 Nov 2007 13:49:15.0154 (UTC) FILETIME=[7852BF20:01C82D0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Henry Sinnreich , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1643373097==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1643373097== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080802040709080703060800" This is a cryptographically signed message in MIME format. --------------ms080802040709080703060800 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Philip Matthews wrote: >> The nodes that can declare themselves a peer, within policy, will need >> to meet certain criteria such as: >> >> - Some security checks (which is TBD) >> - NAT traversal scenario says it's behind no NAT or p2p-friendly NAT >> - BW as seen by the node. > > > Work by various people has shown how to almost completely eliminate the > second criteria so that even nodes behind NATs with endpoint-dependent > mapping can > fully participate as peers. Well, probably they can, but, as long as bandwidth is the most scarce resource, they are not only useless, but also harmfull to the overlay as they require other peers to relay all their traffic. Clearly, it would be much better if they were behind NATs with endpoint-dependent filtering, but endpoint-independent mapping... -- Ciao, Enrico --------------ms080802040709080703060800 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcxMTIyMTM1MDMxWjAjBgkqhkiG9w0BCQQxFgQUijF/9Gh/ Ogxp/zFgQ146ohbTURYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAGDHoxfen9CSPVhOMG7Z55L9iqqF9ZWxbGakULHrNe2/CJvdB205wspe nwTQpzLvHXZyGB/JJiu44/Vv/ZYtQdxmBj0MRJ5z5Re0J9aPA1lKh9ONxoTY58/MnHUN/dxp fK8SldzXhjA9Zx+CaWC4TA3MOkGYiAWsf1DWW8aIHfxcylutfcw0aIha0UN8KKC0Rg9YIeKM OXNdVa4+D0OeGGj9YcK2p0gOYLeO8giU5UEqdy+F9LyFcHBKt7nIsLdkRxZiLa1Sisrrs65d /F1WtG08shrofpg/QyO/x7MuU05UejHIQju2j9iOQVXeN3DdIkn+0XK3sGrdxdqm7nKjG7sA AAAAAAA= --------------ms080802040709080703060800-- --===============1643373097== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1643373097==-- From p2psip-bounces@ietf.org Thu Nov 22 08:58:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCZV-0001Yv-ER; Thu, 22 Nov 2007 08:58:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCZU-0001W0-Aa for p2psip@ietf.org; Thu, 22 Nov 2007 08:58:24 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCZQ-0001E7-8p for p2psip@ietf.org; Thu, 22 Nov 2007 08:58:24 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BD93828000352; Thu, 22 Nov 2007 14:58:19 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id owwdj+Z9n8kG; Thu, 22 Nov 2007 14:58:19 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9F57228000304; Thu, 22 Nov 2007 14:58:09 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Merge of ASP and RELOAD - Version Notificationfordraft-bryan-p2psip-reload-02 Date: Thu, 22 Nov 2007 14:58:09 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD6960193DC01@mx1.office> In-Reply-To: <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Merge of ASP and RELOAD - Version Notificationfordraft-bryan-p2psip-reload-02 Thread-Index: AcgridT7wsttGn6STke6cBOYW9wpvQBdOnNA References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office><20071120151620.D1F2533C21@delta.rtfm.com> <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> From: "Jan Seedorf" To: "David A. Bryan" X-Spam-Score: 1.8 (+) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear David, you raise a very interesting point here. Replication done by the root node serves the purpose of redundancy to = protect against node failure (of the root node) but does not protect = against the root node being adversary. Replication done by the storing = node serves the purpose of having the resource-ID available even if the = root is adversary but may fail to provide redundancy against node = failures. I agree: to have both, a hybrid solution is needed. The storing node = selects the initial replica roots and these again replicate content to = protect against node failure. How to do this in detail is very = DHT-protocol specific and probably not trivial. - Jan > -----Original Message----- > From: David A. Bryan [mailto:dbryan@sipeerior.com]=20 > Sent: Tuesday, November 20, 2007 4:27 PM > To: Eric Rescorla > Cc: p2psip@lists.ietf.org; Jan Seedorf > Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version=20 > Notificationfordraft-bryan-p2psip-reload-02 >=20 > One problem with having the just the source place the=20 > replicas is what happens when the source is offline. >=20 > For example, I am the source. I send out the data to the=20 > original and the replica. Then log off. >=20 > If one peer fails, then that replica is gone for good unless=20 > I come back up to refresh them, so over time, offline=20 > information could "decay" in the presence of a slow peer failure rate. >=20 > Some sort of hybrid might make more sense...but there is=20 > (clearly) a security point that needs to be considered here. >=20 > David (as individual) >=20 >=20 > On Nov 20, 2007 10:16 AM, Eric Rescorla=20 > wrote: > > At Tue, 20 Nov 2007 14:57:28 +0100, > > Jan Seedorf wrote: > > > Dear authors of the new RELOAD draft (02), I have some=20 > comments on=20 > > > the security section: > > > > > > section 7.3. it is specified that the root-node of some=20 > resource ID =20 > > > (i.e., the node responsible for storing the resource) is =20 > > > responsible for replication. In section 10.5.4. "residual attacks" > > > you mention that a query node can check at replica roots=20 > for some =20 > > > resource if the root-node does not respond. I see the following =20 > > > security problem: if the root-node is originally faulty=20 > at storage =20 > > > time (e.g., compromised), it will likely store invalid (though > > > detectable) or no resources at all at the replica roots. As you =20 > > > well describe the only issue here is availability.=20 > However, I think =20 > > > that any countermeasure involving replication must involve =20 > > > distributed storage done by the query node itself (for reasons =20 > > > described above). Replication should not be the=20 > responsibility of =20 > > > the root-node. > > > > Yeah, this is sort of a thinko in our writeup. We intend to move to=20 > > explicit writes to each replica by the storing node and=20 > just ran out=20 > > of pre-draft time :) > > > > > > > Section 10.6.1.: You assume a central authority and indeed this=20 > > > solves many security problems. It limits Sybil attacks=20 > and Eclipse=20 > > > attacks. This is well-described in the draft. However, there are=20 > > > other attacks on DHT routing. Join-leave attacks can be=20 > used by the=20 > > > attacker to chose its location in the DHT despite a=20 > central node-ID=20 > > > assignment authority (see C. Scheideler, "How to Spread=20 > Adversarial=20 > > > Nodes?: Rotate!," Proc. 37th Annual ACM Symp. Theory of Comp.,=20 > > > Baltimore, MD,pp. 704-13, for a formal analysis of the node-ID=20 > > > assignment problem in DHTs and join-leave attacks). Additionally,=20 > > > even if there are no Sybil or Eclipse attacks, adversary nodes=20 > > > (though well certified through the admission authority, e.g.,=20 > > > because they have been compromised) can simply drop=20 > messages. This=20 > > > severely degrades the lookup success rate in a DHT.=20 > Countermeasures=20 > > > against these attacks may well be out-of-scope for P2PSIP=20 > > > standardisation, I just feel the section is misleading in=20 > the sense=20 > > > that it suggests that a central authority protects against all=20 > > > threats on DHT routing. > > > > I agree tha there are significant residual attacks. We'll=20 > see whwat=20 > > we can do to make this text clearer. IF you wanted to suggest some=20 > > text that would be great. > > > > Thanks, > > -Ekr > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > >=20 >=20 >=20 > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com >=20 > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 22 09:04:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCez-0002OP-ET; Thu, 22 Nov 2007 09:04:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvCex-0002OE-VV for p2psip@ietf.org; Thu, 22 Nov 2007 09:04:03 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-08.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvCeu-0001R9-H8 for p2psip@ietf.org; Thu, 22 Nov 2007 09:04:03 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1IvCeu-0003r8-0m; Thu, 22 Nov 2007 09:04:00 -0500 In-Reply-To: <47458927.8060608@telecomitalia.it> References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com><003001c82be2$e7914640$6905a40a@china.huawei.com> <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> <47458927.8060608@telecomitalia.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B536034-219E-437E-9D68-6E2A75AAA961@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior Date: Thu, 22 Nov 2007 09:05:29 -0500 To: Enrico Marocco X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 22-Nov-07, at 08:50 , Enrico Marocco wrote: > Philip Matthews wrote: >>> The nodes that can declare themselves a peer, within policy, will >>> need >>> to meet certain criteria such as: >>> >>> - Some security checks (which is TBD) >>> - NAT traversal scenario says it's behind no NAT or p2p-friendly NAT >>> - BW as seen by the node. >> >> >> Work by various people has shown how to almost completely >> eliminate the >> second criteria so that even nodes behind NATs with endpoint- >> dependent >> mapping can >> fully participate as peers. > > Well, probably they can, but, as long as bandwidth is the most scarce > resource, they are not only useless, but also harmfull to the > overlay as > they require other peers to relay all their traffic. > > Clearly, it would be much better if they were behind NATs with > endpoint-dependent filtering, but endpoint-independent mapping... We know how to set up a direct connection without a relay between a node X behind a NAT with address-and-port-dependent mapping and filtering and a node Y behind a NAT with endpoint-independent mapping and address-dependent filtering. A small number of nodes like X are not really a problem in an overlay. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 22 09:31:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvD5t-0007jo-30; Thu, 22 Nov 2007 09:31:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvD5r-0007gX-82 for p2psip@ietf.org; Thu, 22 Nov 2007 09:31:51 -0500 Received: from mailm.telecomitalia.it ([217.169.121.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvD5n-0002Eb-Dq for p2psip@ietf.org; Thu, 22 Nov 2007 09:31:51 -0500 Received: from ptpxch007rm001.idc.cww.telecomitalia.it ([156.54.205.169]) by mailm.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 15:31:03 +0100 Received: from ptpxch006rm001.idc.cww.telecomitalia.it ([156.54.205.168]) by ptpxch007rm001.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 15:31:03 +0100 Received: from [127.0.0.1] ([163.162.180.246]) by ptpxch006rm001.idc.cww.telecomitalia.it over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 15:31:02 +0100 Message-ID: <474592F6.7010006@telecomitalia.it> Date: Thu, 22 Nov 2007 15:32:22 +0100 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.6 (X11/20071009) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior References: <7b683f3f0711200329s874e4e4x821ac428cc52a32e@mail.gmail.com><003001c82be2$e7914640$6905a40a@china.huawei.com> <4d4304a00711210739x34aa762bo7fe60dcaf83bb14c@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE31F@namail5.corp.adobe.com> <47458927.8060608@telecomitalia.it> <2B536034-219E-437E-9D68-6E2A75AAA961@magma.ca> In-Reply-To: <2B536034-219E-437E-9D68-6E2A75AAA961@magma.ca> X-OriginalArrivalTime: 22 Nov 2007 14:31:02.0527 (UTC) FILETIME=[4ED580F0:01C82D14] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0998143519==" Errors-To: p2psip-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0998143519== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090600000801090605000708" This is a cryptographically signed message in MIME format. --------------ms090600000801090605000708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Philip Matthews wrote: >>>> The nodes that can declare themselves a peer, within policy, will need >>>> to meet certain criteria such as: >>>> >>>> - Some security checks (which is TBD) >>>> - NAT traversal scenario says it's behind no NAT or p2p-friendly NAT >>>> - BW as seen by the node. >>> >>> >>> Work by various people has shown how to almost completely eliminate the >>> second criteria so that even nodes behind NATs with endpoint-dependent >>> mapping can >>> fully participate as peers. >> >> Well, probably they can, but, as long as bandwidth is the most scarce >> resource, they are not only useless, but also harmfull to the overlay as >> they require other peers to relay all their traffic. >> >> Clearly, it would be much better if they were behind NATs with >> endpoint-dependent filtering, but endpoint-independent mapping... > > We know how to set up a direct connection without a relay between a node X > behind a NAT with address-and-port-dependent mapping and filtering and a > node Y behind > a NAT with endpoint-independent mapping and address-dependent filtering. > > A small number of nodes like X are not really a problem in an overlay. The obvious point is how small is small enough. In many cases an overlay maintained by a selection of available nodes performs much better than one where all are always involved; I don't want to take part in the discussion of what clients, peers and user agents are, but I really hope we don't try to avoid an overlay from being participated only by a subset of all possible peers. -- Ciao, Enrico --------------ms090600000801090605000708 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ4zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNMMIICtaADAgECAhA93pW98AVSLKZipzI5De0E MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNzAzMjkxNTAyNTVaFw0wODAzMjgxNTAyNTVaMHoxHzAdBgNVBAMTFlRo YXd0ZSBGcmVlbWFpbCBNZW1iZXIxLjAsBgkqhkiG9w0BCQEWH2Vucmljby5tYXJvY2NvQHRl bGVjb21pdGFsaWEuaXQxJzAlBgkqhkiG9w0BCQEWGGVucmljby5tYXJvY2NvQGdtYWlsLmNv bTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALaNEnc2tIvvdDv1eOEaoTRKfQ9V C7AIlpPaGqPQsyZ1pnGe8dHLmsucl9RAvlft1Pl4FCKodpuSuPn/fWINHExh+GaAvUnGiIIP 1Jk+jm3/Wd0tJByGRgf6Aouk6rLKTE5v/BFldbCdSpdT/1htx5ME9aoYxQ/Vg/CU+X7rTPCR 5tFF8nOEqiFCUFcI9zxy4nfetgUpoomAJwtyX96bYD/ueaKcCMjSaUctpFxy/FRrEalDMQGy v6OzcyugZVUbYxmHoZqUH27vkf+t0DMf4/LEPrfOnJqCAtQbAWSEJJcn6kDGtjTDFs+tbQFv EMqtJhuzIyw4v08o/5paI3Diq1cCAwEAAaNnMGUwDwYDVR0PAQH/BAUDAwf5gDBEBgNVHREE PTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0Bn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQA3J5m3GoDt0TWtO24H GMEX44VbMtvD/e0ZSCPfHQxF347LtbC0yyDtvbioV1mB8joVrj48rGC6/cJxs+xqZ6A1EEUd saeF3T+F8mZh8BYeZo1eqFzgy0ucSJiFJkf38hts/edSqJqFm+CQdP33RVRZ0e0c0Feqoj4h QvoGE5Tx5zCCA0wwggK1oAMCAQICED3elb3wBVIspmKnMjkN7QQwDQYJKoZIhvcNAQEFBQAw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MDMy OTE1MDI1NVoXDTA4MDMyODE1MDI1NVowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1l bWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEn MCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAto0Sdza0i+90O/V44RqhNEp9D1ULsAiWk9oao9CzJnWmcZ7x 0cuay5yX1EC+V+3U+XgUIqh2m5K4+f99Yg0cTGH4ZoC9ScaIgg/UmT6Obf9Z3S0kHIZGB/oC i6TqsspMTm/8EWV1sJ1Kl1P/WG3HkwT1qhjFD9WD8JT5futM8JHm0UXyc4SqIUJQVwj3PHLi d962BSmiiYAnC3Jf3ptgP+55opwIyNJpRy2kXHL8VGsRqUMxAbK/o7NzK6BlVRtjGYehmpQf bu+R/63QMx/j8sQ+t86cmoIC1BsBZIQklyfqQMa2NMMWz61tAW8Qyq0mG7MjLDi/Tyj/mloj cOKrVwIDAQABo2cwZTAPBgNVHQ8BAf8EBQMDB/mAMEQGA1UdEQQ9MDuBH2Vucmljby5tYXJv Y2NvQHRlbGVjb21pdGFsaWEuaXSBGGVucmljby5tYXJvY2NvQGdtYWlsLmNvbTAMBgNVHRMB Af8EAjAAMA0GCSqGSIb3DQEBBQUAA4GBADcnmbcagO3RNa07bgcYwRfjhVsy28P97RlII98d DEXfjsu1sLTLIO29uKhXWYHyOhWuPjysYLr9wnGz7GpnoDUQRR2xp4XdP4XyZmHwFh5mjV6o XODLS5xImIUmR/fyG2z951KomoWb4JB0/fdFVFnR7RzQV6qiPiFC+gYTlPHnMYIDZDCCA2AC AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECED3e lb3wBVIspmKnMjkN7QQwCQYFKw4DAhoFAKCCAcMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDcxMTIyMTQzMjIyWjAjBgkqhkiG9w0BCQQxFgQUkGzirzyz CcIIlQwjj1xigiCBKeYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQB gjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQ dHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB AhA93pW98AVSLKZipzI5De0EMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA93pW98AVSLKZipzI5De0EMA0GCSqG SIb3DQEBAQUABIIBAEZsBmAutozjL+0TuCDTYnswKCW3USqDEO9PX24mRXy0y6JKvOw7toJ2 mRAhGxVW3wrcvaXzW0ghWfHS/9sK26g3F6TNbdQC8BzDwFTthZWRgUQgLFhEwR0FVCCiU5k8 iDSaywECvYsKnGB1e8lbpp5L7lxUlVArwx2trkDaauVRsUMSqXQC0nX5bo6ynDwZgW9UDB+t 3nc54b2/XHya+UiEPkPgC8wLU7VpKtVwgeYcOcmlyCbLARIbMkWP5keOyf3WNjHLcZQ0U5AH m0+Ejd9Lm+6fEmIOF8mKJxna4tevMb3thujqXi8a+xJ93wz+mu47b3xGJblxzl6qD3c/l5QA AAAAAAA= --------------ms090600000801090605000708-- --===============0998143519== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0998143519==-- From p2psip-bounces@ietf.org Thu Nov 22 09:49:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDMh-0007Db-HR; Thu, 22 Nov 2007 09:49:15 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDMf-0007DM-G4 for p2psip@ietf.org; Thu, 22 Nov 2007 09:49:13 -0500 Received: from chip2og54.obsmtp.com ([64.18.13.45]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvDMe-0000uD-Ii for p2psip@ietf.org; Thu, 22 Nov 2007 09:49:13 -0500 Received: from source ([192.150.11.134]) by chip2ob54.postini.com ([64.18.5.12]) with SMTP; Thu, 22 Nov 2007 06:49:04 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAMEklOP015565; Thu, 22 Nov 2007 06:46:52 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAMEmmFZ023570; Thu, 22 Nov 2007 06:48:53 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Nov 2007 23:48:49 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] More thoughts on clients, peers, and services, and service routing Date: Thu, 22 Nov 2007 06:48:46 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE326@namail5.corp.adobe.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] More thoughts on clients, peers, and services, and service routing Thread-Index: AcgsinSh7HRrpKo/RHGT3I+mXM8wSwAil14g References: From: "Henry Sinnreich" To: "Dean Willis" , "P2PSIP Mailing List" X-OriginalArrivalTime: 22 Nov 2007 14:48:49.0652 (UTC) FILETIME=[CAE3DB40:01C82D16] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org These are excellent thoughts and require IMHO not to be solved in the SIP space alone, but in the broader context of p2p.=20 Thanks Dean for stimulating some home work! It includes some research on what the p2p industry (who else is generating all this R&D and Internet traffic?) has done here already. Maybe P2PSIP can reuse some of this work. Henry -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Wednesday, November 21, 2007 4:03 PM To: P2PSIP Mailing List Subject: [P2PSIP] More thoughts on clients, peers, and services,and service routing In the voluminous discussion of the last 36 hours, I think I'm seeing =20 an alternative emerge that I will try and restate. One way to divide the problem space is to differentiate the tasks of =20 "finding", "routing", and "everything else". Several people have proposed that peers exclusively provide "finding =20 and routing" services. Clients use the "finding and routing" services =20 of peers. Both clients and peers can also offer other services, such =20 as STUN relay (although some might say that peers offering other =20 services are acting as clients when they do so). I think this model =20 works fairly well, and it continues in the principle that peers are a =20 superset of clients -- that is, that clients and peers are pretty =20 much similar, but peers do a few things that clients can't. For each =20 service that a client or peer provides, that node would "put" a =20 service entry in to the database, and these services are completely =20 distinct from the nodes role as peer or client Is this the only way to divide the problem? Maybe clients and peers =20 are very different things, neither subsets nor supersets of each other. What if peers deal exclusively with "finding", and we think of =20 message routing as a separate service entirely? In this approach, one could ask a peer "Please store this resource =20 record" or "Please fetch this resource record", but not "Please send =20 this message to alice@example.com". How would this facilitate setting up SIP sessions? Alice might request that the overlay store as a resource record, a =20 route to "alice@example.com", where that route might include not only =20 Alice's "contact", but also hops for nodes that have agreed to serve =20 as relays for sending messages to Alice. This is somewhat analogous =20 to the "path" and "service route" terminology in SIP. We can think of =20 this as a "put" operation against the distributed database. To call Alice, Bob would then simply do a "get" operation, requesting =20 a route to "alice@example.com". He would then use the result as a SIP =20 route vector to send an INVITE request to Alice. Both of these require some sort of convention for constructing the =20 resource-ID for the route record, but that's fairly trivial. The harder parts: How would Alice discover an appropriate vector? And =20 how do we compensate for the fact the ideal route between Bob and =20 Alice might be different than the route between Charlie and Alice? Of course, before Alice can find "routing" nodes in the database, =20 those nodes have to list themselves. Each one might start by finding =20 a primal node (a "routing bootstrap", if you will) and making ICE =20 checks against that node. If they can reach it and it can reach them, =20 they consider themselves "tier-1" nodes, and "put" resource records =20 listing themselves as tier-1 nodes. If not, then they query the =20 database for tier-1 nodes, perform ICE checks against them, and add =20 resource records listing themselves as tier-2 nodes adjacent to the =20 tier-1 nodes which which they have mutual reachability. If they =20 aren't adjacent to any tier-1 nodes, then they repeat for tier-2, =20 then tier-3, and so on. Of course, it would be nice if the =20 distributed database offered some technique for automagically scoping =20 the candidates, but it isn't required for the algorithm to terminate. =20 Optionally, routing nodes could do persistent "outbound"-like =20 bindings with some higher-tier node selected as the most-adjacent =20 node they can reach, thereby either short-circuiting the search =20 process or achieving connectivity across NAT/FW boundaries that block =20 reverse-path checks. One could further short-circuit the process by =20 using broadcast and multicast to find neighbors that have already =20 established their vectors, then copying those vectors rather than =20 finding new ones. Alice might begin by querying the distributed database for nodes =20 offering the "routing" service, thereby obtaining a list of candidate =20 nodes. She might then do something like an ICE-like evaluation to =20 find one or more acceptable candidates, and would select the lowest-=20 tiered node she could reach. Of course it would be nice if the =20 distributed database could help narrow this search, but it isn't =20 absolutely required. Alice would continue working up the tiers until =20 reaching tier-1, then "put" a vector or into the database, where that =20 vector lists Alice's contact plus the URIs of each routing node up to =20 and including her tier-1 contact. Bob, when calling Alice, would "get: her vector, then run a shortest-=20 path calculation between his vector and her vector, then use the =20 result as a SIP route to reach Alice. What we get out of this is a system where the distributed database =20 can be any off-the-shelf DHT (such as OpenDHT), and where SIP =20 messages are routed according to what is in effect a minimum spanning =20 tree calculation against the sip-routing topology of the network. Alternatively, we could do subtree and named-subtree (dynamic =20 aggregation) approaches that would provide absolutely optimal routes =20 but have higher overheads. Think OSPF, but where aggregations (OSPF =20 areas) are defined dynamically vice ICE-like adjacency checks. This is a little different from the current proposals, which seem to =20 require a customized DHT algorithm and and routes messages across =20 that DHT based on the dynamic topology of the DHT itself and is =20 likely to give a much less efficient a route. Of course, the route =20 discovery process (especially in the event of a topology change) is =20 much easier. On the other hand, the DHT topology tells us little or =20 nothing about net-path efficient routing, which is CRITICAL for media-=20 path relay, and the model proposed here would provide much better =20 selection mechanisms for net-path efficient media relays. But haven't we, for all practical purposes, developed a net-path =20 optimized routing database that we bootstrapped into using a =20 conventional DHT? Do we need to reinvent path-efficient routing for =20 messaging, media relay, and every service? Would it have been more =20 efficient just to start with a path-efficient DHT to start with? I =20 don't know yet. I do know that thinking about application-aware =20 routing at Internet scales is giving me a severe head pain, and =20 historically, the complexity of this is why we have the "thin-=20 waisted" routing model of the Internet. I just wished it worked in =20 the real world of NATs and firewalls and other annoying stuff. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 22 10:15:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDmO-0005lJ-2m; Thu, 22 Nov 2007 10:15:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvDmM-0005ag-8E for p2psip@ietf.org; Thu, 22 Nov 2007 10:15:46 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvDmJ-0003od-67 for p2psip@ietf.org; Thu, 22 Nov 2007 10:15:46 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BA73528000353; Thu, 22 Nov 2007 16:15:42 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpmKXZmxNChb; Thu, 22 Nov 2007 16:15:42 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 953FC28000350; Thu, 22 Nov 2007 16:15:22 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 Date: Thu, 22 Nov 2007 16:15:22 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD6960193DC24@mx1.office> In-Reply-To: <4d4304a00711210649o7d305e7dh9dc3e399920532f5@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 Thread-Index: AcgsTcHx7yq+v2pNRYiV/mZIahzIugAwoYEg References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> <20071120151620.D1F2533C21@delta.rtfm.com> <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> <4d4304a00711210649o7d305e7dh9dc3e399920532f5@mail.gmail.com> From: "Jan Seedorf" To: "David A. Bryan" X-Spam-Score: 1.8 (+) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear David, Bruce, and Salman, a couple of thought on this: -- any mechanism on the DHT layer would not prohibit the application = layer to conduct additional replication (as David points out below) -- it may also depend on what layer you have mechanisms to detect = adversary nodes (to intentionally not replicate at adversary nodes). If = this is done at the DHT layer (e.g., by using density checks of the = successor list) this information could be passed on to the application = layer. If you detect adversary nodes at the application layer (e.g., = through timeouts or by cryptographic verification of the content they = provide), only the application layer can use this information for = replication. I thought the WG had decided not to focus on a particular DHT but rather = make P2PSIP use pluggable DHTs. Any mechanism on the DHT layer is very = DHT-protocol specific. Does that not imply that replication on that = layer is out of the scope of the WG? Salman: I think the point raised by David in his other mail was not = _whether_ an operator should ensure that replicas survive node failures = but how this can be done if the source is responsible for replication = (rather a research issue) - Jan > -----Original Message----- > From: amelampus@gmail.com [mailto:amelampus@gmail.com] On=20 > Behalf Of David A. Bryan > Sent: Wednesday, November 21, 2007 3:50 PM > To: Salman Abdul Baset > Cc: Eric Rescorla; p2psip@lists.ietf.org; Jan Seedorf > Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version=20 > Notification fordraft-bryan-p2psip-reload-02 >=20 > Sort of related to this discussion is the open question of=20 > what layer does replication occur? There are several alternatives: >=20 > * Do it on a per-pluggable DHT level. In otherwords, each DHT=20 > that is defined specifies a replication mechanism. This may=20 > be very desirable if someone has a very clever DHT design=20 > with a specific replication scheme, but might remove operator=20 > flexibility and make it difficult for specific applications=20 > to have alternate schemes (although they could layer it on=20 > top of the DHT provided scheme) >=20 > * Do it at the application level instead. Each usage=20 > specifies what replication it would like (how many, where, do=20 > you do source node replication if the source node fails,=20 > etc.) The advantage to this is that it can be much more=20 > tailored for the use of the application, but if one overlay=20 > is supporting multiple usages, then things stored in common=20 > to each usage (maybe the user's public key, for example,=20 > which different applications may want) could conceivably be=20 > replicated in more places than really needed. It also means a=20 > clever DHT replication idea isn't as useful, since there=20 > would still be replication above it at the app level anyway=20 > (although I guess you could just turn off the application=20 > level replication in that case anyway) >=20 > * There might be other options... >=20 > This is definitely a good open issue...I'd love to see a bit=20 > of discussion about what others think the pros and cons are here... >=20 > --David (as individual) >=20 > On Nov 20, 2007 6:43 PM, Salman Abdul Baset=20 > wrote: > > As pointed, the replication mechanisms can be classified as: > > > > 1) Publisher (source) oriented > > 2) Responsible peer (root node) oriented > > > > Both publisher and responsible nodes can determine the node replica=20 > > set, i.e., the list of nodes on which to replicate. In addition to=20 > > security, factors such as churn rate, uptime and load of a=20 > node also=20 > > impact the choice of replica set. > > > > An artifact of using DHTs is that the publisher and=20 > responsible peers=20 > > are generally different. Since nodes churn, the responsible=20 > peer may change. > > In an unstructured (non-DHT) overlay, the publisher node=20 > will likely=20 > > be responsible for determining the replica set. > > > > The question of how many replicas to maintain is best left to the=20 > > overlay operator. As mentioned above, the number of=20 > replicas depends=20 > > on the churn rate, availability guarantees, and security=20 > among others. > > > > The question whether to maintain replicas after source node=20 > fails is=20 > > best left to the overlay operator. > > > > -salman > > > > > > On Tue, 20 Nov 2007, David A. Bryan wrote: > > > > > One problem with having the just the source place the replicas is=20 > > > what happens when the source is offline. > > > > > > For example, I am the source. I send out the data to the original=20 > > > and the replica. Then log off. > > > > > > If one peer fails, then that replica is gone for good=20 > unless I come=20 > > > back up to refresh them, so over time, offline information could=20 > > > "decay" in the presence of a slow peer failure rate. > > > > > > Some sort of hybrid might make more sense...but there is=20 > (clearly) a=20 > > > security point that needs to be considered here. > > > > > > David (as individual) > > > > > > > > > On Nov 20, 2007 10:16 AM, Eric Rescorla=20 > wrote: > > >> At Tue, 20 Nov 2007 14:57:28 +0100, Jan Seedorf wrote: > > >>> Dear authors of the new RELOAD draft (02), I have some=20 > comments on=20 > > >>> the security section: > > >>> > > >>> section 7.3. it is specified that the root-node of=20 > some resource=20 > > >>> ID (i.e., the node responsible for storing the resource) is =20 > > >>> responsible for replication. In section 10.5.4.=20 > "residual attacks" > > >>> you mention that a query node can check at replica=20 > roots for some =20 > > >>> resource if the root-node does not respond. I see the=20 > following =20 > > >>> security problem: if the root-node is originally faulty=20 > at storage =20 > > >>> time (e.g., compromised), it will likely store invalid (though > > >>> detectable) or no resources at all at the replica=20 > roots. As you =20 > > >>> well describe the only issue here is availability. However, I=20 > > >>> think that any countermeasure involving replication=20 > must involve =20 > > >>> distributed storage done by the query node itself (for reasons =20 > > >>> described above). Replication should not be the=20 > responsibility of =20 > > >>> the root-node. > > >> > > >> Yeah, this is sort of a thinko in our writeup. We intend=20 > to move to=20 > > >> explicit writes to each replica by the storing node and just ran=20 > > >> out of pre-draft time :) > > >> > > >> > > >>> Section 10.6.1.: You assume a central authority and indeed this=20 > > >>> solves many security problems. It limits Sybil attacks=20 > and Eclipse=20 > > >>> attacks. This is well-described in the draft. However,=20 > there are=20 > > >>> other attacks on DHT routing. Join-leave attacks can be used by=20 > > >>> the attacker to chose its location in the DHT despite a central=20 > > >>> node-ID assignment authority (see C. Scheideler, "How to Spread=20 > > >>> Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM=20 > Symp. Theory=20 > > >>> of Comp., Baltimore, MD,pp. 704-13, for a formal=20 > analysis of the=20 > > >>> node-ID assignment problem in DHTs and join-leave attacks).=20 > > >>> Additionally, even if there are no Sybil or Eclipse attacks,=20 > > >>> adversary nodes (though well certified through the admission=20 > > >>> authority, e.g., because they have been compromised) can simply=20 > > >>> drop messages. This severely degrades the lookup=20 > success rate in a=20 > > >>> DHT. Countermeasures against these attacks may well be=20 > > >>> out-of-scope for P2PSIP standardisation, I just feel=20 > the section=20 > > >>> is misleading in the sense that it suggests that a central=20 > > >>> authority protects against all threats on DHT routing. > > >> > > >> I agree tha there are significant residual attacks. We'll see=20 > > >> whwat we can do to make this text clearer. IF you wanted=20 > to suggest=20 > > >> some text that would be great. > > >> > > >> Thanks, > > >> -Ekr > > >> > > >> > > >> > > >> _______________________________________________ > > >> P2PSIP mailing list > > >> P2PSIP@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/p2psip > > >> > > > > > > > > > > > > -- > > > David A. Bryan > > > dbryan@SIPeerior.com > > > +1.757.565.0101 x101 > > > +1.757.565.0088 (fax) > > > www.SIPeerior.com > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > >=20 >=20 >=20 > -- > David A. Bryan > dbryan@SIPeerior.com > +1.757.565.0101 x101 > +1.757.565.0088 (fax) > www.SIPeerior.com >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 01:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvSB5-0008US-C5; Fri, 23 Nov 2007 01:38:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvSB3-0008Jl-7D for p2psip@ietf.org; Fri, 23 Nov 2007 01:38:13 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvSB0-0005Tp-7S for p2psip@ietf.org; Fri, 23 Nov 2007 01:38:13 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRY003QC5247W@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 23 Nov 2007 14:37:16 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRY00K7R524LU@szxga04-in.huawei.com> for p2psip@ietf.org; Fri, 23 Nov 2007 14:37:16 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRY00K2F5236P@szxml03-in.huawei.com> for p2psip@ietf.org; Fri, 23 Nov 2007 14:37:16 +0800 (CST) Date: Fri, 23 Nov 2007 14:37:15 +0800 From: Song Yongchao Subject: RE: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior In-reply-to: <474592F6.7010006@telecomitalia.it> To: 'Philip Matthews' Message-id: <000c01c82d9b$49b1f7c0$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgtFJMQn6lSPqELTl6gUXaNttmiPAAg52og X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > We know how to set up a direct connection without a relay between a > node X behind a NAT with address-and-port-dependent mapping and > filtering and a node Y behind a NAT with endpoint-independent mapping > and address-dependent filtering. As I know, NAT mapping rules and endpoint filtering rules for TCP are somewhat different from that for UDP, and even for TCP, various packet sequences for handshaking are filtered by NATs. Do you mean you can set up a direct connection for all X and Y of that kind you mentioned, or just a subset of that? Best Regards! Song Yongchao _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 02:46:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvTFE-0006f1-AZ; Fri, 23 Nov 2007 02:46:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvTFC-0006ew-QV for p2psip@ietf.org; Fri, 23 Nov 2007 02:46:34 -0500 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvTF8-0006ll-61 for p2psip@ietf.org; Fri, 23 Nov 2007 02:46:34 -0500 Received: by wa-out-1112.google.com with SMTP id k40so4978202wah for ; Thu, 22 Nov 2007 23:46:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:from:to:subject:date:message-id:mime-version:content-type:x-mailer:x-mimeole:in-reply-to:thread-index; bh=MWaBabOJhp5sKuHfy0uB+5AmVtyWF62VGDRDu/sSlow=; b=lNTrKIospIAkG2CRgCqWloQwDWt3Acl0HaPnz0Ar2m9TdOZTLCiO0ZFFPTIDbAahil/R8n7RSTml1O6Uh0/MCUhrBkBgyuXGEF+KlRPNBMIXemzJ/r2OxR28ntUffH6jLEFWQN3JYMSt48QXaflolV8lO4L+4Hszwtg58e8JKN8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:message-id:mime-version:content-type:x-mailer:x-mimeole:in-reply-to:thread-index; b=DfOrtZcnvSxAMnezVAYiyO5nwe2PmUN3GA/cGC/xVQJ9pEQckZ/138vWUcV2KrC2Ct1fp5n64vrmO+ZR05AoUG1dZjD3kBmpxB5k36/3V3RNIPspWaCUcHfPG1DgO18GQtrCc2mDOmQ4ye+PibV1DPMgWNH19I+avvGk/l8gLjQ= Received: by 10.115.14.1 with SMTP id r1mr324951wai.1195803987380; Thu, 22 Nov 2007 23:46:27 -0800 (PST) Received: from mlifewangyao ( [123.116.128.59]) by mx.google.com with ESMTPS id l36sm3284220waf.2007.11.22.23.46.24 (version=SSLv3 cipher=RC4-MD5); Thu, 22 Nov 2007 23:46:27 -0800 (PST) From: "Yao Wang" To: "'P2PSIP Mailing List'" Date: Fri, 23 Nov 2007 15:47:25 +0800 Message-ID: <013401c82da5$19ee4ac0$9a00a8c0@mlifewangyao> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0135_01C82DE8.28118AC0" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acgnh1iQxWQ7xgHpTOu0fL+WiRNK5AGGz3Xw X-Spam-Score: 0.0 (/) X-Scan-Signature: ec9c506f029e38d2a6e7b00bc7714181 Subject: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: To those interested in P2PSIP clients) X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0135_01C82DE8.28118AC0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, everyone. The attachment is a new I-D mainly talking about different types of = nodes in P2PSIP.=20 This document is an attempt to classify different types of node in = peer-to-peer Session Initiation Protocol (P2PSIP). Four possible types = of nodes in P2PSIP are discussed based on two characters: whether it = offers overlay-routing services and whether it offers storage functions. = The behaviors of each type of nodes and their possible necessities are = analyzed. This document is dedicated to be a reference for clarifying = some controversial terms in P2PSIP working group, such as "client", = "low-function peer", etc.=20 It is hoped that this document could help the WG to reach a rough = consensus on the types of node within P2PSIP system and the characters = of each type's behavior. Because the IETF Internet-Draft Submission is closed right now, I have = to send it as attachment to this maillist. This document will be = submitted to IETF as soon as IETF Internet-Draft Submission reopened. :) Sincerely yours, =20 Yao Wang=20 Mobile Life and New Media Lab, BUPT -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Thursday, November 15, 2007 9:00 PM To: P2PSIP Mailing List Subject: [P2PSIP] To those interested in P2PSIP clients A word of advice to all those interested in P2PSIP clients: Please write an internet-draft saying why you want clients. State the =20 problem(s) that clients solve that peers do not. More specifically: * Describe a problem that you want to solve using clients. * Present a convincing argument why that problem is interesting. * Present a convincing argument why that problem cannot be solved =20 using peers. DO NOT go into the technical minutia of a client protocol. Just focus =20 on convincing people that the problem is worthwhile solving and that =20 some model of clients would be the best way to solve it. The WG chairs requested this document at the Prague meeting in the =20 spring, but I have yet to see it. - Philip PS. If someone thinks a recently posted draft meets this criteria, =20 then I would appreciate a pointer to it. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_0135_01C82DE8.28118AC0 Content-Type: text/plain; name="draft-li-p2psip-node-types-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-li-p2psip-node-types-00.txt" =0A= =0A= =0A= P2PSIP Working Group L Ch. Li=0A= Internet-Draft Y. Wang=0A= Intended status: Informational BUPT=0A= Expires: May 25, 2008 November 22, 2007=0A= =0A= =0A= Different types of nodes in P2PSIP=0A= draft-li-p2psip-node-types-00=0A= =0A= Status of this Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on May 25, 2008.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The IETF Trust (2007).=0A= =0A= Abstract=0A= =0A= This document is an attempt to classify different types of node in=0A= peer-to-peer Session Initiation Protocol (P2PSIP). Four possible=0A= types of nodes in P2PSIP are discussed based on two characters:=0A= whether it offers overlay-routing services and whether it offers=0A= storage functions. The behaviors of each type of nodes and their=0A= possible necessities are analyzed. This document is dedicated to be=0A= a reference for clarifying some controversial terms in P2PSIP working=0A= group, such as "client", "low-function peer", etc.=0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 1]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3=0A= 2. Types of Nodes . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2.1. Possible types of nodes . . . . . . . . . . . . . . . . . 3=0A= 2.2. Naming of different types . . . . . . . . . . . . . . . . 4=0A= 3. Type B Node . . . . . . . . . . . . . . . . . . . . . . . . . 4=0A= 4. Type C Node . . . . . . . . . . . . . . . . . . . . . . . . . 5=0A= 5. Type D Node (Client) . . . . . . . . . . . . . . . . . . . . . 6=0A= 5.1. P2P Client . . . . . . . . . . . . . . . . . . . . . . . . 6=0A= 5.2. Non-P2P Client . . . . . . . . . . . . . . . . . . . . . . 7=0A= 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 8=0A= 6.1. Reference Model . . . . . . . . . . . . . . . . . . . . . 9=0A= 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10=0A= 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10=0A= 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10=0A= 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11=0A= 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11=0A= 10.2. Informative References . . . . . . . . . . . . . . . . . . 11=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11=0A= Intellectual Property and Copyright Statements . . . . . . . . . . 12=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 2]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= 1. Introduction=0A= =0A= In IETF P2PSIP WG, the discussion on the term "client" and its=0A= possible behavior has lasted for a long time. But there is still no=0A= consensus on the roles and behaviors of non-peer nodes until now.=0A= =0A= To clarify these concepts, based on two fundamental services provided=0A= by P2P overlay, which are overlay-routing and storage, we try to=0A= classify different node types within P2PSIP. For each type of nodes,=0A= their role and behavior are described firstly; then the necessity of=0A= such node is explored. Because not all the node types are necessary,=0A= for the node types that can be merged into other types, our arguments=0A= are presented.=0A= =0A= This document is dedicated to be a reference for clarifying some=0A= controversial terms in P2PSIP WG, such as "client", "low-function=0A= peer", etc. It is hoped that this document could help the WG to=0A= reach a rough consensus on the types of node within P2PSIP system and=0A= the characters of each type's behavior.=0A= =0A= Many points and arguments in this document originate from the=0A= discussions in the P2PSIP maillist and related Internet-Drafts. The=0A= authors of this document appreciate the contributions that are made=0A= by the people who joined in the related discussions.=0A= =0A= 1.1. Requirements Language=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in RFC 2119 [RFC2119].=0A= =0A= =0A= 2. Types of Nodes=0A= =0A= 2.1. Possible types of nodes=0A= =0A= According to [I-D.ietf-p2psip-concepts], P2PSIP overlay provides=0A= distributed database function and distributed transport function for=0A= SIP and other applications. In P2PSIP overlay, peers offer storage=0A= and transport services to allow the distributed database function and=0A= distributed transport function to be implemented. Other types of=0A= nodes MAY exist in P2PSIP.=0A= =0A= Based on the functionalities provided by P2P overlay, say capability=0A= of storage and transport services, nodes in P2PSIP can be divided=0A= into four types as follow:=0A= =0A= =0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 3]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= o Type A Nodes: nodes offering storage and transport services.=0A= =0A= o Type B Nodes: nodes offering transport services but NOT offering=0A= storage services.=0A= =0A= o Type C Nodes: nodes offering storage services but NOT offering=0A= transport services.=0A= =0A= o Type D Nodes: nodes NEITHER offering storage NOR offering=0A= transport services, only using these services.=0A= =0A= In all these types, Type A nodes have been accepted as "P2PSIP peer"=0A= or "peer" by the P2PSIP WG. Thus, in the following sections, we will=0A= mainly focus on the other three types of nodes.=0A= =0A= 2.2. Naming of different types=0A= =0A= Given that the terms such as "client", "low-function peer" are too=0A= ambiguous, in this subsection the naming of each type of node are=0A= clarified.=0A= =0A= In the client/server computing model, "client" refers to nodes only=0A= using services. In the peer-to-peer computing model, "peer" refers=0A= to the nodes both using services and providing services. Thus, type=0A= A node can be named as "peer", which has been accepted by the P2PSIP=0A= WG. Also type D node can be named "client". For type B and type C=0A= nodes, they will be assigned a suitable name based on the analysis of=0A= their main characters.=0A= =0A= =0A= 3. Type B Node=0A= =0A= Type B nodes refer to the nodes which offer transport functionality=0A= but do not contribute their storage capacity.=0A= =0A= In the current version of [I-D.ietf-p2psip-concepts], such type of=0A= nodes is referred as "peers with bad memory". Some want to call this=0A= type of nodes as "clients", and others view this type of nodes as one=0A= type of "low-function peers". The behavior of type B node is=0A= described as follow.=0A= =0A= (Note: the term "client" in following description is corresponded to=0A= the "type B node" in this document.)=0A= =0A= "A client has a 'peer-ID' and joins the overlay in the same way as a=0A= peer, perhaps establishing the same network of connections that a=0A= peer would. Clients participate in the distributed database=0A= algorithm, and can help in transporting messages to other peers and=0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 4]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= clients. However, the distributed database algorithm does not assign=0A= resource records to clients."=0A= =0A= Despite the roles and behaviors of this type of nodes have been=0A= described above, the authors of this document could not find any=0A= convincing argument on the necessity of defining a separate concept=0A= for this type of nodes. If such type of node can "join the overlay=0A= in the same way as peer" and "help in transporting messages to other=0A= peers and clients", it should be recognized as "non-storage peer"=0A= rather than "client".=0A= =0A= =0A= 4. Type C Node=0A= =0A= Type C nodes refer to the nodes which contribute their storage=0A= functionality but do not offer transport functions in P2P network.=0A= =0A= There are two ways to view this type of nodes: one is "low-function=0A= peers"; the other is "P2P clients offering storage services".=0A= Compared with the former one, the latter view is accepted by more=0A= people.=0A= =0A= With different views, this type of nodes might behave differently.=0A= "low-function peers" behave more like peers, while "P2P clients=0A= offering storage services" behave more like the P2P clients defined=0A= in the following section. As a "low-function peer", a type C node=0A= should join overlay, and provides storage service almost the same as=0A= peers do. As a "P2P client offering storage service", a type C node=0A= can only provides storage service to its associated peer(s), and the=0A= type C nodes might be transparent to other peers.=0A= =0A= Because type C nodes are not overlay-routing nodes, therefore, it=0A= should not be recognized as some kind of peer. In addition, because=0A= "P2P client offering storage service" doesn't need to join overlay or=0A= need to know the distributed database algorithm using in overlay,=0A= designing and implementing "P2P client offering storage service"=0A= seems to be less complicated. Thus, in this document, the "P2P=0A= client offering storage service" is preferred and type C node is=0A= named as "storage P2P client", which is a special type of P2P client=0A= defined in section 5.1.=0A= =0A= The necessity of storage P2P client contains two facets: the=0A= necessity of P2P client, the necessity of storage service. There is=0A= no reason to forbid P2P client from providing storage service. And=0A= these storage services can enlarge the capacity of storage of the=0A= overlay. The necessity of P2P client will be discussed in section=0A= 5.1.=0A= =0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 5]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= 5. Type D Node (Client)=0A= =0A= Type D nodes refer to the nodes which neither offer transport=0A= functionality nor contribute their storage capacities. In this=0A= document, these nodes are named as "client".=0A= =0A= Based on the way to access the distributed database function and=0A= distributed transport function provided by overlay, clients (Type D=0A= nodes) can be divided into two categories, P2P client and non-P2P=0A= client. A P2P client use one or more peers as its associated peer(s)=0A= to access these functions; they can directly execute operations such=0A= as PUT, GET, with the help of its associated peer. Non-P2P client=0A= access these functions indirectly through application entities=0A= residing in peers or P2P clients; for example, a SIP UA has to use=0A= SIP proxies coupled with peers to register itself into P2PSIP=0A= overlay.=0A= =0A= 5.1. P2P Client=0A= =0A= The behavior of P2P clients mainly contains three aspects. Firstly,=0A= they comply with the common behavior of type D node; that is to say,=0A= they neither join the P2P overlay nor contribute the overlay-routing=0A= functionalities. Secondly, they are aware of P2P overlay and can=0A= execute operations such as PUT and GET via its associated peer to=0A= insert a resource into P2P overlay or retrieve it from P2P overlay.=0A= Finally, they can be coupled with any application entities. For=0A= example, a P2PSIP application can be coupled with P2P client, using=0A= the P2P operations as an alternative mechanism to [RFC3263].=0A= =0A= Generally speaking, the necessity of P2P client comes from the=0A= heterogeneity among the nodes which want to use services provided by=0A= P2P overlay. The heterogeneity is explained in different aspects in=0A= the following paragraphs.=0A= =0A= Firstly, the heterogeneity of P2P overlay algorithm makes P2P Client=0A= necessary. For example, a P2PSIP node which only supports Chord=0A= algorithm, needs to access services of P2PSIP overlay which uses=0A= Bamboo DHT. Due to the incompatible P2P algorithms, the Chord-based=0A= node can not join in the Bamboo-based DHT overlay. Thus the Chord-=0A= based node has to work as P2P Client and use the client protocol to=0A= access the services of DHT.=0A= =0A= Secondly, the heterogeneity among P2PSIP nodes also makes P2P Client=0A= necessary. In order to make DHT overlay convergent and efficient,=0A= some kinds of nodes, such as nodes with short online time, nodes with=0A= limited computational resources, etc, are not suitable to join the=0A= overlay. These unqualified nodes can only act as client, using=0A= services provided by P2P overlay to avoid introducing badly churns=0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 6]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= into P2P overlay and (or) making itself overloaded in the maintenance=0A= of P2P overlay.=0A= =0A= The third category of Client candidates comes from the nodes which=0A= want to provide services. For example, a STUN/TURN server wants to=0A= provide services to other nodes in a P2PSIP system. For two reasons,=0A= this server may choose not to join in the P2P overlay. One is for=0A= better performance, that is to say, the computational resources for=0A= P2P maintenance and routing can be saved for better performance of=0A= the service it provided, say STUN/TRUN in this case. The other one=0A= is for safety, i.e. if these nodes act as peer in addition to service=0A= provider, it may be under the extra threats which comes from its peer=0A= role.=0A= =0A= 5.2. Non-P2P Client=0A= =0A= Similar to that of P2P client, the behavior of non-P2P client also=0A= contains three parts. They not only comply with the general behavior=0A= of Type D node, but also can be coupled with any application=0A= entities. The main difference is the way they use storage and=0A= routing services provided by P2P overlay. The non-P2P clients are=0A= using these services via SIP entities or other entities coupled with=0A= peers or P2P clients. Taking the SIP UA for example, because they=0A= are unaware of P2P overlay, they can only use peers or P2P clients=0A= coupled with SIP proxy/registrar to register into P2PSIP system and=0A= establish SIP sessions.=0A= =0A= Although people do not believe this kind of nodes and their protocol=0A= should be within the scope of P2PSIP WG, we argue that these non-P2P=0A= clients are necessary to P2PSIP system. The reasons mainly come from=0A= two aspects.=0A= =0A= Firstly, in some application scenarios, for security or other=0A= considerations, some nodes are not entitled to join overlay and also=0A= are forbidden to access P2P overlay directly. Here is an example.=0A= According to [I-D.bryan-p2psip-app-scenarios], one possible=0A= application scenario is "P2P for Redundant SIP Proxies". Under such=0A= circumstances, to ensure the security of P2P network formed by SIP=0A= proxies, the operator who deployed these SIP proxies will not allow=0A= user nodes join the overlay and act as peers. In addition, for the=0A= safety of data stored in the overlay, the user nodes would not be=0A= allowed to directly use the PUT, GET or other functions of the P2P=0A= overlay either. Therefore, these user nodes have to act as non-P2P=0A= client.=0A= =0A= Secondly, for the compatibility with the existing SIP devices, the=0A= non-P2P client should exist in P2PSIP system. These non-P2P aware=0A= SIP clients can neither join in P2PSIP overlay nor access the P2P=0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 7]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= services by using client protocol. However, for smooth evolution of=0A= P2PSIP, these SIP clients should be taken into consideration at the=0A= beginning of P2PSIP's commercial deployment. Therefore, the=0A= compatibility with traditional SIP [RFC3261] is indispensable. Non-=0A= P2P client may be the only suitable role for these non-P2P aware SIP=0A= clients.=0A= =0A= =0A= 6. Summary=0A= =0A= Based on the description of behaviors of different node types and=0A= analysis on the necessity of each type, we propose the concept of=0A= P2PSIP peer (Type A node, MAY include Type B node), storage P2P=0A= client (Type C node), P2P client (Type D nodes) and non-P2P client=0A= (Type D nodes) should be integrated into the concept of P2PSIP system=0A= and their respective protocols should be taken into consideration in=0A= the process of the standardization of P2PSIP if necessary.=0A= =0A= In these proposed concepts, except P2PSIP peer, all the other types=0A= can be merged into a more general term which is "P2PSIP client".=0A= Currently, the concept of "P2PSIP client" has not been clearly=0A= defined. It is hoped that the WG can reach a rough consensus on=0A= "P2PSIP client" based on the analysis of different roles and=0A= behaviors in P2PSIP system.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 8]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= 6.1. Reference Model=0A= =0A= =0A= =0A= --->PSTN=0A= +------+ +------+ +---------+ /=0A= | UA | | UA | | Gateway |-/=0A= |------|##########|------|#####|---------|########=0A= | Peer | | Peer | | Peer 11 | # P2P=0A= | 9 | | 10 | +---------+ # Client=0A= | | | | # Protocol=0A= +------+ +------+ # |=0A= # # | N=0A= # # | A=0A= # # | T +------+=0A= # +-------------+ v N | UA |=0A= # | STUN SERVER = |=3D=3D=3D=3DA=3D=3D|------|=0A= +------+ P2PSIP Overlay |-------------| T | P2P |=0A= | UA | | Peer 12 | N |Client|=0A= |------| +-------------+ A | 4 |=0A= | Peer | # T +------+=0A= | 8 | #=0A= | | #=0A= +------+ # P2PSIP=0A= # # Peer=0A= # +-------+ +-------+ # Protocol=0A= # | Proxy | | Proxy | #=0A= ##############|-------|########|-------|####### +-------+=0A= | | | | | Proxy |=0A= | Peer 7| | Peer = 6|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|-------|=0A= +-------+ +-------+ P2P |Storage|=0A= | Client | P2P |=0A= | SIP Protocol /|Client |=0A= | / | 3 |=0A= +--------+ +--------+ SIP / +-------+=0A= | UA | | UA |-----/=0A= |--------| |--------|=0A= |non-P2P | |non-P2P |=0A= | Client | | Client |=0A= | 1 | | 2 |=0A= +--------+ +--------+=0A= =0A= =0A= =0A= P2PSIP Network Reference Model=0A= =0A= Figure 1=0A= =0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 9]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= Fig 1 illustrates the architecture of P2PSIP networks. This figure=0A= is mainly based on the "Figure: P2PSIP Overlay Reference Model" in=0A= [I-D.ietf-p2psip-concepts]. In addition, some modifications are made=0A= in order to highlight different types of nodes.=0A= =0A= In Fig 1, each node is separated into two parts. The upper part=0A= describes the application entity/entities coupled with the node;=0A= while the lower part tells the node's type.=0A= =0A= Several peers construct a P2PSIP overlay defined in=0A= [I-D.ietf-p2psip-concepts] using peer protocol. Some peers may=0A= provide extra services, such as STUN/TURN services.=0A= =0A= P2P Clients and storage P2P clients do not join the P2PSIP overlay=0A= but use the distributed database function and distributed transport=0A= function provided by overlay. To access these functions, P2P Clients=0A= and storage P2P clients used P2P client protocol to communicate with=0A= peers. Through P2P client protocol, storage P2P clients can also=0A= provide their storage services.=0A= =0A= Some peers and P2P clients/storage P2P clients are coupled with SIP=0A= proxy, thus they can be used as SIP outbound proxies by SIP UAs=0A= residing in non-P2P clients. These SIP UAs might be conventional SIP=0A= UAs or might support some SIP extensions for P2PSIP.=0A= =0A= =0A= 7. IANA Considerations=0A= =0A= This memo includes no request to IANA..=0A= =0A= =0A= 8. Security Considerations=0A= =0A= No security consideration in current version=0A= =0A= =0A= 9. Acknowledgements=0A= =0A= This document is mainly inspired by the related discussion in P2PSIP=0A= maillist. The authors are grateful to those who have actively=0A= participated in the debate on the necessity, behaviors and characters=0A= of P2PSIP client.=0A= =0A= =0A= 10. References=0A= =0A= =0A= =0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 10]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= 10.1. Normative References=0A= =0A= [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate=0A= Requirement Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,=0A= A., Peterson, J., Sparks, R., Handley, M., and E.=0A= Schooler, "SIP: Session Initiation Protocol", RFC 3261,=0A= June 2002.=0A= =0A= [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation=0A= Protocol (SIP): Locating SIP Servers", RFC 3263,=0A= June 2002.=0A= =0A= 10.2. Informative References=0A= =0A= [I-D.bryan-p2psip-app-scenarios]=0A= Bryan, D., Shim, E., Lowekamp, B., and S. Dawkins,=0A= "Application Scenarios for Peer-to-Peer Session Initiation=0A= Protocol (P2PSIP)", draft-bryan-p2psip-app-scenarios-00=0A= (work in progress), November 2007.=0A= =0A= [I-D.ietf-p2psip-concepts]=0A= Bryan, D., Matthews, P., Shim, E., and D. Willis,=0A= "Concepts and Terminology for Peer to Peer SIP",=0A= draft-ietf-p2psip-concepts-01 (work in progress),=0A= November 2007.=0A= =0A= =0A= Authors' Addresses=0A= =0A= LiChun Li=0A= Beijing University of Posts and Telecommunications.=0A= P.O. Box 92, No.10, Xitucheng Road=0A= BeiJing, Haidian District 100876=0A= P.R.China=0A= =0A= Email: lilichun@gmail.com=0A= =0A= =0A= Yao Wang=0A= Beijing University of Posts and Telecommunications.=0A= P.O. Box 92, No.10, Xitucheng Road=0A= BeiJing, Haidian District 100876=0A= P.R.China=0A= =0A= Email: yaowang.bupt@gmail.com=0A= =0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 11]=0A= =0C=0A= Internet-Draft P2PSIP Node Types November 2007=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2007).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is provided by the IETF=0A= Administrative Support Activity (IASA).=0A= =0A= =0A= =0A= =0A= =0A= Li & Wang Expires May 25, 2008 [Page 12]=0A= =0C=0A= =0A= ------=_NextPart_000_0135_01C82DE8.28118AC0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_0135_01C82DE8.28118AC0-- From p2psip-bounces@ietf.org Fri Nov 23 03:11:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvTdK-0001rh-K4; Fri, 23 Nov 2007 03:11:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvTdJ-0001r4-40 for p2psip@ietf.org; Fri, 23 Nov 2007 03:11:29 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvTdE-0007Iw-Cn for p2psip@ietf.org; Fri, 23 Nov 2007 03:11:29 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRY00FQC9DDO4@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 23 Nov 2007 16:10:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRY00LMQ9DCGJ@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 23 Nov 2007 16:10:25 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRY00A7X9DC24@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 23 Nov 2007 16:10:24 +0800 (CST) Date: Fri, 23 Nov 2007 16:10:24 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) In-reply-to: <47349F0A.5090201@tm.uka.de> To: 'Ingmar Baumgart' , p2psip@ietf.org Message-id: <001e01c82da8$4cd87930$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acgi+cZZCUq8SDBRSx2ANPu79AHCKQKrXwmQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > The main contribution is on two aspects: One is reusability of the name > service for things like distributed DNS or HIP. The other is security in > a completely decentralized environment (without login severs). In the draft, it is harder for a node to get a Node ID because some puzzles are set. My concern is: is the Node ID computed off-line or online? If it is offline, sybil attack does exist. Am I missing something? Regards JiangXingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 07:43:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvXsN-0003dI-9W; Fri, 23 Nov 2007 07:43:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvXsM-0003cy-2X for p2psip@ietf.org; Fri, 23 Nov 2007 07:43:18 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvXsI-00071k-Tm for p2psip@ietf.org; Fri, 23 Nov 2007 07:43:18 -0500 Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx2.ira.uni-karlsruhe.de with esmtps id 1IvXsG-00032p-J9; Fri, 23 Nov 2007 13:43:14 +0100 Received: from wooky.tm.uka.de (unknown [IPv6:2001:638:204:6:210:c6ff:fedc:a5d4]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 6A5C02FC00E; Fri, 23 Nov 2007 13:43:12 +0100 (CET) Message-ID: <4746CAF5.8010702@tm.uka.de> Date: Fri, 23 Nov 2007 13:43:33 +0100 From: Ingmar Baumgart User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: JiangXingFeng Subject: Re: [P2PSIP] Draft: Peer-to-Peer Name Service (P2PNS) References: <001e01c82da8$4cd87930$6905a40a@china.huawei.com> In-Reply-To: <001e01c82da8$4cd87930$6905a40a@china.huawei.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Status: No X-Spam-Score: -1.4 (-) X-Spam-Report: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Host: iramx2.ira.uni-karlsruhe.de X-ATIS-Checksum: v3zoCAcc32ckk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org JiangXingFeng wrote: >> The main contribution is on two aspects: One is reusability of the name >> service for things like distributed DNS or HIP. The other is security in >> a completely decentralized environment (without login severs). > > In the draft, it is harder for a node to get a Node ID because some puzzles > are set. My concern is: is the Node ID computed off-line or online? If it is > offline, sybil attack does exist. Am I missing something? In a completely decentralized environment the nodeID in P2PNS is generated offline. Crypto puzzles are used to make a sybil attack harder for an ordinary attacker, but especially in small networks a sybil attack is still feasible. But in my opinion this is the best you can achieve in without relying on any trustworthy authorities. Regards, Ingmar -- Dipl.-Inform. Ingmar Baumgart Institut für Telematik, Universität Karlsruhe (TH) Zirkel 2, 76128 Karlsruhe, Germany Phone: +49 721 608 8281, Fax: +49 721 608 6789 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 10:30:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvaTg-0001u0-St; Fri, 23 Nov 2007 10:30:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvaTf-0001to-7P for p2psip@ietf.org; Fri, 23 Nov 2007 10:29:59 -0500 Received: from el-out-1112.google.com ([209.85.162.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvaTc-0003lO-CC for p2psip@ietf.org; Fri, 23 Nov 2007 10:29:59 -0500 Received: by el-out-1112.google.com with SMTP id r23so1406558elf for ; Fri, 23 Nov 2007 07:29:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=vCOPqSobyhZwtbKbz4Ej93hqZsbxrLw3JZ8Sw3hPMAs=; b=S+A+6Ns5GRVWhtnkdL3jd/s6aHba8Vsi+XM9AKXU/AMHuUQwE/8EVIePijNLDxWMlNRzuPzOZP2rQzXmsdngMvXXQLgGnUmFNeocwsVF8E4tl+nBgYExsbdaA3wP5sBbL0ze4VAWgE0pqmy7YfmohINvHned8ya1RKNhEunAy5U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=AmhA1Ke0zNhmDSgg34c3aBvdhthwNoqiG8VmPqWJvJ+9fcuWDGm/6ALYA/3+OQ3u5ppxREF3+PAM4I+IIHAvXydA4zKlVqh+PK6MqmsbUaP72bRTK7jeCosVkijPpTPa1BRJvLd5eTUA2oNzUc78tYwKgjWYWAYbHBS55uiBvLk= Received: by 10.142.241.10 with SMTP id o10mr1773836wfh.1195831794507; Fri, 23 Nov 2007 07:29:54 -0800 (PST) Received: by 10.142.132.18 with HTTP; Fri, 23 Nov 2007 07:29:54 -0800 (PST) Message-ID: <20d2bdfb0711230729o249c19ccwe1cfc60d86da5b28@mail.gmail.com> Date: Fri, 23 Nov 2007 10:29:54 -0500 From: "Bruce Lowekamp" To: JiangXingFeng Subject: Re: [P2PSIP] Routing mode in P2PSIP In-Reply-To: <008d01c82cb1$0cb485d0$6905a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20d2bdfb0711210516h29407727m1f1312789bbeeb64@mail.gmail.com> <008d01c82cb1$0cb485d0$6905a40a@china.huawei.com> X-Google-Sender-Auth: c5aa62a293d50894 X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 21, 2007 9:40 PM, JiangXingFeng wrote: > HI, Bruce: > > Response inline. > > The reason why I want to introduce semi-recursive routing mode is that it > has some advantages over other routing mode and it is has the best routing > efficiency. And I also think it could be complementary with the iterative > routing mode and iterative mode. > > I also admit there are some problems in semi-recursive mode, but there are > also some other problems to be solved in other routing mode. Now, I think it > is not the right time to exclude the semi-recursive routing mode. > > I also want to get some advice and comments from the other guys in the > community. > > Regards! > JiangXingFeng > > On Nov 20, 2007 9:40 PM, JiangXingFeng wrote: > > > > > > Maybe we could choose some peers which are on the public Internet and > the > > > responder could ask them to relay the response to the source peer. > Because > > > the chosen relaying peer is on the public internet, so the response > could > > > arrive at these relaying peer. So the problem is reduced to how the > relaying > > > peer knows how to relay the response to the source peer. IMHO, there are > two > > > candidate solutions: > > > > This idea works fine if a significant number of the peers have > > unfirewalled, public addresses, but one of the goals of reload-02 (as > > well as reload-01, asp, and most of the other proposals) is to work in > > an environment where there are few to none of the peers with such > > addresses. > > Sorry, I have not read the reload-02 entirely. And I will go on reading it. > I have a concern here: how does the RELOAD support the situation where all > the peers are behind NAT? How do the peers who are behind NAT, maybe > p2p-unfriendly NAT, communicate with each other? Could you give more details > here? Thanks! > "All" peers behind NATs does require some sort of publicly available bootstrap server (although that can be a peer behind a NAT with address independent mapping and filtering). After the initial bootstrap, most communication is routed across the overlay. To open a new connection (for a fingertable entry, for example), any pair of peers except those where both are behind evil (symmetric) NATs will be able to open that connection using ICE. If they are both behind evil NATs, for any fingertable entry (in chord), you can pretty much just ignore the failure because those neighbors exist just as an optimization. But you really do need to have a connection with your predecessor and successor. reload-02 proposes a mechanism for identifying a turn server that peers could use to establish connectivity in that situation. But we anticipate that, even with all peers behind NATs, both peers being behind evil NATs will be extremely rare. The turn location mechanism in reload-02 hypothesizes that it will be easy to determine the percentage of peers that can serve as turn servers. I should also mention that we need to add some text on letting peers behind good NATs be turn servers as well---even if you need to use ICE to open a connection with the turn server itself, there's no reason every peer behind a good NAT can't be a turn server. That essentially lets almost all peers be turn servers. > > While I understand your desire to improve routing > > efficiency, if it makes the routing protocol more complicated because > > different things are done in different conditions, I would be opposed > > to it. > > I don't think introducing semi-recursive routing mode will make the routing > protocol more complicated. There are two routing mode, iterative mode and > recursive mode proposed in RELOAD-2. They have different processing routine, > so the things to be done must be different in the two routing modes. > Semi-recursive could have a separate one, I think. > Iterative and symmetric both work in the presence of NATs. semi-recursive really doesn't without some help and a fallback on symmetric recursive (see my response at the bottom). > > > > The recipient of a message can know whether the sending peer was > > behind a NAT, but a peer itself can't necessarily know if it's behind > > a NAT (until it talks with a node that is outside its NAT). > > I am not an expert of NAT. but I know there are some methods for a node to > know whether it is behind NAT or not. STUN is an example. Do I leave > something behind? If you're configured with a stun server on the other side of a nat or you communicate with a peer on the other side of a nat, then you know you're behind one. However, you can't ever prove that you're not behind a NAT. (could be on a NATed network that's using public-range IP addresses and you just happen not to have talked with anyone on the other side. Or you could be on a large private network in the private address range that doesn't have any connectivity with the outside, in which case you're not behind a NAT.) > > > It can be done, but I would hate to base a protocol on its success. > > If the peer does not know where it is, behind NAT or not, does it mean the > ICE should be used even if the two public guys wants to communicate with > each other directly. From my point of view, it is time-consuming and > unnecessary. I agree there are some optimizations that can be made there. ICE has the virtue of working, even if it's not the most efficient. > > > > > > > The reload-02 messages keep the state in the message itself (the > > via/route list). > > Could you ensure when the response is forward back on the reverse path, all > peers in via or route list did not fail or leave the overlay simultaneously? > IMHO, if any one in the list fails or leaves the overlay, the recursive > routing will fail. We should consider churn in P2P network while designing > peer protocol, after all churn is nature of P2P network. > > >Retransmission is handled end-to-end. So the > > responder still doesn't have a way of knowing for sure if the response > > got back, but it can assume that it was just random packet loss and > > keep sending the response whenever it gets a retransmission until the > > sender receives it. > > Due to the same reason as above, we should consider the possible loss from > overlay churn, not only just assume it is a random packet loss. Regular end-to-end retransmission should handle this. If you have an overlay that has so much churn that you can't get a message routed round-trip, you're going to have problems with any routing algorithm. (and I'm not trying to trivialize the complexity of dealing with churn. it's really hard, but if your peers detect a failed link quickly, symmetric recursive works about as well as anything) > > There is another issue I am also interested: how do the RELOAD-2 determine > the end-to-end timeout period? reload-02 proposes to use the standard sip timeout scheme. > > If you try to send it back directly, the > > responder has to have some heuristic like if it sends the response > > back twice and then receives a third retransmission, there must be a > > nat or firewall issue. > > To be honest, I am not totally understood. Could you give more explanations? > Thanks! To implement semi-recursive, you need to make the link-layer protocol a bit more complex. If you have an ack go between the querying peer and the answering peer after the final response is received, then the answering peer knows the response was received. If no ack is received, then you need the answering peer to do something else, like return the response along the reverse path when it receives a first or second retransmission of the original request. Bruce _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 10:52:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivapb-0006BO-HA; Fri, 23 Nov 2007 10:52:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivapa-0006BI-So for p2psip@ietf.org; Fri, 23 Nov 2007 10:52:38 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvapX-0004OQ-6w for p2psip@ietf.org; Fri, 23 Nov 2007 10:52:38 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2411787rvb for ; Fri, 23 Nov 2007 07:52:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=FF2JdF+C5WoWAv7qJd/yECelAAQ6LYo1vsBQ+ScGIXU=; b=LZ8KVd6FQHzWrL2xPO0iSVzqCklmSdziOEZ/ieAiC4Loi5kkcIPgz0pMS+2d2Ar3viKJz/eK3jzElmaG0Fjb51JBOASsK3v2IPvYRLaeFbUGUHi1Ou1OwfwoQIJMHoNR+toQAq9zi1+C1K9N6eUxCfeCdQTQlm6eWCBMgTplFaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Pr5lQ/xbDT2mcIpwqcicr04OWwYgLZl490GdlNS5Zp38lWpbAQQqFJBIswQ6Prasc5yIWjfp9kJ0Uxv8lLO5Tk0REFA3CNNs+UVL7rXe0k8yOjupOpqyDzuhALqjESj0AKgi6+enhqmwNmmyVJBif8YPq29OSqh8FdzyiKUAtLY= Received: by 10.141.178.5 with SMTP id f5mr4536138rvp.1195833152744; Fri, 23 Nov 2007 07:52:32 -0800 (PST) Received: by 10.141.177.20 with HTTP; Fri, 23 Nov 2007 07:52:32 -0800 (PST) Message-ID: <7b683f3f0711230752x290e3523i8c70cad46d1a20e8@mail.gmail.com> Date: Fri, 23 Nov 2007 10:52:32 -0500 From: "Eunsoo Shim" To: "Yao Wang" Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: To those interested in P2PSIP clients) In-Reply-To: <013401c82da5$19ee4ac0$9a00a8c0@mlifewangyao> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <013401c82da5$19ee4ac0$9a00a8c0@mlifewangyao> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The fundamental characteristics of Peers in DHT are the three things: - Participates in overlay maintenance - Provides routing service - Provides storage service. What do you mean by 'transport service'? Thanks. Eunsoo On Nov 23, 2007 2:47 AM, Yao Wang wrote: > Hi, everyone. > The attachment is a new I-D mainly talking about different types of nodes in P2PSIP. > This document is an attempt to classify different types of node in peer-to-peer Session Initiation Protocol (P2PSIP). Four possible types of nodes in P2PSIP are discussed based on two characters: whether it offers overlay-routing services and whether it offers storage functions. The behaviors of each type of nodes and their possible necessities are analyzed. This document is dedicated to be a reference for clarifying some controversial terms in P2PSIP working group, such as "client", "low-function peer", etc. > It is hoped that this document could help the WG to reach a rough consensus on the types of node within P2PSIP system and the characters of each type's behavior. > > Because the IETF Internet-Draft Submission is closed right now, I have to send it as attachment to this maillist. This document will be submitted to IETF as soon as IETF Internet-Draft Submission reopened. :) > > Sincerely yours, > > Yao Wang > Mobile Life and New Media Lab, BUPT > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: Thursday, November 15, 2007 9:00 PM > To: P2PSIP Mailing List > Subject: [P2PSIP] To those interested in P2PSIP clients > > A word of advice to all those interested in P2PSIP clients: > > Please write an internet-draft saying why you want clients. State the > problem(s) that clients solve that peers do not. > > More specifically: > * Describe a problem that you want to solve using clients. > * Present a convincing argument why that problem is interesting. > * Present a convincing argument why that problem cannot be solved > using peers. > > DO NOT go into the technical minutia of a client protocol. Just focus > on convincing people that the problem is worthwhile solving and that > some model of clients would be the best way to solve it. > > The WG chairs requested this document at the Prague meeting in the > spring, but I have yet to see it. > > - Philip > > PS. If someone thinks a recently posted draft meets this criteria, > then I would appreciate a pointer to it. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 11:11:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivb7e-00034C-Ta; Fri, 23 Nov 2007 11:11:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivb7d-000340-Pf for p2psip@ietf.org; Fri, 23 Nov 2007 11:11:17 -0500 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivb7a-0004xv-US for p2psip@ietf.org; Fri, 23 Nov 2007 11:11:17 -0500 Received: by nz-out-0506.google.com with SMTP id n1so2461027nzf for ; Fri, 23 Nov 2007 08:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=Oc+eg+AsALsvqCvzPkN/fBa4HiHE5sx5mrfje2gMVO8=; b=ZXaS2xUH51BIXdHxfy8agDh9RajdMy0ulFb4Kr2RPa0XeIym+cnOQLGzBdXLlui9xNfR8isAXt+makGZXyClXVuYskwqJMEcz+kmMdIsIaA8hTNl1UoedUsCmDxTcubI3sZkdNyjDis4DE8sgDPu8l8iimr9xhUnz8DoEFT7zOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=q0GioCBYiAVGLfvDTtsZYPPa+Va+ugZEJZW9afFo5XgeC4swvcZVWAAwIZzGR0RRfQlYk2jEfSN0hH6sgtwUHorBaRv/LAd5br5WBx69oPppLeNdUNjCHxbchGQdoBcfCaZ/Ml9NJmCedWdUL+BJMEeClQq1hnsT+oGC9THDFps= Received: by 10.142.185.13 with SMTP id i13mr2641279wff.1195834273836; Fri, 23 Nov 2007 08:11:13 -0800 (PST) Received: by 10.142.200.16 with HTTP; Fri, 23 Nov 2007 08:11:13 -0800 (PST) Message-ID: <7d6b50690711230811r4342cfacm5121a1ba18e18e9b@mail.gmail.com> Date: Sat, 24 Nov 2007 00:11:13 +0800 From: "lichun li" To: "Eunsoo Shim" Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: To those interested in P2PSIP clients) In-Reply-To: <7b683f3f0711230752x290e3523i8c70cad46d1a20e8@mail.gmail.com> MIME-Version: 1.0 References: <013401c82da5$19ee4ac0$9a00a8c0@mlifewangyao> <7b683f3f0711230752x290e3523i8c70cad46d1a20e8@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1403262442==" Errors-To: p2psip-bounces@ietf.org --===============1403262442== Content-Type: multipart/alternative; boundary="----=_Part_29572_14375798.1195834273642" ------=_Part_29572_14375798.1195834273642 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline We reuse the terms in concept draft. In concept draft: "In P2PSIP, peers offer storage and transport services to allow the distributed database function and distributed transport function to be implemented." On 11/23/07, Eunsoo Shim wrote: > > The fundamental characteristics of Peers in DHT are the three things: > - Participates in overlay maintenance > - Provides routing service > - Provides storage service. > > What do you mean by 'transport service'? > > Thanks. > > Eunsoo > > > On Nov 23, 2007 2:47 AM, Yao Wang wrote: > > Hi, everyone. > > The attachment is a new I-D mainly talking about different types > of nodes in P2PSIP. > > This document is an attempt to classify different types of node > in peer-to-peer Session Initiation Protocol (P2PSIP). Four possible > types of nodes in P2PSIP are discussed based on two characters: whether it > offers overlay-routing services and whether it offers storage > functions. The behaviors of each type of nodes and their possible > necessities are analyzed. This document is dedicated to be a reference for > clarifying some controversial terms in P2PSIP working group, such as > "client", "low-function peer", etc. > > It is hoped that this document could help the WG to reach a > rough consensus on the types of node within P2PSIP system and the characters > of each type's behavior. > > > > Because the IETF Internet-Draft Submission is closed right now, > I have to send it as attachment to this maillist. This document will be > submitted to IETF as soon as IETF Internet-Draft Submission reopened. :) > > > > Sincerely yours, > > > > Yao Wang > > Mobile Life and New Media Lab, BUPT > > > > -----Original Message----- > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Sent: Thursday, November 15, 2007 9:00 PM > > To: P2PSIP Mailing List > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > A word of advice to all those interested in P2PSIP clients: > > > > Please write an internet-draft saying why you want clients. State the > > problem(s) that clients solve that peers do not. > > > > More specifically: > > * Describe a problem that you want to solve using clients. > > * Present a convincing argument why that problem is interesting. > > * Present a convincing argument why that problem cannot be solved > > using peers. > > > > DO NOT go into the technical minutia of a client protocol. Just focus > > on convincing people that the problem is worthwhile solving and that > > some model of clients would be the best way to solve it. > > > > The WG chairs requested this document at the Prague meeting in the > > spring, but I have yet to see it. > > > > - Philip > > > > PS. If someone thinks a recently posted draft meets this criteria, > > then I would appreciate a pointer to it. > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > -- > Eunsoo > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_29572_14375798.1195834273642 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
We reuse the terms in concept draft.
In concept draft:
"In P2PSIP, peers offer storage and transport
   services to allow the distributed database function and distributed
   transport function to be implemented."

 
On 11/23/07, Eunsoo Shim <eunsooshim@gmail.com> wrote:
The fundamental characteristics of Peers in DHT are the three things:
- Participates in overlay maintenance
- Provides routing service
- Provides storage service.

What do you mean by 'transport service'?

Thanks.

Eunsoo


On Nov 23, 2007 2:47 AM, Yao Wang < yaowang.bupt@gmail.com> wrote:
> Hi, everyone.
>         The attachment is a new I-D mainly talking about different types of nodes in P2PSIP.
>         This document is an attempt to classify different types of node in    peer-to-peer Session Initiation Protocol (P2PSIP).  Four possible types of nodes in P2PSIP are discussed based on two characters: whether it offers overlay-routing services and whether it offers storage functions.  The behaviors of each type of nodes and their possible necessities are analyzed.  This document is dedicated to be a reference for clarifying some controversial terms in P2PSIP working group, such as "client", "low-function peer", etc.
>         It is hoped that this document could help the WG to reach a rough consensus on the types of node within P2PSIP system and the characters of each type's behavior.
>
>         Because the IETF Internet-Draft Submission is closed right now, I have to send it as attachment to this maillist. This document will be submitted to IETF as soon as IETF Internet-Draft Submission reopened. :)
>
> Sincerely yours,
>
> Yao Wang
> Mobile Life and New Media Lab, BUPT
>
> -----Original Message-----
> From: Philip Matthews [mailto: philip_matthews@magma.ca]
> Sent: Thursday, November 15, 2007 9:00 PM
> To: P2PSIP Mailing List
> Subject: [P2PSIP] To those interested in P2PSIP clients
>
> A word of advice to all those interested in P2PSIP clients:
>
> Please write an internet-draft saying why you want clients. State the
> problem(s) that clients solve that peers do not.
>
> More specifically:
> * Describe a problem that you want to solve using clients.
> * Present a convincing argument why that problem is interesting.
> * Present a convincing argument why that problem cannot be solved
> using peers.
>
> DO NOT go into the technical minutia of a client protocol. Just focus
> on convincing people that the problem is worthwhile solving and that
> some model of clients would be the best way to solve it.
>
> The WG chairs requested this document at the Prague meeting in the
> spring, but I have yet to see it.
>
> - Philip
>
> PS. If someone thinks a recently posted draft meets this criteria,
> then I would appreciate a pointer to it.
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
> _______________________________________________
> P2PSIP mailing list
> P2PSIP@ietf.org
> https://www1.ietf.org/mailman/listinfo/p2psip
>
>



--
Eunsoo

_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip



--
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT ------=_Part_29572_14375798.1195834273642-- --===============1403262442== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1403262442==-- From p2psip-bounces@ietf.org Fri Nov 23 11:36:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbVq-0000rn-FF; Fri, 23 Nov 2007 11:36:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvbVn-0000of-Gu for p2psip@ietf.org; Fri, 23 Nov 2007 11:36:16 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvbVk-0005jb-Og for p2psip@ietf.org; Fri, 23 Nov 2007 11:36:15 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2419281rvb for ; Fri, 23 Nov 2007 08:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=rNHPGgDplJenpoSI0wWoLMAUKeEvXFiOgUaoiRueaDE=; b=KDq2GH9jhAuqxoeu67kGM0NKZDxYswjbEvokMoi3Z+MMdhpYbrckO9ItE6MG3kaYuWzU0BdVX2BPnzIyYuli9kIfQeT6ivK36RsdgSezKYAky44srkcAfvtSe5rH/YEimuSF1weiCHLQc/lK2OwRfz+7y7nsmPGZfl3fqwIIf80= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qIDdFvnBPgD/r7D41LnQJ4o4h8zmOVY0sZo7cgR4p0OpPp8FAyQdUjwiMqDXTatDkdF+hEU6VaieuVq1tMe3tMwE9RABq41xciSenqRGMenUBD+b81APEiyIDzkhtGs8OpwGHX3qzKo2UyIFZ9UGkCAmyqzkZdG66Vvb0U8IVVs= Received: by 10.141.178.5 with SMTP id f5mr2660169rvp.1195835769991; Fri, 23 Nov 2007 08:36:09 -0800 (PST) Received: by 10.141.177.20 with HTTP; Fri, 23 Nov 2007 08:36:09 -0800 (PST) Message-ID: <7b683f3f0711230836u1cb5ce0fhe3f1ce919bb0b471@mail.gmail.com> Date: Fri, 23 Nov 2007 11:36:09 -0500 From: "Eunsoo Shim" To: "lichun li" Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: To those interested in P2PSIP clients) In-Reply-To: <7d6b50690711230811r4342cfacm5121a1ba18e18e9b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <013401c82da5$19ee4ac0$9a00a8c0@mlifewangyao> <7b683f3f0711230752x290e3523i8c70cad46d1a20e8@mail.gmail.com> <7d6b50690711230811r4342cfacm5121a1ba18e18e9b@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Then the transport service is another apsect of the 'routing service'. It is like that we say the IP layer does routing (while an IP packet carries a payload). Somehow the definition of P2PSIP Peer in the concept draft does not mention 'routing'. I am going to suggest slight modification of the definition to other authors. Back to your draft, non-P2P Clients can certain exist. Actually a device with just SIP UA is such a device. But when we consider the overlay layer, such devices are irrelevant. Nor they affect on the overlay protocol design. It just confuses the discussion about node types for the overlay. I don't think such devices should be considered as a type of node in the overlay. Thanks. Eunsoo On Nov 23, 2007 11:11 AM, lichun li wrote: > We reuse the terms in concept draft. > In concept draft: > "In P2PSIP, peers offer storage and transport > services to allow the distributed database function and distributed > transport function to be implemented." > > > > > On 11/23/07, Eunsoo Shim wrote: > > The fundamental characteristics of Peers in DHT are the three things: > > - Participates in overlay maintenance > > - Provides routing service > > - Provides storage service. > > > > What do you mean by 'transport service'? > > > > Thanks. > > > > Eunsoo > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < yaowang.bupt@gmail.com> wrote: > > > Hi, everyone. > > > The attachment is a new I-D mainly talking about different types > of nodes in P2PSIP. > > > This document is an attempt to classify different types of node > in peer-to-peer Session Initiation Protocol (P2PSIP). Four possible > types of nodes in P2PSIP are discussed based on two characters: whether it > offers overlay-routing services and whether it offers storage functions. > The behaviors of each type of nodes and their possible necessities are > analyzed. This document is dedicated to be a reference for clarifying some > controversial terms in P2PSIP working group, such as "client", "low-function > peer", etc. > > > It is hoped that this document could help the WG to reach a > rough consensus on the types of node within P2PSIP system and the characters > of each type's behavior. > > > > > > Because the IETF Internet-Draft Submission is closed right now, > I have to send it as attachment to this maillist. This document will be > submitted to IETF as soon as IETF Internet-Draft Submission reopened. :) > > > > > > Sincerely yours, > > > > > > Yao Wang > > > Mobile Life and New Media Lab, BUPT > > > > > > -----Original Message----- > > > From: Philip Matthews [mailto: philip_matthews@magma.ca] > > > Sent: Thursday, November 15, 2007 9:00 PM > > > To: P2PSIP Mailing List > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > A word of advice to all those interested in P2PSIP clients: > > > > > > Please write an internet-draft saying why you want clients. State the > > > problem(s) that clients solve that peers do not. > > > > > > More specifically: > > > * Describe a problem that you want to solve using clients. > > > * Present a convincing argument why that problem is interesting. > > > * Present a convincing argument why that problem cannot be solved > > > using peers. > > > > > > DO NOT go into the technical minutia of a client protocol. Just focus > > > on convincing people that the problem is worthwhile solving and that > > > some model of clients would be the best way to solve it. > > > > > > The WG chairs requested this document at the Prague meeting in the > > > spring, but I have yet to see it. > > > > > > - Philip > > > > > > PS. If someone thinks a recently posted draft meets this criteria, > > > then I would appreciate a pointer to it. > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > -- > > Eunsoo > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- > Sincerely yours, > > Lichun Li > Mobile Life New Media Lab, BUPT -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 13:56:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivdhm-0002ah-Mn; Fri, 23 Nov 2007 13:56:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivdhj-0002aQ-Ke for p2psip@ietf.org; Fri, 23 Nov 2007 13:56:43 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivdhj-0003wn-7c for p2psip@ietf.org; Fri, 23 Nov 2007 13:56:43 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Nov 2007 10:56:42 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lANIug2s001029; Fri, 23 Nov 2007 10:56:42 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lANIueb5019552; Fri, 23 Nov 2007 18:56:40 GMT In-Reply-To: <008201c82b60$012054d0$6905a40a@china.huawei.com> References: <008201c82b60$012054d0$6905a40a@china.huawei.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <925F6CE8-D2AC-4E9D-A294-4A54DF00570C@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Routing mode in P2PSIP Date: Fri, 23 Nov 2007 10:56:05 -0800 To: JiangXingFeng X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1678; t=1195844202; x=1196708202; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Routing=20mode=20in=20P2PSIP |Sender:=20; bh=v3WuO8Kq4LwFrNQV+PVZcMhjlY+Ghqz3UmcpaG5VkhU=; b=Nobg6DkrWdv2aShJs3y8lw4BSqc41qr+DDz0iur1gQr8klaXoNjAXlaQ6tGyGglEYNoUYQ3O DrjjTb8htahwopQROhUYEwVYaKnpLlJH3ExCrFwKsQN82+If+48rgtCG; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi - I'm not sure I understand what you mean by semi-recursive and how it would work. Could you explain a bit how it works and what would be needed in reload to support it. I'm always curios about how a node decides what to do when there are multiple options available to it. Thanks, Cullen On Nov 20, 2007, at 2:27 AM, JiangXingFeng wrote: > Hi, > > There are four routing mode described in the draft-bryan-p2psip- > reload-01. > After reading P2PP and RELOAD revision 2, only the iterative > routing mode > and recursive mode are supported. > > Why doesn't P2PSIP peer protocol support semi-recursive mode? IMHO, > semi-recursive mode at least has two following advantages over > other routing > mode: > 1. Semi-recursive mode is more resilient from failures of > intermediate peers > than recursive mode. In recursive mode, if any of the intermediate > peers > fails, the response could not return back in the reverse path the > request > has traversed. > 2. Semi-recursive mode has lower latency than recursive and > iterative mode. > The response in semi-recursive mode could go back to the request > originator > by forwarding based on its transport address. > > IMHO, the major issue that semi-recursive mode should face is how the > response goes to the request originator if the request originator > is behind > NAT. I think there must be solution to this issue. > > Comments? > > -- > Jiang XingFeng > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 14:09:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivdu4-0007rt-7e; Fri, 23 Nov 2007 14:09:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivdu2-0007rW-Qe for p2psip@ietf.org; Fri, 23 Nov 2007 14:09:26 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivdu1-0004Oa-Ps for p2psip@ietf.org; Fri, 23 Nov 2007 14:09:26 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Nov 2007 11:09:25 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lANJ9PQL011655; Fri, 23 Nov 2007 11:09:25 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-5.cisco.com (8.12.10/8.12.6) with SMTP id lANJ9OB0025153; Fri, 23 Nov 2007 19:09:24 GMT In-Reply-To: References: Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] More thoughts on clients, peers, and services, and service routing Date: Fri, 23 Nov 2007 11:08:50 -0800 To: Dean Willis X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7463; t=1195844965; x=1196708965; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20More=20thoughts=20on=20clients, =20peers, =2 0and=20services,=20and=20service=20routing |Sender:=20; bh=DTW4A36ZCQYl7QuIGDN2vTOY1UKhC/820GpmBkhfEB8=; b=YaDDavakTdD78rXVjVfRlBulWsb/Iyqbk0T43zOLCk5fzmg1LqrV0czvkTOK3Vs1AZoIMPpM CAivVI2TJIUguUhdRZD1JMhlJlmHHBApY7bW7R1OQla32HrTYdpWSMh7; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean, I have read this 3 times now and I can't figure it out in the slightest. Can you relate this is a concrete way to what would need to be changed on any of the draft proposed solutions. That might help me understand. I'm also very confused if "finding" has to do with peers doing storage or with peers doing routing or something else all together. Thanks, Cullen On Nov 21, 2007, at 2:03 PM, Dean Willis wrote: > > In the voluminous discussion of the last 36 hours, I think I'm > seeing an alternative emerge that I will try and restate. > > One way to divide the problem space is to differentiate the tasks > of "finding", "routing", and "everything else". > > Several people have proposed that peers exclusively provide > "finding and routing" services. Clients use the "finding and > routing" services of peers. Both clients and peers can also offer > other services, such as STUN relay (although some might say that > peers offering other services are acting as clients when they do > so). I think this model works fairly well, and it continues in the > principle that peers are a superset of clients -- that is, that > clients and peers are pretty much similar, but peers do a few > things that clients can't. For each service that a client or peer > provides, that node would "put" a service entry in to the database, > and these services are completely distinct from the nodes role as > peer or client > > > Is this the only way to divide the problem? Maybe clients and peers > are very different things, neither subsets nor supersets of each > other. > > What if peers deal exclusively with "finding", and we think of > message routing as a separate service entirely? > > In this approach, one could ask a peer "Please store this resource > record" or "Please fetch this resource record", but not "Please > send this message to alice@example.com". > > How would this facilitate setting up SIP sessions? > > Alice might request that the overlay store as a resource record, a > route to "alice@example.com", where that route might include not > only Alice's "contact", but also hops for nodes that have agreed to > serve as relays for sending messages to Alice. This is somewhat > analogous to the "path" and "service route" terminology in SIP. We > can think of this as a "put" operation against the distributed > database. > > To call Alice, Bob would then simply do a "get" operation, > requesting a route to "alice@example.com". He would then use the > result as a SIP route vector to send an INVITE request to Alice. > > Both of these require some sort of convention for constructing the > resource-ID for the route record, but that's fairly trivial. > > The harder parts: How would Alice discover an appropriate vector? > And how do we compensate for the fact the ideal route between Bob > and Alice might be different than the route between Charlie and Alice? > > Of course, before Alice can find "routing" nodes in the database, > those nodes have to list themselves. Each one might start by > finding a primal node (a "routing bootstrap", if you will) and > making ICE checks against that node. If they can reach it and it > can reach them, they consider themselves "tier-1" nodes, and "put" > resource records listing themselves as tier-1 nodes. If not, then > they query the database for tier-1 nodes, perform ICE checks > against them, and add resource records listing themselves as tier-2 > nodes adjacent to the tier-1 nodes which which they have mutual > reachability. If they aren't adjacent to any tier-1 nodes, then > they repeat for tier-2, then tier-3, and so on. Of course, it would > be nice if the distributed database offered some technique for > automagically scoping the candidates, but it isn't required for the > algorithm to terminate. Optionally, routing nodes could do > persistent "outbound"-like bindings with some higher-tier node > selected as the most-adjacent node they can reach, thereby either > short-circuiting the search process or achieving connectivity > across NAT/FW boundaries that block reverse-path checks. One could > further short-circuit the process by using broadcast and multicast > to find neighbors that have already established their vectors, then > copying those vectors rather than finding new ones. > > Alice might begin by querying the distributed database for nodes > offering the "routing" service, thereby obtaining a list of > candidate nodes. She might then do something like an ICE-like > evaluation to find one or more acceptable candidates, and would > select the lowest-tiered node she could reach. Of course it would > be nice if the distributed database could help narrow this search, > but it isn't absolutely required. Alice would continue working up > the tiers until reaching tier-1, then "put" a vector or into the > database, where that vector lists Alice's contact plus the URIs of > each routing node up to and including her tier-1 contact. > > Bob, when calling Alice, would "get: her vector, then run a > shortest-path calculation between his vector and her vector, then > use the result as a SIP route to reach Alice. > > What we get out of this is a system where the distributed database > can be any off-the-shelf DHT (such as OpenDHT), and where SIP > messages are routed according to what is in effect a minimum > spanning tree calculation against the sip-routing topology of the > network. > > Alternatively, we could do subtree and named-subtree (dynamic > aggregation) approaches that would provide absolutely optimal > routes but have higher overheads. Think OSPF, but where > aggregations (OSPF areas) are defined dynamically vice ICE-like > adjacency checks. > > This is a little different from the current proposals, which seem > to require a customized DHT algorithm and and routes messages > across that DHT based on the dynamic topology of the DHT itself and > is likely to give a much less efficient a route. Of course, the > route discovery process (especially in the event of a topology > change) is much easier. On the other hand, the DHT topology tells > us little or nothing about net-path efficient routing, which is > CRITICAL for media-path relay, and the model proposed here would > provide much better selection mechanisms for net-path efficient > media relays. > > But haven't we, for all practical purposes, developed a net-path > optimized routing database that we bootstrapped into using a > conventional DHT? Do we need to reinvent path-efficient routing for > messaging, media relay, and every service? Would it have been more > efficient just to start with a path-efficient DHT to start with? I > don't know yet. I do know that thinking about application-aware > routing at Internet scales is giving me a severe head pain, and > historically, the complexity of this is why we have the "thin- > waisted" routing model of the Internet. I just wished it worked in > the real world of NATs and firewalls and other annoying stuff. > > -- > Dean > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 14:18:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ive2t-00064W-VO; Fri, 23 Nov 2007 14:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ive2s-0005wr-Cj for p2psip@ietf.org; Fri, 23 Nov 2007 14:18:34 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ive2o-0003L1-0E for p2psip@ietf.org; Fri, 23 Nov 2007 14:18:34 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2007 11:18:32 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lANJITft017824; Fri, 23 Nov 2007 11:18:29 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-1.cisco.com (8.12.10/8.12.6) with SMTP id lANJISut015864; Fri, 23 Nov 2007 19:18:28 GMT In-Reply-To: <113091BD57179D4491C19DA7E10CD6960193DC24@mx1.office> References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> <20071120151620.D1F2533C21@delta.rtfm.com> <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> <4d4304a00711210649o7d305e7dh9dc3e399920532f5@mail.gmail.com> <113091BD57179D4491C19DA7E10CD6960193DC24@mx1.office> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FD57509-6FA9-4B4C-92D7-B7437BC00B0F@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 Date: Fri, 23 Nov 2007 11:17:53 -0800 To: Jan Seedorf X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9630; t=1195845509; x=1196709509; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Replication=20-=20Was=20Re=3A=20[P2PSIP]=20Merge=20of=20ASP=2 0and=20RELOAD=20-=20Version=20Notification=20fordraft-bryan-p2psip-reload- 02 |Sender:=20; bh=9tq7Qc2tOGFZ+ncJ7DPytBbYdbhZ+e9uVO2O4CAJheo=; b=tbsiceEbTMAQS4ovNrX9OfQy881/q9BWHIAwTF+clMw3T06Pvch4YM6npP6U0wC2Ur6abaoe zPBq2o9a2dLLjR8zqr1sAkDh9dBL8BXXddF6FB8cJ7LwxV81ML0wVo9G; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -1.0 (-) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Jan, I think you are getting at we need replication to be possible at both the DHT and Application layer. I probably agree with you. One of the reasons I think we need this as the application layer is on only it can updated with a new signed copy that obsoletes any prior data because it is authoritative source for the information. On the other hand, we need it in the DHT because when the peer that runs the storing application is offline, we need the information to continue to persist in the DHT as peers storing the data churn. On a side note, I think the WG agreed to have a plug-able type of DHT scheme but I still think we need to specify some. Unless we specify some, I don't see how we can build interoperable systems. Cullen On Nov 22, 2007, at 7:15 AM, Jan Seedorf wrote: > Dear David, Bruce, and Salman, > > a couple of thought on this: > -- any mechanism on the DHT layer would not prohibit the > application layer to conduct additional replication (as David > points out below) > -- it may also depend on what layer you have mechanisms to detect > adversary nodes (to intentionally not replicate at adversary > nodes). If this is done at the DHT layer (e.g., by using density > checks of the successor list) this information could be passed on > to the application layer. If you detect adversary nodes at the > application layer (e.g., through timeouts or by cryptographic > verification of the content they provide), only the application > layer can use this information for replication. > > I thought the WG had decided not to focus on a particular DHT but > rather make P2PSIP use pluggable DHTs. Any mechanism on the DHT > layer is very DHT-protocol specific. Does that not imply that > replication on that layer is out of the scope of the WG? > > Salman: I think the point raised by David in his other mail was not > _whether_ an operator should ensure that replicas survive node > failures but how this can be done if the source is responsible for > replication (rather a research issue) > > - Jan > >> -----Original Message----- >> From: amelampus@gmail.com [mailto:amelampus@gmail.com] On >> Behalf Of David A. Bryan >> Sent: Wednesday, November 21, 2007 3:50 PM >> To: Salman Abdul Baset >> Cc: Eric Rescorla; p2psip@lists.ietf.org; Jan Seedorf >> Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version >> Notification fordraft-bryan-p2psip-reload-02 >> >> Sort of related to this discussion is the open question of >> what layer does replication occur? There are several alternatives: >> >> * Do it on a per-pluggable DHT level. In otherwords, each DHT >> that is defined specifies a replication mechanism. This may >> be very desirable if someone has a very clever DHT design >> with a specific replication scheme, but might remove operator >> flexibility and make it difficult for specific applications >> to have alternate schemes (although they could layer it on >> top of the DHT provided scheme) >> >> * Do it at the application level instead. Each usage >> specifies what replication it would like (how many, where, do >> you do source node replication if the source node fails, >> etc.) The advantage to this is that it can be much more >> tailored for the use of the application, but if one overlay >> is supporting multiple usages, then things stored in common >> to each usage (maybe the user's public key, for example, >> which different applications may want) could conceivably be >> replicated in more places than really needed. It also means a >> clever DHT replication idea isn't as useful, since there >> would still be replication above it at the app level anyway >> (although I guess you could just turn off the application >> level replication in that case anyway) >> >> * There might be other options... >> >> This is definitely a good open issue...I'd love to see a bit >> of discussion about what others think the pros and cons are here... >> >> --David (as individual) >> >> On Nov 20, 2007 6:43 PM, Salman Abdul Baset >> wrote: >>> As pointed, the replication mechanisms can be classified as: >>> >>> 1) Publisher (source) oriented >>> 2) Responsible peer (root node) oriented >>> >>> Both publisher and responsible nodes can determine the node replica >>> set, i.e., the list of nodes on which to replicate. In addition to >>> security, factors such as churn rate, uptime and load of a >> node also >>> impact the choice of replica set. >>> >>> An artifact of using DHTs is that the publisher and >> responsible peers >>> are generally different. Since nodes churn, the responsible >> peer may change. >>> In an unstructured (non-DHT) overlay, the publisher node >> will likely >>> be responsible for determining the replica set. >>> >>> The question of how many replicas to maintain is best left to the >>> overlay operator. As mentioned above, the number of >> replicas depends >>> on the churn rate, availability guarantees, and security >> among others. >>> >>> The question whether to maintain replicas after source node >> fails is >>> best left to the overlay operator. >>> >>> -salman >>> >>> >>> On Tue, 20 Nov 2007, David A. Bryan wrote: >>> >>>> One problem with having the just the source place the replicas is >>>> what happens when the source is offline. >>>> >>>> For example, I am the source. I send out the data to the original >>>> and the replica. Then log off. >>>> >>>> If one peer fails, then that replica is gone for good >> unless I come >>>> back up to refresh them, so over time, offline information could >>>> "decay" in the presence of a slow peer failure rate. >>>> >>>> Some sort of hybrid might make more sense...but there is >> (clearly) a >>>> security point that needs to be considered here. >>>> >>>> David (as individual) >>>> >>>> >>>> On Nov 20, 2007 10:16 AM, Eric Rescorla >> wrote: >>>>> At Tue, 20 Nov 2007 14:57:28 +0100, Jan Seedorf wrote: >>>>>> Dear authors of the new RELOAD draft (02), I have some >> comments on >>>>>> the security section: >>>>>> >>>>>> section 7.3. it is specified that the root-node of >> some resource >>>>>> ID (i.e., the node responsible for storing the resource) is >>>>>> responsible for replication. In section 10.5.4. >> "residual attacks" >>>>>> you mention that a query node can check at replica >> roots for some >>>>>> resource if the root-node does not respond. I see the >> following >>>>>> security problem: if the root-node is originally faulty >> at storage >>>>>> time (e.g., compromised), it will likely store invalid (though >>>>>> detectable) or no resources at all at the replica >> roots. As you >>>>>> well describe the only issue here is availability. However, I >>>>>> think that any countermeasure involving replication >> must involve >>>>>> distributed storage done by the query node itself (for reasons >>>>>> described above). Replication should not be the >> responsibility of >>>>>> the root-node. >>>>> >>>>> Yeah, this is sort of a thinko in our writeup. We intend >> to move to >>>>> explicit writes to each replica by the storing node and just ran >>>>> out of pre-draft time :) >>>>> >>>>> >>>>>> Section 10.6.1.: You assume a central authority and indeed this >>>>>> solves many security problems. It limits Sybil attacks >> and Eclipse >>>>>> attacks. This is well-described in the draft. However, >> there are >>>>>> other attacks on DHT routing. Join-leave attacks can be used by >>>>>> the attacker to chose its location in the DHT despite a central >>>>>> node-ID assignment authority (see C. Scheideler, "How to Spread >>>>>> Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM >> Symp. Theory >>>>>> of Comp., Baltimore, MD,pp. 704-13, for a formal >> analysis of the >>>>>> node-ID assignment problem in DHTs and join-leave attacks). >>>>>> Additionally, even if there are no Sybil or Eclipse attacks, >>>>>> adversary nodes (though well certified through the admission >>>>>> authority, e.g., because they have been compromised) can simply >>>>>> drop messages. This severely degrades the lookup >> success rate in a >>>>>> DHT. Countermeasures against these attacks may well be >>>>>> out-of-scope for P2PSIP standardisation, I just feel >> the section >>>>>> is misleading in the sense that it suggests that a central >>>>>> authority protects against all threats on DHT routing. >>>>> >>>>> I agree tha there are significant residual attacks. We'll see >>>>> whwat we can do to make this text clearer. IF you wanted >> to suggest >>>>> some text that would be great. >>>>> >>>>> Thanks, >>>>> -Ekr >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> P2PSIP mailing list >>>>> P2PSIP@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/p2psip >>>>> >>>> >>>> >>>> >>>> -- >>>> David A. Bryan >>>> dbryan@SIPeerior.com >>>> +1.757.565.0101 x101 >>>> +1.757.565.0088 (fax) >>>> www.SIPeerior.com >>>> >>>> _______________________________________________ >>>> P2PSIP mailing list >>>> P2PSIP@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/p2psip >>>> >>> >> >> >> >> -- >> David A. Bryan >> dbryan@SIPeerior.com >> +1.757.565.0101 x101 >> +1.757.565.0088 (fax) >> www.SIPeerior.com >> > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 14:56:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvedO-0003tc-6D; Fri, 23 Nov 2007 14:56:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvedN-0003tV-1h for p2psip@ietf.org; Fri, 23 Nov 2007 14:56:17 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvedK-0004c3-LC for p2psip@ietf.org; Fri, 23 Nov 2007 14:56:17 -0500 Received: by rv-out-0910.google.com with SMTP id l15so2455693rvb for ; Fri, 23 Nov 2007 11:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=hwyHSnQC1KpMdgNvVpvXnuLrkMbL8nYJ0sa/DUFbiBQ=; b=OiL9u+auelM+IpxvXFhZjv+vLV8EsPoBPa+FRYb7pmEkpXsV9nHpk0DcAjr7SlYEh/YEIOJa5ldOX3ZP+nqEDk8bsanGXkiRgzjmxshgeWNSJg8qAsoaTsgK+YvaAq9nssLja0tHNrwt4WDZPXQitrfYRx5JYuRwnjhCLvXusBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jpcTbFMHbZwe42dFrWp5hFXe1rK0NoQPdInbuKD64W9RdkV+RuaddzQPH5UDzEko8AY4jeNukpquhbDLfcXgRVAJHHO2M1vWkicIHOtaQVNzlCGsyo5OLbGtwb+EBBfpDkx4KqGFPPXdm1HTfC4kOSiSygMxByLT6lrTi0I6Das= Received: by 10.141.128.19 with SMTP id f19mr671064rvn.1195847773878; Fri, 23 Nov 2007 11:56:13 -0800 (PST) Received: by 10.141.177.20 with HTTP; Fri, 23 Nov 2007 11:56:13 -0800 (PST) Message-ID: <7b683f3f0711231156g37754b03q95958f344694342c@mail.gmail.com> Date: Fri, 23 Nov 2007 14:56:13 -0500 From: "Eunsoo Shim" To: "Cullen Jennings" Subject: Re: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 In-Reply-To: <7FD57509-6FA9-4B4C-92D7-B7437BC00B0F@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> <20071120151620.D1F2533C21@delta.rtfm.com> <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> <4d4304a00711210649o7d305e7dh9dc3e399920532f5@mail.gmail.com> <113091BD57179D4491C19DA7E10CD6960193DC24@mx1.office> <7FD57509-6FA9-4B4C-92D7-B7437BC00B0F@cisco.com> X-Spam-Score: 3.0 (+++) X-Scan-Signature: f60fbf3dbcaca652b6d10036f0630412 Cc: Jan Seedorf , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 23, 2007 2:17 PM, Cullen Jennings wrote: > > Hi Jan, > > I think you are getting at we need replication to be possible at both > the DHT and Application layer. I probably agree with you. One of the > reasons I think we need this as the application layer is on only it > can updated with a new signed copy that obsoletes any prior data > because it is authoritative source for the information. I am fine with allowing replication in both layers - DHT and application. Just let me clarify one thing. There are two nodes that may initiate replication. - Source Node (Peer or Client) - Responsible Peer Replication by the Responsible Peer must be done in the DHT layer. Replication by the source node may be performed in the DHT layer or in the application layer. The two cases will be (almost) identical from the protocol perspective. (In Pastry, the nodes on the path to the Responsible Peer make and keep a copy of the data. I am not sure if we want to follow it.) On the other > hand, we need it in the DHT because when the peer that runs the > storing application is offline, we need the information to continue > to persist in the DHT as peers storing the data churn. > > On a side note, I think the WG agreed to have a plug-able type of DHT > scheme but I still think we need to specify some. Unless we specify > some, I don't see how we can build interoperable systems. Agreed. Thanks. Eunsoo > > On Nov 22, 2007, at 7:15 AM, Jan Seedorf wrote: > > > Dear David, Bruce, and Salman, > > > > a couple of thought on this: > > -- any mechanism on the DHT layer would not prohibit the > > application layer to conduct additional replication (as David > > points out below) > > -- it may also depend on what layer you have mechanisms to detect > > adversary nodes (to intentionally not replicate at adversary > > nodes). If this is done at the DHT layer (e.g., by using density > > checks of the successor list) this information could be passed on > > to the application layer. If you detect adversary nodes at the > > application layer (e.g., through timeouts or by cryptographic > > verification of the content they provide), only the application > > layer can use this information for replication. > > > > I thought the WG had decided not to focus on a particular DHT but > > rather make P2PSIP use pluggable DHTs. Any mechanism on the DHT > > layer is very DHT-protocol specific. Does that not imply that > > replication on that layer is out of the scope of the WG? > > > > Salman: I think the point raised by David in his other mail was not > > _whether_ an operator should ensure that replicas survive node > > failures but how this can be done if the source is responsible for > > replication (rather a research issue) > > > > - Jan > > > >> -----Original Message----- > >> From: amelampus@gmail.com [mailto:amelampus@gmail.com] On > >> Behalf Of David A. Bryan > >> Sent: Wednesday, November 21, 2007 3:50 PM > >> To: Salman Abdul Baset > >> Cc: Eric Rescorla; p2psip@lists.ietf.org; Jan Seedorf > >> Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version > >> Notification fordraft-bryan-p2psip-reload-02 > >> > >> Sort of related to this discussion is the open question of > >> what layer does replication occur? There are several alternatives: > >> > >> * Do it on a per-pluggable DHT level. In otherwords, each DHT > >> that is defined specifies a replication mechanism. This may > >> be very desirable if someone has a very clever DHT design > >> with a specific replication scheme, but might remove operator > >> flexibility and make it difficult for specific applications > >> to have alternate schemes (although they could layer it on > >> top of the DHT provided scheme) > >> > >> * Do it at the application level instead. Each usage > >> specifies what replication it would like (how many, where, do > >> you do source node replication if the source node fails, > >> etc.) The advantage to this is that it can be much more > >> tailored for the use of the application, but if one overlay > >> is supporting multiple usages, then things stored in common > >> to each usage (maybe the user's public key, for example, > >> which different applications may want) could conceivably be > >> replicated in more places than really needed. It also means a > >> clever DHT replication idea isn't as useful, since there > >> would still be replication above it at the app level anyway > >> (although I guess you could just turn off the application > >> level replication in that case anyway) > >> > >> * There might be other options... > >> > >> This is definitely a good open issue...I'd love to see a bit > >> of discussion about what others think the pros and cons are here... > >> > >> --David (as individual) > >> > >> On Nov 20, 2007 6:43 PM, Salman Abdul Baset > >> wrote: > >>> As pointed, the replication mechanisms can be classified as: > >>> > >>> 1) Publisher (source) oriented > >>> 2) Responsible peer (root node) oriented > >>> > >>> Both publisher and responsible nodes can determine the node replica > >>> set, i.e., the list of nodes on which to replicate. In addition to > >>> security, factors such as churn rate, uptime and load of a > >> node also > >>> impact the choice of replica set. > >>> > >>> An artifact of using DHTs is that the publisher and > >> responsible peers > >>> are generally different. Since nodes churn, the responsible > >> peer may change. > >>> In an unstructured (non-DHT) overlay, the publisher node > >> will likely > >>> be responsible for determining the replica set. > >>> > >>> The question of how many replicas to maintain is best left to the > >>> overlay operator. As mentioned above, the number of > >> replicas depends > >>> on the churn rate, availability guarantees, and security > >> among others. > >>> > >>> The question whether to maintain replicas after source node > >> fails is > >>> best left to the overlay operator. > >>> > >>> -salman > >>> > >>> > >>> On Tue, 20 Nov 2007, David A. Bryan wrote: > >>> > >>>> One problem with having the just the source place the replicas is > >>>> what happens when the source is offline. > >>>> > >>>> For example, I am the source. I send out the data to the original > >>>> and the replica. Then log off. > >>>> > >>>> If one peer fails, then that replica is gone for good > >> unless I come > >>>> back up to refresh them, so over time, offline information could > >>>> "decay" in the presence of a slow peer failure rate. > >>>> > >>>> Some sort of hybrid might make more sense...but there is > >> (clearly) a > >>>> security point that needs to be considered here. > >>>> > >>>> David (as individual) > >>>> > >>>> > >>>> On Nov 20, 2007 10:16 AM, Eric Rescorla > >> wrote: > >>>>> At Tue, 20 Nov 2007 14:57:28 +0100, Jan Seedorf wrote: > >>>>>> Dear authors of the new RELOAD draft (02), I have some > >> comments on > >>>>>> the security section: > >>>>>> > >>>>>> section 7.3. it is specified that the root-node of > >> some resource > >>>>>> ID (i.e., the node responsible for storing the resource) is > >>>>>> responsible for replication. In section 10.5.4. > >> "residual attacks" > >>>>>> you mention that a query node can check at replica > >> roots for some > >>>>>> resource if the root-node does not respond. I see the > >> following > >>>>>> security problem: if the root-node is originally faulty > >> at storage > >>>>>> time (e.g., compromised), it will likely store invalid (though > >>>>>> detectable) or no resources at all at the replica > >> roots. As you > >>>>>> well describe the only issue here is availability. However, I > >>>>>> think that any countermeasure involving replication > >> must involve > >>>>>> distributed storage done by the query node itself (for reasons > >>>>>> described above). Replication should not be the > >> responsibility of > >>>>>> the root-node. > >>>>> > >>>>> Yeah, this is sort of a thinko in our writeup. We intend > >> to move to > >>>>> explicit writes to each replica by the storing node and just ran > >>>>> out of pre-draft time :) > >>>>> > >>>>> > >>>>>> Section 10.6.1.: You assume a central authority and indeed this > >>>>>> solves many security problems. It limits Sybil attacks > >> and Eclipse > >>>>>> attacks. This is well-described in the draft. However, > >> there are > >>>>>> other attacks on DHT routing. Join-leave attacks can be used by > >>>>>> the attacker to chose its location in the DHT despite a central > >>>>>> node-ID assignment authority (see C. Scheideler, "How to Spread > >>>>>> Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM > >> Symp. Theory > >>>>>> of Comp., Baltimore, MD,pp. 704-13, for a formal > >> analysis of the > >>>>>> node-ID assignment problem in DHTs and join-leave attacks). > >>>>>> Additionally, even if there are no Sybil or Eclipse attacks, > >>>>>> adversary nodes (though well certified through the admission > >>>>>> authority, e.g., because they have been compromised) can simply > >>>>>> drop messages. This severely degrades the lookup > >> success rate in a > >>>>>> DHT. Countermeasures against these attacks may well be > >>>>>> out-of-scope for P2PSIP standardisation, I just feel > >> the section > >>>>>> is misleading in the sense that it suggests that a central > >>>>>> authority protects against all threats on DHT routing. > >>>>> > >>>>> I agree tha there are significant residual attacks. We'll see > >>>>> whwat we can do to make this text clearer. IF you wanted > >> to suggest > >>>>> some text that would be great. > >>>>> > >>>>> Thanks, > >>>>> -Ekr > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> P2PSIP mailing list > >>>>> P2PSIP@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/p2psip > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> David A. Bryan > >>>> dbryan@SIPeerior.com > >>>> +1.757.565.0101 x101 > >>>> +1.757.565.0088 (fax) > >>>> www.SIPeerior.com > >>>> > >>>> _______________________________________________ > >>>> P2PSIP mailing list > >>>> P2PSIP@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/p2psip > >>>> > >>> > >> > >> > >> > >> -- > >> David A. Bryan > >> dbryan@SIPeerior.com > >> +1.757.565.0101 x101 > >> +1.757.565.0088 (fax) > >> www.SIPeerior.com > >> > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 15:11:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvesK-00009l-Ho; Fri, 23 Nov 2007 15:11:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvesJ-00004t-HU for p2psip@ietf.org; Fri, 23 Nov 2007 15:11:43 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvesG-0005Ri-6F for p2psip@ietf.org; Fri, 23 Nov 2007 15:11:43 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5389B33C21; Fri, 23 Nov 2007 12:06:35 -0800 (PST) Date: Fri, 23 Nov 2007 12:06:34 -0800 From: Eric Rescorla To: Cullen Jennings Subject: Re: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 In-Reply-To: <7FD57509-6FA9-4B4C-92D7-B7437BC00B0F@cisco.com> References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> <20071120151620.D1F2533C21@delta.rtfm.com> <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> <4d4304a00711210649o7d305e7dh9dc3e399920532f5@mail.gmail.com> <113091BD57179D4491C19DA7E10CD6960193DC24@mx1.office> <7FD57509-6FA9-4B4C-92D7-B7437BC00B0F@cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071123200635.5389B33C21@delta.rtfm.com> X-Spam-Score: 1.3 (+) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Jan Seedorf , P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Fri, 23 Nov 2007 11:17:53 -0800, Cullen Jennings wrote: > > On a side note, I think the WG agreed to have a plug-able type of DHT > scheme but I still think we need to specify some. Unless we specify > some, I don't see how we can build interoperable systems. AFAICT, both of these are required by our charter: 2. A proposed standard defining a P2PSIP Peer Protocol. This protocol is used between P2PSIP overlay peers, some of which may be behind NATs. This protocol will define how the P2PSIP peers collectively provide for user and resource location in a SIP environment with no or minimal centralized servers. This protocol may or may not be syntactically based on SIP, a decision to be made by the WG. The group will identify and require one base P2P algorithm (likely a particular Distributed Hash Table (DHT) algorithm), while allowing for additional optional algorithms in the future. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 21:21:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvkeU-0005Lh-Bf; Fri, 23 Nov 2007 21:21:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvkeS-0005Lb-JD for p2psip@ietf.org; Fri, 23 Nov 2007 21:21:48 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvkeM-0008L9-L6 for p2psip@ietf.org; Fri, 23 Nov 2007 21:21:48 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRZ006RSNUMGW@szxga02-in.huawei.com> for p2psip@ietf.org; Sat, 24 Nov 2007 10:20:47 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRZ00G4ENUL1X@szxga02-in.huawei.com> for p2psip@ietf.org; Sat, 24 Nov 2007 10:20:46 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRZ00DHQNULMV@szxml04-in.huawei.com> for p2psip@ietf.org; Sat, 24 Nov 2007 10:20:45 +0800 (CST) Date: Sat, 24 Nov 2007 10:20:45 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Routing mode in P2PSIP In-reply-to: <20d2bdfb0711230729o249c19ccwe1cfc60d86da5b28@mail.gmail.com> To: 'Bruce Lowekamp' Message-id: <000601c82e40$9ea4bc40$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acgt5daHRaFDNU+CTeuCXqXzyqq/hwAVAi6A X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > "All" peers behind NATs does require some sort of publicly available > bootstrap server (although that can be a peer behind a NAT with > address independent mapping and filtering). After the initial > bootstrap, most communication is routed across the overlay. > To open a new connection (for a fingertable entry, for example), any > pair of peers except those where both are behind evil (symmetric) NATs > will be able to open that connection using ICE. If they are both > behind evil NATs, for any fingertable entry (in chord), you can pretty > much just ignore the failure because those neighbors exist just as an > optimization. But you really do need to have a connection with your > predecessor and successor. reload-02 proposes a mechanism for > identifying a turn server that peers could use to establish > connectivity in that situation. But we anticipate that, even with all > peers behind NATs, both peers being behind evil NATs will be extremely > rare. > > The turn location mechanism in reload-02 hypothesizes that it will be > easy to determine the percentage of peers that can serve as turn > servers. I should also mention that we need to add some text on > letting peers behind good NATs be turn servers as well---even if you > need to use ICE to open a connection with the turn server itself, > there's no reason every peer behind a good NAT can't be a turn server. > That essentially lets almost all peers be turn servers. What I really am very interested in: How are the peers with good property learned? By itself or by others? > > Iterative and symmetric both work in the presence of NATs. > semi-recursive really doesn't without some help and a fallback on > symmetric recursive (see my response at the bottom). Semi-recursive may fail. It also falls back to a asymmetric method proposed in SEP, which you could find at http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt; IMHO, iterative also may not work without help from other method. If the source peer gets the next hop peer, with which there is no direct connection. It may use the peer ID of next hop peer to arrive at the next hop peer. > If you're configured with a stun server on the other side of a nat or > you communicate with a peer on the other side of a nat, then you know > you're behind one. However, you can't ever prove that you're not > behind a NAT. (could be on a NATed network that's using public-range > IP addresses and you just happen not to have talked with anyone on the > other side. Or you could be on a large private network in the private > address range that doesn't have any connectivity with the outside, in > which case you're not behind a NAT.) I agree with you that the location of the stun server will influence the determination. But I think a stun server deployed on the public internet could achieve this goal. > > > >Retransmission is handled end-to-end. So the > > > responder still doesn't have a way of knowing for sure if the response > > > got back, but it can assume that it was just random packet loss and > > > keep sending the response whenever it gets a retransmission until the > > > sender receives it. > > > > Due to the same reason as above, we should consider the possible loss from > > overlay churn, not only just assume it is a random packet loss. > > Regular end-to-end retransmission should handle this. If you have an > overlay that has so much churn that you can't get a message routed > round-trip, you're going to have problems with any routing algorithm. > (and I'm not trying to trivialize the complexity of dealing with > churn. it's really hard, but if your peers detect a failed link > quickly, symmetric recursive works about as well as anything) Yes, I assume the churn rate may be low. But it does exist. Let's show an example if there is one peer in the route list which failed or leaved while the response goes back. Say the request starts from the A, and traverse B, C and D, and finally arrive at the destination X. If the peer C fails before the response reaches it. So the D should route the response based on the peer ID C. Later a peer Y who is responsible for the key C and send the response based on B. But there is no matched connection, so X has to route the response through the overlay. and B receives the response and forward it to the A. >From the above example, the response has to be routed through the overlay two more cycles and introduce the more latency. And it becomes worse, if the packet is of big size. > > There is another issue I am also interested: how do the RELOAD-2 determine > > the end-to-end timeout period? > > reload-02 proposes to use the standard sip timeout scheme. I am not familiar with the sip timeout scheme. Intuitively, I think it would be more complicated than in sip because the latency may vary largely between different transactions. > > To implement semi-recursive, you need to make the link-layer protocol > a bit more complex. If you have an ack go between the querying peer > and the answering peer after the final response is received, then the > answering peer knows the response was received. If no ack is > received, then you need the answering peer to do something else, like > return the response along the reverse path when it receives a first or > second retransmission of the original request. IMHO, maybe the asymmetric is the better choice by considering routing efficiency. There may be several relaying peers which could be tried sequentially. Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 21:25:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvkiQ-0000rR-8N; Fri, 23 Nov 2007 21:25:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvkiO-0000rJ-N6 for p2psip@ietf.org; Fri, 23 Nov 2007 21:25:52 -0500 Received: from nz-out-0506.google.com ([64.233.162.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvkiL-0008Rl-Ed for p2psip@ietf.org; Fri, 23 Nov 2007 21:25:52 -0500 Received: by nz-out-0506.google.com with SMTP id n1so860nzf for ; Fri, 23 Nov 2007 18:25:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=g2RG+KestId3gMrneZz3Nq9NNbUlpI2F+jW1jUDCTII=; b=VcMbQe5Wa39+mNfi+GW2EN56v51WGWEyVPogdNZ+GAek7RZDtnw0KLfDQfuH8y7j0QeNxRRmHnZpAJzuslg/y2lQUpmON6i4Z/OKR5GoNINSyEr/4HpOk5EfBOTsadtf7UfJNW55yz/8VNvBTmaE8mujj16Ik5M6gKizMHb7f2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QbEI0lgISotz08cpPMLgfNXCXBRJx13Mwwy1CLHNUq6VWMbytd3cWGsIZJ6ArwG7bc0WiTJhZJm8IpmJo99CH8AXLGzkv85UHNZwmPcVl7lf/yuuXuNHKlh1J/L4LJvEE/IBpXQkHGy0Vdrhhxo8704sZAYgXv8iss1yAxTv+BI= Received: by 10.142.79.15 with SMTP id c15mr671wfb.1195871148400; Fri, 23 Nov 2007 18:25:48 -0800 (PST) Received: by 10.142.200.16 with HTTP; Fri, 23 Nov 2007 18:25:48 -0800 (PST) Message-ID: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com> Date: Sat, 24 Nov 2007 10:25:48 +0800 From: "lichun li" To: "Eunsoo Shim" Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: To those interested in P2PSIP clients) In-Reply-To: <7b683f3f0711230836u1cb5ce0fhe3f1ce919bb0b471@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <013401c82da5$19ee4ac0$9a00a8c0@mlifewangyao> <7b683f3f0711230752x290e3523i8c70cad46d1a20e8@mail.gmail.com> <7d6b50690711230811r4342cfacm5121a1ba18e18e9b@mail.gmail.com> <7b683f3f0711230836u1cb5ce0fhe3f1ce919bb0b471@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Please see inline. On Nov 24, 2007 12:36 AM, Eunsoo Shim wrote: > Then the transport service is another apsect of the 'routing service'. > It is like that we say the IP layer does routing (while an IP packet > carries a payload). > Somehow the definition of P2PSIP Peer in the concept draft does not > mention 'routing'. > I am going to suggest slight modification of the definition to other authors. I agree. Some explanations about these services should be given. > Back to your draft, non-P2P Clients can certain exist. Actually a > device with just SIP UA is such a device. > But when we consider the overlay layer, such devices are irrelevant. > Nor they affect on the overlay protocol design. It just confuses the > discussion about node types for the overlay. I don't think such > devices should be considered as a type of node in the overlay. I agree. This draft still needs modification. IMO, this type of node is related to P2PSIP. And some SIP UAs may support some SIP extensions for P2PSIP. So I think this type of node should be considered in WG. > Thanks. > > Eunsoo > > > > On Nov 23, 2007 11:11 AM, lichun li wrote: > > We reuse the terms in concept draft. > > In concept draft: > > "In P2PSIP, peers offer storage and transport > > services to allow the distributed database function and distributed > > transport function to be implemented." > > > > > > > > > > On 11/23/07, Eunsoo Shim wrote: > > > The fundamental characteristics of Peers in DHT are the three things: > > > - Participates in overlay maintenance > > > - Provides routing service > > > - Provides storage service. > > > > > > What do you mean by 'transport service'? > > > > > > Thanks. > > > > > > Eunsoo > > > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < yaowang.bupt@gmail.com> wrote: > > > > Hi, everyone. > > > > The attachment is a new I-D mainly talking about different types > > of nodes in P2PSIP. > > > > This document is an attempt to classify different types of node > > in peer-to-peer Session Initiation Protocol (P2PSIP). Four possible > > types of nodes in P2PSIP are discussed based on two characters: whether it > > offers overlay-routing services and whether it offers storage functions. > > The behaviors of each type of nodes and their possible necessities are > > analyzed. This document is dedicated to be a reference for clarifying some > > controversial terms in P2PSIP working group, such as "client", "low-function > > peer", etc. > > > > It is hoped that this document could help the WG to reach a > > rough consensus on the types of node within P2PSIP system and the characters > > of each type's behavior. > > > > > > > > Because the IETF Internet-Draft Submission is closed right now, > > I have to send it as attachment to this maillist. This document will be > > submitted to IETF as soon as IETF Internet-Draft Submission reopened. :) > > > > > > > > Sincerely yours, > > > > > > > > Yao Wang > > > > Mobile Life and New Media Lab, BUPT > > > > > > > > -----Original Message----- > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca] > > > > Sent: Thursday, November 15, 2007 9:00 PM > > > > To: P2PSIP Mailing List > > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > > > A word of advice to all those interested in P2PSIP clients: > > > > > > > > Please write an internet-draft saying why you want clients. State the > > > > problem(s) that clients solve that peers do not. > > > > > > > > More specifically: > > > > * Describe a problem that you want to solve using clients. > > > > * Present a convincing argument why that problem is interesting. > > > > * Present a convincing argument why that problem cannot be solved > > > > using peers. > > > > > > > > DO NOT go into the technical minutia of a client protocol. Just focus > > > > on convincing people that the problem is worthwhile solving and that > > > > some model of clients would be the best way to solve it. > > > > > > > > The WG chairs requested this document at the Prague meeting in the > > > > spring, but I have yet to see it. > > > > > > > > - Philip > > > > > > > > PS. If someone thinks a recently posted draft meets this criteria, > > > > then I would appreciate a pointer to it. > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > -- > > > Eunsoo > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > -- > > Sincerely yours, > > > > Lichun Li > > Mobile Life New Media Lab, BUPT > > > > -- > Eunsoo > -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 21:59:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvlFD-0001LZ-KX; Fri, 23 Nov 2007 21:59:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvlFC-0001Fu-UL for p2psip@ietf.org; Fri, 23 Nov 2007 21:59:46 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvlF8-0000iZ-6r for p2psip@ietf.org; Fri, 23 Nov 2007 21:59:46 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRZ001GBPLXPN@szxga02-in.huawei.com> for p2psip@ietf.org; Sat, 24 Nov 2007 10:58:45 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRZ00K8JPLVPD@szxga02-in.huawei.com> for p2psip@ietf.org; Sat, 24 Nov 2007 10:58:45 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRZ00DI4PLNMY@szxml04-in.huawei.com> for p2psip@ietf.org; Sat, 24 Nov 2007 10:58:43 +0800 (CST) Date: Sat, 24 Nov 2007 10:58:35 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients) In-reply-to: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com> To: 'lichun li' , 'Eunsoo Shim' Message-id: <000001c82e45$eae81ac0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: AcguQZPz+UOfZuZ6T/uMIfxgmNjg0QAAYU3A X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Please see inline. Best regards, Hewen > -----Original Message----- > From: lichun li [mailto:lilichun@gmail.com] > Sent: 2007?11?24? 10:26 > To: Eunsoo Shim > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] New I-D: different types of nodes in > P2PSIP (was: Tothose interested in P2PSIP clients) > > Please see inline. > > On Nov 24, 2007 12:36 AM, Eunsoo Shim wrote: > > Then the transport service is another apsect of the > 'routing service'. > > It is like that we say the IP layer does routing (while an > IP packet > > carries a payload). > > Somehow the definition of P2PSIP Peer in the concept draft does not > > mention 'routing'. > > I am going to suggest slight modification of the definition > to other authors. > > I agree. Some explanations about these services should be given. > > > Back to your draft, non-P2P Clients can certain exist. Actually a > > device with just SIP UA is such a device. > > But when we consider the overlay layer, such devices are irrelevant. > > Nor they affect on the overlay protocol design. It just > confuses the > > discussion about node types for the overlay. I don't think such > > devices should be considered as a type of node in the overlay. > > I agree. This draft still needs modification. IMO, this type > of node is related to P2PSIP. And some SIP UAs may support > some SIP extensions for P2PSIP. So I think this type of node > should be considered in WG. [Hewen] There is already a consensus in IETF69 that the P2P layer should be distinct from the SIP layer, the last Concept document (-v01) records it in Section 5.7. In fact, a device only with SIP UA is now regarded as a device irrelevant to P2P layer. > > > Thanks. > > > > Eunsoo > > > > > > > > On Nov 23, 2007 11:11 AM, lichun li wrote: > > > We reuse the terms in concept draft. > > > In concept draft: > > > "In P2PSIP, peers offer storage and transport > > > services to allow the distributed database function > and distributed > > > transport function to be implemented." > > > > > > > > > > > > > > > On 11/23/07, Eunsoo Shim wrote: > > > > The fundamental characteristics of Peers in DHT are the > three things: > > > > - Participates in overlay maintenance > > > > - Provides routing service > > > > - Provides storage service. > > > > > > > > What do you mean by 'transport service'? > > > > > > > > Thanks. > > > > > > > > Eunsoo > > > > > > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < > yaowang.bupt@gmail.com> wrote: > > > > > Hi, everyone. > > > > > The attachment is a new I-D mainly talking about > > > > > different types > > > of nodes in P2PSIP. > > > > > This document is an attempt to classify > different types > > > > > of node > > > in peer-to-peer Session Initiation Protocol (P2PSIP). > Four possible > > > types of nodes in P2PSIP are discussed based on two characters: > > > whether it offers overlay-routing services and whether it > offers storage functions. > > > The behaviors of each type of nodes and their possible > necessities > > > are analyzed. This document is dedicated to be a reference for > > > clarifying some controversial terms in P2PSIP working > group, such as > > > "client", "low-function peer", etc. > > > > > It is hoped that this document could help the WG to > > > > > reach a > > > rough consensus on the types of node within P2PSIP system and the > > > characters of each type's behavior. > > > > > > > > > > Because the IETF Internet-Draft Submission is closed > > > > > right now, > > > I have to send it as attachment to this maillist. This > document will > > > be submitted to IETF as soon as IETF Internet-Draft Submission > > > reopened. :) > > > > > > > > > > Sincerely yours, > > > > > > > > > > Yao Wang > > > > > Mobile Life and New Media Lab, BUPT > > > > > > > > > > -----Original Message----- > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca] > > > > > Sent: Thursday, November 15, 2007 9:00 PM > > > > > To: P2PSIP Mailing List > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > > > > > A word of advice to all those interested in P2PSIP clients: > > > > > > > > > > Please write an internet-draft saying why you want clients. > > > > > State the > > > > > problem(s) that clients solve that peers do not. > > > > > > > > > > More specifically: > > > > > * Describe a problem that you want to solve using clients. > > > > > * Present a convincing argument why that problem is > interesting. > > > > > * Present a convincing argument why that problem cannot be > > > > > solved using peers. > > > > > > > > > > DO NOT go into the technical minutia of a client > protocol. Just > > > > > focus on convincing people that the problem is worthwhile > > > > > solving and that some model of clients would be the > best way to solve it. > > > > > > > > > > The WG chairs requested this document at the Prague > meeting in > > > > > the spring, but I have yet to see it. > > > > > > > > > > - Philip > > > > > > > > > > PS. If someone thinks a recently posted draft meets this > > > > > criteria, then I would appreciate a pointer to it. > > > > > > > > > > _______________________________________________ > > > > > P2PSIP mailing list > > > > > P2PSIP@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > _______________________________________________ > > > > > P2PSIP mailing list > > > > > P2PSIP@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Eunsoo > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > -- > > > Sincerely yours, > > > > > > Lichun Li > > > Mobile Life New Media Lab, BUPT > > > > > > > > -- > > Eunsoo > > > > > > -- > Sincerely yours, > > Lichun Li > Mobile Life New Media Lab, BUPT > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 22:05:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvlLA-0000NH-6Z; Fri, 23 Nov 2007 22:05:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvlL9-0000NC-4K for p2psip@ietf.org; Fri, 23 Nov 2007 22:05:55 -0500 Received: from szxga04-in.huawei.com ([61.144.161.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IvlL2-0000t5-Uw for p2psip@ietf.org; Fri, 23 Nov 2007 22:05:55 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRZ00GHNPW7IP@szxga04-in.huawei.com> for p2psip@ietf.org; Sat, 24 Nov 2007 11:04:55 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JRZ003L8PW6GI@szxga04-in.huawei.com> for p2psip@ietf.org; Sat, 24 Nov 2007 11:04:55 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JRZ00CCUPW6E9@szxml03-in.huawei.com> for p2psip@ietf.org; Sat, 24 Nov 2007 11:04:54 +0800 (CST) Date: Sat, 24 Nov 2007 11:04:53 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Routing mode in P2PSIP In-reply-to: <925F6CE8-D2AC-4E9D-A294-4A54DF00570C@cisco.com> To: 'Cullen Jennings' Message-id: <000701c82e46$c9789350$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AcguApVRSRRCZtjKSXyE6YqMZBAKWAAPh9FA X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Thanks for your response. See inline. What I really suggest is to include the semi-recursive in the list of the candidate routing mode due to its advantages over other methods. Of course, there are some issues of the semi-recursive routing mode to be solved. After we come to the consensus that the semi-recursive is useful to peer protocol, we could start to figure out how it realizes. Regards! -- Jiang XingFeng > > Hi - I'm not sure I understand what you mean by semi-recursive and > how it would work. Could you explain a bit how it works and what > would be needed in reload to support it. I give short answer here. For more details, please refer to http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt; thanks! I have some ideas about this issue: how does the responder send the response back to the source peer directly if the source peer is behind NAT? Maybe we could choose some peers which are on the public Internet or behind good NAT (endpoint-independent mapping and filtering) and the responder could ask them to relay the response to the source peer. Because the chosen relaying peers are on the public internet or behind good NAT, so the response could arrive at these relaying peers. So the problem is reduced to how the relaying peer knows how to relay the response to the source peer. IMHO, there are two candidate solutions: 1. The source peer could find in its routing states some neighbor peers with public address. Since the source peer and the relaying peer are neighbors, so there must be at least a pre-established connection between them. So if the relaying peer receives the response from the responder, it will check whether it has a pre-established connection with the source peer. If there is, forward the response over the connection. If there is none, maybe it discards the response for security consideration. It is like what the TURN does. TURN relays the packet from the peer only if there is permission for the peer. 2. If there is no such neighbor peers in its routing states, the source peer could use an alternative method. It could find a public peer and send the request to this peer. Upon receiving the request, the public peer could learn the source transport address of the request and put it in the request. Later the request will be processed by the responder and the response will be returned to the relaying peer. The relaying peer could check whether the source peer's transport address in the response, if it is, the public relaying peer uses this transport address to forward the response to the source peer. > I'm always curios about how > a node decides what to do when there are multiple options available > to it. > Do you mean what the responder does when there are several relaying peers available? If my understanding is right, the responder could send the response parallelly for the reliability of the response; > Thanks, Cullen > > On Nov 20, 2007, at 2:27 AM, JiangXingFeng wrote: > > > Hi, > > > > There are four routing mode described in the draft-bryan-p2psip- > > reload-01. > > After reading P2PP and RELOAD revision 2, only the iterative > > routing mode > > and recursive mode are supported. > > > > Why doesn't P2PSIP peer protocol support semi-recursive mode? IMHO, > > semi-recursive mode at least has two following advantages over > > other routing > > mode: > > 1. Semi-recursive mode is more resilient from failures of > > intermediate peers > > than recursive mode. In recursive mode, if any of the intermediate > > peers > > fails, the response could not return back in the reverse path the > > request > > has traversed. > > 2. Semi-recursive mode has lower latency than recursive and > > iterative mode. > > The response in semi-recursive mode could go back to the request > > originator > > by forwarding based on its transport address. > > > > IMHO, the major issue that semi-recursive mode should face is how the > > response goes to the request originator if the request originator > > is behind > > NAT. I think there must be solution to this issue. > > > > Comments? > > > > -- > > Jiang XingFeng > > > > > > > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 23:42:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvmqC-0003Ck-Ny; Fri, 23 Nov 2007 23:42:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvmqB-0003Cd-Bp for p2psip@ietf.org; Fri, 23 Nov 2007 23:42:03 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivmq9-00039z-0f for p2psip@ietf.org; Fri, 23 Nov 2007 23:42:03 -0500 Received: by rv-out-0910.google.com with SMTP id l15so20856rvb for ; Fri, 23 Nov 2007 20:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ROFLR2LHCn7H4Lb0JcsjtTdqO0O/1aKgcp0yCuh1N68=; b=gBP441P2kTPgnDufD22hh+H+6B6dJ7Ws8+YC4ZvRnWDE3Nknw7zpIUdMCgKQ1mq2D1l0bYDK+hjSKc1ZGNuLeOmR1FduT78zSL5dTXjplvkRRgDPnMxgCUFUPAem/IMnyIVOVS2fhJ4IJZ3690JZrcdHNbqAO9W3Nqurtr1AtpA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BQrC93CoNASDByTgzz6pgTwDicG4YlYdPzNRyI0e1fxgDkYZ3bsdquLBbsdJx4crSKMmyagrOgk0K9EW8hiCZZinBKMqK76lQvWlxILfj9YoYG1dicfHiCXdVVqFUJU9iMjE9MNI848mvVHjFLehFMmMK9P8hoPxOyty8sjqeNw= Received: by 10.142.231.7 with SMTP id d7mr6862wfh.1195879320222; Fri, 23 Nov 2007 20:42:00 -0800 (PST) Received: by 10.142.200.16 with HTTP; Fri, 23 Nov 2007 20:42:00 -0800 (PST) Message-ID: <7d6b50690711232042i2f4bfe9au65c0b5b38a8e40b5@mail.gmail.com> Date: Sat, 24 Nov 2007 12:42:00 +0800 From: "lichun li" To: "Zheng Hewen" Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients) In-Reply-To: <000001c82e45$eae81ac0$5105a40a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com> <000001c82e45$eae81ac0$5105a40a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I also think the P2P layer should be distinct from the SIP layer. On Nov 24, 2007 10:58 AM, Zheng Hewen wrote: > Hi, > > Please see inline. > > Best regards, > Hewen > > > > -----Original Message----- > > From: lichun li [mailto:lilichun@gmail.com] > > Sent: 2007?11?24? 10:26 > > To: Eunsoo Shim > > Cc: P2PSIP Mailing List > > Subject: Re: [P2PSIP] New I-D: different types of nodes in > > P2PSIP (was: Tothose interested in P2PSIP clients) > > > > Please see inline. > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim wrote: > > > Then the transport service is another apsect of the > > 'routing service'. > > > It is like that we say the IP layer does routing (while an > > IP packet > > > carries a payload). > > > Somehow the definition of P2PSIP Peer in the concept draft does not > > > mention 'routing'. > > > I am going to suggest slight modification of the definition > > to other authors. > > > > I agree. Some explanations about these services should be given. > > > > > Back to your draft, non-P2P Clients can certain exist. Actually a > > > device with just SIP UA is such a device. > > > But when we consider the overlay layer, such devices are irrelevant. > > > Nor they affect on the overlay protocol design. It just > > confuses the > > > discussion about node types for the overlay. I don't think such > > > devices should be considered as a type of node in the overlay. > > > > I agree. This draft still needs modification. IMO, this type > > of node is related to P2PSIP. And some SIP UAs may support > > some SIP extensions for P2PSIP. So I think this type of node > > should be considered in WG. > > [Hewen] There is already a consensus in IETF69 that the P2P layer should be distinct from the SIP layer, the last Concept > document (-v01) records it in Section 5.7. In fact, a device only with SIP UA is now regarded as a device irrelevant to P2P > layer. > > > > > > > Thanks. > > > > > > Eunsoo > > > > > > > > > > > > On Nov 23, 2007 11:11 AM, lichun li wrote: > > > > We reuse the terms in concept draft. > > > > In concept draft: > > > > "In P2PSIP, peers offer storage and transport > > > > services to allow the distributed database function > > and distributed > > > > transport function to be implemented." > > > > > > > > > > > > > > > > > > > > On 11/23/07, Eunsoo Shim wrote: > > > > > The fundamental characteristics of Peers in DHT are the > > three things: > > > > > - Participates in overlay maintenance > > > > > - Provides routing service > > > > > - Provides storage service. > > > > > > > > > > What do you mean by 'transport service'? > > > > > > > > > > Thanks. > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < > > yaowang.bupt@gmail.com> wrote: > > > > > > Hi, everyone. > > > > > > The attachment is a new I-D mainly talking about > > > > > > different types > > > > of nodes in P2PSIP. > > > > > > This document is an attempt to classify > > different types > > > > > > of node > > > > in peer-to-peer Session Initiation Protocol (P2PSIP). > > Four possible > > > > types of nodes in P2PSIP are discussed based on two characters: > > > > whether it offers overlay-routing services and whether it > > offers storage functions. > > > > The behaviors of each type of nodes and their possible > > necessities > > > > are analyzed. This document is dedicated to be a reference for > > > > clarifying some controversial terms in P2PSIP working > > group, such as > > > > "client", "low-function peer", etc. > > > > > > It is hoped that this document could help the WG to > > > > > > reach a > > > > rough consensus on the types of node within P2PSIP system and the > > > > characters of each type's behavior. > > > > > > > > > > > > Because the IETF Internet-Draft Submission is closed > > > > > > right now, > > > > I have to send it as attachment to this maillist. This > > document will > > > > be submitted to IETF as soon as IETF Internet-Draft Submission > > > > reopened. :) > > > > > > > > > > > > Sincerely yours, > > > > > > > > > > > > Yao Wang > > > > > > Mobile Life and New Media Lab, BUPT > > > > > > > > > > > > -----Original Message----- > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca] > > > > > > Sent: Thursday, November 15, 2007 9:00 PM > > > > > > To: P2PSIP Mailing List > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > > > > > > > A word of advice to all those interested in P2PSIP clients: > > > > > > > > > > > > Please write an internet-draft saying why you want clients. > > > > > > State the > > > > > > problem(s) that clients solve that peers do not. > > > > > > > > > > > > More specifically: > > > > > > * Describe a problem that you want to solve using clients. > > > > > > * Present a convincing argument why that problem is > > interesting. > > > > > > * Present a convincing argument why that problem cannot be > > > > > > solved using peers. > > > > > > > > > > > > DO NOT go into the technical minutia of a client > > protocol. Just > > > > > > focus on convincing people that the problem is worthwhile > > > > > > solving and that some model of clients would be the > > best way to solve it. > > > > > > > > > > > > The WG chairs requested this document at the Prague > > meeting in > > > > > > the spring, but I have yet to see it. > > > > > > > > > > > > - Philip > > > > > > > > > > > > PS. If someone thinks a recently posted draft meets this > > > > > > criteria, then I would appreciate a pointer to it. > > > > > > > > > > > > _______________________________________________ > > > > > > P2PSIP mailing list > > > > > > P2PSIP@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > _______________________________________________ > > > > > > P2PSIP mailing list > > > > > > P2PSIP@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Eunsoo > > > > > > > > > > _______________________________________________ > > > > > P2PSIP mailing list > > > > > P2PSIP@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > -- > > > > Sincerely yours, > > > > > > > > Lichun Li > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > -- > > > Eunsoo > > > > > > > > > > > -- > > Sincerely yours, > > > > Lichun Li > > Mobile Life New Media Lab, BUPT > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 23 23:46:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivmuw-00018S-6W; Fri, 23 Nov 2007 23:46:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivmuv-00018I-6c for p2psip@ietf.org; Fri, 23 Nov 2007 23:46:57 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivmus-0003Hx-8i for p2psip@ietf.org; Fri, 23 Nov 2007 23:46:57 -0500 Received: by rv-out-0910.google.com with SMTP id l15so21708rvb for ; Fri, 23 Nov 2007 20:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=2TG2n8B9EBhmAOysA7FACf3TqqHEzXoD0keiY7Uc0Co=; b=CoACTTJ+n0uwdi5QAwTmLJwN4cwP3RrEJkl1pPp9B/G2apQl5nu2BNTSrMBObpLPR0HPhtGdFjI6zKw92hrMmXqJ8O1OqtiGsZ4zHU22rFJVMeBi6+Fl3ogQARuaEUmcd6O68tDP6tlrV4zJ/ivmK/ob/4agtH5qbj2ikpLpPy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TN14mFBxyWpH3doGV3vY/H4cYvaWuiJXillJ7EBTamLRRsDjPaE9qAeymb3qiqG68ZhKYJmysPMelwZEyA5DJxvpyWO4jXWyrF061Tfd7dH2Sk37pVyE17KqXh/4G4ibsncmdfVvO705+wdusPPQgOS1nRzaiO4fwExJxs39gVo= Received: by 10.140.199.19 with SMTP id w19mr38011rvf.1195879613640; Fri, 23 Nov 2007 20:46:53 -0800 (PST) Received: by 10.141.177.20 with HTTP; Fri, 23 Nov 2007 20:46:53 -0800 (PST) Message-ID: <7b683f3f0711232046o63dc2f03j2f2a47855d40dbbd@mail.gmail.com> Date: Fri, 23 Nov 2007 23:46:53 -0500 From: "Eunsoo Shim" To: "lichun li" Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients) In-Reply-To: <7d6b50690711232042i2f4bfe9au65c0b5b38a8e40b5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com> <000001c82e45$eae81ac0$5105a40a@china.huawei.com> <7d6b50690711232042i2f4bfe9au65c0b5b38a8e40b5@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org The node type 3 in the draft provides the storage service but the routing service (transport service). Could you describe a scenario where a device is not capable of providing the routing service but capable of providing the storage service? Thanks. Eunsoo On Nov 23, 2007 11:42 PM, lichun li wrote: > I also think the P2P layer should be distinct from the SIP layer. > > > On Nov 24, 2007 10:58 AM, Zheng Hewen wrote: > > Hi, > > > > Please see inline. > > > > Best regards, > > Hewen > > > > > > > -----Original Message----- > > > From: lichun li [mailto:lilichun@gmail.com] > > > Sent: 2007?11?24? 10:26 > > > To: Eunsoo Shim > > > Cc: P2PSIP Mailing List > > > Subject: Re: [P2PSIP] New I-D: different types of nodes in > > > P2PSIP (was: Tothose interested in P2PSIP clients) > > > > > > Please see inline. > > > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim wrote: > > > > Then the transport service is another apsect of the > > > 'routing service'. > > > > It is like that we say the IP layer does routing (while an > > > IP packet > > > > carries a payload). > > > > Somehow the definition of P2PSIP Peer in the concept draft does not > > > > mention 'routing'. > > > > I am going to suggest slight modification of the definition > > > to other authors. > > > > > > I agree. Some explanations about these services should be given. > > > > > > > Back to your draft, non-P2P Clients can certain exist. Actually a > > > > device with just SIP UA is such a device. > > > > But when we consider the overlay layer, such devices are irrelevant. > > > > Nor they affect on the overlay protocol design. It just > > > confuses the > > > > discussion about node types for the overlay. I don't think such > > > > devices should be considered as a type of node in the overlay. > > > > > > I agree. This draft still needs modification. IMO, this type > > > of node is related to P2PSIP. And some SIP UAs may support > > > some SIP extensions for P2PSIP. So I think this type of node > > > should be considered in WG. > > > > [Hewen] There is already a consensus in IETF69 that the P2P layer should be distinct from the SIP layer, the last Concept > > document (-v01) records it in Section 5.7. In fact, a device only with SIP UA is now regarded as a device irrelevant to P2P > > layer. > > > > > > > > > > > Thanks. > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > On Nov 23, 2007 11:11 AM, lichun li wrote: > > > > > We reuse the terms in concept draft. > > > > > In concept draft: > > > > > "In P2PSIP, peers offer storage and transport > > > > > services to allow the distributed database function > > > and distributed > > > > > transport function to be implemented." > > > > > > > > > > > > > > > > > > > > > > > > > On 11/23/07, Eunsoo Shim wrote: > > > > > > The fundamental characteristics of Peers in DHT are the > > > three things: > > > > > > - Participates in overlay maintenance > > > > > > - Provides routing service > > > > > > - Provides storage service. > > > > > > > > > > > > What do you mean by 'transport service'? > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < > > > yaowang.bupt@gmail.com> wrote: > > > > > > > Hi, everyone. > > > > > > > The attachment is a new I-D mainly talking about > > > > > > > different types > > > > > of nodes in P2PSIP. > > > > > > > This document is an attempt to classify > > > different types > > > > > > > of node > > > > > in peer-to-peer Session Initiation Protocol (P2PSIP). > > > Four possible > > > > > types of nodes in P2PSIP are discussed based on two characters: > > > > > whether it offers overlay-routing services and whether it > > > offers storage functions. > > > > > The behaviors of each type of nodes and their possible > > > necessities > > > > > are analyzed. This document is dedicated to be a reference for > > > > > clarifying some controversial terms in P2PSIP working > > > group, such as > > > > > "client", "low-function peer", etc. > > > > > > > It is hoped that this document could help the WG to > > > > > > > reach a > > > > > rough consensus on the types of node within P2PSIP system and the > > > > > characters of each type's behavior. > > > > > > > > > > > > > > Because the IETF Internet-Draft Submission is closed > > > > > > > right now, > > > > > I have to send it as attachment to this maillist. This > > > document will > > > > > be submitted to IETF as soon as IETF Internet-Draft Submission > > > > > reopened. :) > > > > > > > > > > > > > > Sincerely yours, > > > > > > > > > > > > > > Yao Wang > > > > > > > Mobile Life and New Media Lab, BUPT > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca] > > > > > > > Sent: Thursday, November 15, 2007 9:00 PM > > > > > > > To: P2PSIP Mailing List > > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > > > > > > > > > A word of advice to all those interested in P2PSIP clients: > > > > > > > > > > > > > > Please write an internet-draft saying why you want clients. > > > > > > > State the > > > > > > > problem(s) that clients solve that peers do not. > > > > > > > > > > > > > > More specifically: > > > > > > > * Describe a problem that you want to solve using clients. > > > > > > > * Present a convincing argument why that problem is > > > interesting. > > > > > > > * Present a convincing argument why that problem cannot be > > > > > > > solved using peers. > > > > > > > > > > > > > > DO NOT go into the technical minutia of a client > > > protocol. Just > > > > > > > focus on convincing people that the problem is worthwhile > > > > > > > solving and that some model of clients would be the > > > best way to solve it. > > > > > > > > > > > > > > The WG chairs requested this document at the Prague > > > meeting in > > > > > > > the spring, but I have yet to see it. > > > > > > > > > > > > > > - Philip > > > > > > > > > > > > > > PS. If someone thinks a recently posted draft meets this > > > > > > > criteria, then I would appreciate a pointer to it. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > P2PSIP mailing list > > > > > > > P2PSIP@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > _______________________________________________ > > > > > > > P2PSIP mailing list > > > > > > > P2PSIP@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Eunsoo > > > > > > > > > > > > _______________________________________________ > > > > > > P2PSIP mailing list > > > > > > P2PSIP@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sincerely yours, > > > > > > > > > > Lichun Li > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > > > > > -- > > > > Eunsoo > > > > > > > > > > > > > > > > -- > > > Sincerely yours, > > > > > > Lichun Li > > > Mobile Life New Media Lab, BUPT > > > > > > _______________________________________________ > > > P2PSIP mailing list > > > P2PSIP@ietf.org > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > -- > > Sincerely yours, > > Lichun Li > Mobile Life New Media Lab, BUPT > -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sat Nov 24 04:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivqsq-0002Qz-2k; Sat, 24 Nov 2007 04:01:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivqso-0002Qk-JW for p2psip@ietf.org; Sat, 24 Nov 2007 04:01:02 -0500 Received: from mail33-43.sinamail.sina.com.cn ([202.108.33.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivqsn-0004Nl-In for p2psip@ietf.org; Sat, 24 Nov 2007 04:01:02 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAHJMR0cKNgZi/3poAKMA Received: from dellwei (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id B538814DDC0E for ; Sat, 24 Nov 2007 17:00:58 +0800 (CST) Message-ID: <008c01c82e78$86e818d0$da07740a@dellwei> From: "Wei Gengyu" To: "P2PSIP Mailing List" References: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com><000001c82e45$eae81ac0$5105a40a@china.huawei.com> <7d6b50690711232042i2f4bfe9au65c0b5b38a8e40b5@mail.gmail.com> Date: Sat, 24 Nov 2007 17:00:56 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.8 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [P2PSIP] P2P layer and Peer Identifier X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1986427311==" Errors-To: p2psip-bounces@ietf.org --===============1986427311== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGksIGFsbCwNCg0KSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgUDJQIGxheWVyIGFuZCBQZWVyIElk ZW50aWZpZXI/DQoNCldoZW4gc2F5aW5nIFAyUCBsYXllciwgYXJlIHRoZSBlbnRpdGllcyBhdCB0 aGUgbGF5ZXIgaWRlbnRpZmllZCBieSBQZWVyIElkZW50aWZpZXJzPw0KVGhlIFBlZXIgSWRlbnRp ZmllciBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBlbnRpdHkgYXQgYXBwbGljYXRpb24gbGF5ZXIg b2YgSW50ZXJuZXQuDQpJdCBzZWVtcyB0aGF0IHRoZSBQZWVyIElkZW50aWZpZXIgaXMgZ2VuZXJh dGVkIGJ5IERIVC4NCklzIHRoZXJlIGFub3RoZXIgIGZvcm1hdCBvZiBQZWVyIElkZW50aWZpZXIg d2hpY2ggaXMgcmVhZGFibGUsIHNvbWV0aGluZyBsaWtlIFVSST8NCg0KQW5kIHRoZSBQZWVyIElk ZW50aWZpZXIgc2hvdWxkIG5vdCBiZSB0aGUgc2FtZSBhcyB0aGUgSG9zdCBJZGVudGlmaWVyIG9y IE5vZGUgSWRlbnRpZmllciBpbiB0aGUgSW50ZXJuZXQuDQpUaGUgUDJQIGxheWVyIHByb3ZpZGVz IGEgc2VydmljZSBtYXBwaW5nIHRoZSBQZWVyIElkZW50aWZpZXIgdG8gSG9zdCBJZGVudGlmaWVy IGFzc29jaWF0ZWQgd2l0aCBhIElQIGFkZHJlc3Mgb3IgYWRkcmVzc2VzLiANCg0KU28sIFBlZXIg SWRlbnRpZmllciBpcyBub3QgYSBIb3N0IElkZW50aWZpZXIgb3IgSVAgYWRkcmVzcy4NCg0KSSB3 b3VsZCBsaWtlIHRvIGJlIGVkdWNhdGVkLg0KSXQgd2lsbCBiZSBoZWxwZnVsIGZvciBtZSB0byB1 bmRlcnN0YW5kIEhJUC4NCg0KQmVzdCByZWdhcmRzLCANCg0KR2VuZ3l1DQoNCi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAibGljaHVuIGxpIiA8bGlsaWNodW5AZ21haWwuY29t Pg0KVG86ICJaaGVuZyBIZXdlbiIgPGh3emhlbmdAaHVhd2VpLmNvbT4NCkNjOiAiUDJQU0lQIE1h aWxpbmcgTGlzdCIgPHAycHNpcEBpZXRmLm9yZz4NClNlbnQ6IFNhdHVyZGF5LCBOb3ZlbWJlciAy NCwgMjAwNyAxMjo0MiBQTQ0KU3ViamVjdDogUmU6IFtQMlBTSVBdIE5ldyBJLUQ6IGRpZmZlcmVu dCB0eXBlcyBvZiBub2RlcyBpbiBQMlBTSVAgKHdhczpUb3Rob3NlIGludGVyZXN0ZWQgaW4gUDJQ U0lQIGNsaWVudHMpDQoNCg0KPkkgYWxzbyB0aGluayB0aGUgUDJQIGxheWVyIHNob3VsZCBiZSBk aXN0aW5jdCBmcm9tIHRoZSBTSVAgbGF5ZXIuDQo+IA0KPiBPbiBOb3YgMjQsIDIwMDcgMTA6NTgg QU0sIFpoZW5nIEhld2VuIDxod3poZW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPj4gSGksDQo+Pg0K Pj4gICAgUGxlYXNlIHNlZSBpbmxpbmUuDQo+Pg0KPj4gQmVzdCByZWdhcmRzLA0KPj4gSGV3ZW4N Cj4+DQo+Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBQMlBTSVAgbWFpbGluZyBsaXN0DQo+IFAyUFNJUEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnBzaXANCj4= --===============1986427311== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1986427311==-- From p2psip-bounces@ietf.org Sat Nov 24 11:22:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivxlw-00017U-Fs; Sat, 24 Nov 2007 11:22:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivxlv-00017K-IX for p2psip@ietf.org; Sat, 24 Nov 2007 11:22:23 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ivxls-0007q7-2C for p2psip@ietf.org; Sat, 24 Nov 2007 11:22:23 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id DEF5833C21; Sat, 24 Nov 2007 08:17:17 -0800 (PST) Date: Sat, 24 Nov 2007 08:17:17 -0800 From: Eric Rescorla To: JiangXingFeng Subject: Re: [P2PSIP] Routing mode in P2PSIP In-Reply-To: <000701c82e46$c9789350$6905a40a@china.huawei.com> References: <925F6CE8-D2AC-4E9D-A294-4A54DF00570C@cisco.com> <000701c82e46$c9789350$6905a40a@china.huawei.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071124161717.DEF5833C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Sat, 24 Nov 2007 11:04:53 +0800, JiangXingFeng wrote: > > Hi, > Thanks for your response. See inline. > > What I really suggest is to include the semi-recursive in the list of the > candidate routing mode due to its advantages over other methods. Of course, > there are some issues of the semi-recursive routing mode to be solved. After > we come to the consensus that the semi-recursive is useful to peer protocol, > we could start to figure out how it realizes. > > Regards! > -- > Jiang XingFeng > > > > > Hi - I'm not sure I understand what you mean by semi-recursive and > > how it would work. Could you explain a bit how it works and what > > would be needed in reload to support it. > > I give short answer here. For more details, please refer to > http://tools.ietf.org/wg/p2psip/draft-jiang-p2psip-sep-00.txt; thanks! > > I have some ideas about this issue: how does the responder send the response > back to the source peer directly if the source peer is behind NAT? > > Maybe we could choose some peers which are on the public Internet or behind > good NAT (endpoint-independent mapping and filtering) and the responder > could ask them to relay the response to the source peer. Discovering for sure whether you're one of these peers seems somewhat difficult. And then we're faced with the problem of advertising the existence of such peers. That seems like something it would be better not to have as a precondition of success. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 25 20:48:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwT5G-0008Ns-G2; Sun, 25 Nov 2007 20:48:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwT5E-0008Ne-RZ for p2psip@ietf.org; Sun, 25 Nov 2007 20:48:24 -0500 Received: from nz-out-0506.google.com ([64.233.162.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwT5A-0005pg-Dh for p2psip@ietf.org; Sun, 25 Nov 2007 20:48:24 -0500 Received: by nz-out-0506.google.com with SMTP id n1so192364nzf for ; Sun, 25 Nov 2007 17:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=qGusd3oqhuK5y7YZqYrPK6lqMK4lFqvx/y7EPTRNElY=; b=vWOtJQKv0byKdbYiEV0oAxMylF8K/4lcSQBvYYBagEjRuPwJcQGimaA8Oe+3aW11M+RulfExt0jpszfmfGjhV+16VWJ5ghdEKktvZ9rT6NzRvG+q7hK+mGWSsNxI/lUNPiSCSJ69faMfbT0Hg3WGbwWsJd1HUVeJ1AHA8MMbc+0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=MUOD3JkE46GlQEZ38jYu8C9y2x8ICI2ShDbfG8s6vm4x6DeSyRgUmm9og6JtfbFIl0wdAoT+IY8+sOpauGFIxUJgnch2OJZFysVn3L8UnHzcNCKo5s0+2dOMVrgD+MihFKmySPSXQx2CviXQ/2B7WDvF/HD/vWCrdcquBozjM9E= Received: by 10.143.157.10 with SMTP id j10mr174635wfo.1196041699287; Sun, 25 Nov 2007 17:48:19 -0800 (PST) Received: by 10.142.200.16 with HTTP; Sun, 25 Nov 2007 17:48:19 -0800 (PST) Message-ID: <7d6b50690711251748k3293f294s68eab0e12fe8f1ac@mail.gmail.com> Date: Mon, 26 Nov 2007 09:48:19 +0800 From: "lichun li" To: "Eunsoo Shim" Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients) In-Reply-To: <7b683f3f0711232046o63dc2f03j2f2a47855d40dbbd@mail.gmail.com> MIME-Version: 1.0 References: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com> <000001c82e45$eae81ac0$5105a40a@china.huawei.com> <7d6b50690711232042i2f4bfe9au65c0b5b38a8e40b5@mail.gmail.com> <7b683f3f0711232046o63dc2f03j2f2a47855d40dbbd@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0685632664==" Errors-To: p2psip-bounces@ietf.org --===============0685632664== Content-Type: multipart/alternative; boundary="----=_Part_2024_28195017.1196041699264" ------=_Part_2024_28195017.1196041699264 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline To provide storage service, a device should have enough disk space. If the device doesn't support the routing algorithm, it is not capable of providing the routing service. For example, a node only supporting Chord can not be a peer in bamboo overlay. If the device has poor connectivity, it's not suitable to provide routing service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe the latency is high. On 11/24/07, Eunsoo Shim wrote: > > The node type 3 in the draft provides the storage service but the > routing service (transport service). > Could you describe a scenario where a device is not capable of > providing the routing service but capable of providing the storage > service? > > Thanks. > > Eunsoo > > On Nov 23, 2007 11:42 PM, lichun li wrote: > > I also think the P2P layer should be distinct from the SIP layer. > > > > > > On Nov 24, 2007 10:58 AM, Zheng Hewen wrote: > > > Hi, > > > > > > Please see inline. > > > > > > Best regards, > > > Hewen > > > > > > > > > > -----Original Message----- > > > > From: lichun li [mailto:lilichun@gmail.com] > > > > Sent: 2007?11?24? 10:26 > > > > To: Eunsoo Shim > > > > Cc: P2PSIP Mailing List > > > > Subject: Re: [P2PSIP] New I-D: different types of nodes in > > > > P2PSIP (was: Tothose interested in P2PSIP clients) > > > > > > > > Please see inline. > > > > > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim wrote: > > > > > Then the transport service is another apsect of the > > > > 'routing service'. > > > > > It is like that we say the IP layer does routing (while an > > > > IP packet > > > > > carries a payload). > > > > > Somehow the definition of P2PSIP Peer in the concept draft does > not > > > > > mention 'routing'. > > > > > I am going to suggest slight modification of the definition > > > > to other authors. > > > > > > > > I agree. Some explanations about these services should be given. > > > > > > > > > Back to your draft, non-P2P Clients can certain exist. Actually a > > > > > device with just SIP UA is such a device. > > > > > But when we consider the overlay layer, such devices are > irrelevant. > > > > > Nor they affect on the overlay protocol design. It just > > > > confuses the > > > > > discussion about node types for the overlay. I don't think such > > > > > devices should be considered as a type of node in the overlay. > > > > > > > > I agree. This draft still needs modification. IMO, this type > > > > of node is related to P2PSIP. And some SIP UAs may support > > > > some SIP extensions for P2PSIP. So I think this type of node > > > > should be considered in WG. > > > > > > [Hewen] There is already a consensus in IETF69 that the P2P layer > should be distinct from the SIP layer, the last Concept > > > document (-v01) records it in Section 5.7. In fact, a device only with > SIP UA is now regarded as a device irrelevant to P2P > > > layer. > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 11:11 AM, lichun li wrote: > > > > > > We reuse the terms in concept draft. > > > > > > In concept draft: > > > > > > "In P2PSIP, peers offer storage and transport > > > > > > services to allow the distributed database function > > > > and distributed > > > > > > transport function to be implemented." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/23/07, Eunsoo Shim wrote: > > > > > > > The fundamental characteristics of Peers in DHT are the > > > > three things: > > > > > > > - Participates in overlay maintenance > > > > > > > - Provides routing service > > > > > > > - Provides storage service. > > > > > > > > > > > > > > What do you mean by 'transport service'? > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < > > > > yaowang.bupt@gmail.com> wrote: > > > > > > > > Hi, everyone. > > > > > > > > The attachment is a new I-D mainly talking about > > > > > > > > different types > > > > > > of nodes in P2PSIP. > > > > > > > > This document is an attempt to classify > > > > different types > > > > > > > > of node > > > > > > in peer-to-peer Session Initiation Protocol (P2PSIP). > > > > Four possible > > > > > > types of nodes in P2PSIP are discussed based on two characters: > > > > > > whether it offers overlay-routing services and whether it > > > > offers storage functions. > > > > > > The behaviors of each type of nodes and their possible > > > > necessities > > > > > > are analyzed. This document is dedicated to be a reference for > > > > > > clarifying some controversial terms in P2PSIP working > > > > group, such as > > > > > > "client", "low-function peer", etc. > > > > > > > > It is hoped that this document could help the WG to > > > > > > > > reach a > > > > > > rough consensus on the types of node within P2PSIP system and > the > > > > > > characters of each type's behavior. > > > > > > > > > > > > > > > > Because the IETF Internet-Draft Submission is closed > > > > > > > > right now, > > > > > > I have to send it as attachment to this maillist. This > > > > document will > > > > > > be submitted to IETF as soon as IETF Internet-Draft Submission > > > > > > reopened. :) > > > > > > > > > > > > > > > > Sincerely yours, > > > > > > > > > > > > > > > > Yao Wang > > > > > > > > Mobile Life and New Media Lab, BUPT > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca] > > > > > > > > Sent: Thursday, November 15, 2007 9:00 PM > > > > > > > > To: P2PSIP Mailing List > > > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > > > > > > > > > > > A word of advice to all those interested in P2PSIP clients: > > > > > > > > > > > > > > > > Please write an internet-draft saying why you want clients. > > > > > > > > State the > > > > > > > > problem(s) that clients solve that peers do not. > > > > > > > > > > > > > > > > More specifically: > > > > > > > > * Describe a problem that you want to solve using clients. > > > > > > > > * Present a convincing argument why that problem is > > > > interesting. > > > > > > > > * Present a convincing argument why that problem cannot be > > > > > > > > solved using peers. > > > > > > > > > > > > > > > > DO NOT go into the technical minutia of a client > > > > protocol. Just > > > > > > > > focus on convincing people that the problem is worthwhile > > > > > > > > solving and that some model of clients would be the > > > > best way to solve it. > > > > > > > > > > > > > > > > The WG chairs requested this document at the Prague > > > > meeting in > > > > > > > > the spring, but I have yet to see it. > > > > > > > > > > > > > > > > - Philip > > > > > > > > > > > > > > > > PS. If someone thinks a recently posted draft meets this > > > > > > > > criteria, then I would appreciate a pointer to it. > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > P2PSIP mailing list > > > > > > > > P2PSIP@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > P2PSIP mailing list > > > > > > > > P2PSIP@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Eunsoo > > > > > > > > > > > > > > _______________________________________________ > > > > > > > P2PSIP mailing list > > > > > > > P2PSIP@ietf.org > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sincerely yours, > > > > > > > > > > > > Lichun Li > > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > > > > > > > > > -- > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > -- > > > > Sincerely yours, > > > > > > > > Lichun Li > > > > Mobile Life New Media Lab, BUPT > > > > > > > > _______________________________________________ > > > > P2PSIP mailing list > > > > P2PSIP@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Sincerely yours, > > > > Lichun Li > > Mobile Life New Media Lab, BUPT > > > > > > -- > Eunsoo > -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_2024_28195017.1196041699264 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
To provide storage service, a device should have enough disk space.
If the device doesn't support the routing algorithm, it is not capable of providing the routing service. For example, a node only supporting Chord can not be a peer in bamboo overlay.
If the device has poor connectivity, it's not suitable to provide routing service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe the latency is high. 
 
On 11/24/07, Eunsoo Shim <eunsooshim@gmail.com> wrote:
The node type 3 in the draft provides the storage service but the
routing service (transport service).
Could you describe a scenario where a device is not capable of
providing the routing service but capable of providing the storage
service?

Thanks.

Eunsoo

On Nov 23, 2007 11:42 PM, lichun li < lilichun@gmail.com> wrote:
> I also think the P2P layer should be distinct from the SIP layer.
>
>
> On Nov 24, 2007 10:58 AM, Zheng Hewen < hwzheng@huawei.com> wrote:
> > Hi,
> >
> >    Please see inline.
> >
> > Best regards,
> > Hewen
> >
> >
> > > -----Original Message-----
> > > From: lichun li [mailto:lilichun@gmail.com]
> > > Sent: 2007?11?24? 10:26
> > > To: Eunsoo Shim
> > > Cc: P2PSIP Mailing List
> > > Subject: Re: [P2PSIP] New I-D: different types of nodes in
> > > P2PSIP (was: Tothose interested in P2PSIP clients)
> > >
> > > Please see inline.
> > >
> > > On Nov 24, 2007 12:36 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > > > Then the transport service is another apsect of the
> > > 'routing service'.
> > > > It is like that we say the IP layer does routing (while an
> > > IP packet
> > > > carries a payload).
> > > > Somehow the definition of P2PSIP Peer in the concept draft does not
> > > > mention 'routing'.
> > > > I am going to suggest slight modification of the definition
> > > to other authors.
> > >
> > > I agree. Some explanations about these services should be given.
> > >
> > > > Back to your draft,  non-P2P Clients can certain exist. Actually a
> > > > device with just SIP UA is such a device.
> > > > But when we consider the overlay layer, such devices are irrelevant.
> > > > Nor they affect on the overlay protocol design. It just
> > > confuses the
> > > > discussion about node types for the overlay. I don't think such
> > > > devices should be considered as a type of node in the overlay.
> > >
> > > I agree. This draft still needs modification. IMO, this type
> > > of node is related to P2PSIP. And some SIP UAs may support
> > > some SIP extensions for P2PSIP. So I think this type of node
> > > should be considered in WG.
> >
> > [Hewen] There is already a consensus in IETF69 that the P2P layer should be distinct from the SIP layer, the last Concept
> > document (-v01) records it in Section 5.7. In fact, a device only with SIP UA is now regarded as a device irrelevant to P2P
> > layer.
> >
> >
> > >
> > > > Thanks.
> > > >
> > > > Eunsoo
> > > >
> > > >
> > > >
> > > > On Nov 23, 2007 11:11 AM, lichun li <lilichun@gmail.com> wrote:
> > > > > We reuse the terms in concept draft.
> > > > > In concept draft:
> > > > > "In P2PSIP, peers offer storage and transport
> > > > >    services to allow the distributed database function
> > > and distributed
> > > > >    transport function to be implemented."
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 11/23/07, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > > > > > The fundamental characteristics of Peers in DHT are the
> > > three things:
> > > > > > - Participates in overlay maintenance
> > > > > > - Provides routing service
> > > > > > - Provides storage service.
> > > > > >
> > > > > > What do you mean by 'transport service'?
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Eunsoo
> > > > > >
> > > > > >
> > > > > > On Nov 23, 2007 2:47 AM, Yao Wang <
> > > yaowang.bupt@gmail.com> wrote:
> > > > > > > Hi, everyone.
> > > > > > >         The attachment is a new I-D mainly talking about
> > > > > > > different types
> > > > > of nodes in P2PSIP.
> > > > > > >         This document is an attempt to classify
> > > different types
> > > > > > > of node
> > > > > in    peer-to-peer Session Initiation Protocol (P2PSIP).
> > > Four possible
> > > > > types of nodes in P2PSIP are discussed based on two characters:
> > > > > whether it offers overlay-routing services and whether it
> > > offers storage functions.
> > > > > The behaviors of each type of nodes and their possible
> > > necessities
> > > > > are analyzed.  This document is dedicated to be a reference for
> > > > > clarifying some controversial terms in P2PSIP working
> > > group, such as
> > > > > "client", "low-function peer", etc.
> > > > > > >         It is hoped that this document could help the WG to
> > > > > > > reach a
> > > > > rough consensus on the types of node within P2PSIP system and the
> > > > > characters of each type's behavior.
> > > > > > >
> > > > > > >         Because the IETF Internet-Draft Submission is closed
> > > > > > > right now,
> > > > > I have to send it as attachment to this maillist. This
> > > document will
> > > > > be submitted to IETF as soon as IETF Internet-Draft Submission
> > > > > reopened. :)
> > > > > > >
> > > > > > > Sincerely yours,
> > > > > > >
> > > > > > > Yao Wang
> > > > > > > Mobile Life and New Media Lab, BUPT
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca ]
> > > > > > > Sent: Thursday, November 15, 2007 9:00 PM
> > > > > > > To: P2PSIP Mailing List
> > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients
> > > > > > >
> > > > > > > A word of advice to all those interested in P2PSIP clients:
> > > > > > >
> > > > > > > Please write an internet-draft saying why you want clients.
> > > > > > > State the
> > > > > > > problem(s) that clients solve that peers do not.
> > > > > > >
> > > > > > > More specifically:
> > > > > > > * Describe a problem that you want to solve using clients.
> > > > > > > * Present a convincing argument why that problem is
> > > interesting.
> > > > > > > * Present a convincing argument why that problem cannot be
> > > > > > > solved using peers.
> > > > > > >
> > > > > > > DO NOT go into the technical minutia of a client
> > > protocol. Just
> > > > > > > focus on convincing people that the problem is worthwhile
> > > > > > > solving and that some model of clients would be the
> > > best way to solve it.
> > > > > > >
> > > > > > > The WG chairs requested this document at the Prague
> > > meeting in
> > > > > > > the spring, but I have yet to see it.
> > > > > > >
> > > > > > > - Philip
> > > > > > >
> > > > > > > PS. If someone thinks a recently posted draft meets this
> > > > > > > criteria, then I would appreciate a pointer to it.
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > P2PSIP mailing list
> > > > > > > P2PSIP@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > P2PSIP mailing list
> > > > > > > P2PSIP@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Eunsoo
> > > > > >
> > > > > > _______________________________________________
> > > > > > P2PSIP mailing list
> > > > > > P2PSIP@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sincerely yours,
> > > > >
> > > > > Lichun Li
> > > > > Mobile Life New Media Lab, BUPT
> > > >
> > > >
> > > >
> > > > --
> > > > Eunsoo
> > > >
> > >
> > >
> > >
> > > --
> > > Sincerely yours,
> > >
> > > Lichun Li
> > > Mobile Life New Media Lab, BUPT
> > >
> > > _______________________________________________
> > > P2PSIP mailing list
> > > P2PSIP@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/p2psip
> > >
> >
> >
> >
> >
>
>
>
> --
>
> Sincerely yours,
>
> Lichun Li
> Mobile Life New Media Lab, BUPT
>



--
Eunsoo



--
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT ------=_Part_2024_28195017.1196041699264-- --===============0685632664== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0685632664==-- From p2psip-bounces@ietf.org Sun Nov 25 21:22:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTbp-0001py-6U; Sun, 25 Nov 2007 21:22:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTbo-0001po-NW for p2psip@ietf.org; Sun, 25 Nov 2007 21:22:04 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwTbo-0001Eq-1N for p2psip@ietf.org; Sun, 25 Nov 2007 21:22:04 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS300LUCD794L@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 10:21:09 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS300H56D794Q@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 10:21:09 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS300K2YD73E5@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 10:21:09 +0800 (CST) Date: Mon, 26 Nov 2007 10:21:03 +0800 From: Song Yongchao Subject: RE: [P2PSIP] Routing mode in P2PSIP In-reply-to: <20071124161717.DEF5833C21@delta.rtfm.com> To: 'Eric Rescorla' Message-id: <002101c82fd3$011027a0$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgutlQaWrcRgsRzTem4VDMs93oz8QBGzKyA X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org [Jiang]> > Maybe we could choose some peers which are on the public Internet or behind > > good NAT (endpoint-independent mapping and filtering) and the responder > > could ask them to relay the response to the source peer. > [Eric]> Discovering for sure whether you're one of these peers seems somewhat > difficult. Eric, could you explain for me why do you think it is difficult to discover that? I am a little confused about whether each peer should have a knowledge of that it is NATed or not, and know its NAT Mapping address or public address or TURN relay address, to set up a direct connection with other peers? Best Regards! Song Yongchao _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 25 21:32:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTlQ-00014b-OD; Sun, 25 Nov 2007 21:32:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTlP-00014L-RR for p2psip@ietf.org; Sun, 25 Nov 2007 21:31:59 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwTlP-0001c3-Cc for p2psip@ietf.org; Sun, 25 Nov 2007 21:31:59 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id B69DE33C21; Sun, 25 Nov 2007 18:26:58 -0800 (PST) Date: Sun, 25 Nov 2007 18:26:58 -0800 From: Eric Rescorla To: Song Yongchao Subject: Re: [P2PSIP] Routing mode in P2PSIP In-Reply-To: <002101c82fd3$011027a0$3e05a40a@china.huawei.com> References: <20071124161717.DEF5833C21@delta.rtfm.com> <002101c82fd3$011027a0$3e05a40a@china.huawei.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071126022658.B69DE33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 26 Nov 2007 10:21:03 +0800, Song Yongchao wrote: > > [Jiang]> > Maybe we could choose some peers which are on the public Internet > or behind > > > good NAT (endpoint-independent mapping and filtering) and the responder > > > could ask them to relay the response to the source peer. > > > [Eric]> Discovering for sure whether you're one of these peers seems > somewhat > > difficult. > > Eric, could you explain for me why do you think it is difficult to discover > that? How do you propose to discover it? It's certainly not enough to have a non-1597 address. Those are still sometimes NATed. You can compare your host candidate to whatever server reflexive candidates you have, but if you're unlucky about STUN server selection, they might still be the same. This complexity is part of why ICE does not attempt to make such determinations. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 25 21:42:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTw1-0003Og-Lg; Sun, 25 Nov 2007 21:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwTvy-0003Gt-Ua for p2psip@ietf.org; Sun, 25 Nov 2007 21:42:55 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwTvv-0007G8-EH for p2psip@ietf.org; Sun, 25 Nov 2007 21:42:54 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS300LG3E5X4L@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 10:41:57 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS3009EKE5WJQ@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 10:41:57 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS3003T1E5WOJ@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 10:41:56 +0800 (CST) Date: Mon, 26 Nov 2007 10:41:56 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Routing mode in P2PSIP In-reply-to: <20071124161717.DEF5833C21@delta.rtfm.com> To: 'Eric Rescorla' Message-id: <001901c82fd5$e91312e0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgutjSDc1dnk8E+Qe2ySkiXXpzfwwBG0Wlg X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Eric: Thanks for your response. I agree with you that semi-recursive mode has a few issues you have pointed out. I also think it could be solved as the research deepens. What I concerns about the recursive mode is its routing efficiency. Using a peer ID to route packet could at least ensure in theory that NAT isn't a problem any more. But latency in recursive for the transaction appears to vary dramastically. It brings the prediction of end-to-end retransmission timeout harder. If the timeout value is set inappropriately, either a lot of retransmission packets go into the overlay or transaction stands with higher latency. Some overlay maintenance operations like Join, Leave, may be insensitive to the routing efficiency. What they want is the reliability and correctness. But some other operations, like GET, are issued upon the request of the user of the overlay. If a SIP UA issues a GET to discover peer's contact address, the time for the lookup will be limited due to real time application's characteristic which has tight demand for call-establishment time. So what I suggest here is to put the semi-recursive in the list of candidate routing modes. BTW: If we have a requirement first, there may be no so many arguments here. How about work out a requirement first and then go to the protocol design work? Regards! JiangXingFeng > Discovering for sure whether you're one of these peers seems somewhat > difficult. And then we're faced with the problem of advertising the > existence of such peers. That seems like something it would be better > not to have as a precondition of success. > > -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Sun Nov 25 23:10:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVIy-0000iw-Uy; Sun, 25 Nov 2007 23:10:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwVIx-0000ij-8k for p2psip@ietf.org; Sun, 25 Nov 2007 23:10:43 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwVIq-0000zD-Q4 for p2psip@ietf.org; Sun, 25 Nov 2007 23:10:43 -0500 Received: by nz-out-0506.google.com with SMTP id n1so214798nzf for ; Sun, 25 Nov 2007 20:10:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=0Q/nP28rMKGSUah84eHAE+7wWrvCwEtdmkbRFCPqORA=; b=J0lfByHRhHl0mu2LGzYDLWw8+4SomKlRpwvoEdNcykPuTiZZRHznlHc8B7s2m5uX7Q51b4c7IQHnX5TmVvBHNB5TSSZFNnrlYPsdXnu0OlgfbAIWHDr+RW+Yzd6s1thyzCWJnbj3Wano1dddpfAqzzL7jcI7eN0c0Z9+c6/PfKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tKdwFJu7cd27JiQ7nOGlH2NYT1wn/3n+umDS/hSU4lCddiseESX2Eifp8cyRSD7yJj0oTxqarMulvcLJYV76NMR9JEqI/CuGagPEwMFXE38KJvqS+jwINeOmcaWNGdhXafXQWMKt2Bg7/lEnhI2eye1INkN2nlG411zo8TWwrYM= Received: by 10.141.141.3 with SMTP id t3mr906823rvn.1196050235834; Sun, 25 Nov 2007 20:10:35 -0800 (PST) Received: by 10.141.177.20 with HTTP; Sun, 25 Nov 2007 20:10:35 -0800 (PST) Message-ID: <7b683f3f0711252010r5811e00j4dbbd278a9ff5a0f@mail.gmail.com> Date: Sun, 25 Nov 2007 23:10:35 -0500 From: "Eunsoo Shim" To: "lichun li" Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients) In-Reply-To: <7d6b50690711251748k3293f294s68eab0e12fe8f1ac@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com> <000001c82e45$eae81ac0$5105a40a@china.huawei.com> <7d6b50690711232042i2f4bfe9au65c0b5b38a8e40b5@mail.gmail.com> <7b683f3f0711232046o63dc2f03j2f2a47855d40dbbd@mail.gmail.com> <7d6b50690711251748k3293f294s68eab0e12fe8f1ac@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 25, 2007 8:48 PM, lichun li wrote: > To provide storage service, a device should have enough disk space. > If the device doesn't support the routing algorithm, it is not capable of > providing the routing service. For example, a node only supporting Chord can > not be a peer in bamboo overlay. Hmm, so what you mean is that a device with enough HW resources and good network conditions become a Client because it does not have the right routing algorithm code. And such a device may provide the storage service. It seems it is a possible scenario. But still I am not sure how much we gain having those Clients provide the storage service. Somehow I feel it just adds complexity without much benefit. Do you see a significant benefit from it? > If the device has poor connectivity, it's not suitable to provide routing > service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe > the latency is high. > Devices with these conditions won't be suitable to provide the storage service. Thanks. Eunsoo > > On 11/24/07, Eunsoo Shim wrote: > > The node type 3 in the draft provides the storage service but the > > routing service (transport service). > > Could you describe a scenario where a device is not capable of > > providing the routing service but capable of providing the storage > > service? > > > > Thanks. > > > > Eunsoo > > > > On Nov 23, 2007 11:42 PM, lichun li < lilichun@gmail.com> wrote: > > > I also think the P2P layer should be distinct from the SIP layer. > > > > > > > > > On Nov 24, 2007 10:58 AM, Zheng Hewen < hwzheng@huawei.com> wrote: > > > > Hi, > > > > > > > > Please see inline. > > > > > > > > Best regards, > > > > Hewen > > > > > > > > > > > > > -----Original Message----- > > > > > From: lichun li [mailto:lilichun@gmail.com] > > > > > Sent: 2007?11?24? 10:26 > > > > > To: Eunsoo Shim > > > > > Cc: P2PSIP Mailing List > > > > > Subject: Re: [P2PSIP] New I-D: different types of nodes in > > > > > P2PSIP (was: Tothose interested in P2PSIP clients) > > > > > > > > > > Please see inline. > > > > > > > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > > > > Then the transport service is another apsect of the > > > > > 'routing service'. > > > > > > It is like that we say the IP layer does routing (while an > > > > > IP packet > > > > > > carries a payload). > > > > > > Somehow the definition of P2PSIP Peer in the concept draft does > not > > > > > > mention 'routing'. > > > > > > I am going to suggest slight modification of the definition > > > > > to other authors. > > > > > > > > > > I agree. Some explanations about these services should be given. > > > > > > > > > > > Back to your draft, non-P2P Clients can certain exist. Actually a > > > > > > device with just SIP UA is such a device. > > > > > > But when we consider the overlay layer, such devices are > irrelevant. > > > > > > Nor they affect on the overlay protocol design. It just > > > > > confuses the > > > > > > discussion about node types for the overlay. I don't think such > > > > > > devices should be considered as a type of node in the overlay. > > > > > > > > > > I agree. This draft still needs modification. IMO, this type > > > > > of node is related to P2PSIP. And some SIP UAs may support > > > > > some SIP extensions for P2PSIP. So I think this type of node > > > > > should be considered in WG. > > > > > > > > [Hewen] There is already a consensus in IETF69 that the P2P layer > should be distinct from the SIP layer, the last Concept > > > > document (-v01) records it in Section 5.7. In fact, a device only with > SIP UA is now regarded as a device irrelevant to P2P > > > > layer. > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 11:11 AM, lichun li wrote: > > > > > > > We reuse the terms in concept draft. > > > > > > > In concept draft: > > > > > > > "In P2PSIP, peers offer storage and transport > > > > > > > services to allow the distributed database function > > > > > and distributed > > > > > > > transport function to be implemented." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/23/07, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > > > > > > The fundamental characteristics of Peers in DHT are the > > > > > three things: > > > > > > > > - Participates in overlay maintenance > > > > > > > > - Provides routing service > > > > > > > > - Provides storage service. > > > > > > > > > > > > > > > > What do you mean by 'transport service'? > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < > > > > > yaowang.bupt@gmail.com> wrote: > > > > > > > > > Hi, everyone. > > > > > > > > > The attachment is a new I-D mainly talking about > > > > > > > > > different types > > > > > > > of nodes in P2PSIP. > > > > > > > > > This document is an attempt to classify > > > > > different types > > > > > > > > > of node > > > > > > > in peer-to-peer Session Initiation Protocol (P2PSIP). > > > > > Four possible > > > > > > > types of nodes in P2PSIP are discussed based on two characters: > > > > > > > whether it offers overlay-routing services and whether it > > > > > offers storage functions. > > > > > > > The behaviors of each type of nodes and their possible > > > > > necessities > > > > > > > are analyzed. This document is dedicated to be a reference for > > > > > > > clarifying some controversial terms in P2PSIP working > > > > > group, such as > > > > > > > "client", "low-function peer", etc. > > > > > > > > > It is hoped that this document could help the WG to > > > > > > > > > reach a > > > > > > > rough consensus on the types of node within P2PSIP system and > the > > > > > > > characters of each type's behavior. > > > > > > > > > > > > > > > > > > Because the IETF Internet-Draft Submission is closed > > > > > > > > > right now, > > > > > > > I have to send it as attachment to this maillist. This > > > > > document will > > > > > > > be submitted to IETF as soon as IETF Internet-Draft Submission > > > > > > > reopened. :) > > > > > > > > > > > > > > > > > > Sincerely yours, > > > > > > > > > > > > > > > > > > Yao Wang > > > > > > > > > Mobile Life and New Media Lab, BUPT > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca ] > > > > > > > > > Sent: Thursday, November 15, 2007 9:00 PM > > > > > > > > > To: P2PSIP Mailing List > > > > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > > > > > > > > > > > > > A word of advice to all those interested in P2PSIP clients: > > > > > > > > > > > > > > > > > > Please write an internet-draft saying why you want clients. > > > > > > > > > State the > > > > > > > > > problem(s) that clients solve that peers do not. > > > > > > > > > > > > > > > > > > More specifically: > > > > > > > > > * Describe a problem that you want to solve using clients. > > > > > > > > > * Present a convincing argument why that problem is > > > > > interesting. > > > > > > > > > * Present a convincing argument why that problem cannot be > > > > > > > > > solved using peers. > > > > > > > > > > > > > > > > > > DO NOT go into the technical minutia of a client > > > > > protocol. Just > > > > > > > > > focus on convincing people that the problem is worthwhile > > > > > > > > > solving and that some model of clients would be the > > > > > best way to solve it. > > > > > > > > > > > > > > > > > > The WG chairs requested this document at the Prague > > > > > meeting in > > > > > > > > > the spring, but I have yet to see it. > > > > > > > > > > > > > > > > > > - Philip > > > > > > > > > > > > > > > > > > PS. If someone thinks a recently posted draft meets this > > > > > > > > > criteria, then I would appreciate a pointer to it. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > P2PSIP mailing list > > > > > > > > > P2PSIP@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > P2PSIP mailing list > > > > > > > > > P2PSIP@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > P2PSIP mailing list > > > > > > > > P2PSIP@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Sincerely yours, > > > > > > > > > > > > > > Lichun Li > > > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sincerely yours, > > > > > > > > > > Lichun Li > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > _______________________________________________ > > > > > P2PSIP mailing list > > > > > P2PSIP@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sincerely yours, > > > > > > Lichun Li > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > -- > > Eunsoo > > > > > > -- > > > Sincerely yours, > > Lichun Li > Mobile Life New Media Lab, BUPT -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 01:03:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwX3h-0006yA-PT; Mon, 26 Nov 2007 01:03:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwX3f-0006rD-TN for p2psip@ietf.org; Mon, 26 Nov 2007 01:03:03 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwX3f-0006M4-85 for p2psip@ietf.org; Mon, 26 Nov 2007 01:03:03 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS3007C2NFLD1@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 14:02:09 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS300L7GNFKKB@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 14:02:09 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS300BONNFKFY@szxml04-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 14:02:08 +0800 (CST) Date: Mon, 26 Nov 2007 14:02:08 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Routing mode in P2PSIP In-reply-to: <20071126022658.B69DE33C21@delta.rtfm.com> To: 'Eric Rescorla' , 'Song Yongchao' Message-id: <002001c82ff1$e0ddb870$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acgv1IYhMykU0yhsQROmHlqMdymGEAAG2Pdg X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > How do you propose to discover it? It's certainly not enough to have > a non-1597 address. Those are still sometimes NATed. You can compare > your host candidate to whatever server reflexive candidates you have, > but if you're unlucky about STUN server selection, they might still > be the same. This complexity is part of why ICE does not attempt > to make such determinations. IMHO, one viable method is to discover it during the enrollment procedure. Up to now, community has agreed that some centralized servers, such as enrollment server, bootstrap server are needed. These servers must be supposed to be accessed by any nodes in the overlay. I think the meaning of the word "public" here is that STUN servers with "public" addresses could be visited directly by any nodes in the overlay. If the corresponding overlay will be operated globally, the STUN server or other server must be equipped with a "real public address". If the overlay is to be operated in a private scope, for example, in a private business network, a node is thought of as having a public address even if it has a address within private address range, for example, 10.; So I think it is up to the operator to determine where to deploy its STUN servers or something like them to help nodes discovering its service/capability easier. Any comment is appreciated. Regards! JiangXingFeng _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 01:19:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwXJe-0003sP-Qs; Mon, 26 Nov 2007 01:19:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwXJd-0003pn-DA for p2psip@ietf.org; Mon, 26 Nov 2007 01:19:33 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwXJZ-0003hG-6x for p2psip@ietf.org; Mon, 26 Nov 2007 01:19:33 -0500 Received: by nz-out-0506.google.com with SMTP id n1so233049nzf for ; Sun, 25 Nov 2007 22:19:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=dFBBQv84Q5HOhGMA6NeceU9Gjop/cN+osPV5HXyjdC0=; b=Lp0jYTL+mDWuDIPJfFkU1T1Zp+xbd5NnZCTHYPfohnPzOVMKRMgUwOVytGz8nMq0c6dyPWoQLUGLzJDlmrUl+uRYfraSPXFHyRjKxYIHNRzvDFooke+/rUA7QbkpELeajvtzrO7K01EVPWShWjH3HhX3ujVGWLn8rNr1uignXTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=e8Nhv9/iHdtmhvD9U3gEUdoSyyROeTkQAwFplEl0ULzdNJdAA+tTx3jpG6jeN/IxjnFHae/iqYGuXrQo7eC77MrMo6riFuUoVEJbwPbtklHs9nGCbPnv6V3NLGDKs7SEMbqtXxiaamCNKAROWVnf9F7pf2MJsLp6jdgm2OV1mBk= Received: by 10.143.17.13 with SMTP id u13mr194711wfi.1196057968115; Sun, 25 Nov 2007 22:19:28 -0800 (PST) Received: by 10.142.200.16 with HTTP; Sun, 25 Nov 2007 22:19:28 -0800 (PST) Message-ID: <7d6b50690711252219y1dbccdfet2b90e475c6d2da0d@mail.gmail.com> Date: Mon, 26 Nov 2007 14:19:28 +0800 From: "lichun li" To: "Eunsoo Shim" Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients) In-Reply-To: <7b683f3f0711252010r5811e00j4dbbd278a9ff5a0f@mail.gmail.com> MIME-Version: 1.0 References: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com> <000001c82e45$eae81ac0$5105a40a@china.huawei.com> <7d6b50690711232042i2f4bfe9au65c0b5b38a8e40b5@mail.gmail.com> <7b683f3f0711232046o63dc2f03j2f2a47855d40dbbd@mail.gmail.com> <7d6b50690711251748k3293f294s68eab0e12fe8f1ac@mail.gmail.com> <7b683f3f0711252010r5811e00j4dbbd278a9ff5a0f@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 17589c7043b24a47064a4b7516f59671 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1362173337==" Errors-To: p2psip-bounces@ietf.org --===============1362173337== Content-Type: multipart/alternative; boundary="----=_Part_2504_22614300.1196057968088" ------=_Part_2504_22614300.1196057968088 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline On 11/26/07, Eunsoo Shim wrote: > On Nov 25, 2007 8:48 PM, lichun li wrote: > > To provide storage service, a device should have enough disk space. > > If the device doesn't support the routing algorithm, it is not capable > of > > providing the routing service. For example, a node only supporting Chord > can > > not be a peer in bamboo overlay. > > Hmm, so what you mean is that a device with enough HW resources and > good network conditions become a Client because it does not have the > right routing algorithm code. And such a device may provide the > storage service. > > It seems it is a possible scenario. But still I am not sure how much > we gain having those Clients provide the storage service. Somehow I > feel it just adds complexity without much benefit. Do you see a > significant benefit from it? The complexity can be reduced, if some messages and mechanisms in peer protocol can be reused. The benefit is enlarging the storage capacity of the system. Storing offline messages, voicemail requires much disk space. Larger storage capacity also enhances the resistibility to some kind of DoS attack. I think the authors of http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt also have some good reasons. > > If the device has poor connectivity, it's not suitable to provide > routing > > service. Maybe the device is behind NAT. Maybe the bandwidth is low. > Maybe > > the latency is high. > > > Devices with these conditions won't be suitable to provide the storage > service. A peer contacts many nodes. A client offering storage service only provide storage service to its associated peer(s). Network condition requirement by a peer is higher. Network condition requirement: peer > client offering storage service > normal client I think at least the device behind NAT is suitable to offer storage service. > Thanks. > > Eunsoo > > > > > On 11/24/07, Eunsoo Shim wrote: > > > The node type 3 in the draft provides the storage service but the > > > routing service (transport service). > > > Could you describe a scenario where a device is not capable of > > > providing the routing service but capable of providing the storage > > > service? > > > > > > Thanks. > > > > > > Eunsoo > > > > > > On Nov 23, 2007 11:42 PM, lichun li < lilichun@gmail.com> wrote: > > > > I also think the P2P layer should be distinct from the SIP layer. > > > > > > > > > > > > On Nov 24, 2007 10:58 AM, Zheng Hewen < hwzheng@huawei.com> wrote: > > > > > Hi, > > > > > > > > > > Please see inline. > > > > > > > > > > Best regards, > > > > > Hewen > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: lichun li [mailto:lilichun@gmail.com] > > > > > > Sent: 2007?11?24? 10:26 > > > > > > To: Eunsoo Shim > > > > > > Cc: P2PSIP Mailing List > > > > > > Subject: Re: [P2PSIP] New I-D: different types of nodes in > > > > > > P2PSIP (was: Tothose interested in P2PSIP clients) > > > > > > > > > > > > Please see inline. > > > > > > > > > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim < eunsooshim@gmail.com> > wrote: > > > > > > > Then the transport service is another apsect of the > > > > > > 'routing service'. > > > > > > > It is like that we say the IP layer does routing (while an > > > > > > IP packet > > > > > > > carries a payload). > > > > > > > Somehow the definition of P2PSIP Peer in the concept draft > does > > not > > > > > > > mention 'routing'. > > > > > > > I am going to suggest slight modification of the definition > > > > > > to other authors. > > > > > > > > > > > > I agree. Some explanations about these services should be given. > > > > > > > > > > > > > Back to your draft, non-P2P Clients can certain exist. > Actually a > > > > > > > device with just SIP UA is such a device. > > > > > > > But when we consider the overlay layer, such devices are > > irrelevant. > > > > > > > Nor they affect on the overlay protocol design. It just > > > > > > confuses the > > > > > > > discussion about node types for the overlay. I don't think > such > > > > > > > devices should be considered as a type of node in the overlay. > > > > > > > > > > > > I agree. This draft still needs modification. IMO, this type > > > > > > of node is related to P2PSIP. And some SIP UAs may support > > > > > > some SIP extensions for P2PSIP. So I think this type of node > > > > > > should be considered in WG. > > > > > > > > > > [Hewen] There is already a consensus in IETF69 that the P2P layer > > should be distinct from the SIP layer, the last Concept > > > > > document (-v01) records it in Section 5.7. In fact, a device only > with > > SIP UA is now regarded as a device irrelevant to P2P > > > > > layer. > > > > > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 11:11 AM, lichun li > wrote: > > > > > > > > We reuse the terms in concept draft. > > > > > > > > In concept draft: > > > > > > > > "In P2PSIP, peers offer storage and transport > > > > > > > > services to allow the distributed database function > > > > > > and distributed > > > > > > > > transport function to be implemented." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/23/07, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > > > > > > > The fundamental characteristics of Peers in DHT are the > > > > > > three things: > > > > > > > > > - Participates in overlay maintenance > > > > > > > > > - Provides routing service > > > > > > > > > - Provides storage service. > > > > > > > > > > > > > > > > > > What do you mean by 'transport service'? > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < > > > > > > yaowang.bupt@gmail.com> wrote: > > > > > > > > > > Hi, everyone. > > > > > > > > > > The attachment is a new I-D mainly talking about > > > > > > > > > > different types > > > > > > > > of nodes in P2PSIP. > > > > > > > > > > This document is an attempt to classify > > > > > > different types > > > > > > > > > > of node > > > > > > > > in peer-to-peer Session Initiation Protocol (P2PSIP). > > > > > > Four possible > > > > > > > > types of nodes in P2PSIP are discussed based on two > characters: > > > > > > > > whether it offers overlay-routing services and whether it > > > > > > offers storage functions. > > > > > > > > The behaviors of each type of nodes and their possible > > > > > > necessities > > > > > > > > are analyzed. This document is dedicated to be a reference > for > > > > > > > > clarifying some controversial terms in P2PSIP working > > > > > > group, such as > > > > > > > > "client", "low-function peer", etc. > > > > > > > > > > It is hoped that this document could help the WG > to > > > > > > > > > > reach a > > > > > > > > rough consensus on the types of node within P2PSIP system > and > > the > > > > > > > > characters of each type's behavior. > > > > > > > > > > > > > > > > > > > > Because the IETF Internet-Draft Submission is > closed > > > > > > > > > > right now, > > > > > > > > I have to send it as attachment to this maillist. This > > > > > > document will > > > > > > > > be submitted to IETF as soon as IETF Internet-Draft > Submission > > > > > > > > reopened. :) > > > > > > > > > > > > > > > > > > > > Sincerely yours, > > > > > > > > > > > > > > > > > > > > Yao Wang > > > > > > > > > > Mobile Life and New Media Lab, BUPT > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca] > > > > > > > > > > Sent: Thursday, November 15, 2007 9:00 PM > > > > > > > > > > To: P2PSIP Mailing List > > > > > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > > > > > > > > > > > > > > > A word of advice to all those interested in P2PSIP > clients: > > > > > > > > > > > > > > > > > > > > Please write an internet-draft saying why you want > clients. > > > > > > > > > > State the > > > > > > > > > > problem(s) that clients solve that peers do not. > > > > > > > > > > > > > > > > > > > > More specifically: > > > > > > > > > > * Describe a problem that you want to solve using > clients. > > > > > > > > > > * Present a convincing argument why that problem is > > > > > > interesting. > > > > > > > > > > * Present a convincing argument why that problem cannot > be > > > > > > > > > > solved using peers. > > > > > > > > > > > > > > > > > > > > DO NOT go into the technical minutia of a client > > > > > > protocol. Just > > > > > > > > > > focus on convincing people that the problem is > worthwhile > > > > > > > > > > solving and that some model of clients would be the > > > > > > best way to solve it. > > > > > > > > > > > > > > > > > > > > The WG chairs requested this document at the Prague > > > > > > meeting in > > > > > > > > > > the spring, but I have yet to see it. > > > > > > > > > > > > > > > > > > > > - Philip > > > > > > > > > > > > > > > > > > > > PS. If someone thinks a recently posted draft meets this > > > > > > > > > > criteria, then I would appreciate a pointer to it. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > P2PSIP mailing list > > > > > > > > > > P2PSIP@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > P2PSIP mailing list > > > > > > > > > > P2PSIP@ietf.org > > > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > P2PSIP mailing list > > > > > > > > > P2PSIP@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Sincerely yours, > > > > > > > > > > > > > > > > Lichun Li > > > > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sincerely yours, > > > > > > > > > > > > Lichun Li > > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > _______________________________________________ > > > > > > P2PSIP mailing list > > > > > > P2PSIP@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Sincerely yours, > > > > > > > > Lichun Li > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > > > > > -- > > > Eunsoo > > > > > > > > > > > -- > > > > > > Sincerely yours, > > > > Lichun Li > > Mobile Life New Media Lab, BUPT > > > > -- > Eunsoo > -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------=_Part_2504_22614300.1196057968088 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 11/26/07, Eunsoo Shim <eunsooshim@gmail.com> wrote:
On Nov 25, 2007 8:48 PM, lichun li <lilichun@gmail.com> wrote:
> To provide storage service, a device should have enough disk space.
> If the device doesn't support the routing algorithm, it is not capable of
> providing the routing service. For example, a node only supporting Chord can
> not be a peer in bamboo overlay.

Hmm, so what you mean is that a device with enough HW resources and
good network conditions become a Client because it does not have the
right routing algorithm code. And such a device may provide the
storage service.

It seems it is a possible scenario. But still I am not sure how much
we gain having those Clients provide the storage service. Somehow I
feel it just adds complexity without much benefit. Do you see a
significant benefit from it?
 
 

 
The complexity can be reduced, if some messages and mechanisms in peer protocol can be reused.
The benefit is enlarging the storage capacity of the system. Storing offline messages, voicemail requires much disk space. Larger storage capacity also enhances the resistibility  to some kind of DoS attack.
 
I think the authors of http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt also have some good reasons.

 
> If the device has poor connectivity, it's not suitable to provide routing
> service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe
> the latency is high.
>
Devices with these conditions won't be suitable to provide the storage service.
 
A peer contacts many nodes. A client offering storage service only provide storage service to its associated peer(s). Network condition requirement by a peer is higher.
Network condition requirement: peer > client offering storage service > normal client
I think at least the device behind NAT is suitable to offer storage service.
 
Thanks.

Eunsoo

>
> On 11/24/07, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > The node type 3 in the draft provides the storage service but the
> > routing service (transport service).
> > Could you describe a scenario where a device is not capable of
> > providing the routing service but capable of providing the storage
> > service?
> >
> > Thanks.
> >
> > Eunsoo
> >
> > On Nov 23, 2007 11:42 PM, lichun li < lilichun@gmail.com> wrote:
> > > I also think the P2P layer should be distinct from the SIP layer.
> > >
> > >
> > > On Nov 24, 2007 10:58 AM, Zheng Hewen < hwzheng@huawei.com> wrote:
> > > > Hi,
> > > >
> > > >    Please see inline.
> > > >
> > > > Best regards,
> > > > Hewen
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: lichun li [mailto:lilichun@gmail.com ]
> > > > > Sent: 2007?11?24? 10:26
> > > > > To: Eunsoo Shim
> > > > > Cc: P2PSIP Mailing List
> > > > > Subject: Re: [P2PSIP] New I-D: different types of nodes in
> > > > > P2PSIP (was: Tothose interested in P2PSIP clients)
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > > > > > Then the transport service is another apsect of the
> > > > > 'routing service'.
> > > > > > It is like that we say the IP layer does routing (while an
> > > > > IP packet
> > > > > > carries a payload).
> > > > > > Somehow the definition of P2PSIP Peer in the concept draft does
> not
> > > > > > mention 'routing'.
> > > > > > I am going to suggest slight modification of the definition
> > > > > to other authors.
> > > > >
> > > > > I agree. Some explanations about these services should be given.
> > > > >
> > > > > > Back to your draft,  non-P2P Clients can certain exist. Actually a
> > > > > > device with just SIP UA is such a device.
> > > > > > But when we consider the overlay layer, such devices are
> irrelevant.
> > > > > > Nor they affect on the overlay protocol design. It just
> > > > > confuses the
> > > > > > discussion about node types for the overlay. I don't think such
> > > > > > devices should be considered as a type of node in the overlay.
> > > > >
> > > > > I agree. This draft still needs modification. IMO, this type
> > > > > of node is related to P2PSIP. And some SIP UAs may support
> > > > > some SIP extensions for P2PSIP. So I think this type of node
> > > > > should be considered in WG.
> > > >
> > > > [Hewen] There is already a consensus in IETF69 that the P2P layer
> should be distinct from the SIP layer, the last Concept
> > > > document (-v01) records it in Section 5.7. In fact, a device only with
> SIP UA is now regarded as a device irrelevant to P2P
> > > > layer.
> > > >
> > > >
> > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Eunsoo
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Nov 23, 2007 11:11 AM, lichun li <lilichun@gmail.com> wrote:
> > > > > > > We reuse the terms in concept draft.
> > > > > > > In concept draft:
> > > > > > > "In P2PSIP, peers offer storage and transport
> > > > > > >    services to allow the distributed database function
> > > > > and distributed
> > > > > > >    transport function to be implemented."
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 11/23/07, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > > > > > > > The fundamental characteristics of Peers in DHT are the
> > > > > three things:
> > > > > > > > - Participates in overlay maintenance
> > > > > > > > - Provides routing service
> > > > > > > > - Provides storage service.
> > > > > > > >
> > > > > > > > What do you mean by 'transport service'?
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > Eunsoo
> > > > > > > >
> > > > > > > >
> > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang <
> > > > > yaowang.bupt@gmail.com> wrote:
> > > > > > > > > Hi, everyone.
> > > > > > > > >         The attachment is a new I-D mainly talking about
> > > > > > > > > different types
> > > > > > > of nodes in P2PSIP.
> > > > > > > > >         This document is an attempt to classify
> > > > > different types
> > > > > > > > > of node
> > > > > > > in    peer-to-peer Session Initiation Protocol (P2PSIP).
> > > > > Four possible
> > > > > > > types of nodes in P2PSIP are discussed based on two characters:
> > > > > > > whether it offers overlay-routing services and whether it
> > > > > offers storage functions.
> > > > > > > The behaviors of each type of nodes and their possible
> > > > > necessities
> > > > > > > are analyzed.  This document is dedicated to be a reference for
> > > > > > > clarifying some controversial terms in P2PSIP working
> > > > > group, such as
> > > > > > > "client", "low-function peer", etc.
> > > > > > > > >         It is hoped that this document could help the WG to
> > > > > > > > > reach a
> > > > > > > rough consensus on the types of node within P2PSIP system and
> the
> > > > > > > characters of each type's behavior.
> > > > > > > > >
> > > > > > > > >         Because the IETF Internet-Draft Submission is closed
> > > > > > > > > right now,
> > > > > > > I have to send it as attachment to this maillist. This
> > > > > document will
> > > > > > > be submitted to IETF as soon as IETF Internet-Draft Submission
> > > > > > > reopened. :)
> > > > > > > > >
> > > > > > > > > Sincerely yours,
> > > > > > > > >
> > > > > > > > > Yao Wang
> > > > > > > > > Mobile Life and New Media Lab, BUPT
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca ]
> > > > > > > > > Sent: Thursday, November 15, 2007 9:00 PM
> > > > > > > > > To: P2PSIP Mailing List
> > > > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients
> > > > > > > > >
> > > > > > > > > A word of advice to all those interested in P2PSIP clients:
> > > > > > > > >
> > > > > > > > > Please write an internet-draft saying why you want clients.
> > > > > > > > > State the
> > > > > > > > > problem(s) that clients solve that peers do not.
> > > > > > > > >
> > > > > > > > > More specifically:
> > > > > > > > > * Describe a problem that you want to solve using clients.
> > > > > > > > > * Present a convincing argument why that problem is
> > > > > interesting.
> > > > > > > > > * Present a convincing argument why that problem cannot be
> > > > > > > > > solved using peers.
> > > > > > > > >
> > > > > > > > > DO NOT go into the technical minutia of a client
> > > > > protocol. Just
> > > > > > > > > focus on convincing people that the problem is worthwhile
> > > > > > > > > solving and that some model of clients would be the
> > > > > best way to solve it.
> > > > > > > > >
> > > > > > > > > The WG chairs requested this document at the Prague
> > > > > meeting in
> > > > > > > > > the spring, but I have yet to see it.
> > > > > > > > >
> > > > > > > > > - Philip
> > > > > > > > >
> > > > > > > > > PS. If someone thinks a recently posted draft meets this
> > > > > > > > > criteria, then I would appreciate a pointer to it.
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > P2PSIP mailing list
> > > > > > > > > P2PSIP@ietf.org
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > P2PSIP mailing list
> > > > > > > > > P2PSIP@ietf.org
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Eunsoo
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > P2PSIP mailing list
> > > > > > > > P2PSIP@ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sincerely yours,
> > > > > > >
> > > > > > > Lichun Li
> > > > > > > Mobile Life New Media Lab, BUPT
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Eunsoo
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sincerely yours,
> > > > >
> > > > > Lichun Li
> > > > > Mobile Life New Media Lab, BUPT
> > > > >
> > > > > _______________________________________________
> > > > > P2PSIP mailing list
> > > > > P2PSIP@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Sincerely yours,
> > >
> > > Lichun Li
> > > Mobile Life New Media Lab, BUPT
> > >
> >
> >
> >
> > --
> > Eunsoo
> >
>
>
>
> --
>
>
> Sincerely yours,
>
> Lichun Li
> Mobile Life New Media Lab, BUPT



--
Eunsoo



--
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT ------=_Part_2504_22614300.1196057968088-- --===============1362173337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1362173337==-- From p2psip-bounces@ietf.org Mon Nov 26 04:01:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZqV-0002lB-VE; Mon, 26 Nov 2007 04:01:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZqU-0002ky-SY for p2psip@ietf.org; Mon, 26 Nov 2007 04:01:38 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwZqL-0007ss-6s for p2psip@ietf.org; Mon, 26 Nov 2007 04:01:38 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS3001SLVIY83@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 16:56:58 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS300LE9VIXF7@szxga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 16:56:58 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS300HBFVIW0J@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 16:56:57 +0800 (CST) Date: Mon, 26 Nov 2007 16:56:56 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt In-reply-to: <02a601c820e2$e2b416d0$6501a8c0@china.huawei.com> To: 'Spencer Dawkins' , 'P2PSIP Mailing List' Message-id: <002d01c8300a$4c6edfc0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acgg4w25/suZ0J3iRqCa5+hxmwj3+gPJeAHw X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Spencer: Thanks for the analysis work of application scenarios from you guys. Application scenarios vary tremendously in its attributes you have classified. Do you want our resulting protocol support all or most of the application scenarios? IMHO, the more valuable work is to find the commonalities among them and try to get some conclusions like that: whether all or most of peers are behind NAT; whether centralized server could be available in every application scenarios, what is the suitable churn rate for the various applications, etc. If we could reach consensus on these issues, we could make it as a input to the design of the peer and/or client protocol. Regards! -- Jiang XingFeng > -----Original Message----- > From: Spencer Dawkins [mailto:spencer@mcsr-labs.org] > Sent: Wednesday, November 07, 2007 10:07 AM > To: P2PSIP Mailing List > Subject: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt > > Just as a heads-up - we've redone the Use Case draft (as "application > scenarios") and submitted the document - should be available now. > > Please feel free to express opinions (and outrage - flaming torches and > pitchforks will work better in cyberspace than in damp Vancouver :-) > > Thanks, > > Spencer > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > Title : Application Scenarios for Peer-to-Peer Session > > Initiation Protocol (P2PSIP) > > Author(s) : D. Bryan, et al. > > Filename : draft-bryan-p2psip-app-scenarios-00.txt > > Pages : 19 > > Date : 2007-11-06 > > > > This document attempts to identify and classify application scenarios > > of P2P based SIP. It does not attempt to exhaustively enumerate > > these scenarios, and is focused exclusively on scenarios related to > > real-time IP communication. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-bryan-p2psip-app-scenarios-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > > i-d-announce-request@ietf.org with the word unsubscribe in the body of > > the message. > > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then > > "get draft-bryan-p2psip-app-scenarios-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE /internet-drafts/draft-bryan-p2psip-app-scenarios-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > ---------------------------------------------------------------------------- ---- > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 04:26:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaCs-0004YV-6I; Mon, 26 Nov 2007 04:24:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaCq-0004YL-UK for p2psip@ietf.org; Mon, 26 Nov 2007 04:24:44 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwaCb-00005j-EP for p2psip@ietf.org; Mon, 26 Nov 2007 04:24:44 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS300JHVWRBWL@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 17:23:36 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS3008QYWR6CI@szxga02-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 17:23:35 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS300HDHWR20J@szxml03-in.huawei.com> for p2psip@ietf.org; Mon, 26 Nov 2007 17:23:30 +0800 (CST) Date: Mon, 26 Nov 2007 17:23:26 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients) In-reply-to: <7d6b50690711252219y1dbccdfet2b90e475c6d2da0d@mail.gmail.com> To: 'lichun li' , 'Eunsoo Shim' Message-id: <000101c8300d$ffec3f40$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Thread-index: Acgv9GyQrI237jXxQASX0TwKtWZWPAAF8yVg X-Spam-Score: 0.0 (/) X-Scan-Signature: 08aa56e70047071f9a3037af5750d40e Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1195944056==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1195944056== Content-type: multipart/alternative; boundary="Boundary_(ID_na7yhKDMH/8W00UuJTHMaQ)" This is a multi-part message in MIME format. --Boundary_(ID_na7yhKDMH/8W00UuJTHMaQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, In my opinion, clients can provide storage service to its associated peer, but they do not store any DHT data, hence it essentially is a kind of service over P2P network. P2PSIP peer/client protocol data operations (GET/PUT/REMOVE) can be reused to implement the service; certainly other ways may be choices. For instance, peers in the overlay can store indices of files and clients store the files in real deployment, this design reduces unwanted traffic into the overlay or/and enhances the ability to more stably and securely provide services. Certainly, those are only considerations in the real deployment; it does not determine who is peer and who is client because the decision is made by the operator. Any comment is appreciated. Best regards, Hewen _____ From: lichun li [mailto:lilichun@gmail.com] Sent: 2007?11?26? 14:19 To: Eunsoo Shim Cc: Zheng Hewen; P2PSIP Mailing List Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients) On 11/26/07, Eunsoo Shim wrote: On Nov 25, 2007 8:48 PM, lichun li wrote: > To provide storage service, a device should have enough disk space. > If the device doesn't support the routing algorithm, it is not capable of > providing the routing service. For example, a node only supporting Chord can > not be a peer in bamboo overlay. Hmm, so what you mean is that a device with enough HW resources and good network conditions become a Client because it does not have the right routing algorithm code. And such a device may provide the storage service. It seems it is a possible scenario. But still I am not sure how much we gain having those Clients provide the storage service. Somehow I feel it just adds complexity without much benefit. Do you see a significant benefit from it? The complexity can be reduced, if some messages and mechanisms in peer protocol can be reused. The benefit is enlarging the storage capacity of the system. Storing offline messages, voicemail requires much disk space. Larger storage capacity also enhances the resistibility to some kind of DoS attack. I think the authors of http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt also have some good reasons. > If the device has poor connectivity, it's not suitable to provide routing > service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe > the latency is high. > Devices with these conditions won't be suitable to provide the storage service. A peer contacts many nodes. A client offering storage service only provide storage service to its associated peer(s). Network condition requirement by a peer is higher. Network condition requirement: peer > client offering storage service > normal client I think at least the device behind NAT is suitable to offer storage service. Thanks. Eunsoo > > On 11/24/07, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > The node type 3 in the draft provides the storage service but the > > routing service (transport service). > > Could you describe a scenario where a device is not capable of > > providing the routing service but capable of providing the storage > > service? > > > > Thanks. > > > > Eunsoo > > > > On Nov 23, 2007 11:42 PM, lichun li < lilichun@gmail.com> wrote: > > > I also think the P2P layer should be distinct from the SIP layer. > > > > > > > > > On Nov 24, 2007 10:58 AM, Zheng Hewen < hwzheng@huawei.com> wrote: > > > > Hi, > > > > > > > > Please see inline. > > > > > > > > Best regards, > > > > Hewen > > > > > > > > > > > > > -----Original Message----- > > > > > From: lichun li [mailto:lilichun@gmail.com ] > > > > > Sent: 2007?11?24? 10:26 > > > > > To: Eunsoo Shim > > > > > Cc: P2PSIP Mailing List > > > > > Subject: Re: [P2PSIP] New I-D: different types of nodes in > > > > > P2PSIP (was: Tothose interested in P2PSIP clients) > > > > > > > > > > Please see inline. > > > > > > > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > > > > Then the transport service is another apsect of the > > > > > 'routing service'. > > > > > > It is like that we say the IP layer does routing (while an > > > > > IP packet > > > > > > carries a payload). > > > > > > Somehow the definition of P2PSIP Peer in the concept draft does > not > > > > > > mention 'routing'. > > > > > > I am going to suggest slight modification of the definition > > > > > to other authors. > > > > > > > > > > I agree. Some explanations about these services should be given. > > > > > > > > > > > Back to your draft, non-P2P Clients can certain exist. Actually a > > > > > > device with just SIP UA is such a device. > > > > > > But when we consider the overlay layer, such devices are > irrelevant. > > > > > > Nor they affect on the overlay protocol design. It just > > > > > confuses the > > > > > > discussion about node types for the overlay. I don't think such > > > > > > devices should be considered as a type of node in the overlay. > > > > > > > > > > I agree. This draft still needs modification. IMO, this type > > > > > of node is related to P2PSIP. And some SIP UAs may support > > > > > some SIP extensions for P2PSIP. So I think this type of node > > > > > should be considered in WG. > > > > > > > > [Hewen] There is already a consensus in IETF69 that the P2P layer > should be distinct from the SIP layer, the last Concept > > > > document (-v01) records it in Section 5.7. In fact, a device only with > SIP UA is now regarded as a device irrelevant to P2P > > > > layer. > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 11:11 AM, lichun li wrote: > > > > > > > We reuse the terms in concept draft. > > > > > > > In concept draft: > > > > > > > "In P2PSIP, peers offer storage and transport > > > > > > > services to allow the distributed database function > > > > > and distributed > > > > > > > transport function to be implemented." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/23/07, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > > > > > > The fundamental characteristics of Peers in DHT are the > > > > > three things: > > > > > > > > - Participates in overlay maintenance > > > > > > > > - Provides routing service > > > > > > > > - Provides storage service. > > > > > > > > > > > > > > > > What do you mean by 'transport service'? > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < > > > > > yaowang.bupt@gmail.com> wrote: > > > > > > > > > Hi, everyone. > > > > > > > > > The attachment is a new I-D mainly talking about > > > > > > > > > different types > > > > > > > of nodes in P2PSIP. > > > > > > > > > This document is an attempt to classify > > > > > different types > > > > > > > > > of node > > > > > > > in peer-to-peer Session Initiation Protocol (P2PSIP). > > > > > Four possible > > > > > > > types of nodes in P2PSIP are discussed based on two characters: > > > > > > > whether it offers overlay-routing services and whether it > > > > > offers storage functions. > > > > > > > The behaviors of each type of nodes and their possible > > > > > necessities > > > > > > > are analyzed. This document is dedicated to be a reference for > > > > > > > clarifying some controversial terms in P2PSIP working > > > > > group, such as > > > > > > > "client", "low-function peer", etc. > > > > > > > > > It is hoped that this document could help the WG to > > > > > > > > > reach a > > > > > > > rough consensus on the types of node within P2PSIP system and > the > > > > > > > characters of each type's behavior. > > > > > > > > > > > > > > > > > > Because the IETF Internet-Draft Submission is closed > > > > > > > > > right now, > > > > > > > I have to send it as attachment to this maillist. This > > > > > document will > > > > > > > be submitted to IETF as soon as IETF Internet-Draft Submission > > > > > > > reopened. :) > > > > > > > > > > > > > > > > > > Sincerely yours, > > > > > > > > > > > > > > > > > > Yao Wang > > > > > > > > > Mobile Life and New Media Lab, BUPT > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca ] > > > > > > > > > Sent: Thursday, November 15, 2007 9:00 PM > > > > > > > > > To: P2PSIP Mailing List > > > > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > > > > > > > > > > > > > A word of advice to all those interested in P2PSIP clients: > > > > > > > > > > > > > > > > > > Please write an internet-draft saying why you want clients. > > > > > > > > > State the > > > > > > > > > problem(s) that clients solve that peers do not. > > > > > > > > > > > > > > > > > > More specifically: > > > > > > > > > * Describe a problem that you want to solve using clients. > > > > > > > > > * Present a convincing argument why that problem is > > > > > interesting. > > > > > > > > > * Present a convincing argument why that problem cannot be > > > > > > > > > solved using peers. > > > > > > > > > > > > > > > > > > DO NOT go into the technical minutia of a client > > > > > protocol. Just > > > > > > > > > focus on convincing people that the problem is worthwhile > > > > > > > > > solving and that some model of clients would be the > > > > > best way to solve it. > > > > > > > > > > > > > > > > > > The WG chairs requested this document at the Prague > > > > > meeting in > > > > > > > > > the spring, but I have yet to see it. > > > > > > > > > > > > > > > > > > - Philip > > > > > > > > > > > > > > > > > > PS. If someone thinks a recently posted draft meets this > > > > > > > > > criteria, then I would appreciate a pointer to it. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > P2PSIP mailing list > > > > > > > > > P2PSIP@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > P2PSIP mailing list > > > > > > > > > P2PSIP@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > P2PSIP mailing list > > > > > > > > P2PSIP@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Sincerely yours, > > > > > > > > > > > > > > Lichun Li > > > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sincerely yours, > > > > > > > > > > Lichun Li > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > _______________________________________________ > > > > > P2PSIP mailing list > > > > > P2PSIP@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sincerely yours, > > > > > > Lichun Li > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > -- > > Eunsoo > > > > > > -- > > > Sincerely yours, > > Lichun Li > Mobile Life New Media Lab, BUPT -- Eunsoo -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT --Boundary_(ID_na7yhKDMH/8W00UuJTHMaQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi,
 
   In my opinion, clients can provide storage service to its associated peer, but they do not store any DHT data, hence it essentially is a kind of service over P2P network. P2PSIP peer/client protocol data operations (GET/PUT/REMOVE) can be reused to implement the service; certainly other ways may be choices.
   For instance, peers in the overlay can store indices of files and clients store the files in real deployment, this design reduces unwanted traffic into the overlay or/and enhances the ability to more stably and securely provide services. Certainly, those are only considerations in the real deployment; it does not determine who is peer and who is client because the decision is made by the operator.
   Any comment is appreciated.
 
Best regards,
Hewen

From: lichun li [mailto:lilichun@gmail.com]
Sent: 2007年11月26日 14:19
To: Eunsoo Shim
Cc: Zheng Hewen; P2PSIP Mailing List
Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients)



On 11/26/07, Eunsoo Shim <eunsooshim@gmail.com> wrote:
On Nov 25, 2007 8:48 PM, lichun li <lilichun@gmail.com> wrote:
> To provide storage service, a device should have enough disk space.
> If the device doesn't support the routing algorithm, it is not capable of
> providing the routing service. For example, a node only supporting Chord can
> not be a peer in bamboo overlay.

Hmm, so what you mean is that a device with enough HW resources and
good network conditions become a Client because it does not have the
right routing algorithm code. And such a device may provide the
storage service.

It seems it is a possible scenario. But still I am not sure how much
we gain having those Clients provide the storage service. Somehow I
feel it just adds complexity without much benefit. Do you see a
significant benefit from it?
 
 

 
The complexity can be reduced, if some messages and mechanisms in peer protocol can be reused.
The benefit is enlarging the storage capacity of the system. Storing offline messages, voicemail requires much disk space. Larger storage capacity also enhances the resistibility  to some kind of DoS attack.
 
I think the authors of http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt also have some good reasons.
  
 
> If the device has poor connectivity, it's not suitable to provide routing
> service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe
> the latency is high.
>
Devices with these conditions won't be suitable to provide the storage service.
 
A peer contacts many nodes. A client offering storage service only provide storage service to its associated peer(s). Network condition requirement by a peer is higher.
Network condition requirement: peer > client offering storage service > normal client
I think at least the device behind NAT is suitable to offer storage service.
 
Thanks.

Eunsoo

>
> On 11/24/07, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > The node type 3 in the draft provides the storage service but the
> > routing service (transport service).
> > Could you describe a scenario where a device is not capable of
> > providing the routing service but capable of providing the storage
> > service?
> >
> > Thanks.
> >
> > Eunsoo
> >
> > On Nov 23, 2007 11:42 PM, lichun li < lilichun@gmail.com> wrote:
> > > I also think the P2P layer should be distinct from the SIP layer.
> > >
> > >
> > > On Nov 24, 2007 10:58 AM, Zheng Hewen < hwzheng@huawei.com> wrote:
> > > > Hi,
> > > >
> > > >    Please see inline.
> > > >
> > > > Best regards,
> > > > Hewen
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: lichun li [mailto:lilichun@gmail.com ]
> > > > > Sent: 2007?11?24? 10:26
> > > > > To: Eunsoo Shim
> > > > > Cc: P2PSIP Mailing List
> > > > > Subject: Re: [P2PSIP] New I-D: different types of nodes in
> > > > > P2PSIP (was: Tothose interested in P2PSIP clients)
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > > > > > Then the transport service is another apsect of the
> > > > > 'routing service'.
> > > > > > It is like that we say the IP layer does routing (while an
> > > > > IP packet
> > > > > > carries a payload).
> > > > > > Somehow the definition of P2PSIP Peer in the concept draft does
> not
> > > > > > mention 'routing'.
> > > > > > I am going to suggest slight modification of the definition
> > > > > to other authors.
> > > > >
> > > > > I agree. Some explanations about these services should be given.
> > > > >
> > > > > > Back to your draft,  non-P2P Clients can certain exist. Actually a
> > > > > > device with just SIP UA is such a device.
> > > > > > But when we consider the overlay layer, such devices are
> irrelevant.
> > > > > > Nor they affect on the overlay protocol design. It just
> > > > > confuses the
> > > > > > discussion about node types for the overlay. I don't think such
> > > > > > devices should be considered as a type of node in the overlay.
> > > > >
> > > > > I agree. This draft still needs modification. IMO, this type
> > > > > of node is related to P2PSIP. And some SIP UAs may support
> > > > > some SIP extensions for P2PSIP. So I think this type of node
> > > > > should be considered in WG.
> > > >
> > > > [Hewen] There is already a consensus in IETF69 that the P2P layer
> should be distinct from the SIP layer, the last Concept
> > > > document (-v01) records it in Section 5.7. In fact, a device only with
> SIP UA is now regarded as a device irrelevant to P2P
> > > > layer.
> > > >
> > > >
> > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Eunsoo
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Nov 23, 2007 11:11 AM, lichun li <lilichun@gmail.com> wrote:
> > > > > > > We reuse the terms in concept draft.
> > > > > > > In concept draft:
> > > > > > > "In P2PSIP, peers offer storage and transport
> > > > > > >    services to allow the distributed database function
> > > > > and distributed
> > > > > > >    transport function to be implemented."
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 11/23/07, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > > > > > > > The fundamental characteristics of Peers in DHT are the
> > > > > three things:
> > > > > > > > - Participates in overlay maintenance
> > > > > > > > - Provides routing service
> > > > > > > > - Provides storage service.
> > > > > > > >
> > > > > > > > What do you mean by 'transport service'?
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > Eunsoo
> > > > > > > >
> > > > > > > >
> > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang <
> > > > > yaowang.bupt@gmail.com> wrote:
> > > > > > > > > Hi, everyone.
> > > > > > > > >         The attachment is a new I-D mainly talking about
> > > > > > > > > different types
> > > > > > > of nodes in P2PSIP.
> > > > > > > > >         This document is an attempt to classify
> > > > > different types
> > > > > > > > > of node
> > > > > > > in    peer-to-peer Session Initiation Protocol (P2PSIP).
> > > > > Four possible
> > > > > > > types of nodes in P2PSIP are discussed based on two characters:
> > > > > > > whether it offers overlay-routing services and whether it
> > > > > offers storage functions.
> > > > > > > The behaviors of each type of nodes and their possible
> > > > > necessities
> > > > > > > are analyzed.  This document is dedicated to be a reference for
> > > > > > > clarifying some controversial terms in P2PSIP working
> > > > > group, such as
> > > > > > > "client", "low-function peer", etc.
> > > > > > > > >         It is hoped that this document could help the WG to
> > > > > > > > > reach a
> > > > > > > rough consensus on the types of node within P2PSIP system and
> the
> > > > > > > characters of each type's behavior.
> > > > > > > > >
> > > > > > > > >         Because the IETF Internet-Draft Submission is closed
> > > > > > > > > right now,
> > > > > > > I have to send it as attachment to this maillist. This
> > > > > document will
> > > > > > > be submitted to IETF as soon as IETF Internet-Draft Submission
> > > > > > > reopened. :)
> > > > > > > > >
> > > > > > > > > Sincerely yours,
> > > > > > > > >
> > > > > > > > > Yao Wang
> > > > > > > > > Mobile Life and New Media Lab, BUPT
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca ]
> > > > > > > > > Sent: Thursday, November 15, 2007 9:00 PM
> > > > > > > > > To: P2PSIP Mailing List
> > > > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients
> > > > > > > > >
> > > > > > > > > A word of advice to all those interested in P2PSIP clients:
> > > > > > > > >
> > > > > > > > > Please write an internet-draft saying why you want clients.
> > > > > > > > > State the
> > > > > > > > > problem(s) that clients solve that peers do not.
> > > > > > > > >
> > > > > > > > > More specifically:
> > > > > > > > > * Describe a problem that you want to solve using clients.
> > > > > > > > > * Present a convincing argument why that problem is
> > > > > interesting.
> > > > > > > > > * Present a convincing argument why that problem cannot be
> > > > > > > > > solved using peers.
> > > > > > > > >
> > > > > > > > > DO NOT go into the technical minutia of a client
> > > > > protocol. Just
> > > > > > > > > focus on convincing people that the problem is worthwhile
> > > > > > > > > solving and that some model of clients would be the
> > > > > best way to solve it.
> > > > > > > > >
> > > > > > > > > The WG chairs requested this document at the Prague
> > > > > meeting in
> > > > > > > > > the spring, but I have yet to see it.
> > > > > > > > >
> > > > > > > > > - Philip
> > > > > > > > >
> > > > > > > > > PS. If someone thinks a recently posted draft meets this
> > > > > > > > > criteria, then I would appreciate a pointer to it.
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > P2PSIP mailing list
> > > > > > > > > P2PSIP@ietf.org
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > P2PSIP mailing list
> > > > > > > > > P2PSIP@ietf.org
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Eunsoo
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > P2PSIP mailing list
> > > > > > > > P2PSIP@ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sincerely yours,
> > > > > > >
> > > > > > > Lichun Li
> > > > > > > Mobile Life New Media Lab, BUPT
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Eunsoo
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sincerely yours,
> > > > >
> > > > > Lichun Li
> > > > > Mobile Life New Media Lab, BUPT
> > > > >
> > > > > _______________________________________________
> > > > > P2PSIP mailing list
> > > > > P2PSIP@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Sincerely yours,
> > >
> > > Lichun Li
> > > Mobile Life New Media Lab, BUPT
> > >
> >
> >
> >
> > --
> > Eunsoo
> >
>
>
>
> --
>
>
> Sincerely yours,
>
> Lichun Li
> Mobile Life New Media Lab, BUPT



--
Eunsoo



--
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT
--Boundary_(ID_na7yhKDMH/8W00UuJTHMaQ)-- --===============1195944056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1195944056==-- From p2psip-bounces@ietf.org Mon Nov 26 05:01:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwamc-00007J-TH; Mon, 26 Nov 2007 05:01:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwamb-0008Tv-67 for p2psip@ietf.org; Mon, 26 Nov 2007 05:01:41 -0500 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Iwama-00047I-OS for p2psip@ietf.org; Mon, 26 Nov 2007 05:01:41 -0500 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Mon, 26 Nov 2007 02:01:30 -0800 From: "David Barrett" To: "'Eric Rescorla'" , "'Song Yongchao'" Subject: RE: [P2PSIP] Routing mode in P2PSIP Date: Mon, 26 Nov 2007 02:01:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgv1I1I7djixUqMRo2ZT4imk7pFsgAPWG2g In-Reply-To: <20071126022658.B69DE33C21@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Subject: Re: [P2PSIP] Routing mode in P2PSIP > > > Eric, could you explain for me why do you think it is difficult to > discover > > that? > > How do you propose to discover it? It's certainly not enough to have > a non-1597 address. Those are still sometimes NATed. You can compare > your host candidate to whatever server reflexive candidates you have, > but if you're unlucky about STUN server selection, they might still > be the same. This complexity is part of why ICE does not attempt > to make such determinations. For the record, there's a persistent myth that NAT classification is difficult and unreliable. It's not. Just use several STUN servers that you know are non-NAT'd, try various combinations, and you can classify translation and filtering properties with a very high degree of reliability. Granted, like everything with NATs (or, indeed, in the real world), it's not perfect: sometimes you get false positives and negatives, and sometimes NAT properties change over time. But it's more than a reliable enough technique to be useful. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 05:13:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwaxc-0008T0-G9; Mon, 26 Nov 2007 05:13:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaxX-0008P8-IN for p2psip@ietf.org; Mon, 26 Nov 2007 05:12:59 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwaxU-0004Mp-Nt for p2psip@ietf.org; Mon, 26 Nov 2007 05:12:59 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAQABaZS014351; Mon, 26 Nov 2007 12:12:19 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 12:12:18 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 12:12:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothoseinterested in P2PSIP clients) Date: Mon, 26 Nov 2007 12:15:05 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F057538CE@esebe102.NOE.Nokia.com> In-Reply-To: <000101c8300d$ffec3f40$5105a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothoseinterested in P2PSIP clients) Thread-Index: Acgv9GyQrI237jXxQASX0TwKtWZWPAAF8yVgAAIakhA= References: <7d6b50690711252219y1dbccdfet2b90e475c6d2da0d@mail.gmail.com> <000101c8300d$ffec3f40$5105a40a@china.huawei.com> From: To: , , X-OriginalArrivalTime: 26 Nov 2007 10:12:18.0617 (UTC) FILETIME=[D383D290:01C83014] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93a9b7eb0f4b3b8a49c341eb77478ab2 Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0852179921==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0852179921== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83014.D32425DB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83014.D32425DB Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit >P2PSIP peer/client protocol data operations (GET/PUT/REMOVE) can be reused to implement the service; certainly other ways may be choices. I would keep it external to the client protocol. If a peer decides to store data in another entity it may use any protocol to transfer the data, it does not have to be a client protocol. We should not invent yet another file transfer protocol. Marcin ________________________________ From: ext Zheng Hewen [mailto:hwzheng@huawei.com] Sent: 26 November, 2007 11:23 To: 'lichun li'; 'Eunsoo Shim' Cc: 'P2PSIP Mailing List' Subject: RE: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothoseinterested in P2PSIP clients) Hi, In my opinion, clients can provide storage service to its associated peer, but they do not store any DHT data, hence it essentially is a kind of service over P2P network. P2PSIP peer/client protocol data operations (GET/PUT/REMOVE) can be reused to implement the service; certainly other ways may be choices. For instance, peers in the overlay can store indices of files and clients store the files in real deployment, this design reduces unwanted traffic into the overlay or/and enhances the ability to more stably and securely provide services. Certainly, those are only considerations in the real deployment; it does not determine who is peer and who is client because the decision is made by the operator. Any comment is appreciated. Best regards, Hewen ________________________________ From: lichun li [mailto:lilichun@gmail.com] Sent: 2007$BG/(J11$B7n(J26$BF|(J 14:19 To: Eunsoo Shim Cc: Zheng Hewen; P2PSIP Mailing List Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients) On 11/26/07, Eunsoo Shim wrote: On Nov 25, 2007 8:48 PM, lichun li wrote: > To provide storage service, a device should have enough disk space. > If the device doesn't support the routing algorithm, it is not capable of > providing the routing service. For example, a node only supporting Chord can > not be a peer in bamboo overlay. Hmm, so what you mean is that a device with enough HW resources and good network conditions become a Client because it does not have the right routing algorithm code. And such a device may provide the storage service. It seems it is a possible scenario. But still I am not sure how much we gain having those Clients provide the storage service. Somehow I feel it just adds complexity without much benefit. Do you see a significant benefit from it? The complexity can be reduced, if some messages and mechanisms in peer protocol can be reused. The benefit is enlarging the storage capacity of the system. Storing offline messages, voicemail requires much disk space. Larger storage capacity also enhances the resistibility to some kind of DoS attack. I think the authors of http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt also have some good reasons. > If the device has poor connectivity, it's not suitable to provide routing > service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe > the latency is high. > Devices with these conditions won't be suitable to provide the storage service. A peer contacts many nodes. A client offering storage service only provide storage service to its associated peer(s). Network condition requirement by a peer is higher. Network condition requirement: peer > client offering storage service > normal client I think at least the device behind NAT is suitable to offer storage service. Thanks. Eunsoo > > On 11/24/07, Eunsoo Shim < eunsooshim@gmail.com > wrote: > > The node type 3 in the draft provides the storage service but the > > routing service (transport service). > > Could you describe a scenario where a device is not capable of > > providing the routing service but capable of providing the storage > > service? > > > > Thanks. > > > > Eunsoo > > > > On Nov 23, 2007 11:42 PM, lichun li < lilichun@gmail.com> wrote: > > > I also think the P2P layer should be distinct from the SIP layer. > > > > > > > > > On Nov 24, 2007 10:58 AM, Zheng Hewen < hwzheng@huawei.com> wrote: > > > > Hi, > > > > > > > > Please see inline. > > > > > > > > Best regards, > > > > Hewen > > > > > > > > > > > > > -----Original Message----- > > > > > From: lichun li [mailto:lilichun@gmail.com ] > > > > > Sent: 2007?11?24? 10:26 > > > > > To: Eunsoo Shim > > > > > Cc: P2PSIP Mailing List > > > > > Subject: Re: [P2PSIP] New I-D: different types of nodes in > > > > > P2PSIP (was: Tothose interested in P2PSIP clients) > > > > > > > > > > Please see inline. > > > > > > > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > > > > Then the transport service is another apsect of the > > > > > 'routing service'. > > > > > > It is like that we say the IP layer does routing (while an > > > > > IP packet > > > > > > carries a payload). > > > > > > Somehow the definition of P2PSIP Peer in the concept draft does > not > > > > > > mention 'routing'. > > > > > > I am going to suggest slight modification of the definition > > > > > to other authors. > > > > > > > > > > I agree. Some explanations about these services should be given. > > > > > > > > > > > Back to your draft, non-P2P Clients can certain exist. Actually a > > > > > > device with just SIP UA is such a device. > > > > > > But when we consider the overlay layer, such devices are > irrelevant. > > > > > > Nor they affect on the overlay protocol design. It just > > > > > confuses the > > > > > > discussion about node types for the overlay. I don't think such > > > > > > devices should be considered as a type of node in the overlay. > > > > > > > > > > I agree. This draft still needs modification. IMO, this type > > > > > of node is related to P2PSIP. And some SIP UAs may support > > > > > some SIP extensions for P2PSIP. So I think this type of node > > > > > should be considered in WG. > > > > > > > > [Hewen] There is already a consensus in IETF69 that the P2P layer > should be distinct from the SIP layer, the last Concept > > > > document (-v01) records it in Section 5.7. In fact, a device only with > SIP UA is now regarded as a device irrelevant to P2P > > > > layer. > > > > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 11:11 AM, lichun li wrote: > > > > > > > We reuse the terms in concept draft. > > > > > > > In concept draft: > > > > > > > "In P2PSIP, peers offer storage and transport > > > > > > > services to allow the distributed database function > > > > > and distributed > > > > > > > transport function to be implemented." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 11/23/07, Eunsoo Shim < eunsooshim@gmail.com> wrote: > > > > > > > > The fundamental characteristics of Peers in DHT are the > > > > > three things: > > > > > > > > - Participates in overlay maintenance > > > > > > > > - Provides routing service > > > > > > > > - Provides storage service. > > > > > > > > > > > > > > > > What do you mean by 'transport service'? > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang < > > > > > yaowang.bupt@gmail.com> wrote: > > > > > > > > > Hi, everyone. > > > > > > > > > The attachment is a new I-D mainly talking about > > > > > > > > > different types > > > > > > > of nodes in P2PSIP. > > > > > > > > > This document is an attempt to classify > > > > > different types > > > > > > > > > of node > > > > > > > in peer-to-peer Session Initiation Protocol (P2PSIP). > > > > > Four possible > > > > > > > types of nodes in P2PSIP are discussed based on two characters: > > > > > > > whether it offers overlay-routing services and whether it > > > > > offers storage functions. > > > > > > > The behaviors of each type of nodes and their possible > > > > > necessities > > > > > > > are analyzed. This document is dedicated to be a reference for > > > > > > > clarifying some controversial terms in P2PSIP working > > > > > group, such as > > > > > > > "client", "low-function peer", etc. > > > > > > > > > It is hoped that this document could help the WG to > > > > > > > > > reach a > > > > > > > rough consensus on the types of node within P2PSIP system and > the > > > > > > > characters of each type's behavior. > > > > > > > > > > > > > > > > > > Because the IETF Internet-Draft Submission is closed > > > > > > > > > right now, > > > > > > > I have to send it as attachment to this maillist. This > > > > > document will > > > > > > > be submitted to IETF as soon as IETF Internet-Draft Submission > > > > > > > reopened. :) > > > > > > > > > > > > > > > > > > Sincerely yours, > > > > > > > > > > > > > > > > > > Yao Wang > > > > > > > > > Mobile Life and New Media Lab, BUPT > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca ] > > > > > > > > > Sent: Thursday, November 15, 2007 9:00 PM > > > > > > > > > To: P2PSIP Mailing List > > > > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients > > > > > > > > > > > > > > > > > > A word of advice to all those interested in P2PSIP clients: > > > > > > > > > > > > > > > > > > Please write an internet-draft saying why you want clients. > > > > > > > > > State the > > > > > > > > > problem(s) that clients solve that peers do not. > > > > > > > > > > > > > > > > > > More specifically: > > > > > > > > > * Describe a problem that you want to solve using clients. > > > > > > > > > * Present a convincing argument why that problem is > > > > > interesting. > > > > > > > > > * Present a convincing argument why that problem cannot be > > > > > > > > > solved using peers. > > > > > > > > > > > > > > > > > > DO NOT go into the technical minutia of a client > > > > > protocol. Just > > > > > > > > > focus on convincing people that the problem is worthwhile > > > > > > > > > solving and that some model of clients would be the > > > > > best way to solve it. > > > > > > > > > > > > > > > > > > The WG chairs requested this document at the Prague > > > > > meeting in > > > > > > > > > the spring, but I have yet to see it. > > > > > > > > > > > > > > > > > > - Philip > > > > > > > > > > > > > > > > > > PS. If someone thinks a recently posted draft meets this > > > > > > > > > criteria, then I would appreciate a pointer to it. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > P2PSIP mailing list > > > > > > > > > P2PSIP@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > P2PSIP mailing list > > > > > > > > > P2PSIP@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > Eunsoo > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > P2PSIP mailing list > > > > > > > > P2PSIP@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Sincerely yours, > > > > > > > > > > > > > > Lichun Li > > > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Eunsoo > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Sincerely yours, > > > > > > > > > > Lichun Li > > > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > _______________________________________________ > > > > > P2PSIP mailing list > > > > > P2PSIP@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/p2psip > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Sincerely yours, > > > > > > Lichun Li > > > Mobile Life New Media Lab, BUPT > > > > > > > > > > > -- > > Eunsoo > > > > > > -- > > > Sincerely yours, > > Lichun Li > Mobile Life New Media Lab, BUPT -- Eunsoo -- Sincerely yours, Lichun Li Mobile Life New Media Lab, BUPT ------_=_NextPart_001_01C83014.D32425DB Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit
>P2PSIP peer/client protocol data operations (GET/PUT/REMOVE) can be reused to implement the service; certainly other ways may be choices.
I would keep it external to the client protocol. If a peer decides to store data in another entity it may use any protocol to transfer the data, it does not have to be a client protocol. We should not invent yet another file transfer protocol.
 
Marcin 
 
From: ext Zheng Hewen [mailto:hwzheng@huawei.com]
Sent: 26 November, 2007 11:23
To: 'lichun li'; 'Eunsoo Shim'
Cc: 'P2PSIP Mailing List'
Subject: RE: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothoseinterested in P2PSIP clients)

Hi,
 
   In my opinion, clients can provide storage service to its associated peer, but they do not store any DHT data, hence it essentially is a kind of service over P2P network. P2PSIP peer/client protocol data operations (GET/PUT/REMOVE) can be reused to implement the service; certainly other ways may be choices.
   For instance, peers in the overlay can store indices of files and clients store the files in real deployment, this design reduces unwanted traffic into the overlay or/and enhances the ability to more stably and securely provide services. Certainly, those are only considerations in the real deployment; it does not determine who is peer and who is client because the decision is made by the operator.
   Any comment is appreciated.
 
Best regards,
Hewen

From: lichun li [mailto:lilichun@gmail.com]
Sent: 2007$BG/(B11$B7n(B26$BF|(B 14:19
To: Eunsoo Shim
Cc: Zheng Hewen; P2PSIP Mailing List
Subject: Re: [P2PSIP] New I-D: different types of nodes in P2PSIP (was: Tothose interested in P2PSIP clients)



On 11/26/07, Eunsoo Shim <eunsooshim@gmail.com> wrote:
On Nov 25, 2007 8:48 PM, lichun li <lilichun@gmail.com> wrote:
> To provide storage service, a device should have enough disk space.
> If the device doesn't support the routing algorithm, it is not capable of
> providing the routing service. For example, a node only supporting Chord can
> not be a peer in bamboo overlay.

Hmm, so what you mean is that a device with enough HW resources and
good network conditions become a Client because it does not have the
right routing algorithm code. And such a device may provide the
storage service.

It seems it is a possible scenario. But still I am not sure how much
we gain having those Clients provide the storage service. Somehow I
feel it just adds complexity without much benefit. Do you see a
significant benefit from it?
 
 

 
The complexity can be reduced, if some messages and mechanisms in peer protocol can be reused.
The benefit is enlarging the storage capacity of the system. Storing offline messages, voicemail requires much disk space. Larger storage capacity also enhances the resistibility  to some kind of DoS attack.
 
I think the authors of http://www.p2psip.org/drafts/draft-zheng-p2psip-client-protocol-00.txt also have some good reasons.
  
 
> If the device has poor connectivity, it's not suitable to provide routing
> service. Maybe the device is behind NAT. Maybe the bandwidth is low. Maybe
> the latency is high.
>
Devices with these conditions won't be suitable to provide the storage service.
 
A peer contacts many nodes. A client offering storage service only provide storage service to its associated peer(s). Network condition requirement by a peer is higher.
Network condition requirement: peer > client offering storage service > normal client
I think at least the device behind NAT is suitable to offer storage service.
 
Thanks.

Eunsoo

>
> On 11/24/07, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > The node type 3 in the draft provides the storage service but the
> > routing service (transport service).
> > Could you describe a scenario where a device is not capable of
> > providing the routing service but capable of providing the storage
> > service?
> >
> > Thanks.
> >
> > Eunsoo
> >
> > On Nov 23, 2007 11:42 PM, lichun li < lilichun@gmail.com> wrote:
> > > I also think the P2P layer should be distinct from the SIP layer.
> > >
> > >
> > > On Nov 24, 2007 10:58 AM, Zheng Hewen < hwzheng@huawei.com> wrote:
> > > > Hi,
> > > >
> > > >    Please see inline.
> > > >
> > > > Best regards,
> > > > Hewen
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: lichun li [mailto:lilichun@gmail.com ]
> > > > > Sent: 2007?11?24? 10:26
> > > > > To: Eunsoo Shim
> > > > > Cc: P2PSIP Mailing List
> > > > > Subject: Re: [P2PSIP] New I-D: different types of nodes in
> > > > > P2PSIP (was: Tothose interested in P2PSIP clients)
> > > > >
> > > > > Please see inline.
> > > > >
> > > > > On Nov 24, 2007 12:36 AM, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > > > > > Then the transport service is another apsect of the
> > > > > 'routing service'.
> > > > > > It is like that we say the IP layer does routing (while an
> > > > > IP packet
> > > > > > carries a payload).
> > > > > > Somehow the definition of P2PSIP Peer in the concept draft does
> not
> > > > > > mention 'routing'.
> > > > > > I am going to suggest slight modification of the definition
> > > > > to other authors.
> > > > >
> > > > > I agree. Some explanations about these services should be given.
> > > > >
> > > > > > Back to your draft,  non-P2P Clients can certain exist. Actually a
> > > > > > device with just SIP UA is such a device.
> > > > > > But when we consider the overlay layer, such devices are
> irrelevant.
> > > > > > Nor they affect on the overlay protocol design. It just
> > > > > confuses the
> > > > > > discussion about node types for the overlay. I don't think such
> > > > > > devices should be considered as a type of node in the overlay.
> > > > >
> > > > > I agree. This draft still needs modification. IMO, this type
> > > > > of node is related to P2PSIP. And some SIP UAs may support
> > > > > some SIP extensions for P2PSIP. So I think this type of node
> > > > > should be considered in WG.
> > > >
> > > > [Hewen] There is already a consensus in IETF69 that the P2P layer
> should be distinct from the SIP layer, the last Concept
> > > > document (-v01) records it in Section 5.7. In fact, a device only with
> SIP UA is now regarded as a device irrelevant to P2P
> > > > layer.
> > > >
> > > >
> > > > >
> > > > > > Thanks.
> > > > > >
> > > > > > Eunsoo
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Nov 23, 2007 11:11 AM, lichun li <lilichun@gmail.com> wrote:
> > > > > > > We reuse the terms in concept draft.
> > > > > > > In concept draft:
> > > > > > > "In P2PSIP, peers offer storage and transport
> > > > > > >    services to allow the distributed database function
> > > > > and distributed
> > > > > > >    transport function to be implemented."
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 11/23/07, Eunsoo Shim < eunsooshim@gmail.com> wrote:
> > > > > > > > The fundamental characteristics of Peers in DHT are the
> > > > > three things:
> > > > > > > > - Participates in overlay maintenance
> > > > > > > > - Provides routing service
> > > > > > > > - Provides storage service.
> > > > > > > >
> > > > > > > > What do you mean by 'transport service'?
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > > Eunsoo
> > > > > > > >
> > > > > > > >
> > > > > > > > On Nov 23, 2007 2:47 AM, Yao Wang <
> > > > > yaowang.bupt@gmail.com> wrote:
> > > > > > > > > Hi, everyone.
> > > > > > > > >         The attachment is a new I-D mainly talking about
> > > > > > > > > different types
> > > > > > > of nodes in P2PSIP.
> > > > > > > > >         This document is an attempt to classify
> > > > > different types
> > > > > > > > > of node
> > > > > > > in    peer-to-peer Session Initiation Protocol (P2PSIP).
> > > > > Four possible
> > > > > > > types of nodes in P2PSIP are discussed based on two characters:
> > > > > > > whether it offers overlay-routing services and whether it
> > > > > offers storage functions.
> > > > > > > The behaviors of each type of nodes and their possible
> > > > > necessities
> > > > > > > are analyzed.  This document is dedicated to be a reference for
> > > > > > > clarifying some controversial terms in P2PSIP working
> > > > > group, such as
> > > > > > > "client", "low-function peer", etc.
> > > > > > > > >         It is hoped that this document could help the WG to
> > > > > > > > > reach a
> > > > > > > rough consensus on the types of node within P2PSIP system and
> the
> > > > > > > characters of each type's behavior.
> > > > > > > > >
> > > > > > > > >         Because the IETF Internet-Draft Submission is closed
> > > > > > > > > right now,
> > > > > > > I have to send it as attachment to this maillist. This
> > > > > document will
> > > > > > > be submitted to IETF as soon as IETF Internet-Draft Submission
> > > > > > > reopened. :)
> > > > > > > > >
> > > > > > > > > Sincerely yours,
> > > > > > > > >
> > > > > > > > > Yao Wang
> > > > > > > > > Mobile Life and New Media Lab, BUPT
> > > > > > > > >
> > > > > > > > > -----Original Message-----
> > > > > > > > > From: Philip Matthews [mailto: philip_matthews@magma.ca ]
> > > > > > > > > Sent: Thursday, November 15, 2007 9:00 PM
> > > > > > > > > To: P2PSIP Mailing List
> > > > > > > > > Subject: [P2PSIP] To those interested in P2PSIP clients
> > > > > > > > >
> > > > > > > > > A word of advice to all those interested in P2PSIP clients:
> > > > > > > > >
> > > > > > > > > Please write an internet-draft saying why you want clients.
> > > > > > > > > State the
> > > > > > > > > problem(s) that clients solve that peers do not.
> > > > > > > > >
> > > > > > > > > More specifically:
> > > > > > > > > * Describe a problem that you want to solve using clients.
> > > > > > > > > * Present a convincing argument why that problem is
> > > > > interesting.
> > > > > > > > > * Present a convincing argument why that problem cannot be
> > > > > > > > > solved using peers.
> > > > > > > > >
> > > > > > > > > DO NOT go into the technical minutia of a client
> > > > > protocol. Just
> > > > > > > > > focus on convincing people that the problem is worthwhile
> > > > > > > > > solving and that some model of clients would be the
> > > > > best way to solve it.
> > > > > > > > >
> > > > > > > > > The WG chairs requested this document at the Prague
> > > > > meeting in
> > > > > > > > > the spring, but I have yet to see it.
> > > > > > > > >
> > > > > > > > > - Philip
> > > > > > > > >
> > > > > > > > > PS. If someone thinks a recently posted draft meets this
> > > > > > > > > criteria, then I would appreciate a pointer to it.
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > P2PSIP mailing list
> > > > > > > > > P2PSIP@ietf.org
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > P2PSIP mailing list
> > > > > > > > > P2PSIP@ietf.org
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Eunsoo
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > P2PSIP mailing list
> > > > > > > > P2PSIP@ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Sincerely yours,
> > > > > > >
> > > > > > > Lichun Li
> > > > > > > Mobile Life New Media Lab, BUPT
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Eunsoo
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sincerely yours,
> > > > >
> > > > > Lichun Li
> > > > > Mobile Life New Media Lab, BUPT
> > > > >
> > > > > _______________________________________________
> > > > > P2PSIP mailing list
> > > > > P2PSIP@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/p2psip
> > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > Sincerely yours,
> > >
> > > Lichun Li
> > > Mobile Life New Media Lab, BUPT
> > >
> >
> >
> >
> > --
> > Eunsoo
> >
>
>
>
> --
>
>
> Sincerely yours,
>
> Lichun Li
> Mobile Life New Media Lab, BUPT



--
Eunsoo



--
Sincerely yours,

Lichun Li
Mobile Life New Media Lab, BUPT
------_=_NextPart_001_01C83014.D32425DB-- --===============0852179921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0852179921==-- From p2psip-bounces@ietf.org Mon Nov 26 05:14:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwayi-0001hr-9c; Mon, 26 Nov 2007 05:14:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwayh-0001hM-Hj for p2psip@ietf.org; Mon, 26 Nov 2007 05:14:11 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwaya-0001Jz-6C for p2psip@ietf.org; Mon, 26 Nov 2007 05:14:11 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lAQADuYJ013463 for ; Mon, 26 Nov 2007 12:13:58 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 12:13:56 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 12:13:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Nov 2007 12:16:42 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F057538D4@esebe102.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: P2PSIP security requirements Thread-Index: Acgqsj9UsxgjVb+ZSu6NTuZ45gG7lwBiYDpA References: From: To: X-OriginalArrivalTime: 26 Nov 2007 10:13:57.0188 (UTC) FILETIME=[0E449040:01C83015] X-Nokia-AV: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: jan-erik.ekberg@nokia.com, pekka.laitinen@nokia.com Subject: [P2PSIP] P2PSIP security requirements X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi all, We submitted a new version of the security requirements draft: http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-security-re quirements-02.txt. We improved the security threats section and modified requirements according to your comments.=20 This document presents a basic set of security requirements that we believe that each of the proposals needs to address: P2PSIP system requirements related to security issues are summarized below: Req. 1: Dependence of reachability of a centralized server SHOULD be minimized. Req. 2: P2PSIP security SHOULD scale from a small ad-hoc network to a network with hundred millions of network nodes and users. Req. 3: Existing security mechanisms SHOULD be used as much as possible to protect P2PSIP functions, and avoid the need for standardizing new mechanisms. Req. 4: Security requirements on the base P2P algorithm (e.g., DHT implementations) used in P2PSIP SHOULD be minimized and SHOULD NOT limit its scalability. Req. 5: The registered identities in a P2PSIP overlay MUST be preserved. The attacker MUST NOT be able to steal identity from another user. Req. 6: The enrollment process MUST make it difficult for an attacker to register many identities in a P2PSIP overlay and easily modify the registered identities. Req. 7: It MUST be difficult to select a particular peer ID e.g. peer ID assignment process should introduce some degree of randomness to peer identities. Req. 8: It MUST be possible to authenticate users and P2PSIP network entities. Req. 9: It MUST NOT be possible to repeat or delay valid data transmission during enrollment and modification of P2PSIP resource (user) records. Req. 10: The P2PSIP security MUST support integrity protection of the data being inserted or retrieved to/from an overlay. Req. 11: The P2PSIP network entities MUST be provided with an option to encrypt data exchanged with other P2PSIP network entities. Req. 12: Only authorized users and P2PSIP network entities MUST be able to join the P2PSIP system and insert, modify, delete or overwrite P2PSIP resource (user) records in the P2PSIP system. Req. 13: In the situations where many users or P2PSIP network entities register the same resource in the P2PSIP overlay, each entity MUST have rights only to its own part of a resource record. Req. 14: An owner of P2PSIP resource (user) record MAY indicate which users or network entities can retrieve, modify, and delete data stored in their P2PSIP resource (user) records. Req. 15: P2PSIP overlay protocols MUST be designed such a way so that the effect of DOS attacks on the P2PSIP overlay is minimized. Req. 16: It SHOULD be possible to limit the impact of badly behaving P2PSIP nodes on the overall system security. There SHOULD be an option to identify malfunctioning or badly behaving nodes, and exclude or reject them from the P2PSIP system. We would appreciate your comments! Marcin =20 >A new version of I-D,=20 >draft-matuszewski-p2psip-security-requirements-02.txt has been=20 >successfuly submitted by Marcin Matuszewski and posted to the=20 >IETF repository. > >Filename: draft-matuszewski-p2psip-security-requirements >Revision: 02 >Title: Security requirements in P2PSIP >Creation_date: 2007-11-19 >WG ID: Independent Submission >Number_of_pages: 23 > >Abstract: >This document presents main security requirements for the=20 >Peer-to- Peer SIP (P2PSIP) architecture and its components. =20 >This document also analyses security threats in P2PSIP. =20 >Typical security ontology is used as classification for the threats. > =20 > =20 > > >The IETF Secretariat. > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 05:16:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwb0S-0003JP-Cc; Mon, 26 Nov 2007 05:16:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwb0Q-0003JH-Ch for p2psip@ietf.org; Mon, 26 Nov 2007 05:15:58 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwb0P-0004R4-VX for p2psip@ietf.org; Mon, 26 Nov 2007 05:15:58 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAQAFjDO009258; Mon, 26 Nov 2007 04:16:02 -0600 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 12:15:38 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 12:15:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] comments on using DHTs in wireless ad hoc networks Date: Mon, 26 Nov 2007 12:18:24 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F057538D7@esebe102.NOE.Nokia.com> In-Reply-To: <618e24240711201011n547370bag5556ed3f9d9c958b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] comments on using DHTs in wireless ad hoc networks Thread-Index: AcgroMzUNdDlMnVZQMi97M/rUGjjTAAoEQVw References: <618e24240711201011n547370bag5556ed3f9d9c958b@mail.gmail.com> From: To: , X-OriginalArrivalTime: 26 Nov 2007 10:15:38.0112 (UTC) FILETIME=[4A6C5800:01C83015] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Victor >Are other solutions or DHT adaptations (e.g. CHR) considered depending = on application scenario requirements? Yes, you are right DHTs may not be optimal for small ad-hoc overlay = networks. Depending on the scenario it may be easier and more efficient = (overhead) to implement an unstructured overlays. =20 The P2PP allows for unstructured overlays as well. Marcin =20 >-----Original Message----- >From: ext Victor Pascual =C1vila = [mailto:victor.pascual.avila@gmail.com]=20 >Sent: 20 November, 2007 20:11 >To: p2psip@ietf.org >Subject: [P2PSIP] comments on using DHTs in wireless ad hoc networks > >Hi all, >In "draft-bryan-p2psip-app-scenarios-00.txt", section 4.2 and 4.2.1. >identifies "Ad-Hoc and Ephemeral Groups" application=20 >scenarios, and can be read: > >"Examples of such environment are isolated wireless ad-hoc=20 >networks with no connection to the Internet or ad-hoc networks=20 >with limited connectivity to the Internet in situations like=20 >outdoor public events, emergencies, and battlefields." > >In "draft-ietf-p2psip-concepts-01", section 5.1 describes "The=20 >Distributed Database Function", and can be read: > >"A class of algorithms known as Distributed Hash Tables=20 > are one way to=20 >implement the Distributed Database. In particular, both the=20 >Chord and Bamboo algorithms have been suggested as good=20 >choices for the distributed database algorithm. However, no=20 >decision has been taken so far." > >Problem of implementing a distributed hash table in wireless=20 >ad hoc networks is well-known. Scarceness of resources and=20 >node mobility turn routing into a problem. > >Is there a consensus on using the same type of "Distributed=20 >Database Function" (e.g. DHT) in all application scenarios?=20 >Are other solutions or DHT adaptations (e.g. CHR) considered=20 >depending on application scenario requirements? > >Thanks and sorry if this was already discussed, >-- >Victor Pascual =C1vila > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 08:09:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwdiV-0004Xc-TJ; Mon, 26 Nov 2007 08:09:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwdiU-0004XX-L3 for p2psip@ietf.org; Mon, 26 Nov 2007 08:09:38 -0500 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwdiQ-0005Nc-0a for p2psip@ietf.org; Mon, 26 Nov 2007 08:09:38 -0500 Received: by py-out-1112.google.com with SMTP id d32so2181305pye for ; Mon, 26 Nov 2007 05:09:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=PnGzwsjimQAZh7BM9hWCNWoxDHYwFX1PjuWEpH8EYc0=; b=FZJGOIwIZA3lO3BjjcIx3BYKtMfe86NF5mpZ/uKzvuNHu8wstnmEYdyPqVcXNpUigOBFz57mJJA9w4qQ+MTd0qSrj3kX2r/k+nmCbbfj47UKU3zwFD+N+RquOFI+jMkWDDDmnjsOQqupow8IG/TGR2seN2Bh7blUsNpSYLedJZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Gdaiw4x41S1zg1GuY/sEkEjJ+kuK2lSueiHsVVkPp+bquRogg9bLWABVCHXkgZ6J2BUKPF7GHw5F8YY5dcXLvAZ3nYy++GaOA0ihiPTN9bnmxxjRDDaTcqcu57bAnS2UI+FVLRKgiFWwGBUCt+J8FcbI1mNTUsZHFRoNgjAuG9s= Received: by 10.35.12.10 with SMTP id p10mr3281994pyi.1196082573662; Mon, 26 Nov 2007 05:09:33 -0800 (PST) Received: by 10.35.74.7 with HTTP; Mon, 26 Nov 2007 05:09:33 -0800 (PST) Message-ID: <9b9e17760711260509s326e1669n5ab21d2b51b97fe6@mail.gmail.com> Date: Mon, 26 Nov 2007 15:09:33 +0200 From: "Mosiuoa Tsietsi" To: marcin.matuszewski@nokia.com Subject: Re: [P2PSIP] comments on using DHTs in wireless ad hoc networks In-Reply-To: <3F18E76823C95E4795181D74BAC7664F057538D7@esebe102.NOE.Nokia.com> MIME-Version: 1.0 References: <618e24240711201011n547370bag5556ed3f9d9c958b@mail.gmail.com> <3F18E76823C95E4795181D74BAC7664F057538D7@esebe102.NOE.Nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0352565189==" Errors-To: p2psip-bounces@ietf.org --===============0352565189== Content-Type: multipart/alternative; boundary="----=_Part_1264_13501841.1196082573645" ------=_Part_1264_13501841.1196082573645 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, At MP2P Pisa '06, Heer et al presented their ideas on adapting DHTs for MANETs, by building a DHT over a MANET underlay. I didn't get the paper, but I do have a copy of the slides they presented, so I may have this muddled up, but it seems like they based their design on the need to compensate for the cost of redundancy and overlay maintenance, by allowing = a single MANET to host several smaller but merged DHT rings, the goal being t= o establish as few DHT connections as possible per ring. They seemed to indicate that it's possible but there are difficulties in working with two heterogeneous routing layers. Mos On Nov 26, 2007 12:18 PM, wrote: > Hi Victor > > >Are other solutions or DHT adaptations (e.g. CHR) considered depending o= n > application scenario requirements? > > Yes, you are right DHTs may not be optimal for small ad-hoc overlay > networks. Depending on the scenario it may be easier and more efficient > (overhead) to implement an unstructured overlays. > > The P2PP allows for unstructured overlays as well. > > Marcin > > >-----Original Message----- > >From: ext Victor Pascual =C1vila [mailto:victor.pascual.avila@gmail.com] > >Sent: 20 November, 2007 20:11 > >To: p2psip@ietf.org > >Subject: [P2PSIP] comments on using DHTs in wireless ad hoc networks > > > >Hi all, > >In "draft-bryan-p2psip-app-scenarios-00.txt", section 4.2 and 4.2.1. > >identifies "Ad-Hoc and Ephemeral Groups" application > >scenarios, and can be read: > > > >"Examples of such environment are isolated wireless ad-hoc > >networks with no connection to the Internet or ad-hoc networks > >with limited connectivity to the Internet in situations like > >outdoor public events, emergencies, and battlefields." > > > >In "draft-ietf-p2psip-concepts-01", section 5.1 describes "The > >Distributed Database Function", and can be read: > > > >"A class of algorithms known as Distributed Hash Tables > > are one way to > >implement the Distributed Database. In particular, both the > >Chord and Bamboo algorithms have been suggested as good > >choices for the distributed database algorithm. However, no > >decision has been taken so far." > > > >Problem of implementing a distributed hash table in wireless > >ad hoc networks is well-known. Scarceness of resources and > >node mobility turn routing into a problem. > > > >Is there a consensus on using the same type of "Distributed > >Database Function" (e.g. DHT) in all application scenarios? > >Are other solutions or DHT adaptations (e.g. CHR) considered > >depending on application scenario requirements? > > > >Thanks and sorry if this was already discussed, > >-- > >Victor Pascual =C1vila > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > ------=_Part_1264_13501841.1196082573645 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all,

At MP2P Pisa '06, Heer et al presented their ideas on ad= apting DHTs for MANETs, by building a DHT over a MANET underlay.  I di= dn't get the paper, but I do have a copy of the slides they presented, = so I may have this muddled up, but it seems like they based their design on= the need to compensate for the cost of redundancy and overlay maintenance,= by allowing a single MANET to host several smaller but merged DHT rings, t= he goal being to establish as few DHT connections as possible per ring.&nbs= p; They seemed to indicate that it's possible but there are difficultie= s in working with two heterogeneous routing layers.

Mos

On Nov 26, 2007 12:18 PM, &l= t;marcin.matuszewski@nokia.= com> wrote:
Hi Victor

>Are other solutions or DHT adapt= ations (e.g. CHR) considered depending on application scenario requirements= ?

Yes, you are right DHTs may not be optimal for small ad-hoc = overlay networks. Depending on the scenario it may be easier and more effic= ient (overhead) to implement an unstructured overlays.

The P2PP allows for unstructured overlays as well.

Marcin

>-----Original Message----->From: ext Victor Pascual =C1vila [mailto: victor.pascual.avila@gmail.com]
>Sent: 20 November, 2007 20:11>To: p2psip@ietf.org
>Subj= ect: [P2PSIP] comments on using DHTs in wireless ad hoc networks
> >Hi all,
>In "draft-bryan-p2psip-app-scenarios-00.txt", = section 4.2 and 4.2.1.
>identifies  "Ad-Hoc and Ephemeral G= roups" application
>scenarios, and can be read:
>
>&= quot;Examples of such environment are isolated wireless ad-hoc
>networks with no connection to the Internet or ad-hoc networks
&= gt;with limited connectivity to the Internet in situations like
>outd= oor public events, emergencies, and battlefields."
>
>In &= quot;draft-ietf-p2psip-concepts-01", section=20 5.1 describes "The
>Distributed Database Function", and can= be read:
>
>"A class of algorithms known as Distributed H= ash Tables
>< http://en.wikipedia.org/wiki/P2P_overlay> are one way to
>impl= ement the Distributed Database.  In particular, both the
>Chord = and Bamboo algorithms have been suggested as good
>choices for the di= stributed database algorithm.  However, no
>decision has been taken so far."
>
>Problem of imp= lementing a distributed hash table in wireless
>ad hoc networks is we= ll-known. Scarceness of resources and
>node mobility turn routing int= o a problem.
>
>Is there a consensus on using the same type of "Distri= buted
>Database Function" (e.g. DHT) in all application scenario= s?
>Are other solutions or DHT adaptations (e.g. CHR) considered
>depending on application scenario requirements?
>
>Thanks a= nd sorry if this was already discussed,
>--
>Victor Pascual =C1= vila
>

___________________________________________= ____
P2PSIP mailing list
P2PSIP@ietf.o= rg
https://www1.ietf.org/mailman/listinfo/p2psip

------=_Part_1264_13501841.1196082573645-- --===============0352565189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0352565189==-- From p2psip-bounces@ietf.org Mon Nov 26 08:28:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwe0P-0002vJ-U4; Mon, 26 Nov 2007 08:28:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwe0O-0002nV-KB for p2psip@ietf.org; Mon, 26 Nov 2007 08:28:08 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwe0O-0000Dj-9B for p2psip@ietf.org; Mon, 26 Nov 2007 08:28:08 -0500 Received: from Henning-Schulzrinnes-Computer (pool-70-21-184-101.nwrk.east.verizon.net [70.21.184.101]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAQDS0Dp000384 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Nov 2007 08:28:01 -0500 (EST) Message-Id: <14704AE7-D483-4438-8684-DB703DEFFB9D@cs.columbia.edu> From: Henning Schulzrinne To: JiangXingFeng In-Reply-To: <002d01c8300a$4c6edfc0$6905a40a@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt Date: Mon, 26 Nov 2007 08:28:00 -0500 References: <002d01c8300a$4c6edfc0$6905a40a@china.huawei.com> X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I'm sorry, but none of these questions are likely to be answerable with any degree of specificity, so delaying work or hoping for answers is not too helpful. Like in many other circumstances, we have to design robust and extensible protocols that recognize that protocol designers almost always fail to predict the range of use for their creations. We already know - that some fraction of peers may be behind NATs, but there's no way to predict whether that's 0.1% or 100% and what kind of NATs - that we may or may not have central servers - that churn rates may be very high or close to zero Henning On Nov 26, 2007, at 3:56 AM, JiangXingFeng wrote: > Hi, Spencer: > > Thanks for the analysis work of application scenarios from you guys. > > Application scenarios vary tremendously in its attributes you have > classified. Do you want our resulting protocol support all or most > of the > application scenarios? > > IMHO, the more valuable work is to find the commonalities among them > and try > to get some conclusions like that: whether all or most of peers are > behind > NAT; whether centralized server could be available in every > application > scenarios, what is the suitable churn rate for the various > applications, > etc. > > If we could reach consensus on these issues, we could make it as a > input to > the design of the peer and/or client protocol. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 09:57:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfOc-0007O3-0v; Mon, 26 Nov 2007 09:57:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwfOa-0007LI-84 for p2psip@ietf.org; Mon, 26 Nov 2007 09:57:12 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwfOV-0007zL-Rt for p2psip@ietf.org; Mon, 26 Nov 2007 09:57:12 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id AB8DA33C21; Mon, 26 Nov 2007 06:52:07 -0800 (PST) Date: Mon, 26 Nov 2007 06:52:07 -0800 From: Eric Rescorla To: "David Barrett" Subject: Re: [P2PSIP] Routing mode in P2PSIP In-Reply-To: <20071126095402.BF2055C027@laser.networkresonance.com> References: <20071126022658.B69DE33C21@delta.rtfm.com> <20071126095402.BF2055C027@laser.networkresonance.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071126145207.AB8DA33C21@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 26 Nov 2007 02:01:30 -0800, David Barrett wrote: > > > -----Original Message----- > > From: Eric Rescorla [mailto:ekr@networkresonance.com] > > Subject: Re: [P2PSIP] Routing mode in P2PSIP > > > > > Eric, could you explain for me why do you think it is difficult to > > discover > > > that? > > > > How do you propose to discover it? It's certainly not enough to have > > a non-1597 address. Those are still sometimes NATed. You can compare > > your host candidate to whatever server reflexive candidates you have, > > but if you're unlucky about STUN server selection, they might still > > be the same. This complexity is part of why ICE does not attempt > > to make such determinations. > > For the record, there's a persistent myth that NAT classification is > difficult and unreliable. It's not. Luckily, I didn't say any such thing. > Just use several STUN servers that you > know are non-NAT'd, Yes, this is called assuming your premises. *Precisely* one of the concerns here is the ability to collect a reliable set of STUN servers. Yes, you can probably get a good estimate, but because these semi-recursive techniques don't do probing (a la ICE) but rather make the alleged "public" node a bottleneck, a very high degree of reliability is important. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 12:10:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhTm-0001jU-DL; Mon, 26 Nov 2007 12:10:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhTl-0001jI-5i for p2psip@ietf.org; Mon, 26 Nov 2007 12:10:41 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhTe-0004DK-N8 for p2psip@ietf.org; Mon, 26 Nov 2007 12:10:41 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 26 Nov 2007 09:10:34 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAQHAYkc016958; Mon, 26 Nov 2007 09:10:34 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAQHAWb5003353; Mon, 26 Nov 2007 17:10:32 GMT In-Reply-To: <001901c82fd5$e91312e0$6905a40a@china.huawei.com> References: <001901c82fd5$e91312e0$6905a40a@china.huawei.com> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <80DE4084-A8BA-4B26-A8DD-2A7E5703DB60@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 26 Nov 2007 09:09:56 -0800 To: P2PSIP Mailing List X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2395; t=1196097034; x=1196961034; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Requirements=20for=20=20Routing=20mode=20in=20P2PSIP |Sender:=20; bh=bAzj+PBCWWSYJFL/MFN1Et850BmYrwX3K4Om2RDvXr8=; b=dnTZc1fyRObhtQ01QI0V3ZMIxm9oO8KQRcH1YYXqkz47AaN41hE4Fq0vw0rtns5/RSgTPi9G zPRD9EhmO3Y1TwsYjjJ5d6XBdLoDH0Tqz7nZY5tj6A87aCNjJPQbiDrW; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [P2PSIP] Requirements for Routing mode in P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Sounds like a good suggestion to lay out some of the key requirements that will drive the designs... I'm sure there are many more but a few things I am thinking about below. On Nov 25, 2007, at 6:41 PM, JiangXingFeng wrote: > > BTW: If we have a requirement first, there may be no so many > arguments here. > How about work out a requirement first and then go to the protocol > design > work? Works when many of the peers are behind NATs Works with no centralized servers. One of the reasons I want this is so that things work if several perviously enrolled devices show up at an location of a emergency where some sort of adhoc network is up and running, and that adhoc network does not have connectivity to the global network. If we assume that we can use centralized servers, there are probably much easier solutions to this whole problem than most the current proposals in this WG. Works while the DHT overlays are in the process of splitting, or joining due to the radical changes in the network connectivity. Can resolve in under 5 seconds almost always and under 2 seconds most of the time. I realize these are very vaguely states and I would need to describe many other parameters to make them something we could design to but I can expand on this if it is useful. I find making them sort of "fluffy" helps not get wrapped around the axle on if a given design meets them or not. Not preclude the system from being usable in a routing systems that allows peers to conceal key privacy related information while at the same time not requiring that every deployment have to do this. Not exactly a requirements but a property that should be one of the properties that we try to optimize is ability to debug these networks. These tend to be some of the most complicated to diagnose systems I have ever worked with. The churn of peers make them significantly more complicated to diagnose that most distributed systems I have worked with and the inherent distributed system nature already made them much more complicated than a more traditional client/server architecture. Given the difficulty in diagnosing things on a typical SIP VoIP system today, I am very concerned about how hard it will be to diagnose things in these systems. Cullen _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 12:14:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhX7-0003l4-OF; Mon, 26 Nov 2007 12:14:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhX6-0003i1-Jg for p2psip@ietf.org; Mon, 26 Nov 2007 12:14:08 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwhWz-0004Ln-I3 for p2psip@ietf.org; Mon, 26 Nov 2007 12:14:08 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 26 Nov 2007 09:14:01 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAQHE0Ha000782; Mon, 26 Nov 2007 09:14:01 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAQHE0b5006597; Mon, 26 Nov 2007 17:14:00 GMT In-Reply-To: <14704AE7-D483-4438-8684-DB703DEFFB9D@cs.columbia.edu> References: <002d01c8300a$4c6edfc0$6905a40a@china.huawei.com> <14704AE7-D483-4438-8684-DB703DEFFB9D@cs.columbia.edu> Impp: xmpp:cullenfluffyjennings@jabber.org Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BB9CC64-88DE-4ECE-AD48-BC25FACF1350@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt Date: Mon, 26 Nov 2007 09:13:23 -0800 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=452; t=1196097241; x=1196961241; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[P2PSIP]=20Fw=3A=20I-D=20Action=3Adraft-bryan-p2psip- app-scenarios-00.txt |Sender:=20; bh=lZRMP4xPYgSzlR2IBXhPMKzgH683y/1K5YJGsvWzUxs=; b=rlGgvcSdX2tcyHWY3z3+XHonkBhdLYhcF+a4PfPnLbFY1rz+jsLt7oamDBJPGAXjIN4Yl3gZ sDnVBFETn5+rO191dxKEPuHiDtROiH/q7GyFlqczWKSbtWVJhgIdid+8; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 26, 2007, at 5:28 AM, Henning Schulzrinne wrote: > We already know > - that some fraction of peers may be behind NATs, but there's no > way to predict whether that's 0.1% or 100% and what kind of NATs > - that we may or may not have central servers > - that churn rates may be very high or close to zero > > Henning I think what I am seeing is more or less the same as Henning. Cullen _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 13:03:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiIe-0001I9-MY; Mon, 26 Nov 2007 13:03:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwiId-0001Hr-0f for p2psip@ietf.org; Mon, 26 Nov 2007 13:03:15 -0500 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwiIb-0006tP-Co for p2psip@ietf.org; Mon, 26 Nov 2007 13:03:14 -0500 Received: by py-out-1112.google.com with SMTP id d32so2628619pye for ; Mon, 26 Nov 2007 10:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=a+JoJOkaX4GSamuwrgy3AzJzc8tsWSU4pfOj+IfqEEU=; b=rteaY7a0NmVkbIIs49lrRmfEuTHzMl30B6YnMK/aFEm1+wKLwmjj6pUBaBkgX0mINvYT4/8SsSi442qXTFIDv73nYkyFsqeepUM/CcBY37qQCprjjxmMxckpgUuTyWkQS8dagfi+S6dKfv25obYKlIIEoGh4lBc7Kd8inRzTOmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=xFjpDdhixHGAgCzAZhjvP8xLjCBaMXmguF2oCU0I8lsFyxLbUAEovPC0fcC68cswCujUcBeesJeXsRMbuT8RfMx586yBu0HJufSrypBlLIrsEmpQm2z+ywRdxJ+XTLAIo8QZWc4R22M1gR9rHhSIizXjLMVYpr/yYOhnpPIfsxE= Received: by 10.65.119.14 with SMTP id w14mr6546615qbm.1196100192562; Mon, 26 Nov 2007 10:03:12 -0800 (PST) Received: by 10.65.180.16 with HTTP; Mon, 26 Nov 2007 10:03:12 -0800 (PST) Message-ID: <4d4304a00711261003v11530de2ga127dbc623640c6@mail.gmail.com> Date: Mon, 26 Nov 2007 13:03:12 -0500 From: "David A. Bryan" To: "Cullen Jennings" Subject: Re: [P2PSIP] Requirements for Routing mode in P2PSIP In-Reply-To: <80DE4084-A8BA-4B26-A8DD-2A7E5703DB60@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001901c82fd5$e91312e0$6905a40a@china.huawei.com> <80DE4084-A8BA-4B26-A8DD-2A7E5703DB60@cisco.com> X-Google-Sender-Auth: 9a7ccfd0166054c8 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org As folks who are actually already supporting shipping product on this stuff, I wanted to strongly support Cullen's comment that we keep ease of debugging in mind. We certainly have done so in our product/proposals, and it requires a good bit of forethought to get that right, but it is absolutely essential. Simplicity and the ability to easily examine what is going on are key features... David (as individual) On Nov 26, 2007 12:09 PM, Cullen Jennings wrote: > > Sounds like a good suggestion to lay out some of the key requirements > that will drive the designs... I'm sure there are many more but a few > things I am thinking about below. > > On Nov 25, 2007, at 6:41 PM, JiangXingFeng wrote: > > > > > BTW: If we have a requirement first, there may be no so many > > arguments here. > > How about work out a requirement first and then go to the protocol > > design > > work? > > Works when many of the peers are behind NATs > > Works with no centralized servers. One of the reasons I want this is > so that things work if several perviously enrolled devices show up at > an location of a emergency where some sort of adhoc network is up and > running, and that adhoc network does not have connectivity to the > global network. If we assume that we can use centralized servers, > there are probably much easier solutions to this whole problem than > most the current proposals in this WG. > > Works while the DHT overlays are in the process of splitting, or > joining due to the radical changes in the network connectivity. > > Can resolve in under 5 seconds almost always and under 2 seconds most > of the time. I realize these are very vaguely states and I would need > to describe many other parameters to make them something we could > design to but I can expand on this if it is useful. I find making > them sort of "fluffy" helps not get wrapped around the axle on if a > given design meets them or not. > > Not preclude the system from being usable in a routing systems that > allows peers to conceal key privacy related information while at the > same time not requiring that every deployment have to do this. > > Not exactly a requirements but a property that should be one of the > properties that we try to optimize is ability to debug these > networks. These tend to be some of the most complicated to diagnose > systems I have ever worked with. The churn of peers make them > significantly more complicated to diagnose that most distributed > systems I have worked with and the inherent distributed system nature > already made them much more complicated than a more traditional > client/server architecture. Given the difficulty in diagnosing things > on a typical SIP VoIP system today, I am very concerned about how > hard it will be to diagnose things in these systems. > > Cullen > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 15:12:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkJF-0007pa-71; Mon, 26 Nov 2007 15:12:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwkJE-0007oT-9g for p2psip@ietf.org; Mon, 26 Nov 2007 15:12:00 -0500 Received: from quinthar.com ([64.62.221.66]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IwkJA-00022S-E5 for p2psip@ietf.org; Mon, 26 Nov 2007 15:12:00 -0500 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Mon, 26 Nov 2007 12:11:53 -0800 From: "David Barrett" To: "'Eric Rescorla'" Subject: RE: [P2PSIP] Routing mode in P2PSIP Date: Mon, 26 Nov 2007 12:11:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgwPZKOre9h9h8LTfG0hwgObs9FgwAKPb1Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20071126145207.AB8DA33C21@delta.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Subject: Re: [P2PSIP] Routing mode in P2PSIP > > > > > Eric, could you explain for me why do you think it is difficult to > > > discover > > > > that? > > > > > > How do you propose to discover it? It's certainly not enough to have > > > a non-1597 address. Those are still sometimes NATed. You can compare > > > your host candidate to whatever server reflexive candidates you have, > > > but if you're unlucky about STUN server selection, they might still > > > be the same. This complexity is part of why ICE does not attempt > > > to make such determinations. > > > > For the record, there's a persistent myth that NAT classification is > > difficult and unreliable. It's not. > > Luckily, I didn't say any such thing. Ah, oops -- I misinterpreted your text. I'm glad we agree NAT classification is both possible and useful given a reliable set of STUN servers. Sorry for the confusion! As for how to get the "reliable set of STUN servers" in the first place, I'm assuming that when you contact the bootstrap service, it gives you a list of STUN servers. To start, the list would be populated by a "bootstrap STUN service" (a small set of globally hosted STUN servers). But as nodes are added to the network, those who are not firewalled add themselves to the list for future nodes to use. The upshot is your pool of STUN servers scales with total network size. Anyway, just piping up as I (mistakenly) thought I heard trash-talking about NAT classification, and I wanted to chime in to set the record straight. -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 20:06:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwouX-0003Sk-RR; Mon, 26 Nov 2007 20:06:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwouW-0003Re-DW for p2psip@ietf.org; Mon, 26 Nov 2007 20:06:48 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwouU-0001SE-0z for p2psip@ietf.org; Mon, 26 Nov 2007 20:06:48 -0500 Received: by rv-out-0910.google.com with SMTP id l15so707494rvb for ; Mon, 26 Nov 2007 17:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:message-id:mime-version:content-type:x-mailer:x-mimeole:thread-index; bh=YKwnFEpmPA4qUfarABXOZpqLx+D/1TJFtZB9m1AwGN8=; b=vJvY6NmHglPp7EmSjqWOPUA4I67LBThRN+ikcaZuHFjd4BUpbl9NbN2ifxiUwihL44YqZDzVrIQhV7KCuwlr4CjdidgseJvDfN1yfJlCHY2wfKPVjioQAxWII/v2ifSUqY57RejGozjKz9FrHZ7xn+zMx5L8jJiVH1ukhINZgeM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:from:to:subject:date:message-id:mime-version:content-type:x-mailer:x-mimeole:thread-index; b=jPcJuY7RwcAwqrrQWiLV5MLia0HihbHQjkqUUwsEEZeKFLFHF8Hs12ZLWBRmoH//4zKw/5nEdC5sUcMCTZA9h5CT9iy4hp/IZkg/oeeECgkKa0+XMwzBXieFd+wGNCe266+CFcSF0eMPlqsTXJZ/hBUBRvx0gm4giWTDJBsGdOo= Received: by 10.141.99.4 with SMTP id b4mr1570362rvm.1196125591019; Mon, 26 Nov 2007 17:06:31 -0800 (PST) Received: from mlifewangyao ( [123.116.131.244]) by mx.google.com with ESMTPS id f13sm4625527rvb.2007.11.26.17.06.28 (version=SSLv3 cipher=RC4-MD5); Mon, 26 Nov 2007 17:06:30 -0800 (PST) From: "Yao Wang" To: "'P2PSIP Mailing List'" Date: Tue, 27 Nov 2007 09:07:36 +0800 Message-ID: <001801c83091$e78b5b00$9a00a8c0@mlifewangyao> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgwkeXBY/9OJSqbQZiBgVvbIcUVSw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Subject: [P2PSIP] New Draft available online: Different types of nodes in P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0270013841==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0270013841== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C830D4.F5AE9B00" This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C830D4.F5AE9B00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, everyone Thanks to Mr. Bryan=E2=80=99s help, our new draft, which is = named as =E2=80=9CDifferent types of nodes in P2PSIP=E2=80=9D, is = currently available online at = http://www.p2psip.org/drafts/draft-li-p2psip-node-types-00.txt. =20 This document is an attempt to classify different types of node in = peer-to-peer Session Initiation Protocol (P2PSIP). Four possible types = of nodes in P2PSIP are discussed based on two characters: whether it = offers overlay-routing services and whether it offers storage functions. = The behaviors of each type of nodes and their possible necessities are = analyzed. This document is dedicated to be a reference for clarifying = some controversial terms in P2PSIP working group, such as "client", = "low-function peer", etc. =20 This draft was published firstly as an attachment on last Friday. Until = now, there have been some discussions which we appreciate very much on = this subject. We will modify some descriptions of this draft based on = the rough consensus of the discussions if necessary. =20 Comments are always welcomed.=20 =20 =20 Sincerely yours, =20 Yao Wang=20 Mobile Life and New Media Lab, BUPT =20 =20 ------=_NextPart_000_0019_01C830D4.F5AE9B00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hello, everyone

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Thanks to Mr. Bryan=E2=80=99s help, our new draft, which is named as =E2=80=9CDifferent types of nodes in = P2PSIP=E2=80=9D, is currently available online at h= ttp://www.p2psip.org/drafts/draft-li-p2psip-node-types-00.txt.

 

This document = is an attempt to classify different types of node in peer-to-peer Session = Initiation Protocol (P2PSIP).=C2=A0 Four possible types of nodes in P2PSIP are = discussed based on two characters: whether it offers overlay-routing services and = whether it offers storage functions.=C2=A0 The behaviors of each type of nodes and = their possible necessities are analyzed.=C2=A0 This document is dedicated to be a = reference for clarifying some controversial terms in P2PSIP working group, such as "client", "low-function peer", = etc.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

This draft was = published firstly as an attachment on last Friday. Until now, there have been some discussions which we appreciate very much on this subject. We will = modify some descriptions of this draft based on the rough consensus of the = discussions if necessary.

 

Comments are = always welcomed.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=

 

Sincerely yours,

 

Yao Wang 

Mobile Life and New Media Lab, = BUPT

 

 

------=_NextPart_000_0019_01C830D4.F5AE9B00-- --===============0270013841== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0270013841==-- From p2psip-bounces@ietf.org Mon Nov 26 20:51:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwpby-0001Kj-G7; Mon, 26 Nov 2007 20:51:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwpbx-0001KX-93 for p2psip@ietf.org; Mon, 26 Nov 2007 20:51:41 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iwpbw-0008Ag-Hn for p2psip@ietf.org; Mon, 26 Nov 2007 20:51:41 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS500JC26H5Z9@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 09:51:05 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS500B636H4B9@szxga01-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 09:51:05 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS500N5R6H400@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 09:51:04 +0800 (CST) Date: Tue, 27 Nov 2007 09:51:00 +0800 From: Song Yongchao Subject: RE: [P2PSIP] Routing mode in P2PSIP In-reply-to: <200711262011.ALT70949@szxrg04-in.huawei.com> To: 'David Barrett' Message-id: <004801c83097$f87aee20$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgwPZKOre9h9h8LTfG0hwgObs9FgwAKPb1QAAuJPQA= X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > > > For the record, there's a persistent myth that NAT classification is > > > difficult and unreliable. It's not. > > > > Luckily, I didn't say any such thing. > > Ah, oops -- I misinterpreted your text. I'm glad we agree NAT > classification is both possible and useful given a reliable set of STUN > servers. I agree with that. There is no doubt here. > As for how to get the "reliable set of STUN servers" in the first place, I'm > assuming that when you contact the bootstrap service, it gives you a list of > STUN servers. To start, the list would be populated by a "bootstrap STUN > service" (a small set of globally hosted STUN servers). But as nodes are > added to the network, those who are not firewalled add themselves to the > list for future nodes to use. The selection of STUN servers is a problem that we must concern about in P2P overlay. Because a node may be behind multiple NATs, with an unlucky STUN server selection(also NATed), it may be of no use to setup a direct connection between two NATed peers. What I suggest, is to make powerful peers or servers with "Public" address to provide STUN service. It must be very useful for collecting effective candidates to setup direct connections, and at the same time, they can perform the role of message RELAY in the overlay. Best Regards! Song Yongchao _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 21:33:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqGf-00044d-Bu; Mon, 26 Nov 2007 21:33:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqGc-00044R-UA for p2psip@ietf.org; Mon, 26 Nov 2007 21:33:42 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwqGY-000195-Qh for p2psip@ietf.org; Mon, 26 Nov 2007 21:33:42 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS500E7D8EJYJ@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 10:32:44 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS50061R8EIFX@szxga02-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 10:32:43 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS5003X68EEZ8@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 10:32:42 +0800 (CST) Date: Tue, 27 Nov 2007 10:32:38 +0800 From: Zheng Hewen Subject: RE: [P2PSIP] P2PSIP security requirements In-reply-to: <3F18E76823C95E4795181D74BAC7664F057538D4@esebe102.NOE.Nokia.com> To: marcin.matuszewski@nokia.com, p2psip@ietf.org Message-id: <005701c8309d$c7324ba0$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acgqsj9UsxgjVb+ZSu6NTuZ45gG7lwBiYDpAARcG8IA= X-Spam-Score: 0.3 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: jan-erik.ekberg@nokia.com, pekka.laitinen@nokia.com X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Here are some cents after a quick look. (1).In Section 2.3, "Enrolment protocol" appears, is it a distinctly different protocol from peer/client protocol? Would you give an example? (2).Do you think that resource records pollution is a security threat to P2PSIP overlay? For example, some malicious node may publish fake resource records; it will cause some negative impaction; (3).For "Req.7: It MUST be difficult to select a particular peer ID e.g. peer ID assignment process should introduce some degree of randomness to peer identities", Should "e.g." be "i.e."? (4)."Req. 9: It MUST NOT be possible to repeat or delay valid data transmission during enrollment and modification of P2PSIP resource (user) records". I did not understand it, why do we need it? (5).Req.16 says "It SHOULD be possible to limit the impact of badly behaving P2PSIP nodes on the overall system security. There SHOULD be an option to identify malfunctioning or badly behaving nodes, and exclude or reject them from the P2PSIP system", in my understanding, we can reject suspicious nodes through Enrollment process or some mechanism like blacklisting, how to exclude those nodes? Explicit exclusion routing method like RSVP-TE EXO? Another personal opinion, for P2PSIP overlay, extra security requirements are mandatory in some scenarios such as in an unknown Internet environment, but they are optional in some scenarios such as in an autonomous enterprise private network, do you think so? Certainly, those requirements listed in the I-D are basic and necessary for untrusty network. Any comment please. Best regards, Hewen > -----Original Message----- > From: marcin.matuszewski@nokia.com > [mailto:marcin.matuszewski@nokia.com] > Sent: 2007?11?26? 18:17 > To: p2psip@ietf.org > Cc: jan-erik.ekberg@nokia.com; pekka.laitinen@nokia.com > Subject: [P2PSIP] P2PSIP security requirements > > > Hi all, > > We submitted a new version of the security requirements draft: > http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-s > ecurity-re > quirements-02.txt. We improved the security threats section > and modified requirements according to your comments. > > This document presents a basic set of security requirements > that we believe that each of the proposals needs to address: > > P2PSIP system requirements related to security issues are summarized > below: > > Req. 1: Dependence of reachability of a centralized server > SHOULD be > minimized. > > Req. 2: P2PSIP security SHOULD scale from a small ad-hoc > network to a > network with hundred millions of network nodes and users. > > Req. 3: Existing security mechanisms SHOULD be used as much as > possible to protect P2PSIP functions, and avoid the need for > standardizing new mechanisms. > > Req. 4: Security requirements on the base P2P algorithm (e.g., DHT > implementations) used in P2PSIP SHOULD be minimized and SHOULD NOT > limit its scalability. > > Req. 5: The registered identities in a P2PSIP overlay MUST be > preserved. The attacker MUST NOT be able to steal identity from > another user. > > Req. 6: The enrollment process MUST make it difficult for > an attacker > to register many identities in a P2PSIP overlay and easily > modify the > registered identities. > > Req. 7: It MUST be difficult to select a particular peer > ID e.g. peer > ID assignment process should introduce some degree of randomness to > peer identities. > > Req. 8: It MUST be possible to authenticate users and > P2PSIP network > entities. > > Req. 9: It MUST NOT be possible to repeat or delay valid data > transmission during enrollment and modification of P2PSIP resource > (user) records. > > Req. 10: The P2PSIP security MUST support integrity > protection of the > data being inserted or retrieved to/from an overlay. > > Req. 11: The P2PSIP network entities MUST be provided with > an option > to encrypt data exchanged with other P2PSIP network entities. > > Req. 12: Only authorized users and P2PSIP network entities MUST be > able to join the P2PSIP system and insert, modify, delete or > overwrite P2PSIP resource (user) records in the P2PSIP system. > > Req. 13: In the situations where many users or P2PSIP network > entities register the same resource in the P2PSIP overlay, each > entity MUST have rights only to its own part of a resource record. > > Req. 14: An owner of P2PSIP resource (user) record MAY > indicate which > users or network entities can retrieve, modify, and delete data > stored in their P2PSIP resource (user) records. > > Req. 15: P2PSIP overlay protocols MUST be designed such a > way so that > the effect of DOS attacks on the P2PSIP overlay is minimized. > > Req. 16: It SHOULD be possible to limit the impact of > badly behaving > P2PSIP nodes on the overall system security. There SHOULD be an > option to identify malfunctioning or badly behaving nodes, and > exclude or reject them from the P2PSIP system. > > > We would appreciate your comments! > > Marcin > > >A new version of I-D, > >draft-matuszewski-p2psip-security-requirements-02.txt has been > >successfuly submitted by Marcin Matuszewski and posted to the IETF > >repository. > > > >Filename: draft-matuszewski-p2psip-security-requirements > >Revision: 02 > >Title: Security requirements in P2PSIP > >Creation_date: 2007-11-19 > >WG ID: Independent Submission > >Number_of_pages: 23 > > > >Abstract: > >This document presents main security requirements for the > >Peer-to- Peer SIP (P2PSIP) architecture and its components. > >This document also analyses security threats in P2PSIP. > >Typical security ontology is used as classification for the threats. > > > > > > > > > >The IETF Secretariat. > > > > > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 21:39:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqMZ-0000T1-D1; Mon, 26 Nov 2007 21:39:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqMX-0000Sq-S7 for p2psip@ietf.org; Mon, 26 Nov 2007 21:39:49 -0500 Received: from chip2og53.obsmtp.com ([64.18.13.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwqMU-0007P2-0y for p2psip@ietf.org; Mon, 26 Nov 2007 21:39:49 -0500 Received: from source ([192.150.11.134]) by chip2ob53.postini.com ([64.18.5.12]) with SMTP; Mon, 26 Nov 2007 18:39:39 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAR2bQOP017216; Mon, 26 Nov 2007 18:37:30 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAR2dOFZ001974; Mon, 26 Nov 2007 18:39:33 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 11:39:25 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Requirements for Routing mode in P2PSIP Date: Mon, 26 Nov 2007 18:39:21 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE344@namail5.corp.adobe.com> In-Reply-To: <4d4304a00711261003v11530de2ga127dbc623640c6@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Requirements for Routing mode in P2PSIP Thread-Index: AcgwVqRaRl8WIQJxQZOgdarQErnHiAARZBmA References: <001901c82fd5$e91312e0$6905a40a@china.huawei.com><80DE4084-A8BA-4B26-A8DD-2A7E5703DB60@cisco.com> <4d4304a00711261003v11530de2ga127dbc623640c6@mail.gmail.com> From: "Henry Sinnreich" To: "David A. Bryan" , "Cullen Jennings" X-OriginalArrivalTime: 27 Nov 2007 02:39:25.0815 (UTC) FILETIME=[B9AD0870:01C8309E] X-Spam-Score: -4.0 (----) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I strongly agree with both Cullen and David about the need for ease of debugging P2PSIP systems. The proof would consist in someone proposing tools for debugging P2PSIP and actually reporting on their efficiency. To make this actionable, how about adding this as a WG deliverable? Even if it is a slightly longer term objective?=20 Henry -----Original Message----- From: David A. Bryan [mailto:dbryan@sipeerior.com]=20 Sent: Monday, November 26, 2007 12:03 PM To: Cullen Jennings Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Requirements for Routing mode in P2PSIP As folks who are actually already supporting shipping product on this stuff, I wanted to strongly support Cullen's comment that we keep ease of debugging in mind. We certainly have done so in our product/proposals, and it requires a good bit of forethought to get that right, but it is absolutely essential. Simplicity and the ability to easily examine what is going on are key features... David (as individual) On Nov 26, 2007 12:09 PM, Cullen Jennings wrote: > > Sounds like a good suggestion to lay out some of the key requirements > that will drive the designs... I'm sure there are many more but a few > things I am thinking about below. > > On Nov 25, 2007, at 6:41 PM, JiangXingFeng wrote: > > > > > BTW: If we have a requirement first, there may be no so many > > arguments here. > > How about work out a requirement first and then go to the protocol > > design > > work? > > Works when many of the peers are behind NATs > > Works with no centralized servers. One of the reasons I want this is > so that things work if several perviously enrolled devices show up at > an location of a emergency where some sort of adhoc network is up and > running, and that adhoc network does not have connectivity to the > global network. If we assume that we can use centralized servers, > there are probably much easier solutions to this whole problem than > most the current proposals in this WG. > > Works while the DHT overlays are in the process of splitting, or > joining due to the radical changes in the network connectivity. > > Can resolve in under 5 seconds almost always and under 2 seconds most > of the time. I realize these are very vaguely states and I would need > to describe many other parameters to make them something we could > design to but I can expand on this if it is useful. I find making > them sort of "fluffy" helps not get wrapped around the axle on if a > given design meets them or not. > > Not preclude the system from being usable in a routing systems that > allows peers to conceal key privacy related information while at the > same time not requiring that every deployment have to do this. > > Not exactly a requirements but a property that should be one of the > properties that we try to optimize is ability to debug these > networks. These tend to be some of the most complicated to diagnose > systems I have ever worked with. The churn of peers make them > significantly more complicated to diagnose that most distributed > systems I have worked with and the inherent distributed system nature > already made them much more complicated than a more traditional > client/server architecture. Given the difficulty in diagnosing things > on a typical SIP VoIP system today, I am very concerned about how > hard it will be to diagnose things in these systems. > > Cullen > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 21:46:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqTF-0005FJ-K1; Mon, 26 Nov 2007 21:46:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqTE-0005FB-CN for p2psip@ietf.org; Mon, 26 Nov 2007 21:46:44 -0500 Received: from py-out-1112.google.com ([64.233.166.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwqTC-0007bx-Md for p2psip@ietf.org; Mon, 26 Nov 2007 21:46:44 -0500 Received: by py-out-1112.google.com with SMTP id d32so3465778pye for ; Mon, 26 Nov 2007 18:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=AAyKbsLGgE8ZrCzKnAREgRRYzxeqLtSgf1hWK+14eEo=; b=ODQaFKvs1k8ZvGplgAzyCqZgrepfdKhCoVHfidnHKM0IQlqV5hX8WiMyLdJ+U1UPMm5RVcJmoVn94ChlhEKkTei1brZcFEcSGnp1XfHRPuAFTNv4stfRI/6SEZxWvm+MkgUSgrQ2gwrbAqJk3QnoaS6usS4jHMHz0XZJ6XIA08Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=GHTXlznKvUbliqrUQR+DHpyCBT+OjDR5cSQUH0UdB5o2ux6Gkd4VK7XNZgMJVxL3dtQBvM9RFKpvIHtEgAtSs16b9jQfTobvlv1K3ESPyCx3kVGo7jH2T0CPC+0YmvYcFxMBAGj1MMPoQEwUnm6JqepFMvog8qLbnEriIStEz5g= Received: by 10.65.203.3 with SMTP id f3mr7517124qbq.1196131602117; Mon, 26 Nov 2007 18:46:42 -0800 (PST) Received: by 10.65.180.16 with HTTP; Mon, 26 Nov 2007 18:46:42 -0800 (PST) Message-ID: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> Date: Mon, 26 Nov 2007 21:46:42 -0500 From: "David A. Bryan" To: "P2PSIP Mailing List" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: b740be27926e066a X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [P2PSIP] Agenda for the upcoming meeting in Vancouver X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Please find the newest version of the agenda below. A few comments. To minimize slide changing time we are going to insist (no exceptions) that slides be sent to the chairs in no later than 5pm Tuesday night so we can have them all ready to go. We are taking the approach of leading discussion on 5 topics that have generated list traffic. We have allocated :15 minutes for each. Each person listed as a leader should make slides and discuss them on list prior to the meeting, with an eye toward the discussion being able to reach some real consensus on that issue. If people don't get something out prior to Vancouver, we may find a different leader. Please check to see if you are a proposed leader. If you are and don't want to be, let us know and we'll find someone else. We've left time at the end for specific protocol discussions, but if we run overtime, these will get bumped. For the existing ones, the focus should be on what is new. For the new protocols (those submitted this cycle) the talk must be on why you made a new protocol (What is unique about it/benefits over the earlier proposals) Thanks, David (and Brian) (as chairs) Agenda: P2PSIP Agenda Wednesday, 5 December, 2007, 1300-1500 in Salon D/E Chairs: David Bryan Brian Rosen Agenda Bash/Administrivia (Chairs) :10 Open Questions Discussion :15 minutes per topic The purpose of this section is to discuss, in detail, a few of the topics that have been being discussed most extensively on the mailing list and that the group appears to have to address to move forward on a serious protocol draft. Goals here are grand and lofty and we may have to settle for less... The proposed leader *must* discuss this (and share slide text in advance of the meeting) on-list to build up a good discussion on the topic. Topic: "Routing: What does it look like?" Leader: Spencer Dawkins Goal: How many routing techniques do we need, and can we pick a set? Discuss/compare different routing techniques (iterative, recursive, semi-recursive, as well as symmetric vs. asymmetric). Can we decide on a set for the protocol to implement? Topic: "NAT Traversal for P2P Messages" Leader: Philip Matthews Goal: Decide on what a NAT traversal mechanism will look like. How do we implement NAT traversal for P2P messages? How do we locate STUN servers (if we use them) Topic: "Do we need clients (other than SIP)?" Leader: Marcin Matuszewski Goal: Present a set of use cases for why clients are needed, get consensus or if we need them Topic: "PeerID assignment and Chosen Location Attacks" Leader: Eric Rescorla Goal: Understand the implications of PeerID assignment on security Take a look at how PeerIDs can be selected, and how this affects chosen location attacks. Discuss different approaches offered for ID assignment. Topic: "Replication" Leader: Bruce Lowekamp Goal: Understand the problems inherent in replication. Compare mechanisms for replication (root replicates, source replicates, other) and discuss how we might select. More importantly, *where* in the protocol (DHT level, application level) should this happen? Concepts Document (TBD) :10 Open questions on the concepts draft. Hopefully, some clarification to some questions will come from the above discussions. (Very unlikely to actually get time...) Peer Protocol Proposal Discussions (authors) :05 per proposal (:10 for merged proposals so as not to penalize merging. Time permitting) Time limit will be *very* strictly enforced For existing proposals, topic must be about what has changed since the last version. For new proposals, topic must be what is new about this draft? Why a new draft instead of a tweak to one of the existing proposals? * RELOAD (merged with ASP, :10) * P2PP * HIPHOP * XPP * with HIP * SEP/Client Protocol * P2PNS Reading: Because this agenda revolves around the questions, rather than specific drafts being proposed, a specific reading list is not possible. See www.p2psip.org/ietf.php for a list of current drafts, and revisit the mailing list for recent discussion on these items. -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 21:57:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqdB-0004b5-GG; Mon, 26 Nov 2007 21:57:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwqd8-0004av-Ol for p2psip@ietf.org; Mon, 26 Nov 2007 21:56:58 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwqd4-0007uj-JX for p2psip@ietf.org; Mon, 26 Nov 2007 21:56:58 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS500HR79HHYD@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 10:56:05 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS500FE29HGAT@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 10:56:05 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS5004OE9HF2P@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 10:56:04 +0800 (CST) Date: Tue, 27 Nov 2007 10:56:03 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt In-reply-to: <14704AE7-D483-4438-8684-DB703DEFFB9D@cs.columbia.edu> To: 'Henning Schulzrinne' Message-id: <008701c830a1$0cc31ac0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcgwMCxP/5wKuS+MTnWmuvM5NfR78wAb7gSQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Henning: Does it mean that a resulting peer protocol is an all-weather one? Does it mean that we should work out various building blocks and it is up to the operator to choose what kinds of combination of these building blocks which will work well in the given scenario? Regards! -- Jiang XingFeng > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, November 26, 2007 9:28 PM > To: JiangXingFeng > Cc: 'Spencer Dawkins'; 'P2PSIP Mailing List' > Subject: Re: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt > > I'm sorry, but none of these questions are likely to be answerable > with any degree of specificity, so delaying work or hoping for answers > is not too helpful. Like in many other circumstances, we have to > design robust and extensible protocols that recognize that protocol > designers almost always fail to predict the range of use for their > creations. > > We already know > - that some fraction of peers may be behind NATs, but there's no way > to predict whether that's 0.1% or 100% and what kind of NATs > - that we may or may not have central servers > - that churn rates may be very high or close to zero > > Henning > > On Nov 26, 2007, at 3:56 AM, JiangXingFeng wrote: > > > Hi, Spencer: > > > > Thanks for the analysis work of application scenarios from you guys. > > > > Application scenarios vary tremendously in its attributes you have > > classified. Do you want our resulting protocol support all or most > > of the > > application scenarios? > > > > IMHO, the more valuable work is to find the commonalities among them > > and try > > to get some conclusions like that: whether all or most of peers are > > behind > > NAT; whether centralized server could be available in every > > application > > scenarios, what is the suitable churn rate for the various > > applications, > > etc. > > > > If we could reach consensus on these issues, we could make it as a > > input to > > the design of the peer and/or client protocol. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 22:31:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrAf-00038e-3a; Mon, 26 Nov 2007 22:31:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrAd-00038B-TU for p2psip@ietf.org; Mon, 26 Nov 2007 22:31:35 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwrAa-00087W-J5 for p2psip@ietf.org; Mon, 26 Nov 2007 22:31:35 -0500 Received: from Henning-Schulzrinnes-Computer (pool-70-21-184-101.nwrk.east.verizon.net [70.21.184.101]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAR3VNme001462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Nov 2007 22:31:24 -0500 (EST) Message-Id: <989483F2-39DA-40AB-9AC1-D288C298C041@cs.columbia.edu> From: Henning Schulzrinne To: JiangXingFeng In-Reply-To: <008701c830a1$0cc31ac0$6905a40a@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt Date: Mon, 26 Nov 2007 22:31:23 -0500 References: <008701c830a1$0cc31ac0$6905a40a@china.huawei.com> X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -1.0 (-) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Yes, in the sense that all Internet protocols have to operate in all kinds of "weather". Ideally, they'll be able to make use of "sunshine" to perform better. However, I wouldn't use the term "operator" - there may not be an operator in the traditional sense. Also, I would hope that smart implementations are adaptive, rather than requiring manual configuration. We don't want a system that needs a dozen parameters to be tweaked by a user or "operator". On Nov 26, 2007, at 9:56 PM, JiangXingFeng wrote: > Hi, Henning: > > Does it mean that a resulting peer protocol is an all-weather one? > Does it > mean that we should work out various building blocks and it is up to > the > operator to choose what kinds of combination of these building > blocks which > will work well in the given scenario? > > Regards! _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 22:43:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrM6-0003Ba-A7; Mon, 26 Nov 2007 22:43:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrM5-0003BL-7T for p2psip@ietf.org; Mon, 26 Nov 2007 22:43:25 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwrM2-0002gh-3i for p2psip@ietf.org; Mon, 26 Nov 2007 22:43:25 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS500HJDBI792@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 11:39:43 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS500255BI60G@szxga03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 11:39:43 +0800 (CST) Received: from j36340 ([10.164.5.105]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS5003HXBI6Z8@szxml03-in.huawei.com> for p2psip@ietf.org; Tue, 27 Nov 2007 11:39:42 +0800 (CST) Date: Tue, 27 Nov 2007 11:39:42 +0800 From: JiangXingFeng Subject: RE: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt In-reply-to: <989483F2-39DA-40AB-9AC1-D288C298C041@cs.columbia.edu> To: 'Henning Schulzrinne' Message-id: <008801c830a7$2586c4c0$6905a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acgwpf4MjEC/0I5DSJmLg/Cjc3GBAwAAGuuw X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > Yes, in the sense that all Internet protocols have to operate in all > kinds of "weather". Ideally, they'll be able to make use of "sunshine" > to perform better. One further question: We try to make each building block work well in all kinds of weather as much as possible. But it may be harder to achieve this goal. Does it mean that we could develop some complementary building blocks each of which may perform better in different scenarios? > However, I wouldn't use the term "operator" - there may not be an > operator in the traditional sense. Also, I would hope that smart > implementations are adaptive, rather than requiring manual > configuration. We don't want a system that needs a dozen parameters to > be tweaked by a user or "operator". Right. One of the advantage of the P2P system is self-organization. What I want to say here: it is up to the implementers to choose a given combination of building blocks to be used in a given scenarios. > > On Nov 26, 2007, at 9:56 PM, JiangXingFeng wrote: > > > Hi, Henning: > > > > Does it mean that a resulting peer protocol is an all-weather one? > > Does it > > mean that we should work out various building blocks and it is up to > > the > > operator to choose what kinds of combination of these building > > blocks which > > will work well in the given scenario? > > > > Regards! _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Mon Nov 26 22:53:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrW8-0003mn-My; Mon, 26 Nov 2007 22:53:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwrW7-0003mU-1R for p2psip@ietf.org; Mon, 26 Nov 2007 22:53:47 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwrW3-0004IO-At for p2psip@ietf.org; Mon, 26 Nov 2007 22:53:47 -0500 Received: from Henning-Schulzrinnes-Computer (pool-70-21-184-101.nwrk.east.verizon.net [70.21.184.101]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAR3rc1Q005097 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 26 Nov 2007 22:53:39 -0500 (EST) Message-Id: <7F74F53E-8259-46BD-836B-708D16D1975F@cs.columbia.edu> From: Henning Schulzrinne To: JiangXingFeng In-Reply-To: <008801c830a7$2586c4c0$6905a40a@china.huawei.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [P2PSIP] Fw: I-D Action:draft-bryan-p2psip-app-scenarios-00.txt Date: Mon, 26 Nov 2007 22:53:38 -0500 References: <008801c830a7$2586c4c0$6905a40a@china.huawei.com> X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: -1.0 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 26, 2007, at 10:39 PM, JiangXingFeng wrote: >> Yes, in the sense that all Internet protocols have to operate in all >> kinds of "weather". Ideally, they'll be able to make use of >> "sunshine" >> to perform better. > > One further question: We try to make each building block work well > in all > kinds of weather as much as possible. But it may be harder to > achieve this > goal. Does it mean that we could develop some complementary building > blocks > each of which may perform better in different scenarios? I don't know how one can answer such a question in general. More building blocks can be useful, but you pay in terms of overall system complexity and interoperability problems, since there are now more likely to be many more combinations of feature sets to contend with. Henning _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 02:55:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwvIE-0008Ec-NU; Tue, 27 Nov 2007 02:55:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwvIC-00089M-OG for p2psip@ietf.org; Tue, 27 Nov 2007 02:55:40 -0500 Received: from mail33-43.sinamail.sina.com.cn ([202.108.33.43]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwvIB-0001WY-5T for p2psip@ietf.org; Tue, 27 Nov 2007 02:55:40 -0500 X-srcip: 211.160.21.17 Received: from dellwei (unknown [211.160.21.17]) by smtp.vip.sina.com (SINAMAIL) with ESMTP id AA13C14DDC19 for ; Tue, 27 Nov 2007 15:55:35 +0800 (CST) Message-ID: <004801c830ca$e350ceb0$da07740a@dellwei> From: "Wei Gengyu" To: "P2PSIP Mailing List" References: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com><000001c82e45$eae81ac0$5105a40a@china.huawei.com><7d6b50690711232042i2f4bfe9au65c0b5b38a8e40b5@mail.gmail.com> <008c01c82e78$86e818d0$da07740a@dellwei> Subject: Re: [P2PSIP] P2P layer and Peer Identifier Date: Tue, 27 Nov 2007 15:55:33 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 2.8 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1355685416==" Errors-To: p2psip-bounces@ietf.org --===============1355685416== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGksIGFsbCwgDQoNCkkgbWFrZSB0aGUgcXVlc3Rpb24gY29uY3JldC4NCg0KRnJvbSBSRkMgNDQy Mywgd2Uga25vdyB0aGF0ICJ0aGUgSG9zdCBJZGVudGl0eSBQcm90b2NvbCAoSElQKSwgYmV0d2Vl biB0aGUgaW50ZXJuZXR3b3JraW5nIGFuZCB0cmFuc3BvcnQgbGF5ZXJzIg0KU28sIHdlIGNhbiBk cmF3IGEgcGljdHVyZSBvZiBISVAgcHJvdG9jb2wgbGF5ZXIgaW4gdGhlIEludGVybmV0IGFzIGZv bGxvd3M6DQoNCiANCg0KICAgICAgQXBwbGljYXRpb24gbGF5ZXINCiAgICAgDQogICAgICBUQ1Av VURQDQogICAgIA0KICAgICAgSElQDQogICAgIA0KICAgICAgSVANCiAgICAgDQogDQoNCiANCg0K IA0KDQogDQoNCiANCg0KIA0KDQoNCg0KSG93IEhJUCB1c2VkIGluIHRoZSBQMlBTSVAgb3Zlcmxh eT8gIFdlIGhhdmUgc2VlbiB0d28gcHJvcG9zZWQgaW4gdGhlIEktRHMuIA0KDQoNCg0KVGhlIGZp cnN0IG9uZSBpcyBpbiAiZHJhZnQtbWF0dGhld3MtcDJwc2lwLWhpcC1ob3AtMDAuIiAgSXQgZGVw aWN0cyB0aGUgcHJvdG9jb2wgYXJjaGl0ZWN0dXJlIG9mIFAyUCBsYXllciBpbiB0d28gcGxhY2Vz IGFzIGZvbGxvd3M6IA0KDQoiQ29uc2lkZXIgdGhlIGFyY2hpdGVjdHVyZSBmb3IgYSBQMlBTSVAg cGVlciBzaG93biBpbiBGaWd1cmUgMSIuDQoNCiANCg0KICAgICAgU0lQDQogICAgIE90aGVyIGFw cGxpY2F0aW9ucw0KICAgICANCiAgICAgIERpc3RyaWJ1dGVkIERhdGFiYXNlDQogICAgIERpc3Ry aWJ1dGVkIERhdGFiYXNlDQogICAgIA0KICAgICAgRGlzdHJpYnV0ZWQgVHJhbnNwb3J0DQogICAg IA0KDQogDQoNCiJGaWd1cmUgNCBzaG93cyB0aGUgZnVuZGFtZW50YWwgcHJvdG9jb2wgbGF5ZXJp bmcgaW4gb3VyIHByb3Bvc2FsLiINCg0KICAgICAgU0lQDQogICAgIE90aGVyIGFwcGxpY2F0aW9u cw0KICAgICANCiAgICAgIERpc3RyaWJ1dGVkIGRhdGFiYXNlDQogICAgIE92ZXJsYXkgbWFpbnRl bmFuY2UNCiAgICAgDQogICAgICBUQ1B2NiwgVURQdjYsIFRMUywgZXRjLg0KICAgICANCiAgICAg IEhJUCBvciBFU1ANCiAgICAgDQogICAgICBVRFB2NA0KICAgICBVRFB2Ng0KICAgICANCiAgICAg IElQdjQNCiAgICAgSVB2Ng0KICAgICANCg0KIA0KDQogDQoNClRoZSBzZWNvbmQgb25lIGlzIGlu ICJkcmFmdC1oYXV0YWtvcnBpLXAycHNpcC13aXRoLWhpcC0wMS50eHQiDQoNCiJUaGUgbmV0d29y ayBwcm90b2NvbCBsYXllcmluZywgaW4gZm91ciBkaXN0aW5jdCBjYXNlcywgaXMgaWxsdXN0cmF0 ZWQgaW4gRmlndXJlIDMuIih0aGUgZm9sbG93aW5nIGZpZ3VyZSkNCg0KIA0KDQogICAgICBISVAN CiAgICAgIA0KICAgICAgDQogICAgICANCiAgICAgDQogICAgICBQZWVyIHByb3RvY29sDQogICAg IFBlZXIgcHJvdG9jb2wNCiAgICAgU0lQICYgRGF0YQ0KICAgICAgDQogICAgIA0KICAgICAgVHJh bnNwb3J0IHByb3RvY29sDQogICAgIFRyYW5zcG9ydCBwcm90b2NvbA0KICAgICBUcmFuc3BvcnQg cHJvdG9jb2wNCiAgICAgSElQDQogICAgIA0KICAgICAgRVNQDQogICAgIEVTUA0KICAgICBFU1AN CiAgICAgRVNQDQogICAgIA0KICAgICAgVURQDQogICAgIFVEUA0KICAgICBVRFANCiAgICAgVURQ DQogICAgIA0KICAgICAgSVANCiAgICAgSVANCiAgICAgSVANCiAgICAgSVANCiAgICAgDQoNCmEp SW5pdGlhbCBISVAgQmFzZSBFeGNoYW5nZSAgYikgUGVlciBQcm90b2NvbCAgYykgU0lQIHNpZ25h bGluZyBhbmQgZGF0YSAgZCkgU3Vic2VxdWVudCBISVAgcGFja2V0cw0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgDQoNCiANCg0KU28sIHRoZXJlIGFyZSBzb21lIGJhc2ljIGNvbmNlcHRz IHRoYXQgbXVzdCBiZSBtYWRlIGNsZWFyLg0KDQoNCg0KMS4gd2hhdCBpcyBQMlAgbGF5ZXIuIElz IGl0IGEgb3ZlcmxheSBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgb2YgSW50ZXJuZXQgb3IgaXMg aXQgaW5jbHVkaW5nIHNldmVyYWwgbGF5ZXJzIGkuZS4sIG5ldHdvcmssIHRyYW5zcG9ydCBhbmQg YXBwbGljYXRpb24gbGF5ZXJzLg0KDQogDQoNCjIuIEluIGRyYWZ0LWhhdXRha29ycGktcDJwc2lw LXdpdGgtaGlwLTAxLnR4dCwgDQoNCiJQZWVycyBpbiBhIFAyUFNJUCBuZXR3b3JrIG5lZWQgdG8g aGF2ZSBsb25nLWxpdmVkIGNvbm5lY3Rpb25zIHRvIG90aGVyIHBlZXJzIGluIHRoZSBuZXR3b3Jr LCBhbmQgSElQIGNhbiBiZSB1dGlsaXplZCB0byBzZXR1cCBhbmQgbWFpbnRhaW4gdGhvc2UgY29u bmVjdGlvbnMuIiANCg0KV2h5IHRoZSBISVAgcHJvdG9jb2wgaXMgcHV0IG92ZXIgUGVlciBwcm90 b2NvbD8NCg0KIA0KDQozLiBJbiAiZHJhZnQtbWF0dGhld3MtcDJwc2lwLWhpcC1ob3AtMDAiLA0K DQoiV2UgZGlzY3VzcyB0aGUgZnVuY3Rpb25zIG9mIHRoZSBQMlAgbGF5ZXIgaW4gc3VjaCBhbiBh cmNoaXRlY3R1cmUsIGFuZCBmb2N1cyBpbiBvbiB0aGUgRGlzdHJpYnV0ZWQgVHJhbnNwb3J0IGZ1 bmN0aW9uIC0gdGhlIGZ1bmN0aW9uIHRoYXQgYWxsb3dzIGEgcGVlciB0byBleGNoYW5nZSBtZXNz YWdlcyB3aXRoIGFueSBvdGhlciBwZWVyIGluIHRoZSBvdmVybGF5LCBldmVuIGluIHRoZSBwcmVz ZW5jZSBvZiBOQVRzLiINCg0KIldlIGRpc2N1c3MgaG93IGEgY29tcGxldGUgUDJQU0lQIGFyY2hp dGVjdHVyZSBjYW4gYmUgYnVpbHQgYXJvdW5kIEhJUCwgYW5kIGNvbnRyYXN0IHRoaXMgYXBwcm9h Y2ggd2l0aCBvdGhlciBhcHByb2FjaGVzIGZvciBpbXBsZW1lbnRpbmcgYSBQMlAgbGF5ZXIuIg0K DQpQbGVhc2UgY2xhcmlmeSB3aGljaCBmaWd1cmUgaXMgdGhlIFAyUCBsYXllciBldmVuIHRob3Vn aCBJIGNvdWxkIGluZmVyIHRoYXQgdGhlIFAyUCBsYXllciBpbmNsdWRlcyBzZXZlcmFsIGxheWVy cyBpbiB0aGUgY29udGV4dC4gDQoNCiANCg0KNC4gSW4gImRyYWZ0LW1hdHRoZXdzLXAycHNpcC1o aXAtaG9wLTAwIiwNCg0KIkhvc3QgSWRlbnRpdGllcyBjb3VsZCBiZSBhc3NpZ25lZCB0byBwZWVy cyBpbiBhdCBsZWFzdCB0d28gZGlmZmVyZW50IHdheXMuIE9uZSB3YXkgaXMgZm9yIHBlZXJzIHRv IGdlbmVyYXRlIHRoZWlyIG93biBwdWJsaWMvcHJpdmF0ZSBrZXkgcGFpcnMuIEFub3RoZXIgd2F5 IGlzIHRvIGFsbG9jYXRlIHRoZW0gdG8gcGVlcnMsIHBlcmhhcHMgaW4gICAgY29uanVuY3Rpb24g d2l0aCBhIHNldCBvZiBjcmVkZW50aWFscywgdXNpbmcgYSBjZW50cmFsaXplZCBhbGxvY2F0aW9u IHN5c3RlbS4iDQoNCldoYXQgaXMgSG9zdCBJZGVudGl0aWVzIG9yIGlkZW50aWZpZXI/IFdoYXQg aXMgUGVlciBJZGVudGlmaWVyPw0KDQpBcmUgdGhvc2UgaWRlbnRpZmllcnMgYXQgdGhlIHNhbWUg bGF5ZXIgb3Igbm90PyANCg0KDQoNCg0KTG9va2luZyBmb3J3YXJkIHRoZSByZXBseS4NCg0KUmVn YXJkcywgDQoNCkdlbmd5dQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTog IldlaSBHZW5neXUiIDx3ZWlnZW5neXVAdmlwLnNpbmEuY29tPg0KVG86ICJQMlBTSVAgTWFpbGlu ZyBMaXN0IiA8cDJwc2lwQGlldGYub3JnPg0KU2VudDogU2F0dXJkYXksIE5vdmVtYmVyIDI0LCAy MDA3IDU6MDAgUE0NClN1YmplY3Q6IFtQMlBTSVBdIFAyUCBsYXllciBhbmQgUGVlciBJZGVudGlm aWVyDQoNCg0KPiBIaSwgYWxsLA0KPiANCj4gSSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgUDJQIGxh eWVyIGFuZCBQZWVyIElkZW50aWZpZXI/DQo+IA0KPiBXaGVuIHNheWluZyBQMlAgbGF5ZXIsIGFy ZSB0aGUgZW50aXRpZXMgYXQgdGhlIGxheWVyIGlkZW50aWZpZWQgYnkgUGVlciBJZGVudGlmaWVy cz8NCj4gVGhlIFBlZXIgSWRlbnRpZmllciBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBlbnRpdHkg YXQgYXBwbGljYXRpb24gbGF5ZXIgb2YgSW50ZXJuZXQuDQo+IEl0IHNlZW1zIHRoYXQgdGhlIFBl ZXIgSWRlbnRpZmllciBpcyBnZW5lcmF0ZWQgYnkgREhULg0KPiBJcyB0aGVyZSBhbm90aGVyICBm b3JtYXQgb2YgUGVlciBJZGVudGlmaWVyIHdoaWNoIGlzIHJlYWRhYmxlLCBzb21ldGhpbmcgbGlr ZSBVUkk/DQo+IA0KPiBBbmQgdGhlIFBlZXIgSWRlbnRpZmllciBzaG91bGQgbm90IGJlIHRoZSBz YW1lIGFzIHRoZSBIb3N0IElkZW50aWZpZXIgb3IgTm9kZSBJZGVudGlmaWVyIGluIHRoZSBJbnRl cm5ldC4NCj4gVGhlIFAyUCBsYXllciBwcm92aWRlcyBhIHNlcnZpY2UgbWFwcGluZyB0aGUgUGVl ciBJZGVudGlmaWVyIHRvIEhvc3QgSWRlbnRpZmllciBhc3NvY2lhdGVkIHdpdGggYSBJUCBhZGRy ZXNzIG9yIGFkZHJlc3Nlcy4gDQo+IA0KPiBTbywgUGVlciBJZGVudGlmaWVyIGlzIG5vdCBhIEhv c3QgSWRlbnRpZmllciBvciBJUCBhZGRyZXNzLg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIGJlIGVk dWNhdGVkLg0KPiBJdCB3aWxsIGJlIGhlbHBmdWwgZm9yIG1lIHRvIHVuZGVyc3RhbmQgSElQLg0K PiANCj4gQmVzdCByZWdhcmRzLCANCj4gDQo+IEdlbmd5dQ0KPiANCj4gLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLSANCj4gRnJvbTogImxpY2h1biBsaSIgPGxpbGljaHVuQGdtYWlsLmNvbT4N Cj4gVG86ICJaaGVuZyBIZXdlbiIgPGh3emhlbmdAaHVhd2VpLmNvbT4NCj4gQ2M6ICJQMlBTSVAg TWFpbGluZyBMaXN0IiA8cDJwc2lwQGlldGYub3JnPg0KPiBTZW50OiBTYXR1cmRheSwgTm92ZW1i ZXIgMjQsIDIwMDcgMTI6NDIgUE0NCj4gU3ViamVjdDogUmU6IFtQMlBTSVBdIE5ldyBJLUQ6IGRp ZmZlcmVudCB0eXBlcyBvZiBub2RlcyBpbiBQMlBTSVAgKHdhczpUb3Rob3NlIGludGVyZXN0ZWQg aW4gUDJQU0lQIGNsaWVudHMpDQo+IA0KPiANCj4+SSBhbHNvIHRoaW5rIHRoZSBQMlAgbGF5ZXIg c2hvdWxkIGJlIGRpc3RpbmN0IGZyb20gdGhlIFNJUCBsYXllci4NCj4+IA0KPj4gT24gTm92IDI0 LCAyMDA3IDEwOjU4IEFNLCBaaGVuZyBIZXdlbiA8aHd6aGVuZ0BodWF3ZWkuY29tPiB3cm90ZToN Cj4+PiBIaSwNCj4+Pg0KPj4+ICAgIFBsZWFzZSBzZWUgaW5saW5lLg0KPj4+DQo+Pj4gQmVzdCBy ZWdhcmRzLA0KPj4+IEhld2VuDQo+Pj4NCj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IFAyUFNJUCBtYWlsaW5nIGxpc3QNCj4+IFAyUFNJ UEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcDJw c2lwDQo+Pg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBQMlBTSVAgbWFpbGluZyBsaXN0 DQo+IFAyUFNJUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9wMnBzaXANCj4= --===============1355685416== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1355685416==-- From p2psip-bounces@ietf.org Tue Nov 27 04:06:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwOm-0005vK-BX; Tue, 27 Nov 2007 04:06:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwwOk-0005gz-9H for p2psip@ietf.org; Tue, 27 Nov 2007 04:06:30 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwwOj-0000Fm-Ae for p2psip@ietf.org; Tue, 27 Nov 2007 04:06:30 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 44B5B21588; Tue, 27 Nov 2007 10:01:09 +0100 (CET) X-AuditID: c1b4fb3e-ae69ebb00000459d-ff-474bdcd58622 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2072721572; Tue, 27 Nov 2007 10:01:09 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 10:01:08 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 10:01:08 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 38B822750; Tue, 27 Nov 2007 11:01:08 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A63364DC3B; Tue, 27 Nov 2007 11:01:05 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 38A934DC2F; Tue, 27 Nov 2007 11:01:05 +0200 (EET) Message-ID: <474BDD3E.7010906@ericsson.com> Date: Tue, 27 Nov 2007 11:02:54 +0200 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: "David A. Bryan" Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> In-Reply-To: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 27 Nov 2007 09:01:08.0411 (UTC) FILETIME=[0CAFD8B0:01C830D4] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: P2PSIP Mailing List , Philip Matthews X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi David and others, I would like to suggest a small change to the agenda. Could the "HIPHOP" and "with HIP" be moved from "Peer Protocol Proposal Discussions" to "Open Questions Discussion". The reasoning being that they are not really peer protocol proposals. The title of the presentation could be "Should HIP be used for managing connections between peers?". Quite often the "with-hip" draft is mistakenly seen as a peer protocol proposal, but in fact it describes how HIP can be used *with* other peer protocols (e.g., RELOAD and P2PP). -- Jani David A. Bryan wrote: > Please find the newest version of the agenda below. > > A few comments. To minimize slide changing time we are going to insist > (no exceptions) that slides be sent to the chairs in no later than 5pm > Tuesday night so we can have them all ready to go. > > We are taking the approach of leading discussion on 5 topics that have > generated list traffic. We have allocated :15 minutes for each. Each > person listed as a leader should make slides and discuss them on list > prior to the meeting, with an eye toward the discussion being able to > reach some real consensus on that issue. If people don't get something > out prior to Vancouver, we may find a different leader. Please check > to see if you are a proposed leader. If you are and don't want to be, > let us know and we'll find someone else. > > We've left time at the end for specific protocol discussions, but if > we run overtime, these will get bumped. For the existing ones, the > focus should be on what is new. For the new protocols (those submitted > this cycle) the talk must be on why you made a new protocol (What is > unique about it/benefits over the earlier proposals) > > Thanks, > > David (and Brian) (as chairs) > > Agenda: > > P2PSIP Agenda > > Wednesday, 5 December, 2007, 1300-1500 in Salon D/E > > Chairs: > David Bryan > Brian Rosen > > Agenda Bash/Administrivia (Chairs) :10 > > Open Questions Discussion :15 minutes per topic > > The purpose of this section is to discuss, in detail, a few of the > topics that have been being discussed most extensively on the mailing > list and that the group appears to have to address to move forward on > a serious protocol draft. Goals here are grand and lofty and we may > have to settle for less... > > The proposed leader *must* discuss this (and share slide text in > advance of the meeting) on-list to build up a good discussion on the > topic. > > Topic: "Routing: What does it look like?" > Leader: Spencer Dawkins > Goal: How many routing techniques do we need, and can we pick a set? > Discuss/compare different routing techniques (iterative, recursive, > semi-recursive, as well as symmetric vs. asymmetric). Can we decide > on a set for the protocol to implement? > > Topic: "NAT Traversal for P2P Messages" > Leader: Philip Matthews > Goal: Decide on what a NAT traversal mechanism will look like. > How do we implement NAT traversal for P2P messages? How do we locate > STUN servers (if we use them) > > Topic: "Do we need clients (other than SIP)?" > Leader: Marcin Matuszewski > Goal: Present a set of use cases for why clients are needed, get > consensus or if we need them > > Topic: "PeerID assignment and Chosen Location Attacks" > Leader: Eric Rescorla > Goal: Understand the implications of PeerID assignment on security > Take a look at how PeerIDs can be selected, and how this affects > chosen location attacks. Discuss different approaches offered for > ID assignment. > > Topic: "Replication" > Leader: Bruce Lowekamp > Goal: Understand the problems inherent in replication. > Compare mechanisms for replication (root replicates, source > replicates, other) and discuss how we might select. More > importantly, *where* in the protocol (DHT level, application > level) should this happen? > > Concepts Document (TBD) :10 > Open questions on the concepts draft. Hopefully, some clarification > to some questions will come from the above discussions. > > (Very unlikely to actually get time...) > > Peer Protocol Proposal Discussions (authors) :05 per proposal (:10 for > merged proposals so as not to penalize merging. Time permitting) > > Time limit will be *very* strictly enforced > > For existing proposals, topic must be about what has changed since > the last version. For new proposals, topic must be what is new about > this draft? Why a new draft instead of a tweak to one of the existing > proposals? > > * RELOAD (merged with ASP, :10) > * P2PP > * HIPHOP > * XPP > * with HIP > * SEP/Client Protocol > * P2PNS > > Reading: > > Because this agenda revolves around the questions, rather than specific > drafts being proposed, a specific reading list is not possible. See > www.p2psip.org/ietf.php for a list of current drafts, and revisit the > mailing list for recent discussion on these items. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 07:40:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwzjZ-0003Jw-TJ; Tue, 27 Nov 2007 07:40:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwzjX-0003JV-T5 for p2psip@ietf.org; Tue, 27 Nov 2007 07:40:11 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwzjX-0005gL-2y for p2psip@ietf.org; Tue, 27 Nov 2007 07:40:11 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Iwziz-0006Te-03; Tue, 27 Nov 2007 07:39:37 -0500 In-Reply-To: <474BDD3E.7010906@ericsson.com> References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <474BDD3E.7010906@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36CBC3F6-EF56-4897-B6D6-430DC7BB9F89@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver Date: Tue, 27 Nov 2007 07:40:06 -0500 To: "David A. Bryan" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org This might be a useful change, and potentially more valuable than 5 minutes on each proposal. However, I feel compelled to point out one point: Jani feels strongly that P2PSIP needs to adopt HIP as-is, while I am now of the opinion that P2PSIP may instead wish to look individually at the features of HIP and consider which are worth adopting. So if I was asked to lead such a discussion, I would talk about the various features of HIP individually and compare them with their alternatives. Never-the-less, I do think this would be a valuable discussion. (Of course, there are lots of valuable discussions in P2PSIP ...) - Philip On 27-Nov-07, at 04:02 , Jani Hautakorpi (JO/LMF) wrote: > Hi David and others, > > I would like to suggest a small change to the agenda. Could the > "HIPHOP" and "with HIP" be moved from "Peer Protocol Proposal > Discussions" to "Open Questions Discussion". The reasoning being > that they are not really peer protocol proposals. The title of the > presentation could be "Should HIP be used for managing connections > between peers?". > > Quite often the "with-hip" draft is mistakenly seen as a peer > protocol proposal, but in fact it describes how HIP can be used > *with* other peer protocols (e.g., RELOAD and P2PP). > > > -- > Jani > > David A. Bryan wrote: >> Please find the newest version of the agenda below. >> A few comments. To minimize slide changing time we are going to >> insist >> (no exceptions) that slides be sent to the chairs in no later than >> 5pm >> Tuesday night so we can have them all ready to go. >> We are taking the approach of leading discussion on 5 topics that >> have >> generated list traffic. We have allocated :15 minutes for each. Each >> person listed as a leader should make slides and discuss them on list >> prior to the meeting, with an eye toward the discussion being able to >> reach some real consensus on that issue. If people don't get >> something >> out prior to Vancouver, we may find a different leader. Please check >> to see if you are a proposed leader. If you are and don't want to be, >> let us know and we'll find someone else. >> We've left time at the end for specific protocol discussions, but if >> we run overtime, these will get bumped. For the existing ones, the >> focus should be on what is new. For the new protocols (those >> submitted >> this cycle) the talk must be on why you made a new protocol (What is >> unique about it/benefits over the earlier proposals) >> Thanks, >> David (and Brian) (as chairs) >> Agenda: >> P2PSIP Agenda >> Wednesday, 5 December, 2007, 1300-1500 in Salon D/E >> Chairs: >> David Bryan >> Brian Rosen >> Agenda Bash/Administrivia (Chairs) :10 >> Open Questions Discussion :15 minutes per topic >> The purpose of this section is to discuss, in detail, a few of the >> topics that have been being discussed most extensively on the >> mailing >> list and that the group appears to have to address to move >> forward on >> a serious protocol draft. Goals here are grand and lofty and we may >> have to settle for less... >> The proposed leader *must* discuss this (and share slide text in >> advance of the meeting) on-list to build up a good discussion on >> the >> topic. >> Topic: "Routing: What does it look like?" >> Leader: Spencer Dawkins >> Goal: How many routing techniques do we need, and can we pick a >> set? >> Discuss/compare different routing techniques (iterative, >> recursive, >> semi-recursive, as well as symmetric vs. asymmetric). Can we >> decide >> on a set for the protocol to implement? >> Topic: "NAT Traversal for P2P Messages" >> Leader: Philip Matthews >> Goal: Decide on what a NAT traversal mechanism will look like. >> How do we implement NAT traversal for P2P messages? How do we >> locate >> STUN servers (if we use them) >> Topic: "Do we need clients (other than SIP)?" >> Leader: Marcin Matuszewski >> Goal: Present a set of use cases for why clients are needed, get >> consensus or if we need them >> Topic: "PeerID assignment and Chosen Location Attacks" >> Leader: Eric Rescorla >> Goal: Understand the implications of PeerID assignment on security >> Take a look at how PeerIDs can be selected, and how this affects >> chosen location attacks. Discuss different approaches offered for >> ID assignment. >> Topic: "Replication" >> Leader: Bruce Lowekamp >> Goal: Understand the problems inherent in replication. >> Compare mechanisms for replication (root replicates, source >> replicates, other) and discuss how we might select. More >> importantly, *where* in the protocol (DHT level, application >> level) should this happen? >> Concepts Document (TBD) :10 >> Open questions on the concepts draft. Hopefully, some clarification >> to some questions will come from the above discussions. >> (Very unlikely to actually get time...) >> Peer Protocol Proposal Discussions (authors) :05 per proposal (:10 >> for >> merged proposals so as not to penalize merging. Time permitting) >> Time limit will be *very* strictly enforced >> For existing proposals, topic must be about what has changed since >> the last version. For new proposals, topic must be what is new >> about >> this draft? Why a new draft instead of a tweak to one of the >> existing >> proposals? >> * RELOAD (merged with ASP, :10) >> * P2PP >> * HIPHOP >> * XPP >> * with HIP >> * SEP/Client Protocol >> * P2PNS >> Reading: >> Because this agenda revolves around the questions, rather than >> specific >> drafts being proposed, a specific reading list is not possible. See >> www.p2psip.org/ietf.php for a list of current drafts, and revisit the >> mailing list for recent discussion on these items. > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 08:30:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0WY-0001Hj-FX; Tue, 27 Nov 2007 08:30:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0WX-0001HR-4Y for p2psip@ietf.org; Tue, 27 Nov 2007 08:30:49 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-09.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix0WV-0001bk-I1 for p2psip@ietf.org; Tue, 27 Nov 2007 08:30:49 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Ix0WV-0005Tx-0W; Tue, 27 Nov 2007 08:30:47 -0500 In-Reply-To: <004801c830ca$e350ceb0$da07740a@dellwei> References: <7d6b50690711231825s501cec95off34d66b891e476d@mail.gmail.com><000001c82e45$eae81ac0$5105a40a@china.huawei.com><7d6b50690711232042i2f4bfe9au65c0b5b38a8e40b5@mail.gmail.com> <008c01c82e78$86e818d0$da07740a@dellwei> <004801c830ca$e350ceb0$da07740a@dellwei> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D156A6A-97AC-4321-9982-3178DF70C36D@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] P2P layer and Peer Identifier Date: Tue, 27 Nov 2007 08:30:42 -0500 To: Wei Gengyu X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 27-Nov-07, at 02:55 , Wei Gengyu wrote: > > So, there are some basic concepts that must be made clear. > > > > 1. what is P2P layer. Is it a overlay at the application layer of > Internet or is it including several layers i.e., network, transport > and application layers. In draft-matthews-p2psip-hip-hop-00, the P2P layer was introduced to split this functionality from the SIP layer. At the time that draft was written, people were still arguing for a combined SIP + P2P layer. Since then, however, the WG has agreed that there will be at least two different layers. > > > > 2. In draft-hautakorpi-p2psip-with-hip-01.txt, > > "Peers in a P2PSIP network need to have long-lived connections to > other peers in the network, and HIP can be utilized to setup and > maintain those connections." > > Why the HIP protocol is put over Peer protocol? HIP comes with its own signaling protocol. So the question is: what is the relationship between that protocol and the peer protocol. I can see four answers: 1) The Peer Protocol runs over HIP signaling. This was the approach taken in draft-matthews-p2psip-hip-hop. This approach probably requires extensions to HIP, and a number of such extensions are proposed in that draft. 2) HIP signaling runs over the Peer Protocol. This is the approach taken in draft-hautakorpi-p2psip-with-hip. By doing this, fewer extensions to HIP are required (perhaps none). 3) Features of HIP signaling are integrated into the Peer Protocol. This is the approach that I currently think is the most promising. draft-matthews-p2psip-id-loc hints at this approach, without any real details. 4) Features of the Peer Protocol are integrated into HIP. So far, no one is proposing this approach. > > > > 3. In "draft-matthews-p2psip-hip-hop-00", > > "We discuss the functions of the P2P layer in such an architecture, > and focus in on the Distributed Transport function - the function > that allows a peer to exchange messages with any other peer in the > overlay, even in the presence of NATs." > > "We discuss how a complete P2PSIP architecture can be built around > HIP, and contrast this approach with other approaches for > implementing a P2P layer." > > Please clarify which figure is the P2P layer even though I could > infer that the P2P layer includes several layers in the context. Yes. In draft-matthews-p2psip-hip-hop-00, the term "P2P layer" meant the combination of three protocols: Peer Protocol, HIP, and whatever transport protocol the application was using. > > > 4. In "draft-matthews-p2psip-hip-hop-00", > > "Host Identities could be assigned to peers in at least two > different ways. One way is for peers to generate their own public/ > private key pairs. Another way is to allocate them to peers, > perhaps in conjunction with a set of credentials, using a > centralized allocation system." > > What is Host Identities or identifier? What is Peer Identifier? A Host Identity is a concept from HIP. It is a unique identifier for a host in the Internet, and doesn't change even if the host changes its IP address(es). A Peer Identifier is a concept from P2PSIP. It is a unique identifier for a peer in a specific overlay, It presumably also doesn't change if the peer changes its IP address(es). One of the motivators behind trying to figure out the relationship between HIP and P2PSIP is that these two concepts seem very similar. draft-matthews-p2psip-hip-hop proposed that the two concepts should be the same. However, there is now a debate on whether this would make overlays more vulnerable to the "Chosen Location" attack. Though I still wonder if this is really true, never-the-less I am starting to think that the two concepts are distinct (but related). - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 08:36:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0bX-0006rg-5q; Tue, 27 Nov 2007 08:35:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix0bW-0006rY-KN for p2psip@ietf.org; Tue, 27 Nov 2007 08:35:58 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix0bV-00051O-MU for p2psip@ietf.org; Tue, 27 Nov 2007 08:35:58 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 14EF22060B; Tue, 27 Nov 2007 14:35:57 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-99-474c1d3c7189 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E4FD1205F6; Tue, 27 Nov 2007 14:35:56 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 14:35:56 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 14:35:56 +0100 Received: from [131.160.126.130] (rvi2-126-130.lmf.ericsson.se [131.160.126.130]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CF4D32460; Tue, 27 Nov 2007 15:35:55 +0200 (EET) Message-ID: <474C1D3B.1020200@ericsson.com> Date: Tue, 27 Nov 2007 15:35:55 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <474BDD3E.7010906@ericsson.com> <36CBC3F6-EF56-4897-B6D6-430DC7BB9F89@magma.ca> In-Reply-To: <36CBC3F6-EF56-4897-B6D6-430DC7BB9F89@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2007 13:35:56.0401 (UTC) FILETIME=[704B7610:01C830FA] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Philip, a clarification: are you thinking of modifying HIP to suit our (P2PSIP) needs (there is ongoing to work to specify a HIP message to carry payloads such as signalling messages and to allow HIP to negotiate other security mechanisms other than ESP), or to re-implement those parts of HIP P2PSIP needs using a different protocol? Thanks, Gonzalo Philip Matthews wrote: > This might be a useful change, and potentially more valuable than 5 > minutes on each proposal. > > However, I feel compelled to point out one point: Jani feels strongly > that P2PSIP needs to adopt HIP as-is, while I am now of the opinion that > P2PSIP may instead wish to look individually at the features of HIP and > consider which are worth adopting. So if I was asked to lead such a > discussion, I would talk about the various features of HIP individually > and compare them with their alternatives. > > Never-the-less, I do think this would be a valuable discussion. (Of > course, there are lots of valuable discussions in P2PSIP ...) > > - Philip > > > On 27-Nov-07, at 04:02 , Jani Hautakorpi (JO/LMF) wrote: > >> Hi David and others, >> >> I would like to suggest a small change to the agenda. Could the >> "HIPHOP" and "with HIP" be moved from "Peer Protocol Proposal >> Discussions" to "Open Questions Discussion". The reasoning being that >> they are not really peer protocol proposals. The title of the >> presentation could be "Should HIP be used for managing connections >> between peers?". >> >> Quite often the "with-hip" draft is mistakenly seen as a peer protocol >> proposal, but in fact it describes how HIP can be used *with* other >> peer protocols (e.g., RELOAD and P2PP). >> >> >> -- >> Jani >> >> David A. Bryan wrote: >>> Please find the newest version of the agenda below. >>> A few comments. To minimize slide changing time we are going to insist >>> (no exceptions) that slides be sent to the chairs in no later than 5pm >>> Tuesday night so we can have them all ready to go. >>> We are taking the approach of leading discussion on 5 topics that have >>> generated list traffic. We have allocated :15 minutes for each. Each >>> person listed as a leader should make slides and discuss them on list >>> prior to the meeting, with an eye toward the discussion being able to >>> reach some real consensus on that issue. If people don't get something >>> out prior to Vancouver, we may find a different leader. Please check >>> to see if you are a proposed leader. If you are and don't want to be, >>> let us know and we'll find someone else. >>> We've left time at the end for specific protocol discussions, but if >>> we run overtime, these will get bumped. For the existing ones, the >>> focus should be on what is new. For the new protocols (those submitted >>> this cycle) the talk must be on why you made a new protocol (What is >>> unique about it/benefits over the earlier proposals) >>> Thanks, >>> David (and Brian) (as chairs) >>> Agenda: >>> P2PSIP Agenda >>> Wednesday, 5 December, 2007, 1300-1500 in Salon D/E >>> Chairs: >>> David Bryan >>> Brian Rosen >>> Agenda Bash/Administrivia (Chairs) :10 >>> Open Questions Discussion :15 minutes per topic >>> The purpose of this section is to discuss, in detail, a few of the >>> topics that have been being discussed most extensively on the mailing >>> list and that the group appears to have to address to move forward on >>> a serious protocol draft. Goals here are grand and lofty and we may >>> have to settle for less... >>> The proposed leader *must* discuss this (and share slide text in >>> advance of the meeting) on-list to build up a good discussion on the >>> topic. >>> Topic: "Routing: What does it look like?" >>> Leader: Spencer Dawkins >>> Goal: How many routing techniques do we need, and can we pick a set? >>> Discuss/compare different routing techniques (iterative, recursive, >>> semi-recursive, as well as symmetric vs. asymmetric). Can we decide >>> on a set for the protocol to implement? >>> Topic: "NAT Traversal for P2P Messages" >>> Leader: Philip Matthews >>> Goal: Decide on what a NAT traversal mechanism will look like. >>> How do we implement NAT traversal for P2P messages? How do we locate >>> STUN servers (if we use them) >>> Topic: "Do we need clients (other than SIP)?" >>> Leader: Marcin Matuszewski >>> Goal: Present a set of use cases for why clients are needed, get >>> consensus or if we need them >>> Topic: "PeerID assignment and Chosen Location Attacks" >>> Leader: Eric Rescorla >>> Goal: Understand the implications of PeerID assignment on security >>> Take a look at how PeerIDs can be selected, and how this affects >>> chosen location attacks. Discuss different approaches offered for >>> ID assignment. >>> Topic: "Replication" >>> Leader: Bruce Lowekamp >>> Goal: Understand the problems inherent in replication. >>> Compare mechanisms for replication (root replicates, source >>> replicates, other) and discuss how we might select. More >>> importantly, *where* in the protocol (DHT level, application >>> level) should this happen? >>> Concepts Document (TBD) :10 >>> Open questions on the concepts draft. Hopefully, some clarification >>> to some questions will come from the above discussions. >>> (Very unlikely to actually get time...) >>> Peer Protocol Proposal Discussions (authors) :05 per proposal (:10 for >>> merged proposals so as not to penalize merging. Time permitting) >>> Time limit will be *very* strictly enforced >>> For existing proposals, topic must be about what has changed since >>> the last version. For new proposals, topic must be what is new about >>> this draft? Why a new draft instead of a tweak to one of the existing >>> proposals? >>> * RELOAD (merged with ASP, :10) >>> * P2PP >>> * HIPHOP >>> * XPP >>> * with HIP >>> * SEP/Client Protocol >>> * P2PNS >>> Reading: >>> Because this agenda revolves around the questions, rather than specific >>> drafts being proposed, a specific reading list is not possible. See >>> www.p2psip.org/ietf.php for a list of current drafts, and revisit the >>> mailing list for recent discussion on these items. >> > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 09:23:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1LD-0000VV-Hv; Tue, 27 Nov 2007 09:23:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1LC-0000Ua-HE for p2psip@ietf.org; Tue, 27 Nov 2007 09:23:10 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-01.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix1LC-0002Kq-50 for p2psip@ietf.org; Tue, 27 Nov 2007 09:23:10 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-01.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Ix1LB-0001Nm-2K; Tue, 27 Nov 2007 09:23:09 -0500 In-Reply-To: <008201c82b60$012054d0$6905a40a@china.huawei.com> References: <008201c82b60$012054d0$6905a40a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E33467E-406A-4D50-A2A4-ED53BD3425FE@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Routing mode in P2PSIP Date: Tue, 27 Nov 2007 09:23:07 -0500 To: JiangXingFeng X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org I would like to point out that are two related topics here: 1) Sending a message to a specific peer in the overlay, AND 2) Searching for a peer with a given property. In the former case, you have a message (say a RELOAD OPEN message) that you wish to send to a specific peer, and you know the peer id of the destination. In the latter case, you are searching for a peer that, for example, holds a particular resource record; in this case, you don't know the peer id of the destination peer. The idea that XingFeng is suggesting (of using a peer with a public IP address as a relay) was also suggested by Jani Hautakorpi in draft- hautakorpi-p2psip-with-hip-00. This idea applies to case (1), but is not appropriate for case (2). I see this idea working as follows. Say a peer Z discovers, while setting up connections to other peers in the overlay, that its ICE host candidate H is the candidate selected in every case. This may or may not mean that H is a public IP address, but it does indicate that many other peers can reach Z using H. Thus Z, which has a user "Wilma", can insert the following resource record for Wilma into the overlay: contact:Wilma@Z; contact address:Wilma@H This "Contact address" field specifies an address at which Z can likely be reached. This indicates that Z can likely be reached by sending a message directly to H. Now say peer Z has a connection to peer Y, and the connection to peer Y uses a server-reflexive candidate for Y (in other words, Y is behind a NAT relative to Z). Then Z can say to Y: "I am willing to act as a relay for you". Thus Y, which has a user "Fred" can insert the following into the resource record for Fred: contact:Fred@Y; contact address:Fred@H Here the contact address for Y is actually the address for Z, which will relay messages onwards to Y. Peer X, upon retrieving a resource record with a contact address, and wanting to send a message, can do one of two things: a) It sends the message to H, and waits for a short while. If no response is received, it sends the message hop-by-hop through the overlay. b) It simultaneously sends the message directly to H, and hop-by-hop around the overlay. Which one of (a) or (b) the peer X does can be a matter of local policy. - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 09:56:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1re-0005R7-Bx; Tue, 27 Nov 2007 09:56:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1rd-0005Qt-7p for p2psip@ietf.org; Tue, 27 Nov 2007 09:56:41 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-05.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix1rb-0007ya-0q for p2psip@ietf.org; Tue, 27 Nov 2007 09:56:41 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-05.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Ix1r3-0004cp-0l; Tue, 27 Nov 2007 09:56:05 -0500 In-Reply-To: <474C1D3B.1020200@ericsson.com> References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <474BDD3E.7010906@ericsson.com> <36CBC3F6-EF56-4897-B6D6-430DC7BB9F89@magma.ca> <474C1D3B.1020200@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <101CDD2D-6F23-45D3-A9E0-BF526CEA203E@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver Date: Tue, 27 Nov 2007 09:56:32 -0500 To: Gonzalo Camarillo X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 27-Nov-07, at 08:35 , Gonzalo Camarillo wrote: > Hi Philip, > > a clarification: are you thinking of modifying HIP to suit our > (P2PSIP) needs (there is ongoing to work to specify a HIP message > to carry payloads such as signalling messages and to allow HIP to > negotiate other security mechanisms other than ESP), or to re- > implement those parts of HIP P2PSIP needs using a different protocol? > This is a good question. As you know, there has been quite a bit of discussion in the past few months over the best way to interface HIP signaling with the Peer Protocol. We have investigated (a) putting HIP below the Peer Protocol (HIP-HOP), and (b) carrying HIP signaling messages in the body of Peer Protocol messages (WITH-HIP-01). Personally, I am not completely happy with either approach right now, so I am currently leaning towards approach (c): integrating aspects of HIP signaling into the Peer Protocol. Part of the issue concerns what aspects of HIP we want for P2PSIP. The aspects in question are: 1) The concept of the id/locator split 2) The concept of encrypting messages using ESP (vs. TLS/DTLS) 3) The concept of protecting against denial of service attacks using puzzles I don't think the group has thought a lot about these questions (particularly, the DoS attack question), so a discussion would be good. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 10:19:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2Dd-0000R3-7R; Tue, 27 Nov 2007 10:19:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2Dc-0000O8-IX for p2psip@ietf.org; Tue, 27 Nov 2007 10:19:24 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix2Db-0006OQ-DT for p2psip@ietf.org; Tue, 27 Nov 2007 10:19:24 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9648F20645; Tue, 27 Nov 2007 16:19:22 +0100 (CET) X-AuditID: c1b4fb3c-aef95bb0000030cf-98-474c357ad1bd Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6C6462005D; Tue, 27 Nov 2007 16:19:22 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 16:19:22 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 16:19:22 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0375727BB; Tue, 27 Nov 2007 17:19:21 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 68AB54DC3B; Tue, 27 Nov 2007 17:19:19 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id ED2DA4DC2F; Tue, 27 Nov 2007 17:19:18 +0200 (EET) Message-ID: <474C35E3.4090407@ericsson.com> Date: Tue, 27 Nov 2007 17:21:07 +0200 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Philip Matthews Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <474BDD3E.7010906@ericsson.com> <36CBC3F6-EF56-4897-B6D6-430DC7BB9F89@magma.ca> In-Reply-To: <36CBC3F6-EF56-4897-B6D6-430DC7BB9F89@magma.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 27 Nov 2007 15:19:22.0201 (UTC) FILETIME=[E33D6490:01C83108] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Philip, Despite the differences in opinion, I still think that it would be beneficial to present how HIP (or HIP-like mechanism) could be utilized *with* existing Peer Protocol proposals. It would also give people a chance to understand that with-hip is not yet another peer protocol proposal. Furthermore, I think that the proposed "Should HIP be used for managing connections between peers?" presentation is tackling a bit of the same topics as now listed "NAT Traversal for P2P Messages" and "PeerID assignment and Chosen Location Attacks" presentations. -- Jani Philip Matthews wrote: > This might be a useful change, and potentially more valuable than 5 > minutes on each proposal. > > However, I feel compelled to point out one point: Jani feels strongly > that P2PSIP needs to adopt HIP as-is, while I am now of the opinion that > P2PSIP may instead wish to look individually at the features of HIP and > consider which are worth adopting. So if I was asked to lead such a > discussion, I would talk about the various features of HIP individually > and compare them with their alternatives. > > Never-the-less, I do think this would be a valuable discussion. (Of > course, there are lots of valuable discussions in P2PSIP ...) > > - Philip > > > On 27-Nov-07, at 04:02 , Jani Hautakorpi (JO/LMF) wrote: > >> Hi David and others, >> >> I would like to suggest a small change to the agenda. Could the >> "HIPHOP" and "with HIP" be moved from "Peer Protocol Proposal >> Discussions" to "Open Questions Discussion". The reasoning being that >> they are not really peer protocol proposals. The title of the >> presentation could be "Should HIP be used for managing connections >> between peers?". >> >> Quite often the "with-hip" draft is mistakenly seen as a peer protocol >> proposal, but in fact it describes how HIP can be used *with* other >> peer protocols (e.g., RELOAD and P2PP). >> >> >> --Jani >> >> David A. Bryan wrote: >>> Please find the newest version of the agenda below. >>> A few comments. To minimize slide changing time we are going to insist >>> (no exceptions) that slides be sent to the chairs in no later than 5pm >>> Tuesday night so we can have them all ready to go. >>> We are taking the approach of leading discussion on 5 topics that have >>> generated list traffic. We have allocated :15 minutes for each. Each >>> person listed as a leader should make slides and discuss them on list >>> prior to the meeting, with an eye toward the discussion being able to >>> reach some real consensus on that issue. If people don't get something >>> out prior to Vancouver, we may find a different leader. Please check >>> to see if you are a proposed leader. If you are and don't want to be, >>> let us know and we'll find someone else. >>> We've left time at the end for specific protocol discussions, but if >>> we run overtime, these will get bumped. For the existing ones, the >>> focus should be on what is new. For the new protocols (those submitted >>> this cycle) the talk must be on why you made a new protocol (What is >>> unique about it/benefits over the earlier proposals) >>> Thanks, >>> David (and Brian) (as chairs) >>> Agenda: >>> P2PSIP Agenda >>> Wednesday, 5 December, 2007, 1300-1500 in Salon D/E >>> Chairs: >>> David Bryan >>> Brian Rosen >>> Agenda Bash/Administrivia (Chairs) :10 >>> Open Questions Discussion :15 minutes per topic >>> The purpose of this section is to discuss, in detail, a few of the >>> topics that have been being discussed most extensively on the mailing >>> list and that the group appears to have to address to move forward on >>> a serious protocol draft. Goals here are grand and lofty and we may >>> have to settle for less... >>> The proposed leader *must* discuss this (and share slide text in >>> advance of the meeting) on-list to build up a good discussion on the >>> topic. >>> Topic: "Routing: What does it look like?" >>> Leader: Spencer Dawkins >>> Goal: How many routing techniques do we need, and can we pick a set? >>> Discuss/compare different routing techniques (iterative, recursive, >>> semi-recursive, as well as symmetric vs. asymmetric). Can we decide >>> on a set for the protocol to implement? >>> Topic: "NAT Traversal for P2P Messages" >>> Leader: Philip Matthews >>> Goal: Decide on what a NAT traversal mechanism will look like. >>> How do we implement NAT traversal for P2P messages? How do we locate >>> STUN servers (if we use them) >>> Topic: "Do we need clients (other than SIP)?" >>> Leader: Marcin Matuszewski >>> Goal: Present a set of use cases for why clients are needed, get >>> consensus or if we need them >>> Topic: "PeerID assignment and Chosen Location Attacks" >>> Leader: Eric Rescorla >>> Goal: Understand the implications of PeerID assignment on security >>> Take a look at how PeerIDs can be selected, and how this affects >>> chosen location attacks. Discuss different approaches offered for >>> ID assignment. >>> Topic: "Replication" >>> Leader: Bruce Lowekamp >>> Goal: Understand the problems inherent in replication. >>> Compare mechanisms for replication (root replicates, source >>> replicates, other) and discuss how we might select. More >>> importantly, *where* in the protocol (DHT level, application >>> level) should this happen? >>> Concepts Document (TBD) :10 >>> Open questions on the concepts draft. Hopefully, some clarification >>> to some questions will come from the above discussions. >>> (Very unlikely to actually get time...) >>> Peer Protocol Proposal Discussions (authors) :05 per proposal (:10 for >>> merged proposals so as not to penalize merging. Time permitting) >>> Time limit will be *very* strictly enforced >>> For existing proposals, topic must be about what has changed since >>> the last version. For new proposals, topic must be what is new about >>> this draft? Why a new draft instead of a tweak to one of the existing >>> proposals? >>> * RELOAD (merged with ASP, :10) >>> * P2PP >>> * HIPHOP >>> * XPP >>> * with HIP >>> * SEP/Client Protocol >>> * P2PNS >>> Reading: >>> Because this agenda revolves around the questions, rather than specific >>> drafts being proposed, a specific reading list is not possible. See >>> www.p2psip.org/ietf.php for a list of current drafts, and revisit the >>> mailing list for recent discussion on these items. >> > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 10:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2Te-0000bN-GV; Tue, 27 Nov 2007 10:35:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix2Td-0000aM-2E for p2psip@ietf.org; Tue, 27 Nov 2007 10:35:57 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-08.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix2Tb-0007SX-LR for p2psip@ietf.org; Tue, 27 Nov 2007 10:35:57 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-08.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Ix2Tb-0008IN-0w; Tue, 27 Nov 2007 10:35:55 -0500 In-Reply-To: <474C35E3.4090407@ericsson.com> References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <474BDD3E.7010906@ericsson.com> <36CBC3F6-EF56-4897-B6D6-430DC7BB9F89@magma.ca> <474C35E3.4090407@ericsson.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B590FDA-04AB-4F8E-AD1B-6DDBEB53ECE0@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver Date: Tue, 27 Nov 2007 10:35:52 -0500 To: "Jani Hautakorpi (JO/LMF)" X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On 27-Nov-07, at 10:21 , Jani Hautakorpi (JO/LMF) wrote: > Hi Philip, > > Despite the differences in opinion, I still think that it would be > beneficial to present how HIP (or HIP-like mechanism) could be > utilized *with* existing Peer Protocol proposals. It would also > give people a chance to understand that with-hip is not yet another > peer protocol proposal. I agree. I suggest the topic be renamed to something like "What should be the relationship between HIP and P2PSIP?". - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 11:27:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3H9-00020r-HW; Tue, 27 Nov 2007 11:27:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix3H8-00020h-Le for p2psip@ietf.org; Tue, 27 Nov 2007 11:27:06 -0500 Received: from mail5.primus.ca ([216.254.141.172] helo=mail-09.primus.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix3H8-0001Va-8l for p2psip@ietf.org; Tue, 27 Nov 2007 11:27:06 -0500 Received: from [216.13.42.68] (helo=[10.10.80.124]) by mail-09.primus.ca with esmtpa (Exim 4.63) (envelope-from ) id 1Ix3H6-0001HV-1k; Tue, 27 Nov 2007 11:27:04 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0399354B-38AB-4209-9E2B-48577299D1E2@magma.ca> Content-Transfer-Encoding: 7bit From: Philip Matthews Date: Tue, 27 Nov 2007 11:27:01 -0500 To: P2PSIP Mailing List X-Mailer: Apple Mail (2.752.2) X-Authenticated: philip_matthews@magma.ca - ([10.10.80.124]) [216.13.42.68] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [P2PSIP] NAT Traversal Discussion in Vancouver X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Folks: The chairs have asked me to lead a discussion of "NAT Traversal for P2P Messages". What I would like to get is a solid idea of what people would like to see discussed during this slot. As I see it, there are four parts to the whole P2PSIP NAT traversal discussion: 1) The high-level NAT Traversal approach that most people seem to be adopting is the idea of routing around the overlay to reach peers behind NATs. As I understand it, that is going to be covered in the "Routing: What does it look like?" discussion. As I see it, even the recent ideas to include Relays would fall under that discussion. [Spencer: Do you agree?] 2) The very-low-level NAT Traversal approach is ICE, and I don't see anyone questioning that. I don't think a discussion of this is worth precious meeting time. This leaves two medium-level issues: 3) Is NAT Traversal is done by each application separately, or is done once (by HIP or the Peer Protocol)? In essence, this morphs into the whole ID/Locator split idea. 4) How does a peer locate STUN and TURN servers? Both (3) and (4) would be good topics for a 15 minute discussion, but I feel that there is only time for one of these. So I would like to choose just one for the discussion. There have been drafts discussing both of these, but I think that (3) has been a hotter topic recently than (4), so my preference is to discuss (3). Comments? Is there something that I have missed? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 14:41:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6JC-0004Jy-Uz; Tue, 27 Nov 2007 14:41:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6JA-0004JW-Ok for p2psip@ietf.org; Tue, 27 Nov 2007 14:41:24 -0500 Received: from exprod6og56.obsmtp.com ([64.18.1.208]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix6JA-0001Xh-2d for p2psip@ietf.org; Tue, 27 Nov 2007 14:41:24 -0500 Received: from source ([192.150.20.142]) by exprod6ob56.postini.com ([64.18.5.12]) with SMTP; Tue, 27 Nov 2007 11:41:21 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lARJfKNT005120; Tue, 27 Nov 2007 11:41:20 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lARJfHFX007458; Tue, 27 Nov 2007 11:41:19 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 11:41:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] NAT Traversal Discussion in Vancouver Date: Tue, 27 Nov 2007 11:41:13 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE348@namail5.corp.adobe.com> In-Reply-To: <0399354B-38AB-4209-9E2B-48577299D1E2@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] NAT Traversal Discussion in Vancouver Thread-Index: AcgxEl/E6piOgAv1TkC3ShkI+mGnIwAGILqA References: <0399354B-38AB-4209-9E2B-48577299D1E2@magma.ca> From: "Henry Sinnreich" To: "Philip Matthews" , "P2PSIP Mailing List" X-OriginalArrivalTime: 27 Nov 2007 19:41:17.0371 (UTC) FILETIME=[7A3608B0:01C8312D] X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > There have been drafts discussing both of these, but I think that (3)=20 > has been a hotter topic recently There have been drafts discussing =20 > both of these, but I think that (3) has been a hotter topic recently =20 > than (4), so my preference is to discuss (3).=20 The beauty (of 3; HIP use) is in the eye of the beholder and the discussions on it may have been due to the fact that it is more controversial. Topic 4 (How does a peer locate STUN and TURN servers?) seems to me more realistic for the Internet 'as is' today and more interesting. So a counter suggestion is: - Give topic 4 preference and let's start with it, - If time permits, I would be interested to understand=20 a. How can HIP be used on existing platforms without modifying the TCP/IP stack? What are the costs and trade-offs in complexity and time to market? b. There are several _name based routing_ proposals in the works and HIP is only one of them. NUTSS is another. Is there a neutral party to inform us about this field? Just to get a comparison and to make a reasonable risk assessment on what will eventually get deployed. The reasons why HIP is championed for P2PSIP have been well articulated on this list and in the I-Ds, so it is time to take a more balanced look at all the options that may becomes available with name based routing, whenever/if this happens.=20 Henry=20 -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca]=20 Sent: Tuesday, November 27, 2007 10:27 AM To: P2PSIP Mailing List Subject: [P2PSIP] NAT Traversal Discussion in Vancouver Folks: The chairs have asked me to lead a discussion of "NAT Traversal for =20 P2P Messages". What I would like to get is a solid idea of what =20 people would like to see discussed during this slot. As I see it, there are four parts to the whole P2PSIP NAT traversal =20 discussion: 1) The high-level NAT Traversal approach that most people seem to be =20 adopting is the idea of routing around the overlay to reach peers =20 behind NATs. As I understand it, that is going to be covered in the =20 "Routing: What does it look like?" discussion. As I see it, even the =20 recent ideas to include Relays would fall under that discussion. =20 [Spencer: Do you agree?] 2) The very-low-level NAT Traversal approach is ICE, and I don't see =20 anyone questioning that. I don't think a discussion of this is worth =20 precious meeting time. This leaves two medium-level issues: 3) Is NAT Traversal is done by each application separately, or is =20 done once (by HIP or the Peer Protocol)? In essence, this morphs into =20 the whole ID/Locator split idea. 4) How does a peer locate STUN and TURN servers? Both (3) and (4) would be good topics for a 15 minute discussion, but =20 I feel that there is only time for one of these. So I would like to =20 choose just one for the discussion. There have been drafts discussing =20 both of these, but I think that (3) has been a hotter topic recently =20 than (4), so my preference is to discuss (3). Comments? Is there something that I have missed? - Philip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 14:54:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6WA-000333-Lo; Tue, 27 Nov 2007 14:54:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix6W8-0002zx-S8 for p2psip@ietf.org; Tue, 27 Nov 2007 14:54:48 -0500 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ix6W8-0005ud-EQ for p2psip@ietf.org; Tue, 27 Nov 2007 14:54:48 -0500 Received: from lappy ([98.207.96.5]) by quinthar.com for ; Tue, 27 Nov 2007 11:54:44 -0800 From: "David Barrett" To: "'Philip Matthews'" , "'P2PSIP Mailing List'" Subject: RE: [P2PSIP] NAT Traversal Discussion in Vancouver Date: Tue, 27 Nov 2007 11:54:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgxEl0HF1oefeKlQ6SKNz4v8IHcRgAHFnRw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <0399354B-38AB-4209-9E2B-48577299D1E2@magma.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Message-Id: > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Subject: [P2PSIP] NAT Traversal Discussion in Vancouver > > 2) The very-low-level NAT Traversal approach is ICE, and I don't see > anyone questioning that. I don't think a discussion of this is worth > precious meeting time. Though it needn't be a topic of discussion, can you ask the attendees if anybody has some real-world performance and reliability data on ICE that they can share? I don't think any has been published to date, but perhaps new data has come out since our last requests. Indeed, if anybody has this data (or can get it), this would be an excellent time to share it. Specifically, I'm curious to know how long it typically takes to set up a particular connection, and with what probability it can establish a direct connection between two arbitrary peers on the internet. ("Connection setup" and "peer connectivity") Thanks! -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 15:38:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7Co-0003o6-Lr; Tue, 27 Nov 2007 15:38:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix7Cn-0003du-1d for p2psip@ietf.org; Tue, 27 Nov 2007 15:38:53 -0500 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ix7Ck-0004c9-6W for p2psip@ietf.org; Tue, 27 Nov 2007 15:38:53 -0500 Received: by mu-out-0910.google.com with SMTP id i10so1415884mue for ; Tue, 27 Nov 2007 12:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=8K1GOb45CP+3UcEm3dRYFLvoZPyc/nkQTMptHmwiK+c=; b=ou7UZn9enIOOOlfQl66Hka5vEygb4OrMwbTBheZCsLgqO0wo6kp4D26HOo8Mb3BNdXNezvJ5kATGBJLA7tYV5FAZLVhmrDO2nCDnyqvBPXIh0RS3TJ36ZP4zul/CEWZ6lNwtaZa99UwQYuPk+WRjfWs4zqulDRsQ11TOmYYFs30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=bDj7Ia7Xt9bcrd9LsASeSQGj/kAHV0o29rRw1QETUuK6+qMFv5j6ttQXu/eUhPuBpDQmAKRen9ncDAYn3/QuWxwQ9LMF/DnJctVv1GSuShYnzSjv1yaczU/wtColowA3yxEmXTCCbiGhqis2OzIyNjqgFjsIpZf32J1FTY8+hBs= Received: by 10.64.28.3 with SMTP id b3mr31573958qbb.1196195927767; Tue, 27 Nov 2007 12:38:47 -0800 (PST) Received: by 10.65.180.16 with HTTP; Tue, 27 Nov 2007 12:38:47 -0800 (PST) Message-ID: <4d4304a00711271238qa0eeec7v804d2dffd856ec9b@mail.gmail.com> Date: Tue, 27 Nov 2007 15:38:47 -0500 From: "David A. Bryan" To: "David Barrett" Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <0399354B-38AB-4209-9E2B-48577299D1E2@magma.ca> X-Google-Sender-Auth: ba2f3249cf87ff36 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Philip Matthews , P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Happy to have discussion like that on list or in halls and such, since it is relevant to building these things, but that definitely isn't in our space, and I don't want to discuss that in meeting - we have enough things for our agenda. Be a better topic over in MMUSIC... David (as chair) On Nov 27, 2007 2:54 PM, David Barrett wrote: > > -----Original Message----- > > From: Philip Matthews [mailto:philip_matthews@magma.ca] > > Subject: [P2PSIP] NAT Traversal Discussion in Vancouver > > > > 2) The very-low-level NAT Traversal approach is ICE, and I don't see > > anyone questioning that. I don't think a discussion of this is worth > > precious meeting time. > > Though it needn't be a topic of discussion, can you ask the attendees if > anybody has some real-world performance and reliability data on ICE that > they can share? I don't think any has been published to date, but perhaps > new data has come out since our last requests. > > Indeed, if anybody has this data (or can get it), this would be an excellent > time to share it. Specifically, I'm curious to know how long it typically > takes to set up a particular connection, and with what probability it can > establish a direct connection between two arbitrary peers on the internet. > ("Connection setup" and "peer connectivity") > > Thanks! > > -david > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 17:44:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix99m-00028n-CJ; Tue, 27 Nov 2007 17:43:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix99l-00028e-8Q for p2psip@ietf.org; Tue, 27 Nov 2007 17:43:53 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix99k-0007dV-Sv for p2psip@ietf.org; Tue, 27 Nov 2007 17:43:53 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id C632733C28; Tue, 27 Nov 2007 14:03:09 -0800 (PST) Date: Tue, 27 Nov 2007 14:03:09 -0800 From: Eric Rescorla To: "David A. Bryan" Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver In-Reply-To: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127220309.C632733C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Mon, 26 Nov 2007 21:46:42 -0500, David A. Bryan wrote: > Topic: "PeerID assignment and Chosen Location Attacks" > Leader: Eric Rescorla > Goal: Understand the implications of PeerID assignment on security > Take a look at how PeerIDs can be selected, and how this affects > chosen location attacks. Discuss different approaches offered for > ID assignment. This is the first I've heard of this assignment, but if people think it's interesting for us to discuss, sure I'm willing to do it. I think we've already had a bunch of discussion on the list... > * RELOAD (merged with ASP, :10) This doesn't seem fair. RELOAD is now one proposal, regardless of how it got there. We should get 5 minutes like everyone else. > Because this agenda revolves around the questions, rather than specific > drafts being proposed, a specific reading list is not possible. See > www.p2psip.org/ietf.php for a list of current drafts, and revisit the > mailing list for recent discussion on these items. When I went through the drafts it sure seemed to me like many of them had useful perspectives on these issues. Could the chairs please provide a reading list of drafts for each question? -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 18:42:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxA4l-0003Yl-HB; Tue, 27 Nov 2007 18:42:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxA4k-0003YU-I2 for p2psip@ietf.org; Tue, 27 Nov 2007 18:42:46 -0500 Received: from py-out-1112.google.com ([64.233.166.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxA4k-0005br-2K for p2psip@ietf.org; Tue, 27 Nov 2007 18:42:46 -0500 Received: by py-out-1112.google.com with SMTP id d32so4877756pye for ; Tue, 27 Nov 2007 15:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=xRmFNK3LKK1ijwNACthnX9zsjYNVFNv8WE7KqUtmCu8=; b=KG5RzwEj1eTJm53QIiN1pU3YqZn+DW8OKXXkSaLKxPGLSywWtW1GRExZgd3H+iDU3gO6eBQDROViWlZzyws6+Mfs6Kyo1X1gS1aGXrfwpCmiK9YTKQa1cdhB8DEbm3jBEgZwsXQrs4rqakXMOKaWK7culI4Hj7dcWtBVcz0RFds= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=gny2jb+QkrxdydRC+QS4AymaHb6Vsfho8/CXBJ03REvVZQLVO/LD+7CKq6NSkFVUeIP+wIeMNjyGGsG+9Y1I42DRWEcQZmpvKss8mjdWWNhRT0XOgQgjh+YzJefoMNMYcfg2ICDqiikkcRWw15YdKaFRA7H/MrlsoJlAVNsOjHI= Received: by 10.65.119.14 with SMTP id w14mr9908334qbm.1196206965354; Tue, 27 Nov 2007 15:42:45 -0800 (PST) Received: by 10.65.180.16 with HTTP; Tue, 27 Nov 2007 15:42:45 -0800 (PST) Message-ID: <4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com> Date: Tue, 27 Nov 2007 18:42:45 -0500 From: "David A. Bryan" To: "Eric Rescorla" Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver In-Reply-To: <20071127220309.C632733C28@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <20071127220309.C632733C28@delta.rtfm.com> X-Google-Sender-Auth: 1f07fee68025f019 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Inline On Nov 27, 2007 5:03 PM, Eric Rescorla wrote: > At Mon, 26 Nov 2007 21:46:42 -0500, > David A. Bryan wrote: > > Topic: "PeerID assignment and Chosen Location Attacks" > > Leader: Eric Rescorla > > Goal: Understand the implications of PeerID assignment on security > > Take a look at how PeerIDs can be selected, and how this affects > > chosen location attacks. Discuss different approaches offered for > > ID assignment. > > This is the first I've heard of this assignment, but if people think > it's interesting for us to discuss, sure I'm willing to do it. I > think we've already had a bunch of discussion on the list... That's why I told folks if they don't want the assignment, they can refuse. Glad you are interested. This stems from the suggestion by Henning a few weeks ago that we tackle some topics, rather than focus too much on individual drafts. BTW yes, there has been a bunch of discussion on list...that was how these topics were selected. > > > * RELOAD (merged with ASP, :10) > > This doesn't seem fair. RELOAD is now one proposal, regardless of > how it got there. We should get 5 minutes like everyone else. After putting the original agenda together with :5 each, Brian expressed a strong opion on wanting to *not* penalize merges by essentially shorting people time for doing. If you want to give up your 5 minutes, we're happy to use it for something else...I'm still not convinced we'll get to the individual discussions anyway. > > Because this agenda revolves around the questions, rather than specific > > drafts being proposed, a specific reading list is not possible. See > > www.p2psip.org/ietf.php for a list of current drafts, and revisit the > > mailing list for recent discussion on these items. > > When I went through the drafts it sure seemed to me like many of them > had useful perspectives on these issues. Could the chairs please > provide a reading list of drafts for each question? As you just stated, many of the more than a dozen current drafts submitted have useful perspective on the issues. I don't really think it makes sense for me to, essentially, list the dozen or so drafts that are relevant to each question, especially since many (including each of the proposed protocols) has things to say on each. David > > -Ekr > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Tue Nov 27 18:47:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxA9O-0000Qj-VA; Tue, 27 Nov 2007 18:47:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxA9N-0000B5-Aa for p2psip@ietf.org; Tue, 27 Nov 2007 18:47:33 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxA9M-0006pY-SG for p2psip@ietf.org; Tue, 27 Nov 2007 18:47:33 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 79EEF33C28; Tue, 27 Nov 2007 15:42:33 -0800 (PST) Date: Tue, 27 Nov 2007 15:42:32 -0800 From: Eric Rescorla To: "David A. Bryan" Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver In-Reply-To: <4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com> References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <20071127220309.C632733C28@delta.rtfm.com> <4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071127234233.79EEF33C28@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 27 Nov 2007 18:42:45 -0500, David A. Bryan wrote: > > Inline > > On Nov 27, 2007 5:03 PM, Eric Rescorla wrote: > > At Mon, 26 Nov 2007 21:46:42 -0500, > > David A. Bryan wrote: > > > Topic: "PeerID assignment and Chosen Location Attacks" > > > Leader: Eric Rescorla > > > Goal: Understand the implications of PeerID assignment on security > > > Take a look at how PeerIDs can be selected, and how this affects > > > chosen location attacks. Discuss different approaches offered for > > > ID assignment. > > > > This is the first I've heard of this assignment, but if people think > > it's interesting for us to discuss, sure I'm willing to do it. I > > think we've already had a bunch of discussion on the list... > > That's why I told folks if they don't want the assignment, they can > refuse. Glad you are interested. This stems from the suggestion by > Henning a few weeks ago that we tackle some topics, rather than focus > too much on individual drafts. BTW yes, there has been a bunch of > discussion on list...that was how these topics were selected. Yes, my point was that I didn't think I needed to start a discussion, since there already has been one. > > > Because this agenda revolves around the questions, rather than specific > > > drafts being proposed, a specific reading list is not possible. See > > > www.p2psip.org/ietf.php for a list of current drafts, and revisit the > > > mailing list for recent discussion on these items. > > > > When I went through the drafts it sure seemed to me like many of them > > had useful perspectives on these issues. Could the chairs please > > provide a reading list of drafts for each question? > > As you just stated, many of the more than a dozen current drafts > submitted have useful perspective on the issues. I don't really think > it makes sense for me to, essentially, list the dozen or so drafts > that are relevant to each question, especially since many (including > each of the proposed protocols) has things to say on each. Actually, I think that would be extremely useful. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 28 01:32:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGSp-0006zG-4R; Wed, 28 Nov 2007 01:32:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGSm-0006yz-Rd for p2psip@ietf.org; Wed, 28 Nov 2007 01:32:00 -0500 Received: from [74.95.2.169] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxGSm-0003CS-Bd for p2psip@ietf.org; Wed, 28 Nov 2007 01:32:00 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5B42C33C3D; Tue, 27 Nov 2007 22:26:47 -0800 (PST) Date: Tue, 27 Nov 2007 22:26:46 -0800 From: Eric Rescorla To: "David A. Bryan" Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver In-Reply-To: <20071127234233.79EEF33C28@delta.rtfm.com> References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <20071127220309.C632733C28@delta.rtfm.com> <4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com> <20071127234233.79EEF33C28@delta.rtfm.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071128062647.5B42C33C3D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org At Tue, 27 Nov 2007 15:42:32 -0800, Eric Rescorla wrote: > > As you just stated, many of the more than a dozen current drafts > > submitted have useful perspective on the issues. I don't really think > > it makes sense for me to, essentially, list the dozen or so drafts > > that are relevant to each question, especially since many (including > > each of the proposed protocols) has things to say on each. > > Actually, I think that would be extremely useful. To expand on this a little bit: not all of the drafts address each issue, and it would be useful for people who are interested in each issue to be able to know which drafts to focus on. As a secondary issue, my experience is that people only read the drafts that are on the reading list. To have a good discussion based on the drafts then we need people to read them, which means we should have an explicit list. -Ekr _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 28 01:51:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGlU-0005L3-69; Wed, 28 Nov 2007 01:51:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGlT-0005Kw-Aw for p2psip@ietf.org; Wed, 28 Nov 2007 01:51:19 -0500 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxGlS-0000g0-Oo for p2psip@ietf.org; Wed, 28 Nov 2007 01:51:19 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1065282rvb for ; Tue, 27 Nov 2007 22:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=k2vrS5zyOBLIRbChmSjdUlsJ1wOAPCQuYwYAerpM9fI=; b=Rivs2ZGAqaJxDQhIbDuLsdeHErfpUuHhHSEm13laIk14EjIyOXVa2K/myMzt2z7T06deQ7ikV/tgE1xCUjqBNxisXKo2+hXJk6CQhWTklAiPJddGLepTWRj4jqUWrCJRDneCWM5is1Qh25HNAGE2c79hoAIqUCjQ03heYb5D6TU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=elHy277pOWR3vPqeJF2jjpca4PSBPHBxAtmEnxH6fjnSl4XTyF9U6zip2FBAFkdOAB638vsjRqR0PZf90sVCM97lun7VtzWb5wlF0cENkQ3uaUNkmvu9ruomIBpQ5Lif+zUxrObmzcEEM+vh11eeKJAC+3u18CNanOB5j8SwvRY= Received: by 10.140.187.10 with SMTP id k10mr2409722rvf.1196232676442; Tue, 27 Nov 2007 22:51:16 -0800 (PST) Received: by 10.141.177.20 with HTTP; Tue, 27 Nov 2007 22:51:16 -0800 (PST) Message-ID: <7b683f3f0711272251w6779a040jad8f3868f308b42e@mail.gmail.com> Date: Wed, 28 Nov 2007 01:51:16 -0500 From: "Eunsoo Shim" To: p2psip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [P2PSIP] Draft about P2PSIP Client Concept X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, We wrote the following draft. Even though the draft is quite late for the upcoming IETF meeting, we hope this helps the discussion about the Clients in the meeting. title: P2PSIP Clients file: draft-pascual-p2psip-clients-00 Abstract This document describes why and when some devices would better be a Client rather than a Peer. The purpose of this document is to facilitate the discussion and understanding about the Client node type. It is available in the link below. http://www.ee.columbia.edu/~eunsoo/open2/draft-pascual-p2psip-clients-00.txt It will be submitted to the IETF. Thanks. -- Eunsoo _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 28 02:06:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGzg-0003bR-CB; Wed, 28 Nov 2007 02:06:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxGzc-0003bE-Ow for p2psip@ietf.org; Wed, 28 Nov 2007 02:05:56 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxGza-0001SX-FJ for p2psip@ietf.org; Wed, 28 Nov 2007 02:05:56 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS7004HHFOIQ7@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 28 Nov 2007 15:05:07 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JS700DFVFOIEJ@szxga03-in.huawei.com> for p2psip@ietf.org; Wed, 28 Nov 2007 15:05:06 +0800 (CST) Received: from z52048 ([10.164.5.81]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JS7007JAFOEHY@szxml04-in.huawei.com> for p2psip@ietf.org; Wed, 28 Nov 2007 15:05:06 +0800 (CST) Date: Wed, 28 Nov 2007 15:05:02 +0800 From: Zheng Hewen In-reply-to: To: 'Philip Matthews' , 'Henning Schulzrinne' Message-id: <001001c8318c$ff4d2f10$5105a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: TEXT/PLAIN Content-transfer-encoding: 7BIT Thread-index: Acgqsd+owdgH+qPyT5+0ch2h8OdFpAG2rfLA X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: 'P2PSIP Mailing List' Subject: [P2PSIP] Draft about P2PSIP Client Concept X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, We formed an initial I-D to address : * Describe a problem that you want to solve using clients. * Present a convincing argument why that problem is interesting. * Present a convincing argument why that problem cannot be solved using peers. Any comment is appreciated! Best regards, Hewen > -----Original Message----- > From: Eunsoo Shim [mailto:eunsooshim@gmail.com] > Sent: 2007?11?28? 14:51 > To: p2psip@ietf.org > Cc: Victor Pascual ??vila; marcin.matuszewski@nokia.com; Zheng Hewen > Subject: Draft about P2PSIP Client Concept > > Hi, > > We wrote the following draft. Even though the draft is quite > late for the upcoming IETF meeting, we hope this helps the > discussion about the Clients in the meeting. > > > title: P2PSIP Clients > file: draft-pascual-p2psip-clients-00 > Abstract > > This document describes why and when some devices would > better be a Client rather than a Peer. The purpose of this > document is to facilitate the discussion and understanding > about the Client node type. > > It is available in the link below. > http://www.ee.columbia.edu/~eunsoo/open2/draft-pascual-p2psip- > clients-00.txt > > It will be submitted to the IETF. > Thanks. > -- > Eunsoo > > -----Original Message----- > From: Philip Matthews [mailto:philip_matthews@magma.ca] > Sent: 2007?11?19? 21:42 > To: Henning Schulzrinne > Cc: P2PSIP Mailing List > Subject: Re: [P2PSIP] [P2PSIP:Survey] P2PSIP Client Character/Behavior > > > On 17-Nov-07, at 12:06 , Henning Schulzrinne wrote: > > > > > Frankly, I don't understand your reluctance to deal with clients. > > All protocol proposals trivially accommodate them, as far as I can > > tell, so it's not like this is going to cause dramatic scope creep. > > > > Let me turn this around. I'd like to hear from people who have an > > argument as to why clients are not needed or why they cause > > significant increases in complexity. > > 1) The usual desire not to introduce a concept that is not needed. > 2) No clear idea why people want clients. So far, the only > agreed- upon description of a client is that they do > something less than a peer. > 3) No clear description of what a client is. Concepts-01 > lists three different alternatives that have been proposed by > people, and so far there seems to be no WG consensus around > any of these. > > Your e-mail is a good start to an argument why there might be > nodes that can and might want to be clients, but cannot be > peers, though it still doesn't describe WHAT a client is. > > Let me be clear. Given a good argument, I am quite willing to > have the concept of a client. I just need to know what it is > and why I need it. > > - Philip > > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 28 09:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNSL-0002Kd-75; Wed, 28 Nov 2007 09:00:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNSK-0002KJ-MF for p2psip@ietf.org; Wed, 28 Nov 2007 09:00:00 -0500 Received: from nz-out-0506.google.com ([64.233.162.224]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNSK-0003i3-3M for p2psip@ietf.org; Wed, 28 Nov 2007 09:00:00 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1069489nzf for ; Wed, 28 Nov 2007 05:59:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=bi9J2K1iu9Gj/5P1sPwU95ABvkG//nsluYx3AA29ITo=; b=PKdIOXDlzL1Bzwt1UsT//TQK95nFIZnbHu/JUqRTPITQh/E3q46qsqbb+sugJ/N3TqeqBmN+2yo9dBpr/UoF6ZMcc4YOomlMUYAz8YqFSrDWargrvEbYt2QWtIC6BJsSDc9Z3KtEGRWe+AxuX27dYfk9nbpeHueEPvyrMwWbv6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=Dx/wjgR0qLCKTfykZAWX5GCX2LbBT7AvU8GvpkUv2r8s8Wi/p6Ui0ub2BxaOr3jBMvCIDAi7NrUIgpE46gNR5c7uQBAaPDoZRIwcPuYYm9h0pB/SA2D7pbKuwpJzVHtNbb1MbHNIjIWwG5sOPVwFptojxUB5G3bgmdELyX11Ls8= Received: by 10.65.124.8 with SMTP id b8mr11814933qbn.1196258387945; Wed, 28 Nov 2007 05:59:47 -0800 (PST) Received: by 10.65.180.16 with HTTP; Wed, 28 Nov 2007 05:59:47 -0800 (PST) Message-ID: <4d4304a00711280559v9a5cce2r56d1f7d63e2e79de@mail.gmail.com> Date: Wed, 28 Nov 2007 08:59:47 -0500 From: "David A. Bryan" To: "Eric Rescorla" Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver In-Reply-To: <20071127234233.79EEF33C28@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com> <20071127220309.C632733C28@delta.rtfm.com> <4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com> <20071127234233.79EEF33C28@delta.rtfm.com> X-Google-Sender-Auth: 5135eaef3c257f9f X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Inline. On Nov 27, 2007 6:42 PM, Eric Rescorla wrote: > At Tue, 27 Nov 2007 18:42:45 -0500, > David A. Bryan wrote: > > > > Inline > > > > On Nov 27, 2007 5:03 PM, Eric Rescorla wrote: > > > At Mon, 26 Nov 2007 21:46:42 -0500, > > > David A. Bryan wrote: > > > > Topic: "PeerID assignment and Chosen Location Attacks" > > > > Leader: Eric Rescorla > > > > Goal: Understand the implications of PeerID assignment on security > > > > Take a look at how PeerIDs can be selected, and how this affects > > > > chosen location attacks. Discuss different approaches offered for > > > > ID assignment. > > > > > > This is the first I've heard of this assignment, but if people think > > > it's interesting for us to discuss, sure I'm willing to do it. I > > > think we've already had a bunch of discussion on the list... > > > > That's why I told folks if they don't want the assignment, they can > > refuse. Glad you are interested. This stems from the suggestion by > > Henning a few weeks ago that we tackle some topics, rather than focus > > too much on individual drafts. BTW yes, there has been a bunch of > > discussion on list...that was how these topics were selected. > > Yes, my point was that I didn't think I needed to start a discussion, > since there already has been one. > I'd like to see the slides cover the discussion, rather than one person's viewpoint (hence why the people are listed as "leader" -- in many cases these are contentious issues and we have picked an active participant, who in many cases is also a partisan...I assume people can at least present both sides of the issue in the slides, even if in the discussion they vociferously argue for their perspective). As such, I'd like discussion about what will be presented so we don't have a problem where only one person's view is presented on the slides. That is really what I was talking about. We have had discussion or the topic wouldn't have made the list. > > > > Because this agenda revolves around the questions, rather than specific > > > > drafts being proposed, a specific reading list is not possible. See > > > > www.p2psip.org/ietf.php for a list of current drafts, and revisit the > > > > mailing list for recent discussion on these items. > > > > > > When I went through the drafts it sure seemed to me like many of them > > > had useful perspectives on these issues. Could the chairs please > > > provide a reading list of drafts for each question? > > > > As you just stated, many of the more than a dozen current drafts > > submitted have useful perspective on the issues. I don't really think > > it makes sense for me to, essentially, list the dozen or so drafts > > that are relevant to each question, especially since many (including > > each of the proposed protocols) has things to say on each. > > Actually, I think that would be extremely useful. I am afraid I really disagree with you here. We tried something similar when we discussed broad issues/topics in Prague, and a few folks later mentioned to me that particular drafts they felt had said something on the issue were not being listed for that topics reading. Essentially, it would be my/Brian's personal opinion as to whether a particular draft had anything useful to say on a broad topic, a decision I believe is in the eye of the beholder. If you as an individual want to go ahead and make a list, that is great but personally, I feel quite strongly that is not an appropriate thing for a chair to do. Obviously we will list drafts for more narrow topics or particular draft discussions. David (as chair) > -Ekr > > -- David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 28 12:10:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxQQs-0005SN-PS; Wed, 28 Nov 2007 12:10:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxQQr-0005Qd-Sl for p2psip@ietf.org; Wed, 28 Nov 2007 12:10:41 -0500 Received: from chip2og56.obsmtp.com ([64.18.13.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxQQq-0006Sn-Sm for p2psip@ietf.org; Wed, 28 Nov 2007 12:10:41 -0500 Received: from source ([192.150.11.134]) by chip2ob56.postini.com ([64.18.5.12]) with SMTP; Wed, 28 Nov 2007 09:10:28 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lASH8AOP013044; Wed, 28 Nov 2007 09:08:14 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lASHAHFV000716; Wed, 28 Nov 2007 09:10:18 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 09:10:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Agenda for the upcoming meeting in Vancouver (existentialist topics) Date: Wed, 28 Nov 2007 09:10:05 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE35A@namail5.corp.adobe.com> In-Reply-To: <4d4304a00711280559v9a5cce2r56d1f7d63e2e79de@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Agenda for the upcoming meeting in Vancouver (existentialist topics) Thread-Index: Acgxxv47OsfxucU4QsqQ9wOyDY9+VgAFmp4g References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com><20071127220309.C632733C28@delta.rtfm.com><4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com><20071127234233.79EEF33C28@delta.rtfm.com> <4d4304a00711280559v9a5cce2r56d1f7d63e2e79de@mail.gmail.com> From: "Henry Sinnreich" To: "David A. Bryan" , "Eric Rescorla" X-OriginalArrivalTime: 28 Nov 2007 17:10:11.0560 (UTC) FILETIME=[88FACE80:01C831E1] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Both David and EKR make some very good arguments, though I believe the central theme should be the existentialist topics for P2PSIP and have changed the subject title accordingly. Here are some examples: 1. P2PSIP must work on the Internet 'as is' 1.1. NAT traversal since most peers will be behind several NAT. Though these is a wide-spread belief that ICE is the answer, we don't know if it is the only answer, if it is the best answer, what the % success ratio is, what the performance and complexity may be. There are no deployment data to make any judgments, nor have any measuring tools even been proposed. 2.2. Solutions based on HIP and other NG Internet technologies. What is the risk assessment they may actually happen and when? 3. Security We have an abundance of security solutions, but no assessment of what is the minimal solutions that will be good enough and no more (such as ZRTP for CS SIP)? Remember that too much security comes at a heavy cost and may fail in the market. What is the right balance for some sample usage scenarios? 3. What will make P2PSIP a successful protocol? 3.1. To what degree should preference be given to free and open software such as the SER, Bamboo and P2PP? 3.2. To what degree to give preference to I-Ds written by authors actually developing and testing P2PSIP? (and making the software available) Reference: What Makes For a Successful Protocol?=20 ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-iab-protocol-suc cess-01.txt =20 This is just a sample list. Maybe during the Agenda Bashing or here on the list people can contribute to what are the most critical issues to discuss and to solve. What do you think? What are the most critical topics for the agenda? Henry =20 -----Original Message----- From: David A. Bryan [mailto:dbryan@sipeerior.com]=20 Sent: Wednesday, November 28, 2007 8:00 AM To: Eric Rescorla Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver Inline. On Nov 27, 2007 6:42 PM, Eric Rescorla wrote: > At Tue, 27 Nov 2007 18:42:45 -0500, > David A. Bryan wrote: > > > > Inline > > > > On Nov 27, 2007 5:03 PM, Eric Rescorla wrote: > > > At Mon, 26 Nov 2007 21:46:42 -0500, > > > David A. Bryan wrote: > > > > Topic: "PeerID assignment and Chosen Location Attacks" > > > > Leader: Eric Rescorla > > > > Goal: Understand the implications of PeerID assignment on security > > > > Take a look at how PeerIDs can be selected, and how this affects > > > > chosen location attacks. Discuss different approaches offered for > > > > ID assignment. > > > > > > This is the first I've heard of this assignment, but if people think > > > it's interesting for us to discuss, sure I'm willing to do it. I > > > think we've already had a bunch of discussion on the list... > > > > That's why I told folks if they don't want the assignment, they can > > refuse. Glad you are interested. This stems from the suggestion by > > Henning a few weeks ago that we tackle some topics, rather than focus > > too much on individual drafts. BTW yes, there has been a bunch of > > discussion on list...that was how these topics were selected. > > Yes, my point was that I didn't think I needed to start a discussion, > since there already has been one. > I'd like to see the slides cover the discussion, rather than one person's viewpoint (hence why the people are listed as "leader" -- in many cases these are contentious issues and we have picked an active participant, who in many cases is also a partisan...I assume people can at least present both sides of the issue in the slides, even if in the discussion they vociferously argue for their perspective). As such, I'd like discussion about what will be presented so we don't have a problem where only one person's view is presented on the slides. That is really what I was talking about. We have had discussion or the topic wouldn't have made the list. > > > > Because this agenda revolves around the questions, rather than specific > > > > drafts being proposed, a specific reading list is not possible. See > > > > www.p2psip.org/ietf.php for a list of current drafts, and revisit the > > > > mailing list for recent discussion on these items. > > > > > > When I went through the drafts it sure seemed to me like many of them > > > had useful perspectives on these issues. Could the chairs please > > > provide a reading list of drafts for each question? > > > > As you just stated, many of the more than a dozen current drafts > > submitted have useful perspective on the issues. I don't really think > > it makes sense for me to, essentially, list the dozen or so drafts > > that are relevant to each question, especially since many (including > > each of the proposed protocols) has things to say on each. > > Actually, I think that would be extremely useful. I am afraid I really disagree with you here. We tried something similar when we discussed broad issues/topics in Prague, and a few folks later mentioned to me that particular drafts they felt had said something on the issue were not being listed for that topics reading. Essentially, it would be my/Brian's personal opinion as to whether a particular draft had anything useful to say on a broad topic, a decision I believe is in the eye of the beholder. If you as an individual want to go ahead and make a list, that is great but personally, I feel quite strongly that is not an appropriate thing for a chair to do. Obviously we will list drafts for more narrow topics or particular draft discussions. David (as chair) > -Ekr > > --=20 David A. Bryan dbryan@SIPeerior.com +1.757.565.0101 x101 +1.757.565.0088 (fax) www.SIPeerior.com _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 28 15:30:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTYe-00058S-6z; Wed, 28 Nov 2007 15:30:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxTYc-00057P-Mg for p2psip@ietf.org; Wed, 28 Nov 2007 15:30:54 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxTYc-0004o3-2Q for p2psip@ietf.org; Wed, 28 Nov 2007 15:30:54 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lASKUJP7029640; Wed, 28 Nov 2007 22:30:50 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 22:30:27 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 22:30:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] NAT Traversal Discussion in Vancouver Date: Wed, 28 Nov 2007 22:30:59 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F057B9E1E@esebe102.NOE.Nokia.com> In-Reply-To: <0399354B-38AB-4209-9E2B-48577299D1E2@magma.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] NAT Traversal Discussion in Vancouver Thread-Index: AcgxEmwcrc58g+OJQXiNAjx6dFYwDAA6PApQ References: <0399354B-38AB-4209-9E2B-48577299D1E2@magma.ca> From: To: , X-OriginalArrivalTime: 28 Nov 2007 20:30:27.0377 (UTC) FILETIME=[82F6FA10:01C831FD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Philip, I agree that 3 and 4 are interesting issues but in my opinion 4 is much more important. I do not see HIP flying anyway. It introduces complexity and does not offer clear advantages over widely implemented protocols. Besides HIP together with a distributed nature of P2PSIP introduces more questions than answers. In my opinion it is a good protocol for researcher to play with but I see problems with wide deployment of HIP.=20 Marcin=20 >-----Original Message----- >From: ext Philip Matthews [mailto:philip_matthews@magma.ca]=20 >Sent: 27 November, 2007 18:27 >To: P2PSIP Mailing List >Subject: [P2PSIP] NAT Traversal Discussion in Vancouver > >Folks: > >The chairs have asked me to lead a discussion of "NAT=20 >Traversal for P2P Messages". What I would like to get is a=20 >solid idea of what people would like to see discussed during this slot. > >As I see it, there are four parts to the whole P2PSIP NAT traversal >discussion: > >1) The high-level NAT Traversal approach that most people seem=20 >to be adopting is the idea of routing around the overlay to=20 >reach peers behind NATs. As I understand it, that is going to=20 >be covered in the >"Routing: What does it look like?" discussion. As I see it,=20 >even the recent ideas to include Relays would fall under that=20 >discussion. =20 >[Spencer: Do you agree?] > >2) The very-low-level NAT Traversal approach is ICE, and I=20 >don't see anyone questioning that. I don't think a discussion=20 >of this is worth precious meeting time. > >This leaves two medium-level issues: > >3) Is NAT Traversal is done by each application separately, or=20 >is done once (by HIP or the Peer Protocol)? In essence, this=20 >morphs into the whole ID/Locator split idea. > >4) How does a peer locate STUN and TURN servers? > >Both (3) and (4) would be good topics for a 15 minute=20 >discussion, but I feel that there is only time for one of=20 >these. So I would like to choose just one for the discussion.=20 >There have been drafts discussing both of these, but I think=20 >that (3) has been a hotter topic recently than (4), so my=20 >preference is to discuss (3). > >Comments? >Is there something that I have missed? > >- Philip > >_______________________________________________ >P2PSIP mailing list >P2PSIP@ietf.org >https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Wed Nov 28 21:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZbC-0000KM-9M; Wed, 28 Nov 2007 21:57:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxZbB-0000KD-9b for p2psip@ietf.org; Wed, 28 Nov 2007 21:57:57 -0500 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxZb9-0007bF-I2 for p2psip@ietf.org; Wed, 28 Nov 2007 21:57:57 -0500 Received: from [72.87.190.177] (helo=[10.9.0.1]) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IxZb8-0008Be-EN; Wed, 28 Nov 2007 21:57:54 -0500 Message-ID: <474E2A8B.2060403@idssoftware.com> Date: Wed, 28 Nov 2007 18:57:15 -0800 From: Michael Chen User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification for draft-bryan-p2psip-reload-02 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 68edf72dbb77893ca35f5539f9d485d07e972de0d01da94038c6e0e3eedd69109febee2098b57d90350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 72.87.190.177 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Cullen, I don't see where the protocol sends the originator's peer-ID. At the end of section 4.1, it says the via list starts out empty and the route list has the intermediate and destination peer IDs. Say A wants to reach C through B, then in the forwarding header sent by A, the route-list contains [B, C], and the via list is empty. Where does C or B for that matter know the peer ID of A when it's time to send the respond back? Should the via-list in the forwarding header sent by A contains the peer ID of A? Also, any comment of my earlier suggestion in this thread about swapping the position of the via list and route list? Thanks --Michael Cullen Jennings wrote: > > The various authors of ASP and RELOAD have managed to get these two > proposal merged together into one and we are pretty happy with the > result. > > You can find it at > http://www.ietf.org/internet-drafts/draft-bryan-p2psip-reload-02.txt > > > Begin forwarded message: > >> From: IETF I-D Submission Tool >> Date: November 18, 2007 8:57:03 PM PST >> To: fluffy@cisco.com >> Cc: lowekamp@sipeerior.com, ekr@networkresonance.com, jdrosen@cisco.com >> Subject: New Version Notification for draft-bryan-p2psip-reload-02 >> >> >> A new version of I-D, draft-bryan-p2psip-reload-02.txt has been >> successfuly submitted by Cullen Jennings and posted to the IETF >> repository. >> >> Filename: draft-bryan-p2psip-reload >> Revision: 02 >> Title: REsource LOcation And Discovery (RELOAD) >> Creation_date: 2007-11-18 >> WG ID: Independent Submission >> Number_of_pages: 96 >> >> Abstract: >> This document defines REsource LOcation And Discovery (RELOAD), a >> peer-to-peer (P2P) binary signaling protocol for usage on the >> Internet. A P2P signaling protocol provides its clients with an >> abstract hash table service between a set of cooperating peers that >> form the overlay network. RELOAD is designed to support a P2P >> Session Initiation Protocol (P2PSIP) network, but it can be utilized >> by other applications with similar requirements by defining new >> usages that specify the data types that must be stored for a >> particular application, such as location for SIP. RELOAD defines a >> security model based on a certificate enrollment service that >> provides unique identities. NAT traversal is a fundamental service >> of the protocol. >> >> This draft represents a concrete proposal for the P2PSIP Peer >> Protocol. The protocol described here builds on the lessons and >> experiences from designing and implementing the dSIP, ASP, and RELOAD >> protocols and is a merge of features from RELOAD-01 and ASP. >> >> >> >> The IETF Secretariat. > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 29 04:14:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxfTa-0006P3-CZ; Thu, 29 Nov 2007 04:14:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxfTY-0006Oe-66 for p2psip@ietf.org; Thu, 29 Nov 2007 04:14:28 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxfTX-0003t2-0F for p2psip@ietf.org; Thu, 29 Nov 2007 04:14:28 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lAT9Cq9A023040; Thu, 29 Nov 2007 11:13:06 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 11:13:05 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 11:13:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] P2PSIP security requirements Date: Thu, 29 Nov 2007 11:15:56 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F057BA08C@esebe102.NOE.Nokia.com> In-Reply-To: <005701c8309d$c7324ba0$5105a40a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] P2PSIP security requirements Thread-Index: Acgqsj9UsxgjVb+ZSu6NTuZ45gG7lwBiYDpAARcG8IAAV/ZboA== References: <3F18E76823C95E4795181D74BAC7664F057538D4@esebe102.NOE.Nokia.com> <005701c8309d$c7324ba0$5105a40a@china.huawei.com> From: To: , X-OriginalArrivalTime: 29 Nov 2007 09:13:05.0738 (UTC) FILETIME=[0D12C2A0:01C83268] X-Nokia-AV: Clean X-Spam-Score: 0.3 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: jan-erik.ekberg@nokia.com, pekka.laitinen@nokia.com X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Hewen, Thanks for your comments. Answers inline... =20 >-----Original Message----- >From: ext Zheng Hewen [mailto:hwzheng@huawei.com]=20 >Sent: 27 November, 2007 04:33 >To: Matuszewski Marcin (Nokia-NRC/Helsinki); p2psip@ietf.org >Cc: Ekberg Jan-Erik (Nokia-NRC/Helsinki); Laitinen Pekka=20 >(Nokia-NRC/Helsinki) >Subject: RE: [P2PSIP] P2PSIP security requirements > >Hi, > > Here are some cents after a quick look. > (1).In Section 2.3, "Enrolment protocol" appears, is it a=20 >distinctly different protocol from peer/client protocol? Would=20 >you give an example? There are some alternatives. In my opinion the best option is PKCS#10 with HTTP Digest on top of TLS. =20 > (2).Do you think that resource records pollution is a=20 >security threat to P2PSIP overlay? For example, some=20 >malicious node may publish fake resource records; it will=20 >cause some negative impaction; Yes this is a security threat. It can be mitigated using authentication mechanisms, however the access control and authentication mechanisms may not work if peers that are responsible for storing resource (user) records do not act according to the overlay policies. > (3).For "Req.7: It MUST be difficult to select a particular=20 >peer ID e.g. peer ID assignment process should introduce some=20 >degree of randomness to peer identities", Should "e.g." be "i.e."? Thanks for noticing it. I will correct it. > (4)."Req. 9: It MUST NOT be possible to repeat or delay=20 >valid data transmission during enrollment and modification of=20 >P2PSIP resource (user) records". I did not understand it, why=20 >do we need it? This requirement is mostly about replay attacks. An example of the replay attack: a badly behaving node take an older request sent by another node, resend it to the overlay, and thus replace any newer data with the old information. =20 > (5).Req.16 says "It SHOULD be possible to limit the impact=20 >of badly behaving P2PSIP nodes on the overall system security. >There SHOULD be an option to identify malfunctioning or badly=20 >behaving nodes, and exclude or reject them from the P2PSIP=20 >system", in my understanding, we can reject suspicious nodes=20 >through Enrollment process or some mechanism like=20 >blacklisting, how to exclude those nodes? Explicit exclusion=20 >routing method like RSVP-TE EXO? The enrolment process cannot fully protect against malicious nodes joining an overlay network. For example in an enterprise domain your peer is admitted to the network because you are an employee of the organization. This does not guarantee that you will not try to attack the system. There are mechanisms to identify malfunctioning or badly behaving nodes and reject them from the network. =20 > Another personal opinion, for P2PSIP overlay, extra=20 >security requirements are mandatory in some scenarios such as=20 >in an unknown Internet environment, but they are optional in=20 >some scenarios such as in an autonomous enterprise private=20 >network, do you think so?=20 This is a good question. We were discussing this issue.=20 Our current thinking is that we are going to standardize only one protocol that will work in different scenarios. It is true that some of the protocol functions will not be used in all of the scenarios. Certainly, those requirements listed=20 >in the I-D are basic and necessary for untrusty network. > Any comment please. > >Best regards, >Hewen > >> -----Original Message----- >> From: marcin.matuszewski@nokia.com >> [mailto:marcin.matuszewski@nokia.com] >> Sent: 2007?11?26? 18:17 >> To: p2psip@ietf.org >> Cc: jan-erik.ekberg@nokia.com; pekka.laitinen@nokia.com >> Subject: [P2PSIP] P2PSIP security requirements >> >> >> Hi all, >> >> We submitted a new version of the security requirements draft: >> http://www.ietf.org/internet-drafts/draft-matuszewski-p2psip-s >> ecurity-re >> quirements-02.txt. We improved the security threats section and=20 >> modified requirements according to your comments. >> >> This document presents a basic set of security requirements that we=20 >> believe that each of the proposals needs to address: >> >> P2PSIP system requirements related to security issues are summarized >> below: >> >> Req. 1: Dependence of reachability of a centralized server SHOULD=20 >> be >> minimized. >> >> Req. 2: P2PSIP security SHOULD scale from a small ad-hoc=20 >network to=20 >> a >> network with hundred millions of network nodes and users. >> >> Req. 3: Existing security mechanisms SHOULD be used as much as >> possible to protect P2PSIP functions, and avoid the need for >> standardizing new mechanisms. >> >> Req. 4: Security requirements on the base P2P algorithm (e.g., DHT >> implementations) used in P2PSIP SHOULD be minimized and SHOULD NOT >> limit its scalability. >> >> Req. 5: The registered identities in a P2PSIP overlay MUST be >> preserved. The attacker MUST NOT be able to steal identity from >> another user. >> >> Req. 6: The enrollment process MUST make it difficult for an=20 >> attacker >> to register many identities in a P2PSIP overlay and easily modify=20 >> the >> registered identities. >> >> Req. 7: It MUST be difficult to select a particular peer ID e.g.=20 >> peer >> ID assignment process should introduce some degree of=20 >randomness to >> peer identities. >> >> Req. 8: It MUST be possible to authenticate users and P2PSIP=20 >> network >> entities. >> >> Req. 9: It MUST NOT be possible to repeat or delay valid data >> transmission during enrollment and modification of P2PSIP resource >> (user) records. >> >> Req. 10: The P2PSIP security MUST support integrity protection of=20 >> the >> data being inserted or retrieved to/from an overlay. >> >> Req. 11: The P2PSIP network entities MUST be provided with an=20 >> option >> to encrypt data exchanged with other P2PSIP network entities. >> >> Req. 12: Only authorized users and P2PSIP network entities MUST be >> able to join the P2PSIP system and insert, modify, delete or >> overwrite P2PSIP resource (user) records in the P2PSIP system. >> >> Req. 13: In the situations where many users or P2PSIP network >> entities register the same resource in the P2PSIP overlay, each >> entity MUST have rights only to its own part of a resource record. >> >> Req. 14: An owner of P2PSIP resource (user) record MAY indicate=20 >> which >> users or network entities can retrieve, modify, and delete data >> stored in their P2PSIP resource (user) records. >> >> Req. 15: P2PSIP overlay protocols MUST be designed such a way so=20 >> that >> the effect of DOS attacks on the P2PSIP overlay is minimized. >> >> Req. 16: It SHOULD be possible to limit the impact of badly=20 >> behaving >> P2PSIP nodes on the overall system security. There SHOULD be an >> option to identify malfunctioning or badly behaving nodes, and >> exclude or reject them from the P2PSIP system. >> >> >> We would appreciate your comments! >> >> Marcin >> >> >A new version of I-D, >> >draft-matuszewski-p2psip-security-requirements-02.txt has been=20 >> >successfuly submitted by Marcin Matuszewski and posted to the IETF=20 >> >repository. >> > >> >Filename: draft-matuszewski-p2psip-security-requirements >> >Revision: 02 >> >Title: Security requirements in P2PSIP >> >Creation_date: 2007-11-19 >> >WG ID: Independent Submission >> >Number_of_pages: 23 >> > >> >Abstract: >> >This document presents main security requirements for the >> >Peer-to- Peer SIP (P2PSIP) architecture and its components. >> >This document also analyses security threats in P2PSIP. >> >Typical security ontology is used as classification for the threats. >> > >> > >> > >> > >> >The IETF Secretariat. >> > >> > >> > >> >> _______________________________________________ >> P2PSIP mailing list >> P2PSIP@ietf.org >> https://www1.ietf.org/mailman/listinfo/p2psip >> > > > > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 29 06:41:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixhm1-0001JA-BR; Thu, 29 Nov 2007 06:41:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixhm0-0001Ih-6N for p2psip@ietf.org; Thu, 29 Nov 2007 06:41:40 -0500 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixhly-0001O1-He for p2psip@ietf.org; Thu, 29 Nov 2007 06:41:40 -0500 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E3EBF20F96; Thu, 29 Nov 2007 12:41:37 +0100 (CET) X-AuditID: c1b4fb3e-afea1bb00000459d-4d-474ea571cfaa Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D101B20255; Thu, 29 Nov 2007 12:41:37 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 12:41:37 +0100 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 12:41:37 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1273C24DC; Thu, 29 Nov 2007 13:41:37 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B80424DC3B; Thu, 29 Nov 2007 13:41:34 +0200 (EET) Received: from [127.0.0.1] (localhost [IPv6:::1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5E8354DC2F; Thu, 29 Nov 2007 13:41:34 +0200 (EET) Message-ID: <474EA5DB.4010201@ericsson.com> Date: Thu, 29 Nov 2007 13:43:23 +0200 From: "Jani Hautakorpi (JO/LMF)" Organization: Ericsson User-Agent: Thunderbird 1.5.0.14pre (X11/20071023) MIME-Version: 1.0 To: Henry Sinnreich Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver (existentialist topics) References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com><20071127220309.C632733C28@delta.rtfm.com><4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com><20071127234233.79EEF33C28@delta.rtfm.com> <4d4304a00711280559v9a5cce2r56d1f7d63e2e79de@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE35A@namail5.corp.adobe.com> In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE35A@namail5.corp.adobe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 29 Nov 2007 11:41:37.0425 (UTC) FILETIME=[CCDA4810:01C8327C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi Henry, Henry Sinnreich wrote: > Both David and EKR make some very good arguments, though I believe the > central theme should be the existentialist topics for P2PSIP and have > changed the subject title accordingly. Here are some examples: > > ... > > 2.2. Solutions based on HIP and other NG Internet technologies. > > What is the risk assessment they may actually happen and when? I didn't quite understand this question. Could you clarify what you meant by this? I would like to point out that, for example, the mechanisms in with-hip draft does not require global deployment of HIP-enabled operating systems or anything like that; the with-hip mechanisms can be embedded to the P2PSIP applications. -- Jani _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 29 11:38:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmOr-0008Ld-I5; Thu, 29 Nov 2007 11:38:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmOp-0008Hw-7C for p2psip@ietf.org; Thu, 29 Nov 2007 11:38:03 -0500 Received: from chip2og55.obsmtp.com ([64.18.13.47]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxmOo-0002uD-Pb for p2psip@ietf.org; Thu, 29 Nov 2007 11:38:03 -0500 Received: from source ([192.150.11.134]) by chip2ob55.postini.com ([64.18.5.12]) with SMTP; Thu, 29 Nov 2007 08:37:53 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lATGZYOP002998; Thu, 29 Nov 2007 08:35:34 -0800 (PST) Received: from apacmail.pac.adobe.com (apacmail.pac.adobe.com [130.248.36.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lATGatFt002326; Thu, 29 Nov 2007 08:37:41 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by apacmail.pac.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 01:37:37 +0900 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] Agenda for the upcoming meeting in Vancouver (existentialist topics) Date: Thu, 29 Nov 2007 08:37:19 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE363@namail5.corp.adobe.com> In-Reply-To: <474EA5DB.4010201@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] Agenda for the upcoming meeting in Vancouver (existentialist topics) Thread-Index: AcgyfNEmaCCzuifkSaWBl3a2NYFtHwAJ+fcg References: <4d4304a00711261846l57ef779ehee84781487742a76@mail.gmail.com><20071127220309.C632733C28@delta.rtfm.com><4d4304a00711271542v2927bc9fvbd7c26c6c6be645f@mail.gmail.com><20071127234233.79EEF33C28@delta.rtfm.com> <4d4304a00711280559v9a5cce2r56d1f7d63e2e79de@mail.gmail.com> <24CCCC428EFEA2469BF046DB3C7A8D223AE35A@namail5.corp.adobe.com> <474EA5DB.4010201@ericsson.com> From: "Henry Sinnreich" To: "Jani Hautakorpi (JO/LMF)" X-OriginalArrivalTime: 29 Nov 2007 16:37:37.0260 (UTC) FILETIME=[268A0AC0:01C832A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Jani, Thanks for note! >the with-hip mechanisms can be embedded=20 >to the P2PSIP applications. This means that on the laptop I am currently using there would be two = TCP/IP stacks: 1. The native TCP/IP stack of the existing OS (WinXP in my case), 2. A 2nd TCP stack in the P2PSIP application. While this would work, I = am wondering about the performance and ease of integrating with WinXP = (in my example). 3. I would need to duplicate the expertise put in the existing TCP/IP = stack that has taken years to develop to where it is now. 4. Don't residential routers and other network elements have to = understand HIP? My apology for the possibly na=EFve questions. Can you provide some comfort for the above concerns? Henry -----Original Message----- From: Jani Hautakorpi (JO/LMF) [mailto:jani.hautakorpi@ericsson.com]=20 Sent: Thursday, November 29, 2007 5:43 AM To: Henry Sinnreich Cc: David A. Bryan; Eric Rescorla; P2PSIP Mailing List Subject: Re: [P2PSIP] Agenda for the upcoming meeting in Vancouver = (existentialist topics) Hi Henry, Henry Sinnreich wrote: > Both David and EKR make some very good arguments, though I believe the > central theme should be the existentialist topics for P2PSIP and have > changed the subject title accordingly. Here are some examples: >=20 > ... >=20 > 2.2. Solutions based on HIP and other NG Internet technologies. >=20 > What is the risk assessment they may actually happen and when? I didn't quite understand this question. Could you clarify what you=20 meant by this? I would like to point out that, for example, the mechanisms in with-hip=20 draft does not require global deployment of HIP-enabled operating=20 systems or anything like that; the with-hip mechanisms can be embedded=20 to the P2PSIP applications. --=20 Jani _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Thu Nov 29 13:12:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnsT-0006zs-DC; Thu, 29 Nov 2007 13:12:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxnsS-0006wA-1v for p2psip@ietf.org; Thu, 29 Nov 2007 13:12:44 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxnsQ-0002Xy-Js for p2psip@ietf.org; Thu, 29 Nov 2007 13:12:43 -0500 Received: from localhost (atlas1.office [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 21D492800034F; Thu, 29 Nov 2007 19:12:42 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxLcJORiOnli; Thu, 29 Nov 2007 19:12:42 +0100 (CET) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0148728000302; Thu, 29 Nov 2007 19:12:32 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 Date: Thu, 29 Nov 2007 19:12:22 +0100 Message-ID: <113091BD57179D4491C19DA7E10CD6960193E18E@mx1.office> In-Reply-To: <7FD57509-6FA9-4B4C-92D7-B7437BC00B0F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 Thread-Index: AcguBaeGO0nEjuWfTP6XwbgPqW2BxgEpT6Qg References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office> <20071120151620.D1F2533C21@delta.rtfm.com> <4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com> <4d4304a00711210649o7d305e7dh9dc3e399920532f5@mail.gmail.com> <113091BD57179D4491C19DA7E10CD6960193DC24@mx1.office> <7FD57509-6FA9-4B4C-92D7-B7437BC00B0F@cisco.com> From: "Jan Seedorf" To: "Cullen Jennings" X-Spam-Score: 3.0 (+++) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: P2PSIP WG X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dear Cullen, > I think you are getting at we need replication to be possible=20 > at both the DHT and Application layer. I probably agree with=20 > you. One of the reasons I think we need this as the=20 > application layer is on only it can updated with a new signed=20 > copy that obsoletes any prior data because it is=20 > authoritative source for the information. On the other hand,=20 > we need it in the DHT because when the peer that runs the=20 > storing application is offline, we need the information to=20 > continue to persist in the DHT as peers storing the data churn. Yes, that was my point. There are good reasons for either layer to have = replication handled by it. - Jan > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: Friday, November 23, 2007 8:18 PM > To: Jan Seedorf > Cc: P2PSIP WG > Subject: Replication - Was Re: [P2PSIP] Merge of ASP and=20 > RELOAD - Version Notification fordraft-bryan-p2psip-reload-02 >=20 >=20 > Hi Jan, >=20 > I think you are getting at we need replication to be possible=20 > at both the DHT and Application layer. I probably agree with=20 > you. One of the reasons I think we need this as the=20 > application layer is on only it can updated with a new signed=20 > copy that obsoletes any prior data because it is=20 > authoritative source for the information. On the other hand,=20 > we need it in the DHT because when the peer that runs the=20 > storing application is offline, we need the information to=20 > continue to persist in the DHT as peers storing the data churn. >=20 > On a side note, I think the WG agreed to have a plug-able=20 > type of DHT scheme but I still think we need to specify some.=20 > Unless we specify some, I don't see how we can build=20 > interoperable systems. >=20 > Cullen >=20 > On Nov 22, 2007, at 7:15 AM, Jan Seedorf wrote: >=20 > > Dear David, Bruce, and Salman, > > > > a couple of thought on this: > > -- any mechanism on the DHT layer would not prohibit the=20 > application=20 > > layer to conduct additional replication (as David points out below) > > -- it may also depend on what layer you have mechanisms to detect=20 > > adversary nodes (to intentionally not replicate at=20 > adversary nodes).=20 > > If this is done at the DHT layer (e.g., by using density=20 > checks of the=20 > > successor list) this information could be passed on to the=20 > application=20 > > layer. If you detect adversary nodes at the application=20 > layer (e.g.,=20 > > through timeouts or by cryptographic verification of the=20 > content they=20 > > provide), only the application layer can use this information for=20 > > replication. > > > > I thought the WG had decided not to focus on a particular DHT but=20 > > rather make P2PSIP use pluggable DHTs. Any mechanism on the=20 > DHT layer=20 > > is very DHT-protocol specific. Does that not imply that=20 > replication on=20 > > that layer is out of the scope of the WG? > > > > Salman: I think the point raised by David in his other mail was not=20 > > _whether_ an operator should ensure that replicas survive node=20 > > failures but how this can be done if the source is responsible for=20 > > replication (rather a research issue) > > > > - Jan > > > >> -----Original Message----- > >> From: amelampus@gmail.com [mailto:amelampus@gmail.com] On=20 > Behalf Of=20 > >> David A. Bryan > >> Sent: Wednesday, November 21, 2007 3:50 PM > >> To: Salman Abdul Baset > >> Cc: Eric Rescorla; p2psip@lists.ietf.org; Jan Seedorf > >> Subject: Re: [P2PSIP] Merge of ASP and RELOAD - Version=20 > Notification=20 > >> fordraft-bryan-p2psip-reload-02 > >> > >> Sort of related to this discussion is the open question of=20 > what layer=20 > >> does replication occur? There are several alternatives: > >> > >> * Do it on a per-pluggable DHT level. In otherwords, each=20 > DHT that is=20 > >> defined specifies a replication mechanism. This may be=20 > very desirable=20 > >> if someone has a very clever DHT design with a specific=20 > replication=20 > >> scheme, but might remove operator flexibility and make it=20 > difficult=20 > >> for specific applications to have alternate schemes (although they=20 > >> could layer it on top of the DHT provided scheme) > >> > >> * Do it at the application level instead. Each usage=20 > specifies what=20 > >> replication it would like (how many, where, do you do source node=20 > >> replication if the source node fails, > >> etc.) The advantage to this is that it can be much more=20 > tailored for=20 > >> the use of the application, but if one overlay is=20 > supporting multiple=20 > >> usages, then things stored in common to each usage (maybe=20 > the user's=20 > >> public key, for example, which different applications may=20 > want) could=20 > >> conceivably be replicated in more places than really=20 > needed. It also=20 > >> means a clever DHT replication idea isn't as useful, since there=20 > >> would still be replication above it at the app level=20 > anyway (although=20 > >> I guess you could just turn off the application level=20 > replication in=20 > >> that case anyway) > >> > >> * There might be other options... > >> > >> This is definitely a good open issue...I'd love to see a bit of=20 > >> discussion about what others think the pros and cons are here... > >> > >> --David (as individual) > >> > >> On Nov 20, 2007 6:43 PM, Salman Abdul Baset=20 > =20 > >> wrote: > >>> As pointed, the replication mechanisms can be classified as: > >>> > >>> 1) Publisher (source) oriented > >>> 2) Responsible peer (root node) oriented > >>> > >>> Both publisher and responsible nodes can determine the=20 > node replica=20 > >>> set, i.e., the list of nodes on which to replicate. In=20 > addition to=20 > >>> security, factors such as churn rate, uptime and load of a > >> node also > >>> impact the choice of replica set. > >>> > >>> An artifact of using DHTs is that the publisher and > >> responsible peers > >>> are generally different. Since nodes churn, the responsible > >> peer may change. > >>> In an unstructured (non-DHT) overlay, the publisher node > >> will likely > >>> be responsible for determining the replica set. > >>> > >>> The question of how many replicas to maintain is best left to the=20 > >>> overlay operator. As mentioned above, the number of > >> replicas depends > >>> on the churn rate, availability guarantees, and security > >> among others. > >>> > >>> The question whether to maintain replicas after source node > >> fails is > >>> best left to the overlay operator. > >>> > >>> -salman > >>> > >>> > >>> On Tue, 20 Nov 2007, David A. Bryan wrote: > >>> > >>>> One problem with having the just the source place the=20 > replicas is=20 > >>>> what happens when the source is offline. > >>>> > >>>> For example, I am the source. I send out the data to the=20 > original=20 > >>>> and the replica. Then log off. > >>>> > >>>> If one peer fails, then that replica is gone for good > >> unless I come > >>>> back up to refresh them, so over time, offline information could=20 > >>>> "decay" in the presence of a slow peer failure rate. > >>>> > >>>> Some sort of hybrid might make more sense...but there is > >> (clearly) a > >>>> security point that needs to be considered here. > >>>> > >>>> David (as individual) > >>>> > >>>> > >>>> On Nov 20, 2007 10:16 AM, Eric Rescorla > >> wrote: > >>>>> At Tue, 20 Nov 2007 14:57:28 +0100, Jan Seedorf wrote: > >>>>>> Dear authors of the new RELOAD draft (02), I have some > >> comments on > >>>>>> the security section: > >>>>>> > >>>>>> section 7.3. it is specified that the root-node of > >> some resource > >>>>>> ID (i.e., the node responsible for storing the resource) is=20 > >>>>>> responsible for replication. In section 10.5.4. > >> "residual attacks" > >>>>>> you mention that a query node can check at replica > >> roots for some > >>>>>> resource if the root-node does not respond. I see the > >> following > >>>>>> security problem: if the root-node is originally faulty > >> at storage > >>>>>> time (e.g., compromised), it will likely store invalid (though > >>>>>> detectable) or no resources at all at the replica > >> roots. As you > >>>>>> well describe the only issue here is availability. However, I=20 > >>>>>> think that any countermeasure involving replication > >> must involve > >>>>>> distributed storage done by the query node itself (for reasons=20 > >>>>>> described above). Replication should not be the > >> responsibility of > >>>>>> the root-node. > >>>>> > >>>>> Yeah, this is sort of a thinko in our writeup. We intend > >> to move to > >>>>> explicit writes to each replica by the storing node and=20 > just ran=20 > >>>>> out of pre-draft time :) > >>>>> > >>>>> > >>>>>> Section 10.6.1.: You assume a central authority and=20 > indeed this=20 > >>>>>> solves many security problems. It limits Sybil attacks > >> and Eclipse > >>>>>> attacks. This is well-described in the draft. However, > >> there are > >>>>>> other attacks on DHT routing. Join-leave attacks can=20 > be used by=20 > >>>>>> the attacker to chose its location in the DHT despite=20 > a central=20 > >>>>>> node-ID assignment authority (see C. Scheideler, "How=20 > to Spread=20 > >>>>>> Adversarial Nodes?: Rotate!," Proc. 37th Annual ACM > >> Symp. Theory > >>>>>> of Comp., Baltimore, MD,pp. 704-13, for a formal > >> analysis of the > >>>>>> node-ID assignment problem in DHTs and join-leave attacks). > >>>>>> Additionally, even if there are no Sybil or Eclipse attacks,=20 > >>>>>> adversary nodes (though well certified through the admission=20 > >>>>>> authority, e.g., because they have been compromised)=20 > can simply=20 > >>>>>> drop messages. This severely degrades the lookup > >> success rate in a > >>>>>> DHT. Countermeasures against these attacks may well be=20 > >>>>>> out-of-scope for P2PSIP standardisation, I just feel > >> the section > >>>>>> is misleading in the sense that it suggests that a central=20 > >>>>>> authority protects against all threats on DHT routing. > >>>>> > >>>>> I agree tha there are significant residual attacks. We'll see=20 > >>>>> whwat we can do to make this text clearer. IF you wanted > >> to suggest > >>>>> some text that would be great. > >>>>> > >>>>> Thanks, > >>>>> -Ekr > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> P2PSIP mailing list > >>>>> P2PSIP@ietf.org > >>>>> https://www1.ietf.org/mailman/listinfo/p2psip > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> David A. Bryan > >>>> dbryan@SIPeerior.com > >>>> +1.757.565.0101 x101 > >>>> +1.757.565.0088 (fax) > >>>> www.SIPeerior.com > >>>> > >>>> _______________________________________________ > >>>> P2PSIP mailing list > >>>> P2PSIP@ietf.org > >>>> https://www1.ietf.org/mailman/listinfo/p2psip > >>>> > >>> > >> > >> > >> > >> -- > >> David A. Bryan > >> dbryan@SIPeerior.com > >> +1.757.565.0101 x101 > >> +1.757.565.0088 (fax) > >> www.SIPeerior.com > >> > > > > _______________________________________________ > > P2PSIP mailing list > > P2PSIP@ietf.org > > https://www1.ietf.org/mailman/listinfo/p2psip >=20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 30 01:48:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixzfv-00011p-4H; Fri, 30 Nov 2007 01:48:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixzft-00011a-Ej for p2psip@ietf.org; Fri, 30 Nov 2007 01:48:33 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixzfs-00080H-PP for p2psip@ietf.org; Fri, 30 Nov 2007 01:48:33 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSB0052E47OQU@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 30 Nov 2007 14:47:48 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JSB00E1K47OFT@szxga03-in.huawei.com> for p2psip@ietf.org; Fri, 30 Nov 2007 14:47:48 +0800 (CST) Received: from s64081a ([10.164.5.62]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JSB00BFF47NFZ@szxml04-in.huawei.com> for p2psip@ietf.org; Fri, 30 Nov 2007 14:47:48 +0800 (CST) Date: Fri, 30 Nov 2007 14:47:47 +0800 From: Song Yongchao Subject: RE: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD - VersionNotification fordraft-bryan-p2psip-reload-02 In-reply-to: <113091BD57179D4491C19DA7E10CD6960193E18E@mx1.office> To: 'Jan Seedorf' , 'Cullen Jennings' Message-id: <000c01c8331c$eb5c6160$3e05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcguBaeGO0nEjuWfTP6XwbgPqW2BxgEpT6QgABu5VCA= X-Spam-Score: 1.2 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: 'P2PSIP WG' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org > -----Original Message----- > From: Jan Seedorf [mailto:Jan.Seedorf@nw.neclab.eu] > Sent: Friday, November 30, 2007 2:12 AM > To: Cullen Jennings > Dear Cullen, > > > I think you are getting at we need replication to be possible > > at both the DHT and Application layer. I probably agree with > > you. One of the reasons I think we need this as the > > application layer is on only it can updated with a new signed > > copy that obsoletes any prior data because it is > > authoritative source for the information. On the other hand, > > we need it in the DHT because when the peer that runs the > > storing application is offline, we need the information to > > continue to persist in the DHT as peers storing the data churn. > > Yes, that was my point. There are good reasons for either layer to have > replication handled by it. > > - Jan That was also my point. Replication handled by either layer, or either the source peer or the responsible peer, has its pros and cons. However, for the peer protocol, should only take the replication handled by distributed storage layer into account, either by the source peer or the responsible peer. For the availability when the source peer is offline, I prefer the responsible peer to do it. Of course, whether or not to replicate in the overlay is left to the decision of the overlay operator. _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 30 03:45:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy1VN-0007vD-45; Fri, 30 Nov 2007 03:45:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy1VL-0007v3-OU for p2psip@ietf.org; Fri, 30 Nov 2007 03:45:47 -0500 Received: from pontius.teigre.com ([213.225.78.155]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy1VL-0002ue-8Q for p2psip@ietf.org; Fri, 30 Nov 2007 03:45:47 -0500 X-ClientAddr: 213.145.160.17 Received: from [127.0.0.1] (213-145-160-17.dd.nextgentel.com [213.145.160.17]) by pontius.teigre.com (8.13.8/8.13.8) with ESMTP id lAU8jjtf008339; Fri, 30 Nov 2007 09:45:45 +0100 Message-ID: <474FCDB6.3070506@teigre.com> Date: Fri, 30 Nov 2007 09:45:42 +0100 From: "Greger V. Teigre" User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Barrett Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver References: In-Reply-To: X-teigre.com-MailScanner-Information: Please contact the ISP for more information X-teigre.com-MailScanner: Found to be clean X-teigre.com-MailScanner-From: greger@teigre.com X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: 'Philip Matthews' , 'P2PSIP Mailing List' X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0912872754==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0912872754== Content-Type: multipart/alternative; boundary="------------090307050402030209000009" This is a multi-part message in MIME format. --------------090307050402030209000009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To ICE testing, the only data I have seen are from pjsip and only anecdotal. Cut from blog entry: http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and-turn/ "I've tried with running two pjsua's behind the same NAT that doesn't do hairpin, and the local address pair is used. And trying two pjsua's behind different NATs, the public address pair is used. So it looks like it's working! More over, I've been testing it since last week, and quite few bugs have been found and fixed. And negotiation is pretty quick, around 100 ms with two endpoints on different ADSL line, even though the SDP answer was delayed in the proxy (ICE is able to start the checks early even when SDP answer hasn't been received by caller). But one of the major difficulties with testing ICE these days is practically there is no other freely available ICE implementation out there (I mean, ICE-14/15 compliant ones), so although ICE implementation in PJNATH does seem to work, and it follows ICE-15 closely, we couldn't be sure that it is compliant until it talks with other implementation. So if any of you know one, please do let me know!" The implementation is documented here: http://www.pjsip.org/pjnath/docs/html/index.htm The library was recently updated to the latest updates. I haven't seen any larger scale testing yet. g-) David Barrett wrote: >> -----Original Message----- >> From: Philip Matthews [mailto:philip_matthews@magma.ca] >> Subject: [P2PSIP] NAT Traversal Discussion in Vancouver >> >> 2) The very-low-level NAT Traversal approach is ICE, and I don't see >> anyone questioning that. I don't think a discussion of this is worth >> precious meeting time. >> > > Though it needn't be a topic of discussion, can you ask the attendees if > anybody has some real-world performance and reliability data on ICE that > they can share? I don't think any has been published to date, but perhaps > new data has come out since our last requests. > > Indeed, if anybody has this data (or can get it), this would be an excellent > time to share it. Specifically, I'm curious to know how long it typically > takes to set up a particular connection, and with what probability it can > establish a direct connection between two arbitrary peers on the internet. > ("Connection setup" and "peer connectivity") > > Thanks! > > -david > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > > > --------------090307050402030209000009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit To ICE testing, the only data I have seen are from pjsip and only anecdotal.
Cut from blog entry: http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and-turn/

"I’ve tried with running two pjsua’s behind the same NAT that doesn’t do hairpin, and the local address pair is used. And trying two pjsua’s behind different NATs, the public address pair is used. So it looks like it’s working!
More over, I’ve been testing it since last week, and quite few bugs have been found and fixed. And negotiation is pretty quick, around 100 ms with two endpoints on different ADSL line, even though the SDP answer was delayed in the proxy (ICE is able to start the checks early even when SDP answer hasn’t been received by caller).
But one of the major difficulties with testing ICE these days is practically there is no other freely available ICE implementation out there (I mean, ICE-14/15 compliant ones), so although ICE implementation in PJNATH does seem to work, and it follows ICE-15 closely, we couldn’t be sure that it is compliant until it talks with other implementation. So if any of you know one, please do let me know!"

The implementation is documented here: http://www.pjsip.org/pjnath/docs/html/index.htm

The library was recently updated to the latest updates. I haven't seen any larger scale testing yet.
g-)

David Barrett wrote: 
-----Original Message-----
From: Philip Matthews [mailto:philip_matthews@magma.ca]
Subject: [P2PSIP] NAT Traversal Discussion in Vancouver

2) The very-low-level NAT Traversal approach is ICE, and I don't see
anyone questioning that. I don't think a discussion of this is worth
precious meeting time.
    

Though it needn't be a topic of discussion, can you ask the attendees if
anybody has some real-world performance and reliability data on ICE that
they can share?  I don't think any has been published to date, but perhaps
new data has come out since our last requests.

Indeed, if anybody has this data (or can get it), this would be an excellent
time to share it.  Specifically, I'm curious to know how long it typically
takes to set up a particular connection, and with what probability it can
establish a direct connection between two arbitrary peers on the internet.
("Connection setup" and "peer connectivity")

Thanks!

-david


_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip
--------------090307050402030209000009-- --===============0912872754== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0912872754==-- From p2psip-bounces@ietf.org Fri Nov 30 09:43:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy75p-0007SN-0M; Fri, 30 Nov 2007 09:43:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy75m-0007Rl-Rz for p2psip@ietf.org; Fri, 30 Nov 2007 09:43:46 -0500 Received: from exprod6og53.obsmtp.com ([64.18.1.187]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy75m-0001bZ-5e for p2psip@ietf.org; Fri, 30 Nov 2007 09:43:46 -0500 Received: from source ([192.150.20.142]) by exprod6ob53.postini.com ([64.18.5.12]) with SMTP; Fri, 30 Nov 2007 06:43:18 PST Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAUEh8hb013390; Fri, 30 Nov 2007 06:43:13 -0800 (PST) Received: from fe1.corp.adobe.com (fe1.corp.adobe.com [10.8.192.70]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAUEh7RC000480; Fri, 30 Nov 2007 06:43:07 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe1.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 06:43:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 30 Nov 2007 06:43:02 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE369@namail5.corp.adobe.com> In-Reply-To: <474FCDB6.3070506@teigre.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: plan B for NAT traversal for P2PSIP Thread-Index: AcgzLXDkjd9Z6ksqSN2Owyj4JCJJiAALg68g References: <474FCDB6.3070506@teigre.com> From: "Henry Sinnreich" To: "Greger V. Teigre" , "David Barrett" X-OriginalArrivalTime: 30 Nov 2007 14:43:07.0178 (UTC) FILETIME=[521078A0:01C8335F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 81ca0cebdb446e1ff4e2b634791f24a9 Cc: Philip Matthews , P2PSIP Mailing List Subject: [P2PSIP] plan B for NAT traversal for P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1602835375==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============1602835375== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8335F.515EC755" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8335F.515EC755 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable (I changed the Subject header) =20 Greger, =20 You have given us a valuable pointer to ICE NAT traversal at=20 http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun -and-turn/ where the implementer says: So Does It Work?=20 Yes! (or, erm.. I think so!) The point is that if ICE does not work satisfactory, there must be a plan B for NAT traversal for P2PSIP.=20 Remember the WG assumption that most endpoints will be behind several levels of NAT. We also want 100% success ratio as well as low call setup delay. =20 One plan B is the model to just use an "openDHT-like overlay" as a service.=20 Endpoints behind NAT may just work using one of several pre-provisioned or discovered STUN/TURN servers, after which all the p2p happens as in the openDHT. I believe ICE has a much better chance as well when two endpoints have to just connect to the DHT. http://www.sigcomm.org/sigcomm2005/paper-RheGod.pdf=20 =20 Incidentally, the paper also shows the excellent security properties of this approach when using the overlay in data mode. Look at Table1. =20 I understand there are P2P SIP demos working exactly this way. =20 There is no time to discuss plan B next week in the WG meeting, but don't exclude the possibility it may happen sometimes later. =20 Henry =20 ________________________________ From: Greger V. Teigre [mailto:greger@teigre.com]=20 Sent: Friday, November 30, 2007 2:46 AM To: David Barrett Cc: 'Philip Matthews'; 'P2PSIP Mailing List' Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver =20 To ICE testing, the only data I have seen are from pjsip and only anecdotal.=20 Cut from blog entry: http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun -and-turn/ "I've tried with running two pjsua's behind the same NAT that doesn't do hairpin, and the local address pair is used. And trying two pjsua's behind different NATs, the public address pair is used. So it looks like it's working! More over, I've been testing it since last week, and quite few bugs have been found and fixed. And negotiation is pretty quick, around 100 ms with two endpoints on different ADSL line, even though the SDP answer was delayed in the proxy (ICE is able to start the checks early even when SDP answer hasn't been received by caller). But one of the major difficulties with testing ICE these days is practically there is no other freely available ICE implementation out there (I mean, ICE-14/15 compliant ones), so although ICE implementation in PJNATH does seem to work, and it follows ICE-15 closely, we couldn't be sure that it is compliant until it talks with other implementation. So if any of you know one, please do let me know!" The implementation is documented here: http://www.pjsip.org/pjnath/docs/html/index.htm The library was recently updated to the latest updates. I haven't seen any larger scale testing yet.=20 g-) David Barrett wrote:=20 -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Subject: [P2PSIP] NAT Traversal Discussion in Vancouver =20 2) The very-low-level NAT Traversal approach is ICE, and I don't see anyone questioning that. I don't think a discussion of this is worth precious meeting time. =20 =20 Though it needn't be a topic of discussion, can you ask the attendees if anybody has some real-world performance and reliability data on ICE that they can share? I don't think any has been published to date, but perhaps new data has come out since our last requests. =20 Indeed, if anybody has this data (or can get it), this would be an excellent time to share it. Specifically, I'm curious to know how long it typically takes to set up a particular connection, and with what probability it can establish a direct connection between two arbitrary peers on the internet. ("Connection setup" and "peer connectivity") =20 Thanks! =20 -david =20 =20 _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip =20 =20 =20 ------_=_NextPart_001_01C8335F.515EC755 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

(I changed the Subject = header)

 

Greger,

=

 

You have given us a valuable = pointer to ICE NAT traversal at

http://blog.pjsip.org/2007/04/06/introducing-pjnath-op= en-source-ice-stun-and-turn/ where the implementer says:

So Does It Work? =

Yes! (or, erm.. I think so!)

The point is = that if ICE does not work satisfactory, there must be a plan B for NAT = traversal for P2PSIP.

Remember the WG assumption that most endpoints will be behind several levels of = NAT.

We also want = 100% success ratio as well as low call setup delay.

 =

One plan B is = the model to just use an “openDHT-like overlay” as a service.

Endpoints behind NAT may just work = using one of several pre-provisioned or discovered STUN/TURN servers, after = which all the p2p happens as in the openDHT. I believe ICE has a much better = chance as well when two endpoints have to just connect to the = DHT.

http://www.s= igcomm.org/sigcomm2005/paper-RheGod.pdf

 

Incidentally, the paper also shows = the excellent security properties of this approach when using the overlay in = data mode. Look at Table1.

 

I understand there are P2P SIP = demos working exactly this way.

 

There is no time to discuss plan B = next week in the WG meeting, but don’t exclude the possibility it may = happen sometimes later.

 

Henry

 

From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Friday, November = 30, 2007 2:46 AM
To: David Barrett
Cc: 'Philip Matthews'; 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver

 

To ICE testing, the only data I have seen are = from pjsip and only anecdotal.
Cut from blog entry: http://blog.pjsip.org/2007/04/06/introducing-pjnath-op= en-source-ice-stun-and-turn/

"I’ve tried with running two pjsua’s behind the same = NAT that doesn’t do hairpin, and the local address pair is used. And trying = two pjsua’s behind different NATs, the public address pair is used. So = it looks like it’s working!
More over, I’ve been testing it since last week, and quite few = bugs have been found and fixed. And negotiation is pretty quick, around 100 ms = with two endpoints on different ADSL line, even though the SDP answer was delayed = in the proxy (ICE is able to start the checks early even when SDP answer = hasn’t been received by caller).
But one of the major difficulties with testing ICE these days is = practically there is no other freely available ICE implementation out there (I mean, ICE-14/15 compliant ones), so although ICE implementation in PJNATH does = seem to work, and it follows ICE-15 closely, we couldn’t be sure that = it is compliant until it talks with other implementation. So if any of you = know one, please do let me know!"

The implementation is documented here: http://www.pjsip= .org/pjnath/docs/html/index.htm

The library was recently updated to the latest updates. I haven't seen = any larger scale testing yet.
g-)

David Barrett wrote: = 

-----Original =
Message-----
From: Philip Matthews [mailto:philip_matthews@magma.ca<=
/a>]
Subject: [P2PSIP] NAT Traversal Discussion in =
Vancouver
 
2) The very-low-level NAT Traversal approach =
is ICE, and I don't see
anyone questioning that. I don't think a =
discussion of this is worth
precious meeting =
time.
    =

 
Though it needn't be a topic of discussion, =
can you ask the attendees if
anybody has some real-world performance and =
reliability data on ICE that
they can share?  I don't think any has =
been published to date, but =
perhaps
new data has come out since our last =
requests.
 
Indeed, if anybody has this data (or can get =
it), this would be an excellent
time to share it.  Specifically, I'm =
curious to know how long it =
typically
takes to set up a particular connection, and =
with what probability it can
establish a direct connection between two =
arbitrary peers on the =
internet.
("Connection setup" and "peer =
connectivity")
 
Thanks!
 
-david
 
 
______________________________________________=
_
P2PSIP mailing =
list
P2PSIP@ietf.org
https://www1.ietf.=
org/mailman/listinfo/p2psip
 
 
 
------_=_NextPart_001_01C8335F.515EC755-- --===============1602835375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1602835375==-- From p2psip-bounces@ietf.org Fri Nov 30 16:24:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDLG-0000di-FS; Fri, 30 Nov 2007 16:24:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDLF-0000Zc-8U for p2psip@ietf.org; Fri, 30 Nov 2007 16:24:09 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyDLD-0006of-CG for p2psip@ietf.org; Fri, 30 Nov 2007 16:24:09 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lAULMuGk021079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 Nov 2007 15:22:58 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] More thoughts on clients, peers, and services, and service routing Date: Fri, 30 Nov 2007 15:22:48 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 23, 2007, at 1:08 PM, Cullen Jennings wrote: > On Nov 21, 2007, at 2:03 PM, Dean Willis wrote: >> One way to divide the problem space is to differentiate the tasks >> of "finding", "routing", and "everything else". >> >> Several people have proposed that peers exclusively provide >> "finding and routing" services. Clients use the "finding and >> routing" services of peers. Both clients and peers can also offer >> other services, such as STUN relay (although some might say that >> peers offering other services are acting as clients when they do >> so). I think this model works fairly well, and it continues in >> the principle that peers are a superset of clients -- that is, >> that clients and peers are pretty much similar, but peers do a few >> things that clients can't. For each service that a client or peer >> provides, that node would "put" a service entry in to the >> database, and these services are completely distinct from the >> nodes role as peer or client >> >> >> Is this the only way to divide the problem? Maybe clients and >> peers are very different things, neither subsets nor supersets of >> each other. >> >> What if peers deal exclusively with "finding", and we think of >> message routing as a separate service entirely? >> > > Dean, I have read this 3 times now and I can't figure it out in the > slightest. Can you relate this is a concrete way to what would > need to be changed on any of the draft proposed solutions. That > might help me understand. I'm also very confused if "finding" has > to do with peers doing storage or with peers doing routing or > something else all together. "Finding" is the old "SIP location service problem" -- given a SIP URI (or perhaps a resource identifier), how do we know where to send SIP requests to in order to establish a multimedia session? Clearly "clients" ask some other nodes ("peers"?) for this information. "Routing" is the old SIP "proxy" function -- it happens when nodes accept requests that are not targeted to themselves, and pass them along to other nodes that may either be the target or closer to the target. Some models of P2PSIP distinguish the two functions, others conflate them, and others provide only one function. For example, assume we have a model where a client (alice) wishes to send a message to Bob (sip:bob@example.com). So Alice asks (a "get" operation) a peer "Please give me the node ID at which I can reach sip:bob@example.com" (or perhaps she first hashes said string into a resource ID). The peer tells her "sip:bob@example.com can be reached at node 0xA14578AB18EDF5". So then Alice asks the peer for routing, saying "Send this message (or connect me) to node 0xA14578AB18EDF5". In this model, we have both "finding" and "routing", and they are discrete operations (note that "routing" may mean passing discrete messages, or it might establish a tunnel between the nodes -- that's another issue). Another model (as proposed by Henry), Alice would simply get "the Contact: for sip@bob@example.com" and would receive "sip:bob@128.194.18.1". Alice would then connect using SIP to 128.194.18.1 and send an INVITE request. Here we have "finding", but no "routing" being provided by the P2P layer. In yet another model, Alice would start by saying "Send this message to sip:bob@example.com". The peer would then (possibly after resolving the target it to a node ID, or perhaps just by following next-hop pointer) forward the request on. This model conflates "finding" and "routing" -- that is, there is no "get", only "send". The important distinction here is that there is some service or set of services (such as "finding" and/or "routing") being provided by the peers that are not being provided by the clients, and that there is some functionality other than that provided by SIP happening between the clients and the peers. For example, a SIP client certainly wouldn't know how to hash a resource name like "sip:bob@example.com" into a resource ID. A P2PSIP client might or might not know how to do this, depending on the exact model. We seem to be converging on a model where the overlay itself offers both finding and routing, with both occurring along the connectivity graph of a DHT. I'm suggesting that this may not be the only viable model, and that we might get different results if we used the DHT only for the "finding" operations, and use some other mechanism (as yet undefined) for the "routing" operations. In fact, it might be possible to have "routing" as a service that is completely apart from the DHT, perhaps by clients, or perhaps by nodes that aren't even aware of the DHT. One might "find" a nearby routing node, then use some other mechanism to send the SIP request through that routing node (and perhaps other routing nodes) to the target. Here's an example. Alice still wants to call Bob. Alice does a "get" on sip:bob@example.com, and receives a route- vector like ", , . Alice then sends an INVITE using this route- vector as a preloaded Route: header field. In this example, all the message-passing work is done at the SIP level. What the P2P overlay did was 1) establish a reachability graph between the proxies participating in the overlay, and 2) calculate an efficient path through that reachability graph to the target. Does that help explain my pondering? This leads me to also wonder about what may be another functional split: "routing" as we have used it above conflates both the determination of a path and the forwarding of a message. It doesn't have to, as my last example shows. The mechanism used to find the path between two nodes does not necessarily transfer a message between those two nodes. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 30 17:17:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEAS-0003gJ-PK; Fri, 30 Nov 2007 17:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEAR-0003fv-LK for p2psip@ietf.org; Fri, 30 Nov 2007 17:17:03 -0500 Received: from chip2og52.obsmtp.com ([64.18.13.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyEAQ-00063m-Ld for p2psip@ietf.org; Fri, 30 Nov 2007 17:17:03 -0500 Received: from source ([192.150.11.134]) by chip2ob52.postini.com ([64.18.5.12]) with SMTP; Fri, 30 Nov 2007 14:16:55 PST Received: from inner-relay-3.eur.adobe.com (inner-relay-3.adobe.com [192.150.20.198] (may be forged)) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id lAUMEaOP000342; Fri, 30 Nov 2007 14:14:40 -0800 (PST) Received: from fe2.corp.adobe.com (fe2.corp.adobe.com [10.8.192.72]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id lAUMGhFV000068; Fri, 30 Nov 2007 14:16:44 -0800 (PST) Received: from namail5.corp.adobe.com ([10.8.192.88]) by fe2.corp.adobe.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 14:16:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [P2PSIP] More thoughts on clients, peers, and services, and service routing Date: Fri, 30 Nov 2007 14:16:35 -0800 Message-ID: <24CCCC428EFEA2469BF046DB3C7A8D223AE36D@namail5.corp.adobe.com> In-Reply-To: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [P2PSIP] More thoughts on clients, peers, and services, and service routing Thread-Index: Acgzl2W89wbjQUZHRj6TNAqSiuzgxwABbmiA References: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com> From: "Henry Sinnreich" To: "Dean Willis" , "Cullen Jennings" X-OriginalArrivalTime: 30 Nov 2007 22:16:43.0567 (UTC) FILETIME=[B04BDBF0:01C8339E] X-Spam-Score: -4.0 (----) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org >"finding", "routing", and "everything else" Dean and Cullen make excellent points, though what do we put "Under everything else"? There are also all kind of system design items, such as in Bamboo that must be accomplished in the real world: Modules * Router: routing-table, leaf-set, cache. Iterative + recursive,=20 * Messages: join-request/response, leaf-set-changed, routing-table-request, ping-request, neighbor-announce, ... * DHT: put, get, remove. Fairness for disk quota * Gateway: for clients to use the service * Data manager: replication of stored data on leaf set * DB: high-performance, embedded database library from Berkeley * Network: congestion controlled UDP * Async event architecture * ReDiR: client side library for the service interface Soft-state: Failures and smart timeouts for neighbor recovery Proximity neighbor selection for various metrics: * Latency * Routing hops * Bandwidth ...etc., ... I have borrowed these items from a paper by Kundan Singh. Henry -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Friday, November 30, 2007 3:23 PM To: Cullen Jennings Cc: P2PSIP Mailing List Subject: Re: [P2PSIP] More thoughts on clients, peers, and services,and service routing On Nov 23, 2007, at 1:08 PM, Cullen Jennings wrote: > On Nov 21, 2007, at 2:03 PM, Dean Willis wrote: >> One way to divide the problem space is to differentiate the tasks =20 >> of "finding", "routing", and "everything else". >> >> Several people have proposed that peers exclusively provide =20 >> "finding and routing" services. Clients use the "finding and =20 >> routing" services of peers. Both clients and peers can also offer =20 >> other services, such as STUN relay (although some might say that =20 >> peers offering other services are acting as clients when they do =20 >> so). I think this model works fairly well, and it continues in =20 >> the principle that peers are a superset of clients -- that is, =20 >> that clients and peers are pretty much similar, but peers do a few =20 >> things that clients can't. For each service that a client or peer =20 >> provides, that node would "put" a service entry in to the =20 >> database, and these services are completely distinct from the =20 >> nodes role as peer or client >> >> >> Is this the only way to divide the problem? Maybe clients and =20 >> peers are very different things, neither subsets nor supersets of =20 >> each other. >> >> What if peers deal exclusively with "finding", and we think of =20 >> message routing as a separate service entirely? >> > > Dean, I have read this 3 times now and I can't figure it out in the =20 > slightest. Can you relate this is a concrete way to what would =20 > need to be changed on any of the draft proposed solutions. That =20 > might help me understand. I'm also very confused if "finding" has =20 > to do with peers doing storage or with peers doing routing or =20 > something else all together. "Finding" is the old "SIP location service problem" -- given a SIP =20 URI (or perhaps a resource identifier), how do we know where to send =20 SIP requests to in order to establish a multimedia session? Clearly =20 "clients" ask some other nodes ("peers"?) for this information. "Routing" is the old SIP "proxy" function -- it happens when nodes =20 accept requests that are not targeted to themselves, and pass them =20 along to other nodes that may either be the target or closer to the =20 target. Some models of P2PSIP distinguish the two functions, others conflate =20 them, and others provide only one function. For example, assume we have a model where a client (alice) wishes to =20 send a message to Bob (sip:bob@example.com). So Alice asks (a "get" =20 operation) a peer "Please give me the node ID at which I can reach =20 sip:bob@example.com" (or perhaps she first hashes said string into a =20 resource ID). The peer tells her "sip:bob@example.com can be reached =20 at node 0xA14578AB18EDF5". So then Alice asks the peer for routing, =20 saying "Send this message (or connect me) to node 0xA14578AB18EDF5". =20 In this model, we have both "finding" and "routing", and they are =20 discrete operations (note that "routing" may mean passing discrete =20 messages, or it might establish a tunnel between the nodes -- that's =20 another issue). Another model (as proposed by Henry), Alice would simply get "the =20 Contact: for sip@bob@example.com" and would receive =20 "sip:bob@128.194.18.1". Alice would then connect using SIP to =20 128.194.18.1 and send an INVITE request. Here we have "finding", but =20 no "routing" being provided by the P2P layer. In yet another model, Alice would start by saying "Send this message =20 to sip:bob@example.com". The peer would then (possibly after =20 resolving the target it to a node ID, or perhaps just by following =20 next-hop pointer) forward the request on. This model conflates =20 "finding" and "routing" -- that is, there is no "get", only "send". The important distinction here is that there is some service or set =20 of services (such as "finding" and/or "routing") being provided by =20 the peers that are not being provided by the clients, and that there =20 is some functionality other than that provided by SIP happening =20 between the clients and the peers. For example, a SIP client =20 certainly wouldn't know how to hash a resource name like =20 "sip:bob@example.com" into a resource ID. A P2PSIP client might or =20 might not know how to do this, depending on the exact model. We seem to be converging on a model where the overlay itself offers =20 both finding and routing, with both occurring along the connectivity =20 graph of a DHT. I'm suggesting that this may not be the only viable =20 model, and that we might get different results if we used the DHT =20 only for the "finding" operations, and use some other mechanism (as =20 yet undefined) for the "routing" operations. In fact, it might be =20 possible to have "routing" as a service that is completely apart from =20 the DHT, perhaps by clients, or perhaps by nodes that aren't even =20 aware of the DHT. One might "find" a nearby routing node, then use =20 some other mechanism to send the SIP request through that routing =20 node (and perhaps other routing nodes) to the target. Here's an example. Alice still wants to call Bob. Alice does a "get" on sip:bob@example.com, and receives a route-=20 vector like ", , =20 . Alice then sends an INVITE using this route-=20 vector as a preloaded Route: header field. In this example, all the message-passing work is done at the SIP =20 level. What the P2P overlay did was 1) establish a reachability graph =20 between the proxies participating in the overlay, and 2) calculate an =20 efficient path through that reachability graph to the target. Does that help explain my pondering? This leads me to also wonder about what may be another functional =20 split: "routing" as we have used it above conflates both the =20 determination of a path and the forwarding of a message. It doesn't =20 have to, as my last example shows. The mechanism used to find the =20 path between two nodes does not necessarily transfer a message =20 between those two nodes. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 30 18:00:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEqp-00028R-71; Fri, 30 Nov 2007 18:00:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEqn-00028E-8r for p2psip@ietf.org; Fri, 30 Nov 2007 18:00:49 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyEqm-0008N5-Cr for p2psip@ietf.org; Fri, 30 Nov 2007 18:00:49 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 30 Nov 2007 18:00:47 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAUN0mmm002852; Fri, 30 Nov 2007 18:00:48 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAUN0VBi009908; Fri, 30 Nov 2007 23:00:43 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 18:00:43 -0500 Received: from [161.44.174.179] ([161.44.174.179]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 18:00:42 -0500 Message-ID: <47509618.7060001@cisco.com> Date: Fri, 30 Nov 2007 18:00:40 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Dean Willis Subject: Re: [P2PSIP] More thoughts on clients, peers, and services, and service routing References: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com> In-Reply-To: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Nov 2007 23:00:42.0697 (UTC) FILETIME=[D5572390:01C833A4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6794; t=1196463648; x=1197327648; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[P2PSIP]=20More=20thoughts=20on=20clients, =20peers, =2 0and=20services,=09and=20service=0A=20routing |Sender:=20 |To:=20Dean=20Willis=20; bh=JQdp8+QMMWMxbsx8IhXi+Mu7tbNOKUktqwNUyFMdfO0=; b=oaBoSmvnX0LFbkjMe2hae9Z8TG0yuuV6TmVBF8zoorT/p/JxQGT+43mz+2vrLF0qCC+CBZSE RHD4uZQFm4WkIfEx7S377Id6bz5JdpM4UR/JlxikKkCVzOowDJNetpfa; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Dean, Very interesting stuff you wrote below. A related question: in a regular sip network, UAs often "hide behind" a proxy - the proxy acts as a screening device. It also acts as a policy agent for selecting which of possibly several UAs for the AOR gets a call. (It may also do callerprefs but typically callee policy takes precedence.) Is any of this behavior in scope for P2PSIP? Is it part of the finding function, the routing function, or some new function? Thanks, Paul Dean Willis wrote: > > On Nov 23, 2007, at 1:08 PM, Cullen Jennings wrote: >> On Nov 21, 2007, at 2:03 PM, Dean Willis wrote: >>> One way to divide the problem space is to differentiate the tasks of >>> "finding", "routing", and "everything else". >>> >>> Several people have proposed that peers exclusively provide "finding >>> and routing" services. Clients use the "finding and routing" services >>> of peers. Both clients and peers can also offer other services, such >>> as STUN relay (although some might say that peers offering other >>> services are acting as clients when they do so). I think this model >>> works fairly well, and it continues in the principle that peers are a >>> superset of clients -- that is, that clients and peers are pretty >>> much similar, but peers do a few things that clients can't. For each >>> service that a client or peer provides, that node would "put" a >>> service entry in to the database, and these services are completely >>> distinct from the nodes role as peer or client >>> >>> >>> Is this the only way to divide the problem? Maybe clients and peers >>> are very different things, neither subsets nor supersets of each other. >>> >>> What if peers deal exclusively with "finding", and we think of >>> message routing as a separate service entirely? >>> >> >> Dean, I have read this 3 times now and I can't figure it out in the >> slightest. Can you relate this is a concrete way to what would need >> to be changed on any of the draft proposed solutions. That might help >> me understand. I'm also very confused if "finding" has to do with >> peers doing storage or with peers doing routing or something else all >> together. > > "Finding" is the old "SIP location service problem" -- given a SIP URI > (or perhaps a resource identifier), how do we know where to send SIP > requests to in order to establish a multimedia session? Clearly > "clients" ask some other nodes ("peers"?) for this information. > > "Routing" is the old SIP "proxy" function -- it happens when nodes > accept requests that are not targeted to themselves, and pass them along > to other nodes that may either be the target or closer to the target. > > Some models of P2PSIP distinguish the two functions, others conflate > them, and others provide only one function. > > For example, assume we have a model where a client (alice) wishes to > send a message to Bob (sip:bob@example.com). So Alice asks (a "get" > operation) a peer "Please give me the node ID at which I can reach > sip:bob@example.com" (or perhaps she first hashes said string into a > resource ID). The peer tells her "sip:bob@example.com can be reached at > node 0xA14578AB18EDF5". So then Alice asks the peer for routing, saying > "Send this message (or connect me) to node 0xA14578AB18EDF5". In this > model, we have both "finding" and "routing", and they are discrete > operations (note that "routing" may mean passing discrete messages, or > it might establish a tunnel between the nodes -- that's another issue). > > Another model (as proposed by Henry), Alice would simply get "the > Contact: for sip@bob@example.com" and would receive > "sip:bob@128.194.18.1". Alice would then connect using SIP to > 128.194.18.1 and send an INVITE request. Here we have "finding", but no > "routing" being provided by the P2P layer. > > In yet another model, Alice would start by saying "Send this message to > sip:bob@example.com". The peer would then (possibly after resolving the > target it to a node ID, or perhaps just by following next-hop pointer) > forward the request on. This model conflates "finding" and "routing" -- > that is, there is no "get", only "send". > > The important distinction here is that there is some service or set of > services (such as "finding" and/or "routing") being provided by the > peers that are not being provided by the clients, and that there is some > functionality other than that provided by SIP happening between the > clients and the peers. For example, a SIP client certainly wouldn't know > how to hash a resource name like "sip:bob@example.com" into a resource > ID. A P2PSIP client might or might not know how to do this, depending on > the exact model. > > We seem to be converging on a model where the overlay itself offers both > finding and routing, with both occurring along the connectivity graph of > a DHT. I'm suggesting that this may not be the only viable model, and > that we might get different results if we used the DHT only for the > "finding" operations, and use some other mechanism (as yet undefined) > for the "routing" operations. In fact, it might be possible to have > "routing" as a service that is completely apart from the DHT, perhaps by > clients, or perhaps by nodes that aren't even aware of the DHT. One > might "find" a nearby routing node, then use some other mechanism to > send the SIP request through that routing node (and perhaps other > routing nodes) to the target. > > Here's an example. Alice still wants to call Bob. > > Alice does a "get" on sip:bob@example.com, and receives a route-vector > like ", , > . Alice then sends an INVITE using this > route-vector as a preloaded Route: header field. > > In this example, all the message-passing work is done at the SIP level. > What the P2P overlay did was 1) establish a reachability graph between > the proxies participating in the overlay, and 2) calculate an efficient > path through that reachability graph to the target. > > Does that help explain my pondering? > > This leads me to also wonder about what may be another functional split: > "routing" as we have used it above conflates both the determination of a > path and the forwarding of a message. It doesn't have to, as my last > example shows. The mechanism used to find the path between two nodes > does not necessarily transfer a message between those two nodes. > > -- > Dean > > > _______________________________________________ > P2PSIP mailing list > P2PSIP@ietf.org > https://www1.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 30 18:33:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFLv-00024E-R2; Fri, 30 Nov 2007 18:32:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFLu-00023i-9z for p2psip@ietf.org; Fri, 30 Nov 2007 18:32:58 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyFLt-0007YJ-U8 for p2psip@ietf.org; Fri, 30 Nov 2007 18:32:58 -0500 X-AuditID: c0a8013c-ac720bb000001e2e-8c-47509da8b385 Received: from s73602 (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 9A2D94DC008 for ; Fri, 30 Nov 2007 16:32:56 -0700 (MST) Message-ID: <1d5801c833a9$48ea3fa0$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: "P2PSIP Mailing List" References: <0399354B-38AB-4209-9E2B-48577299D1E2@magma.ca> Date: Fri, 30 Nov 2007 11:43:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 1.4 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [P2PSIP] Re: NAT Traversal Discussion in Vancouver X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Philip, > Folks: > > The chairs have asked me to lead a discussion of "NAT Traversal for P2P > Messages". What I would like to get is a solid idea of what people would > like to see discussed during this slot. > > As I see it, there are four parts to the whole P2PSIP NAT traversal > discussion: > > 1) The high-level NAT Traversal approach that most people seem to be > adopting is the idea of routing around the overlay to reach peers behind > NATs. As I understand it, that is going to be covered in the "Routing: > What does it look like?" discussion. As I see it, even the recent ideas > to include Relays would fall under that discussion. [Spencer: Do you > agree?] yes, I do, and I'm working on slides that cover this. Sorry for not responding sooner (you mean you CAN'T read my mind?). Spencer _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 30 18:33:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFLy-00026p-7J; Fri, 30 Nov 2007 18:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFLx-000252-6m for p2psip@ietf.org; Fri, 30 Nov 2007 18:33:01 -0500 Received: from mail.globalsuite.net ([69.46.103.200]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyFLv-0000Eo-O7 for p2psip@ietf.org; Fri, 30 Nov 2007 18:33:01 -0500 X-AuditID: c0a8013c-aef25bb000001e2e-8f-47509daa3fa8 Received: from s73602 (unknown [207.236.117.226]) by mail.globalsuite.net (Symantec Mail Security) with ESMTP id 5958D4DC008 for ; Fri, 30 Nov 2007 16:32:58 -0700 (MST) Message-ID: <1d5901c833a9$49863180$6501a8c0@china.huawei.com> From: "Spencer Dawkins" To: "P2PSIP WG" References: <113091BD57179D4491C19DA7E10CD6960193D92F@mx1.office><20071120151620.D1F2533C21@delta.rtfm.com><4d4304a00711200727oa17b125o839d9febef8058ca@mail.gmail.com><4d4304a00711210649o7d305e7dh9dc3e399920532f5@mail.gmail.com><113091BD57179D4491C19DA7E10CD6960193DC24@mx1.office> <7FD57509-6FA9-4B4C-92D7-B7437BC00B0F@cisco.com> Subject: Re: Replication - Was Re: [P2PSIP] Merge of ASP and RELOAD - VersionNotification fordraft-bryan-p2psip-reload-02 Date: Fri, 30 Nov 2007 12:06:38 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 2.6 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org Hi, Cullen, If I may disagree with your individual hat :-) It IS tempting to provide replication at both levels, but if we can avoid that, I'd like to avoid that. I'm concerned that we're headed for the situation where applications that care handle their own replication because they may end up running on overlays that don't provide replication, so the overlay replication only "adds value" for applications that don't handle replication because they don't care. I'm also concerned about debugging, especially with race conditions, but expect you are already thinking about that. Thanks, Spencer p.s. I'm also remembering a fairly funny conversation with Jonathan Sadler about how pleased he was with the high uptime he was seeing from an immature MPLS fast recovery implementation ... ... until he got suspicious and asked the SONET guys if they had disabled SONET-layer protection. They hadn't ("who would want SONET without protection?"), so the MPLS implementation had never seen a link failure in testing. No wonder it was so "reliable" ... > Hi Jan, > > I think you are getting at we need replication to be possible at both the > DHT and Application layer. I probably agree with you. One of the reasons > I think we need this as the application layer is on only it can updated > with a new signed copy that obsoletes any prior data because it is > authoritative source for the information. On the other hand, we need it > in the DHT because when the peer that runs the storing application is > offline, we need the information to continue to persist in the DHT as > peers storing the data churn. > > On a side note, I think the WG agreed to have a plug-able type of DHT > scheme but I still think we need to specify some. Unless we specify some, > I don't see how we can build interoperable systems. > > Cullen _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 30 19:28:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyGDx-0000k0-Nn; Fri, 30 Nov 2007 19:28:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyGDx-0000jn-6b for p2psip@ietf.org; Fri, 30 Nov 2007 19:28:49 -0500 Received: from quinthar.com ([64.62.221.66]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyGDw-0005bN-Ec for p2psip@ietf.org; Fri, 30 Nov 2007 19:28:49 -0500 Received: from lappy ([76.231.185.49]) by quinthar.com for ; Fri, 30 Nov 2007 16:28:40 -0800 From: "David Barrett" To: "'Henry Sinnreich'" , "'Greger V. Teigre'" Date: Fri, 30 Nov 2007 16:28:39 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcgzLXDkjd9Z6ksqSN2Owyj4JCJJiAALg68gABUacyA= In-Reply-To: <24CCCC428EFEA2469BF046DB3C7A8D223AE369@namail5.corp.adobe.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8d895f7c89fea7fff87709b22b67e77e Cc: 'Philip Matthews' , 'P2PSIP Mailing List' Subject: [P2PSIP] RE: plan B for NAT traversal for P2PSIP X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1240699124==" Errors-To: p2psip-bounces@ietf.org Message-Id: This is a multi-part message in MIME format. --===============1240699124== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01C8336E.11094B20" This is a multi-part message in MIME format. ------=_NextPart_000_0033_01C8336E.11094B20 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Are you suggesting that plan B is "don't attempt direct connections between NAT'd peers" and instead just to relay everything via the DHT? I think that's a good fallback plan if a direct connection can't be established. Incidentally, also I'd toss out plan C: create a new NAT penetration protocol that is "ICE-lite". Basically, refine the best elements of ICE/STUN/TURN into a new protocol that is simpler to implement and iteratively built in conjunction with real-world testing (rather than designed first, tested later). -david _____ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Friday, November 30, 2007 6:43 AM To: Greger V. Teigre; David Barrett Cc: Philip Matthews; P2PSIP Mailing List; bennylp@pjsip.org Subject: plan B for NAT traversal for P2PSIP (I changed the Subject header) Greger, You have given us a valuable pointer to ICE NAT traversal at http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and -turn/ where the implementer says: So Does It Work? Yes! (or, erm.. I think so!) The point is that if ICE does not work satisfactory, there must be a plan B for NAT traversal for P2PSIP. Remember the WG assumption that most endpoints will be behind several levels of NAT. We also want 100% success ratio as well as low call setup delay. One plan B is the model to just use an "openDHT-like overlay" as a service. Endpoints behind NAT may just work using one of several pre-provisioned or discovered STUN/TURN servers, after which all the p2p happens as in the openDHT. I believe ICE has a much better chance as well when two endpoints have to just connect to the DHT. http://www.sigcomm.org/sigcomm2005/paper-RheGod.pdf Incidentally, the paper also shows the excellent security properties of this approach when using the overlay in data mode. Look at Table1. I understand there are P2P SIP demos working exactly this way. There is no time to discuss plan B next week in the WG meeting, but don't exclude the possibility it may happen sometimes later. Henry _____ From: Greger V. Teigre [mailto:greger@teigre.com] Sent: Friday, November 30, 2007 2:46 AM To: David Barrett Cc: 'Philip Matthews'; 'P2PSIP Mailing List' Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver To ICE testing, the only data I have seen are from pjsip and only anecdotal. Cut from blog entry: http://blog.pjsip.org/2007/04/06/introducing-pjnath-open-source-ice-stun-and -turn/ "I've tried with running two pjsua's behind the same NAT that doesn't do hairpin, and the local address pair is used. And trying two pjsua's behind different NATs, the public address pair is used. So it looks like it's working! More over, I've been testing it since last week, and quite few bugs have been found and fixed. And negotiation is pretty quick, around 100 ms with two endpoints on different ADSL line, even though the SDP answer was delayed in the proxy (ICE is able to start the checks early even when SDP answer hasn't been received by caller). But one of the major difficulties with testing ICE these days is practically there is no other freely available ICE implementation out there (I mean, ICE-14/15 compliant ones), so although ICE implementation in PJNATH does seem to work, and it follows ICE-15 closely, we couldn't be sure that it is compliant until it talks with other implementation. So if any of you know one, please do let me know!" The implementation is documented here: http://www.pjsip.org/pjnath/docs/html/index.htm The library was recently updated to the latest updates. I haven't seen any larger scale testing yet. g-) David Barrett wrote: -----Original Message----- From: Philip Matthews [mailto:philip_matthews@magma.ca] Subject: [P2PSIP] NAT Traversal Discussion in Vancouver 2) The very-low-level NAT Traversal approach is ICE, and I don't see anyone questioning that. I don't think a discussion of this is worth precious meeting time. Though it needn't be a topic of discussion, can you ask the attendees if anybody has some real-world performance and reliability data on ICE that they can share? I don't think any has been published to date, but perhaps new data has come out since our last requests. Indeed, if anybody has this data (or can get it), this would be an excellent time to share it. Specifically, I'm curious to know how long it typically takes to set up a particular connection, and with what probability it can establish a direct connection between two arbitrary peers on the internet. ("Connection setup" and "peer connectivity") Thanks! -david _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip ------=_NextPart_000_0033_01C8336E.11094B20 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Are you suggesting that plan B is = “don’t attempt direct connections between NAT’d peers” and instead = just to relay everything via the DHT?  I think that’s a good fallback = plan if a direct connection can’t be established.  =

 

Incidentally, also I’d toss = out plan C: create a new NAT penetration protocol that is = “ICE-lite”.

 

Basically, refine the best elements = of ICE/STUN/TURN into a new protocol that is simpler to implement and iteratively built = in conjunction with real-world testing (rather than designed first, tested = later).

 

-david

 

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Friday, November = 30, 2007 6:43 AM
To: Greger V. Teigre; = David Barrett
Cc: Philip Matthews; = P2PSIP Mailing List; bennylp@pjsip.org
Subject: plan B for NAT = traversal for P2PSIP

 

(I changed the Subject = header)

 

Greger,

=

 

You have given us a valuable = pointer to ICE NAT traversal at

http://blog.pjsip.org/2007/04/06/introducing-pjnath-op= en-source-ice-stun-and-turn/ where the implementer says:

So Does It Work? =

Yes! (or, erm.. I think so!)

The point is = that if ICE does not work satisfactory, there must be a plan B for NAT = traversal for P2PSIP.

Remember the WG assumption that most endpoints will be behind several levels of = NAT.

We also want = 100% success ratio as well as low call setup delay.

 =

One plan B is = the model to just use an “openDHT-like overlay” as a service.

Endpoints behind NAT may just work = using one of several pre-provisioned or discovered STUN/TURN servers, after = which all the p2p happens as in the openDHT. I believe ICE has a much better = chance as well when two endpoints have to just connect to the = DHT.

http://www.s= igcomm.org/sigcomm2005/paper-RheGod.pdf

 

Incidentally, the paper also shows = the excellent security properties of this approach when using the overlay in = data mode. Look at Table1.

 

I understand there are P2P SIP = demos working exactly this way.

 

There is no time to discuss plan B = next week in the WG meeting, but don’t exclude the possibility it may = happen sometimes later.

 

Henry

 

From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: Friday, November = 30, 2007 2:46 AM
To: David Barrett
Cc: 'Philip Matthews'; 'P2PSIP Mailing List'
Subject: Re: [P2PSIP] NAT Traversal Discussion in Vancouver

 

To ICE testing, the only data I have seen are = from pjsip and only anecdotal.
Cut from blog entry: http://blog.pjsip.org/2007/04/06/introducing-pjnath-op= en-source-ice-stun-and-turn/

"I’ve tried with running two pjsua’s behind the same = NAT that doesn’t do hairpin, and the local address pair is used. And trying = two pjsua’s behind different NATs, the public address pair is used. So = it looks like it’s working!
More over, I’ve been testing it since last week, and quite few = bugs have been found and fixed. And negotiation is pretty quick, around 100 ms = with two endpoints on different ADSL line, even though the SDP answer was delayed = in the proxy (ICE is able to start the checks early even when SDP answer = hasn’t been received by caller).
But one of the major difficulties with testing ICE these days is = practically there is no other freely available ICE implementation out there (I mean, ICE-14/15 compliant ones), so although ICE implementation in PJNATH does = seem to work, and it follows ICE-15 closely, we couldn’t be sure that = it is compliant until it talks with other implementation. So if any of you = know one, please do let me know!"

The implementation is documented here: http://www.pjsip= .org/pjnath/docs/html/index.htm

The library was recently updated to the latest updates. I haven't seen = any larger scale testing yet.
g-)

David Barrett wrote: = 

-----Original =
Message-----
From: Philip Matthews [mailto:philip_matthews@magma.ca<=
/a>]
Subject: [P2PSIP] NAT Traversal Discussion in =
Vancouver
 
2) The very-low-level NAT Traversal approach =
is ICE, and I don't see
anyone questioning that. I don't think a =
discussion of this is worth
precious meeting =
time.
    =

 
Though it needn't be a topic of discussion, =
can you ask the attendees if
anybody has some real-world performance and =
reliability data on ICE that
they can share?  I don't think any has =
been published to date, but =
perhaps
new data has come out since our last =
requests.
 
Indeed, if anybody has this data (or can get =
it), this would be an excellent
time to share it.  Specifically, I'm =
curious to know how long it =
typically
takes to set up a particular connection, and =
with what probability it can
establish a direct connection between two =
arbitrary peers on the =
internet.
("Connection setup" and "peer =
connectivity")
 
Thanks!
 
-david
 
 
______________________________________________=
_
P2PSIP mailing =
list
P2PSIP@ietf.org
https://www1.ietf.=
org/mailman/listinfo/p2psip
 
 
 
------=_NextPart_000_0033_01C8336E.11094B20-- --===============1240699124== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============1240699124==-- From p2psip-bounces@ietf.org Fri Nov 30 20:18:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyH07-0004GL-NB; Fri, 30 Nov 2007 20:18:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyH05-0004FT-Ru for p2psip@ietf.org; Fri, 30 Nov 2007 20:18:33 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyH04-0002xU-3W for p2psip@ietf.org; Fri, 30 Nov 2007 20:18:33 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB11ISsF003558 for ; Sat, 1 Dec 2007 03:18:30 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 03:18:28 +0200 Received: from esebe102.NOE.Nokia.com ([172.21.138.217]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Dec 2007 03:18:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 1 Dec 2007 03:21:22 +0200 Message-ID: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Client discussion in Vancouver Thread-Index: AcgzuHuQE+bcMuT1QNyK9HOLLqxPpA== From: To: X-OriginalArrivalTime: 01 Dec 2007 01:18:29.0018 (UTC) FILETIME=[14739FA0:01C833B8] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Subject: [P2PSIP] Client discussion in Vancouver X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0089988881==" Errors-To: p2psip-bounces@ietf.org This is a multi-part message in MIME format. --===============0089988881== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C833B8.1434979F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C833B8.1434979F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Please see a draft version of the presentation about clients. Any comments appreciated! http://netlabathut.googlepages.com/Clients_02.ppt Marcin ------_=_NextPart_001_01C833B8.1434979F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Client discussion in Vancouver

Hi all,

Please see a draft version of the = presentation about clients. Any comments appreciated!
http://netlabathut.googlepages.com/Clients_02.ppt

Marcin

------_=_NextPart_001_01C833B8.1434979F-- --===============0089988881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip --===============0089988881==-- From p2psip-bounces@ietf.org Fri Nov 30 21:27:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyI4r-0006Rr-Da; Fri, 30 Nov 2007 21:27:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyI4q-0006RQ-7L for p2psip@ietf.org; Fri, 30 Nov 2007 21:27:32 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyI4p-00081C-Ia for p2psip@ietf.org; Fri, 30 Nov 2007 21:27:32 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lB12RPtT022801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 Nov 2007 20:27:26 -0600 In-Reply-To: <47509618.7060001@cisco.com> References: <93C7E361-0992-4D42-A4D9-D0379D763C5F@softarmor.com> <47509618.7060001@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4526A716-B185-4BD4-A428-B4BC5A5CEF71@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] More thoughts on clients, peers, and services, and service routing Date: Fri, 30 Nov 2007 20:27:16 -0600 To: Paul Kyzivat X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: P2PSIP Mailing List X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 30, 2007, at 5:00 PM, Paul Kyzivat wrote: > Dean, > > Very interesting stuff you wrote below. Thanks. I think "interesting" is a good adjective. Far more polite than "deranged", which probably came to mind for at least a few readers. > > A related question: > > in a regular sip network, UAs often "hide behind" a proxy - the > proxy acts as a screening device. It also acts as a policy agent > for selecting which of possibly several UAs for the AOR gets a > call. (It may also do callerprefs but typically callee policy takes > precedence.) > > Is any of this behavior in scope for P2PSIP? Is it part of the > finding function, the routing function, or some new function? > I've been pondering that question for some time. Either we lose much of the functionality built into SIP proxies (which includes what you list above along with, to my mind, the far more important function of hiding the UA's IP address unless proxy policy lets the request through), or we have to find a new way to provide those functions. I think this could take two forms, one novel, one conventional. In the conventional approach, the "peer" that would be found using a "get" on a AOR resource is a SIP proxy, and once it gets a SIP request, it applies the usual policy decisions before passing the request on to the end UA. This "passing on" could be done using conventional SIP, or it could be done using the overlay. What makes it work is the same sort of indirection that maps AOR to Contact to User. We'd just introduce an intermediary resource ID. In effect, Alice might insert her two phones "alice-1@example.com" and "alice-2@example.com" into the overlay, and her proxy peer might insert "alice@example.com" and be configured with a policy table that applies "contact routing" towards the phones. We can even think of using a SIP REGISTER request, routed over the overlay, to inform the proxy peer about the downstream bindings. Perhaps there is even a way to apply CPL in this sort of model. A more novel approach would be to put the traditional "proxy policy" functions into the overlay. One approach would be to have a "policy language", and for each AOR, put a policy resource into the overlay. Before sending a message, a peer would first do a "get" on the policy resource, then interpret the policy resource before dispatching the request. For example, the policy resource for "alice@example.com" might indicate that she's busy next week and all calls should be retargeted to "alice@voicemail.example.com". Alice's various devices (assuming she has more than one) might achieve the effect of SIP contact-registration by amending Alice's policy resource to add themselves to the policy. I think the current models rather naively assume "one AOR, one device" and that any policy enforcement can be done in the terminating device. There's probably an underlying assumption that any more complex policy gets handled by something analogous to a B2BUA, but I don't think it really has to work that way. Indeed, I expect to see all sorts of policy-driven indirection models working their way into the overlay once we get the basic functions sorted out. But that does raise the question of the system being more effective if we build these functions in up front. Here's a nifty use case: Let's say Alice only wants Bob and Charlie to be able to deduce her location from the overlay. The resource "alice@example.com" might, instead of returning a Contact, instead return only a policy object. That policy object might contain sections encrypted with Bob and Charlie's public keys. Each section, when decrypted, would provide a retargeting to an anonymous resource ID that Alice minted for temporary use. Bob "calls" alice, "getting" the resource record "alice@example.com", finds it to be a policy object that has a section keyed for him, decrypts it, finds that it contains instructions to retarget to another resource, does a "connect" on that resource, and is connected to Alice's phone. These are the kinds of things that can happen when we start thinking of the overlay as a distributed database, not just as a distributed proxy-registrar. -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip From p2psip-bounces@ietf.org Fri Nov 30 21:29:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyI7D-0003LD-9U; Fri, 30 Nov 2007 21:29:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyI7B-0003Kk-Aq for p2psip@ietf.org; Fri, 30 Nov 2007 21:29:57 -0500 Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyI79-00067o-4P for p2psip@ietf.org; Fri, 30 Nov 2007 21:29:57 -0500 Received: from [192.168.2.100] (cpe-76-185-142-113.tx.res.rr.com [76.185.142.113] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id lB12TrCI022820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 30 Nov 2007 20:29:54 -0600 In-Reply-To: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> References: <3F18E76823C95E4795181D74BAC7664F0581B3F5@esebe102.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [P2PSIP] Client discussion in Vancouver Date: Fri, 30 Nov 2007 20:29:45 -0600 To: "" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: p2psip@ietf.org X-BeenThere: p2psip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Peer-to-Peer SIP working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: p2psip-bounces@ietf.org On Nov 30, 2007, at 7:21 PM, wrote: > > Hi all, > > Please see a draft version of the presentation about clients. Any > comments appreciated! > http://netlabathut.googlepages.com/Clients_02.ppt > This still doesn't say a lot about what peers really do differently from clients. Perhaps it would be better expressed as a set of use cases? -- Dean _______________________________________________ P2PSIP mailing list P2PSIP@ietf.org https://www1.ietf.org/mailman/listinfo/p2psip