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

Emil Ivov <> Tue, 11 June 2013 06:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD3F121F998B for <>; Mon, 10 Jun 2013 23:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.994
X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3LY06wMAuBxK for <>; Mon, 10 Jun 2013 23:03:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::230]) by (Postfix) with ESMTP id 7E58D21F9050 for <>; Mon, 10 Jun 2013 23:03:26 -0700 (PDT)
Received: by with SMTP id t56so5518099wes.35 for <>; Mon, 10 Jun 2013 23:03:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=73TaXKt647FQH72U8ml1vsjecYRIyvPDZoi9mOIMsDE=; b=L2E3BGTdiw+G0O0XOMl21GqiBDxbgW8W1wrujfdfmSB65YGRSjxWbKlLsXtVyMebwA IXiaqU5GQyrpK94m6ShXOQ3tQJZ2UlLBLqEuax+PBidGkftr4W0sr6bLJ6QkMb5zxall NJcGZILT7CjI+MnLr8I0G5G8cqDheXpyQr5o12/U+OapdZRB+xmm/fJkww2cXjtIiA9C Blot1sRYuhnLcGPn9lUESoASeFRh9m4ZlRdibGrbPrqJ50JJpLXAYH9gaKdYk4/zuRR2 LwkOshBUF9LfVgnYLu2L47Q9lxzYHn40WCL75a9k3cCYN9qrML9SWlZZ+nIEMAk/9oai WzrQ==
X-Received: by with SMTP id v10mr7440906wje.16.1370930605263; Mon, 10 Jun 2013 23:03:25 -0700 (PDT)
Received: from camionet.local ([2a01:e35:8a55:abc0:8d48:fb46:b976:405a]) by with ESMTPSA id fu14sm15311072wic.8.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 23:03:24 -0700 (PDT)
Message-ID: <>
Date: Tue, 11 Jun 2013 08:03:21 +0200
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQlNrd0Y2VzcBciPOfVxoue5ZG9BP7W58wJoRIMA1rC7Y/dQdl1d3BcMp8mTCrbW2boV803+
Cc: " 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: Tue, 11 Jun 2013 06:03:27 -0000

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.