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

[Stephan Wenger <[e-mail]>]

Hi Paul,

Thanks for your review.  Comments below in blue.

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

--- Begin Message ---

Hi Roman,

Thanks for your review and for the time you spent on it.  Please see inline in blue.

To summarize, I propose to address some of your comments editorially during AUTH48.

Stephan

 

On 6/14/22, 08:45, "Roman Danyliw via Datatracker" <[e-mail]> wrote:

 

[…]

 

 

    The document, along with other ballot positions, can be found here:

    https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/

 

 

 

    ----------------------------------------------------------------------

    COMMENT:

    ----------------------------------------------------------------------

 

    ** Section 1.1.2.

 

    The decoding capability information includes parameters that stay

       constant for the lifetime of a VVC bitstream, which in IETF terms can

       translate to a session .

 

    I appreciate the clarity.  Would it be possible reframe this to be explicit on

    the definition of this “IETF session” for a reader that might not know what

    that means?

 

You got us there. :-).   In the IETF RTP and conferencing world, the term “session” is unfortunately ill-defined.  There are even quite regularly misunderstandings about the term “RTP session”, which is reasonably well defined, but is not what we mean here.    

Reading through this again, I think we should remove the reference to “IETF session”.  Instead, we should use more colloquial terms, such as “duration of a video conference, continuous video stream, and similar—any video that is processed by a decoder between setup and teardown.  For streaming, the requirement of constant parameters pertains through splicing.” Would that work for you?

 

 

    ** Section 4.3.1.  What is the Type value in the PayloadHdr of this Single NAL

    Unit Packet?  Section 4.3.2 which describes APs says its type value is 28. 

    Section 4.3.3 which describes fragments says its type is 29.  [VCC] is behind a

    paywall so I am unable to check the Table 5 per the reference in Section 1.1.4.

 

So first, VVC is not behind a paywall.  Like all ITU Recommendations you can download it for free.  Please see here: https://www.itu.int/itu-t/recommendations/rec.aspx?rec=14948  Behind the link above, you wish to click on the “Superseded” 2020 version.  The pre-published V2 (dated 4/22) is indeed only downloadable for TIES users only, for the time being, until the final editing process by the ITU is complete.  However, we reference V1 in our spec.  Even the ISO version is free as, after long deliberation, the power that be in ISO found no wisdom in charging money for a document that can be downloaded, with their consent, for free elsewhere :-).  

Inside H.266v1, you’ll find the NAL unit type codes in section 7.4.2.2 and Table 5.  In that table, NAL unit type codes 28..31 inclusive are marked as “unspecified”, which is JVET’s way to say that those codes can be used by other standards to carry structures not defined by JVET, and are guaranteed not to be used by JVET in the future.  

Now, going back to the VVC payload draft, we use that “extension by external spec” mechanism of H.266.  In particular, we assign the value 28 for aggregation packets, and 29 for fragmentation packets.  For a single NAL unit packet, the payload format doesn’t use its own header, for bitrate savings.  Instead, the H.266 NAL unit header data co-serves as the payload header.  Insofar, the type field uses one of the 28 NAL unit types defined in the H.266 spec in aforementioned location.  This co-serving property of NAL unit headers and payload headers was first introduced in RFC 3984, and has been part of the RTP payload formats for NAL unit based codecs ever since, so we expect implementers to be generally familiar with it.

In this light, do you think we need additional language?  (We intentionally kept informative language to the minimum, because engineers who implement this spec, in practice, need to be familiar with the VVC spec also, and that spec has virtually no informative language.)

   

 

    ** Section 4.3.1.  An early reference to sprop-max-don-diff defined later in

    the document would be very helpful.

 

I agree, and we can add that during AUTH48, assuming you guys agree.  It’s an editorial-only change.

 

    ** Section 4.3.3.

       FuType: 5 bits

 

          The field FuType MUST be equal to the field Type of the fragmented

          NAL unit.

 

    What is the reference for the possible values of this field?

 

The language is unambiguous.  It’s one of the 28 NAL unit types defined by JVET (see above).  Which one depends on the NAL unit that is being fragmented.  I suggest no change here.

 

    ** Section 9.  Thank you for discussing the trade-offs with deploying the MANE.

     Since E2E security was noted for deployments without the MANE, please also be

    explicitly on what including the MANE means.

 

    OLD

       To be allowed to perform

       such operations, a MANE is required to be a trusted entity that is

       included in the security context establishment.

 

    NEW

    To be allowed to perform such operations, a MANE is required to be a trusted

    entity that is included in the security context establishment. This on-path

    inclusion of the MANE forgoes end-to-end security guarantees for the end points.

 

Fine, and we can implement this during AUTH48.

 

 

--- End Message ---