Subject: Re: [avtext] WGLC for draft-ietf-avtext-splicing-notification-01

From: Bo Burman <[email-masked]>
Date: Fri, 17 Apr 2015 13:33:21 +0000

I have reviewed this draft, and I think that it addresses all of my previous concerns.

I have the following, additional comments to section 6:

1) Is the intent that the main RTP stream in the SPLICE group is always the one with the splicing-interval extmap attribute, and the substitutive RTP is the other one? If so, I think being explicit about that could be helpful. You have marked that with an i= line in the example, but do not require it formally, and I also think you cannot require a parser to rely on i= information to choose which is which.

2) I think it may be helpful to say that can there MUST NOT be more than two m-lines in a single SPLICE group. If there would be more, you obviously cannot know which RTP m-line to splice in at the splice point.

3) I think it may be helpful to say that a single m-line MUST NOT be part of more than a single SPLICE group.

4) s/FID/SPLICE/

5) In 6.3, SDP offer, should the substitutive video be sendonly, or is it intentionally sendrecv? It is sendrecv also in the SDP answer, so if it is intentional, it is formally OK between offer and answer.

6) In 6.3, SDP answer, the substitutive audio is marked as sendonly, but should be recvonly to match the offer.

7) Editorial nits:
Near the end of section 2: s/sllowing/allowing/
Near beginning of section 6: s/This document extended/ This document extends/

Cheers,
Bo

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Jonathan Lennox
> Sent: den 31 mars 2015 16:27
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [avtext] WGLC for draft-ietf-avtext-splicing-notification-01
> 
> This is to announce a 3 week Working Group Last Call for
> 
> 	draft-ietf-avtext-splicing-notification-01
> 
> as proposed standard.
> 
> Please review and provide any comments you may have on the document by Tuesday, April 21, 2015. Comments should
> be sent to the document authors and the AVTEXT WG list. If you review the document but do not have any comments,
> please send a note to that effect as well.
> 
> Please also forward this WGLC call to any other interested parties who may be able to review the draft, asking them to
> also direct their comments to the authors and the list as above.
> 
> Thank you!
> 
>          Jonathan (AVTEXT co-chair)
> 
> 
> Draft information:
> 
>   This draft is a work item of the Audio/Video Transport Extensions Working Group of the IETF.
> 
>        Title           : RTP/RTCP extension for RTP Splicing Notification
>        Authors         : Jinwei Xia
>                          Roni Even
>                          Rachel Huang
>                          Lingli Deng
> 	Filename        : draft-ietf-avtext-splicing-notification-01.txt
> 	Pages           : 17
> 	Date            : 2014-12-10
> 
> 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.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-avtext-splicing-notification/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-avtext-splicing-notification-01
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtext-splicing-notification-01
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Colin Perkins <[email-masked]>
Date: Sat, 18 Apr 2015 11:17:54 +0100

I've also reviewed this. I had similar comments to Bo around use of the grouping framework, signalling what is the main and which is the substitutive stream, and behaviour when there are more than two streams in the splicing group.

I also noticed that Section 3.2, last paragraph, says "MAY NOT", which is not an RFC 2119 keyword. Is this intended to be MUST NOT, SHOULD NOT, or something else entirely?

Colin

-- 
Colin Perkins
https://csperkins.org/

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 21 Apr 2015 02:06:06 +0000

Dear Bo,

Many thanks to you for your careful reviewing and valuable comments. Please see my reply inline.

BR,
Rachel

> From: avtext [mailto:[email-masked]] On Behalf Of Bo Burman
> Sent: Friday, April 17, 2015 9:33 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [avtext] WGLC for draft-ietf-avtext-splicing-notification-01
> 
> 1) Is the intent that the main RTP stream in the SPLICE group is always the one
> with the splicing-interval extmap attribute, and the substitutive RTP is the
> other one? If so, I think being explicit about that could be helpful. You have
> marked that with an i= line in the example, but do not require it formally, and I
> also think you cannot require a parser to rely on i= information to choose which
> is which.

[Rachel]: Totally agree. We'll clarify it in the next version. The main stream is the one with the splicing-interval extmap attribute.

> 
> 2) I think it may be helpful to say that can there MUST NOT be more than two
> m-lines in a single SPLICE group. If there would be more, you obviously cannot
> know which RTP m-line to splice in at the splice point.

[Rachel]: Yes. Only 2 m-lines are allowed in a SPLICE group.

> than a single SPLICE group.

