Re: [MMUSIC] Review draft-ietf-mmusic-sdp-mux-attributes-06

"Stach, Thomas" <thomas.stach@unify.com> Thu, 15 January 2015 15:22 UTC

Return-Path: <thomas.stach@unify.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED991B2C15 for <mmusic@ietfa.amsl.com>; Thu, 15 Jan 2015 07:22:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.389
X-Spam-Level: **
X-Spam-Status: No, score=2.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, J_CHICKENPOX_111=0.6, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1N79Ne8c_tP for <mmusic@ietfa.amsl.com>; Thu, 15 Jan 2015 07:22:53 -0800 (PST)
Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 4ADCA1B2C14 for <mmusic@ietf.org>; Thu, 15 Jan 2015 07:22:52 -0800 (PST)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 056C31EB8591; Thu, 15 Jan 2015 16:22:51 +0100 (CET)
Received: from MCHP04MSX.global-ad.net ([169.254.1.138]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0195.001; Thu, 15 Jan 2015 16:22:50 +0100
From: "Stach, Thomas" <thomas.stach@unify.com>
To: Suhas Nandakumar <suhasietf@gmail.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: Review draft-ietf-mmusic-sdp-mux-attributes-06
Thread-Index: AdAsJEASQouJwUUoSvOAW0BcJAaOQgDw7ieAADr8ZgA=
Date: Thu, 15 Jan 2015 15:22:50 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE121E2856BD@MCHP04MSX.global-ad.net>
References: <F81CEE99482EFE438DAE2A652361EE121E280FFD@MCHP04MSX.global-ad.net> <CAMRcRGSLhajoudbjdS0Z=91N-ZxEpfLJBtE297jbKrh2RMJYrA@mail.gmail.com>
In-Reply-To: <CAMRcRGSLhajoudbjdS0Z=91N-ZxEpfLJBtE297jbKrh2RMJYrA@mail.gmail.com>
Accept-Language: de-AT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/A7-nuANgW8hnB0sxpJ5dmclya00>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Review draft-ietf-mmusic-sdp-mux-attributes-06
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jan 2015 15:22:55 -0000

Suhas,
just a few replies below ...

 
5.7 a=crypto
I don’t think the text goes far enough. 
The category TRANSPORT can only be applied if one assumes that all bundled m-lines contain the a=crypto attribute and together with the same crypto suite.
Otherwise, if you want to bundle m-lines offering SRTP with some that offer RTP, the RTP m-lines would have inherit the SRTP master key and would be encrypted.
One resolution could be a restriction to bundle only m-lines that all offer SRTP and use the same SRTP keying mechanism.
 
[Suhas]. This was the assumption made as required by Section 10.1.1 of BUNDLE draft which mandates the proto value for all the m=lines BUNDLED MUST be same. Thus bundling RTP/AVP with RTP/SAVP for example is not allowed by design.
[TS] Yes, you're right
 
Alternatively, you could also apply the NORMAL category and use the key material as provided for the corresponding m-line, if any.
The correct key material for a specific RTP stream would have to be determined via the RTP header extension from draft-bundle.
Using NORMAL in such a way would also allow for bundling of RTP and SRTP m-lines, even if the keying material is provided by different key exchange mechanism like MIKEY and SDP Security Descriptions.

[Suhas] - I would prefer deferring this to future specifications on defining the procedures to use different keying mechanisms for SRTP keys in a given Bundle group.
[TS] OK. This might get more complex than it looks at first sight. TRANSPORT keeps thing simple.

OTOH even if there are m=lines that differ in the keying mechanisms, the category TRANSPORT implies that the keying mechanism corresponding the BUNDLE address needs to be considered. So the Offerer/Answerer has a choice on choosing which m=line's BUNDLE-tag appears first in the BUNDLE group.
 
 
5.14 a=rtcp attribute
The category needs to be changed from IDENTICAL to TRANSPORT.
Otherwise it conflicts with https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-14#section-10.3.2 
In case of a=rtcp-mux draft-bundle prescribes a=rtcp with a port identical to the RTP port and deliberately avoided choosing identical RTP ports in the m-lines.
If ICE is used, a=rtcp would carry the default RTCP candidate, which again would not necessarily be identical for all m-lines.

[Suhas] : Completely agree. Thanks for catching this. I will update the draft to reflect the same 
 
5.35 a=key-mgmt attribute 
 
The table is a bit misleading as it seems to imply that there is a a=mikey attribute, where the prtcl-id  value in the a=key-mgmt attribute is actually meant. Similar as for section 5.7 the prtcl-id  would need to be the same for all bundled m-lines. 
The key-mgmt-data part (i.e. keying material) of the a=key-mgmt attribute could however still be different for each m-lines similar as for the a=crypto attribute. 
Due to the similarities with a=crypto (or a=fingerprint in section 5.36) I think that TRANSPORT (or NORMAL as proposed above) is a better fit than IDENTICAL. 
 
5.39 ZRTP
Similar to section 5.7, the RTP header extension from draft-bundle would allow that the a=ZRTP-hash can be associated to the corresponding media stream. With that I don’t see why this can’t be changed from NOT RECOMMENDED to NORMAL. 
TRANSPORT couldn’t probably used as not all m-lines are required to use a=ZRTP-hash

[Suhas] :  NOT RECOMMENDED still seems to be appropriate for the very same reason that some of the media lines might not have zrtp-hash undefined.  However, in future if there exists a specification that describes the header extension for using zrtp-hash in BUNDLE scenario, we can always upgrade the mux category referencing that specification.
[TS] OK

I'm also fine with the rest of your responses.


Regards
Thomas