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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 14 Oct 2015 12:26:42 -0700

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ppsp-base-tracker-protocol/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

- intro: last para (just before 1.1) puzzles me. Not sure
why it''s there.

- 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.

- RFC2616 is obsoleted.

- 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.

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

- I also agree with Ben's discuss.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 22 Oct 2015 07:09:27 +0000

Hi Stephen,

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

BR,
Rachel

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Thursday, October 15, 2015 3:27 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> Zongning; [email-masked]
> Subject: Stephen Farrell's Discuss on draft-ietf-ppsp-base-tracker-protocol-10:
> (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> 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].
"

> 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 

OLD
"
   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.
"

NEW
"
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:

NEW
"
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.
"