RE: Fwd: I-D ACTION:draft-zimmermann-avt-zrtp-03.txt

["Dan Wing" <dwing@xxxxxxxxx>]

> Perhaps.
> 
> However, I guess this is not the place to discuss exactly how 
> the early
> media is solved in SIP. All I'm saying is that it seems like a large
> number of people do think that the SDP answer should be sent to the
> calling UA before early media is transmitted, so I don't think it's a
> strong justification not to use a signalling based solution. 
> 
> Some intermediate nodes will also require the SDP answer 
> before passing
> anything trough gates etc (no matter whether it will be a both-way or
> one-way throughconnect).

To summarize your comments, I believe you're saying this requirement:

   R5:  A solution SHOULD avoid clipping media before SDP answer
        without additional SIP signalling.

isn't necessary and doesn't need to be met.  Rather, you're saying that
SIP should just flat-out require the answerer not send media until 
its answer is received by the offerer.  As you say, this isn't an 
RTPSEC (SRTP) issue per se but also applies to RTP, thus isn't 
something RTPSEC need worry about.

> >>Another thing to remember is that the signalling path is normally 
> >>"two-way" from the start, while the media plane path may only be 
> >>one-way (enforced using gates etc) during the session setup, which 
> >>means that mechanisms realying on terminals performing two-way 
> >>negotiation on the media plane may not work (at least not 
> >>until INVITE 200 OK has been sent).
> > 
> >Operating with those systems is not a requirement gathered in
> >draft-wing-media-security-requirements.  Should it have been?
> 
> I think so.
> 
> We need to remember that media will not always be end-to-end. You may
> have SBCs, transcoders, media mixers etc, in the path which will
> terminate media. I don't think that is covered in requirements.

It's not mentioned in the requirements.

> >Note that those systems won't work with ICE, either.
> 
> Maybe not.

If those systems don't have exceptions for DTLS-SRTP, RTP header
extensions, or ZRTP packets, it isn't too likely they have extensions
for ICE, either...

> >What do you advise we do -- change those get those systems changed 
> >or give up and key entirely in SIP?
> >There was consensus in Montreal that we can't achieve 
> success with an 
> >entirely call- signaling-based approach.  I don't see how we 
> >could revisit that now, a week before the Prague IETF.
> 
> I wasn't in Montreal, and I wasn't even following this work at that
> time, so I appologize for bringing this up at this stage. 

That's alright -- better now than on Monday in Prague.

> I am not sure I am totally convinced about all justifications why a
> media plane mechanism would be "better". But, I have to admit that I
> haven't studied all the details, so I am not really arguing for or
> against any specific solution at this point. I just think 
> there are some things that need to be taken into consideration.

Without a list of requirements, we cannot make progress.  From
your statement above, I believe your requirement is:

  A solution MUST NOT expect packets to be received on the 
  media path until 200 OK, because the media path will be 
  blocked by middleboxes until the 200 OK.

Is that an accurate description of the requirement?

-d