Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03
"Schmidt, Christian 1. (NSN - DE/Munich)" <christian.1.schmidt@nsn.com> Wed, 07 September 2011 08:12 UTC
Return-Path: <christian.1.schmidt@nsn.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 0AE1221F8BAA for <ppsp@ietfa.amsl.com>; Wed, 7 Sep 2011 01:12:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.415
X-Spam-Level:
X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MANGLED_LIST=2.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8d94G5lAGK0P for <ppsp@ietfa.amsl.com>; Wed, 7 Sep 2011 01:12:03 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 70B5A21F8C13 for <ppsp@ietf.org>; Wed, 7 Sep 2011 01:12:02 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p878Dbhr007949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 7 Sep 2011 10:13:37 +0200
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p878DZ1f027104; Wed, 7 Sep 2011 10:13:36 +0200
Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Sep 2011 10:13:35 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC6D36.0A049242"
Date: Wed, 07 Sep 2011 10:13:33 +0200
Message-ID: <C58FFCAAA14F454A85AFB7C1C2F862C4024238D0@DEMUEXC013.nsn-intra.net>
In-Reply-To: <E84E7B8FF3F2314DA16E48EC89AB49F01CF8C461@DAPHNIS.office.hd>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: RE: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03
Thread-Index: AQHMZkOiDMy/BPlOgkqQRsEANytWQZU4H83zgAhh1RCAAQ97EA==
References: <E84E7B8FF3F2314DA16E48EC89AB49F01CF51D19@DAPHNIS.office.hd><201108161556008185916@chinamobile.com><E84E7B8FF3F2314DA16E48EC89AB49F01CF69BD0@Polydeuces.office.hd> <201108231032130037515@chinamobile.com> <C58FFCAAA14F454A85AFB7C1C2F862C4023A635F@DEMUEXC013.nsn-intra.net> <201109011508590279274@chinamobile.com> <E84E7B8FF3F2314DA16E48EC89AB49F01CF8C461@DAPHNIS.office.hd>
From: "Schmidt, Christian 1. (NSN - DE/Munich)" <christian.1.schmidt@nsn.com>
To: ext Martin Stiemerling <Martin.Stiemerling@neclab.eu>, zhangyunfei <zhangyunfei@chinamobile.com>, ppsp@ietf.org
X-OriginalArrivalTime: 07 Sep 2011 08:13:35.0570 (UTC) FILETIME=[0A51DB20:01CC6D36]
Subject: Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 07 Sep 2011 08:12:06 -0000
Hi Martin, I am not in favor of replacing the existing text. I would like to see some kind of a merger. What about the following proposal? Br Christian 6. Security Considerations This memo discusses the problem statement around a peer-to-peer streaming protocols without specifying the protocols. The protocol specification is deferred to other memos under development in the PPSP working group. This document is neither a requirement document nor a protocol specification. But we believe it is important for the reader to understand areas of security caused by the p2p nature of the proposed solution. Main issue is the usage of untrusted entities (peers) for service provisioning. Malicious peers may - Issue denial of service attacks to the trackers by sending large amount of requests with the tracker protocol - May fake information on behalf of other peers - May fake information about available content - May fake information about chunk availability Malicious peers/trackers may - May reply instead of the regular tracker (man in the middle attack) The PPSP protocol specifications, e.g., the peer protocol and the tracker protocol, will document the expected threats and how they will be mitigated for each protocol, but also considerations on threats and mitigations when combining both protocols in an application. This will include privacy of the users, protection of the content distribution, but not protection of the content by Digital Rights Management (DRM). From: ext Martin Stiemerling [mailto:Martin.Stiemerling@neclab.eu] Sent: Tuesday, September 06, 2011 5:12 PM To: zhangyunfei; Schmidt, Christian 1. (NSN - DE/Munich); ppsp@ietf.org Subject: RE: RE: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03 Short answer: Do you refer to add my text proposal to the existing text or to replace the existing text? I would replace it, as some threats, but not all, are outlined, but without a solution, as this draft cannot give a detailed solution. Martin From: zhangyunfei [mailto:zhangyunfei@chinamobile.com] Sent: Thursday, September 01, 2011 9:09 AM To: Schmidt, Christian 1. (NSN - DE/; Martin Stiemerling; ppsp@ietf.org Subject: Re: RE: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03 Hi Christian and Martin, Thanks for the comments. From my point of view, the general descrption of the security threat and points to possible solutions is important for readers to understand the whole picture. So it would be great if the draft can add what Martin proposed based on our previous version. How do you think about this, Martin? BR Yunfei ________________________________ zhangyunfei 2011-09-01 ________________________________ 发件人: Schmidt, Christian 1. (NSN - DE/Munich) 发送时间: 2011-08-29 20:03:05 收件人: ext zhangyunfei; Martin Stiemerling; ppsp@ietf.org 抄送: 主题: RE: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03 Hi Martin, Yunfei, In PPSP overview we have just a hint to the problem statement ID.: In PPSP requirements we have just a summary of security related requirements. But I did not found an ID describing security threats / problems due to the usage of p2p technology for streaming. I think we need such a general description and the problem statement ID seems to be the best place for it. The actual version covers security problem description and points towards possible solutions (it is not a solution description). The responsibility for proper method selection should be done in the related protocol descriptions (tracker / peer). What do you think about this proposal? Best Regards Christian 6. Security Considerations PPSP will not attempt to provide a solution on security and copyright issues like malicious content distribution, content pollution and DRM for a general P2P streaming system. Instead PPSP security involves the security problems related to PPSP protocols. The protocol documents will contain a complete description on the security/privacy issues relevant to any usage of PPSP. 6.1. Tracker Protocol Malicious peers may issue denial of service attack to the trackers by sending large amount of requests with tracker protocol. Distributed trackers deployment may alleviate the problem. For protection against denial of service attacks, standard security methods can be used. Malicious peers may report fake information on behalf of other peers. This can be avoided with peer authentication. Malicious peers may report fake information about available content. For this purpose, malicious peers can be reported to the tracker. Malicious tracker, especially distributed version, can be very harmful. The malicious acting tracker may reply instead of the regular tracker (man in the middle attack). To avoid this tracker authentication could be used. The malicious acting tracker may reply the peers with fake peer-list. Peers may find they cannot find desired data with the fake peer-list. 6.2. Peer Protocol Similar to the behavior in the tracker-peer interaction, malicious peers may also create fake information on chunk availability and exchange it with other peers. Some techniques to check the data integrity (e.g., using checksum) may be useful for detecting the attack. 6.3. Solution for Security Threats / Problems. The PPSP protocol specifications, e.g., the peer protocol and the tracker protocol, will Choose and document adequate methods to solve this security issues in a proper way. From: ppsp-bounces@ietf.org [mailto:ppsp-bounces@ietf.org] On Behalf Of ext zhangyunfei Sent: Tuesday, August 23, 2011 4:32 AM To: Martin Stiemerling; ppsp@ietf.org Subject: Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03 Hi Martin, Thanks so much for the proposoal. Let me make sure your meaning: Do you mean we'd better have a very high-level description on the PPSP secuirty threats and possible solutions, instead of having a detailed description on the peer and tracker protocol security issues, right? BR Yunfei ________________________________ zhangyunfei 2011-08-23 ________________________________ 发件人: Martin Stiemerling 发送时间: 2011-08-22 20:41:53 收件人: zhangyunfei; ppsp@ietf.org 抄送: 主题: RE: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03 Hi Yunfei, Here is the text proposal for the security section. It is fairly short but should suffice the considerations for the problem statement. I have included the “protection of the content distribution” to the scope; this is included in the current text. However, it will be necessary to document what the threat to the content distribution is, e.g., to not forward chunks or exchange chunks with bogus data; and also to document mitigations to this (hashes, hash tress, etc). Here you go: 6. Security Considerations This memo discusses the problem statement around a peer-to-peer streaming protocols without specifying the protocols. The protocol specification is deferred to other memos under development in the PPSP working group. The PPSP protocol specifications, e.g., the peer protocol and the tracker protocol, will document the expected threats and how they will be mitigated for each protocol, but also considerations on threats and mitigations when combining both protocols in an application. This will include privacy of the users, protection of the content distribution, but not protection of the content by Digital Rights Management (DRM). Martin From: zhangyunfei [mailto:zhangyunfei@chinamobile.com] Sent: Tuesday, August 16, 2011 9:56 AM To: Martin Stiemerling; ppsp@ietf.org Subject: Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03 Hi Martin, Thanks for the careful review. Please see inline for the reply. BR Yunfei ________________________________ zhangyunfei 2011-08-16 ________________________________ 发件人: Martin Stiemerling 发送时间: 2011-08-15 21:06:14 收件人: ppsp@ietf.org 抄送: 主题: [ppsp] WGLC comments draft-ietf-ppsp-problem-statement-03 [Writing not as WG chair, but as individual contributor] Dear all, I have reviewed the draft draft-ietf-ppsp-problem-statement-03 and did mainly find editorial issues. Non-Editorials: - Section 3.1, 2nd paragraph, " With PPSP, P2P cache can detect P2P streaming applications much easier without needing to update its library."; It might not be completely obvious to an average reader why a standarizded P2P protocol would make things easier here. How about adding at the end of this sentence: ", as there is only a single protocol to be detected and not a potentially unknown set of proprietary P2P protocols". [Yunfei]Good proposal! - Section 3.2, 1st paragraph, 1st sentence. I cannot see the relationship between the section's intended scope and DONA or any other content centric networking. [Yunfei] Acutally it wants to explain the phenomenon that stream content(including using P2P)will account a lot in future network is a trend. But maybe we can replace the trend by actual figures(e.g, in section1, cisco figures)to avoid the misleading sentence. - Section 3.2, 3rd paragraph, You lost me with the everything after the first sentence of this paragraph. I don't understand what it is saying or what it should be saying. [Yunfei] The sentence is saying that PPSP reduces the complexity of the case by case adaptation between CDN and the CP.Maybe I can rewrite this part. - Section 3.3, 1st paragraph, The first sentence about "mobility and wireless are becoming increasingly dominate " is basically reflecting the current situation, but what is the relationship to the future Internet activities mentioned there? The mobile and wireless part is already sort of dominant by today. [Yunfei] Good question. Similar to section 3.1, replace "trend" by "fact". - Section 3.4, 2nd paragraph: I know what this paragraph is aiming at, i.e., reusing the same library and potentially other optimizations. But it would be better to rephrase the paragraph. E.g., "PPSP can help to reduce the resource consumption on resource constraint devices, such as STBs or mobile phones, by reusing a PPSP base library and ..." [Yunfei] Fine for the change. - Security section: I'm not sure that the current security section is exactly what we need for the problem statement. It is on one hand detailed on the threat description (e.g., "peers may report fake information about available content"), but on the other side lacks the description of countermeasures to those threats. I would propose to rewrite the security section to cover a broader focus on highlighting certain threats, but letting the fix to those to the particular protocol specifications, i.e., the peer protocol and the tracker protocol. I can provide some initial text, if there is an agreement to replace the security section. [Yunfei] Thanks and would be glad to see your detailed text on broadening the section. And would ask Christian for more comments. Editorials (mainly suggestions to improve readability): - General: There are many places where the dots are misplaced, e.g., in - Section 1, 2nd paragraph, " paradigm [Survey].The". This should read "paradigm [Survey]. The" (space between dot and The) - Which Internet draft template is being used for this draft? The new templates have the "Abstract" before the part on " Status of this Memo" and " Copyright Notice". - Section 1, 2nd paragraph, comma missing, replace "like CNN [CNN] PPstream" with "like CNN [CNN], PPstream" - Section 1, 2nd paragraph, replace "Client-Server" with "client-server". The spelling of this is not consistent in the draft. - Section 1, 4th paragraph, replace "Almost all these systems" with " Almost all of these systems". - Section 1, 4th paragraph, replace "P2P streaming, the open protocols will dynamically reduce " with "P2P streaming, open protocols may reduce " - Section 2, paragraph starting with "PPSP", replace "The abbreviation of P2P streaming protocols" with "The abbreviation of Peer-to-Peer Streaming Protocols" - Section 2, paragraph starting with "Tracker", replace "list of peers storing chunks for a specific channel or streaming file" with "list of peers which participate in a specific video channel or in the distribution of a streaming file". - Section 2, paragraph starting with "Tracker", replace "from peers for peer lists" with "from peers with a list of candidate peers". - Section 3, 1st paragraph, replace "The problems brought by proprietary" with "The problems imposed by proprietary" - Section 3.1, title of this section, replace "Difficulties for ISP in deploying P2P caches" with "Difficulties for ISPs in deploying P2P caches" - Section 3.1, 1st paragraph, replace "P2P cache is used to reduce the" with "P2P caches are used to reduce the" or "P2P caching is used to reduce the" - Section 3.1, 2nd paragraph, replace "With PPSP, P2P cache can detect" with "With PPSP, a P2P cache can detect" - Section 3.1, 2nd paragraph, the last sentence, there are two commas between "tracker/peer protocol" and "which is easier..." - Section 3.2, 2nd paragraph, replace "Similar to the cache case, this" with "Similar to the caching case in Section 3.1, this" - Section 3.3, 1st paragraph, last sentence, the dot at the end is missing. - Section 3.3, 2nd paragraph, page 10, replace "trackers and peers need more information" with "trackers and peers may need more information" - Section 3.3, 2nd paragraph, page 10, there is terminology collision, as serving gateway is translated to GGSN. A change of a SGSN will not be noticed by the terminal. Moving to a new GGSN might be. However, moving to a new GGSN might be experience like any other event where the IP address changes. - Section 3.4, 1st paragraph, replace "In other word" with "In other words" - Section 3.4, 1st paragraph, replace "multiple programs in one resource constraint" with "multiple programs in a resource constraint" - Section 4, 1st paragraph: replace full 1st paragraph with "The objective of the PPSP working group is to design a unified peer- to-peer streaming protocol (PPSP) to address the problems discussed in the preceding sections." - Section 4, 3rd paragraph: replace "and then retrieve for wanted streaming" with "and then retrieve the wanted streaming" - Section 4, 4th paragraph: replace " topology e.g., a tree." With " topology, e.g., a tree." - Section 4, 4th paragraph: replace "(maybe with recommended order)" with "(potentially in a recommended order)" - Section 4, 4th paragraph: replace "Few practical systems" with "Few commercially deployed" - Section 4, 5th paragraph: what is "unfounded data"? - Section 4, 6th paragraph: move this paragraph to page 12 before paragraph starting with "In detail," - Section 4, last paragraph, page 12: I'm not sure that we still need this paragraph. Can we remove it? - Section 5, 1st paragraph, there is a leftover: " <Text for this section >". - Section 5.2, 1st paragraph, replace "Also it can also talk" with "It can also communicate" - Section 5.3, 2nd paragraph, replace " With PPSP Peers can identify the types of access networks, their load/congestion information" with " With PPSP, peers may be able to identify the type of access networks, average load". Do not include congestion information, as this information is anyhow too volatile to be tracked by some entity of the peer network, other than the peers which are anyhow directly communicating with each other. - Section 5.3, 2nd paragraph, replace "be selected, which will lead to" with "be selected, which may lead to" - Section 5.5, 1st paragraph, replace "section3" with "Section 3" - Section 5.5, 1st paragraph, replace "nodes in the network" with "nodes at the network" - Reference section: This section does not follow the style of references as used in the RFC series and needs to be updated. [Yunfei]I'll update these editorial issues in new version draft. Kind regards Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ ppsp mailing list ppsp@ietf.org https://www.ietf.org/mailman/listinfo/ppsp
- [ppsp] WGLC comments draft-ietf-ppsp-problem-stat… Martin Stiemerling
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… zhangyunfei
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Martin Stiemerling
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Johan Pouwelse
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… zhangyunfei
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… zhangyunfei
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Schmidt, Christian 1. (NSN - DE/Munich)
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… zhangyunfei
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Martin Stiemerling
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Martin Stiemerling
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Martin Stiemerling
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Schmidt, Christian 1. (NSN - DE/Munich)
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Martin Stiemerling
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Schmidt, Christian 1. (NSN - DE/Munich)
- Re: [ppsp] WGLC comments draft-ietf-ppsp-problem-… Martin Stiemerling
- [ppsp] (no subject) zhangyunfei