[MMUSIC] RE: Question on draft-ietf-mmusic-kmgmt-ext-15

"Karl Norrman (KI/EAB)" <karl.norrman@ericsson.com> Fri, 21 October 2005 14:23 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxnq-0005Dv-3A; Fri, 21 Oct 2005 10:23:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESxno-0005Dq-3s for mmusic@megatron.ietf.org; Fri, 21 Oct 2005 10:23:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24397 for <mmusic@ietf.org>; Fri, 21 Oct 2005 10:23:12 -0400 (EDT)
Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ESxzs-0002rr-Fu for mmusic@ietf.org; Fri, 21 Oct 2005 10:35:58 -0400
Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7953125E; Fri, 21 Oct 2005 16:23:11 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 16:21:17 +0200
Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 16:21:17 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 21 Oct 2005 16:21:16 +0200
Message-ID: <3AD208E1F0D5EB47AC3C5617420BCB020147B24B@esealmw104.eemea.ericsson.se>
Thread-Topic: Question on draft-ietf-mmusic-kmgmt-ext-15
Thread-Index: AcXVfP4r9xTiRK9CTXu6d5KU1jzOeQAzNgBg
From: "Karl Norrman (KI/EAB)" <karl.norrman@ericsson.com>
To: "Elwell, John" <john.elwell@siemens.com>
X-OriginalArrivalTime: 21 Oct 2005 14:21:17.0405 (UTC) FILETIME=[B34D78D0:01C5D64A]
X-Brightmail-Tracker: AAAAAA==
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Content-Transfer-Encoding: quoted-printable
Cc: elisabetta.carrara@ericsson.com, mmusic@ietf.org, "Jari Arkko (JO/LMF)" <jari.arkko@ericsson.com>, "Fredrik Lindholm (AL/EAB)" <fredrik.lindholm@ericsson.com>
Subject: [MMUSIC] RE: Question on draft-ietf-mmusic-kmgmt-ext-15
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org

Hello!

A Crypto session is equivalent to an SRTP session 
when using the SRTP profile in MIKEY (see Appendix 
A of RFC 3830).  Hence, no other media than SAVP (in your example) can 
be regarded as a Crypto Session.  So for your examples below, 
4 is the answer (only SAVP counts).

Regards,
Karl

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com]
> Sent: den 20 oktober 2005 15:49
> To: Jari Arkko (JO/LMF); elisabetta.carrara@ericsson.com; Fredrik
> Lindholm (AL/EAB); Mats Näslund (KI/EAB); Karl Norrman (KI/EAB)
> Cc: mmusic@ietf.org; Fries, Steffen
> Subject: Question on draft-ietf-mmusic-kmgmt-ext-15
> 
> 
> In section 7.1, first bullet it states:
> "When referring to streams described in SDP, MIKEY SHALL allocate two
> consecutive numbers for the related Crypto Session indexes 
> (as each stream
> can be bi-directional). An example: if the SDP contains two m lines
> (specifying whatever direction of the streams), and MIKEY is 
> at the session
> level, then MIKEY allocates e.g. the Crypto Sessions 
> Identifiers (CS IDs,
> see [MIKEY)] '1' and '2' for the first m line, and '3' and '4' for the
> second m line."
> My question is, what if not all m= lines use SRTP transport, 
> e.g., some use
> RTP transport? Must MIKEY still allocate Crypto Sessions for 
> each m= line,
> even though there is no way of indicating anything other than 
> "SRTP" as the
> protocol type in the security profile of a Crypto Session? Or does the
> statement quoted above apply only to media that require a 
> security profile?
> 
> Consider this example:
> m=xxxx ppp RTP/SAVP
> m=xxxx ppp RTP/AVP
> m=xxxx ppp RTP/SAVP
> Must I allocate 6 Crypto Sessions (2 for each m= line) for 
> this, i.e, CS ID
> 1 and 2 to the first, CS ID 3 and 4 to the second, etc.? If 
> so, what goes in
> the protocol type of the security profile for the CS ID 3 and CS ID 4
> entries in the CS ID map?
> Or can I allocate just 4 Crypto Sessions, which implicitly 
> would apply to
> the first and last m= lines?
> 
> Consider also this example:
> m=xxxx ppp RTP/SAVP
> m=xxxx ppp RTP/SAVP
> m=xxxx ppp RTP/AVP
> A similar question, although note here that the SRTP media 
> are contiguous,
> so if I only allocate 4 Crypto Session, then they would map 
> to the first and
> second m= lines (i.e., no gap). Would this be preferable, or 
> do I still need
> to allocate 6?
> 
> John
> 

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic