Re: [ppsp] 2nd part of an early AD review of draft-ietf-ppsp-problem-statement-10.txt

[Zongning <[e-mail]>]

Hi, Martin,

Sorry for the late reply due to public holidays in China. Please see below brief answers.

Thanks.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Martin Stiemerling
> Sent: Monday, October 01, 2012 11:19 PM
> To: [e-mail]
> Subject: [ppsp] 2nd part of an early AD review of
> draft-ietf-ppsp-problem-statement-10.txt
> 
> Dear all,
> 
> Here is the second part of the remainder of the
> draft-ietf-ppsp-problem-statement-10.txt:
> 
> Section 6.3., paragraph 1:
> 
>  >    The peer protocol defines how the peers advertise streaming content
>  >    availability and exchange status with each other. The peer protocol
>  >    also defines the requests and responses of the chunks among the
>  >    peers.
> 
>    The last part means the data exchange requests and respones,
>    isn't it?

[Ning] Yes.

>  >    PPSP.PP.REQ-1: The streaming content availability request message
>  >    MUST allow the peer to solicit the chunk information from other peers
>  >    in the peer list. The chunk information MUST at least contain the
>  >    chunk ID. This chunk availability information MUST NOT be passed on
>  >    to other peer, unless validated (e.g. prevent hearsay and DoS).
> 
>    This seems to be a requirement which is made up of several
>    requirements. First of all, a mechanism is required to exchange
>    information about the avail. of chunks. Second this information
>    must contain the chunk ID of available or unavailable chunks? Third,
>    do not forward this information.
> 

[Ning] We mean chunk ID of available chunks. I will separate them to multiple Req. items.

> 
> Section 6.3., paragraph 2:
> 
>  >    PPSP.PP.REQ-2: The streaming content availability reply message MUST
>  >    allow the peer to offer the information of the chunks in its content
>  >    buffer. The chunk information MUST at least contain the chunk ID.
> 
>    We do not define messages here. Only protocol requirements. This
>    holds also true for the other requirements in this section. The chunk
>    ID part is duplicated from REQ1. What is this requirement about??
> 

[Ning] Because we thought that the content avail. request & response are two basic parts of peer protocol, we list requirements (on request & response) in separate items. I am also fine with merging them.

> 
> Section 6.3., paragraph 3:
> 
>  >    PPSP.PP.REQ-3: The streaming content availability request message
>  >    SHOULD allow the peer to solicit an additional list of peers to that
>  >    received from the tracker - with the same swarm ID. The reply
>  >    message MUST contain swarm-membership information of the peers
> that
>  >    have explicitly indicated they are part of the swarm, verifiable by
>  >    the receiver. This additional list of peers MUST only contain peers
>  >    which have been checked to be valid and online recently (e.g. prevent
>  >    hearsay and DoS).
> 
>    Too many requirements packed into a single one. Please sort them
>    out into multiple requirements.
> 

[Ning] OK.

> 
> Section 6.3., paragraph 5:
> 
>  >    PPSP.PP.REQ-4: Streaming content availability update message among
>  >    the peers MUST be supported by the peer protocol. The peer protocol
>  >    MUST implement either pull-based, push-based or both.
> 
>    This seems to be related to REQ1? What is the difference?
>   I assume that a general description of the peer protocol, e.g., used
> to contanct other peers, to exchange information about what chunks are
> available, etc will help in defining the requirements.
> 

[Ning] The difference is that here we mean the content availability UPDATE (e.g. new chunks available since last request), not the whole content availability info.

> 
> Section 6.3., paragraph 7:
> 
>  >    PPSP.PP.REQ-5: The chunk availability information between peers MUST
>  >    be expressed as compactly as possible.
> 
>    Please remove this requirements, as it is not clear in technical
>    terms what 'compact' is referring to. There is no measure to say that
>    one protocol is sending more or less data for the chunk availability
>    we have agreed on. It might be good to retain this information in
>    a descriptive text, but not as a requirement.
> 

[Ning] OK. I will move this to description text.

> 
> Section 6.3., paragraph 9:
> 
>  >    PPSP.PP.REQ-6: The peer status report/update SHOULD be advertised
>  >    among the peers in order to reflect the status of the peer. Peer
>  >    status information should be advertised among the peers via the
>  >    peer status report/update message. For example, peer status can be
>  >    online time, physical link status including DSL/WiFi/etc, battery
>  >    status, processing capability, and other capabilities of the peer.
>  >    With such information, a peer can select more appropriate peers for
>  >    streaming.
> 
>    This requirement should probably read like 'the peer protocol MUST
>    support the exchange of additional information about the peers. This
>    information canbe, for instance, information about the access link
>    or information about whether a peer is running on battery or is
>    connected to a power supply.
> 

[Ning] Good suggestion, thanks.

> 
> Section 6.3., paragraph 10:
> 
>  >    PPSP.PP.REQ-7: The peers MUST implement the peer protocol for chunk
>  >    data (not availability information) requests and responses among the
>  >    peers before the streaming content is transmitted.
> 
>    What is this requirement about? I do not understand the intent of
>    this requirement.
> 

[Ning] The intention is to include more signaling messages (e.g. requesting certain chunks, and necessary negotiation for data transmission) into the scope of peer protocol.

> 
> Section 7., paragraph 2:
> 
>  >    - Originate denial of service (DOS) attacks to the trackers by
>  >    sending large amount of requests with the tracker protocol;
>  >    - Originate fake information on behalf of other peers;
>  >    - Originate fake information about chunk availability;
> 
>    I would add more a classification about where the attack can happen,
>    e.e.g., on tracker info, the info between the peers, on the content.
> 

[Ning] Good suggestion, thanks.

