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

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Tue, 11 June 2013 06:16 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C9021F9A7F for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 23:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.949
X-Spam-Level:
X-Spam-Status: No, score=-109.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+rinFq7OVnA for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 23:16:18 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 69F6E21F9A79 for <mmusic@ietf.org>; Mon, 10 Jun 2013 23:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2574; q=dns/txt; s=iport; t=1370931378; x=1372140978; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rgnuj8YrFplLkFQJYOIp+1bxRDiWqwfEfUE2Guy4eKs=; b=g8xCIC/NXvEMtHTb1+wyjqjM3IWkqzrd0k3z1DkCs8MymT40T1mM15o1 jZ6P6KLYJnSS8cDlBs8Dz+lN+Qibse9lHWL7fXxpvQcv2D6JJSKONPIyA AXtTStXulISmZVToMS5vC/ynwZXPfEKGmtWkbXArrV0eAT7wl6iRuczmK g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlkFAADAtlGtJV2d/2dsb2JhbABZgwkwSb5JexZ0giMBAQEDAQEBATctBwQHBQsCAQgOCgoUECcLJQIEDgUIh38GDLoJjwQCMQeCf2EDmGmQGYMPgic
X-IronPort-AV: E=Sophos;i="4.87,843,1363132800"; d="scan'208";a="221233204"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 11 Jun 2013 06:16:17 +0000
Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5B6GHsQ024576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Jun 2013 06:16:17 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.36]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 11 Jun 2013 01:16:17 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt
Thread-Index: AQHOZe11EXDGbTPi/kGsN0Ab2PGjGpkwBu1ogABXZQA=
Date: Tue, 11 Jun 2013 06:15:26 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB113558E6A@xmb-aln-x02.cisco.com>
References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1134DED4A@xmb-aln-x02.cisco.com> <518E169E.4050006@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB1135230D4@xmb-aln-x02.cisco.com> <51B5EDB9.9030109@jitsi.org> <C5E08FE080ACFD4DAE31E4BDBF944EB113558B54@xmb-aln-x02.cisco.com> <51B6BDA9.2000902@jitsi.org>
In-Reply-To: <51B6BDA9.2000902@jitsi.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.89.35]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4BEE345C05BC6043B171F8C05EFD8F41@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Cullen Jennings \(fluffy\)" <fluffy@cisco.com>, "mmusic@ietf.org WG" <mmusic@ietf.org>
Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-latching-01.txt
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 06:16:23 -0000

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 ?

 
On Jun 11, 2013, at 3:03 PM, Emil Ivov <emcho@jitsi.org> 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:
>>> 
>>> tools.ietf.org/html/draft-ietf-mmusic-latching-02#page-11
>>> 
>>> (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
> 
> 
> -- 
> https://jitsi.org
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic