[avtext] Proposed text for Alia and other AD's DISCUSS

["Huangyihong (Rachel)" <[e-mail]>]

Hi All,

Here's my proposal for addressing Alia's and other AD's similar DISCUSS. The main idea is to add a new subsection in Section 2, which is showed as following:

"
2.1 Overview of RTP Splicing

   RTP Splicing is to replace some multimedia content with certain
   substitutive multimedia content, and then forward it to the receivers
   for a period of time. This process is authorized by the service
   provider who sends the multimedia content to these receivers. A
   typical usage is that IPTV service providers use their own regional
   advertising content to replace national advertising content provided
   by the content providers.  

   The splicer is a middlebox handling RTP splicing. It receives main
   content and substitutive content simultaneously but only chooses to
   send one of them to the receiver at any point of time. When RTP
   splicing begins, the splicer sends the substitutive content to the
   receivers instead of the main content. When RTP splicing ends, the
   splicer switches back to sending the main content to the receivers.

   The middle box working as the splicer is either a translator or a
   mixer. [RFC6828] specifies a splicer implemented as a mixer that uses
   its own SSRC, sequence number space, and timing model when generating
   the output stream to receivers. The mixer must not insert the SSRC of
   the main RTP stream or the SSRC of the substitutive RTP stream into
   the contributing source (CSRC) list in the output media stream when
   implementing undetectable splicing. Since it works as the mixer, it
   splits the RTCP flow between the sender and receiver into two
   separate RTCP loops. This implies additional considerations should be
   taken into account when handling congestion control, see Section 4.4
   of [RFC6828]. 

   A translator [RFC3550] can also be a splicer by forwarding the RTP packets with
   their SSRCs intact, where the congestion control runs between
   original sender and receiver, or between substitutive sender and
   receiver. In such a case, the RTCP feedback message must be passed to
   the right sender to let the congestion control work. And undetectable
   splicing will not be fulfilled when the translator works as the
   splicer.
"

Besides that, a new terminology is defined in section 1.1 to define "Undetectable Splicing", see below:

"
Undetectable Splicing:

The RTP receivers are not able to detect any splicing points in the RTP layer. Sometimes, service providers may require an undetectable splicing to avoid the RTP receivers from filtering out the advertisement content.

"

Your further thoughts or comments are welcomed. We'll bring a new version as soon as consensus is achieved.

BR,
Rachel


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Monday, June 20, 2016 9:14 PM
> To: Mirja Kuehlewind (IETF)
> Cc: Colin Perkins; [e-mail];
> [e-mail]; [e-mail]; The IESG;
> [e-mail]
> Subject: Re: [avtext] Kathleen Moriarty's No Objection on
> draft-ietf-avtext-splicing-notification-07: (with COMMENT)
> 
> 
> 
> Sent from my iPhone
> 
> > On Jun 20, 2016, at 5:29 AM, Mirja Kuehlewind (IETF) <[e-mail]>
> wrote:
> >
> > Hi Colin,
> >
> > see below.
> >
> >>> Am 16.06.2016 um 00:34 schrieb Colin Perkins <[e-mail]>:
> >>>
> >>> On 15 Jun 2016, at 19:37, Kathleen Moriarty
> <[e-mail]> wrote:
> >>>
> >>> Kathleen Moriarty has entered the following ballot position for
> >>> draft-ietf-avtext-splicing-notification-07: No Objection
> >>>
> >>> When responding, please keep the subject line intact and reply to
> >>> all email addresses included in the To and CC lines. (Feel free to
> >>> cut this introductory paragraph, however.)
> >>>
> >>>
> >>> Please refer to
> >>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> >>> for more information about IESG DISCUSS and COMMENT positions.
> >>>
> >>>
> >>> The document, along with other ballot positions, can be found here:
> >>> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notifica
> >>> tion/
> >>>
> >>>
> >>>
> >>> --------------------------------------------------------------------
> >>> --
> >>> COMMENT:
> >>> --------------------------------------------------------------------
> >>> --
> >>>
> >>> I strongly support Mirja's and Alia's discuss points and would like
> >>> to see more of a discussion of the capability to hide splicing in
> >>> the security considerations text.  My ballot would be discuss, but
> >>> they pulled out the relevant sections and that would be duplication.
> >>> I'd like to review agreed upon text though to address these concerns.
> >>>
> >>> I don't like the idea of enabling a MiTM, but do see the draft talks
> >>> about how to protect headers when this happens and confidentiality
> >>> is needed as well as session protection between the endpoints and
> >>> the splicer (which I don't like either, but you do call out the
> >>> security considerations of this and that's what is needed).
> >>
> >> The mechanism described doesn’t work unless the receiver explicitly
> chooses to receive media content delivered via the splicer. I agree that the
> draft could be more clearly written, but it doesn’t seem to be “enabling a
> MiTM” attack, since the receiver opts in.
> >
> > This definitely need from clarification in the draft!
> 
> Yes, can we see some proposed text?
> 
> Thank you,
> Kathleen
> >
> > Mirja
> >
> >
> >>
> >> --
> >> Colin Perkins
> >> https://csperkins.org/
> >