RE: [P2PSIP] Abusive and trustable peers and clients

"Henry Sinnreich" <hsinnrei@adobe.com> Mon, 19 November 2007 15:56 UTC

Return-path: <p2psip-bounces@ietf.org>
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 <hsinnrei@adobe.com>
To: Spencer Dawkins <spencer@mcsr-labs.org>, p2psip@lists.ietf.org
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 <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=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] 
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 
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

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