Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt

Ari Keränen <> Fri, 14 June 2013 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26BF421F9D0A for <>; Fri, 14 Jun 2013 09:04:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.037
X-Spam-Status: No, score=-5.037 tagged_above=-999 required=5 tests=[AWL=0.913, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N-7GUbyPXj24 for <>; Fri, 14 Jun 2013 09:04:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9453221F9C81 for <>; Fri, 14 Jun 2013 09:04:23 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-98-51bb3f050319
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 15.F5.18006.50F3BB15; Fri, 14 Jun 2013 18:04:21 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server id; Fri, 14 Jun 2013 18:04:21 +0200
Received: from ( []) by (Postfix) with ESMTP id 5A6352AC6; Fri, 14 Jun 2013 19:04:21 +0300 (EEST)
Received: from (localhost []) by (Postfix) with ESMTP id 11425552A1; Fri, 14 Jun 2013 19:04:19 +0300 (EEST)
Received: from (localhost []) by (Postfix) with ESMTP id B5BEA55089; Fri, 14 Jun 2013 19:04:18 +0300 (EEST)
Message-ID: <>
Date: Fri, 14 Jun 2013 19:04:20 +0300
From: Ari Keränen <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Emil Ivov <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM+JvrS6r/e5Ag9+XLS3W7JzAYtExmc1i 6vLHLA7MHlN+b2T1WLLkJ5PH/zeBAcxR3DZJiSVlwZnpefp2CdwZ02YeZiqYrFyx/NUl9gbG v9JdjJwcEgImEsd7TrJD2GISF+6tZ+ti5OIQEjjFKLGy4yATSEJIYAOjxJsffBCJ3YwSc9f9 ZYRw1jFK7Fi/hAnCWcEocX7ZNrAWXgFtiY0tuxlBbBYBVYnFjxeBxdkEbCVWv7rJAmKLCiRL TJ66ggWiXlDi5MwnYLaIgLxEdxtEPbNAjETPtQYwW1jAWeL4jHcsEMt2Mks83b8e7HBOAU2J GxcnM0I0WEgsfnOQHcKWl2jeOpsZ4jk1iavnNjFD/KMqcfXfK8YJjKKzkOyehaR9FpL2BYzM qxjZcxMzc9LLjTYxAqPh4JbfqjsY75wTOcQozcGiJM778dSuQCGB9MSS1OzU1ILUovii0pzU 4kOMTBycIIJLqoGRh7lv5WXeyG2GqY4/+/9/uSHwZMraAkO1ODHT8zKJJSEzJWJuLC78wJxY 5Wv0lYXZo+fE6vO+oaxGadM2Ga/jSWwMPGveqHSrTVbZO8T0sbvB5wkPLLZxzd75JL9untGk azMzfzmpneJ56TL/v4XJXBtWLQMvncUsBx+1qK06dOa22V/DlJlKLMUZiYZazEXFiQCUCFFl WQIAAA==
Cc: "Cullen Jennings (fluffy)" <>, " WG" <>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jun 2013 16:04:29 -0000


The proposed text looks good to me (just need to expand the CGN acronym 
since it seems to be the first instance; and check if you can find good 
reference of CGN).

Regarding the RFC3424 UNSAF considerations, I discussed this together 
with our co-chair and AD, and we agreed that a full 3424 treatment is 
unnecessary considering that this is documenting existing behavior, not 
a new mechanism.

If this clears the remaining WGLC comments, we could move forward with 
the document.


On 6/11/13 10:52 AM, Emil Ivov wrote:
> On 11.06.13, 08:15, Cullen Jennings (fluffy) wrote:
>> Well, do you think the draft should say that this approach MUST NOT
>> be used with uncarpeted media because it allows and attacker behind
>> the same CGN can intercept the media ?
> I am assuming uncarpeted means unprotected here. Is this right?
> If so, then I think we shouldn't be doing any kind of (non-S) RTP
> because, regardless of whether or not we are using latching, our media
> would be exposed to eavesdropping from our ISP, hotspot provider, VoIP
> service provider, potentially people on the same link as us, MiTM
> attackers that have fooled us into using them as a default gateway,
> Wi-Fi monitors and possibly many others.
> As for the draft saying "MUST NOT", I wouldn't mind at all, however we
> don't even have a 2119 section. Also, we are not specifying a NAT
> traversal mechanism, we are just describing one that people are using
> overwhelmingly so that we can have something to point to as a
> descriptive reference.
> I agree that this point can be stressed upon however so, what if we
> added the following:
> ... actually participating in the SRTP key exchange then it would
>     simply refuse to latch onto a source unless it can authenticate
>     it.
>     *Failing to implement this would represent а serious threat to
>      users connecting from behind CGNs and is considered a harmful
>      practice.*
> Would this work?
> Emil
>> On Jun 11, 2013, at 3:03 PM, Emil Ivov <> wrote:
>>> Hey Cullen,
>>> On 11.06.13, 04:55, Cullen Jennings (fluffy) wrote:
>>>>>> and discussing the issues it raises with relation to this
>>>>>> draft.
>>>>>> Next I think you need to add a specific attack where two
>>>>>> people are both behind the same CGN.
>>>>> This exact case was already described in the security
>>>>> considerations section:
>>>>> (last paragraph on the page)
>>>> It was exactly this paragraph that I thought was pretty
>>>> misleading. When I read " SBCs have various mechanisms to prevent
>>>> this as well." I really wonder what they when both end points are
>>>> behind a CGN.
>>>> I think this paragraph should make it very clear that in the
>>>> CGN case, this technic allows interception of the media. If there
>>>> are specific ways to stop that from happening, the draft should
>>>> say it and if there are not it should be very explicitly clear
>>>> about that.
>>> I was actually referring to text that came later in that same
>>> paragraph:
>>> The attacker could also redirect all media to the real SIP UA after
>>> receiving it, in which case the attack would likely remain
>>> undetected and succeed.  Again, this would be of particular concern
>>> with larger scale NATs serving many different endpoints such as
>>> carrier grade NATs.  The larger the number of devices fronted by a
>>> NAT is, the more use cases would vary and the more the number of
>>> possible attack vectors would grow.
>>> 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. Additionally if the SBC that performs the latching is
>>> actually participating in the SRTP key exchange then it would
>>> simply refuse to latch onto a source unless it can authenticate
>>> it.
>>> Cheers, Emil
>>> --
>>> _______________________________________________ mmusic mailing
>>> list