Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sdp-mux-attributes vs draft-ietf-avtcore-rfc5764-mux-fixes
Suhas Nandakumar <suhasietf@gmail.com> Thu, 26 May 2016 03:09 UTC
Return-Path: <suhasietf@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 831A712D0F2; Wed, 25 May 2016 20:09:49 -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 O0gg1kP7UtvU; Wed, 25 May 2016 20:09:46 -0700 (PDT)
Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (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 9960C12D539; Wed, 25 May 2016 20:09:45 -0700 (PDT)
Received: by mail-yw0-x232.google.com with SMTP id x189so65007276ywe.3; Wed, 25 May 2016 20:09:45 -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=tMAMBxMEP3BPhkFwAe9r6LAZCA+2eEJ6qvtUt8lQSVg=; b=YfNGeZroQKQSODzPC7HzL1U7x2g3l/6yw5GHdEHP4k/h1YQBmGCPlb3ciovQgEuEp8 05gBOniNciHli9Hej6Q+ZdMgXr82/zpG29KnzeKILvnRx+amvhrgigi7GaXJLg4v7eFD WHy1VHeMDYORStfqtZqT3JCMYLeF6rsqOYtplnJFXPudEbNG7bRW6TKnUFc8vPA7MweF iUK5L7/nGLKp+958CQ6B3BpSGAKqtNvEgczvzb0Ow475gbmLPw03k1exLKLVfGzdYNFI 4dfEv72vWHymC0Rsd9Hsil0OIi4nncml8cqfRf/tMa9o3ICpHgBclJmpwXn7V3wLyw5H mPbQ==
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=tMAMBxMEP3BPhkFwAe9r6LAZCA+2eEJ6qvtUt8lQSVg=; b=PUG8Bz8hta8h8XAeEGt9YiVmgDabeuXKDrdJp3jZEGTyBX/UthqmHwp2aW0lU+ZXJ0 D7iIMHNtkKlAafw83MYID+CJlJ6NZIIUkxtmbj6g80G+QZU8W8NC6n2nZmA+X1Z/Dqfp VYoQpDIw91cQWLcABlwVEdSar8wre/mpHrh/A8Y2TwI0XM5ud8jayJPisXNDXvkoiFAU CtklcQfxz5HnvjkYQ4jf4mp+XUPh0wzgWo3wJAvT4H+1Unh1kLFYuXCLh8iApDhnHoWx O0hxB4ygbe9uBbTlIoUfzzYt1Sp8s6U2ccCYfdDqIfNvg8GlW4+N+4clq2pMvCDK/UJb IGzA==
X-Gm-Message-State: ALyK8tIst19MXvHzY/Yub7n/IXOBUAPricfI+RXOD5CBuYY/1w3eu7qcJB4NOqc9/Iiyn8Hxn8t0pXGr9fKzVg==
MIME-Version: 1.0
X-Received: by 10.129.90.135 with SMTP id o129mr4927421ywb.20.1464232184753; Wed, 25 May 2016 20:09:44 -0700 (PDT)
Received: by 10.129.54.15 with HTTP; Wed, 25 May 2016 20:09:44 -0700 (PDT)
In-Reply-To: <CCF13C88-3C10-4E73-88A5-B70BA1C15A20@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>
Date: Wed, 25 May 2016 20:09:44 -0700
Message-ID: <CAMRcRGTRkM8wksX8jHBwa1+kT_JSN9x=HtpV81+LcwdvsdcWNg@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
Content-Type: multipart/alternative; boundary="001a114914f03db6920533b61f4f"
Archived-At: <http://mailarchive.ietf.org/arch/msg/avt/R2JDIMHi5ldCNZclSbe7gNGlLW0>
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 03:09:49 -0000
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 >
- [AVTCORE] Fwd: [MMUSIC] zrtp: draft-ietf-mmusic-s… Gonzalo Salgueiro (gsalguei)
- [AVTCORE] zrtp: draft-ietf-mmusic-sdp-mux-attribu… Ben Campbell
- Re: [AVTCORE] zrtp: draft-ietf-mmusic-sdp-mux-att… Marc Petit-Huguenin
- Re: [AVTCORE] zrtp: draft-ietf-mmusic-sdp-mux-att… Ben Campbell
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Alan Johnston
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Ben Campbell
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Gonzalo Salgueiro (gsalguei)
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Alan Johnston
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Gonzalo Salgueiro (gsalguei)
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Suhas Nandakumar
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Ben Campbell
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Gonzalo Salgueiro (gsalguei)
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Alan Johnston
- Re: [AVTCORE] [MMUSIC] zrtp: draft-ietf-mmusic-sd… Gonzalo Salgueiro (gsalguei)