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

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

As per Marc’s response to Magnus’ LC comments, below is the reference discussion with the AD regarding normative vs. informative reference to ZRTP for mux-fix draft.

Cheers,

Gonzalo

> Begin forwarded message:
> 
> From: "Gonzalo Salgueiro (gsalguei)" <[e-mail]>
> Subject: Re: [MMUSIC] [AVTCORE] zrtp: draft-ietf-mmusic-sdp-mux-attributes vs draft-ietf-avtcore-rfc5764-mux-fixes
> Date: June 17, 2016 at 5:04:11 PM EDT
> To: Ben Campbell <[e-mail]>
> Cc: "Gonzalo Salgueiro (gsalguei)" <[e-mail]>, Marc Petit-Huguenin <[e-mail]>
> 
> Hi Ben - 
> 
> We gave this a good bit of thought.  The fact that ZRTP is informational was simply a factor in our decision, but not the main impetus.  Our rationale was more around the fact that an implementer of the demux logic presented in the mux-fix draft doesn’t need to read the ZRTP spec.  The necessity of reading the ZRTP seemed more of an academic exercise for those curious about ZRTP operation since the explanation for why it is being explicitly carved out in the demux scheme seemed to be wholly explained in the mux-fix draft.  Now, I *do* think that when Alan does get around to ZRTPbis then I think that document should absolutely make a normative reference to this one because there will necessarily need to be text about why certain bits in the header are being set to fixed values.
> 
> At any rate, we understand that this is a bit of a judgement call and if we are asked to make it a normative reference, then we are perfectly fine with that.
> 
> Cheers,
> 
> Gonzalo
> 
> 
>> On Jun 17, 2016, at 4:56 PM, Ben Campbell <[e-mail]> wrote:
>> 
>> Please consider whether the zrtp reference should be normative. That is, do you need to read that to understand this draft. (Personally, I think this is a borderline case.)
>> 
>> I recognize that zRTP is informational, but that doesn't prevent a normative reference if there is good reason. But it does create a few minor process hoops.
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> On 15 Jun 2016, at 14:15, Gonzalo Salgueiro (gsalguei) wrote:
>> 
>>> We have posted the new version that takes ZRTP into account. Have a look and see if everything is OK.
>>> 
>>> -G
>>> 
>>> 
>>>> On Jun 14, 2016, at 4:29 AM, Ben Campbell <[e-mail]> wrote:
>>>> 
>>>> Hi Gonzalo,
>>>> 
>>>> It's hard to give a definitive answer without seeing the changed text in context--but I think you can structure this as a reference to the old 6198. If 6198bis obsoletes 6198, then the reference effectively gets "upgraded". Now, if you depend on 6198bis changes, you might at least mention that, at the time of this writing, there are discussions about the changes in progress.
>>>> 
>>>> As far as normative vs informational--I lean towards normative. 6198 is informational, but we can make an exception for the downref if we do it for good reason and mention it in the IETF last call. But again, this sort of depends on the changed text.
>>>> 
>>>> Thanks!
>>>> 
>>>> Ben.
>>>> 
>>>> 
>>>> On 14 Jun 2016, at 6:44, Gonzalo Salgueiro (gsalguei) wrote:
>>>> 
>>>>> Hi Ben -
>>>>> 
>>>>> 
>>>>> Marc (on Cc) and I plan to make the proposed changes to the mux-fix draft on Wednesday.  In planning for that we were thinking through some things where we’d appreciate your advice.  As discussed, the proposed change will require changes to mux-fix draft and a new version of RFC 6189.  Does this mean we need a reference to RFC6189bis?  (BTW - There is a RFC6189bis available (http://zfone.com/docs/ietf/rfc6189bis.dif.html) but it seems to be an abandoned version from 2012.) Would it have to be normative?  If so, that would mean we are potentially waiting years to publish mux-fix, which is far from the intent. Or can we make it informative? Or can we simply put a reference to the old RFC 6189 and then let 6189bis be responsible for explaining what was done in mux-fix?
>>>>> 
>>>>> Any advice is truly appreciated…
>>>>> 
>>>>> -G
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jun 7, 2016, at 10:53 PM, Ben Campbell <[e-mail]> wrote:
>>>>>> 
>>>>>> Excellent, thanks!
>>>>>> 
>>>>>> On 7 Jun 2016, at 21:40, Gonzalo Salgueiro (gsalguei) wrote:
>>>>>> 
>>>>>> Hi Ben -
>>>>>> 
>>>>>> Sent the email to AVT & MMUSIC again indicating the ‘speak now or forever hold your peace’ sentiment. We’ll produce an updated draft over the next few days.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Gonzalo
>>>>>> 
>>>>>> On Jun 7, 2016, at 6:31 PM, Ben Campbell [e-mail] wrote:
>>>>>> 
>>>>>> I suspect that this whole thing is enough of an edge case that people won't care much one way or another, and would be willing to move it forward as is. (It's been on the list, afterall, and I think the people who care have spoken up.)
>>>>>> 
>>>>>> But if you want to be sure, you could re-summarize the proposed actions to the lists, along with an explicit statement that if people don't object really soon now, the proposal will take effect.
>>>>>> 
>>>>>> Thanks!
>>>>>> 
>>>>>> Ben.
>>>>>> 
>>>>>> On 3 Jun 2016, at 1:55, Gonzalo Salgueiro (gsalguei) wrote:
>>>>>> 
>>>>>> Hi Ben -
>>>>>> 
>>>>>> Never heard from anyone else on this besides from Alan (6189 author) and us (mux-fix authors). So not sure what consensus is and how to get this moving forward.
>>>>>> 
>>>>>> Any advice?
>>>>>> 
>>>>>> Gonzalo
>>>>>> 
>>>>>> On May 25, 2016, at 11: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
>>>>>> 
>