Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-latching-04

[Alissa Cooper <[e-mail]>]

Hi Emil,

Thanks for responding. Comments inline.

On 3/19/14 1:51 AM, "Emil Ivov" <[e-mail]> wrote:

>Hey Alissa,
>
>Apologies for the delay. My mail filters were somewhat messed up and I
>missed on some of the MMUSIC traffic.
>
>More inline.
>
>On Fri, Mar 14, 2014 at 8:41 PM, Alissa Cooper <[e-mail]> wrote:
>> I have reviewed this draft in preparation for IETF LC. I have one issue
>>that
>> I'd like to see the group discuss before issuing the LC: Section 1 says
>>"the
>> latching mechanism is considered inappropriate for general use on the
>> Internet unless all security considerations are taken into account and
>> solved." But given the lack of mitigations for attacks originating from
>> behind large-scale NATs as described in Section 5, it's not obvious to
>>me
>> that that condition can realistically be met.
>
>The draft suggests use of SRTP for authenticating media which does
>resolve the security issues (from a privacy/confidentiality
>perspective). 

I was more concerned with the DoS aspect.

>That's part of section 5:
>
>   Naturally, SRTP [RFC3711] would help mitigate such threats and should
>   be used independently of HNT.  For example, in cases where end-to-end
>   encryption is used it would still be possible for an attacker to
>   hijack a session despite the use of SRTP and perform a denial of
>   service attack.  However, media integrity would not be compromised.
>
>How does this sound to you?
>
>Now that I am reading it actually, I am thinking that there's no need
>for such a DoS to have permanent consequences. As long as an SRTP
>supporting SBC continues to latch to any new source until it
>authenticates one, then things should be fine.
>
>If this sounds reasonable, we will update the text in the next iteration.

Could you propose the text change on the list and we can hash it out here?

>
>Also it is worth reminding that the above threats apply mostly to
>generic Internet deployments. Many people using latching today, do so
>in controlled environments, where that kind of hijacking could not
>occur.

This was my point in raising the question about the characterization in
section 1. I think something like the following might capture the
situation better:

OLD:
Due to the security issues presented in Section 5, the latching mechanism
is considered inappropriate for general use on the Internet unless all
security considerations are taken into account and solved.


NEW:
Due to the security issues presented in Section 5, the latching mechanism
is considered inappropriate for general use on the Internet, and in
controlled environments unless all security considerations are taken into
account and solved.



>
>> There is an in-text reference to "[tcp-splicing]," but there is no such
>> reference in the references section.
>
>Oh right! Do we have a good reference about this at the IETF?
>Otherwise we could just go for something like this:
>
>"TCP Splice for application layer proxy performance" DA Maltz, P
>Bhagwat - Journal of High Speed Networks, 1999 - IOS Pressure

I think that's fine. I'm not aware of an IETF spec.

Alissa

>
>Emil
>
>-- 
>https://jitsi.org