IETF Logo Mail Archive

Re: [AVTCORE] RTP Header Extension Encryption

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Thu, 10 September 2020 21: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 354603A0E6A for <avt@ietfa.amsl.com>; Thu, 10 Sep 2020 14:44:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.045
X-Spam-Level:
X-Spam-Status: No, score=-2.045 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-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=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 XwVXOlUFa7zB for <avt@ietfa.amsl.com>; Thu, 10 Sep 2020 14:44:28 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 437B93A0E19 for <avt@ietf.org>; Thu, 10 Sep 2020 14:44:28 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id t10so8909314wrv.1 for <avt@ietf.org>; Thu, 10 Sep 2020 14:44:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=AiIB4RV7cbvUY4C+kofle8CpU2QLDUbcXtp5DzFAV0M=; b=D/NhAQu3F65lb5Dn0VZ9XVV84TzMVyW/sA/RqNQ+x5h07O1QsPOKs9Vu7YZcwaJjCs y9aLeS/KG0VgFMP+ZjEzLf+iwgTMpPM4Duc2pz7zQOl7oZluIuuPLA0GIwmeMwc81jgS fLOa7kWeCxTNI1eq/6uHX2unsWelbVtWPbpj0wiKLwzrc9rTQ0i/vs3F9JPikah9gDQn gem9pUFGgE90sxazbgpiaD7QFAOazRxd5BnYOMOrW6RK31wD++MZq81SYRs+ZBFbAVSY xULfw3ECQ2NMxXwE607J9RtmpqA7o2yshGNKu1Lh9WWlg0RHRmg9YxwkMblJB2jAk5gR 4EOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AiIB4RV7cbvUY4C+kofle8CpU2QLDUbcXtp5DzFAV0M=; b=fOQ8WqXuFqTTe5zUH4z0m4ZYGvdubZ5s0OZbvxK4d6eqvRJryjYxgM89Befh8JB9qS mVRfaJNxb7nrG2pVtj5ihleBZT4zaiNtqhhYLTdGeTnZ3u0LriK99pX5bbjajDg1gGX2 C/35NpaP8468SvUbi3v4weVc1lDNdevu1pwgE3S2P5iZy/SCEMoXrzZyt07yUd4rZo7U XVUR+xH+CHQaxMotlaZnp/FWQo+45X9JeO9uhsl13WJ1jvEKbNBAm7tRw9W3uJNQY+zp 4x36xl5eEEK1xyZi5V6OLYV59+NOX/HTFxNQvTmmWHPYZ77LVeS8hJ0pIEzeKs+2obET F7qg==
X-Gm-Message-State: AOAM532475wNRkI3ZDFFDna7V0vFvgg36yJ81qdVBtZLulmZOPShBhKZ +kUFA/0bMdmX1o+yEJJYjWZms9A0VCkARA==
X-Google-Smtp-Source: ABdhPJxR9G+qIBZmZ7C4tSCB19yFuGoAOhRMXjDpzy6XmzcEv62sWSDyN0RJQ2rDe2VJBbGqVhWA7Q==
X-Received: by 2002:adf:82e6:: with SMTP id 93mr11032049wrc.393.1599774266416; Thu, 10 Sep 2020 14:44:26 -0700 (PDT)
Received: from [192.168.0.11] (79.108.125.160.dyn.user.ono.com. [79.108.125.160]) by smtp.googlemail.com with ESMTPSA id g8sm66030wmd.12.2020.09.10.14.44.25 for <avt@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Sep 2020 14:44:26 -0700 (PDT)
To: avt@ietf.org
References: <CAOW+2dvo8z422LFeP5S652bq8RkF-SKhik=aXYXpTe9zqBX5yw@mail.gmail.com> <CAOW+2dt_A+A1AVnTUQyB4sTG5hMCv7Gf3-rrBB89LR-oacX=Rg@mail.gmail.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Message-ID: <ca4ccb1d-3ac8-75c1-9a2a-70bf1c3315b9@gmail.com>
Date: Thu, 10 Sep 2020 23:44:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CAOW+2dt_A+A1AVnTUQyB4sTG5hMCv7Gf3-rrBB89LR-oacX=Rg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------6E082BDF2B7CE1F01AB288A1"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/iol2u0vx5F7i_uVbqFr78PVtHcM>
Subject: Re: [AVTCORE] RTP Header Extension Encryption
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: Thu, 10 Sep 2020 21:44:30 -0000

Fully agree.

On 10/09/2020 23:42, Bernard Aboba wrote:
> Speaking only for myself (Chair hat off), the lesson from the RFC 6904 
> implementation experience described in the slides is that complexity 
> is the enemy of implementation correctness and also interoperability.  
>  So a goal should be to simplify the new proposal as much as possible. 
> This includes the potential to negotiate encryption of all RTP header 
> extensions "on" or "off" rather than allowing individual RTP header 
> extensions to be negotiated as encrypted or not.
>
> There was also some discussion of whether encryption could be 
> negotiated per m-line or just a blanket on/off for all m-lines.  IMHO, 
> negotiating encryption per m-line is more complex, particularly if we 
> also choose to extend the scope of encryption, so as to cover the ID 
> field (e.g. encrypt the entire RTP header extension block).  Extending 
> the scope of encryption means that the entire MID header extension 
> (including the ID field) could be encrypted.
>
> Having encryption on for some m-lines and off for other m-lines seems 
> like it would open up a number of corner cases.  If some MIDs have RTP 
> header extensions encrypted and others do not, how does an RTP 
> receiver know whether a particular RTP packet it receives has RTP 
> header extensions encrypted or not?
>
> To determine this, the receiver needs to determine the MID value, but 
> for some packets the MID header extension is encrypted, and for other 
> RTP packets it isn't. The implementer might have to do some 
> error-prone and potentially non-interoperable gymnastics, like using 
> heuristics to guess whether the RTP header extension block is 
> unencrypted or encrypted, or attempting to decrypt the RTP header 
> extension block on all received RTP packets, then checking for a MID 
> header extension to confirm that yes, the RTP header extension block 
> should have been encrypted.
>
> This complexity can be avoided if RTP header extension encryption is 
> either on or off for all MIDs. It is hard to come up with a use case 
> in which you'd only want some m-lines to have RTP header extension 
> encryption on and you'd want other m-lines to have RTP header 
> extensions sent in the clear. So the added complexity doesn't seem to 
> have a corresponding benefit.
>
> On Thu, Sep 10, 2020 at 2:14 PM Bernard Aboba <bernard.aboba@gmail.com 
> <mailto:bernard.aboba@gmail.com>> wrote:
>
>     At IETF 108, Justin Uberti lead a side meeting relating to RTP
>     header extension encryption:
>     https://www.ietf.org/proceedings/108/slides/slides-108-avtcore-rtp-header-extension-encryption-full-01
>
>     As presented in the slides there are a number of potential options
>     for moving forward. It is quite likely that we will discuss this
>     more at IETF 109, but I thought it would be useful to get mailing
>     list discussion going beforehand.
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

v2.23.0 | Report a Bug | By Email