Re: [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: sframe@ietfa.amsl.com
Delivered-To: sframe@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DEEB3A0B7E for <sframe@ietfa.amsl.com>; Thu, 10 Sep 2020 07:19:20 -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=unavailable 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 6p5jdWx_QhbW for <sframe@ietfa.amsl.com>; Thu, 10 Sep 2020 07:19:16 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 C65413A0B83 for <sframe@ietf.org>; Thu, 10 Sep 2020 07:19:16 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id o16so6161281qkj.10 for <sframe@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=myr+1YyzPJ7FeXlbAnHhjYxKzQg3Z2uf0tT6GN2TgeLOFT7xnEFbwYJ3SzsH89fmtv P6NdrmidDGSZlWzJ3SZHDA26+FVsDgJBvXv6HCTt8iaX6agGs03vgYmw84eb9GYpTIrJ O37LKTFpZGjBhxpEU1PJf3XkYse19yUlir1yATHm5YUn7UvlSkkDbatT6lJux2UD2PO3 pDnqsIEqO7FbKwEUWklthiFLQNz+0fxT3qkCufx4CyMfPhF+U/rEwi9YA26Argl0eoBb 354rWT2jmbXabCygZl0CWBiWQA4hA63KzuFbdxtVczcDpcgICoXHvt5tC4XLiR4q7ST4 q+Jg==
X-Gm-Message-State: AOAM532deFO+efSnBr0C68xXFHyRJeOYm0aXapiTepWUvz1/ObbQ8Tku q8AwIZGg3ZYuoALWL/wtT0PpCOaWXURqyDlVjELjuA==
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/sframe/Qn-q15byuuxGjer_hg0uTqUF0CE>
Subject: Re: [Sframe] Magnus Westerlund's Block on charter-ietf-sframe-00-00: (with BLOCK and COMMENT)
X-BeenThere: sframe@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <sframe.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sframe>, <mailto:sframe-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sframe/>
List-Post: <mailto:sframe@ietf.org>
List-Help: <mailto:sframe-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sframe>, <mailto:sframe-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 14:19:20 -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
>