Date: November 17, 2022
Request for Publication of: "RTP Payload Format for the Secure Communication
Interoperability Protocol (SCIP) Codec" Document:
https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-scip WG:
AVTCORE Type: Proposed Standard Shepard: Bernard Aboba
<bernard.aboba@gmail.com>
Document Overview
This document describes the RTP payload format of the Secure
Communication Interoperability Protocol (SCIP). SCIP is an
application layer protocol that defines the establishment of reliable
secure end-to-end communications, including capabilities exchange
with secure session establishment parameters such as codec selection,
encryption algorithms, security levels, and cryptographic
initialization values. This document defines the Session Description
Protocol (SDP) and RTP parameters needed to support SCIP over RTP.
The SCIP codec produces a bitstream that this specification endeavors
to transport over RTP. Unlike other codecs, SCIP does not have its own
upper layer syntax (e.g. no NAL units), but rather secures the output
of the codecs that it uses (e.g. G.711, H.264, etc.). SCIP achieves
this by encrypting codec output that has been previously formatted
according to the relevant RTP payload specification (e.g. RFC 6184
for H.264/AVC).
Since SCIP includes its own facilities for capabilities exchange,
it is only necessary to negotiate the use of SCIP within SDP
Offer/Answer; the specific codecs to be encapsulated within SCIP
are then negotiated via the exchange of SCIP messages.
While SCIP provides for secure end-to-end communications, in
conferencing scenarios the conferencing server is considered "trusted"
so that it is granted access to cleartext media and can support
operations such as mixing, transcoding or re-packetization,
that are not permitted in "end-to-end" security schemes such as
PERC or SFrame where the conferencing server is not trusted.
Shepherd Write-Up
1. Document History
a. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?
The AVTCORE WG has discussed the "RTP Payload Format for the SCIP Codec" at
multiple meetings. WG Last Call was announced on April 8, 2022 and concluded
on May 8, 2022:
https://mailarchive.ietf.org/arch/msg/avt/JKrPnCPMHgb6IIAfwyZhc-wF0a4/
As noted in the thread, 19 individuals indicated their support for advancement
of the document, which is more than any AVTCORE WG document in recent memory.
The Call for Adoption (CfA) announcement also elicited a large response
(39 responses) as noted below:
https://mailarchive.ietf.org/arch/msg/avt/vufEcYOXx7KWgfEx3tPoc0u2Wc0/
At this point, there is broad support for moving forward.
b. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?
There have been questions relating to the architectural differences between
SCIP and other "end-to-end" security schemes such as PERC and SFrame. Since
SCIP includes support for capabilities exchange, it is only necessary to
negotiate support for SCIP within SDP Offer/Answer; the details of the specific
codecs encapsulated in SCIP (e.g. G.711, H.264) are handled within SCIP and do
not need to be negotiated in SDP O/A. Since in SCIP the conference server is
considered trusted and has access to cleartext media, SCIP does not require
that conferencing servers support "codec independent forwarding". Once
explained, these points have not been controversial.
Reviewers have questioned whether the informative references to SCIP WG
documents should be normative. While other RTP Payload Format documents have
contained normative references to codec documents (e.g.
draft-ietf-avtcore-rtp-vvc contains a normative reference to the VVC codec
specification) in this case, the WG came to agreement that the references to
SCIP WG documents should remain informative. Since the SCIP codec includes its
own signaling as well as media transport functionality, the main requirement
for intermediaries such SBCs is to avoid removing the SCIP codec within Offers
and Answers, as well as to pass the SCIP RTP payloads unmodified.
There have also been questions about how to obtain access to SCIP WG
specifications. An email address has been provided which can be used to request
the documents. Multiple WG participants (including the shepard) have requested
the documents and have been provided with them.
c. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)
No indications of extreme discontent or intent to appeal.
d. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as RFC 7942 recommends) or elsewhere
(where)?
SCIP over RTP has been implemented and widely deployed in endpoints, such
as communication devices utilized by members of the North Atlantic Treaty
Organization (NATO). One of the motivations for publishing this document
as a Proposed Standard is to address interoperability issues with
Session Border Controllers (SBCs).
Since the SCIP protocol negotiates end-to-end secure communications, SBCs
need to recognize SCIP audio/video in SDP as well as refraining from
modifying the contents of the RTP payloads containing SCIP messages. Since
those messages are secured end-to-end, attempts to transcode or otherwise
modify the RTP payloads result in communications failure.
2. Additional Reviews
a. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.
The SCIP protocol is defined by the SCIP WG, who have been active in the
creation and maintenance of SCIP for more than a decade. Since SCIP over
RTP has been widely deployed, the protocol as well as its transport over
RTP is presumably well understood (except perhaps by SBC vendors).
Several directorate reviews have been requested and completed:
ARTART Review (Ready with Issues):
https://datatracker.ietf.org/doc/review-ietf-avtcore-rtp-scip-02-artart-early-fenton-2022-10-10/
SECDIR Review (Has Issues):
https://datatracker.ietf.org/doc/review-ietf-avtcore-rtp-scip-02-secdir-early-nystrom-2022-09-07/
GENART Review (Ready with Issues):
https://datatracker.ietf.org/doc/review-ietf-avtcore-rtp-scip-01-genart-early-bryant-2022-06-30/
SDP Directorate Review:
https://mailarchive.ietf.org/arch/msg/avt/7yqJcKcF_vWGQG0q7vxbRpeSpoU/
The authors made changes to the specification to response to these reviews.
b. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
The document does not define any MIBs, YANG modules or URI types.
Media sub-type allocations were approved for SCIP prior to submission of this
document. See Section 5.1 ("audio/scip") and Section 5.2 ("video/scip")
c. If the document contains a YANG module, has the final version of the module
been checked with any of the recommended validation tools for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time? Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in RFC 8342?
No YANG module.
d. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.
No formal languages.
3. Document Shepherd Checks
a. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?
The wide response to the Call for Adoption (CfA) and WGLC Announcements
indicates that the document is needed.
My review of the document is here:
https://mailarchive.ietf.org/arch/msg/avt/8Kpakxp78_jnux9P2_iD0L4VkxQ/
The authors have made changes to the document to respond to those comments.
https://mailarchive.ietf.org/arch/msg/avt/Y8XHPhLN5yRzt_BB7g3i-LY42gk/
b. Several IETF Areas have assembled lists of common issues that their
reviewers encounter. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?
As an RTP Payload format, it is not clear what Common Issues lists would
apply, if any.
c. What type of RFC publication is being requested on the IETF stream (Best
Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?
Proposed Standard.
d. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in BCP 79? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.
Yes. The authors have been asked to acknowledge their responsibilities
under BCP 78 & 79, and have responded:
https://mailarchive.ietf.org/arch/msg/avt/JaHArf3iaehSNoyEozJur3zU050/
Dan Hanson:
https://mailarchive.ietf.org/arch/msg/avt/X6ZNoJ2Vbo2sgSQHPSOjw8dcwlM/ Keith
Maver: https://mailarchive.ietf.org/arch/msg/avt/Lscy9_6tOm7QbBViHL2lahP3Fnk/
Michael Faller:
https://mailarchive.ietf.org/arch/browse/avt/?gbt=1&index=Lscy9_6tOm7QbBViHL2lahP3Fnk
e. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.
The authors were queried for their willingness to be listed:
https://mailarchive.ietf.org/arch/msg/avt/vZ3UmljJPlu3IqmDlAaHRnHC4Qc/
Each has responded with their willingness to be listed:
Michael Faller:
https://mailarchive.ietf.org/arch/msg/avt/zOJHt8z2tBvgsNX9dSn2ORZLkbQ/ Keith
Maver: https://mailarchive.ietf.org/arch/msg/avt/4BgsmsMIiwi9eN6aA4MN-FYhiKE/
Dan Hanson:
https://mailarchive.ietf.org/arch/msg/avt/hDDON7rzo1r_p2ElGJJKNABE04E/
f. Document any remaining I-D nits in this document. Simply running the idnits
tool is not enough; please review the "Content Guidelines" on
authors.ietf.org. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)
There do not appear to be any remaining I-D nits in the document:
idnits 2.17.00 (12 Aug 2021)
/tmp/idnits28550/draft-ietf-avtcore-rtp-scip-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
No issues found here.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
No nits found.
--------------------------------------------------------------------------------
g. Should any informative references be normative or vice-versa? See the IESG
Statement on Normative and Informative References.
The WG has discussed whether the references to the SCIP WG documents should be
normative, and has concluded that they should be informative.
h. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?
The references to the SCIP WG documents are informative. An email address has
been provided through which those documents can be requested. Multiple WG
participants requested access and were provided with the documentation without
fees.
i. Are there any normative downward references (see RFC 3967 and BCP
97) that are not already listed in the DOWNREF registry? If so,
list them.
No normative downward references.
j. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?
No normative references to documents that are not ready to be submitted to the
IESG or are in an unclear state.
k. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.
This document does not change the status of any existing RFCs.
l. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see RFC 8126).
IANA had previously reviewed and allocated the media sub-types requested in this
document (Sections 5.1 and 5.2), so that further review did not appear
necessary.
m. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.
No new IANA registries.