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

Hadriel Kaplan wrote:

> 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?
>  
Yes.


> 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)
>  
I think requirements for 1 belong in a separate document (which belongs 
to MMUSIC), but we also still need requirements for 2. I believe those 
fall-out of the rtpsec "BOF" discussion we had in Montreal and they 
should be provided in a separate document (since we have a lot of 
different proposed solutions currently and probably more to come).

>  
>
> > 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, 
Yeah, except they are different dialogues (but "same difference" in some 
implementations I'm sure :-)

> 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.
>  
Sounds good.

-- Flemming

> -hadriel
>
>