Skip to main content

Early Review of draft-ietf-avtcore-rtp-scip-01
review-ietf-avtcore-rtp-scip-01-genart-early-bryant-2022-06-30-00

Request Review of draft-ietf-avtcore-rtp-scip
Requested revision No specific revision (document currently at 09)
Type Early Review
Team General Area Review Team (Gen-ART) (genart)
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-06-30
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 Stewart Bryant
State Completed
Request Early review on draft-ietf-avtcore-rtp-scip by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/UqpTwkxRsJyLZHQA9FAqx8R0z4o
Reviewed revision 01 (document currently at 09)
Result Ready w/issues
Completed 2022-06-30
review-ietf-avtcore-rtp-scip-01-genart-early-bryant-2022-06-30-00
This simple document is adequate to register the media type as is. There are
however a few small issues that could usefully be addressed.

The introduction could usefully be expanded to include a couple of sentences on
context and a direct reference to the protocols rather than a pointer to the
IANA registry from which the reader has to get a pointer to the protocol.
Bringing forward some material from the background to the introduction or
merging the two sections would achieve this.

The RFC 2119 language is not the latest version:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

I am surprised that the nits checker did not bring this up.

In the text SCIP is sometimes capitalised and sometimes in lower case, they
clearly mean different things but I could not see any text in the document that
clarified the semantics of each variant.

The references SCIP210 and SCIP214 are shown as informational. I assume that as
much as anything this is because they are not widely available and strictly you
could just treat them as opaque, but given they are fundamental to what you are
standardising I would have expected them to be normative.