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

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

> On May 25, 2016, at 8:50 PM, Ben Campbell <[e-mail]> 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. 

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) <
>> [e-mail]> 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 <[e-mail]>
>>>> 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) <
>>>> [e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/avt
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> 
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>