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

"Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com> Wed, 25 May 2016 20:57 UTC

Return-Path: <gsalguei@cisco.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 7A73D12DAA4; Wed, 25 May 2016 13:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 jDfWF79wBVRH; Wed, 25 May 2016 13:57:00 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4418F12DD5B; Wed, 25 May 2016 13:57:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8294; q=dns/txt; s=iport; t=1464209820; x=1465419420; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2Wg3mFiDPXTtNmqd2YKWrG4oOrFZYFsO13Dk92l0HdM=; b=k/No6srD7Epa9eu29HgQU35mjAQ+DBA4okyHkaJd8bk6w3eZ3qm4DdKh jDRcVafY9nqVtj2utFXNI1PMDLtImws907yzIGz8IpL90JMv3iJekHfHL 3wykm6xyVzUS38YceQPYnd8wVo+j22bKyW1FKnMsah+xVKmRbHehadx8y o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgD2EEZX/5xdJa1cgzdWfQauBItvA?= =?us-ascii?q?Q2BeBcLhSVKAhyBKDgUAQEBAQEBAWUnhEMBAQEDAQEBASAEDToLBQsCAQgYAgI?= =?us-ascii?q?fBwICAh8GCxUQAgQOBRSIAQMPCA6xQI0SDYQpAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBFwWBAYUmgXaCVoJDgXwXgmorgi4FiASQADMBjCaBeYFph3uFOIYzgTGHZwE?= =?us-ascii?q?eAQFCggUBHBaBNW4BiQd/AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,365,1459814400"; d="scan'208";a="108364072"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 May 2016 20:56:59 +0000
Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4PKuxr5013935 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 May 2016 20:56:59 GMT
Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 25 May 2016 15:56:58 -0500
Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Wed, 25 May 2016 15:56:58 -0500
From: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
To: Alan Johnston <alan.b.johnston@gmail.com>
Thread-Topic: [MMUSIC] [AVTCORE] zrtp: draft-ietf-mmusic-sdp-mux-attributes vs draft-ietf-avtcore-rfc5764-mux-fixes
Thread-Index: AQHRthL8VuJ5x/fyEE6AYexF7eizHZ/KQAMAgAAFTwCAACwxAIAABhuA
Date: Wed, 25 May 2016 20:56:58 +0000
Message-ID: <80563BED-ADDE-4C2B-8B4E-DF1C8F3E3FA5@cisco.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>
In-Reply-To: <CAKhHsXG96C141ujTNtKP8D1QEHB2seYnCR67mRYzSqac5fijJg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.114.3]
Content-Type: text/plain; charset="utf-8"
Content-ID: <296B7AE262BBA642B2EC0C0B2D903D2B@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/SyAoBoEYFhDrRN91VMn3VIxRoBg>
Cc: mmusic WG <mmusic@ietf.org>, Marc Petit-Huguenin <marc@petit-huguenin.org>, "avt@ietf.org WG" <avt@ietf.org>, "draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org" <draft-ietf-mmusic-sdp-mux-attributes.all@ietf.org>, "draft-ietf-avtcore-rfc5764-mux-fixes.all@ietf.org" <draft-ietf-avtcore-rfc5764-mux-fixes.all@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:57:02 -0000

Hi Alan - 

One of the reasons we made the suggestion was because (in our estimation) it did not have a major impact to the ZRTP packet format. Currently the packet format is:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 1|Not Used (set to zero) |         Sequence Number       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Magic Cookie 'ZRTP' (0x5a525450)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Source Identifier                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |           ZRTP Message (length depends on Message Type)       |
   |                            . . .                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          CRC (1 word)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Our proposal was to set bits 4 and 5 to zero, which is currently what the protocol calls for and should implicitly make all existing implementations compliant.  All we are proposing is is to take bits 4 and 5 out of the “Not Used” range and leave them fixed to the value that current implementations use.  Does this make sense?

In any case, I’d like to try and understand what impact this has to the current rfc5764-mux-fix text.  Is it as simple as explicitly reserving values 16 - 19 for ZRTP? Or did you have something else in mind?  If you can make specific text suggestions that will simplify things.

Thanks,

Gonzalo


 


> On May 25, 2016, at 1:35 PM, Alan Johnston <alan.b.johnston@gmail.com> 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
>