[Rachel]: Exactly. We'll clarify it in the next version.

> 4) s/FID/SPLICE/

[Rachel]: Ok.

> 
> 5) In 6.3, SDP offer, should the substitutive video be sendonly, or is it
> intentionally sendrecv? It is sendrecv also in the SDP answer, so if it is
> intentional, it is formally OK between offer and answer.

[Rachel]: It should be sendonly.

> be recvonly to match the offer.

[Rachel]: Yes. You're right. Will fix it.

> 
> 7) Editorial nits:
> Near the end of section 2: s/sllowing/allowing/ Near beginning of section 6:
> s/This document extended/ This document extends/

[Rachel]: Okay. Thanks.

> > Cc: [email-masked];
> > [email-masked]
> > Please review and provide any comments you may have on the document by
> > Tuesday, April 21, 2015. Comments should be sent to the document
> > authors and the AVTEXT WG list. If you review the document but do not have
> any comments, please send a note to that effect as well.
> >
> > Please also forward this WGLC call to any other interested parties who
> > may be able to review the draft, asking them to also direct their comments to
> the authors and the list as above.
> >
> > Thank you!
> >
> > 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.
> >

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 21 Apr 2015 02:11:24 +0000

Hi Colin,

Thank you for the comments. Please see inline.

BR,
Rachel

> From: avtext [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Saturday, April 18, 2015 6:18 PM
> To: Bo Burman
> Cc: [email-masked]; [email-masked]
> I've also reviewed this. I had similar comments to Bo around use of the
> grouping framework, signalling what is the main and which is the substitutive
> stream, and behaviour when there are more than two streams in the splicing
> group.

[Rachel]: The main stream is implied by the a=extmap:1 urn:ietf:params:rtp-hdrext:splicing-interval. And only two streams are allowed in the splicing group. We'll add some texts to clarify it.

> 
> I also noticed that Section 3.2, last paragraph, says "MAY NOT", which is not an
> RFC 2119 keyword. Is this intended to be MUST NOT, SHOULD NOT, or
> something else entirely?

[Rachel]: Will change it to "SHOULD NOT".

> > 1) Is the intent that the main RTP stream in the SPLICE group is always the
> one with the splicing-interval extmap attribute, and the substitutive RTP is the
> > Near the end of section 2: s/sllowing/allowing/ Near beginning of
> > section 6: s/This document extended/ This document extends/
> >
> > Cheers,
> > Bo
> >
> >> Please review and provide any comments you may have on the document
> >> by Tuesday, April 21, 2015. Comments should be sent to the document
> >> Please also forward this WGLC call to any other interested parties
> >> who may be able to review the draft, asking them to also direct their
> comments to the authors and the list as above.
> >>
> >> Thank you!
> >>

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 21 Apr 2015 16:51:41 +0000

Commenting as an individual.

Substantive:

I don’t think the security consideration in the second paragraph of Section 7 makes sense.  A malicious endpoint that possesses the SRTP key can insert false values for the header extension whether or not the header extensions are encrypted.

To determine whether RTP Header Encryption needs to be used, we need to know whether there are cases where the splicing notification information needs to be kept confidential from an endpoint that can see the encrypted main content, but does not possess the SRTP keys.  I don’t see this as particularly compelling.  The only exposure I see is that not encrypting the header extensions allows an untrusted observer to break an attempt at undetectable splicing, but I think there are lots of other ways someone who could see the pre-spliced media could work out when splicing happened, even when the media is encrypted.

That said, I think it’s important to note somewhere that the splicer should not forward the splicing notification information on the (spliced) output stream.  It MUST NOT forward it if it's trying to do undetectable splicing (since it breaks it); otherwise, it’s just mostly useless, unless you’re expecting that someone downstream of you might want to splice a second time.

Editorial:

Section 2:

	According to RTP Splicing draft [RFC6828],

RFC 6828 is a published RFC, and therefore not a draft.

	In this document, the main RTP sender uses a couple of NTP-format timestamps

“Couple” is a less formal word than would normally be used in a standards document; additionally, in some dialects of English it means “an unspecified small number,” rather than precisely “two”.  I suggest either using “a pair of”, or just “two”.  (Occurs multiple places in the document.)

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 22 Apr 2015 10:43:57 +0000

Hi Jonathan,

Thanks for the comments. Please see inline.

BR,
Rachel