> 
> Section 7., paragraph 5:
> 
>  >    PPSP.SEC.REQ-1: PPSP MUST support closed swarms, where the peers
> are
>  >    authenticated.
> 
>    A closed swarm does not need necessarily authentication, but also run
>    in a wallend garden, i.e., in a private network. The requirement is
>    ok, but I would remove the authenticated here and also add a further
>    requirement adding the ability to authenticate peers. Further, this
>    requirement w/o authenticatoin does not belong here, but somewhere
>    else, e.g., what are requirements for the tracker and the peers
>    out of this?
> 

[Ning] I would prefer to keep authenticated peer and add private network case. Adding authentication requirement to tracker protocol is a good suggestion to me.

> 
> Section 7., paragraph 7:
> 
>  >    PPSP.SEC.REQ-2: Confidentiality of the streaming content in PPSP
>  >    SHOULD be supported and the corresponding key management scheme
>  >    SHOULD scale well in P2P streaming systems.
> 
>    Again, these are requirements. And, how do you define scale well?
> 

[Ning] I think one example of "scale well" is to define key/token based on peer group level, rather than content level.

> 
> Section 7., paragraph 8:
> 
>  >    PPSP.SEC.REQ-3: PPSP MUST provide an option in order to encrypt the
>  >    data exchange among the PPSP entities.
> 
>    What is 'an option' in this case? You mean more the 'ability'
>    isn't it?An option is reading more like a protocol option.
> 

[Ning] Yes, I mean "ability".

> 
> Section 7., paragraph 9:
> 
>  >    PPSP.SEC.REQ-4: PPSP MUST have mechanisms in order to limit
> potential
>  >    damage caused by malfunctioning and badly behaving peers in the P2P
>  >    streaming system.
> 
>    It will very hard, up to impossible, to proof this requirement.
> 
> 
> Section 7., paragraph 10:
> 
>  >    Such an attack will degrade the quality of the rendered media at the
>  >    receiver. For example, in a P2P live streaming system a polluter can
>  >    introduce corrupted chunks. Each receiver integrates into its
>  >    playback stream the polluted chunks it receives from its neighbors.
>  >    Since the peers forwards chunks to other peers, the polluted content
>  >    can potentially spread through the P2P streaming network.
> 
>    Please specifiy a protocol requirement to mitigate this type
>    of attack.
> 

[Ning] As suggested, I will remove Req-4 and elaborate more on Req-10.

> 
> Section 7., paragraph 11:
> 
>  >    PPSP.SEC.REQ-5: PPSP SHOULD support identifying badly behaving
> peers,
>  >    and exclude or reject them from the P2P streaming system.
> 
>    What does this mean? Logging, for instance, or list with bad peers?
> 

[Ning] Logging the peer behavior is one example. Anyway this is design guideline for PPSP system.

> 
> Section 7., paragraph 12:
> 
>  >    PPSP.SEC.REQ-6: PPSP MUST prevent peers from DoS attacks which will
>  >    exhaust the available resources of the P2P streaming system.
> 
>    I have trouble to see how this can be implemented in a protocol? If
>    a per wants to start a DoS attack, it can do it. However, the peer
>    protocol and the tracker protocols shouldn't make life easy for
>    such peers.
> 

[Ning] I think this item actually belongs to more general item like REQ-5.

> 
> Section 7., paragraph 14:
> 
>  >    PPSP.SEC.REQ-7: PPSP SHOULD be robust, i.e., when centralized tracker
>  >    fails, the P2P streaming system SHOULD still work by supporting
>  >    distributed trackers.
> 
>    This is not a security requirement, but it is a requirement for
>    the protocol design.
> 

[Ning] Good suggestion, thanks. I will move this to tracker part.

> 
> Section 7., paragraph 15:
> 
>  >    PPSP.SEC.REQ-8: Existing P2P security mechanisms SHOULD be re-used
> as
>  >    much as possible in PPSP, to avoid developing new security mechanisms.
> 
>    Not a protocol requirement, but more a design guideline.
> 

[Ning] Yes, and I think most of Req. items in the section are PPSP system design guideline. Can I clarify this at the beginning of this section?

> 
> Section 7., paragraph 16:
> 
>  >    PPSP.SEC.REQ-9: Integrity of the streaming content in PPSP MUST be
>  >    supported to provide a peer with the possibility to identify
>  >    unauthentic media content (undesirable modified by other entities
>  >    rather than its genuine source). The corresponding checksum
>  >    distribution and verification scheme SHOULD scale well in P2P
>  >    streaming system and be robust against distrustful trackers/peers.
> 
>    The descriptive text out of REQ-4 fits perfectly and it is one
>    attack vector. Remove REQ-4 keep REQ-9 and add extra requirements
>    that state what the other protocol requirements are to get rid off
>    other bad peers.
> 

[Ning] Good suggestion, thanks.

> 
> Section 7., paragraph 17:
> 
>  >    The PPSP protocol specifications will document the expected threats
>  >    (and how they will be mitigated by each protocol) and also
>  >    considerations on threats and mitigations when combining both
>  >    protocols in an application. This will include privacy of the users
>  >    and protection of the content distribution. Protection of the content
>  >    by Digital Rights Management (DRM) is outside the scope of the PPSP.
> 
>    What is the difference between 'protection of the content
>    distribution' and DRM?
> 

[Ning] I think the protection here means mechanism done by peers themselves like adding check sum, other than general methods done by parties not in PPSP system.

>   Martin
> 
> --
> IETF Transport Area Director
> 
> [e-mail]
> 
> NEC Laboratories Europe - Network Research Division NEC Europe Limited
> Registered Office: NEC House, 1 Victoria Road, London W3 6BL
> Registered in England 283
> _______________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp