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

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