RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (4)

RFC 7574, "Peer-to-Peer Streaming Peer Protocol (PPSPP)", July 2015

Source of RFC: ppsp (tsv)

Errata ID: 4724
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Sung Hei Kim, Chang Kyu Lee
Date Reported: 2016-07-01
Verifier Name: Spencer Dawkins
Date Verified: 2017-08-21

Section 1.3 says:

swarm ID
Unique identifier for a swarm of peers, in PPSPP a sequence of
bytes. For video on demand with content integrity protection
enabled, the identifier is the so-called root hash of a Merkle
hash tree over the content. For live streaming, the swarm ID is
a public key.

It should say:

swarm ID
Unique identifier for a swarm of peers, in PPSPP a sequence of
bytes. For video on demand, the identifier is the so-called root hash
of a Merkle hash tree over the content. For live streaming, the 
swarm ID is a public key.

Notes:

According to chapter 5 and chapter 6.1, it seems that it is not mandatory to use content integrity protection scheme.
The definition of swarm ID in the original text does not define how the ID is used in environment with the content integrity protection disabled.
It is possible to add new description on how swarm ID is defined in the content integrity protection scheme is disabled.
Or, it is possible to remove the parts regarding content integrity protection.

We propose to remove "with content integrity protection enabled" part.

Spencer: confirmed in conversations with Victor Grishchenko <victor.grishchenko@gmail.com> on the PPSP mailing list.

Errata ID: 4725
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Sung Hei Kim, Chang Kyu Lee
Date Reported: 2016-07-01
Verifier Name: Spencer Dawkins
Date Verified: 2017-08-21

Section 5 says:

PPSPP can use different methods for protecting the integrity of the
content while it is being distributed via the peer-to-peer network.
More specifically, PPSPP can use different methods for receiving
peers to detect whether a requested chunk has been maliciously
modified by the sending peer. In benign environments, content
integrity protection can be disabled.

For static content, PPSPP currently defines one method for protecting
integrity, called the Merkle Hash Tree scheme. If PPSPP operates
over the Internet, this scheme MUST be used. If PPSPP operates in a
benign environment, this scheme MAY be used. So the scheme is
mandatory to implement, to satisfy the requirement of strong security
for an IETF protocol [RFC3365]. An extended version of the scheme is
used to efficiently protect dynamically generated content (live
streams), as explained below and in Section 6.1.

It should say:

PPSPP can use different methods for protecting the integrity of the
content while it is being distributed via the peer-to-peer network.
More specifically, PPSPP can use different methods for receiving
peers to detect whether a requested chunk has been maliciously
modified by the sending peer.

For static content, PPSPP currently defines one method for protecting
integrity, called the Merkle Hash Tree scheme.
The scheme is mandatory to implement, to satisfy the requirement of 
strong security for an IETF protocol [RFC3365]. An extended version
of the scheme is used to efficiently protect dynamically generated
content (live streams), as explained below and in Section 6.1.

Notes:

RFC 7574 (PPSP-PP) defines how the peers exchange chunks regarding content integrity protection scheme. It describes the relationship of the DATA and INTEGRITY messages.
But, it does not describes how peers exchange chunks when the content integrity protection scheme is disabled.
Thus, to the readers, it seems that content integrity protection scheme is very important part of PPSP-PP and must be used in order to implement PPSP-PP.
I think the RFC 7574 (PPSP-PP) should be changed to clearly express that the content integrity protection scheme must be used in PPSP-PP.
The proposed changes is to remove options regarding the use of content integrity protection.

Spencer: confirmed in conversations with Victor Grishchenko <victor.grishchenko@gmail.com> on the PPSP mailing list.

Errata ID: 4726
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Sung Hei Kim, Chang Kyu Lee
Date Reported: 2016-07-01
Verifier Name: Spencer Dawkins
Date Verified: 2017-08-21

Section 6.1 says:

In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash
Tree scheme for static content with signatures to unify the video-on-
demand and live streaming scenarios. The use of Merkle hash trees
reduces the number of signing and verification operations, hence
providing a similar signature amortization to the approach described
in [SIGMCAST]. If PPSPP operates over the Internet, the "Unified
Merkle Tree" method MUST be used. If the protocol operates in a
benign environment, the "Unified Merkle Tree" method MAY be used. So
this method is mandatory to implement.

It should say:

In the "Unified Merkle Tree" method, PPSPP combines the Merkle Hash
Tree scheme for static content with signatures to unify the video-on-
demand and live streaming scenarios. The use of Merkle hash trees
reduces the number of signing and verification operations, hence
providing a similar signature amortization to the approach described
in [SIGMCAST].

Notes:

RFC 7574 (PPSP-PP) defines how the peers exchange chunks regarding content integrity protection scheme. It describes the relationship of the DATA and INTEGRITY messages.
But, it does not describes how peers exchange chunks when the content integrity protection scheme is disabled.
Thus, to the readers, it seems that content integrity protection scheme is very important part of PPSP-PP and must be used in order to implement PPSP-PP.
I think the RFC 7574 (PPSP-PP) should be changed to clearly express that the content integrity protection scheme must be used in PPSP-PP.
The proposed changes is to remove options regarding the use of content integrity protection.

Spencer: confirmed in conversations with Victor Grishchenko <victor.grishchenko@gmail.com> on the PPSP mailing list.

Errata ID: 4880
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Sung Hei Kim, Chang Kyu Lee
Date Reported: 2016-12-07
Verifier Name: Spencer Dawkins
Date Verified: 2017-08-21

Section 7.5 says:

   A peer MUST include the content integrity method used by a swarm.
   The code for this option is 3.  Defined values are listed in Table 4.

                   +--------+-------------------------+
                   | Method | Description             |
                   +--------+-------------------------+
                   | 0      | No integrity protection |
                   | 1      | Merkle Hash Tree        |
                   | 2      | Sign All                |
                   | 3      | Unified Merkle Tree     |
                   | 4-255  | Unassigned              |
                   +--------+-------------------------+

            Table 4: PPSPP Content Integrity Protection Methods

It should say:

   A peer MUST include the content integrity method used by a swarm.
   The code for this option is 3.  Defined values are listed in Table 4.

                   +--------+-------------------------+
                   | Method | Description             |
                   +--------+-------------------------+
                   | 0      | Unassigned              |
                   | 1      | Merkle Hash Tree        |
                   | 2      | Sign All                |
                   | 3      | Unified Merkle Tree     |
                   | 4-255  | Unassigned              |
                   +--------+-------------------------+

            Table 4: PPSPP Content Integrity Protection Methods

Notes:

As stated in the first sentence of chapter 7.5, “A peer MUST include the content integrity method used by a swarm.”, “No integrity protection” must not be one of the option for PPSPP content integrity protection method. Or, IETF 7574 must define PPSP-PP that does not use the integrity protection method.

The proposed is to remove option of “No integrity protection” in Table 4.

Spencer: confirmed in conversations with Victor Grishchenko <victor.grishchenko@gmail.com> on the PPSP mailing list.

Report New Errata



Advanced Search