Re: [AVTCORE] RTP Header Extension Encryption

Bernard Aboba <> Fri, 11 September 2020 19:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B6EA3A1726 for <>; Fri, 11 Sep 2020 12:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BoRZSieMI_er for <>; Fri, 11 Sep 2020 12:00:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B1003A16D8 for <>; Fri, 11 Sep 2020 12:00:26 -0700 (PDT)
Received: by with SMTP id d15so6861838lfq.11 for <>; Fri, 11 Sep 2020 12:00:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j6qBbZuaxDGlv87jREDyMzxehiiROhYHAAkHHiWvk68=; b=JcBqW8/GdX13ze0JerIUlBnaLdBGF5B2wIPOC3vdhkvUDpRYChtnzq5y7/aKkS8UH+ MKV3hnvV7snflD+rRkSMpYz0nHeI/Zs/bO8OdpmGv+jYLbxQXCYuaRZWOrkRCTjNFhks GqSdfeT015K823F18lXSMlMX9MxDbeFMifltIf0Pt1WAG04tbvkP18Lpae8qM8pT4PdF 6CntmqFaX8LXA9kktXdX2DE4y3o8JNIpEk49LLESP7DP4Nc5oI8wWy6UN7K6bA9bTD3s X9BpSAj8GNe8DkrVXRFmrg06Mn5cXLrflVxOFJQWfycAFvKm5jhz1b6q/0wXCdp4kPyI WG0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j6qBbZuaxDGlv87jREDyMzxehiiROhYHAAkHHiWvk68=; b=XF/THex2IrCtHLsamQFu4d6CY5uYQs5QhOma6RMH0uJT4VdpfkcFHIR6vkeIJisIcu T3i1WqHGewG/pGamFdgSs8QtBPAS+w3SdAwr2X7KL/pGco8HwX5aVz00PuLqMCq3XU2w 6BHqsBJfltMiQg4OI7Y+0L9UcsRvD4hh7++IkOrNnYKAg9w0PYD9rKGZ51F9b90fz/j9 zhzFsQuaFXrWN0dqs+LaM2kxwwacblgIpPwcjBT88QewvXxVkmiU7wSapbpHI0dyJ3i8 TlOCodMbM8DtrOVz9TlCNRUGiJ8ACZ2P/kUeY5FNzSBwk4kFCtWQLU8uFnm0BbycJTJc YHpw==
X-Gm-Message-State: AOAM532exeOCZxWwPV5JUsmUOzO83MfwwQmzi6Yd22E0n4VVGGqzbrzT ykHu3/nQlx4OiP+n6SfKJeclA5xWlVQCtmQVBDE=
X-Google-Smtp-Source: ABdhPJzzXIi7jFwuxksOv2Zr0oY9znc8EDYSLeiXV5ofQt+CtZQif5QIrxbcwkEXlbKS6tIgDfD9+uIySt1RIhEsR9M=
X-Received: by 2002:ac2:5b06:: with SMTP id v6mr648505lfn.284.1599850824181; Fri, 11 Sep 2020 12:00:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Bernard Aboba <>
Date: Fri, 11 Sep 2020 12:00:13 -0700
Message-ID: <>
To: Paul Kyzivat <>
Cc: IETF AVTCore WG <>
Content-Type: multipart/alternative; boundary="00000000000011ad8805af0e4c47"
Archived-At: <>
Subject: Re: [AVTCORE] RTP Header Extension Encryption
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Sep 2020 19:00:39 -0000

Paul said:

"Can you please clarify the scope for which you want the encryption to be
consistent? Above you variously mention all MIDs and all m-lines. I'm
concerned with what "all" applies to.

I think I can agree if you are talking about "all within a bundle
group". Anything broader has major problems."

[BA] Thanks for pointing this out.

Mixing unencrypted and encrypted RTP header extensions within a bundle
group is problematic because all of the RTP packets arrive on the same
port, and the receiver needs to know the MID (which could be encrypted) in
order to figure out which packets should have encrypted and unencrypted RTP
header extensions.  But if you have different bundle groups, then it is
possible for each group to have different settings (e.g. encrypted RTP
header extensions on one group and unencrypted RTP header extensions on
another bundle group) without that problem arising.  So this is an argument
only for consistency within each bundle group, not for requiring all bundle
groups to have the same setting.

On Fri, Sep 11, 2020 at 11:31 AM Paul Kyzivat <> wrote:

> Bernard,
> On 9/10/20 5:42 PM, Bernard Aboba wrote:
> > 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.
> Can you please clarify the scope for which you want the encryption to be
> consistent? Above you variously mention all MIDs and all m-lines. I'm
> concerned with what "all" applies to.
> I think I can agree if you are talking about "all within a bundle
> group". Anything broader has major problems.
>         Thanks,
>         Paul
> _______________________________________________
> Audio/Video Transport Core Maintenance