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

From: "Roni Even" <[email-masked]>
Date: Fri, 6 May 2016 20:08:42 +0300

Hi Magnus,
I looked at your comments about the security section. Since the slicer is a RTP mixer or a RTP translator as specified in RFC 7667 I suggest adding informative reference to RFC7667 for the security risks. There is text that requires the splicer to authenticate the source of the splicing time message.
I propose the following text for the security section.

"The security considerations of the RTP specification [RFC3550] and the general mechanism for RTP header extensions [RFC5285] apply. The splicer can either be a mixer or a translator, and has all the security considerations on these two standard RTP intermediaries as such the security consideration from [RFC7667] and [RFC7201] SHOULD be considered for the splicer.

The splicer replaces some content with other content in RTP packet, thus breaking any RTP-level end-to-end security, such as source authentication and integrity protection. End to end source authentication is not possible with any known existing splicing solution. A new solution can theoretically be developed that enables identification of the participating entities and what each provides, i.e., the different media sources, main and substituting, and the splicer which provides the RTP-level integration of the media payloads in a common timeline and synchronization context.

 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.  

If there is a concern about the confidentiality of the splicing time information, header extension encryption [RFC6904] SHOULD be used.  However, a malicious endpoint may get the splicing time information by other means, e.g., inferring from the communication between the main and substitutive content sources. To avoid the insertion of invalid substitutive content, the splicer MUST have some mechanisms to authenticate the substitutive stream source.

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

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

Thanks
Roni

> -----Original Message-----
> From: avtext [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: Saturday, April 09, 2016 12:16 AM
> To: Huangyihong (Rachel); [email-masked]
> Subject: Re: [avtext] Fwd: New Version Notification for draft-ietf-avtext-
> splicing-notification-06.txt
> 
> 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]
> ----------------------------------------------------------------------
> 
> _______________________________________________
> avtext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avtext

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 May 2016 12:10:51 +0200

Hi,

I am very sorry for the long delay in responding to this.

Please see inline.

