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

["[e-mail]" <[e-mail]>]

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]<mailto:[e-mail]>>
Sent: Friday, January 06, 2023 12:49 PM
To: [e-mail]<mailto:[e-mail]> <Dan.Hanson=[e-mail]<mailto:Dan.Hanson=[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Wednesday, January 4, 2023 2:04 PM
To: Roman Danyliw <[e-mail]<mailto:[e-mail]>>; The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>>
Sent: Tuesday, January 03, 2023 1:56 PM
To: The IESG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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