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

"Ben Campbell" <ben@nostrum.com> Wed, 25 May 2016 20:40 UTC

Return-Path: <ben@nostrum.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 DEC2912D9C2; Wed, 25 May 2016 13:40:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
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 rlIFILSdCHRQ; Wed, 25 May 2016 13:40:48 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2D01F12D906; Wed, 25 May 2016 13:40:48 -0700 (PDT)
Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4PKei62038129 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2016 15:40:45 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18]
From: "Ben Campbell" <ben@nostrum.com>
To: "Alan Johnston" <alan.b.johnston@gmail.com>
Date: Wed, 25 May 2016 15:40:44 -0500
Message-ID: <FC37C429-0F9F-4545-BDA1-5CC6D4CDB028@nostrum.com>
In-Reply-To: <CAKhHsXG96C141ujTNtKP8D1QEHB2seYnCR67mRYzSqac5fijJg@mail.gmail.com>
References: <CD90C355-FAFD-44F9-8CB0-E40045E31046@nostrum.com> <5745E2F4.8040206@petit-huguenin.org> <9759123A-B014-41AC-95B8-720C50BC9E57@nostrum.com> <CAKhHsXG96C141ujTNtKP8D1QEHB2seYnCR67mRYzSqac5fijJg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/5kYukkZ4cUg89UQqX9-vs1qLd5c>
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:40:51 -0000

By the way, when I said "along the lines I expected", I was thinking in 
terms of the updated algorithm in mux-fixes, not an update to ZRTP. As 
an individual, I agree that changing the ZRTP packet format seems 
drastic, and I would be concerned that implementors would ignore such a 
change.

Thanks!

Ben.


On 25 May 2016, at 15:35, Alan Johnston wrote:

> 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
>>