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

Emil Ivov <emcho@jitsi.org> Sat, 11 May 2013 10:00 UTC

Return-Path: <emil@sip-communicator.org>
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 2591821F8E75 for <mmusic@ietfa.amsl.com>; Sat, 11 May 2013 03:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level:
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599]
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 1Efkshgweu0x for <mmusic@ietfa.amsl.com>; Sat, 11 May 2013 03:00:02 -0700 (PDT)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C06EC21F8E94 for <mmusic@ietf.org>; Sat, 11 May 2013 03:00:01 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id p57so4762602wes.20 for <mmusic@ietf.org>; Sat, 11 May 2013 03:00:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=7RvR6+BDmt192bnMUWrPKX8G6vROB+6SMmBIrcBjeE8=; b=gZvuksMW8tLJav8dJQAJACf6npPG+NIDyHVy9oSMg8p5Srdp3LtuO70ExPAO9DArVK XiunRKr0f9VV8rSL3eqm8T7/lrafBB5z/hcC+cWYYiosQevwQZ/Oz85aaBmhYiSNqo0w BWDT4rSHTE9WnTESgYbCTv80FJAbaDkioDepuEpc36dBLzSJfQ9290/7j9WpwRVCNZzb f/XtDvKbCePldK3CzE6seisWjv4tTEFK8VHqUJy8i/Dqb7IOFo6BJ8VPJtcafV6NTKHH DfyBxtHMsAd/wNumhAXMkYSEGBBKr2h/l48joFA+Smne9Eabxg96+qrYUQ2hQScGWZE3 j++g==
X-Received: by 10.180.206.172 with SMTP id lp12mr8448394wic.11.1368266400925; Sat, 11 May 2013 03:00:00 -0700 (PDT)
Received: from camionet.local ([83.228.76.175]) by mx.google.com with ESMTPSA id ge7sm2991677wib.6.2013.05.11.02.59.58 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 May 2013 02:59:59 -0700 (PDT)
Message-ID: <518E169E.4050006@jitsi.org>
Date: Sat, 11 May 2013 12:59:58 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
References: <20130507182905.15924.84115.idtracker@ietfa.amsl.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1134DED4A@xmb-aln-x02.cisco.com>
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB1134DED4A@xmb-aln-x02.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQnQCDZdzxVJIb1crldcfKLNEnCXYX+Ie/3YWMR4/gi3BJIRbaIVE5/mGGCeKMrAUF3S1KDK
Cc: "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: Sat, 11 May 2013 10:00:03 -0000

Hey Cullen,

On 10.05.13, 23:53, Cullen Jennings (fluffy) wrote:
> 
> I think the security section series underestimates the security
> vulnerabilities this introduces.

If you think we've missed any specific attacks we'd be happy to add them.

> I'm very sad to see the IETF
> publishing this at all with anything other than "This is not the
> recommended way to solve this problem" and why.

Well that's pretty much what we say:

    In no way does this document try to make a case for HNT or
    present it as a solution that is somehow better than
    alternatives such as ICE. The mechanisms described here, popular
    as they may be, are not necessarily considered best practice or
    recommended operation.

The security considerations section also specifically outlines cases
where DoS attacks can be performed even with the use of SRTP:

    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.

The point was to show that in spite of all the threat mitigating
techniques users of latching are still left vulnerable to those.

I certainly don't understand IETF processes as well as you do, but it is
my understanding that as an informational document the draft can only do
so much and that making explicit recommendations for or against
technologies was for Standards Track documents only. Am I wrong about this?

My recollection of the Paris and Vancouver meetings (and a quick skim
through the notes) is that this was also the direction chosen by the WG.

Again, if you believe that additional text would make things clearer we
are wide open to suggestions.

Cheers,
Emil


> 
> 
> 
> 
> On May 7, 2013, at 12:29 PM, internet-drafts@ietf.org wrote:
> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Multiparty Multimedia
>> Session Control Working Group of the IETF.
>> 
>> Title           : Latching: Hosted NAT Traversal (HNT) for Media in
>> Real-Time Communication Author(s)       : Emil Ivov Hadriel Kaplan 
>> Dan Wing Filename        : draft-ietf-mmusic-latching-01.txt Pages
>> : 14 Date            : 2013-05-07
>> 
>> Abstract: This document describes behavior of signalling
>> intermediaries in Real-Time Communication (RTC) deployments,
>> sometimes referred to as Session Border Controllers (SBCs), when
>> performing Hosted NAT Traversal (HNT).  HNT is a set of mechanisms,
>> such as media relaying and latching, that such intermediaries use
>> to enable other RTC devices behind NATs to communicate with each
>> other.  This document is non-normative, and is only written to
>> explain HNT in order to provide a reference to the IETF community,
>> as well as an informative description to manufacturers, and users.
>> 
>> 
>> The IETF datatracker status page for this draft is: 
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-latching
>> 
>> There's also a htmlized version available at: 
>> http://tools.ietf.org/html/draft-ietf-mmusic-latching-01
>> 
>> A diff from the previous version is available at: 
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-latching-01
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at: 
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________ mmusic mailing
>> list mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________ mmusic mailing list 
> mmusic@ietf.org https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org