Re: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)

Richard Barnes <rlb@ipv.sx> Thu, 10 September 2020 14:19 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7B53A0B86 for <dispatch@ietfa.amsl.com>; Thu, 10 Sep 2020 07:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX7n6hDkavb4 for <dispatch@ietfa.amsl.com>; Thu, 10 Sep 2020 07:19:16 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C325F3A0B7E for <dispatch@ietf.org>; Thu, 10 Sep 2020 07:19:16 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id w12so6187409qki.6 for <dispatch@ietf.org>; Thu, 10 Sep 2020 07:19:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OyQ8leW1TV6qpCS8oTNLkttLntIubi8YX0kdTowf6Zw=; b=wZp1s76RVSAOthlkNDELJKWmsniHzlJmUd1E7LZOjWrM3jRZdmAwxVPRpyImbzHXDN CmC6q7T+c95eaXJpE8KJQk0MVvS7wqq67DRgQn5XuAdwmgV5xZHsd79wq+r+3SRVEs8s H/fnC96Rpzg9ah7Jyc0ZsL5aCZ2XBr2LfU/UkN/oIdwas4zqwZhxEQh3DZehYA0A5yHl X7ARhMNTA2xgIapacdtLEmz67crsKIz6pEhv12m0SlhJ/LSEFdJ/L5sG9VKskVtxK4Xa 63Y67+Vy9NnHl+mgOjzew5zMK6QQaC9QeK6VR7u0kZsQAdYxRxMoZrpJQv7reMcCQn9L z57Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OyQ8leW1TV6qpCS8oTNLkttLntIubi8YX0kdTowf6Zw=; b=I5lN5wR06fVU9Vy8OHbSjI3K/NX0wp2wQOLwrCje5FrWvNtSYmur0Zo1/zRXdBoMFU qH86phDa+93eyZKI7rj1831s8kZ9fr7jJD6IVN3kX3aIAa0Ba8C4K1zOQwEGLu5ugb3m Gc1O5p2ZNHncqmsDq4VEko9ZeV7JI1W5ws+wfupVX6gPGRB3e5KlG9CtiEmbL9o7GqSY 25PSrmxEs0MQuesH6QrpqffETOQKruXenDTl1DLAWS+FkFCe+qEOd/RaON0ABzADdjze R9ZvDUSzPT6KMhKFluw7/Yv0H8YnpDEQNhKMMDYvaSc+tB4ATO5UjXbJam9dW5fxEeIn niVQ==
X-Gm-Message-State: AOAM531SraE1SBO1Wi4HUYbyHIyfj6FgZH44S+YPNELCgSX0rJGwOqx0 cEcrFjWKacJX75TnVFuZdJGUs6nuufmAMV0sdrkheg==
X-Google-Smtp-Source: ABdhPJxtAxe0KbIWdOZuDK+uW6wFxeaM3GlKU52H4GHaoP7m5FOYMhzcMzSWpllWUNZtx0d5QAc5hzqdaDs6ErG+fLQ=
X-Received: by 2002:a05:620a:1266:: with SMTP id b6mr8243318qkl.371.1599747555777; Thu, 10 Sep 2020 07:19:15 -0700 (PDT)
MIME-Version: 1.0
References: <159949693494.2875.16993532753477402380@ietfa.amsl.com>
In-Reply-To: <159949693494.2875.16993532753477402380@ietfa.amsl.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 10 Sep 2020 10:18:58 -0400
Message-ID: <CAL02cgS=y7mBt10n+jCGwUoy54eeH9ZXFijQdDSKk5Qt9mNrUw@mail.gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Cc: The IESG <iesg@ietf.org>, sframe-chairs@ietf.org, DISPATCH <dispatch@ietf.org>, sframe@ietf.org
Content-Type: multipart/alternative; boundary="000000000000caf15005aef6406c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/5a4ahNhBplGQ_hI55I4aBy-kkL0>
Subject: Re: [dispatch] [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 14:19:19 -0000

Hi Magnus,

I agree with Sergio here.  The whole idea of SFrame is to have an
encryption layer that doesn't care about any of the RTP nuances you talk
about -- all of the details of how what decoder you send the plaintext to,
substreams, etc. are handled by whatever RTP configuration mechanism you've
set up.  SFrame is just a translation layer between what you send on the
wire and what you do all the other stuff with.

Clearly, the nonce formation text is not clear.  I've made some edits.

https://docs.google.com/document/d/10rG8nAR0U6cBBPffzXnLaPPYL4uzxYViAvgiSezoa7o/edit?usp=sharing

--Richard



On Mon, Sep 7, 2020 at 12:42 PM Magnus Westerlund via Datatracker <
noreply@ietf.org> wrote:

> Magnus Westerlund has entered the following ballot position for
> charter-ietf-sframe-00-00: Block
>
> 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.)
>
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/charter-ietf-sframe/
>
>
>
> ----------------------------------------------------------------------
> BLOCK:
> ----------------------------------------------------------------------
>
> I know we have had discussion touching on this before. But post vacation
> and
> looking on this charter again I think we need to have some additional
> discussion of the goals and how the charter describes them in relation to
> encoder sub-streams and identification of what is encapsulated.
>
> In regards to the below:
>
> This working group will not specify the signaling required to configure
> SFrame
> encryption.  In particular, considerations related to SIP or SDP are out of
> scope.  This is because SFrame is intended to be applied as an additional
> layer
> on top of the base levels of protection that these protocols provide.  This
> working group will, however, define how SFrame interacts with RTP (e.g.,
> with
> regard to packetization, depacketization, and recovery algorithms) to
> ensure
> that it can be used in environments such as WebRTC.
>
> I think there exist a conflict in the above paragraph in relation to stated
> goals of the work. With the following earlier sentence: " It may also be
> desirable to encrypt units of intermediate size (e.g., H.264 NALUs or AV1
> OBUs)
> to allow partial frames to be usable." in mind creating an RTP payload
> format
> that is capable of carrying SFRAMEs that contains these units will require
> some
> interaction with the signalling. Even without these sub-stream SFRAMEs
> there
> exist a description capability that needs to exist in an RTP payload
> format for
> the end-consumer to correctly be able to route the protected data after
> decapsulation and that the end-point having that capability.
>
> If the goal here when it comes to RTP is simply to be able to treat SFRAME
> as
> CODEC in WebRTC and thus use WebRTC InsertableStreams as a receiver of the
> decrypted media ADUs. Require the use of the WebRTC application to have a
> proprietary signalling to know what this ADU is and then route it to a
> media
> decoder? I can see that working in the WebRTC only context. However, I
> would
> prefer if some thought was spent on at least having a model for what
> information may be needed to be able to handle the media streams.
> Considering
> RFC 7656 (https://datatracker.ietf.org/doc/rfc7656/) and the work that was
> needed for us to up-level how RTP worked and even discuss this so that we
> understood each other. I think SFRAME needs to discuss how it is going to
> handle identification of the data encapsulated by SFRAMEs for media. A
> single
> media source can be encoded in multiple formats. Each format may produce
> one or
> more sub-streams of encoding for scalability or robustness and this needs
> to
> conveyed.
>
> So looking at the above challenges in the context of SFRAME over RTP. So a
> possibility here is to say that the SSRC represents either just a media
> source.
> The RTP payload format provides only fragmentation of the SFRAME across
> multiple RTP packets and the RTP timestamp can be used to indicate its
> belonging in the timeline of the encoding. That puts a lot of the
> identification on the SFRAME layer, but its minimizes the signalling
> interactions related to RTP. However it creates limitation about what the
> SFU
> can do, especially when it comes to repair. Switching can be done based on
> Frame-marker extension header. However, layer related loss detection
> becomes
> impossible without additional information, or use of multiple SSRCs.
>
> Thus, I think the charter as currently written are uncertain if it can be
> executed on with stated goals.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> * Information to form a unique nonce within the scope of the key
>
> Is this really "Information to form a" the best formulation. I am
> uncertain if
> the goal is to have a specification for how to generate unique Nonce values
> within the context of a particular key, or if it is related to which
> information sources that should be used when creating a nonce?
>
>
>
> --
> Sframe mailing list
> Sframe@ietf.org
> https://www.ietf.org/mailman/listinfo/sframe
>