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

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
>