Subject: [avtext] Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS)

From: "Alia Atlas" <[email-masked]>
Date: Tue, 14 Jun 2016 14:59:32 -0700

Alia Atlas has entered the following ballot position for
draft-ietf-avtext-splicing-notification-07: Discuss

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-notification/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I believe this is more  a discussion for the IESG.

First, this is way out of my area and I'm not particularly commenting on
the details - but 
I do agree with Mirja's discuss about
"- The following action does not seem to be appropriate for a
specification of an end-to-end protocol:
"And if the splicer wishes to prevent the downstream receivers from
detecting splicing, it MUST
   NOT forward the message.""

The full paragraph at the end of Sec 3.2 is: "When the splicer intercepts
the RTCP splicing notification message,
   it SHOULD NOT forward the message to the down-stream receivers in
   order to reduce RTCP bandwidth consumption. And if the splicer wishes
   to prevent the downstream receivers from detecting splicing, it MUST
   NOT forward the message."

Even more specifically to me, superficially this seems to me to be a way
to change what is in the
stream that a receiver has requested or subscribed to without permission
or notification.   In that light,
the idea that the splicer is able to prevent downstream receivers from
detecting the splicing does
not sound good.

Similarly, the end of Sec 3.1 says "After the splicer intercepts the RTP
header extension and derives the
   Splicing Interval, it will generate its own stream and SHOULD NOT
   include the RTP header extension in outgoing packets to reduce header
   overhead."

This looks like another example of making the choice to hide information
from the receiver.

I realize that there is probably an technical arms-race going on - of
inserting advertisements and
building receivers to block undesired advertisements.  I am  not seeing a
balanced solution that
considers the receivers as well as the senders.

I am startled that there is no consideration of the impact of this
extension on the receivers 
in the security considerations.

The only reference I see in the Security Considerations further assumes
that it is appropriate to have an undetectable splicing.

" A malicious endpoint may also break an undetectable splicing. To
   mitigate this effect, the splicer SHOULD NOT forward the splicing
   time information RTP header extension defined in Section 4.1 to the
   receivers. And it MUST NOT forward this header extension when
   considering an undetectable splicing. "

At a minimum, I feel like there should be a very clear consideration of
the
pros and cons - including from the viewpoint of a receiver. 

If we end up with this biased technology, then it should be clearly
stated
- not hidden in assumptions.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 15 Jun 2016 20:15:47 +0000

Hi Alia,

Thank you for raising the concerns. Please see my replies inline.

Rachel, as one of the author.

-----邮件原件-----
发件人: Alia Atlas [mailto:[email-masked]] 
发送时间: 2016年6月15日 6:00
收件人: The IESG
抄送: [email-masked]; [email-masked]; [email-masked]; [email-masked]
主题: Alia Atlas' Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS)

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

First, this is way out of my area and I'm not particularly commenting on the details - but I do agree with Mirja's discuss about
"- The following action does not seem to be appropriate for a specification of an end-to-end protocol:
"And if the splicer wishes to prevent the downstream receivers from detecting splicing, it MUST
   NOT forward the message.""

[Rachel]: This is not a end-to-end protocol. These extended messages are intended to send to the splicer, which is the middle box expected to be able to modify RTCP messages. Discarding or modifying RTCP packets that don’t make sense for some participants is normal behaviour for RTP middle boxes. I understand the mormative language is kind of confusing here. We'll remove the normative language.

The full paragraph at the end of Sec 3.2 is: "When the splicer intercepts the RTCP splicing notification message,

Even more specifically to me, superficially this seems to me to be a way to change what is in the stream that a receiver has requested or subscribed to without permission
or notification.   In that light,
the idea that the splicer is able to prevent downstream receivers from detecting the splicing does not sound good.

[Rachel]: As I said, this message is supposed to send to the splicer, not the receivers of the end user. When the splicer receives such messages, it'll do the splicing activity, which is to use the substitutive content replace the original content. When splicing interval ends, the splicer will change it back. It's usually used for advertisement insertion.  I do find the word "intercepts" here is improper and confusing. How about using "receives"?

Similarly, the end of Sec 3.1 says "After the splicer intercepts the RTP header extension and derives the
   Splicing Interval, it will generate its own stream and SHOULD NOT
   include the RTP header extension in outgoing packets to reduce header
   overhead."

This looks like another example of making the choice to hide information from the receiver.

[Rachel]: Please see above.

I realize that there is probably an technical arms-race going on - of inserting advertisements and building receivers to block undesired advertisements.  I am  not seeing a balanced solution that considers the receivers as well as the senders.

[Rachel]: On the contrary, it's a method used in IPTV services, that service provider inserts different advertisements to different users. It's totally not blocking or hiding something. Sometime the service provider don't want the end users to detect the advertisement inserting. That's why the splicing interval are not forwarded to the receivers.

I am startled that there is no consideration of the impact of this extension on the receivers in the security considerations.

The only reference I see in the Security Considerations further assumes that it is appropriate to have an undetectable splicing.

At a minimum, I feel like there should be a very clear consideration of the pros and cons - including from the viewpoint of a receiver. 

If we end up with this biased technology, then it should be clearly stated
- not hidden in assumptions.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 15 Jun 2016 16:17:26 -0700

A couple of thoughts here:

- RTP middleboxes do all kinds of things to cleartext media that they receive. Of course people have realized the security drawbacks of this, which is why we have developed security technologies designed to prevent media manipulation and why we have other WGs working on extending that model to conferencing and defining best practices for how to secure media end-to-end.

- I agree that the MUST NOT forward language is ill-advised, and it’s also unnecessary. But even if this document said MUST forward, there is nothing in the protocol semantics that would require implementations to do that, so I imagine that splicers that do not want to forward this information (whether to prevent detection or to reduce overhead) won’t forward it. Similarly, I would imagine that at least some of the payload-specific mechanisms used for this purpose have the same property, so even if systems rely on those mechanisms rather than RTP because the RTP spec says MUST forward, there is no guarantee that the splicing information will reach the receiver.

Alissa

> On Jun 14, 2016, at 2:59 PM, Alia Atlas <[email-masked]> wrote:
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 20 Jun 2016 11:28:12 +0200

Hi,

> Am 16.06.2016 um 01:17 schrieb Alissa Cooper <[email-masked]>:
> 

I still support Alia’s discuss here, because even if we can’t change what people/splicers do, we should not write should an ill-advise in an RFC!

Mirja