Re: [ppsp] Stephen Farrell's Discuss on draft-ietf-ppsp-base-tracker-protocol-10: (with DISCUSS and COMMENT)

"Huangyihong (Rachel)" <> Thu, 22 October 2015 07:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E46E61B381A; Thu, 22 Oct 2015 00:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8kQBRxTm1Ctn; Thu, 22 Oct 2015 00:09:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 405751B3817; Thu, 22 Oct 2015 00:09:46 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id BZD23340; Thu, 22 Oct 2015 07:09:42 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 22 Oct 2015 08:09:40 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Thu, 22 Oct 2015 15:09:28 +0800
From: "Huangyihong (Rachel)" <>
To: Stephen Farrell <>, The IESG <>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-ppsp-base-tracker-protocol-10: (with DISCUSS and COMMENT)
Thread-Index: AQHRBrZLMjqAxHKhOkOsnjjXjHpNAp51fJ3g
Date: Thu, 22 Oct 2015 07:09:27 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Cc: "" <>, "" <>, "" <>
Subject: Re: [ppsp] Stephen Farrell's Discuss on draft-ietf-ppsp-base-tracker-protocol-10: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussing to draw up peer to peer streaming protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Oct 2015 07:09:50 -0000

Hi Stephen,

Thank you for your comments and sorry for our late replies. Please see inline.


> -----Original Message-----
> From: Stephen Farrell []
> Sent: Thursday, October 15, 2015 3:27 AM
> To: The IESG
> Cc:;;
> Zongning;
> Subject: Stephen Farrell's Discuss on draft-ietf-ppsp-base-tracker-protocol-10:
> (with DISCUSS and COMMENT)
> Stephen Farrell has entered the following ballot position for
> draft-ietf-ppsp-base-tracker-protocol-10: Discuss
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 6.2 - can you explain to me how the overall protection against pollution works?
> I'm not quite following it and am concerned that it may be lacking. But that may
> just be me forgetting how this ties together with rfc7574.

[Rachel]: Tracker protocol is used to exchange information like peer list, peer status between peers and trackers. Content pollution is usually caused by content changing between peers. Because trackers don't exchange content information with peers, they don't have ways to detect if a peer is polluting the content or not. The integrity verification schemes mentioned in Section 6.2 are considered in peer protocol, which can reference section 6.1 of RFC7574. So how about changing the Section 6.2 to the following:
Malicious peers may declaim ownership of popular content to the tracker and try to serve polluted (i.e., decoy content or even virus/trojan infected contents) to other peers. For trackers, they don't exchange content information among peers, hence they are difficult to detect if a peer is polluting the content or not. Usually, this kind of pollution can be detected by PPSPP [RFC7574]. More details can be seen in Section 6.1 and Section 12 of [RFC7574].

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> - I-D nits notes a bunch of missing reference entries, e.g.
> for RFC6972 as well as 6 others. Probably some xml2rfc issue.

[Rachel]: Will fix it in the new version.
> - intro: last para (just before 1.1) puzzles me. Not sure why it''s there.

[Rachel]: How about changing to 

   This document describes the base PPSP Tracker protocol and how it
   satisfies the requirements for the IETF Peer-to-Peer Streaming
   Protocol, in order to derive the implications for the standardization
   of the PPSP streaming protocols and to identify open issues and
   promote further discussion.

This document introduces a base PPSP Tracker Protocol which satisfies the requirements from [RFC6972].
> - intro: why is there no mention of Bit Torrent? This seems to be the same
> design for the same purpose, and BT is in widespread use so not explaining the
> relationship seems a bit odd. 5.1.2 seems to be plain silly in that light, while BT
> is not a "standard" that is irrelevant - it has been widely deploy and migration
> from BT to this, or co-existence, would seem critical to the success of this
> effort.

[Rachel]: Actually, at the drafting of PPSP-TP, there's another draft [draft-ietf-ppsp-survey] which has described most of the popular and deployed p2p applications. Currently, [draft-ietf-ppsp-survey] is dead, so maybe we should include some BT descriptions in our draft?

> - RFC2616 is obsoleted.

[Rachel]: Will update.

> - 6.1: I agree with Katheen's discuss, a MUST use TLS is needed here really and
> just reflects reality and is not an additioanl consideration. It is needed for
> clarity though.

[Rachel]: Ok.

> - 6.2: Given the history of spoofing in BT I wondered why there is no object level
> origin auth defined here.

[Rachel]: How about adding a paragraph in Section 6.2 as following:

Some attackers that disrupt P2P streaming on behalf of content providers may provide false or modified content or peer list information to achieve certain malicious goals. Peers connecting to those portals or trackers provided by the attackers may be redirected to some corrupted malicious content. However, there is no standard ways to for peers to avoid this kind of situations completely. Peers can have mechanisms to detect undesirable content or results themselves. For example, if a peer finds the portal returns some undesired content information or the tracker returns some malicious peer lists, the peer may want to quit the swarm, or switch to other P2P streaming services provided by other content providers.

> - I also agree with Ben's discuss.