Re: [AVTCORE] Roman Danyliw's Discuss on draft-ietf-avtcore-rtp-scip-04: (with DISCUSS and COMMENT)

[Bernard Aboba <[e-mail]>]

Dan --

Part of the reason why the IESG reviewers did not request SCIP-210 is so
they could understand whether that document should be considered
"non-normative".

Their questions (validated by my own experience) indicate that there is
information contained in SCIP-210 that helps make the draft more
understandable.

IMHO, that information is relatively small and could probably be added to
the document in a few paragraphs.  For example, one reviewer asked whether
the SCIP payloads should be considered "opaque blobs" without structure.
Perusal of SCIP-210 confirms that this is the case;  but it could easily be
stated in the document and if added would clarify how the SCIP payload and
re-assembly process works.

Similarly,  RTP payload documents typically contain a discussion of how
RTCP feedback is handled, negotiation of SDP parameters, etc.  I had asked
questions relating to those issues (which are not discussed in detail in
the document).  You answered that question on the list, but I did not fully
understand your answer until I looked at SCIP-210.  So a paragraph or two
about the negotiation that SCIP-210 handles (e.g. codec negotiation) and
what is left to SDP would be helpful.  I believe the answer is that the
SCIP RTP payload format only requires negotiation of audio/SCIP and
video/SCIP.  There is nothing in SCIP that would preclude support for
RTP/RTCP mux or BUNDLE, though current implementations don't support
either.

On Tue, Feb 7, 2023 at 11:33 AM [e-mail] <[e-mail]>
wrote:

