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 20:32:10 +0100

Hadriel,

See below.

John

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: 05 September 2006 16:30
> To: Elwell, John; 'Francois Audet'; [email-masked]
> Subject: RE: [MMUSIC] FW: I-D 
> ACTION:draft-kaplan-mmusic-best-effort-srtp-00.txt
> 
> Hi John,
> Thanks for reviewing the draft!  Comments inline...
> 
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]]
> > 
> > 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).
[JRE] The problem is an auto-answer device will probably not send 18x., or
will send 18x immediately followed by 2xx.

> 
> 
> > 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.
[JRE] In the context of what this draft is proposing, I agree that it would
be ambiguous, and hence my alternative proposal for best effort below.
  
> 
> 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.
> 
> 
> > 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. 
[JRE] Such legacy UAs would not be SDP-compliant. I guess it depends how
common such devices are in practice.

> -hadriel

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 5 Sep 2006 16:21:41 -0400

> will send 18x immediately followed by 2xx.

But that's a good thing, isn't it?  If it's an auto-answer, it sends 200ok
right away.  There is no clipping/early-media problem.

> common such devices are in practice.

I don't believe they're non-compliant, and we've been told they're not
uncommon. (probably more common than srtp-capable devices ;)  

I think 3261 regarding 488 responses allows them to reject the offer of
unsupported media capabilities.  While 3264 certainly says how to handle
rejecting specific streams and not others, there's nothing to say you must
accept an offer if you can support only a subset of the streams; so I guess
people took the easy way out.

-hadriel

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Sep 2006 15:32:02 -0500

> > [JRE] Such legacy UAs would not be SDP-compliant. I guess 
> it depends 
> > how common such devices are in practice.
> 
> I don't believe they're non-compliant, and we've been told 
> they're not uncommon. (probably more common than srtp-capable 
> devices ;)  
> 
> I think 3261 regarding 488 responses allows them to reject 
> the offer of unsupported media capabilities.  While 3264 
> certainly says how to handle rejecting specific streams and 
> not others, there's nothing to say you must accept an offer 
> if you can support only a subset of the streams; so I guess 

Exactly.

Again, as per my other email, the really real problem is there is 
no path to go from where we are at today, to SRTP without suddently
breaking something.