[ppsp] [Technical Errata Reported] RFC7574 (4725)

RFC Errata System <rfc-editor@rfc-editor.org> Fri, 01 July 2016 02:21 UTC

Return-Path: <wwwrun@rfc-editor.org>
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 3ECD912D0D9 for <ppsp@ietfa.amsl.com>; Thu, 30 Jun 2016 19:21:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.048
X-Spam-Level:
X-Spam-Status: No, score=-104.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX-xJrP-jx8W for <ppsp@ietfa.amsl.com>; Thu, 30 Jun 2016 19:21:17 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95F3A12D0C2 for <ppsp@ietf.org>; Thu, 30 Jun 2016 19:21:17 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 7DFB9B81064; Thu, 30 Jun 2016 19:21:17 -0700 (PDT)
To: arno@cs.vu.nl, r.petrocco@gmail.com, victor.grishchenko@gmail.com, spencerdawkins.ietf@gmail.com, ietf@kuehlewind.net, zongning@huawei.com, hishigh@sina.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Message-Id: <20160701022117.7DFB9B81064@rfc-editor.org>
Date: Thu, 30 Jun 2016 19:21:17 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ppsp/-ljECuE7Aw5jH-x04KwupRbaEho>
Cc: ppsp@ietf.org, shkim@etri.re.kr, rfc-editor@rfc-editor.org
Subject: [ppsp] [Technical Errata Reported] RFC7574 (4725)
X-BeenThere: ppsp@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 01 Jul 2016 02:21:19 -0000

The following errata report has been submitted for RFC7574,
"Peer-to-Peer Streaming Peer Protocol (PPSPP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7574&eid=4725

--------------------------------------
Type: Technical
Reported by: Sung Hei Kim, Chang Kyu Lee <shkim@etri.re.kr>;

Section: 5

Original Text
-------------
PPSPP can use different methods for protecting the integrity of the
content while it is being distributed via the peer-to-peer network.
More specifically, PPSPP can use different methods for receiving
peers to detect whether a requested chunk has been maliciously
modified by the sending peer. In benign environments, content
integrity protection can be disabled.

For static content, PPSPP currently defines one method for protecting
integrity, called the Merkle Hash Tree scheme. If PPSPP operates
over the Internet, this scheme MUST be used. If PPSPP operates in a
benign environment, this scheme MAY be used. So the scheme is
mandatory to implement, to satisfy the requirement of strong security
for an IETF protocol [RFC3365]. An extended version of the scheme is
used to efficiently protect dynamically generated content (live
streams), as explained below and in Section 6.1.

Corrected Text
--------------
PPSPP can use different methods for protecting the integrity of the
content while it is being distributed via the peer-to-peer network.
More specifically, PPSPP can use different methods for receiving
peers to detect whether a requested chunk has been maliciously
modified by the sending peer.

For static content, PPSPP currently defines one method for protecting
integrity, called the Merkle Hash Tree scheme.
The scheme is mandatory to implement, to satisfy the requirement of 
strong security for an IETF protocol [RFC3365]. An extended version
of the scheme is used to efficiently protect dynamically generated
content (live streams), as explained below and in Section 6.1.

Notes
-----
RFC 7574 (PPSP-PP) defines how the peers exchange chunks regarding content integrity protection scheme. It describes the relationship of the DATA and INTEGRITY messages.
But, it does not describes how peers exchange chunks when the content integrity protection scheme is disabled.
Thus, to the readers, it seems that content integrity protection scheme is very important part of PPSP-PP and must be used in order to implement PPSP-PP.
I think the RFC 7574 (PPSP-PP) should be changed to clearly express that the content integrity protection scheme must be used in PPSP-PP.
The proposed changes is to remove options regarding the use of content integrity protection.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7574 (draft-ietf-ppsp-peer-protocol-12)
--------------------------------------
Title               : Peer-to-Peer Streaming Peer Protocol (PPSPP)
Publication Date    : July 2015
Author(s)           : A. Bakker, R. Petrocco, V. Grishchenko
Category            : PROPOSED STANDARD
Source              : Peer to Peer Streaming Protocol
Area                : Transport
Stream              : IETF
Verifying Party     : IESG