[AVTCORE] Paul Wouters' Discuss on draft-ietf-avtcore-rtp-vvc-16: (with DISCUSS and COMMENT)
Paul Wouters via Datatracker <noreply@ietf.org> Wed, 15 June 2022 13:47 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 528D2C15790B; Wed, 15 Jun 2022 06:47:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-avtcore-rtp-vvc@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com, bernard.aboba@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Message-ID: <165530085733.40665.12087635017629140595@ietfa.amsl.com>
Date: Wed, 15 Jun 2022 06:47:37 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/_UABT0i2sojkTIUX4ftu18zXJvc>
Subject: [AVTCORE] Paul Wouters' Discuss on draft-ietf-avtcore-rtp-vvc-16: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2022 13:47:37 -0000
Paul Wouters has entered the following ballot position for draft-ietf-avtcore-rtp-vvc-16: 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-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? #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 ? 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? #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. ---------------------------------------------------------------------- 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] ? 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? What does the ":" character denote in Figure 5 ,6 and 8? 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. 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? 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. 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. 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?
- [AVTCORE] Paul Wouters' Discuss on draft-ietf-avt… Paul Wouters via Datatracker
- Re: [AVTCORE] Paul Wouters' Discuss on draft-ietf… Stephan Wenger
- Re: [AVTCORE] Paul Wouters' Discuss on draft-ietf… Paul Wouters