RE: draft-kaplan-best-srtp-keys-00.txt: a dual-mode approach

Hi Flemming, comments inline...

> -----Original Message-----
> From: owner-ietf-rtpsec@xxxxxxxxxxxx [mailto:owner-ietf-
> rtpsec@xxxxxxxxxxxx] On Behalf Of Flemming Andreasen
> 
> I read through your document, and my main comment is that we really need
> to agree on the scope of the problem we want to solve before we get into
> specific solution proposals such as this one. For example, the draft
> attempts to address backwards compatibility related to "RTP/AVP" or
> "RTP/SAVP" profile negotiation by simply listing the non-secure one, yet
> it does not address the equally important problem of the offerer listing
> say "RTP/AVPF" instead of "RTP/AVP" (or "RTP/SAVPF"). While I do have an
> opinion on the specific mechanism proposed in here and feedback on some
> technical issues in there, I think it's probably more useful to discuss
> and agree on the scope of the problem we want to solve first (per MMUSIC
> discussions).

The problem I'm trying to address is two-fold: (1) how to make an offer for
SRTP that won't fail if the answerer doesn't do SRTP, and (2) how to get a
key-exchange mechanism that will address both the constraints of devices
that can't reasonably do per-call public key and for whom secdes is
sufficient while addressing the needs for a more secure end-end key exchange
in the media-path.  I agree those are somewhat orthogonal issues and the
first one could/should be handled in the mmusic WG rather than RTPSEC (I
think I even say so in this draft).  Is that what you mean?

And if so, are you saying we need a requirements document for (1) above
before solution proposal, or can we just include the perceived requirements
in a draft addressing it with a solution, and argue about the requirements
from that?  (a la your capability-negotiation draft)


> Regardless, one specific comment: Section 6.3 talks about sending an
> "updated answer" in the 200 OK without a new offer. You cannot do this,
> since RFC 3261 rules require the SDP in the 200 OK to be the same as in
> any provisional response if the 200 OK contains the answer to the
> original offer (i.e. no additonlal offer/answer exchanges in between).

Yeah, I was waiting for someone to call me on that.  :)  I'm not even sure
it's legal per 3264.  But I see it all the time, and it seems to work.  Part
of that may be because UAs expected to handle forking issues where this
could happen, but I see it being explicitly used these days in early-media
"services".  For example a rich progress tone service playing a sound file
from a media server while the target is hunted for.  So I was just
suggesting that could be done where the early media is RTP and the
established media is SRTP, which I realize is very bad form to put into a
draft.  I think I'll just remove it.

-hadriel