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

[Dan Wing <[e-mail]>]

On Apr 1, 2014, at 11:30 AM, Alissa Cooper <[e-mail]> wrote:

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

That same paragraph goes on to say that ICE [RFC5245] is the IETF-advised way of doing things, rather than using Latching.

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

The DoS aspect of authenticating incoming SRTP packets to the SBC?


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

"General use on the Internet" and "in controlled environments" are 100% of all networks, so perhaps simplifying to:

NEW:
  Due to the security issues presented in Section 5, the latching mechanism
  is considered appropriate only when all security considerations are taken into
  account and solved.

-d

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