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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 24 May 2016 18:21:10 -0500

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.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 25 May 2016 10:37:56 -0700

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
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 25 May 2016 12:56:56 -0500

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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 May 2016 13:35:06 -0700

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.
>
> 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.
>>
>>> 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.
>>>
>>> hard, but would be non-trivial. RFC 6189 calls for using the magic cookie
>>> to distinguish zrtp messages from stun messages.
>>>
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 25 May 2016 15:40:44 -0500

By the way, when I said "along the lines I expected", I was thinking in 
terms of the updated algorithm in mux-fixes, not an update to ZRTP. As 
an individual, I agree that changing the ZRTP packet format seems 
drastic, and I would be concerned that implementors would ignore such a 
change.

Thanks!

Ben.

On 25 May 2016, at 15:35, Alan Johnston wrote:

>> it
>>> using
>>>> used
>>>> "transport"
>>>> be
>>>> cookie
>>>> interpreting

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 25 May 2016 20:56:58 +0000

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 -
> 
> That's along the lines that I expected, if the working group chooses this path. What do others think?
> 
> Thanks!
> 
> Ben.
>

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 May 2016 20:01:27 -0700

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

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 26 May 2016 03:05:43 +0000

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.
> 
> On Wed, May 25, 2016 at 1:56 PM, Gonzalo Salgueiro (gsalguei) <[email-masked]> wrote:
> Hi Alan -
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 25 May 2016 20:09:44 -0700

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) <
[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
>
> > 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
> > 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?
> >
> 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
> 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.
> > >
> "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.
> > >
> standards-track spec. But at the same time, I'm not sure we want to exclude
> it from the bundle mechanism.
> > >
> > > Thanks!
> > >
> > > Ben.
> > >
> > >

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 25 May 2016 22:50:15 -0500

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:

>>> On May 25, 2016, at 8:01 PM, Alan Johnston 
>>> <[email-masked]>
>> wrote:
>>>
>>> Hi Gonzalo,
>>>
>>>> On May 25, 2016, at 1:35 PM, Alan Johnston 
>>>> <[email-masked]>
>> wrote:
>>>>
>>>> Hi Marc,
>>>>
>> not. If
>> overlap
>> used in a

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Thu, 26 May 2016 03:59:29 +0000

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

---

From: Alan Johnston <[email-masked]>
Date: Wed, 25 May 2016 21:02:00 -0700

On Wed, May 25, 2016 at 8:59 PM, Gonzalo Salgueiro (gsalguei) <
[email-masked]> wrote:

> mux-fixes.

Agreed.  I will make the changes to RFC 6189.

- Alan -

> >>>>> On May 25, 2016, at 8:01 PM, Alan Johnston <
> [email-masked]>
> >>>> wrote:
> >>>>
> >>>> Hi Gonzalo,
> >>>>
> >>>>> On May 25, 2016, at 1:35 PM, Alan Johnston <
> [email-masked]>
> >>> wrote:
> >>>>>
> >>>>> Hi Marc,
> >>>>>