Skip to main content

Early Review of draft-ietf-avtcore-rtp-scip-01
review-ietf-avtcore-rtp-scip-01-artart-early-fenton-2022-07-10-01

Request Review of draft-ietf-avtcore-rtp-scip
Requested revision No specific revision (document currently at 09)
Type Early Review
Team ART Area Review Team (artart)
Deadline 2022-07-22
Requested 2022-06-06
Requested by Dr. Bernard D. Aboba
Authors Dan Hanson , MikeFaller , Keith Maver
I-D last updated 2022-07-11
Completed reviews Secdir Early review of -02 by Magnus Nyström (diff)
Genart Early review of -01 by Stewart Bryant (diff)
Artart Early review of -01 by Jim Fenton (diff)
Artart Early review of -02 by Jim Fenton (diff)
Tsvart Last Call review of -04 by Olivier Bonaventure (diff)
Opsdir Last Call review of -04 by Dan Romascanu (diff)
Comments
When submitting a review, please CC the AVTCORE WG (avt@ietf.org).

As noted in the introduction, SCIP is a "pseudo-codec" that provides secure
session establishment and transport over RTP.  One of the goals of the
document is to improve interop between SCIP endpoints and intermediaries
such as SBCs and RTP relays.  For example, SBCs have been  observed to
reject SDP Offers including SCIP, and some RTP relays have attempted to
interpret or transcode SCIP RTP payloads, which is not helpful because they
are encrypted and integrity protected.

While SCIP is primarily used for secure audio communications, there is some
experience with video (H.264) as well. In conferencing use cases, SCIP
should be considered a "hop by hop" security service, in contrast to an
"end to end" service such as SFrame. That is, SCIP is compatible with audio
mixing or video MCU services, with the central conferencing server having
access to cleartext media, thereby being considered "trusted".

Note that the document has informative references to the following
documents which can be made available upon request:

         [SCIP210]   SCIP-210, "SCIP Signaling Plan", Revision 3.10, 26
                     October 2017, request access via email
                     <ncia.cis3@ncia.nato.int>nt>.

         [SCIP214]   SCIP-214.2, "Secure Communication Interoperability
                     Protocol (SCIP) over Real-time Transport Protocol
                     (RTP)", Revision 1.1, 18 April 2014, request access
                     via email <ncia.cis3@ncia.nato.int>nt>.


Bernard Aboba

For the AVTCORE WG Chairs
Assignment Reviewer Jim Fenton
State Completed
Request Early review on draft-ietf-avtcore-rtp-scip by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/VUZVeNkbH40M6Oy_yqI7Om9Lvo0
Reviewed revision 01 (document currently at 09)
Result Not ready
Completed 2022-07-11
review-ietf-avtcore-rtp-scip-01-artart-early-fenton-2022-07-10-01
I am the designated ARTART reviewer for this early review of
draft-ietf-avtcore-rtp-scip-01

Abstract: SCIP-214.2 is mentioned here but nowhere else in the document except
as a reference and in the media subtype registration. It seems inappropriate
for the sole mention to be in the abstract; should it also appear in Section 4
along with SCIP-210?

The abstract and introduction seem to present differing objectives for the
document, with the abstract focusing on the protocols themselves and the
introduction focusing more on usage.

Section 2: Might it be helpful to provide an informative reference to the FNBDT
protocol?

Section 2: The fourth and fifth paragraphs don't seem like background
information.

Section 3: While SHALL is an acceptable normative key word, I would prefer to
see MUST in this context (in addition to being more common in IETF documents).

Section 4: SCIP-210 (and perhaps SCIP-214.2) seem like they are required to
implement SCIP, and should therefore be normative references.

Section 4: "SCIP traffic may not always be..." should be reworded with better
normative language such as "The bit rate specified in SDP [RFC8866] is OPTIONAL
since discontinuous..."

Section 4.1: "The Timestamp field increments" should use normative language,
i.e., "The Timestamp field MUST increment"

Sections 5.1 and 5.2: These media subtypes are already registered with IANA and
should not be repeated here (some things like contact addresses may change, and
RFCs are immutable).

Section 6 paragraph 2: "unlikely to pose": Bad implementations might still pose
an DoS threat. Suggest "do not inherently pose".

Section 7: Please add instructions to IANA that upon publication as an RFC, the
registrations for [AUDIOSCIP] and [VIDEOSCIP] should be updated to cite this
document as a reference.

References: As suggested in the references, I requested copies of SCIP-210 and
SCIP-214.2 for my review three working days ago, and have received no response.
Section 6 of draft-kucherawy-bcp97bis-01 (not approved yet, but which seems
likely to be approved as a BCP before this document publishes) states: "At a
minimum, authors/editors of source documents need to secure freely available
copies of the target documents for use by all anticipated reviewers during the
source document's life cycle, which includes working group participants, any
member of the community that chooses to participate in Last Call discussions,
area review teams, IANA expert reviewers, and members of the IESG." You might
want to determine if that requirement can be met here.

UPDATE 2022-07-11: I received copies of SCIP-210 and SCIP-214.2 this morning.
The documents were provided for the specific purpose of this review and not to
be further distributed. It isn't clear to me whether reviewers in other
jurisdictions would be able to get the documents or not.

Authors' Addresses: The SCIP Working Group is not an author of this document,
and should not be in Authors' Addresses.