Subject: [avtext] Fwd: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 6 Apr 2016 18:38:48 +0000

Hi,

This new version addresses Magnus's comment of using an agnostic format. That's the only change made in this version.

BR,
Rachel

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 
发送时间: 2016年4月7日 2:34
收件人: Deng Lingli; Roni Even; Xiajinwei; Huangyihong (Rachel); Lingli Deng
主题: New Version Notification for draft-ietf-avtext-splicing-notification-06.txt

A new version of I-D, draft-ietf-avtext-splicing-notification-06.txt
has been successfully submitted by Rachel Huang and posted to the IETF repository.

Name:		draft-ietf-avtext-splicing-notification
Revision:	06
Title:		RTP/RTCP extension for RTP Splicing Notification
Document date:	2016-04-06
Group:		avtext
Pages:		19
URL:            https://www.ietf.org/internet-drafts/draft-ietf-avtext-splicing-notification-06.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/
Htmlized:       https://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-06
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-06

Abstract:
   Content splicing is a process that replaces the content of a main
   multimedia stream with other multimedia content, and delivers the
   substitutive multimedia content to the receivers for a period of
   time. The splicer is designed to handle RTP splicing and needs to
   know when to start and end the splicing.

   This memo defines two RTP/RTCP extensions to indicate the splicing
   related information to the splicer: an RTP header extension that
   conveys the information in-band and an RTCP packet that conveys the
   information out-of-band.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 8 Apr 2016 18:16:07 -0300

Den 2016-04-06 kl. 15:38, skrev Huangyihong (Rachel):
> Hi,
>
> This new version addresses Magnus's comment of using an agnostic
> format. That's the only change made in this version.

Hi,

So I have reviewed all the changes from the -04 to this -06 version.

First, I think people should be aware that the latest change do change 
the data format of the splicing header extension. This was not my 
intention, but I also don't care about. Just that people should be aware 
of this. I understand this is to enable the 2-bytes format to align with 
the 32-byte boundaries when it is the sole header extension present. 
However, I would note that this is a unnecessary alignment most likely. 
This header extension, even when using 7-byte splicing out timestamps do 
fit within the 1-byte header extension. Thus, in most cases the sole 
reason for using the 2-byte header extension would be in cases where 
this header extension is included together with another header extension 
requiring the 2-byte header extension header. So from my perspective, 
the old 7-byte header extension could be used with both the 1 and 2-byte 
headers.

My other comment is that the Security consideration section still has 
issues from my perspective:

    Since splicer works as a trusted entity, any RTP-level or outside
    security mechanism, such IPsec[RFC4301] or Datagram Transport Layer
    Security [RFC6347], will use a security association between the
    splicer and the receiver. When using the Secure Real-Time Transport
    Protocol (SRTP) [RFC3711], the splicer could be provisioned with the
    same security association as the main RTP sender.

So the alternatives when SRTP is to protect the content from the Splicer 
to the Receiver, then the splicer either has its own security context on 
the splicer to receiver leg, or it has as indicated access to the 
security context from main RTP sender.

Then the following paragraph seem to lack a requirement for 
authenticating the actual splicing notification, i.e. the whole RTP 
packet that it is included in. The text appear to discuss both the 
substitute RTP stream and if the notification is modified, but not an 
authentication requirement to avoid this.

    For cases that the splicing time information is changed by a
    malicious endpoint, the splicing may fail since it will not be
    available at the right time for the substitutive media to arrive

That is not the only issue, it can also be used to hide content that the 
main RTP sender intended to recieve. I think here is the right place to 
insert the authentication need.

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

The undetectable part is a separate issue, please write it as separate 
sentences.

Thanks for addressing the other issues.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 12 Apr 2016 09:36:06 +0000

Hi Magnus,

Inline please.

BR,
Rachel

> -----Original Message-----
> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Saturday, April 09, 2016 5:16 AM
> To: Huangyihong (Rachel); [email-masked]
> Subject: Re: [avtext] Fwd: New Version Notification for
> draft-ietf-avtext-splicing-notification-06.txt
> 
> First, I think people should be aware that the latest change do change the data
> format of the splicing header extension. This was not my intention, but I also
> don't care about. Just that people should be aware of this. I understand this is
> to enable the 2-bytes format to align with the 32-byte boundaries when it is the
> sole header extension present.
> This header extension, even when using 7-byte splicing out timestamps do fit
> within the 1-byte header extension. Thus, in most cases the sole reason for
> using the 2-byte header extension would be in cases where this header
> extension is included together with another header extension requiring the
> 2-byte header extension header. So from my perspective, the old 7-byte header
> extension could be used with both the 1 and 2-byte headers.

[Rachel]: Yes, I agree. Both 7-byte and 6-byte extension are applicable in this case. The only difference is alignment and bit saving. So if you think that there's no need to have such consideration, I'll change it to old 7-byte.

> 
> My other comment is that the Security consideration section still has issues
> from my perspective:
> 
> So the alternatives when SRTP is to protect the content from the Splicer to the
> Receiver, then the splicer either has its own security context on the splicer to
> receiver leg, or it has as indicated access to the security context from main RTP
> sender.
> 
> Then the following paragraph seem to lack a requirement for authenticating
> the actual splicing notification, i.e. the whole RTP packet that it is included in.
> The text appear to discuss both the substitute RTP stream and if the
> notification is modified, but not an authentication requirement to avoid this.
> 
> That is not the only issue, it can also be used to hide content that the main RTP
> sender intended to recieve. I think here is the right place to insert the

[Rachel]: What do you mean by hiding content that the main RTP sender intended to receive? I can see that it only hides the content that the substitutive sender wants to send to the receivers, but the main RTP sender...? What do I miss?

> authentication need.

[Rachel]: So how about the following changes?

OLD
"
   available at the right time for the substitutive media to arrive,
"

NEW
"
   For cases that the splicing time information is changed by a
   malicious endpoint, the splicing may fail since it will not be
   available at the right time for the substitutive media to arrive. To avoid it,
 authentication of the RTP header extension for splicing time information SHOULD be considered.
"

> The undetectable part is a separate issue, please write it as separate

[Rachel]: Okay, then a new paragraph can be added in the end. How about that?

"
   When splicing fails, 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 the header extension when considering an
   undetectable splicing.
"