Subject: RE: [MMUSIC] FW: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp- 00.txt

From: "Elwell, John" <[email-masked]>
Date: Tue, 05 Sep 2006 09:06:14 +0100

This Internet Draft tackles a well-known problem in deploying SRTP, and
clearly has some benefits. However, it fails to solve a couple of problems.

First, there are some options within MIKEY that do not rely on a response in
the SDP answer, and these options have the distinct advantage that SRTP can
be rendered before SDP answer arrives, thereby avoiding speech clipping.
With the possibility of receiving either RTP or SRTP on the same port, this
is clearly no longer possible with the proposal in the draft (as the draft
acknowledges). The use of pre-conditions is quite a heavy price to pay,
particularly in a heavy forking situation.

Second, one of the strengths of MIKEY is that it can be used at session
level, thereby having a single key management exchange for two or more
media. It seems a pity that the draft throws this away just to achieve a
slightly more efficient best effort solution.

Perhaps another way of achieving best effort is to use two m= lines per
medium, m=rtp/savp first (with a=keymgmt or a=crypto attributes or with
a=keymgmt at session level) and m=rtp/avp second. In this way they can use
different ports. A UAS that does not support SRTP would reject SRTP and
accept RTP. A UAS that supports SRTP and can accept the keying proposal
would accept SRTP and reject RTP. Of course, there may be equipment that is
able to accept both streams, in which case the UAC, if it can't handle both,
would have to disable the RTP one using the well-known techniques from RFC
3264, but that would probably account for only a small minority of cases. As
a further improvement an extension to the SDP grouping framework could be
defined, whereby the two m= lines would be marked as alternatives.

Advantages:
- Better exploitation of the various MIKEY options.
- Explicit indication of SRTP (rtp/savp). 

John

> -----Original Message-----
> From: Francois Audet [mailto:[email-masked]] 
> Sent: 01 September 2006 21:19
> To: [email-masked]
> Subject: [MMUSIC] FW: I-D 
> ACTION:draft-kaplan-mmusic-best-effort-srtp-00.txt
> 
> We would like to sollicit comments on the following draft.
> 
> Thanks.
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > Sent: Thursday, August 31, 2006 12:50 PM
> > To: [email-masked]
> > Subject: I-D ACTION:draft-kaplan-mmusic-best-effort-srtp-00.txt
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > 
> > 
> > 	Title		: Session Description Protocol (SDP) 
> >                           Offer/Answer Negotiation For Best-Effort 
> >                           Secure Real-Time Transport Protocol
> > 	Author(s)	: F. Audet, H. Kaplan
> > 	Filename	: draft-kaplan-mmusic-best-effort-srtp-00.txt
> > 	Pages		: 15
> > 	Date		: 2006-8-31
> > 	
> > This document defines the requirements and a proposed solution for 
> >    an SDP Offer/Answer exchange model for negotiating 
> > best-effort SRTP 
> >    keys, i.e., in a backward-compatible manner with non-SRTP 
> > devices.  
> >    The proposed solution is a trivial interpretation of the 
> usage of 
> >    the profile and the usage of SDP indication of [sdesc] 
> and [kmgmt].
> > 
> > A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kaplan-mmusic-best-e
> ffort-srtp
> -00.txt
> > 
> > To remove yourself from the I-D Announcement list, send a 
> message to 
> > [email-masked] with the word unsubscribe in 
> > the body of 
> > the message. 
> > You can also visit 
> > https://www1.ietf.org/mailman/listinfo/I-D-announce 
> > to change your subscription settings.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with the 
> > username "anonymous" and a password of your e-mail address. After 
> > logging in, type "cd internet-drafts" and then 
> > "get draft-kaplan-mmusic-best-effort-srtp-00.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE 
> > /internet-drafts/draft-kaplan-mmusic-best-effort-srtp-00.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> > mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> > 
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 5 Sep 2006 11:29:47 -0400

Hi John,
Thanks for reviewing the draft!  Comments inline...

> From: Elwell, John [mailto:[email-masked]]
> 

The issue of how to disambiguate early media is being left out of this draft
on purpose.  There are several ideas out there for how to do that, but we
decided to leave that out for some future draft to solve.
Pre-conditions is not the only alternative, though: the answerer can send
the answer in a 18x provisional response.  The "clipped" time would then be
very short (essentially the difference between the signaling and media path
one-way delay).

> slightly more efficient best effort solution.

An early rev of the draft did encompass session-level kmgmt.  The problem
was you can offer some media streams as srtp and some not, for the same
session, by encoding RTP/SAVP for only those m= lines you want to be
secured. (as you know)  Therefore not encoding SAVP with a best-effort
session-level kmgmt created an ambiguous offer.  The only thing that made
sense was treating it as if all lines were SAVP if none were, though even
that would be ambiguous with a legacy kmgmt session-level offer requesting
no SRTP - though one wonders why there would be such a thing.  

Would you prefer that?  I.e., is there no use case for a session-level offer
with no secure media streams, and are session-level mikey offers usually for
all the streams to be secure?  If so we could say to do that, and if the
offerer wants to only secure some but not all the media streams, then it has
to stick to SAVP encoding or media-level kmgmt.

> defined, whereby the two m= lines would be marked as alternatives.

The problem with this is we're trying to make it so that the offer works
seamlessly with as large a population of legacy answering UAs (i.e.,
RTP-only) as possible.  If you think offering two m= lines will work
successfully with legacy UA's, then you don't need a draft to do that AFAIK.
You're simply offering two streams.  The problem I've seen is legacy UAs
will reject the whole offer (e.g., send a 488), not just the unsupported
streams. 

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Sep 2006 11:53:57 -0500

See in-line.

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Tuesday, September 05, 2006 8:30 AM
> To: 'Elwell, John'; Audet, Francois (SC100:3055); [email-masked]
> Subject: RE: [MMUSIC] FW: I-D 
> > With the possibility of receiving either RTP or SRTP on the 
> same port, 
> > this is clearly no longer possible with the proposal in the 
> draft (as 
> > the draft acknowledges). The use of pre-conditions is quite a heavy 
> > price to pay, particularly in a heavy forking situation.
> 
> The issue of how to disambiguate early media is being left 
> out of this draft on purpose.  There are several ideas out 
> there for how to do that, but we decided to leave that out 
> for some future draft to solve.
> Pre-conditions is not the only alternative, though: the 
> answerer can send the answer in a 18x provisional response.  
> The "clipped" time would then be very short (essentially the 
> difference between the signaling and media path one-way delay).

Right.

The whole idea is backward compatibility. Further improvement is
certainly
what we have in mind, but we want "a way to get there". 

Noboby will deploy SRTP if you can't get there from here.

> 
> > Second, one of the strengths of MIKEY is that it can be used at 
> > session level, thereby having a single key management 
> exchange for two 
> > or more media. It seems a pity that the draft throws this 
> away just to 
> > achieve a slightly more efficient best effort solution.
> 
> An early rev of the draft did encompass session-level kmgmt.  
> The problem was you can offer some media streams as srtp and 
> some not, for the same session, by encoding RTP/SAVP for only 
> those m= lines you want to be secured. (as you know)  
> Therefore not encoding SAVP with a best-effort session-level 
> kmgmt created an ambiguous offer.  The only thing that made 
> sense was treating it as if all lines were SAVP if none were, 
> though even that would be ambiguous with a legacy kmgmt 
> session-level offer requesting no SRTP - though one wonders 
> why there would be such a thing.  
> 
> Would you prefer that?  I.e., is there no use case for a 
> session-level offer with no secure media streams, and are 
> session-level mikey offers usually for all the streams to be 
> secure?  If so we could say to do that, and if the offerer 
> wants to only secure some but not all the media streams, then 
> it has to stick to SAVP encoding or media-level kmgmt.

John, if you help us with the keymgt (for MIKEY), we can certainly
add it in.

> 
> > Perhaps another way of achieving best effort is to use two m= lines 
> > per medium, m=rtp/savp first (with a=keymgmt or a=crypto 
> attributes or 
> > with a=keymgmt at session level) and m=rtp/avp second. In this way 
> > they can use different ports. A UAS that does not support 
> SRTP would 
> > reject SRTP and accept RTP. A UAS that supports SRTP and can accept 
> > the keying proposal would accept SRTP and reject RTP. Of 
> course, there 
> > may be equipment that is able to accept both streams, in which case 
> > the UAC, if it can't handle both, would have to disable the RTP one 
> > using the well-known techniques from RFC 3264, but that 
> would probably 
> > account for only a small minority of cases.
> > As
> > a further improvement an extension to the SDP grouping 
> framework could 
> > be defined, whereby the two m= lines would be marked as 
> alternatives.
> 
> The problem with this is we're trying to make it so that the 
> offer works seamlessly with as large a population of legacy 
> answering UAs (i.e.,
> RTP-only) as possible.  If you think offering two m= lines 
> will work successfully with legacy UA's, then you don't need 
> a draft to do that AFAIK.
> You're simply offering two streams.  The problem I've seen is 
> legacy UAs will reject the whole offer (e.g., send a 488), 
> not just the unsupported streams. 

Exactly.

The whole idea is to have something that is backward compatible.
Otherwise,
it won't be deployed.

This whole draft is about making SRTP deployable today, in a best-effort
backward compatible way.