> Roman,
>
>
>
> Have you received a copy of the SCIP-210 document?  It would answer most
> of your concerns.  Contact [e-mail] to receive a copy.
>
>
>
> Dan Hanson
> General Dynamics Mission Systems
>
>
>
> *From:* Hanson, Daniel C
> *Sent:* Wednesday, January 18, 2023 10:45 AM
> *To:* Roman Danyliw <[e-mail]>; [e-mail] <Dan.Hanson=
> [e-mail]>; The IESG <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* RE: Roman Danyliw's Discuss on draft-ietf-avtcore-rtp-scip-04:
> (with DISCUSS and COMMENT)
>
>
>
> Roman,
>
>
>
> Have you received a copy of the SCIP-210 document?  It would answer most
> of your concerns.
>
>
>
> More responses below.
>
>
>
> Dan Hanson
> General Dynamics Mission Systems
>
>
>
> *From:* Roman Danyliw <[e-mail]>
> *Sent:* Friday, January 06, 2023 12:49 PM
> *To:* [e-mail] <Dan.Hanson=[e-mail]>; The
> IESG <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* RE: Roman Danyliw's Discuss on draft-ietf-avtcore-rtp-scip-04:
> (with DISCUSS and COMMENT)
>
>
>
> *External E-mail *--- CAUTION: This email originated from outside GDMS.
> Do not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
>
>
> Hi Dan!
>
>
>
> Thanks for the follow-up.  More inline …
>
>
>
> *From:* iesg <[e-mail]> *On Behalf Of *[e-mail]
> *Sent:* Wednesday, January 4, 2023 2:04 PM
> *To:* Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> *Cc:* [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> *Subject:* RE: Roman Danyliw's Discuss on draft-ietf-avtcore-rtp-scip-04:
> (with DISCUSS and COMMENT)
>
>
>
> Roman,
>
>
>
> Responses to comments below in [DH] red.
>
>
>
> Dan Hanson
>
> General Dynamics Mission Systems
>
>
>
> -----Original Message-----
> From: Roman Danyliw via Datatracker <[e-mail]>
> Sent: Tuesday, January 03, 2023 1:56 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Roman Danyliw's Discuss on draft-ietf-avtcore-rtp-scip-04: (with
> DISCUSS and COMMENT)
>
>
>
> ----
>
> External E-mail --- CAUTION: This email originated from outside GDMS. Do
> not click links or open attachments unless you recognize the sender and
> know the content is safe.
>
>
>
> Roman Danyliw has entered the following ballot position for
>
> draft-ietf-avtcore-rtp-scip-04: Discuss
>
>
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
>
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
>
>
>
> The document, along with other ballot positions, can be found here:
>
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-scip/
>
>
>
>
>
>
>
> ----------------------------------------------------------------------
>
> DISCUSS:
>
> ----------------------------------------------------------------------
>
>
>
> (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.
>
>
>
> [DH] All of the security properties are within the SCIP-210 session
> establishment protocol so it is "opaque" at the RTP payload level.
>
>
>
> [Roman] I appreciate this clarification.  I’m still confused.  Taking the
> title of this document (“RTP Payload Format for the Secure Communication
> Interoperability Protocol (SCIP) Codec”) and the associated section title
> (“Section 4.  Payload Format”) literally, and considering that this
> document has proposed standard status, I was expecting the text to explain
> in a normative fashion how to decode or interpret the contents of the RTP
> payload.  Two common ways I could envision that could be done is by putting
> text in this document or via normative references.
>
>
>
> [Roman] The text that is present here makes an informal reference to
> SCIP-210 and provides no further guidance on how to read the RTP payload.
> As a reader, I don’t have sufficient information to understand the RTP
> payload.  It’s fine that it’s blob (in a sense, all RTP payload is a blob
> of some kind), but where is the normative reference to parse the blob.
>
>
>
> [Roman] Appreciating there is a rich IETF history in publishing “RTP
> Payload” documents, I conducted a quick survey to confirm that their
> substance is consistent with my expectations described above.  My quick
> survey of other “RTP Payload” format documents seems to confirm that they
> all devote some text to explaining how to decode what is in the RTP payload
> and crucially provide a normative reference to the associated
> codec/payload.  I looked that these:
>
>
>
> -- RFC4578 (RTP Payload Format for H.261 Video Streams)
>
> -- RFC6184 (RTP Payload Format for H.264 Video)
>
> -- RFC7587 (RTP Payload Format for the Opus Speech and Audio Codec)
>
> -- RFC7798 (RTP Payload Format for High Efficiency Video Coding (HEVC))
>
> -- RFC9134 (RTP Payload Format for ISO/IEC 21122)
>
> -- draft-ietf-payload-vp9 (RTP Payload Format for VP9 Video)
>
> -- draft-ietf-avtcore-rtp-v3c (RTP Payload Format for Visual Volumetric
> Video-based Coding)
>
>
>
> [Roman] Can the WG explain how it’s possible to describe an RTP payload
> format without citing or explaining the details of that format in a
> normative fashion?
>
>
>
> [DH] The WG decided a while back that SCIP-210 would be a informative
> reference.  Any implementor that would build a SCIP device would have
> access to the SCIP-210 specification.  Network devices (e.g., SBCs,
> Proxies, …) do not need ‘decode’ or ‘encode’ the SCIP payload blob.  They
> merely need to pass it on.
>
>
>
>
>
> ** 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.”
>
>
>
> [DH] All of the security properties are specified in SCIP-210. While the
> SCIP payload is encrypted, it does not address many of the RTP security
> issues identified in RFC7202. For example, there is no RTP header
> authentication as specified SRTP (RFC3711), nor are RTCP messages encrypted
> or authenticated.  Therefore we feel this Security Considerations
> boilerplate text still applies.
>
>
>
> [Roman] Thanks for explaining.  I respectfully disagree that the RFC7202
> boilerplate is sufficient here.  My high-level read of RFC7202 is that
> there are a range of solutions in the rich RTP ecosystem by which a generic
> RTP stream could be secured – these would apply to SCIP or anything else –
> and applications need to make the specific decisions.  What is different in
> the case of SCIP is that unlike RTP payloads such as H.261, H.264, H.265,
> V9, etc, the SCIP payload has and provides security services above an
> beyond whatever would be provided by RTP.  If the RTP payload of SCIP is
> being described by the document, the residual (above an beyond RTP)
> protections it affords need to be described or cited.
>
>
>
> [DH] SCIP only encrypts the payload; it does not provide the other
> security services suggested in RFC7202.
>
>
>
> ----------------------------------------------------------------------
>
> COMMENT:
>
> ----------------------------------------------------------------------
>
>
>
> [snip]
>
>
>
> [DH] With respect to network equipment manufacturers, the intent is to
> inform them of the existence of the “scip” payload so they can allow “scip”
> to traverse their networks.  There is no “implementation” of SCIP itself in
> network equipment such as Session Border Controllers or Call Managers.
>
>
>
> [Roman] The WG understand the community better than me.  In my view, if
> the primary purpose of the document is intended to inform about the
> existence of the SCIP payload, why are the media registrations insufficient
> (https://www.iana.org/assignments/media-types/video/scip,
> https://www.iana.org/assignments/media-types/audio/scip)?
>
>
>
> [DH] It is our understanding that in order to get network devices (SBCs,
> Call Managers, …) to support SCIP, a more substantial reference beyond an
> IANA registration is needed.
>
>
>
>
>
> Regards,
>
> Roman
>