Den 2016-04-12 kl. 11:36, skrev Huangyihong (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. 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.
>
> [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.

Ok

>
>>
>> My other comment is that the Security consideration section still
>> has issues from my perspective:
>>
>> 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.
>>
>> 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?

So what I mean with hiding, is that the attacker injects a splicing 
indication for an interval that the main RTP sender does not intend to 
be spliced. Such an extra splicing injection can be used to hide content 
from the main sender so that the receiver(s) don't get to see this, and 
instead get the spliced content.

>
>> authentication need.
>
> [Rachel]: So how about the following changes?
>
> OLD " For cases that the splicing time information is changed by a
> available at the right time for the substitutive media to arrive,
> undetectable splicing. "
> NEW " For cases that the splicing time information is changed by a
> 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. "
>

Yes, I think this takes care of the first part. But I would really 
prefer if the text also can include a discussion of why authentication 
of splicing intervals are required from a point of maintaining control 
of the content actually forwarded to the receivers.

>>
>> , 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.
>
> [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. "
>

Okay, not really what I intended, but it works.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 16 May 2016 12:13:54 +0200

Hi,

See one issue inline. Sorry for the delay in responding.

Den 2016-05-06 kl. 19:08, skrev Roni Even:
> Hi Magnus, I looked at your comments about the security section.
> Since the slicer is a RTP mixer or a RTP translator as specified in
> RFC 7667 I suggest adding informative reference to RFC7667 for the
> security risks. There is text that requires the splicer to
> authenticate the source of the splicing time message. I propose the
> following text for the security section.
>
>
> "The security considerations of the RTP specification [RFC3550] and
> the general mechanism for RTP header extensions [RFC5285] apply. The
> splicer can either be a mixer or a translator, and has all the
> security considerations on these two standard RTP intermediaries as
> such the security consideration from [RFC7667] and [RFC7201] SHOULD
> be considered for the splicer.

The second sentence has very strange grammar. Please address.

/Magnus

>
> The splicer replaces some content with other content in RTP packet,
> thus breaking any RTP-level end-to-end security, such as source
> authentication and integrity protection. End to end source
> authentication is not possible with any known existing splicing
> solution. A new solution can theoretically be developed that enables
> identification of the participating entities and what each provides,
> i.e., the different media sources, main and substituting, and the
> splicer which provides the RTP-level integration of the media
> payloads in a common timeline and synchronization context.
>
> security mechanism, such IPsec [RFC4301] or Datagram Transport Layer
> If there is a concern about the confidentiality of the splicing time
> information, header extension encryption [RFC6904] SHOULD be used.
> However, a malicious endpoint may get the splicing time information
> by other means, e.g., inferring from the communication between the
> main and substitutive content sources. To avoid the insertion of
> invalid substitutive content, the splicer MUST have some mechanisms
> to authenticate the substitutive stream source.
>
> malicious endpoint, the splicing, for example, may fail since it will
> not be available at the right time for the substitutive media to
> arrive.
>
> A malicious endpoint may also break an undetectable splicing. To
> mitigate this effect, the splicer SHOULD NOT forward the splicing
> considering an undetectable splicing."
>
> Thanks Roni
>
>
>
>> -----Original Message----- From: avtext
>> [mailto:[email-masked]] On Behalf Of Magnus Westerlund
>> Sent: Saturday, April 09, 2016 12:16 AM To: Huangyihong (Rachel);
>> [email-masked] Subject: Re: [avtext] Fwd: New Version Notification
>> for draft-ietf-avtext- splicing-notification-06.txt
>>
>> requiring the 2- byte header extension header. So from my
>> right place to insert the authentication need.
>>
>> Färögatan 6                 | Mobile +46 73 0949079 SE-164 80
>> Stockholm, Sweden | mailto: [email-masked]
>> avtext mailing list [email-masked]

-- 

Magnus Westerlund

---

From: "Roni Even" <[email-masked]>
Date: Mon, 16 May 2016 14:26:21 +0300

Hi Magnus,
Sorry, I hope this is better

"The security considerations of the RTP specification [RFC3550] and the general mechanism for RTP header extensions [RFC5285] apply. The splicer can be either a mixer or a translator, and all the security considerations of these two RTP intermediaries topologies described in [RFC7667] and [RFC7201] are applicable for the splicer."

Roni

> From: Magnus Westerlund [mailto:[email-masked]]
> Sent: Monday, May 16, 2016 1:14 PM
> To: Roni Even; 'Huangyihong (Rachel)'; [email-masked]
> > such the security consideration from [RFC7667] and [RFC7201] SHOULD be
> > considered for the splicer.
> 
> > splicer which provides the RTP-level integration of the media payloads
> > in a common timeline and synchronization context.
> >
> > However, a malicious endpoint may get the splicing time information by
> > other means, e.g., inferring from the communication between the main
> > and substitutive content sources. To avoid the insertion of invalid
> > substitutive content, the splicer MUST have some mechanisms to
> > authenticate the substitutive stream source.
> >
> > For cases that the splicing time information is changed by a malicious
> > endpoint, the splicing, for example, may fail since it will not be
> > available at the right time for the substitutive media to arrive.
> >
> > mitigate this effect, the splicer SHOULD NOT forward the splicing time
> >> 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:
> >>
> >> 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.
> >>
> >> 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 authentication need.
> >>

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 17 May 2016 02:13:00 +0000

Hi Magnus,

Thank you for your replies. We'll modify the draft as soon as possible to address your comments. Please see inline. I remove the parts that don't need further discussion.

BR,
Rachel

> Sent: Monday, May 16, 2016 6:11 PM
> Subject: Re: [avtext] Fwd: New Version Notification for
> > 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?
> 
> So what I mean with hiding, is that the attacker injects a splicing indication for
> an interval that the main RTP sender does not intend to be spliced. Such an
> extra splicing injection can be used to hide content from the main sender so
> that the receiver(s) don't get to see this, and instead get the spliced content.
> 
> 

[Rachel]: Got it.

> > avoid it, authentication of the RTP header extension for splicing time
> > information SHOULD be considered. "
> >
> 
> Yes, I think this takes care of the first part. But I would really prefer if the text
> also can include a discussion of why authentication of splicing intervals are
> required from a point of maintaining control of the content actually forwarded
> to the receivers.
> 

[Rachel]: So does the following proposal clear your concern?

 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. Or, an attacker may 
 prevent the receivers receiving the content from the main sender by inserting additional splicing time
 information. To avoid such cases happening, authentication of the RTP header extension for splicing time
information SHOULD be considered.
"

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 24 May 2016 17:50:34 -0500

Hi,

In going back over the changes in version 7, I just noticed the addition 
of normative references to RFCs 7667 and 7201. Those are both 
informational RFCs. That doesn't mean we can't have a normative 
reference to them, but it would require re-running the IETF last call.

Before I do that, do people think that is the right thing to do? Are the 
normative references necessary? (If they were not normative, the 
security considerations wording around the citations would need to 
change.)

Thanks!

Ben.

On 16 May 2016, at 6:26, Roni Even wrote:

> splicer can be either a mixer or a translator, and all the security 
> considerations of these two RTP intermediaries topologies described in 
> [RFC7667] and [RFC7201] are applicable for the splicer."
>
> Roni
>
>
>>> payloads
>>> by
>>> malicious
>>> time
>>>> not
>>>> security
>>>> an
>>>> that
>>>> information

---

From: "Roni Even" <[email-masked]>
Date: Wed, 25 May 2016 09:02:28 +0300

Hi Ben,
I think that they can be informative references with the current text which does not have any normative language. The security considerations of RFC7667 do not mandate any security solution, that section mostly analyze the security issues with the different topologies
Roni

> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, May 25, 2016 1:51 AM
> To: Roni Even; [email-masked]
> Cc: Magnus Westerlund; Huangyihong; [email-masked]
> Subject: Re: [avtext] New Version Notification for draft-ietf-avtext-splicing-
> notification-06.txt
> 
> Hi,
> 
> In going back over the changes in version 7, I just noticed the addition of
> normative references to RFCs 7667 and 7201. Those are both informational
> RFCs. That doesn't mean we can't have a normative reference to them, but it
> would require re-running the IETF last call.
> 
> normative references necessary? (If they were not normative, the security
> considerations wording around the citations would need to
> change.)
> 
> Thanks!
> 
> Ben.
> 
> >>> malicious endpoint, the splicing, for example, may fail since it
> >>> will not be available at the right time for the substitutive media
> >>> to arrive.
> >>>
> >>>> header extension.
> >>>> Protocol (SRTP) [RFC3711], the splicer could be provisioned with
> >>>> the same security association as the main RTP sender.
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> --
> >>>> -
> >>>>
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> >> - Services, Media and Network features, Ericsson Research EAB/TXM

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 25 May 2016 01:18:12 -0500

Hi Roni,

It's not just a matter of normative language. Can the security 
considerations of this document be understood without reading the 
references?

Thanks,

Ben.

On 25 May 2016, at 1:02, Roni Even wrote:

> Hi Ben,
> I think that they can be informative references with the current text 
> which does not have any normative language. The security 
> considerations of RFC7667 do not mandate any security solution, that 
> section mostly analyze the security issues with the different 
> topologies
> Roni
>
>>>>> the
>>>>>> Layer

---

From: "Roni Even" <[email-masked]>
Date: Wed, 25 May 2016 16:15:46 +0300

Hi Ben,
It should be normative. BTW draft-ietf-rtcweb-rtp-usage-26 also has normative reference to RFC7667 (topologies-update)
Roni

> Sent: Wednesday, May 25, 2016 9:18 AM
> To: Roni Even
> Cc: [email-masked]; Magnus Westerlund;
> Huangyihong; [email-masked]
> It's not just a matter of normative language. Can the security considerations
> of this document be understood without reading the references?
> 
> Thanks,
> 
> Ben.
> 
> > topologies Roni
> >> In going back over the changes in version 7, I just noticed the
> >> addition of normative references to RFCs 7667 and 7201. Those are
> >> both informational RFCs. That doesn't mean we can't have a normative
> >> Before I do that, do people think that is the right thing to do? Are
> >> the normative references necessary? (If they were not normative, the
> >>> considerations of these two RTP intermediaries topologies described
> >>> in [RFC7667] and [RFC7201] are applicable for the splicer."
> >>>
> >>> Roni
> >>>
> >>>
> >>>>> Since the slicer is a RTP mixer or a RTP translator as specified
> >>>>> in RFC 7667 I suggest adding informative reference to RFC7667 for
> >>>>> the security risks. There is text that requires the splicer to
> >>>>> authenticate the source of the splicing time message. I propose
> >>>>> the following text for the security section.
> >>>>>
> >>>>>
> >>>>> "The security considerations of the RTP specification [RFC3550]
> >>>>> and the general mechanism for RTP header extensions [RFC5285]
> >>>>> apply.
> >>>>> The
> >>>>> security considerations on these two standard RTP intermediaries
> >>>>> as such the security consideration from [RFC7667] and [RFC7201]
> >>>>> SHOULD be considered for the splicer.
> >>>>
> >>>>> The splicer replaces some content with other content in RTP
> >>>>> packet, thus breaking any RTP-level end-to-end security, such as
> >>>>> source authentication and integrity protection. End to end source
> >>>>> solution. A new solution can theoretically be developed that
> >>>>> enables identification of the participating entities and what each
> >>>>> provides, i.e., the different media sources, main and
> >>>>> substituting, and the splicer which provides the RTP-level
> >>>>> integration of the media payloads in a common timeline and
> >>>>> synchronization context.
> >>>>>
> >>>>> security mechanism, such IPsec [RFC4301] or Datagram Transport
> >>>>> If there is a concern about the confidentiality of the splicing
> >>>>> time information, header extension encryption [RFC6904] SHOULD be
> >>>>> used.
> >>>>> However, a malicious endpoint may get the splicing time
> >>>>> information by other means, e.g., inferring from the communication
> >>>>> between the main and substitutive content sources. To avoid the
> >>>>> insertion of invalid substitutive content, the splicer MUST have
> >>>>> some mechanisms to authenticate the substitutive stream source.
> >>>>>
> >>>>> time information RTP header extension defined in Section 4.1 to
> >>>>> the receivers. And it MUST NOT forward this header extension when
> >>>>>> [email-masked] Subject: Re: [avtext] Fwd: New Version
> >>>>>> Notification for draft-ietf-avtext- splicing-notification-06.txt
> >>>>>>
> >>>>>> 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.
> >>>>>> 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.
> >>>>>>
> >>>>>> 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.
> >>>>>>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 25 May 2016 10:40:05 -0500

On 25 May 2016, at 8:15, Roni Even wrote:

> It should be normative.

> BTW draft-ietf-rtcweb-rtp-usage-26 also has normative reference to 
> RFC7667 (topologies-update)

I think you are right, unless we want to recreate a good bit of the 
referenced language in this draft.

I'm going to start another IETF LC on this draft. I think we can get by 
with a shortened last call (1 week.) Then, if there are no objections, I 
will add one or both of them to the approved downref registry so we can 
remove some of the red tape for future drafts that need to reference 
these.

Thanks!

Ben.

>> considerations
>>>>> and