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

["Ben Campbell" <[e-mail]>]

Hi, some comments inline:

On 21 Jun 2016, at 7:58, Huangyihong (Rachel) wrote:

> 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.

I think this could be strengthened a bit. IIUC, this mechanism assumes 
the splicing interval is sent _by_ the main content provider. That is, 
this mechanism only works with the permission of the content provider. 
If they don't consent, they simply won't send the splicing interval.

This relationship might be more clear if the example talked about the 
main content provider offering a time window for the regional 
advertising insert, rather than about replacing national advertising. 
While that might in fact replace national content, it should be clear 
that the main provider _intends_ for the insert to happen.

>
>    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.

I suggest promoting that last sentence a bit, and removing any hint of 
2119 language. For example:

"The splicer, operating on behalf of the content provider, may not wish 
to reveal that splicing has occurred. In this case, the splicer does not 
insert the SSRCs from either the main or substitutive RTP streams into 
the CSRC list in the resulting output media stream.."

> 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.

That particular motivation gives me a bit of heartburn. But I think the 
reality is that the content provider wants to provide an apparently 
continuous stream, and they don't think the the splicing details are the 
business of the recipient (any more than the splices that occur in the 
original media stream incident to the normal editing of the 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/
>>>