From melodysong@huawei.com Mon Apr 13 19:25:35 2009 Return-Path: X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA47928C102 for ; Mon, 13 Apr 2009 19:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.28 X-Spam-Level: X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[AWL=-0.715, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4BuIiXgoqQi for ; Mon, 13 Apr 2009 19:25:28 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 6608C3A6A9F for ; Mon, 13 Apr 2009 19:25:20 -0700 (PDT) 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 <0KI200M3UK3TZV@szxga03-in.huawei.com> for p2prg@ietf.org; Tue, 14 Apr 2009 10:26:18 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI200EP7K3TOH@szxga03-in.huawei.com> for p2prg@ietf.org; Tue, 14 Apr 2009 10:26:17 +0800 (CST) Received: from s64081 ([10.164.12.64]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI2009XHK3TV0@szxml06-in.huawei.com> for p2prg@ietf.org; Tue, 14 Apr 2009 10:26:17 +0800 (CST) Date: Tue, 14 Apr 2009 10:26:16 +0800 From: Song Haibin To: p2prg@ietf.org Message-id: <005e01c9bca8$63d60db0$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_AaqFRyzl998/Dhf++rQ5mg)" Thread-index: Acm8qGOXhxV88DRlRx2fKYIjs6EIPQ== Subject: [p2prg] Comments to draft-schulzrinne-p2prg-rtc-security-00 X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 02:25:35 -0000 This is a multi-part message in MIME format. --Boundary_(ID_AaqFRyzl998/Dhf++rQ5mg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, I have read this draft last week and found it a really interesting document to read. It is a good tutorial for real time application security in p2p environment. Here are some detailed comments after my reading. 1. In Section 1, paragraph 1, "P2P networks are now also being used for applications such as Voice over IP (VoIP) [SKYPE] [Singh] and television [JOOST] [COOLSTREAM]." [Haibin] As far as I know, Joost has just changed its basic P2P system architecture and turned to client/server architecture. It's better to remove this reference. 2. Section 2.1 Incentive of attacker [Haibin] I could give some additional common incentives of attackers. For example, some attacks are motivated by the business competition or for selling security products. E.g., I heard some firewall product companies usually attack some company's network, and tell them their network is not safe, so that they could sell them firewalls. Attacks due to competition are also common cases. These kinds of attacks may happen to p2p overlays. 3. In Section 2.2 "IP addresses are also an important resource for the attacker since in DHTs such as Chord [Stoica], the position in the overlay is determined by using a base hash function such as SHA-1 [SHA1]on the node's IP address" [Haibin] It is bad to determine a peer's ID using hash function on the node's IP address because IP address may change. But IP address is indeed an important resource for attackers, because it becomes hard for you to track a malicious node if it uses multiple IP addresses. And some authentication methods usually assign only one identity to a single IP address, an attacker with multiple IP addresses can get multiple identities for their attack. 4. I think the analysis in Section 4 is quite intersting and helpful, because many attacks are based on your position in the p2p overlay. 5. In Section 5.1.2, Reactive identification, "In a file-sharing application for example, after downloading content from a node, if the peer observes that data does not match its original query it can identify the corresponding node as malicious." [Haibin] It is hard to determine which node is the malicious node in this context. But at least this content in this node can be marked with "malicious", or this node can be marked with "suspicious". 6. In section 7 Peer-to-peer in realtime communication [Haibin] I agree that confidentiality is one of the most important issue. In file sharing, one does not care too much from whom the contents are downloaded, but in real time apps, one extraordinarily cares about whom he talks with. 7. In section 7.1.2 When to upgrade [Haibin] It lists some information to determine the peer load, e.g. number of clients attached, bandwidth usage for DHT maintenance, memory usage for DHT routing table. I hope p2psip diagnostics (draft-ietf-p2psip-diagnostics) mechanisms can be used to collect the listed corresponding information from the overlay. 8. In section 7.1.4 Incentives for clients, it is said "Peers could restrict the number or types of calls that they allow clients to make." [Haibin] It must be careful that giving this power to peers could bring denial of service attack against clients. 9. I think some black list or white list mechanism is quite interesting and helpful in P2P overlays, I am interested in the maintenance of a black/white list in p2p overlay, on how to establish it, how to access it, and how to update it, and the security about the black list itself. Best Regards, Haibin Skype: alexsonghw --Boundary_(ID_AaqFRyzl998/Dhf++rQ5mg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi,
 
I have read this draft last week and found it a really interesting document to read. It is a good tutorial for real time application security in p2p environment.
 
Here are some detailed comments after my reading.
 
1. In Section 1, paragraph 1, "P2P networks are now also being used for applications such as Voice over IP (VoIP) [SKYPE] [Singh] and television [JOOST] [COOLSTREAM]."
 
[Haibin] As far as I know, Joost has just changed its basic P2P system architecture and turned to client/server architecture. It’s better to remove this reference.
 
2. Section 2.1 Incentive of attacker
 
[Haibin]  I could give some additional common incentives of attackers. For example, some attacks are motivated by the business competition or for selling security products. E.g., I heard some firewall product companies usually attack some company’s network, and tell them their network is not safe, so that they could sell them firewalls. Attacks due to competition are also common cases. These kinds of attacks may happen to p2p overlays.
 
3. In Section 2.2 "IP addresses are also an important resource for the attacker since in DHTs such as Chord [Stoica], the position in the overlay is determined by using a base hash function such as SHA-1 [SHA1]on the node's IP address"
 
[Haibin] It is bad to determine a peer’s ID using hash function on the node’s IP address because IP address may change. But IP address is indeed an important resource for attackers, because it becomes hard for you to track a malicious node if it uses multiple IP addresses. And some authentication methods usually assign only one identity to a single IP address, an attacker with multiple IP addresses can get multiple identities for their attack.
 
4. I think the analysis in Section 4 is quite intersting and helpful, because many attacks are based on your position in the p2p overlay.
 
5. In Section 5.1.2, Reactive identification, "In a file-sharing application for example, after downloading content from a node, if the peer observes that data does not match its original query it can identify the corresponding node as malicious."
 
[Haibin] It is hard to determine which node is the malicious node in this context. But at least this content in this node can be marked with “malicious”, or this node can be marked with “suspicious”.
 
6. In section 7 Peer-to-peer in realtime communication
 
[Haibin] I agree that confidentiality is one of the most important issue. In file sharing, one does not care too much from whom the contents are downloaded, but in real time apps, one extraordinarily cares about whom he talks with.
 
7. In section 7.1.2 When to upgrade
 
[Haibin] It lists some information to determine the peer load, e.g. number of clients attached, bandwidth usage for DHT maintenance, memory usage for DHT routing table. I hope p2psip diagnostics (draft-ietf-p2psip-diagnostics) mechanisms can be used to collect the listed corresponding information from the overlay.
 
8. In section 7.1.4 Incentives for clients, it is said "Peers could restrict the number or types of calls that they allow clients to make."
 
[Haibin] It must be careful that giving this power to peers could bring denial of service attack against clients.
 
9. I think some black list or white list mechanism is quite interesting and helpful in P2P overlays, I am interested in the maintenance of a black/white list in p2p overlay, on how to establish it, how to access it, and how to update it, and the security about the black list itself.
 
Best Regards,
Haibin
Skype: alexsonghw


 
--Boundary_(ID_AaqFRyzl998/Dhf++rQ5mg)-- From enrico.marocco@telecomitalia.it Tue Apr 14 05:43:47 2009 Return-Path: X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F97828C0F2 for ; Tue, 14 Apr 2009 05:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.41 X-Spam-Level: X-Spam-Status: No, score=-0.41 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKriS4o2ILVw for ; Tue, 14 Apr 2009 05:43:46 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id DFF303A6DD7 for ; Tue, 14 Apr 2009 05:43:45 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 14 Apr 2009 14:44:29 +0200 Received: from [10.229.8.41] (10.229.8.41) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.358.0; Tue, 14 Apr 2009 14:44:28 +0200 Message-ID: <49E4852B.4030108@telecomitalia.it> Date: Tue, 14 Apr 2009 14:44:27 +0200 From: Enrico Marocco User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Song Haibin References: <005e01c9bca8$63d60db0$400ca40a@china.huawei.com> In-Reply-To: <005e01c9bca8$63d60db0$400ca40a@china.huawei.com> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000203090203020600020500" Cc: "p2prg@ietf.org" Subject: Re: [p2prg] Comments to draft-schulzrinne-p2prg-rtc-security-00 X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 12:43:47 -0000 --------------ms000203090203020600020500 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for an accurate review, Haibin, we'll integrate your comments in the next version of the draft. A few notes inline. Song Haibin wrote: > 1. In Section 1, paragraph 1, "P2P networks are now also being used for= > applications such as Voice over IP (VoIP) [SKYPE] [Singh] and televisio= n > [JOOST] [COOLSTREAM]." > =20 > [Haibin] As far as I know, Joost has just changed its basic P2P system > architecture and turned to client/server architecture. It=92s better to= > remove this reference. Yes, indeed, probably now PPLive is a better example of P2P systems for realtime content delivery. > 2. Section 2.1 Incentive of attacker > =20 > [Haibin] I could give some additional common incentives of attackers. > For example, some attacks are motivated by the business competition or > for selling security products. E.g., I heard some firewall product > companies usually attack some company=92s network, and tell them their > network is not safe, so that they could sell them firewalls. Attacks du= e > to competition are also common cases. These kinds of attacks may happen= > to p2p overlays. While it is arguably a real issue in C/S scenarios, I'm not sure who, in a P2P system, could be the target customer of such security solutions. Maybe you are thinking of sort of a hybrid model, but the case of some company selling a security product for an application distributed by another company doesn't seem much realistic. OTOH I agree that competition could be a real incentive. > 5. In Section 5.1.2, Reactive identification, "In a file-sharing > application for example, after downloading content from a node, if the > peer observes that data does not match its original query it can > identify the corresponding node as malicious." > =20 > [Haibin] It is hard to determine which node is the malicious node in > this context. But at least this content in this node can be marked with= > =93malicious=94, or this node can be marked with =93suspicious=94. Identification of malicious peers is actually a very complex topic, subject itself of many possible attacks. The example in section 5.1.2, surely over-simplistic, has the only intent to pass to the reader a quick image of the reactive approach, but it is of course far from a real solution. > 7. In section 7.1.2 When to upgrade > =20 > [Haibin] It lists some information to determine the peer load, e.g. > number of clients attached, bandwidth usage for DHT maintenance, memory= > usage for DHT routing table. I hope p2psip diagnostics > (draft-ietf-p2psip-diagnostics) mechanisms can be used to collect the > listed corresponding information from the overlay. At the time of writing the p2psip-diagnostics work was still very early, but I agree that now it would be worth referenced here. --=20 Ciao, Enrico --------------ms000203090203020600020500 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MTQxMjQ0MjdaMCMG CSqGSIb3DQEJBDEWBBSl45efij0wrGigrUGpnDmvx1AFxTBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBACBtWUJUFfZZ /6ADRE5KDILwLhV8Khweyq3Df5Vf94E2RdrUv1L4QpaZBpAYqSfOGJSPDfHAtd8ucMiZQe89 vU7xU0WKSSnr6twZuZC6UZyU41YttF9wjvWSBDW4vVfFIXlaB9wrguojC/3hpgoa8XU8Ft// q0xiYf8TLic3hn5DP8nL1PMCPup05pMPRgUDiUYLS4j3dWiEpokEpyRaaUx3yDABGfnjZTja a5rKl5pGxELm9jnFW7F0y4tACTvkB09Ceqa3Ij6WOq9CKunUEjHN8gHURuOQ70aEHQk/C3he eTQk5yPjejGuDtsEFqDifhYUcFDiU0JX/bC3d7kWFkoAAAAAAAA= --------------ms000203090203020600020500-- From melodysong@huawei.com Tue Apr 14 20:23:54 2009 Return-Path: X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEEB03A6C7F for ; Tue, 14 Apr 2009 20:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.457 X-Spam-Level: X-Spam-Status: No, score=-1.457 tagged_above=-999 required=5 tests=[AWL=1.142, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nx0z+D6ZVth for ; Tue, 14 Apr 2009 20:23:53 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 9F7D33A688A for ; Tue, 14 Apr 2009 20:23:53 -0700 (PDT) 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 <0KI400991HHQUV@szxga02-in.huawei.com> for p2prg@ietf.org; Wed, 15 Apr 2009 11:25:03 +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 <0KI400LDAHHQTA@szxga02-in.huawei.com> for p2prg@ietf.org; Wed, 15 Apr 2009 11:25:02 +0800 (CST) Received: from s64081 ([10.164.12.64]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI400MBPHHQYC@szxml04-in.huawei.com> for p2prg@ietf.org; Wed, 15 Apr 2009 11:25:02 +0800 (CST) Date: Wed, 15 Apr 2009 11:25:02 +0800 From: Song Haibin In-reply-to: <49E4852B.4030108@telecomitalia.it> To: 'Enrico Marocco' Message-id: <003b01c9bd79$c37ab0a0$400ca40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: Acm8/tGKGgW2FquRSgeyPEE+uReQBwAatGfg Cc: p2prg@ietf.org Subject: Re: [p2prg] Comments to draft-schulzrinne-p2prg-rtc-security-00 X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 03:23:54 -0000 Enrico, >-----Original Message----- >From: Enrico Marocco [mailto:enrico.marocco@telecomitalia.it] >Sent: Tuesday, April 14, 2009 8:44 PM >To: Song Haibin >Cc: p2prg@ietf.org >Subject: Re: [p2prg] Comments to >draft-schulzrinne-p2prg-rtc-security-00 > >Thanks for an accurate review, Haibin, we'll integrate your >comments in the next version of the draft. A few notes inline. > >Song Haibin wrote: >> 1. In Section 1, paragraph 1, "P2P networks are now also being used >> for applications such as Voice over IP (VoIP) [SKYPE] [Singh] and >> television [JOOST] [COOLSTREAM]." >> >> [Haibin] As far as I know, Joost has just changed its basic >P2P system >> architecture and turned to client/server architecture. It's >better to >> remove this reference. > >Yes, indeed, probably now PPLive is a better example of P2P >systems for realtime content delivery. > Good example. >> 2. Section 2.1 Incentive of attacker >> >> [Haibin] I could give some additional common incentives of >attackers. >> For example, some attacks are motivated by the business >competition or >> for selling security products. E.g., I heard some firewall product >> companies usually attack some company's network, and tell them their >> network is not safe, so that they could sell them firewalls. Attacks >> due to competition are also common cases. These kinds of attacks may >> happen to p2p overlays. > >While it is arguably a real issue in C/S scenarios, I'm not >sure who, in a P2P system, could be the target customer of >such security solutions. >Maybe you are thinking of sort of a hybrid model, but the case >of some company selling a security product for an application >distributed by another company doesn't seem much realistic. I guess any peers located in a victim company could be the target of such attack, if the p2p application is open on the internet. However, I don't have a real example at my hand for such attack incentive in p2p applications, but for c/s scenarios, google can give many good real examples. >OTOH I agree that competition could be a real incentive. > >> 5. In Section 5.1.2, Reactive identification, "In a file-sharing >> application for example, after downloading content from a >node, if the >> peer observes that data does not match its original query it can >> identify the corresponding node as malicious." >> >> [Haibin] It is hard to determine which node is the malicious node in >> this context. But at least this content in this node can be marked >> with "malicious", or this node can be marked with "suspicious". > >Identification of malicious peers is actually a very complex >topic, subject itself of many possible attacks. The example in >section 5.1.2, surely over-simplistic, has the only intent to >pass to the reader a quick image of the reactive approach, but >it is of course far from a real solution. > >> 7. In section 7.1.2 When to upgrade >> >> [Haibin] It lists some information to determine the peer load, e.g. >> number of clients attached, bandwidth usage for DHT maintenance, >> memory usage for DHT routing table. I hope p2psip diagnostics >> (draft-ietf-p2psip-diagnostics) mechanisms can be used to >collect the >> listed corresponding information from the overlay. > >At the time of writing the p2psip-diagnostics work was still >very early, but I agree that now it would be worth referenced here. I agree. BR Haibin >-- >Ciao, >Enrico > > From hsinnrei@adobe.com Wed Apr 15 06:30:30 2009 Return-Path: X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D847828C1C1 for ; Wed, 15 Apr 2009 06:30:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.048 X-Spam-Level: X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynZxYv+2AJgX for ; Wed, 15 Apr 2009 06:30:24 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by core3.amsl.com (Postfix) with ESMTP id 1191928C14C for ; Wed, 15 Apr 2009 06:30:24 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKSeXhso48Gldefx6LU4EnVj6KzwMKPlOG@postini.com; Wed, 15 Apr 2009 06:31:36 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n3FDPleM025931; Wed, 15 Apr 2009 06:25:47 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n3FDVPY3015581; Wed, 15 Apr 2009 06:31:27 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Wed, 15 Apr 2009 06:31:24 -0700 From: Henry Sinnreich To: Enrico Marocco , Song Haibin Date: Wed, 15 Apr 2009 06:31:23 -0700 Thread-Topic: [p2prg] Comments to draft-schulzrinne-p2prg-rtc-security-00 Thread-Index: Acm8/tQTjDE3Z/b4S5KXcyGEA3emYwAz6Pdr Message-ID: In-Reply-To: <49E4852B.4030108@telecomitalia.it> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C60B4BDBD2B2hsinnreiadobecom_" MIME-Version: 1.0 Cc: "p2prg@ietf.org" Subject: Re: [p2prg] Comments to draft-schulzrinne-p2prg-rtc-security-00 X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 13:30:30 -0000 --_000_C60B4BDBD2B2hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > [Haibin] As far as I know, Joost has just changed its basic P2P system > architecture and turned to client/server architecture. It's better to > remove this reference. There is still Bittorrent and several others. Henry On 4/14/09 7:44 AM, "Enrico Marocco" wrot= e: Thanks for an accurate review, Haibin, we'll integrate your comments in the next version of the draft. A few notes inline. Song Haibin wrote: > 1. In Section 1, paragraph 1, "P2P networks are now also being used for > applications such as Voice over IP (VoIP) [SKYPE] [Singh] and television > [JOOST] [COOLSTREAM]." > > [Haibin] As far as I know, Joost has just changed its basic P2P system > architecture and turned to client/server architecture. It's better to > remove this reference. Yes, indeed, probably now PPLive is a better example of P2P systems for realtime content delivery. > 2. Section 2.1 Incentive of attacker > > [Haibin] I could give some additional common incentives of attackers. > For example, some attacks are motivated by the business competition or > for selling security products. E.g., I heard some firewall product > companies usually attack some company's network, and tell them their > network is not safe, so that they could sell them firewalls. Attacks due > to competition are also common cases. These kinds of attacks may happen > to p2p overlays. While it is arguably a real issue in C/S scenarios, I'm not sure who, in a P2P system, could be the target customer of such security solutions. Maybe you are thinking of sort of a hybrid model, but the case of some company selling a security product for an application distributed by another company doesn't seem much realistic. OTOH I agree that competition could be a real incentive. > 5. In Section 5.1.2, Reactive identification, "In a file-sharing > application for example, after downloading content from a node, if the > peer observes that data does not match its original query it can > identify the corresponding node as malicious." > > [Haibin] It is hard to determine which node is the malicious node in > this context. But at least this content in this node can be marked with > "malicious", or this node can be marked with "suspicious". Identification of malicious peers is actually a very complex topic, subject itself of many possible attacks. The example in section 5.1.2, surely over-simplistic, has the only intent to pass to the reader a quick image of the reactive approach, but it is of course far from a real solution. > 7. In section 7.1.2 When to upgrade > > [Haibin] It lists some information to determine the peer load, e.g. > number of clients attached, bandwidth usage for DHT maintenance, memory > usage for DHT routing table. I hope p2psip diagnostics > (draft-ietf-p2psip-diagnostics) mechanisms can be used to collect the > listed corresponding information from the overlay. At the time of writing the p2psip-diagnostics work was still very early, but I agree that now it would be worth referenced here. -- Ciao, Enrico --_000_C60B4BDBD2B2hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [p2prg] Comments to draft-schulzrinne-p2prg-rtc-security-00</TIT= LE> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:= 14pt'>> [Haibin] As far as I know, Joost has just changed its basic P2P = system<BR> > architecture and turned to client/server architecture. It’s bett= er to<BR> > remove this reference.<BR> <BR> There is still Bittorrent and several others.<BR> <BR> Henry<BR> <BR> <BR> On 4/14/09 7:44 AM, "Enrico Marocco" <<a href=3D"enrico.marocc= o@telecomitalia.it">enrico.marocco@telecomitalia.it</a>> wrote:<BR> <BR> </SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"= ><SPAN STYLE=3D'font-size:14pt'>Thanks for an accurate review, Haibin, we'l= l integrate your comments in<BR> the next version of the draft. A few notes inline.<BR> <BR> Song Haibin wrote:<BR> > 1. In Section 1, paragraph 1, "P2P networks are now also being us= ed for<BR> > applications such as Voice over IP (VoIP) [SKYPE] [Singh] and televisi= on<BR> > [JOOST] [COOLSTREAM]."<BR> > <BR> > [Haibin] As far as I know, Joost has just changed its basic P2P system= <BR> > architecture and turned to client/server architecture. It’s bett= er to<BR> > remove this reference.<BR> <BR> Yes, indeed, probably now PPLive is a better example of P2P systems for<BR> realtime content delivery.<BR> <BR> > 2. Section 2.1 Incentive of attacker<BR> > <BR> > [Haibin]  I could give some additional common incentives of attac= kers.<BR> > For example, some attacks are motivated by the business competition or= <BR> > for selling security products. E.g., I heard some firewall product<BR> > companies usually attack some company’s network, and tell them t= heir<BR> > network is not safe, so that they could sell them firewalls. Attacks d= ue<BR> > to competition are also common cases. These kinds of attacks may happe= n<BR> > to p2p overlays.<BR> <BR> While it is arguably a real issue in C/S scenarios, I'm not sure who, in<BR= > a P2P system, could be the target customer of such security solutions.<BR> Maybe you are thinking of sort of a hybrid model, but the case of some<BR> company selling a security product for an application distributed by<BR> another company doesn't seem much realistic. OTOH I agree that<BR> competition could be a real incentive.<BR> <BR> > 5. In Section 5.1.2, Reactive identification, "In a file-sharing<= BR> > application for example, after downloading content from a node, if the= <BR> > peer observes that data does not match its original query it can<BR> > identify the corresponding node as malicious."<BR> > <BR> > [Haibin] It is hard to determine which node is the malicious node in<B= R> > this context. But at least this content in this node can be marked wit= h<BR> > “malicious”, or this node can be marked with “suspic= ious”.<BR> <BR> Identification of malicious peers is actually a very complex topic,<BR> subject itself of many possible attacks. The example in section 5.1.2,<BR> surely over-simplistic, has the only intent to pass to the reader a<BR> quick image of the reactive approach, but it is of course far from a<BR> real solution.<BR> <BR> > 7. In section 7.1.2 When to upgrade<BR> > <BR> > [Haibin] It lists some information to determine the peer load, e.g.<BR= > > number of clients attached, bandwidth usage for DHT maintenance, memor= y<BR> > usage for DHT routing table. I hope p2psip diagnostics<BR> > (draft-ietf-p2psip-diagnostics) mechanisms can be used to collect the<= BR> > listed corresponding information from the overlay.<BR> <BR> At the time of writing the p2psip-diagnostics work was still very early,<BR= > but I agree that now it would be worth referenced here.<BR> <BR> --<BR> Ciao,<BR> Enrico<BR> <BR> <BR> </SPAN></FONT></BLOCKQUOTE> </BODY> </HTML> --_000_C60B4BDBD2B2hsinnreiadobecom_-- From emil@sip-communicator.org Wed Apr 15 07:27:25 2009 Return-Path: <emil@sip-communicator.org> X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94B753A6E7C for <p2prg@core3.amsl.com>; Wed, 15 Apr 2009 07:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zb02WVDe2lnT for <p2prg@core3.amsl.com>; Wed, 15 Apr 2009 07:27:24 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 3416E3A694A for <p2prg@ietf.org>; Wed, 15 Apr 2009 07:27:24 -0700 (PDT) Received: by bwz17 with SMTP id 17so2935338bwz.37 for <p2prg@ietf.org>; Wed, 15 Apr 2009 07:28:35 -0700 (PDT) Received: by 10.204.97.204 with SMTP id m12mr278578bkn.22.1239805715495; Wed, 15 Apr 2009 07:28:35 -0700 (PDT) Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id z10sm8320986fka.18.2009.04.15.07.28.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 15 Apr 2009 07:28:34 -0700 (PDT) Sender: Emil Ivov <emil@sip-communicator.org> Message-ID: <49E5EF0F.2020708@sip-communicator.org> Date: Wed, 15 Apr 2009 16:28:31 +0200 From: Emil Ivov <emcho@sip-communicator.org> Organization: SIP Communicator User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Henry Sinnreich <hsinnrei@adobe.com> References: <C60B4BDB.D2B2%hsinnrei@adobe.com> In-Reply-To: <C60B4BDB.D2B2%hsinnrei@adobe.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "p2prg@ietf.org" <p2prg@ietf.org> Subject: Re: [p2prg] Comments to draft-schulzrinne-p2prg-rtc-security-00 X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group <p2prg.irtf.org> List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=unsubscribe> List-Archive: <http://www.irtf.org/mail-archive/web/p2prg> List-Post: <mailto:p2prg@irtf.org> List-Help: <mailto:p2prg-request@irtf.org?subject=help> List-Subscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=subscribe> X-List-Received-Date: Wed, 15 Apr 2009 14:27:25 -0000 Hey Henry, Henry Sinnreich wrote: >> [Haibin] As far as I know, Joost has just changed its basic P2P system= >> architecture and turned to client/server architecture. It=92s better t= o >> remove this reference. >=20 > There is still Bittorrent and several others. Indeed, but as we mention in the text the sentence is there only to show uses other than file sharing. We are not trying to provide an exhaustive enumeration. Cheers Emil >=20 > Henry >=20 >=20 > On 4/14/09 7:44 AM, "Enrico Marocco" <enrico.marocco@telecomitalia.it> > wrote: >=20 > Thanks for an accurate review, Haibin, we'll integrate your comment= s in > the next version of the draft. A few notes inline. >=20 > Song Haibin wrote: > > 1. In Section 1, paragraph 1, "P2P networks are now also being us= ed for > > applications such as Voice over IP (VoIP) [SKYPE] [Singh] and > television > > [JOOST] [COOLSTREAM]." > > > > [Haibin] As far as I know, Joost has just changed its basic P2P s= ystem > > architecture and turned to client/server architecture. It=92s bet= ter to > > remove this reference. >=20 > Yes, indeed, probably now PPLive is a better example of P2P systems= for > realtime content delivery. >=20 > > 2. Section 2.1 Incentive of attacker > > > > [Haibin] I could give some additional common incentives of attac= kers. > > For example, some attacks are motivated by the business competiti= on or > > for selling security products. E.g., I heard some firewall produc= t > > companies usually attack some company=92s network, and tell them = their > > network is not safe, so that they could sell them firewalls. > Attacks due > > to competition are also common cases. These kinds of attacks may = happen > > to p2p overlays. >=20 > While it is arguably a real issue in C/S scenarios, I'm not sure wh= o, in > a P2P system, could be the target customer of such security solutio= ns. > Maybe you are thinking of sort of a hybrid model, but the case of s= ome > company selling a security product for an application distributed b= y > another company doesn't seem much realistic. OTOH I agree that > competition could be a real incentive. >=20 > > 5. In Section 5.1.2, Reactive identification, "In a file-sharing > > application for example, after downloading content from a node, i= f the > > peer observes that data does not match its original query it can > > identify the corresponding node as malicious." > > > > [Haibin] It is hard to determine which node is the malicious node= in > > this context. But at least this content in this node can be marke= d with > > =93malicious=94, or this node can be marked with =93suspicious=94= =2E >=20 > Identification of malicious peers is actually a very complex topic,= > subject itself of many possible attacks. The example in section 5.1= =2E2, > surely over-simplistic, has the only intent to pass to the reader a= > quick image of the reactive approach, but it is of course far from = a > real solution. >=20 > > 7. In section 7.1.2 When to upgrade > > > > [Haibin] It lists some information to determine the peer load, e.= g. > > number of clients attached, bandwidth usage for DHT maintenance, = memory > > usage for DHT routing table. I hope p2psip diagnostics > > (draft-ietf-p2psip-diagnostics) mechanisms can be used to collect= the > > listed corresponding information from the overlay. >=20 > At the time of writing the p2psip-diagnostics work was still very e= arly, > but I agree that now it would be worth referenced here. >=20 > -- > Ciao, > Enrico >=20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > p2prg mailing list > p2prg@irtf.org > http://www.irtf.org/mailman/listinfo/p2prg From maselli@di.uniroma1.it Sat Apr 18 10:19:07 2009 Return-Path: <maselli@di.uniroma1.it> X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF1728C0CF for <p2prg@core3.amsl.com>; Sat, 18 Apr 2009 10:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.277 X-Spam-Level: X-Spam-Status: No, score=0.277 tagged_above=-999 required=5 tests=[AWL=-3.366, BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvLy8qzOzPDX for <p2prg@core3.amsl.com>; Sat, 18 Apr 2009 10:19:06 -0700 (PDT) Received: from mail2.di.uniroma1.it (mail2.di.uniroma1.it [151.100.17.20]) by core3.amsl.com (Postfix) with ESMTP id F08B93A6E3D for <p2prg@ietf.org>; Sat, 18 Apr 2009 10:19:05 -0700 (PDT) Received: from gate.di.uniroma1.it (gate.di.uniroma1.it [151.100.17.23]) by mail2.di.uniroma1.it (Postfix) with ESMTP id 763FF2E02A; Sat, 18 Apr 2009 19:24:39 +0200 (CEST) Received: from 79.36.20.17 (SquirrelMail authenticated user maselli) by gate.di.uniroma1.it with HTTP; Sat, 18 Apr 2009 19:07:32 +0200 (CEST) Message-ID: <1188.79.36.20.17.1240074452.squirrel@gate.di.uniroma1.it> Date: Sat, 18 Apr 2009 19:07:32 +0200 (CEST) From: "Gaia Maselli" <maselli@di.uniroma1.it> To: tcos-announce@tcos.org, p2prg@ietf.org, end2end-interest@postel.org User-Agent: SquirrelMail/1.4.13 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [p2prg] (no subject) X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group <p2prg.irtf.org> List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=unsubscribe> List-Archive: <http://www.irtf.org/mail-archive/web/p2prg> List-Post: <mailto:p2prg@irtf.org> List-Help: <mailto:p2prg-request@irtf.org?subject=help> List-Subscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=subscribe> X-List-Received-Date: Sat, 18 Apr 2009 17:19:07 -0000 (Apologies for cross posting.) === IEEE SECON 2009 Call for Posters and Demo http://www.ieee-secon.com/2009/ - Abstract submission due on: 4/20/2009 - Acceptance notification: May, 4, 2009 - Early registration due on: May 9, 2009 - Final abstract due on: May 9, 2009 IEEE SECON 2009 will include poster/demonstration sessions that shall provide a forum to present and discuss: works in progress, industry demonstrations of new applications and techniques, practical implementations, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. One of the key goals of this conference is to foster collaboration between industry and academia. Hence, participation of researchers/developers from industry and posters/demonstrations reporting joint work between industry and academia are especially encouraged. Submissions should be in the form of a proposal describing the main contributions of the poster/demo and the merits of the proposed ideas. If available, preliminary results can also be included. Proposals will be evaluated mainly based on their potential to stimulate interesting discussions, exchange of ideas and promote collaborations. Submissions should not be more than three pages (preferably IEEE conference format, 2-column) in length. Demonstration submissions should include the space requirements and/or any other equipment-specific requirements. The documents must contain the authors' names, affiliations, and contact information and the designated corresponding author. Accepted authors of posters/demos will have a space in the poster/demo session room to display their posters or exhibit their demos and describe their work in discussions with interested attendees. Moreover, the abstact of the accepted posters/demos will appear in IEEE Xplore. IEEE Communications Society policy states that all accepted IEEE SECON 2009 posters/demos require at least a one day registration. For authors co-authoring multiple posters/demos, a one day registration is valid for up to three presentations. In addition, there needs to be at least one person per poster/demo registered for one day by May 9, 2009 in order for the abstract to appear in IEEE Xplore. Please submit the proposal via EDAS at http://edas.info/7621. Any questions can be addressed to the Poster/Demo Co-Chairs, Antonio Capone (antonio.capone@polimi.it <mailto:antonio.capone@polimi.it>) and Suman Banerjee (suman@cs.wisc.edu <mailto:suman@cs.wisc.edu>). Antonio Capone and Suman Banerjee IEEE SECON 2009 Poster/Demo Co-Chairs From maselli@di.uniroma1.it Mon Apr 20 02:33:23 2009 Return-Path: <maselli@di.uniroma1.it> X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D2C28C10A for <p2prg@core3.amsl.com>; Mon, 20 Apr 2009 02:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.624 X-Spam-Level: X-Spam-Status: No, score=-1.624 tagged_above=-999 required=5 tests=[AWL=-0.905, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Xc66-zM7e6R for <p2prg@core3.amsl.com>; Mon, 20 Apr 2009 02:33:22 -0700 (PDT) Received: from mail2.di.uniroma1.it (mail2.di.uniroma1.it [151.100.17.20]) by core3.amsl.com (Postfix) with ESMTP id 3959C28C0E5 for <p2prg@ietf.org>; Mon, 20 Apr 2009 02:33:22 -0700 (PDT) Received: from [151.100.17.90] (maselli.di.uniroma1.it [151.100.17.90]) by mail2.di.uniroma1.it (Postfix) with ESMTP id B19682E03E; Mon, 20 Apr 2009 11:39:05 +0200 (CEST) Message-ID: <49EC41AB.6050400@di.uniroma1.it> Date: Mon, 20 Apr 2009 11:34:35 +0200 From: Gaia Maselli <maselli@di.uniroma1.it> User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: it, it-it, en-us, en MIME-Version: 1.0 To: mycolleagues@grid.lrg.ufsc.br, p2prg@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [p2prg] SECON Call for Posters and Demos: deadline extended X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: maselli@di.uniroma1.it List-Id: Peer-to-Peer Research Group <p2prg.irtf.org> List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=unsubscribe> List-Archive: <http://www.irtf.org/mail-archive/web/p2prg> List-Post: <mailto:p2prg@irtf.org> List-Help: <mailto:p2prg-request@irtf.org?subject=help> List-Subscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=subscribe> X-List-Received-Date: Mon, 20 Apr 2009 09:33:23 -0000 (Apologies for cross posting.) ---------------------------------- IEEE SECON 2009 Call for Posters and Demo http://www.ieee-secon.com/2009/ - Abstract submission due on: 4/24/2009 (EXTENDED) - Acceptance notification: May, 4, 2009 - Early registration due on: May 9, 2009 - Final abstract due on: May 9, 2009 IEEE SECON 2009 will include poster/demonstration sessions that shall provide a forum to present and discuss: works in progress, industry demonstrations of new applications and techniques, practical implementations, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. One of the key goals of this conference is to foster collaboration between industry and academia. Hence, participation of researchers/developers from industry and posters/demonstrations reporting joint work between industry and academia are especially encouraged. Submissions should be in the form of a proposal describing the main contributions of the poster/demo and the merits of the proposed ideas. If available, preliminary results can also be included. Proposals will be evaluated mainly based on their potential to stimulate interesting discussions, exchange of ideas and promote collaborations. Submissions should not be more than three pages (preferably IEEE conference format, 2-column) in length. Demonstration submissions should include the space requirements and/or any other equipment-specific requirements. The documents must contain the authors' names, affiliations, and contact information and the designated corresponding author. Accepted authors of posters/demos will have a space in the poster/demo session room to display their posters or exhibit their demos and describe their work in discussions with interested attendees. Moreover, the abstact of the accepted posters/demos will appear in IEEE Xplore. IEEE Communications Society policy states that all accepted IEEE SECON 2009 posters/demos require at least a one day registration. For authors co-authoring multiple posters/demos, a one day registration is valid for up to three presentations. In addition, there needs to be at least one person per poster/demo registered for one day by May 9, 2009 in order for the abstract to appear in IEEE Xplore. Please submit the proposal via EDAS at http://edas.info/newPaper.php?c=6795. Any questions can be addressed to Poster/Demo Co-Chairs Antonio Capone (antonio.capone@polimi.it) and Suman Banerjee (suman@cs.wisc.edu). Antonio Capone and Suman Banerjee IEEE SECON 2009 Poster/Demo Co-Chairs From sprevidi@cisco.com Mon Apr 20 02:43:48 2009 Return-Path: <sprevidi@cisco.com> X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 228CC3A6A42 for <p2prg@core3.amsl.com>; Mon, 20 Apr 2009 02:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWziG9R5GaIx for <p2prg@core3.amsl.com>; Mon, 20 Apr 2009 02:43:47 -0700 (PDT) Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119]) by core3.amsl.com (Postfix) with ESMTP id 31B5F3A68F6 for <p2prg@ietf.org>; Mon, 20 Apr 2009 02:43:47 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3K9j1m5004622 for <p2prg@ietf.org>; Mon, 20 Apr 2009 11:45:01 +0200 (CEST) Received: from [192.168.0.100] (ams3-vpn-dhcp2703.cisco.com [10.61.74.143]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n3K9j0KC022863; Mon, 20 Apr 2009 11:45:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <299C8B09-6AD4-4D43-A533-777211BECD5A@cisco.com> Content-Transfer-Encoding: 7bit From: stefano previdi <sprevidi@cisco.com> Date: Mon, 20 Apr 2009 11:44:59 +0200 To: p2prg@ietf.org X-Mailer: Apple Mail (2.753.1) Subject: [p2prg] draft-schulzrinne-p2prg-rtc-security-00 as RG doc X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group <p2prg.irtf.org> List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=unsubscribe> List-Archive: <http://www.irtf.org/mail-archive/web/p2prg> List-Post: <mailto:p2prg@irtf.org> List-Help: <mailto:p2prg-request@irtf.org?subject=help> List-Subscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=subscribe> X-List-Received-Date: Mon, 20 Apr 2009 09:43:48 -0000 Hi, following the meeting we had in San Francisco (IETF-74), we plan to move draft-schulzrinne-p2prg-rtc-security-00 in the IRTF publication process. The first stage being an RG internal review, we decided to propose the draft as RG working document. Please, continue to bring to the list any discussion, issue, question about the draft. thanks. Stefano & Volker From enrico.marocco@telecomitalia.it Mon Apr 27 00:41:14 2009 Return-Path: <enrico.marocco@telecomitalia.it> X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339683A6A6B for <p2prg@core3.amsl.com>; Mon, 27 Apr 2009 00:41:14 -0700 (PDT) X-Quarantine-ID: <lRg0Vy3LGUxz> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: couldn't parse head; error near:; [InternetShortcut]; URL=ftp://ftp.ietf.org/internet-drafts/draft-irtf-p2prg-rtc-security-00.txt X-Spam-Flag: NO X-Spam-Score: -0.076 X-Spam-Level: X-Spam-Status: No, score=-0.076 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRg0Vy3LGUxz for <p2prg@core3.amsl.com>; Mon, 27 Apr 2009 00:41:13 -0700 (PDT) Received: from GRFEDG702BA020.telecomitalia.it (grfedg702ba020.telecomitalia.it [156.54.233.201]) by core3.amsl.com (Postfix) with ESMTP id 4B6103A6914 for <p2prg@ietf.org>; Mon, 27 Apr 2009 00:41:12 -0700 (PDT) Received: from GRFHUB701BA020.griffon.local (10.188.101.111) by GRFEDG702BA020.telecomitalia.it (10.188.45.101) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 27 Apr 2009 09:41:35 +0200 Received: from [10.229.8.41] (10.229.8.41) by smtp.telecomitalia.it (10.188.101.114) with Microsoft SMTP Server (TLS) id 8.1.359.3; Mon, 27 Apr 2009 09:41:34 +0200 Message-ID: <49F561C8.60003@telecomitalia.it> Date: Mon, 27 Apr 2009 09:42:00 +0200 From: Enrico Marocco <enrico.marocco@telecomitalia.it> User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: "p2prg@ietf.org" <p2prg@ietf.org> X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080104020609000502060701" Subject: [p2prg] [Fwd: I-D Action:draft-irtf-p2prg-rtc-security-00.txt] X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group <p2prg.irtf.org> List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=unsubscribe> List-Archive: <http://www.irtf.org/mail-archive/web/p2prg> List-Post: <mailto:p2prg@irtf.org> List-Help: <mailto:p2prg-request@irtf.org?subject=help> List-Subscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=subscribe> X-List-Received-Date: Mon, 27 Apr 2009 07:41:14 -0000 --------------ms080104020609000502060701 Content-Type: multipart/mixed; boundary="------------090603050309060301080603" This is a multi-part message in MIME format. --------------090603050309060301080603 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Folks, this draft is an update of draft-schulzrinne-p2prg-rtc-security-00 that should reflect the comments received during the meeting and on the list. Diffs from previous version can be seen at http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-schulzrinne-p2prg-rtc-security-00.txt&url2=http://www.ietf.org/internet-drafts/draft-irtf-p2prg-rtc-security-00.txt The authors think that the draft does quite a good job at picturing the state of the art of security in P2P realtime communications and, since research in this field basically never ends, would like to move it forward soon. However, if you are aware of additional works that would be worth mentioned -- including your own work -- please feel free to point them out. As usual, comments are welcome. Enrico -------- Original Message -------- Subject: I-D Action:draft-irtf-p2prg-rtc-security-00.txt Date: Mon, 27 Apr 2009 09:00:01 +0200 From: Internet-Drafts@ietf.org <Internet-Drafts@ietf.org> Reply-To: internet-drafts@ietf.org <internet-drafts@ietf.org> To: i-d-announce@ietf.org <i-d-announce@ietf.org> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security Issues and Solutions in Peer-to-peer Systems for Realtime Communications Author(s) : H. Schulzrinne, et al. Filename : draft-irtf-p2prg-rtc-security-00.txt Pages : 23 Date : 2009-04-26 Peer-to-peer (P2P) networks offer higher robustness against failure, easier configuration and are generally more economical than their client-server counterparts. It has therefore become reasonable for resource consuming and typically centralized applications like Voice over IP (VoIP) and, in general, realtime communication to adapt and exploit the benefits of P2P. Such a migration needs to address a new set of P2P specific security problems. This document describes some of the known issues found in common P2P networks, analyzing the relevance of such issues and the applicability of existing solutions when using P2P architectures for realtime communication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-irtf-p2prg-rtc-security-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------090603050309060301080603 Content-Type: message/external-body; name="draft-irtf-p2prg-rtc-security-00.url" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-irtf-p2prg-rtc-security-00.url" [InternetShortcut] URL=ftp://ftp.ietf.org/internet-drafts/draft-irtf-p2prg-rtc-security-00.txt --------------090603050309060301080603 Content-Type: text/plain; name="ATT00001.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ATT00001.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------090603050309060301080603-- --------------ms080104020609000502060701 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJwTCC AzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDMxNjE3NTMwMloX DTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEuMCwG CSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNvbWl0YWxpYS5pdDEnMCUGCSqGSIb3 DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK/BW87GvoqHz3iQvO1Tb6f4yEtFel vpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4kceezCjsXBvwNPlGHrzJifUByvwzD QSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yGrj2VIJE03GSpEL01d+omAFUou3mx 8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1BWDl2JJobG9qpC9DlplpDZOdmsAG u/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUANF0cPfVs7AHjHjudH7PzU2wIDAQAB o1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0gRhlbnJp Y28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQB3 Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjFN1tAzHQc/UxJs0gIyRRs3gGBR+p6 TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZW2QOCLdYUf6KdB6ccX7r3a58SRRL l5YTZ7bIhyAEmeI60ioyMI8U5jCCAzswggKkoAMCAQICEEIEYmjMZBX3Us1Th/pMjJYwDQYJ KoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBMB4XDTA5MDMxNjE3NTMwMloXDTEwMDMxNjE3NTMwMlowejEfMB0GA1UEAxMWVGhhd3Rl IEZyZWVtYWlsIE1lbWJlcjEuMCwGCSqGSIb3DQEJARYfZW5yaWNvLm1hcm9jY29AdGVsZWNv bWl0YWxpYS5pdDEnMCUGCSqGSIb3DQEJARYYZW5yaWNvLm1hcm9jY29AZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvd38YWuquonbz4lP4GKp0qij0v4MgXpK /BW87GvoqHz3iQvO1Tb6f4yEtFelvpK2drtUHWyY+ww6QQSOGJvSWEKTRVX5KsXpN2yNeY4k ceezCjsXBvwNPlGHrzJifUByvwzDQSnQLocE1i89x7P2T5brcaGBBgricwQL1Cggg97zp1yG rj2VIJE03GSpEL01d+omAFUou3mx8R/9XOnGnSlDpcOV6s2Ww3NN07+7sSBaE0vcvlYF8pr1 BWDl2JJobG9qpC9DlplpDZOdmsAGu/qwsI0AsucY5ZBFKqzKizQ5PGhrh3u2PHRGNncuHUAN F0cPfVs7AHjHjudH7PzU2wIDAQABo1YwVDBEBgNVHREEPTA7gR9lbnJpY28ubWFyb2Njb0B0 ZWxlY29taXRhbGlhLml0gRhlbnJpY28ubWFyb2Njb0BnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQB3Mi6SymgE1cfsbmr5LWvWVdO58/a0O95kXL2puRn9kGjF N1tAzHQc/UxJs0gIyRRs3gGBR+p6TT1gmnucO8Ji0gJBMBL+ogcfyaV30hZtUceiRevemXvZ W2QOCLdYUf6KdB6ccX7r3a58SRRLl5YTZ7bIhyAEmeI60ioyMI8U5jCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQQgRiaMxkFfdSzVOH+kyMljAJBgUrDgMCGgUAoIIB0DAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MjcwNzQyMDBaMCMG CSqGSIb3DQEJBDEWBBRGp0Wou5JcK/dX/T7eVmH0EOGMLzBfBgkqhkiG9w0BCQ8xUjBQMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMC WkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMIGH BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25z dWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJ c3N1aW5nIENBAhBCBGJozGQV91LNU4f6TIyWMA0GCSqGSIb3DQEBAQUABIIBAJw6ZCix5Qiy l6G+vcgtxG8e5Sj7PAXgjOq3yyO2/lz32r7fkXjJ1aby+bvYJQ1tujBjLXhxj/l58e8fiDWj hHDVfidMOv/t5zgK7Gx9wps+NteoZ2+ce8Ht1Hv5Sskc4odngjVnXyGdUZ96q9oED1ThN4C8 IgHT453OiuYt7yK2t1vBVWmyu7ALlD5vtFyxNHp0uzzY3ewlLEWUtqLAGI3zB4stnay2/s3f 1+SZhiX/nk93yp8YkVpmy717+sBN415sXuwVGCas12/Vw3a4QECrK1pSB+q5qSMS3WlFIFfI ZCST9DpMJfYcVZhYu4KknwR4qE8rlop6h5vbQq4Hi4wAAAAAAAA= --------------ms080104020609000502060701-- From vkg@alcatel-lucent.com Wed Apr 29 14:49:08 2009 Return-Path: <vkg@alcatel-lucent.com> X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E36B428C0E3 for <p2prg@core3.amsl.com>; Wed, 29 Apr 2009 14:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajZiqh36RCCE for <p2prg@core3.amsl.com>; Wed, 29 Apr 2009 14:49:07 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 9750228C1F6 for <p2prg@irtf.org>; Wed, 29 Apr 2009 14:49:07 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-61.lucent.com [135.3.40.61]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id n3TLoRRU009245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <p2prg@irtf.org>; Wed, 29 Apr 2009 16:50:29 -0500 (CDT) Received: from [135.185.236.17] (il0015vkg1.ih.lucent.com [135.185.236.17]) by umail.lucent.com (8.13.8/TPES) with ESMTP id n3TLoRgw011250 for <p2prg@irtf.org>; Wed, 29 Apr 2009 16:50:27 -0500 (CDT) Message-ID: <49F8CBA3.200@alcatel-lucent.com> Date: Wed, 29 Apr 2009 16:50:27 -0500 From: "Vijay K. Gurbani" <vkg@alcatel-lucent.com> Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "p2prg@irtf.org" <p2prg@irtf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [p2prg] IETF 73 (raw) minutes X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group <p2prg.irtf.org> List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=unsubscribe> List-Archive: <http://www.irtf.org/mail-archive/web/p2prg> List-Post: <mailto:p2prg@irtf.org> List-Help: <mailto:p2prg-request@irtf.org?subject=help> List-Subscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=subscribe> X-List-Received-Date: Wed, 29 Apr 2009 21:49:09 -0000 All: Here are the raw minutes I took for p2prg during the IETF 73 meeting. Agenda bashing Volker introduced the WG - Resurrected and re-chartered - Went through the new charter - Looking for new research work and existing WGs and BoFs related to p2prg Enrico Marocco, Mythbustering P2P Traffic Localization Distinguished the term "localization". Huge interest in academia and industry Caching is hard to do w/ p2p localization Traffic shaping possible, but not good for user interests Discussed how peer selection is done in p2p applications - agnostic to network topology and depends on tit-for-tat in BitTorrent, for instance. RTT, jitter estimation are other techniques. p2p localization wants to do better than average. Research papers show it is effective, at least in field trials. Don't know how it will be in the wild. This draft takes a look at various issues discussed in many fora. This draft needs to be moved in a community effort from this group. Please provide input. Outlined the myths -- 6 of them. Went through the myths: 1) Reduced cross-domain traffic: Comcast, TU-Berlin, etc. show reduction in outgoing traffic and inbound traffic. This myth is beleived to be confirmed. 2) Increased application performance: 4 references show that this is true. 2 references show some disadvantages. 3) ... Time running out -- author wants to get a sense from the room on if this work is worth pursuing. Stas Khirman: Yes, useful work. Good to have info in one single place. Richard Yang: Yes. Have a student doing "adaptive localization". Henning Schulzrinne, Security Issues and Solutions in P2P systems for RT communications. Focus is on RT communications. Went through attacker motivation: could be political, financial, or for fun. Attacker resources is primarily minting identities. Attack timing: cracker joins, proves herself and then goes rogue. Reviewed p2p for RT communications. - map names to other identifiers. - provide computational services (proxying and relaying) - store data Went through file sharing vs. RT communications slide. Admission control In telecom systems, it is hard to identify malicious peers. Rogue file detection is much easier. RT systems need just enough node to carry the load for data computation. Summary: Avoid centralization at all costs may not matter for RT services. Steven LeBlond 2 open questions about BT locality - how far can we push it - how many savings can you get? Went through methodology. Ran experiments w/ upto 10K peers. Presented experimental results. Zoran D: Locality is not a simple solution to p2p traffic mgmt. Most questions were answered in the previous talk. Methodlogy was the same (mostly) as the previous talk in how they determined how many IP addresses in an AS. Question: What happens to those ASes where there aren't too many peers? What algorithms will they use? Can larger ASes live with the localization algorithm that works in smaller ASes? Stas Khirman, Public tracker scraping. Scraped three trackers - TPB, Demonoid, and Mininova. TPB has 1.7M torrents, Demonoid has 11K and Mininovas has 4K. Presented slides on distribution for Hellboy DVD on TPB. Henning: Can the authors of the three works here get together and agree on the definition of a CDF so we can normalize the data. Richard: All studies so far focused on ASes. Would be good to get data per ISP, for instance. Richard Yang, Efficient p2p design using in-network data lockers. We need to focus on how to reduce the traffic on the last mile. For downlink we do not want to reduce the traffic. We are only interested in the uplink, which is usually the bottleneck. Must introduce storage capabilities in the network. How? Using p2p caching. Went through their basic idea of data lockers: need a decoupled forwarding and signaling arch. Presented the details of data lockers and results. Question: LAP will be implemented at the client level? Richard: Yes. Q: Did you consider solutions that would be transparent to the clients? Richard: No, do you have a solution? Reinaldo: Why would a client upload to a data locker? Richard: Avoid access congestion on last mile. Avoids messing with tit-for-tat systems since I still get credit. Christophe Diot, Nano Data Centers Don't do p2p on pcs, but on devices managed by someone like the ISP. That is, use the cable/DSL modem to provide p2p services. These devices become the nano data centers. Q: Are you memory constrained on the CPEs? A: No, b/w constrained and CPU constrained. Went through pros and cons of the nano data center. Henning: Is the 90% power savings in the aggregate or did you just shift it from ISP to the customer's premise? Christophe: No, in the aggregate. Went through results and experimental evaluation on live streaming. Thanks, -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From Jan.Seedorf@nw.neclab.eu Thu Apr 30 01:56:44 2009 Return-Path: <Jan.Seedorf@nw.neclab.eu> X-Original-To: p2prg@core3.amsl.com Delivered-To: p2prg@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD5C3A6F22 for <p2prg@core3.amsl.com>; Thu, 30 Apr 2009 01:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ocxd8nBoFIYb for <p2prg@core3.amsl.com>; Thu, 30 Apr 2009 01:56:37 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id CA00E3A6F49 for <p2prg@irtf.org>; Thu, 30 Apr 2009 01:56:16 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 5F4202C0008EB; Thu, 30 Apr 2009 10:57:39 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwR7rnMH0jOf; Thu, 30 Apr 2009 10:57:39 +0200 (CEST) Received: from VENUS.office (mx2.office [192.168.24.15]) by smtp0.neclab.eu (Postfix) with ESMTP id 369FA2C000305; Thu, 30 Apr 2009 10:57:29 +0200 (CEST) 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: Thu, 30 Apr 2009 10:57:29 +0200 Message-ID: <B94940C43117794C9432FF5FF0CCB506919E8F@VENUS.office> In-Reply-To: <49F8CBA3.200@alcatel-lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [p2prg] IETF 73 (raw) minutes Thread-Index: AcnJFJksiDHFfVIPR6aWQXjBw6DViQAXQHHA References: <49F8CBA3.200@alcatel-lucent.com> From: "Jan Seedorf" <Jan.Seedorf@nw.neclab.eu> To: "Vijay K. Gurbani" <vkg@alcatel-lucent.com>, <p2prg@irtf.org> Subject: Re: [p2prg] IETF 73 (raw) minutes X-BeenThere: p2prg@irtf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Peer-to-Peer Research Group <p2prg.irtf.org> List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=unsubscribe> List-Archive: <http://www.irtf.org/mail-archive/web/p2prg> List-Post: <mailto:p2prg@irtf.org> List-Help: <mailto:p2prg-request@irtf.org?subject=help> List-Subscribe: <http://www.irtf.org/mailman/listinfo/p2prg>, <mailto:p2prg-request@irtf.org?subject=subscribe> X-List-Received-Date: Thu, 30 Apr 2009 08:56:44 -0000 Dear Vijay, Thanks for circulating these notes. Btw: it was IETF-74, I believe :) - Jan > -----Original Message----- > From: p2prg-bounces@irtf.org [mailto:p2prg-bounces@irtf.org] On Behalf > Of Vijay K. Gurbani > Sent: Mittwoch, 29. April 2009 23:50 > To: p2prg@irtf.org > Subject: [p2prg] IETF 73 (raw) minutes >=20 > All: Here are the raw minutes I took for p2prg during the > IETF 73 meeting. >=20 > Agenda bashing >=20 > Volker introduced the WG > - Resurrected and re-chartered > - Went through the new charter > - Looking for new research work and existing WGs and BoFs > related to p2prg >=20 > Enrico Marocco, Mythbustering P2P Traffic Localization >=20 > Distinguished the term "localization". > Huge interest in academia and industry > Caching is hard to do w/ p2p localization > Traffic shaping possible, but not good for user interests > Discussed how peer selection is done in p2p applications - > agnostic to network topology and depends on tit-for-tat in > BitTorrent, for instance. RTT, jitter estimation are other > techniques. > p2p localization wants to do better than average. > Research papers show it is effective, at least in field trials. > Don't know how it will be in the wild. > This draft takes a look at various issues discussed in many > fora. > This draft needs to be moved in a community effort from this > group. Please provide input. > Outlined the myths -- 6 of them. > Went through the myths: > 1) Reduced cross-domain traffic: Comcast, TU-Berlin, etc. show > reduction in outgoing traffic and inbound traffic. This myth is > beleived to be confirmed. > 2) Increased application performance: 4 references show that > this is true. 2 references show some disadvantages. > 3) ... > Time running out -- author wants to get a sense from the room on > if this work is worth pursuing. > Stas Khirman: Yes, useful work. Good to have info in one single > place. > Richard Yang: Yes. Have a student doing "adaptive localization". >=20 > Henning Schulzrinne, Security Issues and Solutions in P2P systems > for RT communications. >=20 > Focus is on RT communications. >=20 > Went through attacker motivation: could be political, financial, or > for fun. >=20 > Attacker resources is primarily minting identities. >=20 > Attack timing: cracker joins, proves herself and then goes rogue. >=20 > Reviewed p2p for RT communications. > - map names to other identifiers. > - provide computational services (proxying and relaying) > - store data >=20 > Went through file sharing vs. RT communications slide. >=20 > Admission control >=20 > In telecom systems, it is hard to identify malicious peers. Rogue > file detection is much easier. >=20 > RT systems need just enough node to carry the load for data > computation. >=20 > Summary: Avoid centralization at all costs may not matter for RT > services. >=20 > Steven LeBlond >=20 > 2 open questions about BT locality > - how far can we push it > - how many savings can you get? >=20 > Went through methodology. Ran experiments w/ upto 10K peers. > Presented experimental results. >=20 > Zoran D: Locality is not a simple solution to p2p traffic mgmt. >=20 > Most questions were answered in the previous talk. > Methodlogy was the same (mostly) as the previous talk in how they > determined how many IP addresses in an AS. >=20 > Question: What happens to those ASes where there aren't too many > peers? What algorithms will they use? >=20 > Can larger ASes live with the localization algorithm that works > in smaller ASes? >=20 > Stas Khirman, Public tracker scraping. >=20 > Scraped three trackers - TPB, Demonoid, and Mininova. TPB has > 1.7M torrents, Demonoid has 11K and Mininovas has 4K. >=20 > Presented slides on distribution for Hellboy DVD on TPB. >=20 > Henning: Can the authors of the three works here get together > and agree on the definition of a CDF so we can normalize the > data. >=20 > Richard: All studies so far focused on ASes. Would be good to get > data per ISP, for instance. >=20 > Richard Yang, Efficient p2p design using in-network data lockers. >=20 > We need to focus on how to reduce the traffic on the last mile. >=20 > For downlink we do not want to reduce the traffic. We are only > interested in the uplink, which is usually the bottleneck. >=20 > Must introduce storage capabilities in the network. How? Using > p2p caching. >=20 > Went through their basic idea of data lockers: need a decoupled > forwarding and signaling arch. >=20 > Presented the details of data lockers and results. >=20 > Question: LAP will be implemented at the client level? > Richard: Yes. > Q: Did you consider solutions that would be transparent to the = clients? > Richard: No, do you have a solution? > Reinaldo: Why would a client upload to a data locker? > Richard: Avoid access congestion on last mile. Avoids messing with > tit-for-tat systems since I still get credit. >=20 > Christophe Diot, Nano Data Centers >=20 > Don't do p2p on pcs, but on devices managed by someone like the ISP. > That is, use the cable/DSL modem to provide p2p services. These > devices become the nano data centers. >=20 > Q: Are you memory constrained on the CPEs? > A: No, b/w constrained and CPU constrained. >=20 > Went through pros and cons of the nano data center. >=20 > Henning: Is the 90% power savings in the aggregate or did you just > shift it from ISP to the customer's premise? > Christophe: No, in the aggregate. >=20 > Went through results and experimental evaluation on live streaming. >=20 > Thanks, > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > p2prg mailing list > p2prg@irtf.org > http://www.irtf.org/mailman/listinfo/p2prg