Re: [MMUSIC] zrtp-hash (was Re: AD Evaluation of draft-ietf-mmusic-sdp-mux-attributes-12)

[Alan Johnston <[e-mail]>]

Hi Ben,

What you say makes sense to me.  Adding ZRTP guidance to 5764-mux-fixes
seems like a reasonable solution to me.

- Alan -

On Mon, May 23, 2016 at 4:12 PM, Ben Campbell <[e-mail]> wrote:

> Hi Alan,
>
> If I read RFC 6189 correctly, I see that it documents how to distinguish
> zrtp messages from rtp and stun. Further, it distinguishes itself from stun
> by using a different magic cookie value. That's a little more complex than
> the first-byte demuxing in 5764--although it looks like first-byte demuxing
> might work as long as we don't end up with a conflicting stun method. (I'm
> also not certain that the average 5764 implementation is going to look at
> the cookie to make the demux decision.)
>
> I don't see anything in 6189 about distinguishing itself from DTLS. Again,
> we can infer that from the first byte, as long as we don't get a
> conflicting tls content-type.
>
> This doesn't quite seem (to me) to meet the following requirement in
> draft-ietf-mmusic-sdp-bundle-negotiation (emphasis mine):
>
>   "If bundled "m=" lines use different protocols on top
>    of the transport-layer protocol,  there MUST exist a publicly
>    available specification which describes a mechanism, for **this
>    particular protocol combination**, how to associate received data with
>    the correct protocol."
>
> As mentioned, one way to fix that could be to add zrtp into the general
> guidance in 5764-mux-fixes.
>
> Thanks,
>
> Ben.
>
>
> On 23 May 2016, at 17:48, Alan Johnston wrote:
>
> Hi Ben,
>>
>> The a=zrtp-hash attribute is a hash of the ZRTP Hello message that is
>> going
>> to be sent over the transport.  There is one ZRTP Hello sent per
>> transport,
>> and one handshake per transport.
>>
>> The ZRTP message format was carefully crafted in association with
>> DTLS-SRTP, so if draft-ietf-avtcore-rfc5764-mux-fixes breaks this, then it
>> probably should be fixed.
>>
>> - Alan -
>>
>> On Mon, May 23, 2016 at 3:34 PM, Ben Campbell <[e-mail]> wrote:
>>
>> Hi,
>>>
>>> As promised, here's more on my concern about zrtp-hash in
>>> draft-ietf-mmusic-sdp-mux-attributes:
>>>
>>> I think you need to describe the assumptions about what it means to
>>> multiplex zrtp. Am I correct to assume that the draft assumes that there
>>> is
>>> only one zrtp session in a transport flow, with a single zrtp handshake?
>>> And that all of the bundled m=lines represent media that is part of that
>>> zrtp association? (That is, you never mux distinct zrtp associations, or
>>> zrtp and dtls-srtp?)
>>>
>>> If the answer is yes, then "transport" seems to make sense.
>>>
>>> But is zrtp demuxing really well defined enough to keep this out of the
>>> "NOT RECOMMENDED" category? I'm not sure it meets the bundle requirement
>>> for a public spec on how to demux it. One might infer that from two
>>> public
>>> specs (zrtp and 5764), but IIUC, the guidance proposed in
>>> draft-ietf-avtcore-rfc5764-mux-fixes would cause a zrtp messages to be
>>> dropped, since its first byte would not match any of the demux rules. Or,
>>> if zrtp-hash is allowed, does mux-fixes need to change?
>>>
>>> What am I missing?
>>>
>>> Thanks!
>>>
>>> Ben.
>>>
>>>
>>> On 20 May 2016, at 18:07, Ben Campbell wrote:
>>>
>>> Apologies for my slow response. The last month has been a perfect storm
>>> of
>>>
>>>> productivity killers. I'm digging out of the backlog now. Comments
>>>> inline,
>>>> with sections that appear resolved removed.
>>>>
>>>> There is one issue (zrtp-hash) where I will start a separate thread
>>>> shortly.
>>>>
>>>> Thanks!
>>>>
>>>> Ben.
>>>>
>>>> On 20 Apr 2016, at 1:00, Suhas Nandakumar wrote:
>>>>
>>>> Hello Ben
>>>>
>>>>>
>>>>>  Sorry for the delay in responding. Many thanks for the detailed
>>>>> review.
>>>>>
>>>>>  Please find my responses inline (marked by [Suhas]).
>>>>>
>>>>> Cheers
>>>>> Suhas
>>>>>
>>>>> On Fri, Feb 19, 2016 at 2:28 PM, Ben Campbell <[e-mail]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>>
>>>>>> Here is my AD evaluation of draft-ietf-mmusic-sdp-mux-attributes-12. I
>>>>>> would like at least the substantive
>>>>>> section to be discussed before going to IETF last call.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Ben.
>>>>>>
>>>>>> ----------
>>>>>>
>>>>>> # Substantive #
>>>>>>
>>>>>> - This is very long and detailed. Are the authors and chairs
>>>>>> comfortable
>>>>>> that all sections have had sufficient review?
>>>>>>
>>>>>> -4.0: It would be helpful to add a paragraph describing how these
>>>>>> semantic
>>>>>> groupings map to the categories.
>>>>>>
>>>>>>
>>>>>> [Suhas] The semantic groupings were added as a informal reference and
>>>>> they
>>>>> don't really interact with the categories as such.
>>>>>
>>>>>
>>>> So I have to wonder why we have the groupings. But I guess at this point
>>>> in the process, it's not worth changing that.
>>>>
>>>>
>>>> Does the following rephrasing work
>>>>>
>>>>> *"Attributes in an SDP session description can be defined at the
>>>>> **session-level
>>>>> or  media-level or  source-level. Informally, there are various
>>>>> semantic
>>>>> grouping for these attributes. One such grouping could be as noted
>>>>> below:*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *   o  Attributes related to media content such as media type, encoding
>>>>>      schemes, payload types.   o  Attributes specifying media transport
>>>>> characteristics like RTP/RTP      Control Protocol (RTCP) port numbers,
>>>>> network addresses, QOS.   o  Metadata description attributes capturing
>>>>> session timing and      origin information.   o  Attributes
>>>>> establishing
>>>>> relationships between media descriptions      such as grouping
>>>>> framework
>>>>> [RFC5888 <https://tools.ietf.org/html/rfc5888>]The proposed framework
>>>>> defines categories for the SDP attributes under multiplexing and
>>>>> assigns
>>>>> each SDP attribute to an appropriate multiplexing category.*
>>>>>
>>>>> *Since the multiplexing categories defined in this specification are
>>>>> independent of any informal semantic grouping of the SDP attributes,
>>>>> the
>>>>> categorizations assigned against each attribute  MUST be considered as
>>>>> normative assignments under multiplexing. "*
>>>>>
>>>>>
>>>> All fine, except the last sentence is pretty meta--it uses normative
>>>> language to talk about normative language ("MUST be considered
>>>> normative").
>>>> I'm not entirely sure what you intend there, but how about something to
>>>> the
>>>> effect of "... the categorizations assigned against each attribute are
>>>> normative."
>>>>
>>>>
>>>>
>>>>>
>>>>> -4.2: I recommend choosing a category name that is not a 2119 keyword.
>>>>>
>>>>>>   Maybe something like "not mux-able" or "unsafe"?
>>>>>>
>>>>>>
>>>>>> [Suhas]
>>>>>
>>>>> Initially that category was called "BAD" as in
>>>>>
>>>>>
>>>>>
>>>>> https://datatracker.ietf.org/doc/draft-nandakumar-mmusic-sdp-mux-attributes/01/
>>>>>
>>>>> However we ended upon NOT RECOMMENDED since “BAD” was a bad choice :-)
>>>>>
>>>>> Either of the following options seems fine to me
>>>>>
>>>>>    1.
>>>>>
>>>>>    NOT-RECOMMENDED [ we use hyphen separated multi word format in other
>>>>>    category names]
>>>>>    2. UNSAFE
>>>>>
>>>>>
>>>> I lean towards unsafe. OTOH, NOT-RECOMMENDED makes sense if you intend
>>>> the category name to mean "NOT RECOMMENDED" in the 2119 sense.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> -4.3: Please don't use a 2119 keyword as part of the definition
>>>>>> of a category. This creates sort of a circular dependency; that is
>>>>>> attributes are in this category because they MUST be identical; but
>>>>>> they
>>>>>> MUST be identical because they are in this category. I suggest
>>>>>> describing
>>>>>> the category descriptively, and adding a separate sentence to say
>>>>>> "Attributes
>>>>>> in the IDENTICAL category MUST be identical across all media
>>>>>> descriptions."
>>>>>>
>>>>>>
>>>>>>
>>>>> [Suhas]. I have removed the usage of word identical from the definition
>>>>> as
>>>>> below. Please let me know if this works.
>>>>>
>>>>>
>>>>> Category: IDENTICAL
>>>>>
>>>>> Attributes  and their associated values (if present) in the IDENTICAL
>>>>> category MUST be repeated across all the media descriptions under
>>>>> multiplexing.
>>>>>
>>>>>
>>>>> Okay.
>>>>
>>>> [...]
>>>>
>>>>
>>>>
>>>>>
>>>>> -5.8 and 5.9:
>>>>>
>>>>>>     The last paragraph of 5.8 seems redundant with section 5.9.
>>>>>>
>>>>>> -5.8, last paragraph:
>>>>>>
>>>>>>     "Hence multiplexing MUST NOT be performed even in this
>>>>>>     alternate scenario." seems to contradict the category selection of
>>>>>>     "NOT RECOMMENDED" (but see previous comment about not using 2119
>>>>>>     keywords in a category title.)
>>>>>>
>>>>>>
>>>>>> [Suhas] The idea here is to not perform multiplexing and hence the
>>>>>>
>>>>> category
>>>>> of NOT RECOMMENDED assigned. I can update this once we finalize on the
>>>>> right naming for "NOT RECOMMENDED"
>>>>>
>>>>>
>>>> This argues for the "UNSAFE" name, since the actual normative guidance
>>>> is
>>>> stronger than "NOT RECOMMENDED". (Unless you want a "MUST NOT" name
>>>> :-)  )
>>>>
>>>>
>>>>
>>>>>
>>>>> -5.24, last paragraph: "it is recommended to consult the
>>>>>
>>>>>>   document defining the attribute."
>>>>>>
>>>>>>   I assume one should _always_ refer to the specification of
>>>>>>   an SDP attribute before trying to mux it. But that doc is
>>>>>>   not going to explain muxing issues, is it?
>>>>>>
>>>>>>
>>>>>> [Suhas]
>>>>>>
>>>>>
>>>>> Since cparmin/cparmax can define numerical values/ranges
>>>>>
>>>>> for any of b= or a= attributes (identified via cpar), there is no easy
>>>>> way
>>>>> to assign a multiplexing category unless one knows what cpar is being
>>>>>
>>>>> used and the assignned numerical values to each of cparmin/cparmax
>>>>> mean.
>>>>> Thus the category SPECIAL has been assigned as a recommendation for the
>>>>> implementor to consult the spec that defines a particular usage of
>>>>> cpar,
>>>>> cparmin and cparmax combination to really see what’s going on.
>>>>>
>>>>> This is very similar to extmap or RTCP Application feedback message
>>>>> type
>>>>>
>>>>> How about following rephrasing
>>>>>
>>>>>
>>>>> *"The attributes (a=cparmin and a=cparmax) define minimum and maximum
>>>>> numerical values associated with the attributes described in a=cpar.
>>>>> Since
>>>>> a cpar attribute can either define*
>>>>>
>>>>> *“b=” attribute or any “a=” attribute,  the multiplexing category *
>>>>>
>>>>> *depends on actual attribute being encapsulated and the implications of
>>>>> the
>>>>> numerical values assigned. Hence it is recommended to consult the
>>>>> specification defining the the attributes (cparmin/cparmax) to further
>>>>> analyze their behavior under multiplexing."*
>>>>>
>>>>>
>>>> That works for me.
>>>>
>>>>
>>>>
>>>>>
>>>>> -5.26:
>>>>>
>>>>>>   -"Support of this extension is OPTIONAL."
>>>>>>   Please don't use 2119 keywords to describe existing requirements
>>>>>>   from other docs, unless in direct quotes.
>>>>>>
>>>>>>
>>>>>>
>>>>>> [Suhas] This sentence is taken directly from RFC6714. (
>>>>> https://tools.ietf.org/html/rfc6714)
>>>>>
>>>>>
>>>> Sure, but it's not attributed as a quote. I suggest something to the
>>>> effect of "This is an optional extension according to [RFC6714]", "
>>>> [RFC6714] states that this extension is 'OPTIONAL'",  or even the exact
>>>> same language as currently in the draft, but without the capitalized
>>>> OPTIONAL.
>>>>
>>>> [...]
>>>>
>>>>
>>>>
>>>>>
>>>>> - 5.39:
>>>>>
>>>>>>   I’m not a zrtp expert, but it seems like it might
>>>>>>   be more complicated than this. Section 8 of 6189 says
>>>>>>   “The a=zrtp-hash attribute  can only be included in the
>>>>>>   SDP at the media level since Hello messages sent in
>>>>>>   different media streams will have unique hashes.”
>>>>>>   I wonder if this shouldn't be “identical”?
>>>>>>
>>>>>>
>>>>>> [Suhas] The category TRANSPORT is the appropriate assignment. This
>>>>>> spec
>>>>>>
>>>>> assigns category for these attributes over the multiplexed transport.
>>>>>
>>>>> So, if we have 3 m= lines each with one zrtp-hash and all bundled.
>>>>>
>>>>> The zrtp-hash selected must correspond to the m=line that is selected
>>>>> for
>>>>> BUNDLE once the O/A negotiation completes. Thus the category TRANSPORT.
>>>>>
>>>>>
>>>>>
>>>>> I _think_ you are right, but there may be an interaction here that can
>>>> break things I will think about that more, and respond to this issue is
>>>> a
>>>> separate thread.
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> -5.45:
>>>>>>   6193 is an ISE stream RFC. Does anyone actually use
>>>>>>   in a context where muxing matters?
>>>>>>
>>>>>>
>>>>>> [Suhas] . I doubt it. Do you recommend as NOT-RECOMMENDED instead.
>>>>>
>>>>>
>>>> That seems reasonable, unless  you know of good reasons otherwise.
>>>>
>>>>
>>>> -15.1:
>>>>>>   - Is there no need for a spec for any newly registered categories?
>>>>>>   - 2nd to last paragraph: "This seems vague for a MUST. Do you expect
>>>>>>     the registration of a new category to change the categories
>>>>>>     already assigned to existing SDP parameters? Is it possible
>>>>>>     that a new category only applies to some new SDP parameters?"
>>>>>>
>>>>>>
>>>>>> [Suhas] The following 2 paragraphs are supposed to mean that new
>>>>> multiplexing categories require new registrations via a spec and
>>>>> applicability of the new category to new SDP attributes and possibly
>>>>> existing SDP attributes ( if the new category makes more sense). What
>>>>> would
>>>>> be a better framing to capture the intent ?
>>>>>
>>>>> "*Further entries can be registered on a first-come first-serve basis.
>>>>> Each
>>>>> registration needs to indicate the multiplexing category value to be
>>>>> added
>>>>> to the "Multiplexing Categories" subregistry as defined in this
>>>>> section.*
>>>>>
>>>>> *Such a registration MUST also indicate the applicability of the newly
>>>>> defined multiplexing category value to various subregistries defined at
>>>>> "Session Description Protocol (SDP) Parameters".*
>>>>>
>>>>>
>>>> That works for me.
>>>>
>>>>
>>>>
>>>>>   - Last paragraph: 4566 procedures apply to what? The text just said
>>>>>
>>>>>>     new categories are first-come-first server. I don’t think
>>>>>>     4566 set policies for how to change mux categories.
>>>>>>
>>>>>>
>>>>>> [Suhas] Agreed. I prefer removing this line altogether. Please let me
>>>>> know
>>>>>
>>>>>
>>>>> I agree.
>>>>
>>>>
>>>> -15.2.1:
>>>>>>   How do you expect the table to look after adding this RFC to the
>>>>>>   references? Will this RFC be added to the entries in the MUX
>>>>>>   column?
>>>>>>
>>>>>>
>>>>>> [Suhas] The plan was to add the reference to this RFC in the
>>>>> "Reference
>>>>> Column"
>>>>>
>>>>>
>>>> Okay.
>>>>
>>>> [...]
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>> # Editorial #
>>>>>>
>>>>>>
>>>>>> - The abstract is more detailed than needed. The point is to describe
>>>>> the
>>>>>
>>>>>> purpose of the draft. The second paragraph pretty much accomplishes
>>>>>> that.
>>>>>>
>>>>>>
>>>>>> [Suhas] How do this rephrase look
>>>>>>
>>>>>
>>>>> “The purpose of this specification is to provide a framework for
>>>>> analyzing
>>>>> the multiplexing characteristics of SDP attributes when SDP is used to
>>>>> negotiate the usage of single 5-tuple for sending and receiving media
>>>>> associated with multiple media descriptions,. This specification also
>>>>> categorizes the existing SDP attributes based on the framework
>>>>> described
>>>>> herein.”
>>>>>
>>>>>
>>>>> That works for me.
>>>>
>>>> [...]
>>>>
>>>>
>>>>
>>>>>
>>>>> -5 and subsections: Is there any method to the ordering? They aren't
>>>>>>    in RFC order. It might make sense to group by the nature of the
>>>>>>    attributes, but if that is the case here it's not explained.
>>>>>>
>>>>>>
>>>>>> [Suhas] These are not ordered as of today. I can order the 5.X
>>>>>>
>>>>> subsections
>>>>> by RFC order, if needed.
>>>>>
>>>>>
>>>> Unordered is also okay. I was just wondering if there was a logic that
>>>> should be mentioned.
>>>>
>>>>
>>>> [...]
>>>>
>>>>
>>>>
>>>>>
>>>>> -5.13, table:
>>>>>>   "Specific RTP extension document MUST be referred"
>>>>>>
>>>>>>
>>>>>> [Suhas] The idea was to mean that , one should refer to the
>>>>>>
>>>>> specification
>>>>> that defines a specific RTP extension in order to understand the
>>>>> multiplexing behavior.
>>>>>
>>>>> Would the following rephrasing help instead
>>>>>
>>>>> "Refer to the document defining specific RTP Extension"
>>>>>
>>>>>
>>>>>
>>>>> Yes, thanks.
>>>>
>>>>
>>>>   I don’t understand what that means. If you mean to
>>>>>
>>>>>>    say “refer to specific document”, that shouldn’t use MUST.
>>>>>>
>>>>>> -5.22, table: "document needs to be referred" (several repetitions)
>>>>>>   I'm not sure what this means. Should it say "Refer to the
>>>>>>   specific document"?
>>>>>>
>>>>>>
>>>>>> Similarly as above, would this reprhasing help
>>>>>>
>>>>>
>>>>> "Refer to the document defining specific FEC Scheme
>>>>>
>>>>>
>>>>>
>>>>> Similarly as above, Yes, thanks. :-)
>>>>
>>>>
>>>>
>>>>> -6.3: "not clearly defined offer/answer usage"
>>>>>>   I'm not sure what is meant here. (Also, why is this not TBD or NOT
>>>>>>   RECOMMENDED?)
>>>>>>
>>>>>>
>>>>>> [Suhas] Since RFC3890 b=TIAS is not defined keeping O/A in mind,
>>>>> either
>>>>> the
>>>>> BUNDLE spec or this spec cannot define its mux behavior. This is due to
>>>>> applicability of these specs under SD{ O/A usages alone.
>>>>>
>>>>> I can rephrase the above as
>>>>> "not defined under SDP Offer/Answer usage"
>>>>>
>>>>>
>>>> WFM, thanks.
>>>>
>>>> [...]
>>>>
>>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>>