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

From: Alissa Cooper <[email-masked]>
Date: Tue, 01 Apr 2014 11:30:13 -0700

Hi Emil,

Thanks for responding. Comments inline.

On 3/19/14 1:51 AM, "Emil Ivov" <[email-masked]> 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 <[email-masked]> 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

---

From: Dan Wing <[email-masked]>
Date: Tue, 1 Apr 2014 11:42:40 -0700

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

> I was more concerned with the DoS aspect.

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

> controlled environments unless all security considerations are taken into

"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

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 03 Apr 2014 10:28:16 -0700

Hi Dan,

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

The DoS aspect that is described in the paragraph Emil quoted below.

>> I think something like the following might capture the
>> situation better:
>> 
>> OLD:
>"General use on the Internet" and "in controlled environments" are 100%
>of all networks, so perhaps simplifying to:
>
>NEW:

I think the text in the -04 is preferable to this, as it is more specific.

I would be interested in others' thoughts on the text I proposed above.

Thanks,
Alissa

---

From: Dan Wing <[email-masked]>
Date: Thu, 3 Apr 2014 10:39:46 -0700

>>>> service attack.  However, media integrity would not be compromised.

Sorry, I read it again and I'm still not clear on the concern.  Could you restate or rephrase.

> I would be interested in others' thoughts on the text I proposed above.

Could we at least eliminate the double negatives ("inappropriate ... unless")?

-d

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 03 Apr 2014 11:19:32 -0700

>>>> I was more concerned with the DoS aspect.

In response to Emil's note above about the SRTP text resolving the
security issues "from a privacy/confidentiality perspective," all I was
saying was that my initial question was prompted not because I was
concerned about a breach of confidentiality, but about the ability to
perform a DoS attack even when SRTP is in use. I think the text in Section
5 that describes this is ok though.

>Could we at least eliminate the double negatives ("inappropriate ...

In principle, yes, but it seems much easier to enumerate the situations
where it's inappropriate than where it's appropriate -- I'm finding it
difficult to think of better phrasing.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 15 Apr 2014 16:03:21 -0700

I’d like to close out this thread. Are folks on board with this proposed
change to Section 1?

OLD:

NEW:

Thanks,
Alissa

On 4/3/14, 11:19 AM, "Alissa Cooper" <[email-masked]> wrote:

>_______________________________________________
>mmusic mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/mmusic

---

From: Kevin Gross <[email-masked]>
Date: Tue, 15 Apr 2014 17:29:55 -0600

As fresh eyes on this, I'm having trouble understanding what NEW is trying
to say. Seems like the union of Internet and controlled environments is
everything. How about just saying:

Due to the security issues presented in Section 5, the latching mechanism
is not recommended unless all security considerations are taken into
account and solved.

Also, if you're going to change this in section 1, you'll also want to
change the treatment of the same subject in the last paragraph of the
abstract.

Also, although there's a brief definition of "latching" in the abstract,
there's no mention of "latching" in section 1 until the paragraph under
discussion. It would be helpful to add better context for "latching" in
section 1.

Kevin Gross - AVA Networks

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 18 Apr 2014 14:06:54 -0700

On 4/15/14, 4:29 PM, "Kevin Gross" <[email-masked]> wrote:

> As fresh eyes on this, I'm having trouble understanding what NEW is trying to
> say. Seems like the union of Internet and controlled environments is

This is basically the same as what the text currently says, so I think it’s
better to just leave the text as-is and close out this discussion.

>> 
> Also, if you're going to change this in section 1, you'll also want to change
> the treatment of the same subject in the last paragraph of the abstract.
> 

Seems like a reasonable suggestion. Could the authors make a run at that and
publish a rev that includes the other edits from my AD review?

Thanks,
Alissa

>>>>>>> >>>>> controlled environments unless all security considerations are
taken
>>>>>>> >>>>> into