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

Alan Johnston <alan.b.johnston@gmail.com> Thu, 26 May 2016 04:02 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 BCEF912D15C; Wed, 25 May 2016 21:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, 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 Bu1HIbUo-qBf; Wed, 25 May 2016 21:02:02 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 BEC7612D0B6; Wed, 25 May 2016 21:02:01 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id h185so20653479qke.2; Wed, 25 May 2016 21:02:01 -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=bDG5/UA4EqVabfIfGeb4LqVjWkBcOhNWRaBfs70hSxI=; b=l8JvcAxfCsAi7BwmPw2pGQmdnFI8EVMoFINn2ruAQoTvGcHSCyVVjxLjDiSvGM09S5 ZjFDXVQWkc/3TNmit/r0ELVFL921thd+1g62KNmnxX6UxFpdU90EV5aUAupHhEOHNdN2 lizmPwBdMYvm0g6JuyrLztP0UKDvdUV+xvMku49dgBnOzHKH6Hy+3G24YBbq8E/uYkt1 7EYBlmbtPcW+dBJr2pK1zmZ/3+2S8aO0yOE/FSBBAlsb9e7S5UiGgExJKOxiRbdY15Ed FOsscxMCD43ZEai+HBQUj+L3xOZFmI0Fnd7yxLxbBNOPgB5Y+LP57EfA4a//1gLu2Qo8 SPJQ==
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=bDG5/UA4EqVabfIfGeb4LqVjWkBcOhNWRaBfs70hSxI=; b=NzTHmMO4M8YgVYeGJPjSdUSXdiBRowtTpnwuraGUxllym1HwcF409Q8W+qR2edH9S+ 4yTXgIfnLSXxgQgOVryhJjAqZGZhBCOm+F+K/lFtZiAZiHxKGRZfrlYcPwnO0rRPEtPZ II1WuIkhoDOCjfxghWb2Dep7QEx7K5wVOVtlanVyavSp0yy7zourh7nyf2phVRBerPNP JceVpMvsBXA0vt956f1rShR0Iwrs5n6yyAJgx0PpAsTWuxZrV9Dh8hvY/Axv9kvWGujx 9cGlTQQNM6BYeZKhiS9oowLuWIouwKFFVnhA9tnpbXrxVepbNtZRGk/M4+C1coBKfKTw sElw==
X-Gm-Message-State: ALyK8tKv1fw71Vo1wVEuL+m2hjwpvJs192fUCHe612Z6cGuQQDwOurvLCyksvy9PxUSGaxWbBQ1V3AnfGX1hEg==
MIME-Version: 1.0
X-Received: by 10.55.161.1 with SMTP id k1mr7321073qke.193.1464235320557; Wed, 25 May 2016 21:02:00 -0700 (PDT)
Received: by 10.55.185.70 with HTTP; Wed, 25 May 2016 21:02:00 -0700 (PDT)
In-Reply-To: <D760EEE0-2241-428A-89B7-1D8F985E2BBE@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> <80563BED-ADDE-4C2B-8B4E-DF1C8F3E3FA5@cisco.com> <CAKhHsXGDneqTTaZ0tkw3WxsCPStLuMWGBSDHnarc+4YA-t-tyA@mail.gmail.com> <CCF13C88-3C10-4E73-88A5-B70BA1C15A20@cisco.com> <CAMRcRGTRkM8wksX8jHBwa1+kT_JSN9x=HtpV81+LcwdvsdcWNg@mail.gmail.com> <19E42A64-2DFD-4DAD-AD8D-C971EBD88C19@nostrum.com> <D760EEE0-2241-428A-89B7-1D8F985E2BBE@cisco.com>
Date: Wed, 25 May 2016 21:02:00 -0700
Message-ID: <CAKhHsXEy=QAJb_hvsy5mkxwiH+ph5ryJNVwenLZ0VMf54SyRyg@mail.gmail.com>
From: Alan Johnston <alan.b.johnston@gmail.com>
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
Content-Type: multipart/alternative; boundary=94eb2c05fa182648a40533b6da05
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/QlG_jgpv9MwwZgDJzI7BfTaq3ss>
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: Thu, 26 May 2016 04:02:04 -0000

On Wed, May 25, 2016 at 8:59 PM, Gonzalo Salgueiro (gsalguei) <
gsalguei@cisco.com> wrote:

>
>
> > On May 25, 2016, at 8:50 PM, Ben Campbell <ben@nostrum.com> wrote:
> >
> > Since I'm the one who originally complained about TRANSPORT I should
> probably respond :-)
> >
> > I agree TRANSPORT makes sense if people agree to the changes in
> mux-fixes.
>
> Well, as mentioned in my earlier email, changes to both mux-fixes and 6189
> are needed.
>

Agreed.  I will make the changes to RFC 6189.

- Alan -


>
> Gonzalo
>
>
> > Ben.
> >
> >> On 25 May 2016, at 22:09, Suhas Nandakumar wrote:
> >>
> >> Thanks Ben, Alan , Gonzalo & Marc for driving these discussions.
> >>
> >>
> >> Just getting back to the original question that Ben had on the
> mux-cateory
> >> for ZRTP - Do we all agree that with the changes to rfc5764-mux-fixes
> the
> >> category TRANSPORT makes sense ? Since that helps clarify demuxing ...
> >>
> >> Thanks
> >> Suhas
> >>
> >> On Wed, May 25, 2016 at 8:05 PM, Gonzalo Salgueiro (gsalguei) <
> >> gsalguei@cisco.com> wrote:
> >>
> >>> OK, cool  Thanks, Alan.  Once we get consensus from the WG(s) that
> this is
> >>> the best way forward we will make this change to
> >>> draft-ietf-avtcore-rfc5764-mux-fixes.
> >>>
> >>> Cheers,
> >>>
> >>> Gonzalo
> >>>
> >>>>> On May 25, 2016, at 8:01 PM, Alan Johnston <
> alan.b.johnston@gmail.com>
> >>>> wrote:
> >>>>
> >>>> Hi Gonzalo,
> >>>>
> >>>> Thanks for the clarification - I had it backwards in my head.
>  Existing
> >>> ZRTP implementations will be compliant to the proposal, and we can
> >>> constrain those bits to 0 in the 6189bis draft to lock it down.
> >>>>
> >>>> So I am OK with this proposal.
> >>>>
> >>>> - Alan -
> >>>>
> >>>>> On Wed, May 25, 2016 at 1:56 PM, Gonzalo Salgueiro (gsalguei) <
> >>>> gsalguei@cisco.com> wrote:
> >>>> 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
> >>>
> >>> _______________________________________________
> >>> mmusic mailing list
> >>> mmusic@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/mmusic
> >>>
>