RE: Early media and AVP vs. SAVP

Randell Jesup wrote:

> "Hadriel Kaplan" <HKaplan@xxxxxxxxxxxxxx> writes:
> >That's essentially the embedded proposal in the best-key draft
> >(http://www.ietf.org/internet-drafts/draft-kaplan-best-srtp-keys-00.txt),
> >although Flemming asked that piece of best-key be moved into a
> >separate doc for mmusic discussion rather than this group.
> >(Working on that)
> >
> >The proposed method to handle the issue you raise is to make the
> >answerer use the MKI tag in RTP packets for a while.  This has some
> >issues but seemed the easiest/simplest.  If the far-end chose RTP
> >(or didn't know srtp) it would send media anytime as normal (early
> >media, etc.).  If it understood  the offer and chose SRTP, it would
> >tag the media.
> >
> >The offerer won't and can't decrypt SRTP until it gets an SDP
> >answer anyway, since the keys sent are the transmit side ones.
>
> Ah, right, secdes - I wasn't assuming any particular key-exchange
> protocol (secdes, mikey, whatever you want).  Receive-side keys have
> a distinct advantage in that the answerer can transmit (and be
> decoded correctly) as soon as they send the OK, even if the OK is
> lost and has to be retransmitted.
>
> I'm confused (not being up-to-speed on the reasons for decisions in
> secdes) why transmit-side keys were chosen  - normal INVITE SDP
> usage is that you have to be ready to receive as soon as the INVITE
> is sent - but in secdes you aren't ready to actually receive until
> you see the answer.  In packet-loss and longer-SIP-delay cases, you
> might have 1/2, 1 or even more seconds of clipping of the answerer.
> When each side is ready to send they have the key they need to send,
> if you use receive-side keys in the exchange.

Jon Peterson wanted us to describe why we did that, too, as the
question keeps coming up.

Please see Appendix A of RFC4568, <http://rfc.net/rfc4568.html#p40>.

...


An issue (perhaps resolvable?) with using MKI:


> How does MKI really help you distinguish between RTP and SRTP?  If
> you know that the codec encoding is a fixed length, you can key off
> the payload length to know there's an MKI there, but many codecs
> (video especially) are variable-length, so you'd have to look at the
> last N bytes of the packet and see if they "appear" to be an MKI tag
> - and you could get fooled unless there's a reasonably strong hash
> value to use.

As long as the offerer chooses the MKI value, it's entirely up to the
offerer to Do A Good Enough Job to find its own MKI value at the end 
of the SRTP-encrypted packet.  The offerer would have to choose the MKI
value for the answerer to use, much like with your proposal where the
offerer chooses the RTP payload value for the answerer to use.

> Instead of MKI, we may want to consider the payload-value based
> distinction from my proposal.  It also answers the [note] from
> the paragraph I quoted, allows early media, and doesn't lock one
> into secdes.

The MKI trick could be extended to MIKEY as easily as it could be
extended to Security Descriptions.  

I concur, though, that using the payload value may well be useful
to address this problem.  I'm weighing the benefits of addressing
this problem all in SDP and RTP payload values like this, versus
the benefits of moving key negotiation into the media path (ZRTP,
MIKEYv2, DTLS-SRTP).

-d