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

[Stephen Farrell <[e-mail]>]

Hi,

Sorry for my extremely slow response, but given that you've
gotten the other discusses cleared and I've not found time to
delve into this more myself, I've cleared my discuss on the
basis of your explanation below.

Thanks,
S.


On 22/10/15 08:09, Huangyihong (Rachel) wrote:
> Hi Stephen,
> 
> Thank you for your comments and sorry for our late replies. Please see inline.
> 
> BR,
> Rachel
> 
>> -----Original Message-----
>> From: Stephen Farrell [mailto:[e-mail]]
>> Sent: Thursday, October 15, 2015 3:27 AM
>> To: The IESG
>> Cc: [e-mail]; [e-mail];
>> Zongning; [e-mail]
>> 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 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.
> 
> [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].
> "
> 
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> - 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 
> 
> 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.
> "
> 
>>
>> - I also agree with Ben's discuss.
>>
>