RE: Early media and AVP vs. SAVP

Randell Jesup wrote:
> One item under consideration is offering RTP/AVP but with an a=
> parameter that indicates SRTP is preferred (a=keymgt or a=crypto or
> a=srtp, etc).
>
> At one level this simply works - a responder who doesn't understand
> this trick should just ignore the a= value and respond with RTP/AVP
> and no keying.  And one that does understand it will respond with
> RTP/AVP but with an a= value finishing the key negotiation, and the
> call will be encrypted.

Right.  On the surface this is pretty slick.  It's the details where
this gets stickier.

> The problem is tied to why SAVP is a profile in the first place -
> you can't understand the incoming packets if they show up before
> 200 OK.

Any 1xx could contain an answer, too (not just the 200).  Without PRACK,
though, the answerer can't know that its 1xx arrived.  The standard way to
accomplish this is Security Preconditions
(draft-ietf-mmusic-securityprecondition-02.txt).

However, there is a neat solution that Jonathan has in ICE.  Here is the
excerpt from ice-09:

    To deal with possible losses of the provisional response,
    [the provisional response] SHOULD be retransmitted until
    some indication of receipt.  This indication can be ... 
    through the receipt of a STUN Binding Request with a
    correct username and password.  Even if PRACK is not used,
    the provisional response SHOULD be retransmitted using  the
    exponential backoff described in [11].

We could use a /similar/ technique for SRTP.  That is, we could have the
answerer retransmit its provisional response until it receives some sort of
packet from the offerer.  If the originating endpoint doesn't support ICE,
the 'some sort of packet' could be an SRTP packet.  There is some ugliness
around recvonly and possibly around firewalls and QoS enforcement devices
that won't want to permit an SRTP packet to leak through.  Anyway, this is a
straw man idea that has met with some favor in ICE as an easy way to
accomplish reliable provisional responses without PRACK and might also be
valuable for SRTP.

> If you try to play the incoming packets you'll get static
> or worse.
>
> If this trick is done, the only ways to avoid problems are: don't
> send SRTP media until ACK (can cause clipping, especially in a
> classic ATA+analog phone setup combined with packet loss),

There is an additional problem, that you might want to offer several
cryptographic transformations for SRTP.  For example, you might have
an offerer who wants to use AES-128, AES-256, and SHA256:

  m=audio 49170 RTP/SAVP 0
  a=crypto:1 AES_CM_128_HMAC_SHA1_32
       inline:AAAAAjBINUAvLEw6UzF3WSJ+PSdFcGdUJShpZZZZ|2^20|1:32
  a=crypto:2 AES_CM_256_HMAC_SHA1_32
       inline:CCCCd1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpYYYY|2^20|1:32
  a=crypto:3 AES_CM_256_HMAC_SHA256_32
       inline:FFFFd1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpXXXX|2^20|1:32

If you want to be able to decrypt arriving SRTP packets before you receive
the SDP answer, you need a way to identify which a=crypto line was selected
in the media path somehow. 

One idea, which we floated in the now-defunct
draft-wing-mmusic-sdes-early-media-00.txt, was to have the answerer use an
offerer-selected MKI value as an indicator of which a=crypto line the
answerer selected.  Once the answerer was sure the offerer had received the
SDP answer, the answerer could transmit packets without the MKI.  The MKI
makes those initial SRTP packet larger, which isn't too cool (if nothing
else, it messes up bandwidth calculations and QoS enforcement).

> or use something like this:
> 
> m=audio 1234 RTP/AVP 0 8 98 99
> a=keymgt foo...
> a=rtpmap:98 PCMU/8000
> a=rtpmap:99 PCMA/8000
> a=savp:98 99
> 

> The "a=savp:<payloads>" says that 98 and 99 are encrypted (pick your
> name - a=srtp, etc).  Even this is a problem, since in theory a
> (odd) UA might select 98 over 0 even if it didn't understand the
> a=savp line.  It shouldn't, but it's allowed to.

While we might only be worried about AVP versus SAVP, the problem
is really larger.  The problem is AVP versus SAVP versus AVPF versus
SAVPF.  If another profile is created in 2007, we will begin to see
an interesting explosion.

Flemming's draft-andreasen-mmusic-sdp-capability-negotiation-00.txt
walks through several approaches and makes a recommendation on how
to negotiate between AVP, SAVP, AVPF, and SAVPF.  Flemming presented
that document in MMUSIC; minutes are at
http://www3.ietf.org/proceedings/06jul/minutes/mmusic.txt

-d

> A safer alternative is to modify the codec names in some
> decipherable way:
> 
> m=audio 1234 RTP/AVP 0 8 98 99
> a=keymgt foo...
> a=rtpmap:98 SPCMU/8000
> a=rtpmap:99 SPCMA/8000
> 
> No UA should select those without knowing they're supposed to 
> be encrypted.
> 
> Note that all of these mean adding/duplicating a=rtpmap lines, and
> duplicating a=fmt lines, at a cost to packet size.
> 
> To help with packet size, you can include a way to modify the payload
> values:
> 
> m=audio 1234 RTP/AVP 0 8 98 99
> a=keymgt foo...
> a=rtpmap:98 SAVP/1/0
> a=rtpmap:99 SAVP/1/8
> 
> The rtpmaps for 98 and 99 are still needed since those are dynamic
> payloads and an SBC or other server might reject/block the call if
> there are undefined payload types.  They also include the mapping to
> the non-encrypted payload value so a=fmt values don't have to be
> repeated.  SBCs might cause some problem if they don't know this
> extension and think they need to know/understand all payload codecs.
> 
> The last idea I have would involve another port:
> 
> m=audio 1234 RTP/AVP 0 8 98 99
> a=keymgt foo...
> a=rtpmap:98 SAVP/1/1236
> a=rtpmap:99 SAVP/1/1236
> 
> This says send RTP data to 1234 and SRTP data to 1236.  This 
> means even more ports open for ICE, hand-mapping, etc.  Probably 
> not a good idea.
> 
> Another usage would be for the answerer to use a header 
> extension(!) to indicate SRTP until ACK is received.
>
> None of these are wonderful, but then again we're trying to work
> around a somewhat broken/non-existent capabilities exchange (when it
> comes to profiles especially).  I like the first one if you don't
> mind the chance of a rogue UA selecting one of the dynamic values by
> mistake.  Otherwise probably the 3rd one is probably the most in
> keeping with existing AVT usage.
> 
> -- 
> 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)