Early Review of draft-ietf-avtcore-rtp-scip-02
review-ietf-avtcore-rtp-scip-02-secdir-early-nystrom-2022-09-07-00

Request Review of draft-ietf-avtcore-rtp-scip
Requested revision No specific revision (document currently at 06)
Type Early Review
Team Security Area Directorate (secdir)
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-09-07
Completed reviews Secdir Early review of -02 by Magnus Nystrom (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 Magnus Nystrom
State Completed
Request Early review on draft-ietf-avtcore-rtp-scip by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/luh-UArKvw5ytNi1COycC2iS5PU
Reviewed revision 02 (document currently at 06)
Result Has issues
Completed 2022-08-30
review-ietf-avtcore-rtp-scip-02-secdir-early-nystrom-2022-09-07-00
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other comments.
>

The above mentioned draft describes the RTP payload format of the "Secure
Communication Interoperability Protocol" as audio and video media subtypes,
with corresponding media subtype definitions.

While the draft as such only provides the payload formats, it seems strange
to have an Internet-Draft fully dependent on a protocol which isn't even
referenced in the memo. SCIP is mentioned several times, but there's no
reference to the definition of the protocol. The only reference is to a
"SCIP SIgnaling Plan", but access to that document appears to require an
email-based request to a NATO email address. Should such a document become
a Standards-track RFC?

The Security Considerations section only talks about possible complexity
introduced by the new media subtypes, which may be adequate, but does not
discuss general considerations to take in the context of supporting SCIP.
To my earlier comment, if SCIP itself isn't readily available, there seems
to be a gap here.

Thanks,
-- Magnus