IETF Logo Mail Archive

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

Marc Petit-Huguenin <marc@petit-huguenin.org> Wed, 25 May 2016 17:38 UTC

Return-Path: <marc@petit-huguenin.org>
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 D0CAB12D6B7; Wed, 25 May 2016 10:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 FUGk9XA-vwEd; Wed, 25 May 2016 10:38:07 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C76F12D5C6; Wed, 25 May 2016 10:38:07 -0700 (PDT)
Received: from [IPv6:2001:0:53aa:64c:184d:5c33:53c7:d9b2] (unknown [IPv6:2001:0:53aa:64c:184d:5c33:53c7:d9b2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id D835720251; Wed, 25 May 2016 19:37:59 +0200 (CEST)
From: Marc Petit-Huguenin <marc@petit-huguenin.org>
To: Ben Campbell <ben@nostrum.com>, mmusic WG <mmusic@ietf.org>, "avt@ietf.org WG" <avt@ietf.org>
References: <CD90C355-FAFD-44F9-8CB0-E40045E31046@nostrum.com>
Message-ID: <5745E2F4.8040206@petit-huguenin.org>
Date: Wed, 25 May 2016 10:37:56 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.7.2
MIME-Version: 1.0
In-Reply-To: <CD90C355-FAFD-44F9-8CB0-E40045E31046@nostrum.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="lpGtInOviD2oT6PUpKOOaq5a4EIQWHF08"
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/EauYuIpaF2NZq4_61tc6x-A0lMY>
Cc: draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org, draft-ietf-avtcore-rfc5764-mux-fixes.all@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:38:10 -0000

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
>

v2.23.0 | Report a Bug | By Email