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

Emil Ivov <> Tue, 11 June 2013 07:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8504C21F9A82 for <>; Tue, 11 Jun 2013 00:52:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nkZXZgeak8JQ for <>; Tue, 11 Jun 2013 00:52:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::231]) by (Postfix) with ESMTP id 4FC4321F9A93 for <>; Tue, 11 Jun 2013 00:52:28 -0700 (PDT)
Received: by with SMTP id a12so3727375wgh.4 for <>; Tue, 11 Jun 2013 00:52:27 -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=FFIf6u6scGCwOGkuE8wL1RjPGvd1SBqQKMA2Pru+bYQ=; b=TIcn3Hh51NRIpm9ZhAgRqnImxBiXI/ww7tbr7zSXPM25fC8Ej/2IgcdZwL/baFxM4r mBLM+/zjX2e9cOe7udOaEf0l9hiFRN7/yq5q8lBzDSXD40/bJ5ZiNQfoYnIqzIQgO76y EJkJvDD2s7gCmAXFRthtIX/k0n7Sbmx4sg5/iHoEsSvRH2TLEPgEaZYAPa/VCvdcx4Ok B8OwMbnNnUAsUIpkN3B7HGF9Sb0Mu0i64QqX+nXsbfzSYFlJNea0UMfjR2vOyDyj+z/7 xwRXWuxJp/d6+q/IEN2kY/nyou5WQbhcR5sFfyogwGOAu4w7dMerEDNrJr/jWb5EbfMZ yhEQ==
X-Received: by with SMTP id v7mr7501598wjz.33.1370937147328; Tue, 11 Jun 2013 00:52:27 -0700 (PDT)
Received: from camionet.local ( []) by with ESMTPSA id b11sm15917807wiv.10.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Jun 2013 00:52:26 -0700 (PDT)
Message-ID: <>
Date: Tue, 11 Jun 2013 09:52:24 +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=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlTQu40fh1zavRZDron1df2S6RoPsYqFdZtiqmJjtJRZVMPOwgX0eImrjM4zkTN6Rmdd5XO
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 07:52:38 -0000

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

    *Failing to implement this would represent а serious threat to
     users connecting from behind CGNs and is considered a harmful

Would this work?


> 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