Re: [AVTCORE] Defined by RTP profile ids for encrypted header extensions

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Fri, 31 July 2020 22:44 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147603A076C for <avt@ietfa.amsl.com>; Fri, 31 Jul 2020 15:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.961
X-Spam-Level:
X-Spam-Status: No, score=-0.961 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.116, MISSING_HEADERS=1.021, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KFocNSyWNWBQ for <avt@ietfa.amsl.com>; Fri, 31 Jul 2020 15:44:54 -0700 (PDT)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 3AE763A0764 for <avt@ietf.org>; Fri, 31 Jul 2020 15:44:54 -0700 (PDT)
Received: by mail-wr1-x42a.google.com with SMTP id z18so25696384wrm.12 for <avt@ietf.org>; Fri, 31 Jul 2020 15:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:cc:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=dEgBF1Pj0+ogm+QNldCIOmfZ1Jj858veJKVxySeuXAM=; b=ob27ElsMeYsGljvkY8c/aRXgafHHrHZmTcGjZpT6ZlDXbBxLhGXYqtV6T82/ATkjdR PIUi0u/1ZZwHg+vBhD9dSDFBKUBiZDNIM4LBhjgATy4bTesaM+cKKgEG86CQqPgE1HVb RahxhhOlLvWsIi4GanIWQUz+IV/B/Z/1RghJQ3MjEVCN28pK9QNOJYGhBbaxQpvxiYoy 63plic6svU6ZvnL9VMNYssw++KnB5otZxGdUqAIgQC+6/j6ya4wiWMapuLUayyGFzMlh yi60twHfMNYuVLEbprKAx8+CLXqRyK5ANZZeVfyz84eCHE7J8ne9Mlm68mqO2kUcFIew 5blw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=dEgBF1Pj0+ogm+QNldCIOmfZ1Jj858veJKVxySeuXAM=; b=i8ZTJMdO2Smg/5922+f810iP97ApQi+DFlrJrhDSEU5Z79wqKQY4I60p5EA4WCtJ+O BiGf1PL5gb1j2SSdVVEqcDY7TUjaVrFS8dDTDL00Q7WKzILfC96qD6kKQ9uWrSG/fRJz Odv3o2wNMRcO39oZAf/lJqJNQHUDo9xfWBKtLJEi/NMn1XnWQctH1oVDMmh1hvkXe1ek udKokzuCq3VXZaLyW+gm2/fZQXoOAx95AlmrdsvEhK72LB/pru8BuohlTZ2+G3kIX+sT 52A6BqZhiQAjXgisux1wsVijTJOVs04SArUWLJoJHt5i0Oy7+7wU7ECqGYJfksSPVc6L at+w==
X-Gm-Message-State: AOAM533niUam45wsmeegM/aXU1XMTRfZyiy0OTKMYmTFe1Mryc42p9yp Wde4DMVnuEEkFZVG5jZocT8IBxAQ0pA=
X-Google-Smtp-Source: ABdhPJy2RdPV20Dy/GQyORuDO0oG2kHcGp6yncSR/Y8/tc8/QwtOviMmXKFj5rBdFUwPuzLNA4aAnw==
X-Received: by 2002:adf:bb07:: with SMTP id r7mr5209562wrg.102.1596235492457; Fri, 31 Jul 2020 15:44:52 -0700 (PDT)
Received: from [192.168.1.36] (152.red-79-153-20.dynamicip.rima-tde.net. [79.153.20.152]) by smtp.googlemail.com with ESMTPSA id a134sm15776977wmd.17.2020.07.31.15.44.51 for <avt@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 31 Jul 2020 15:44:51 -0700 (PDT)
Cc: avt@ietf.org
References: <75f257b1-c131-1e83-4c90-03f980466303@gmail.com> <CAOJ7v-0oE=KxGfu+dv0bgxwCOzX1=LfsL2zULJYBSbW6GmkDNA@mail.gmail.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Message-ID: <9d9ed721-ff9b-9db7-7b89-7a8a0f960bdd@gmail.com>
Date: Sat, 1 Aug 2020 00:44:52 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <CAOJ7v-0oE=KxGfu+dv0bgxwCOzX1=LfsL2zULJYBSbW6GmkDNA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------869968D0C1F78E34240CA778"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/ISsxq5a5iX-GN4eVzQ1ZRc9npTQ>
Subject: Re: [AVTCORE] Defined by RTP profile ids for encrypted header extensions
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Fri, 31 Jul 2020 22:44:56 -0000

I am more prone to 1a) forbid

If we add support for id=256 extension, it would have to be backward 
compatible with the non-encrypted version as we can't negotiate 
different extensions for cryptex, so we should not widen it (id 256 is 
not valid id for a "normal" 2 byte extension). Having only 4 bits makes 
it kind of useless and I don't think any implementation supports it anyway.

Regarding ids value, I don't have a strong preference (0xC0DE, 0xC0D2 
would work for me as well), as long as we agree that we need to use two 
new different ids.

Best regards
Sergio

On 31/07/2020 1:22, Justin Uberti wrote:
> For id 256, this is news to me too. 4 bits isn't a lot of room, but if 
> we widened this to 8 bits you could stick ssrc-audio-level in here, 
> saving two bytes per packet. So the options become:
> 1a) forbid
> 1b) leave as-is, but encrypt
> 1c) widen and encrypt
>
> I would go with either 1a) or 1c). 1c) would still need to fall back 
> to a typical extension when not encrypting. (Do we know why this field 
> was historicaly chosen to be 4 bits?)
>
> Regarding id, I'm open to the simplicity argument that you make, 
> although there's also some value in having a value that's immediately 
> obvious from a Wireshark trace (0xC0DE, 0xC0D2). I think I'd lean more 
> toward the numeric approach if we went with something like 1c).
>
> On Thu, Jul 30, 2020 at 3:55 PM Sergio Garcia Murillo 
> <sergio.garcia.murillo@gmail.com 
> <mailto:sergio.garcia.murillo@gmail.com>> wrote:
>
>     Hi all,
>
>     Not sure if we got to a consensus regarding the need to introduce
>     new defined by profile ids for being able to tell if an incoming
>     packet is using the new encryption scheme to protect the csrcs and
>     the rtp headers or not.
>
>     I think we should, but in that case we need to specify two
>     different profiles ids, one for the encrypted one byte header
>     extension and another different one for the 2 bytes one. I have
>     some doubts regarding what to do with the appbits of the 2 byte
>     header extension profile id:
>
>            0                   1
>             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>            |         0x100         |appbits|
>            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>     If I have read the rfc correctly (never understood their meaning
>     until today), it is reserved for carrying the value of the header
>     extension with id 256. This would mean that the appbits for
>     extension 256 are sent unencrypted with the new approach if we
>     keep this format. Probably the best would be to forbid the usage
>     of extension 256 if cryptex is signaled.
>
>     Regarding, ids values, I love 0xC0DE for 1 byte extensions, but
>     not sure if it would be better to be consistent and use 0x1010 for
>     1 byte encrypted extensions and 0x1020 for two byte encrypted
>     extensions.
>
>     Best regard
>
>     Sergio
>
>
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     avt@ietf.org <mailto:avt@ietf.org>
>     https://www.ietf.org/mailman/listinfo/avt
>