Re: [MMUSIC] SDP Directorate review: draft-ietf-avtcore-cryptex

Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> Tue, 14 June 2022 10:27 UTC

Return-Path: <sergio.garcia.murillo@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1310C165639; Tue, 14 Jun 2022 03:27:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D18aNwizx2fY; Tue, 14 Jun 2022 03:27:53 -0700 (PDT)
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A35C1655D7; Tue, 14 Jun 2022 03:27:53 -0700 (PDT)
Received: by mail-pg1-x533.google.com with SMTP id s135so8108753pgs.10; Tue, 14 Jun 2022 03:27:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0X1N+407zP9m0Pwprd/rSYbiyvi+c1IPrQ5mkXjk208=; b=QU+dgsSmiFdlpXj1azaEF5A31/jqDukX5ANrbU42g2pdk/NBVHSxotAfiFGZPDXNs/ kfOFDJY2jlhiJ/djr55mrZQn8CycD6bEfooNARJhVfK1D7lWhvIUs7QqO3Qg1jNW17v1 MU/vZZs4oeIaZuF0A49dWkLPB6SAS7mx52Fu5HP7QJSEDztADjiilcXIOnbxYjeXa55t a98oZuGgawGASegDPi4UKU5g7zZ8Vd7WnRn35hjwZ0ulwJV4AN7l5HrSPbF81ZENh6XL aMazun+gqkgZm9f3IS7ty0Gm3mXIfPTw3VrxI3IR/zVcfre0Wr2asno6RzPOv1rbzp37 EAgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0X1N+407zP9m0Pwprd/rSYbiyvi+c1IPrQ5mkXjk208=; b=4fRCb6h9EgA90gz8Ofnjk7dwjB4z31Hlkmy7F1RNCEmItfHYzVi+0fDCxHlRMDBU0d M8pw0cs+V/EeGaA1impREVT0spfkH4BATdMkqB2rsGwNW1RgW1G9huh9Qspl+2KV87jn FsJDI55LjpNqtrkNFEzjVKFu5HEVTuOT7gK6mSKLsAP6GreXXJ7MDqOhRztcrbyPauAN AYggyODXDHGxdYi5M+oXu96uMc/ySeCDMPWEUuzxUtNF7dGcxsRUEFlaynus1r6MvC54 hYnm7dvu/FKgNvvy4iNeuctrSMqyQtgtAX+UEOCR6leIeYAP9jG0kK/nQ2Hak04gWJk5 3yfA==
X-Gm-Message-State: AOAM530XFh6lHMznxwcLUA5SSKVG9HKdMmsXf8B2cBk2dvCXHhaNw4ZR vAhzFIKYpl944ZBrzJNzqH7i8yaR060lHZpmotY=
X-Google-Smtp-Source: ABdhPJyoM2ORd8VwpJKAg77s+shWzjLq82YK6yWnlgOvzOZjJ+46oHQi7QDAkV5/2uh7tWohgBS1pdg6m1pITTAcvPA=
X-Received: by 2002:a65:6499:0:b0:3fc:dcaa:ad62 with SMTP id e25-20020a656499000000b003fcdcaaad62mr3961181pgv.63.1655202472293; Tue, 14 Jun 2022 03:27:52 -0700 (PDT)
MIME-Version: 1.0
References: <HE1PR07MB4441160C0170EE3B9C827BD893A69@HE1PR07MB4441.eurprd07.prod.outlook.com> <CA+ag07YD7J5ta13buFPOVeKp3fQYvdg0xPm2qcjXOuNXsANc4Q@mail.gmail.com> <HE1PR07MB44417BC524A9F7F1CAD1DCE293AA9@HE1PR07MB4441.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB44417BC524A9F7F1CAD1DCE293AA9@HE1PR07MB4441.eurprd07.prod.outlook.com>
From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Tue, 14 Jun 2022 12:27:41 +0200
Message-ID: <CA+ag07ayre++NUOPjCtZy93a0NUDVPZZ1WfDudpRSLv-3DGr2A@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: IETF AVTCore WG <avt@ietf.org>, "Murray S. Kucherawy" <superuser@gmail.com>, mmusic <mmusic@ietf.org>, "avtcore-chairs@ietf.org" <avtcore-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000064787205e165dbcb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/09f1JiPIg6jnuZih3tLN58eDOUU>
Subject: Re: [MMUSIC] SDP Directorate review: draft-ietf-avtcore-cryptex
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2022 10:27:54 -0000

On Tue, Jun 14, 2022 at 10:53 AM Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> ...
>
> Q4:
>
> >> Section 4 says:
> >>
> >>   "If BUNDLE is in use and the a=cryptex attribute is present for a
> >>   media line, it MUST be present for all media lines belonging to the
> >>   same bundle group.  This ensures that the encrypted MID header
> >>   extensions used to demux BUNDLE can be processed correctly.  When
> >>   used with BUNDLE, this attribute is assigned to the TRANSPORT
> >>   category [RFC8859]."
> >>
> >> First, as the usage of Cryptex is optional, why mandate it on all media
> lines? Could you explain the MID header processing justficiation?
> >
> > If ssrc info is not exchanged in the SDP O/A, then the only way to
> assign a packet to an m-line is by the mid value which is encrypted if
> cryptex is in use. So if the peer signals that it supports receiving
> cryptex in one m-line, it must support it on all of them.
>
> Sure, but if you only indicate cryptex support for m- line X, then the
> peer is only allowed to use cryptex for the RTP packets associated with X.
>
> But, the peer is not allowed to use cryptex for RTP packets associated
> with m- line Y.
>
> But, in general I think it would be good to add some more text on the
> BUNDLE impacts, e.g., that intermediary nodes might not be able to
> distinguish/process bundled media if the MID is encrypted.
>
> For example, in some networks there are intermediaries that "un-BUNDLE"
> media into individual 5-tuples, and that won't work unless such nodes have
> access to the MIDs.
>

There could be two different intermediaries that un-bundle media and
forward them to individual 5-tuples, the ones which terminate the SRTP
encryption and  the ones that don't.
For the ones that terminate SRTP, if they are able to support cryptex on
one m-line, they should be able to support it on all others. It could be
argued that the receiver may want to only protect the header extensions on
some media in order to reduce the processing workload, but not sure if this
is a common or desirable scenario.

For the ones that doesn't terminate SRTP and just forward the SRTP packets
to individual 5-tuples, they will may not be able to process any SRTP
packet with cryptex if no ssrc info is negotiated in the SDP (which is the
intended way of doing BUNDLE, right?).

I will try to add some more text about BUNDLE impacts based on the outcome
of the discussion above.



> >Second, if mandated on all media lines, it will apply also to non-RTP
> media lines (e.g., a WebRTC data channel), and then I think you need to
> have some explicit text about that.
> >
> >What would be the best term for a "media m-line"?
> >
> >- media m-line
> >- media m line
> >- media "m=" line
>
> My suggestion would be to say "m- lines for RTP transported media", or
> something like that, because technically you could transport media also
> using non-RTP mechanisms.
>

I have just checked the BUNDLE rfc and they us the term: *"m="
section* and *RTP-based
media. *What do you think about using this instead?

If BUNDLE is in use and the a=cryptex attribute is present in a "m="
section, it MUST be present for all the "m=" sections for RTP-based media
belonging to the same bundle group.


>
> Regards,
>
> Christer
>
>
>