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

["Ben Campbell" <[e-mail]>]

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