Re: [avtext] Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07: (with DISCUSS and COMMENT)

["Huangyihong (Rachel)" <[e-mail]>]

Hi Stephen,

Please see my replies inline. 

BR,
Rachel

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Thursday, June 16, 2016 7:11 PM
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Stephen Farrell's Discuss on draft-ietf-avtext-splicing-notification-07:
> (with DISCUSS and COMMENT)
> 
> Stephen Farrell 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:
> ----------------------------------------------------------------------
> 
> 
> (1) Section 7, 3rd para: Saying that "splicer works as a trusted entity" seems
> wrong - you need to say who trusts whom for what I think. I also don't get what
> you mean by saying there'll be a security association between the splicer and
> the receiver, nor how that might ever be possible if the splicer wants to hide
> what it's doing.  I think what you're after is some general statement that
> splicing breaks all security unless all the parties involved share the same
> security association. IIRC there is text like that in other RTP documents that
> might be copied but I forget the detail.

[Rachel]: Are you looking for such sentences?

OLD
"
   Since splicer works as a trusted entity, any RTP-level or outside
   security mechanism, such as 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.
"
NEW
"
Since the splicer breaks RTP-level end-to-end security, it need to be a trusted device that is part of the signaling context and get the necessary security associations (e.g., SRTP crypto contexts) established with its RTP session participants. 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.
"
> 
> (2) Section 7, 4th para: You say there is a case where header extension
> encryption SHOULD be used - how would that work? If there's a clear way to do
> it that'd get interop, then why is that not described? If there are ways in which
> might or might not work, or if some proprietary arrangements might be needed
> then how is it ok to have a SHOULD there? I suspect that the right thing here
> may be to not pretend that that can be done but to just stick with saying that
> splicing is inherently not going to work if you use any real security mechanisms,
> or something similar.

[Rachel]: Yes. I agree. So we should use "MUST" here.

OLD:
"
If there is a concern about the confidentiality of the splicing time information, header extension encryption [RFC6904] SHOULD be used.
"

NEW:

"
If there is a concern about the confidentiality of the splicing time information, header extension encryption [RFC6904] MUST be used.
"

> 
> (3) In discussion of RFC6828 there was some concern about possible creation of
> loops. I forget the issues though, but wanted to check this in case it also
> applies here.  (See 4.5 of
> 6828 maybe or the history for that RFC in the tracker.)
> 
> 

[Rachel]: Yes, you're right. How about adding a new paragraph in Section 7 to discuss loops?

"
When implementing undetectable splicing, CSRC list, which can be used to detect RTP-level forwarding loops as defined in Section 8.2 of [RFC3550], may be removed to prevent receivers from detecting the splicing occurrence. Hence, loops could occur to cause packets to loop back to upstream of the splicer and may form a serious denial-of-service threat. In such a case, non-RTP means MUST be used to detect and resolve loops if the splicer does not add a CSRC list when forwarding the RTP packet.
"

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> 
> - I agree with Alia's discuss, but suspect the ship has sailed.
> (Sadly IMO, but sailed nonetheless.)
> 
> - The security considerations here are similar to but not quite the same as
> those in RFC6828 which I think was the last time a similar document was
> before the IESG. I wondered if those differences were significant or not, it
> might be no harm to commpare the two (if that's not already been done) since
> they really ought be pretty much the same.
> 

[Rachel]: Not quite the same. This draft is about defining messages. And RFC6828 is one option scenario where these messages can be used. But people may use other models. But as suggested by Mirja, it's good to add some words to described what RFC 6828 is about.