Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sdp-mux-attributes vs draft-ietf-avtcore-rfc5764-mux-fixes

Alan Johnston <alan.b.johnston@gmail.com> Wed, 25 May 2016 20:36 UTC

Return-Path: <alan.b.johnston@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 9AA0C12DCFE; Wed, 25 May 2016 13:36:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 fnUx_5frUrui; Wed, 25 May 2016 13:36:22 -0700 (PDT)
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (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 D785A12D9C3; Wed, 25 May 2016 13:36:21 -0700 (PDT)
Received: by mail-qg0-f47.google.com with SMTP id q32so28146520qgq.3; Wed, 25 May 2016 13:36:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=hhPmYwhemrOGY5rBiuEBx0E2NeaL4fCpTZ6QAxhXUoQ=; b=H6YFsSL7tTSrw+TD0Icvpzry1LAFYDGAvbAPXOUh1Dz9GU+mEppeDn6nNcg0G3mtMj EA2GSPVPLzSjATUyyUz4fnaRkTTmNj0vJIfjMYNdnYApRG9elMG/jxaOPmteOkIHDZ0J Bv1CTUbv7h5V7rT2XW8ZnM05XJKu93GOjh5FWr0Z4Q9rbOBB0uqoSvNVZrfus6w+lE7Y upZsbqRqqmKeFpbdJttanjneyvZIPTAYrnv7z+ezRCDRu2T1nd6zMih9IyG6cigvrikS 5t/I/XE79YrME6Q2VpyOe01pebegEnYPYow3UjxfrdxDIYp2sdeRIxKxxr1UoBKuCJsq S/Lg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=hhPmYwhemrOGY5rBiuEBx0E2NeaL4fCpTZ6QAxhXUoQ=; b=FfrJIGiA/K/vUSrsT/9AthirLgV7KJCG8c/LJbT2V13tl+mODgQBnBfT49Pd1A2tps G3K9QePIU0/vhiopUz13JY3MHqXstNxqbioM3QNBZeW0dTh0EUwdr3c2KMf2JH1GtEMm bEj3nyz75XiembLb1Aj6jx7rWrLhY/ToOK0X+7lMOiw2CUSIGIjD43WRpeNaFKhT+Pb/ 6fdEDilw2R3c1BP6EYWkoxmHeIqbDJe3MxafAJDBdzvXQrxueF0WRe9lyDiESjkf3bhC tVrwntQsyIdWCJyn77J3n6YJpme+oJOhpf+FA2qvln1Efup0NXcaCbTpt+Zo2XEUMAJO wP2g==
X-Gm-Message-State: ALyK8tISo0XCdqkpU046gj12cZ6r0lUpeO/H8k8H7voVvFg08U3gQ7VKcjEtQUk7YtFi65yxeA58h/sG6osPpw==
MIME-Version: 1.0
X-Received: by 10.140.41.200 with SMTP id z66mr5408235qgz.20.1464208506147; Wed, 25 May 2016 13:35:06 -0700 (PDT)
Received: by 10.55.185.70 with HTTP; Wed, 25 May 2016 13:35:06 -0700 (PDT)
In-Reply-To: <9759123A-B014-41AC-95B8-720C50BC9E57@nostrum.com>
References: <CD90C355-FAFD-44F9-8CB0-E40045E31046@nostrum.com> <5745E2F4.8040206@petit-huguenin.org> <9759123A-B014-41AC-95B8-720C50BC9E57@nostrum.com>
Date: Wed, 25 May 2016 13:35:06 -0700
Message-ID: <CAKhHsXG96C141ujTNtKP8D1QEHB2seYnCR67mRYzSqac5fijJg@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: Ben Campbell <ben@nostrum.com>
Content-Type: multipart/alternative; boundary=001a11c13b84e2dc4d0533b09b1f
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/OiQ71pm7MOgCNXBLYG0Ca-9dQH0>
Cc: Marc Petit-Huguenin <marc@petit-huguenin.org>, draft-ietf-avtcore-rfc5764-mux-fixes.all@ietf.org, mmusic WG <mmusic@ietf.org>, draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org, "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sdp-mux-attributes vs draft-ietf-avtcore-rfc5764-mux-fixes
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
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: Wed, 25 May 2016 20:36:24 -0000

Hi Marc,

Changing the packet format for ZRTP is a pretty major change to the
protocol...

I think the only case where this is an issue would be if both ZRTP and
DTLS-SRTP are offered opportunistically (OSRTP), and either ZRTP or
DTLS-SRTP arrives before the answer is received.    During this window of
time, a slightly more complicated algorithm could be used to distinguish
ZRTP from DTLS-SRTP, such as checking the 32-bit magic cookie that is
present in every ZRTP message. Otherwise, only one of these protocols will
be used at a time, so it is not the same as distinguishing either from STUN
and RTP, which happens throughout a session.

We could put this guidance in a RFC6189bis draft, and the other documents
could just defer to that guidance if they support ZRTP in addition to
DTLS-SRTP opportunistically.

- Alan -

On Wed, May 25, 2016 at 10:56 AM, Ben Campbell <ben@nostrum.com> wrote:

> Hi Marc,
>
> That's along the lines that I expected, if the working group chooses this
> path. What do others think?
>
> Thanks!
>
> Ben.
>
> On 25 May 2016, at 12:37, Marc Petit-Huguenin wrote:
>
> As you mention, there are several ways to handle this issue. We leave it
>> to the community to decide whether to include zrtp in bundle or not. If we
>> were to update the 5764-mux-fix draft, we felt that the cleanest way to
>> handle it is in two steps.
>>
>> One thing to note is that there is no clash/overlap with STUN, so using
>> magic cookie to distinguish from STUN is a moot point. The overlap with the
>> DTLS range is what we need to avoid. The right thing to do seems to be to
>> work on a rfc6189bis draft that would set bit 4 and 5 of the first byte of
>> the zrtp message to 0. This way zrtp cannot clash with DTLS.
>>
>> On the rfc5764-mux-fixes draft, we just change the algorithm to:
>>
>>            +----------------+
>>            |        [0..3] -+--> forward to STUN
>>            |                |
>>            |      [16..19] -+--> forward to ZRTP
>>            |                |
>> packet --> |      [20..63] -+--> forward to DTLS
>>            |                |
>>            |      [64..79] -+--> forward to TURN Channel
>>            |                |
>>            |    [128..191] -+--> forward to RTP/RTCP
>>            +----------------+
>>
>>
>> Does this seem like a reasonable approach?
>>
>>
>> On 05/24/2016 04:21 PM, Ben Campbell wrote:
>>
>>> Hi,
>>>
>>> There appears to be a discrepancy between
>>> draft-ietf-mmusic-sdp-mux-attributes and
>>> draft-ietf-avtcore-rfc5764-mux-fixes concerning whether zrtp can be used
>>> with bundle.
>>>
>>> mux-attributes puts the zrtp-hash attribute [RFC6189] in the "transport"
>>> category, meaning, among other things, that it can be used in a bundle
>>> group. However, as the demux rules are currently defined 5764-mux-fixes,
>>> zrtp messages cannot actually be demuxed. (If I read things correctly, the
>>> first byte of a zrtp message will be 16, which is not in any of the "known
>>> ranges" described in 5765 or 5764-mux-fixes, and therefore the message MUST
>>> be dropped.
>>>
>>> That seems to leave the choice of adding zrtp messages to the demux
>>> rules in 5764-mux-fixes, or removing the implication that zrtp can be
>>> bundled from mux-attributes.
>>>
>>> Adding rules for demuxing zrtp to 5765-mux-fixes would probably not be
>>> hard, but would be non-trivial. RFC 6189 calls for using the magic cookie
>>> to distinguish zrtp messages from stun messages.
>>>
>>> Do people have opinions how to move forward with this? Am I interpreting
>>> the conflict correctly?Keep in mind that ZRTP is not a standards-track
>>> spec. But at the same time, I'm not sure we want to exclude it from the
>>> bundle mechanism.
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>>
>>> _______________________________________________
>>> Audio/Video Transport Core Maintenance
>>> avt@ietf.org
>>> https://www.ietf.org/mailman/listinfo/avt
>>>
>>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>