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

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 8 Jun 2016 02:38:59 +0000

Hi AVT & MMUSIC - 

I haven’t heard any other opinions on this, so I’ll assume making the change t the draft is OK.  Please indicate any objection over the next few days or we will proceed with the update to mux-fix.

Thanks, 

Gonzalo

> On May 25, 2016, at 11:05 PM, Gonzalo Salgueiro (gsalguei) <[email-masked]> 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 <[email-masked]> 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) <[email-masked]> 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 <[email-masked]> 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 <[email-masked]> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/avt
>>> 
>>> 
>>> _______________________________________________
>>> mmusic mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> 
>> 
>> 
>