> Sent: Wednesday, April 22, 2015 12:52 AM
> To: [email-masked]
> I don’t think the security consideration in the second paragraph of Section 7
> makes sense.  A malicious endpoint that possesses the SRTP key can insert
> false values for the header extension whether or not the header extensions are
> encrypted.

[Rachel]: Yes. I think it's a mistake here. It should be "A malicious endpoint that does not possessed the SRTP key could set the values in the header extension falsely to falsely claim the splicing time."
> 
> To determine whether RTP Header Encryption needs to be used, we need to
> know whether there are cases where the splicing notification information
> needs to be kept confidential from an endpoint that can see the encrypted main
> content, but does not possess the SRTP keys.  I don’t see this as particularly
> compelling.  The only exposure I see is that not encrypting the header
> extensions allows an untrusted observer to break an attempt at undetectable
> splicing, but I think there are lots of other ways someone who could see the
> pre-spliced media could work out when splicing happened, even when the
> media is encrypted.

[Rachel]: So how about changing the 2nd and 3rd paragraph from

"  The RTP header extension defined in Section 4.1 include two NTP-
   format timestamps.  In the Secure Real-time Transport Protocol
   (SRTP)[RFC3711], RTP header extensions are authenticated but not
   encrypted.  A malicious endpoint possessing the SRTP key could choose
   to set the values in this header extension falsely, so as to falsely
   claim the splicing time. Also, such a malicious endpoint could cause
   any arbitrary content it wishes spliced into the main RTP stream. 

   In scenarios where this is a concern, additional mechanisms MUST be
   used to protect the confidentiality of the header extension.  This 
   mechanism could be header extension encryption [SRTP-ENCR-HDR], or a
   lower-level security and authentication mechanism such as IPsec
   [RFC4301]."

to

"
   The RTP header extension defined in Section 4.1 include two NTP-
   format timestamps. In the Secure Real-time Transport Protocol
   (SRTP)[RFC3711], RTP header extensions are authenticated but not
   encrypted. A malicious endpoint that does not possessed the SRTP key
   could set the values in the header extension falsely to falsely claim the 
   splicing time, which breaks an attempt at undetectable splicing. In such
   a case, RTP header extension encryption [RFC6904] could be used
   to protect the confidentiality of the header extension."

And what do you mean by " but I think there are lots of other ways someone who could see the
pre-spliced media could work out when splicing happened, even when the media is encrypted "?

> 
> That said, I think it’s important to note somewhere that the splicer should not
> forward the splicing notification information on the (spliced) output stream.  It
> MUST NOT forward it if it's trying to do undetectable splicing (since it breaks it);
> otherwise, it’s just mostly useless, unless you’re expecting that someone
> downstream of you might want to splice a second time.

[Rachel]: It has been mentioned in Section 3, last paragraph, as following:

"
   When the mixer intercepts the RTCP splicing notification message, it
   MAY NOT forward the message to the receivers in order to reduce RTCP
   bandwidth consumption or to avoid downstream receivers from detecting
   splicing defined in Section 4.5 in [RFC6828].
"
How about changing it to 

"  When the mixer intercepts the RTCP splicing notification message, it
   SHOULD NOT forward the message to the receivers in order to reduce RTCP
   bandwidth consumption. And it MUST NOT forward the message to the receivers
   for an undetectable splicing implementation as described in Section 4.5 of [RFC6828].
"

> RFC 6828 is a published RFC, and therefore not a draft.

[Rachel]: Right. Good catch.
> “Couple” is a less formal word than would normally be used in a standards
> document; additionally, in some dialects of English it means “an unspecified
> small number,” rather than precisely “two”.  I suggest either using “a pair
> of”, or just “two”.  (Occurs multiple places in the document.)

[Rachel]: Will change it to "pair"

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 22 Apr 2015 15:26:49 +0000

> On Apr 22, 2015, at 6:43 AM, Huangyihong (Rachel) <[email-masked]> wrote:
> 
> Hi Jonathan,
> 

Replies inline as well; some content trimmed.

> [Rachel]: Yes. I think it's a mistake here. It should be "A malicious endpoint that does not possessed the SRTP key could set the values in the header extension falsely to falsely claim the splicing time.”

No, it couldn’t.  Even though header extensions are sent unencrypted by default in SRTP, they’re still authenticated (as is the base RTP header).  So someone who doesn’t have the key can’t forge header extensions — all they can do is observe them, if they can somehow see the encrypted pre-spliced media.

I’m trying to decide if that’s a threat or not.  I’m inclined to think it isn’t.

>   to protect the confidentiality of the header extension.”

