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

[Martin Stiemerling <[e-mail]>]

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


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


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.


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.


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.


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.


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.


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.


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?


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?


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.


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.


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?


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.


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.


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.


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.


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?

  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