Re: Early media and AVP vs. SAVP

[Randell Jesup <rjesup@xxxxxxxxx>]

"Hadriel Kaplan" <HKaplan@xxxxxxxxxxxxxx> writes:
>> 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.
>
>Yeah, I didn't like it either but the reasons are fairly legit.  The authors
>included the reasons in the Appendix to RFC 4568.  Rob Raymond and Dan Wing
>had a draft for an early-media version which tried to address this, but I
>think that draft expired.  The only answer to your issue right now is
>pre-conditions, AFAIK. 

Answering the reasoning in Appendix A of RFC 4568 on the problems with
receive-direction keys:

   Scenario A (non-forking case): The RFC states that the big problem is
   not being able to decode packets if multiple crypto attributes were
   offered (until the response).  This is a non-issue, since the
   alternative (selected by the RFC) is to use transmit keys, which have
   the same problem, but have it for all cases, not just the
   multiple-attribute case.  So this reason is invalid, IMHO.

   Scenario B (serial forking/forwarding case):  This objection seems to
   be based on the chance that the phone being forwarded to (Carol) selects
   the same SSRC as the forwarder (Bob) had already used, combined with the
   caller (Alice) not considering this an SSRC collision.  This objection
   could be answered by stating that if you implement the RFC you have to
   also consider this a collision.  Barring a broken UA (where SSRCs can be
   predicted) this shouldn't be an issue, and even if it were, it's pretty
   minor problem.

   Scenario C (parallel forking): SSRC collision - again, same comments as
   above; define it as a collision.  As for both using the same master key
   unknowingly and not knowing when to rekey - even for an rate of 1000
   packets per second it will be ~8000 years before the rekeying is
   required, so having two using the master key doesn't seem a true
   security risk (ok, for SRTCP on AVP it's ~300 years - still a pretty
   long time for a connection to last). :-)

To recap:
   Problem 1: if you offer multiple crypto suites, the problem is no worse
   than it is with transmit-keys.

   Problem 2: SSRC collisions yielding 2-time pad issues - define that as a
   collision that should yield a reaction/rekeying.  It _should_ be a 1 in
   4 billion issue anyways, for all but a pretty broken phone.  The caller
   can notice the collision.

   Problem 3: If we let people use the same SSRC (sequentially), the ROC
   can be wrong.  See problem 2 - don't allow that.

   Problem 4: key lifetime - In theory yes this is an issue; in practice
   I'd say no it isn't - and the caller knows about this; if it cares it
   could force a rekeying before the key lifetime expires (in a a few
   generations from now).

I would reject these problems and arguments for the practical cases I need
to handle, and prefer and use receive-key protocols.


However, this RFC is what it is.  My point was to NOT tie the BEST-KEY
negotiation to any particular session-level key negotiation method; it
should be applicable to most of them (I want to use it).  It may want to
discuss how that affects certain protocols (like this RFC), and the
mechanism suggested for figuring out if incoming packets are SRTP or RTP.

>> 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.
>
>Yup, that's one of the issues with it, and I figured you would note that
>(being a video-focused guy :)

:-)

>Is there a real-world need/use for early-video?  We're not talking about
>video before the user actually answers - we're only talking video before an
>SDP answer comes back, which can be in 18x.  I was going to say "don't
>decode it if you don't know". 

It's a bad idea to decode it if you don't know - most video decoders don't
like totally random bits, though they usually just complain and don't show
anything.  As for early-video - if you put an answer in a 18x, you could do
"early" video/audio, but you still have the issue of "what happens if the
packet with the SDP gets lost?"  Yes, it will get retransmitted, but that
might be seconds later, and the caller needs to see an answer before
decoding (with transmit keys), even if the incoming data is actually 
unencrypted (unless you want to get into all sorts of nasty heuristics).
SDP in 18x reduces the probable duration and occurance frequency of
clipping, but doesn't eliminate them.  

>> 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.
>
>Yeah, that was one of the proposals, as was specifying a ssrc, using another
>port, using the padding mechanism, and setting the marker bit.  The unique
>PT was my favorite of those 3, but I was worried it would make it harder for
>sdes-supporting UA's to modify themselves to support it, and it results in a
>lot of PTs. (I was going for ease-of-transition to get broader use)  Also,
>you have to be able to handle SRTCP, fwiw.

That is an issue, though SRTCP might be easier to figure out directly from
the packet (and I think can be).

As for payload-types - yeah, you could add a lot, but with some of
these ideas you'd add 3-4 characters each for the m= line, and then
(for a=savp:0-98,8-99 etc) you'd add 7+(5-to-8) for each, for a total of
about 7 + N*(8 to 12) characters, where N is the number of regular payloads.

If you offer 10 payloads (a lot), you'd be adding around 100 bytes to the
SDP.

>But I'm cool with anything that makes it work and will be popular.

Me too.  SRTP won't be used in practice much if it's not trivially
compatible with existing RTP/AVP phones.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@xxxxxxxxx
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)