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

From: Alissa Cooper <[email-masked]>
Date: Fri, 14 Mar 2014 11:41:17 -0700

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. If it can't be, it seems to me
that this document should be making a stronger statement about the
inappropriateness of latching.

Also, I found a  couple of nits to address with any LC comments:

Section 1:

s/handle traffic in way that/handle traffic in a way that/

Section 2:

s/UA sends packet out first/UA sends packets out first/

Section 4:

s/IETF members/IETF participants/ (two occurrences)

s/the one the best suits/the one that best suits/

s/address information in in offers/address information in offers/

There is an in-text reference to "[tcp-splicing]," but there is no such
reference in the references section.

---

From: Emil Ivov <[email-masked]>
Date: Wed, 19 Mar 2014 10:51:49 +0200

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 <[email-masked]> wrote:
> 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). 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.

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.

I am obviously not suggesting we go and recommend the practice but the
purpose of the draft is to, above all, describe a hugely popular
practice so that we can have an informative (and only informative)
reference.

> If it can't be, it seems to me

We actually did a couple of back and forths (mostly with Cullen) on
making sure that the "LATCHING IS BAD" message is loud enough (in my
personal opinion we are even making it sound scarier that it needs to
be), but if anyone else has text that would better describe the
situation, suggestions are most welcome!

> s/address information in in offers/address information in offers/

Fixed! Thanks very much!

> 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

Emil

-- 
https://jitsi.org

---

From: Cullen Jennings <[email-masked]>
Date: Sat, 22 Mar 2014 12:59:44 -0600

> in controlled environments, where that kind of hijacking could not

Could you provide a bit more about where you see this being used? Most the latching I have seen is in exactly the places where network is not at all controlled. In a managed network you can vernally avoid the need for latching.

---

From: Emil Ivov <[email-masked]>
Date: Sun, 23 Mar 2014 16:14:35 +0100

On 22.03.14, 19:59, Cullen Jennings wrote:
>> generic Internet deployments. Many people using latching today, do
>> so in controlled environments, where that kind of hijacking could
>> not occur.
>
> Could you provide a bit more about where you see this being used?

Test services for one. Multi-site enterprise networks in combination 
with VPN. Public podcast-like conference calls with no access control.

I am sure there are others ... but I don't think it's worth spending 
time on them. The document already advises against latching. You 
personally approved the text and we all have other, more important 
drafts to worry about.

> Most the latching I have seen is in exactly the places where network
> is not at all controlled.

Absolutely there's a lot of that and all the people running services 
that way should have a read at the security considerations section in 
that draft. One more reason to get it out the door.

Emil

-- 
https://jitsi.org