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

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

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