[ppsp] 回复: 答复: ***SPAM*** 8.258 (5) 答复: 答复: tracker protocol review

zhangyunfei <zhangyunfei@chinamobile.com> Tue, 06 November 2012 01:53 UTC

Return-Path: <zhangyunfei@chinamobile.com>
X-Original-To: ppsp@ietfa.amsl.com
Delivered-To: ppsp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAD51F0C67 for <ppsp@ietfa.amsl.com>; Mon, 5 Nov 2012 17:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -92.964
X-Spam-Level:
X-Spam-Status: No, score=-92.964 tagged_above=-999 required=5 tests=[AWL=-2.236, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RELAY_IS_221=2.222, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5Qpz9vgZCdS for <ppsp@ietfa.amsl.com>; Mon, 5 Nov 2012 17:53:38 -0800 (PST)
Received: from imss.chinamobile.com (imss.chinamobile.com [221.130.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED0F1F0C54 for <ppsp@ietf.org>; Mon, 5 Nov 2012 17:53:38 -0800 (PST)
Received: from imss.chinamobile.com (localhost [127.0.0.1]) by localhost.chinamobile.com (Postfix) with ESMTP id EFF12E625; Tue, 6 Nov 2012 09:53:34 +0800 (CST)
Received: from mail.chinamobile.com (unknown [10.1.28.22]) by imss.chinamobile.com (Postfix) with ESMTP id DA7D0E624; Tue, 6 Nov 2012 09:53:34 +0800 (CST)
Received: from zyf-PC ([10.2.43.220]) by mail.chinamobile.com (Lotus Domino Release 6.5.6) with ESMTP id 2012110609533300-4187 ; Tue, 6 Nov 2012 09:53:33 +0800
Date: Tue, 06 Nov 2012 09:53:27 +0800
From: zhangyunfei <zhangyunfei@chinamobile.com>
To: '邓灵莉' <denglingli@chinamobile.com>, 'Rui Cruz' <rui.cruz@ieee.org>, "arno@cs.vu.nl" <arno@cs.vu.nl>
References: <2012110511283736034341@chinamobile.com>, <002001cdbb0b$9e8ff000$dbafd000$@com> <201211051340060015086@chinamobile.com> <004f01cdbb51$a8afc8d0$fa0f5a70$@com> <0D8207BB-EA12-4ECC-84A8-FDE9611AF6D4@ieee.org>, <007501cdbb7c$c07feb40$417fc1c0$@com>
X-Priority: 3 (Normal)
X-Mailer: Foxmail 7.0.1.85[cn]
Mime-Version: 1.0
Message-ID: <2012110609532773548615@chinamobile.com>
X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-06 09:53:33, Serialize by Router on jtgsml01/servers/cmcc(Release 6.5.6|March 06, 2007) at 2012-11-06 09:53:34, Serialize complete at 2012-11-06 09:53:34
Content-Type: multipart/alternative; boundary="----=_001_NextPart433483730410_=----"
X-TM-AS-Product-Ver: IMSS-7.0.0.8231-6.8.0.1017-19344.000
X-TM-AS-Result: No--36.344-7.0-31-10
X-imss-scan-details: No--36.344-7.0-31-10;No--36.344-7.0-31-10
X-TM-AS-User-Approved-Sender: No;No
X-TM-AS-User-Blocked-Sender: No;No
Cc: ppsp <ppsp@ietf.org>
Subject: [ppsp] 回复: 答复: ***SPAM*** 8.258 (5) 答复: 答复: tracker protocol review
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: zhangyunfei <zhangyunfei@chinamobile.com>
List-Id: discussing to draw up peer to peer streaming protocol <ppsp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ppsp>, <mailto:ppsp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ppsp>
List-Post: <mailto:ppsp@ietf.org>
List-Help: <mailto:ppsp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ppsp>, <mailto:ppsp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2012 01:53:40 -0000

Hi Lingli,
   To the best of my understanding, PPSP assumes a trustful content publisher and should identifies only the malicious PEERs. In other words, PPSP is not a complete system to satisfy the suer experience in p2p streaming. Rather it just addresses how to do the communications among peers and trackers and in the process avoiding malicious peers to do the attack/pollutions. The issue to ensure the content publisher trustful is a necessary problem to consider when running a practical p2p streaming system esp. when UGC contents are involved. We welcome contributions in BCP drafts on this issue. 

BR
yunfei




zhangyunfei

发件人: 邓灵莉/Lingli Deng
发送时间: 2012-11-06 01:41
收件人: 'Rui Cruz'; arno@cs.vu.nl
抄送: 'zhangyunfei'; 'Yingjie Gu\(yingjie\)'; 'ppsp'
主题: 答复: [ppsp] ***SPAM*** 8.258 (5) 答复: 答复: tracker protocol review
Hi all,
 
As Arno presented the security proposals in peer protocol, and stated that they meet the security part in the requirement document, I felt a concern with the status in PPSP scope in terms of security issues.
Since the content publishing is now out of scope of the discussion, the very root of trust for the content provided by a peering party to satisfy the user’s expectation is missing. 
 
This cannot be compensated by peer authentication or authorization mechanisms directly, I am afraid. 
 
BR
Lingli
 
发件人: Rui Cruz [mailto:rui.cruz@ieee-pt.org] 代表 Rui Cruz
发送时间: 2012年11月5日 8:24
收件人: 邓灵莉/Lingli Deng
抄送: Rui Cruz; 'zhangyunfei'; 'Yingjie Gu(yingjie)'; 'ppsp'
主题: Re: [ppsp] ***SPAM*** 8.258 (5) 答复: 答复: tracker protocol review
 
Hi Yunfei and Lingli,
 
In section 1.2.3 "Content Information Metadata" and 1.2.4 "Authentication, Confidentiality, Integrity", although informative in nature, the aspect on content integrity is somewhat raised, but not described. However, stating in the draft that "content information metadata used in PPSP may align with MPD formats, such as ISO/IEC 23009-1" means that content protection and integrity verification schemes can be distributed by including root fingerprints for each each video and audio groups described in the MPD of the content.
 
In Appendix B. Media Presentation Description (MPD) of draft-gu-ppsp-tracker-protocol-07, that situation was fairly described with examples, but that section was not transferred to the Base-Protocol draft, as suggested during discussions.
 
In my opinion, I hardly see the distribution of the fingerprints as a role of the tracker protocol as these schemes are related to the content, but I would strongly support not just channel-oriented security in the communication between peers and tracker but also authentication and authorization mechanisms for the peers.

Regards,
 
Rui Cruz
rui.cruz@ieee.org
 
IST/INESC-ID/INOV - Lisbon, Portugal
__________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp
 
On 05/11/2012, at 12:32, 邓灵莉/Lingli Deng <denglingli@chinamobile.com> wrote:



All right. I will discuss it with Yingjie and Rui today. See what to do about it.
Lingli
发件人: zhangyunfei [mailto:zhangyunfei@chinamobile.com] 
发送时间: 2012年11月5日 0:40
收件人: '邓灵莉'; Yingjie Gu(yingjie); 'Rui Cruz'
抄送: ppsp
主题: 回复: 答复: [ppsp] tracker protocol review
 
Yes, Lingli. I mean it would be good to write explicitly to say how to handle this in tracker protocol.
 
BR
Yunfei



zhangyunfei
 
发件人: 邓灵莉/Lingli Deng
发送时间: 2012-11-05 12:11
收件人: 'zhangyunfei'; 'Yingjie Gu\(yingjie\)'; 'Rui Cruz'
抄送: 'ppsp'
主题: 答复: [ppsp] tracker protocol review
Yunfei,
As for your comment asking for clarification for content integrity’s relation to tracker protocol, I would like to explain that as pointed out at the end of Section 9.2,  content pollution
can be detected by incorporating integrity verification schemes for published shared contents.  As content chunks are transferred independently and concurrently, a correspondent chunk-level integrity verification MUST be used, checked with signed fingerprints received from authentic origin.
In other words, these fingerprints MUST be signed by the authentic origin of the content, and MUST be distributed in a trustworthy manner against manipulation and forgery.
It would be reasonable to expect such distribution be handled by the tracker protocol in a security-enhanced sense.
BR
Lingli
发件人: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] 代表 zhangyunfei
发送时间: 2012年11月4日 22:29
收件人: Yingjie Gu(yingjie); 'Rui Cruz'
抄送: ppsp
主题: [ppsp] tracker protocol review
 
Hi Rui and Yingjie (Speaking individually) ,
    I have read the updated tracker protocol draft and have the following comments:
1) Encoding issue: It's good to mention that PPSP-TP is intended to support binary encoding in section 4. However in section 5, 7 and 8, http+XML is still in the main page. Is this just for example? Or a general semantics desperation is enough? I think much of section 7.1 in current version can be placed in Appendix A. Are you intending to use EXI for the binary encoding and do you still need http for the underlying transport?
2)  Check the section 10 for the XML descriptions. Do we need the update of this part?
3)Security part, section 9.2, how does the content integrity check related to the tracker protocol should be better explained.
 
BR
Yunfei
 



zhangyunfei
_______________________________________________
ppsp mailing list
ppsp@ietf.org
https://www.ietf.org/mailman/listinfo/ppsp