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

"Ben Campbell" <ben@nostrum.com> Wed, 25 May 2016 17:57 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 8555E12D104; Wed, 25 May 2016 10:57:00 -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 vNapXIfRrAGV; Wed, 25 May 2016 10:56:59 -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 D089312D887; Wed, 25 May 2016 10:56:58 -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 u4PHuuxE023225 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2016 12:56:57 -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: "Marc Petit-Huguenin" <marc@petit-huguenin.org>
Date: Wed, 25 May 2016 12:56:56 -0500
Message-ID: <9759123A-B014-41AC-95B8-720C50BC9E57@nostrum.com>
In-Reply-To: <5745E2F4.8040206@petit-huguenin.org>
References: <CD90C355-FAFD-44F9-8CB0-E40045E31046@nostrum.com> <5745E2F4.8040206@petit-huguenin.org>
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/ZNXqJ1VkKkW5ymkMAVEv4LcwB2s>
Cc: draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org, mmusic WG <mmusic@ietf.org>, draft-ietf-avtcore-rfc5764-mux-fixes.all@ietf.org, "avt@ietf.org WG" <avt@ietf.org>
Subject: Re: [AVTCORE] 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 17:57:00 -0000

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