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

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

On 21 Jun 2016, at 16:36, Alia Atlas wrote:

> This is useful clarification, but it still contains no hint that the
> receiver has agreed.  It doesn't
> alter the SHOULD or MUSTs associated with hiding this from receivers.
>
> I am looking for a balanced explanation - the motivations here give me 
> more
> than heartburn.
> It's clearly deciding for the content provider.

I'm slightly confused. Why does the receiver have an interest in how the 
content provider composes content?

This is not (or at least should not be) a case where A produces content, 
B messes with it, and C wanted to receive the originally, un-messed-with 
content. It's a case where A provides content that happens to have 
real-time insertions at a splicer operating on A's behalf, and C 
receives it. One assumes C has the right to go somewhere else for their 
content, or maybe request a different, non-spliced stream if A is 
willing to provide it. But otherwise, why does C an interest in how A 
composes the stream?

I suppose there's a possibility for this to be truly abused--but the 
notification comes in the media stream between the content provider and 
the splicer, not from a third party. Obviously there are security 
considerations to make sure that's really true, but that is true for any 
media stream.

(It's entirely possible, nay even likely, that I am missing something. 
Maybe even a whole use case that looks more like a MiTM?)

Thanks!

Ben.

>
> Regards,
> Alia
>
> On Tue, Jun 21, 2016 at 3:32 PM, Ben Campbell <[e-mail]> wrote:
>
>> 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/
>>>>>>
>>>>>
>>>>>