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

[Stephen Farrell <[e-mail]>]

Hiya,

On 20/06/16 11:42, Huangyihong (Rachel) wrote:
> 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. "

That's better yes, but I'd still recommend not saying "trusted
device" at all since that calls into question who is trusting it
for what and in this case the ultimate receiver doesn't usually
know the splicer is there at all and hence cannot trust it in
any meaningful sense. So I'd suggest:

NEW:

"
Since the splicer breaks RTP-level end-to-end security, it needs to
be part of the signaling context and be a part of the
necessary security associations (e.g., SRTP crypto contexts)
established for the RTP session participants. When using the Secure
Real-Time Transport Protocol (SRTP) [RFC3711], the splicer would
have to 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. "

That's clearer than a SHOULD, yes. I'm still not clear if this
MUST is something that just works or not though, can you clarify
that? (In general, I'd not recommend we add any MUST or SHOULD
at all if we're not confident that an implementer will actually
write and test that code and that it'd work.)

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

That does look right to me, but since I don't understand it really,
I'll just believe you that it's ok:-) Are the "non-RTP means" that
could be used something that'd be clear to an implementer? If so,
then that'd be fine. If not, maybe you need to say what that means?

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

Fair enough,
Cheers,
S.


>