Early Review of draft-ietf-avtcore-rtp-scip-01
review-ietf-avtcore-rtp-scip-01-artart-early-fenton-2022-07-10-00
Request | Review of | draft-ietf-avtcore-rtp-scip |
---|---|---|
Requested revision | No specific revision (document currently at 06) | |
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-10 | |
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 | Jim Fenton |
State | Completed Snapshot | |
Review |
review-ietf-avtcore-rtp-scip-01-artart-early-fenton-2022-07-10
|
|
Posted at | https://mailarchive.ietf.org/arch/msg/art/VUZVeNkbH40M6Oy_yqI7Om9Lvo0 | |
Reviewed revision | 01 (document currently at 06) | |
Result | Not ready | |
Completed | 2022-07-11 |
The information below is for an old version of the document.
review-ietf-avtcore-rtp-scip-01-artart-early-fenton-2022-07-10-00
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.