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