Re: [AVTCORE] Paul Wouters' Discuss on draft-ietf-avtcore-rtp-vvc-16: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

On Wed, Jun 15, 2022 at 7:18 PM Stephan Wenger <[e-mail]> wrote:

> Hi Paul,
>
> Thanks for your review.  Comments below in blue.
>

Thanks for the extensive feedback. I have updated my ballot to No Objection.

Note, there is still one "This memo" left at the start of the Introduction
that I would change to "This document", but that's something the RFC editor
would probably be able to do as well without a new draft version.

Paul


> To summarize:
>
> Stephan
>
>
>
>
>
> On 6/15/22, 06:47, "avt on behalf of Paul Wouters via Datatracker" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>
>
> […]
>
>
>
>
>
>     The document, along with other ballot positions, can be found here:
>
>     https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/
>
>
>
>
>
>
>
>     ----------------------------------------------------------------------
>
>     DISCUSS:
>
>     ----------------------------------------------------------------------
>
>
>
>     lease be aware that this document is far outside my area of expertise,
>
>     and my comments might make no sense. Please do not be nervous to tell
>
>     me I am wrong - likely I am....
>
>
>
>     #1
>
>
>
>        [VVC] is particularly vulnerable to such
>
>        attacks, as it is extremely simple to generate datagrams containing
>
>        NAL units that affect the decoding process of many future NAL units.
>
>        Therefore, the usage of data origin authentication and data
> integrity
>
>        protection of at least the RTP packet is RECOMMENDED, for example,
>
>        with SRTP [RFC3711].
>
>
>
>     Is something is "particularly vulnerable", why is its security counter
>
>     measures only RECOMMENDED instead of REQUIRED ? Is there a real world
>
>     use case where this vulnerable protocol should continue despite the
>
>     threat without these counter measures?
>
>
>
> Please see RFC 7202 entitled “Securing the RTP Framework: Why RTP Does Not
> Mandate a Single Media Security Solution” for some of the rationale.
> Unsecured RTP is widely deployed in enterprises.  SRTP (or other hop-to-hop
> security) between endpoints and MANEs is currently the only game in town,
> commercially.  If you wish, we could add a reference to RFC 7202 to this
> paragraph.  For completeness, let me add that possible inclusion of a
> pathologic SEI message is a feature that VVC offers, and was included for
> reasons that JVET found compelling with the understanding that it could be
> a Bad Thing under certain circumstances.  I don’t believe the IETF should
> specifically try to forbid the use of mechanisms that VVC offers.  After
> all, there’s no standards police that would prohibit an implementer to
> ignore that part of the spec. :-).
>
>
>
>     #2
>
>
>
>     Media-Aware Network Element (MANE) are briefly mentioned in the
> Security
>
>     Considerations, but it is unclear to me how a user can optiin or
> opt-out
>
>     of using these or how it could even evaluate a MANE for
> trustworthiness.
>
>     Does a user even know if there is a MANE ?
>
>
>
> MANEs are everywhere.  All the commercial video conferencing tools in
> common use today, be it zoom, Webex, teams, whatnot, use them to some
> extent.  It is in practice close to impossible today to conduct a
> multipoint video conference without trusting the service provider.
>
> Obviously, I don’t know what the typical “user” knows or cares about.
> However, if the question is whether an endpoint could provide a user with
> technology that indicates whether or not a MANE is in use, then I believe
> the answer is “yes”, at least in most cases.  Heuristics may come to play.
> The question rarely, if ever rises, as no current systems use end-to-end
> security, and most commercial systems use MANEs even for point-to-point
> communication.  (There are good and valid technical and business reasons
> why they do so.)
>
> (FWIW, the IETF RTP community has long recognized this shortcoming, and
> many proposals have been made, and continue to be made, to address it.  One
> of them, cryptex, is currently considered by the IESG.  Personally, I
> believe none of those candidate solutions address the problems you mention
> in a way sufficiently generic and sufficiently unintrusive to technologies
> used in MANEs to allow for a commercially viable deployment.  Others differ
> here, obviously.)
>
>
>
>     And especially combining the two issues, if a MANE can rewrite the SEI,
>
>     would it not mean that it could attack a user with malicious data that
>
>     appear trusted?
>
>
>
> For the reason above the data would not appear to be trusted.  If one of
> the commercial service providers deploying MANEs would go into such
> shenanigans, they would probably be called out quickly and go down not much
> later.  But technically, your concern is not addressed by this draft, and I
> don’t see a way how to address it beyond requiring end-to-end security,
> which is not what the world is doing this field.  It’s IMO also not the job
> of a payload format to educate the world about security risks of a protocol
> stack that was developed before security became the thing.
>
>
>
>     #3
>
>
>
>     In the IANA Considerations, it points to another section. It is
> customary
>
>     to just make this section stand on its own with clear and explicit
> instructions
>
>     for IANA so they do not need to read or understand large parts of the
> document.
>
>
>
> I don’t think that’s what we usually do in RTP payload formats.  In fact,
> I believe all recent payload formats with a complex registration, and
> certainly all I co-authored, followed the structure we have here.  Suggest
> no action.
>
>
>
>     ----------------------------------------------------------------------
>
>     COMMENT:
>
>     ----------------------------------------------------------------------
>
>
>
>        forbidden_zero_bit.  Required to be zero in VVC.  Note that the
>
>        inclusion of this bit in the NAL unit header was to enable
>
>        transport of VVC video over MPEG-2 transport systems (avoidance of
>
>        start code emulations) [MPEG2S].  In the context of this memo the
>
>        value 1 may be used
>
>
>
>     So it MUST be zero but MAY be 1? A bit odd for a "forbidden_zero_bit".
>
>     Also, what is "this memo"? Does it mean this document or does it mean
> [MPEG2S] ?
>
>
>
> “This memo” is a leftover from the days when RFCs customarily used that
> language to refer to itself.  We can change this to “this payload format”
> if you consider it worth the (minor) hassle.
>
> There is some logic behind the “required to be zero” *in VVC,* and may be
> one *here and in other system layer specs*.  A forbidden_zero_bit equal
> to one, according to VVC, means the bitstream (or better, the part of the
> bitstream that’s carried in this NAL unit) is non-compliant.  The dumbest
> possible decoder would just throw it away.  However, historically, there
> have been smarter decoders that are capable gracefully handling a bitstream
> with a few bit errors, as were (and are) not uncommon in some (mostly
> wireless) environments.  In such a scenario, if the transport stack knew
> that there may be errors, one implementation (but not standardized)
> strategy was to set the forbidden bit but leave the bitstream otherwise
> unchanged.  A dumb decoder would drop the NAL unit as non-compliant.  A
> smarter decoder, may take the forbidden-zero-bit equal to one as a sign
> that there are gremlins here, and perhaps trigger some form of error
> concealment, defensive decoding, or whatever, to make at least partial use
> of the corrupted NAL unit.
>
> Following the general style of the VVC and other video coding specs, that
> do not include much (barely any) non-normative explanatory language, this
> explanation is not included here.  However, implementers of the payload
> spec will need to have a good understanding of VVC and if those guys
> operate in an environment that allows for bit errors, they know the above.
> If they don’t, I do not believe that this document is the right place to
> educate them.
>
> Hence, I suggest no change, except perhaps fixing “this memo” to “this
> payload format” to remove the ambiguity.
>
>
>
>     PayloadHdr appears without value in Figure 3 and with "(Type=28)" in
> Figure 4.
>
>     Does the first occurance without value also use type=28 ? If so, can
> this be
>
>     added? If not, can the non-28 value be added?
>
>
>
> You are now the third AD who complaints about this, which suggests
> something needs to be done here.  Fig. 3 is the single NAL unit mode where
> the NAL unit header as defined in the VVC spec co-serves as the payload
> header.  The type field values allowed are those allowed in VVC, which are
> 0 through 27.  If you need a more detailed explanation, please refer to my
> reply to Roman, which contains a detailed explanation of this issue
> (attached).
>
> We will add an informative note explaining this.
>
>
>
>     What does the ":" character denote in Figure 5 ,6 and 8?
>
>
>
> The begin and end of the aggregation unit, non 32-bit aligned.  Others
> complained about this as well.  We will add a note.
>
>
>
>       Fragments of the same NAL unit MUST be sent in consecutive
>
>        order with ascending RTP sequence numbers (with no other RTP packets
>
>        within the same RTP stream being sent between the first and last
>
>        fragment).
>
>
>
>     Why is this? I would say the RTP seq numbers would allow the target to
>
>     order the packets, which it has to do anyway if the network causes
> re-ordering.
>
>
>
> Error detection/concealment.  Without adding further bits, the sequence
> number relative to the first Fragmented NAL unit packet, plus the start and
> end bits, are required in combination to identify whether a full NAL unit
> can be reconstructed out of the fragments.
>
>
>
>     Why then, can the host not do this? Eg if it has two crypto modules to
>
>     indepdently encrypt these packets without needing to sync sending them
> to
>
>     ensure this requirement?
>
>
>
> Sorry, I’m not a security expert, and do not understand this scenario.
>
>
>
>         Security considerations:
>
>         See Section 9 of RFC XXXX.
>
>
>
>     Does XXXX refer to this document? eg [RFC TBD1]? Or is this a
> placeholder
>
>     for another RFC that was forgotten and needs fixing? I think it is
>
>     for this document since it has Security Considerations in Section 9.
>
>
>
> Correct.
>
>
>
>     In Section 7.3.2 starts with "This section describes the negotiation of
>
>     unicast messages" but really also describes using Multicast so it is a
>
>     but contradicting.
>
>
>
> Looking at this, I fear we have a section labelling issue.  I don’t think
> O/A is defined for multicast environments, hence the intro language is
> correct.  However, Section 7.3.2.4 should really be 7.3.3, and the
> following layer 3 sections should move down by one.
>
>
>
>        Congestion control for RTP SHALL be used
>
>
>
>     I always find MUST clearer than SHALL? Might be a non-native english
> speaker
>
>     issue contaminated by Gandalf's speech. The same paragraph uses "MUST
> monitor"
>
>     and not "SHALL monitor", so better at least use either MUST or SHALL
> for both
>
>     of these?
>
>
>
> SHALL and MUST are used interchangeably, as per RFC2119 and as spelled out
> in the intro.  My guess is that the MUSTs come more from folks in the
> author’s group who are IETFers, whereas the SHALLs come more from the ITU
> and ISO groups.  Please note that this document recycles a lot of older
> language, going back to RFC3984.  This is one of those leftovers.
>
> I suggest not to address this point.
>
>
>
>
>
>
>
>     _______________________________________________
>
>     Audio/Video Transport Core Maintenance
>
>     [e-mail]
>
>     https://www.ietf.org/mailman/listinfo/avt
>