Subject: [MMUSIC] Feedback requested on requirements

From: [email-masked] (Dale R. Worley)
Date: Tue, 16 Apr 2013 11:49:56 -0400 (EDT)

DES F11  It must be possible to add and remove one way video flows
      within the bundle without requiring an additional offer/answer
      cycle.

   DES F12  Bundling must not interfere with ICE usage, and in
      particular, ICE's ability to negotiate both IPv4 and IPv6
      addresses simultaneously.

   DES F13  It is desirable for RTP media to appear on the wire as
      (encrypted) SRTP packets and for RTCP reports to appear on the
      wire as (authenticated but not encrypted) SRTCP packets.  Thus,
      encryption of RTP/RTCP via DTLS and encapsulation of multiplexed
      packets is not desirable.

Comments?

Dale

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 17 Apr 2013 09:55:33 +0200

>       within the bundle without requiring an additional offer/answer

I think this is desirable and possible to support in certain types of
applications. Some do require additional information that needs to be
signalled somewhere. If one have chose O/A for that transport then this
requirement can't be meet. However, I do agree with the intention that
it should be possible.

>       addresses simultaneously.

I believe the intention is right here, but I stumble on the word
"negotiate". To my understanding the usage of two address families are
not really negotiated. It is more, here are my candidates, create
candidate pairs within each family and then follow the check-board
algorithm.

>       packets is not desirable.

I am not certain I understand the motivations for this requirement. Is
the need to having unencrypted RTCP for third party monitors? From a
security point of view I see issues with such blanket statements. There
can be information in the RTCP that is sensitive for privacy reasons.

For the last sentence are you really meaning DTLS or DTLS-SRTP. There is
a big difference here.

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 18 Apr 2013 16:47:36 -0400 (EDT)

> From: Magnus Westerlund <[email-masked]>

> candidate pairs within each family and then follow the check-board

The object of the verb "negotiate" is "addresses": "ICE negotiates
addresses".  There may be a better word than "negotiate" for what ICE
does.

In any case, Andy Hutton expressed concern that the bundling mechanism
should not limit dual-stack implementations in any way, so I included
this desideratum.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 18 Apr 2013 16:47:04 -0400 (EDT)

> can be information in the RTCP that is sensitive for privacy reasons.

I omitted the discussion of this desideratum:

   This desideratum was suggested by Martin Thompson (http://
   www.ietf.org/mail-archive/web/mmusic/current/msg10400.html) and Dan
   Wing (http://www.ietf.org/mail-archive/web/mmusic/current/
   msg10408.html).

The two referenced messages are:

    From: Martin Thomson <martin.thomson at gmail.com>
    Date: Wed, 27 Feb 2013 14:11:21 -0800
    Cc: "mmusic at ietf.org" <mmusic at ietf.org>

    There are no security reasons why this wouldn't work.  Some
    applications already do this.

    The actual problems are manifold:

     - SRTP was designed to have a low per-packet overhead.  The DTLS
    record layer has a larger per-packet overhead.
     - SRTP exposes certain attributes in clear text for intermediaries to
    use.  Intentionally.  Using DTLS would lose this.
     - SRTP enjoys wide support.  This would harm interoperability with
    existing communication devices, forcing the use of more complex
    gateways.

    From: "Dan Wing" <dwing at cisco.com>
    Date: Thu, 28 Feb 2013 14:51:52 -0800
    Delivered-to: mmusic at ietfa.amsl.com

    SRTP (RFC3711) was carefully and purposefully designed so the RTP header 
    remains in the clear, and DTLS-SRTP was also purposefully designed so
    after the DTLS-SRTP handshake establishes the SRTP keys, the SRTP packets
    flow over the wire exactly like they would for any other keying 
    mechanism (ZRTP, MIKEY-*, Security Descriptions).

    By sending SRTP packets with their RTP header in the clear, it allows:
      * the RTP header to be compressed (cRTP [RFC2508], ECRTP [RFC3545])
      * analysis devices to see where, on a network path, SRTP packets 
	are lost, delayed, or get mis-ordered.
      * analysis devices to see SRTCP receiver reports and sender reports,
	which are typically authenticated but in the clear.

The reason I document this as a requirement for bundling is that it
excludes certain uses of cryptography and more importantly, it
excludes encapsulation techniques.

> For the last sentence are you really meaning DTLS or DTLS-SRTP. There is

I may be misusing the terminology, but I believe that "DTLS-SRTP" is
"providing keying for SRTP using DTLS", whereas the phrase I used is
"encryption of RTP/RTCP via DTLS", which is what I intended.

> From: Christer Holmberg <[email-masked]>

> I am not sure I understand why this is bundle specific.

This requirement excludes techniques that use encapsulation, so it is
a significant constraint on acceptable bundling techniques.

Dale