No, see above.

> pre-spliced media could work out when splicing happened, even when the media is encrypted “?

This was by way of discussion of the question of whether the splicing information being visible was a threat or not.

>   for an undetectable splicing implementation as described in Section 4.5 of [RFC6828].

We should say this for the header extension as well as for the RTCP, yes?

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 24 Apr 2015 02:07:33 +0000

Hi Jonathan,

Okay, now I get it.

When SRTP is used, following concerns exist:
  1. For a malicious endpoint without the key, it can observe the splicing time in the RTP header, and can insert any different substitutive content.
  2. For a malicious endpoint having the key, it can change the splicing time to cause a splicing failure, since it will not be available at the right time for the substitutive content to arrive.
  3. For a malicious endpoint having the key, it can also insert some different substitutive content.
  4. For case 1, RTP header extension encryption can be used. However, the malicious endpoint can get the splicing time information by observing the RTP timestamp of the substitutive stream.

So here are the proposed changes:
For 2rd paragraph, how about changing from 
"
   The RTP header extension defined in Section 4.1 include two NTP-
   format timestamps.  In the Secure Real-time Transport Protocol
   (SRTP)[RFC3711], RTP header extensions are authenticated but not
   encrypted.  A malicious endpoint possessing the SRTP key could choose
    to set the values in this header extension falsely, so as to falsely
    claim the splicing time. Also, such a malicious endpoint could cause
   any arbitrary content it wishes spliced into the main RTP stream.
"
To

"
   The RTP header extension defined in Section 4.1 include two NTP-
   format timestamps.  In the Secure Real-time Transport Protocol
   (SRTP)[RFC3711], RTP header extensions are authenticated but not
   encrypted. For a malicious endpoint without the key, it can observe 
   the splicing time in the RTP header, and can insert any different substitutive
   content. For a malicious endpoint having the key, it can change the splicing time
   to cause a splicing failure, or insert some different substitutive content.
"
And changing the 3rd paragraph from
"
    In scenarios where this is a concern, additional mechanisms MUST be
    used to protect the confidentiality of the header extension.  This 
    mechanism could be header extension encryption [SRTP-ENCR-HDR], or a
    lower-level security and authentication mechanism such as IPsec
    [RFC4301]."
"
To
"
 If there is a concern about the confidentiality of the splicing time information, 
 header extension encryption SHOULD be used. However, the malicious endpoint 
 can get the splicing time information by other means, e.g., observing the RTP timestamp 
 of the substitutive stream. To protect from different substitutive contents are inserted, 
 the splicer MUST have some mechanisms to authenticate the substitutive stream source.
"

And adding a new paragraph to address the splicing failure:

"
 For cases that splicing time information is changes by a malicious endpoint, the splicing may
 fail since it will not be available at the right time for the substitutive media to arrive, 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 extension when considering an undetectable splicing.
"

What do you think?

BR,
Rachel

-----邮件原件-----
发件人: Jonathan Lennox [mailto:[email-masked]] 
发送时间: 2015年4月22日 23:27
收件人: Huangyihong (Rachel)
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: WGLC for draft-ietf-avtext-splicing-notification-01

>> Subject: Re: [avtext] WGLC for 
>> I don’t think the security consideration in the second paragraph of 
>> Section 7 makes sense.  A malicious endpoint that possesses the SRTP 
>> key can insert false values for the header extension whether or not 
>> the header extensions are encrypted.
> 

>> To determine whether RTP Header Encryption needs to be used, we need 
>> to know whether there are cases where the splicing notification 
>> information needs to be kept confidential from an endpoint that can 
>> see the encrypted main content, but does not possess the SRTP keys.  
>> I don’t see this as particularly compelling.  The only exposure I see 
>> is that not encrypting the header extensions allows an untrusted 
>> observer to break an attempt at undetectable splicing, but I think 
>> there are lots of other ways someone who could see the pre-spliced 
>> media could work out when splicing happened, even when the media is encrypted.
> 

No, see above.

> And what do you mean by " but I think there are lots of other ways 
> someone who could see the pre-spliced media could work out when splicing happened, even when the media is encrypted “?

>> That said, I think it’s important to note somewhere that the splicer 
>> should not forward the splicing notification information on the 
>> (spliced) output stream.  It MUST NOT forward it if it's trying to do 
>> undetectable splicing (since it breaks it); otherwise, it’s just 
>> mostly useless, unless you’re expecting that someone downstream of you might want to splice a second time.
>