Ballot for draft-ietf-avtcore-rtp-scip
Discuss
Yes
No Objection
No Record
Summary: Has 2 DISCUSSes. Needs 4 more YES or NO OBJECTION positions to pass.
(I conducted my review without access to [SCIP210]) ** Section 4. It isn’t clear what the format of the payload is from the description provided in this text beyond asserting that it is negotiated via SCIP-210 and that the SCIP codec is an encrypted bitstream. Are all details entirely opaque? If so, can the text please be more explicit in stating that. ** Section 6. RFC7202 appears to be cited here as a reminder to the reader that there are a variety of possible security solutions in the RTP ecosystem. My confusion is that it isn’t clear how this flexibility applies in the case of SCIP. It appears that there is tight coupling between the SCIP session negotiation and the embedded content in the RTP stream. Specifically, Section 4 notes that “The SCIP codec produces an encrypted bitstream that is transported over RTP.” Doesn’t the use of an SCIP payload (the blob generated by a SCIP codec) imply a set of security properties? Where are those formally documented? Section 2 hints at them being “end-to-end security at the application layer, authentication of user identity, the ability to apply different security levels for each secure session, and secure communication over any end-to-end data connection.”
Thank you to Magnus Nystrom for the early SECDIR review. ** Section 1. This document details usage of the "audio/scip" and "video/scip" pseudo-codecs [AUDIOSCIP], [VIDEOSCIP] as a secure session establishment protocol and media transport protocol over RTP. It details how encrypted audio and video codec payloads are transported in RTP packets. I was unable to find the text which describes the “secure session establishment protocol” behavior beyond statements in Section 4 which way SCIP is used for that purpose. Could forward reference be provided? ** Section 2. Editorial. SCIP also provides several important characteristics that have led to its broad acceptance in the international user community. Consider scoping “international user community” a bit more narrowly as Section 1 states that the deployment is limited to “United States and NATO”. ** Section 2. These features include end-to-end security at the application layer, authentication of user identity, the ability to apply different security levels for each secure session, and secure communication over any end-to-end data connection. Is there a specific reference on how these security properties are realized and implemented? ** Section 2. Editorial. s/A combined Department of Defense/A combined US Department of Defense/ ** Section 2. Editorial. This RFC provides essential information about audio/scip and video/ scip media subtypes that enables network equipment manufacturers to include "scip" as a known audio and video media subtype in their equipment and enables network administrators to define and implement a compatible security policy. It wasn’t clear which text in this document was intended to inform the definition of security policies.
Thanks for working on this specification. My understanding is that SCIP is not a typical audio/video codec and intention here is to defice a payload format used along with other audio/video codecs. Thanks to Olivier Bonaventure for an excellent TSVART review.
I would like to discuss the followings -
- It is not clear to me what RTP profile should be used with this payload format. The RTP profiles are mentioned only in the security considerations. I think this specification would not be sufficient to be implemented without specifying the profile usage. I am getting that all the control messages are sent as SCIP messages, hence it needs to be clear on the RTP/RTCP usage.
- This statement needs to be clarified more -
"SCIP traffic is highly variable and the bit rate specified in the SDP [RFC8866] is OPTIONAL since discontinuous transmission (DTX) or other mechanisms may be used."
What does this "highly variable" traffic mean? In what sense it is variable, variable bitrate? if this is highly variable how this would react to congestion and rate control?
what bitrate is specified in the SDP? are you talking about the "b" parameter and interpretation of that? how is that to be interpreted in the session level and media level due to DTX?
- it says -
"a jitter buffer MAY be implemented in endpoint devices only"
Given that "both discontinuous and continuous traffic are highly probable", a jitter buffer is a MAY? How to handle late loss or reordering? is it expected that no transmission error possible in the environment where SCIP operates?
- what is the plan to include the changes agreed to with the TSVART reviewer? I mostly agreed with the resolution agreed with the reviewer and would like to see those changes in the document before we approve this document. That is the reason I am not bringing those topics back in this discuss. Please consider them as my discuss points as well.
Some further comments - - Please add a link to SCIP specification, I had hard time finding public description or documentation of SCIP codecs. - I think it would be great to provide the design principles behind SCIP with some details. This will be helpful for understanding the motivation and rtp format specified in the document.
Clearing my DISCUSS in order to not block document progress, however I trust the responsible AD will make sure it is addressed - see thread here: https://mailarchive.ietf.org/arch/msg/avt/SlWW2g74Rl-_41MzsYBMR-sZT4o/. ==== Previous ballot ===== DISCUSS Apologies for the delayed DISCUSS ballot. I just wanted to bring a process question up before the document moves forward. Since this document will be the reference RFC for two existing media type registrations, I wonder if the change controller should be changed to IETF instead of the SCIP wg. In practice this would mean that any change to the registration would need to go through the IETF, which might make inconsistency between the RFC of reference and the registrations less likely. COMMENT Thank you for the work on this document. I also read this document without reading the SCIP spec, as that spec is referenced informatively. Many thanks to Jim Fenton for his ART ART reviews: https://mailarchive.ietf.org/arch/msg/art/VUZVeNkbH40M6Oy_yqI7Om9Lvo0/ and https://mailarchive.ietf.org/arch/msg/art/HjMttUhTSLuOJZvrvALfHHbAl90/, and to the authors for addressing Jim's comments.
Hi,
(1) p 0, sec
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.
I'm somewhat wondering why this is being published as standards track rather then informational given that the underlying protocol is not openly available.
Minor level comments:
(2) p 4, sec 4.1. RTP Header Fields
SCIP traffic may be continuous or discontinuous. The Timestamp field
MUST increment based on the sampling clock for discontinuous
transmission as described in [RFC3550], Section 5.1. The Timestamp
field for continuous transmission applications is dependent on the
sampling rate of the media as specified in the media subtype's
specification (e.g., MELPe [RFC8130]). Note that during a SCIP
session, both discontinuous and continuous traffic are highly
probable. Therefore, a jitter buffer MAY be implemented in endpoint
devices only but SHOULD NOT be implemented in network devices.
Additionally, network devices SHOULD NOT repacketize SCIP packets.
Please expand on what is meant by "repacketize SCIP packets".
Regards,
Rob
[I support Roman's DISCUSS.]