Re: [secdir] Secdir review of draft-ietf-mmusic-latching-05.txt

Emil Ivov <> Thu, 29 May 2014 16:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A61C61A6FEF for <>; Thu, 29 May 2014 09:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1jViOlZ3xxNm for <>; Thu, 29 May 2014 09:18:40 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACDB11A6FFE for <>; Thu, 29 May 2014 09:18:26 -0700 (PDT)
Received: by with SMTP id l18so653621wgh.11 for <>; Thu, 29 May 2014 09:18:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EQTQDF80WH9jdOAQlAStAFQn2mvoHVyqz9kQTyZ5LFM=; b=TV0nff7CXC7fL91241dZaImpM7vYh4rYqfC9bdGdQNAIuAPJ9AqQaQvCV9Pn1/ftj8 P/n5gT4w5eibELZYsIN4epP8hPbdTpb7rV8aj0vQEiBiYeGpGKZsdbbcTbLCVZM6hNnh Ag/SBvVSDacWKOvI4fIXsoYfAS2/vUrmNfJxN2X7ZJo25JD5qE51NkhLbuwhngA1d9a2 R6UlxpNVWgQj+9H8qwAml5Q7U5UgQjXVbMXmheS20RIrSIbVcvWYo0bI0qZw1HjrU2WN 8RK5ShL6j2Urm8WRq1nsXgdZGs0lmN9SfqnE/5wcQctVwkHgzKeyJiZ7UZPyHotJdgLd VhRg==
X-Gm-Message-State: ALoCoQm+jaHjrrMTtnPa/S3OmknV1OgK6Zfn0r8/FYhDHVxrOrhJI7WGJDdk2baL8ZgAdUBIk/CE
X-Received: by with SMTP id gh20mr12047974wjc.41.1401380301799; Thu, 29 May 2014 09:18:21 -0700 (PDT)
Received: from camionet.local ( []) by with ESMTPSA id s3sm2809456wje.36.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 09:18:20 -0700 (PDT)
Message-ID: <>
Date: Thu, 29 May 2014 18:17:46 +0200
From: Emil Ivov <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Takeshi Takahashi <>,,,,
References: <000001cf759b$d1250a40$736f1ec0$>
In-Reply-To: <000001cf759b$d1250a40$736f1ec0$>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Fri, 30 May 2014 06:20:59 -0700
Subject: Re: [secdir] Secdir review of draft-ietf-mmusic-latching-05.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 May 2014 16:18:42 -0000

Hey Takeshi,

Thank you for your review. Comments inline:

On 22.05.14, 10:57, Takeshi Takahashi wrote:
> Hello,
> I have reviewed this document as part of the security directorate's ongoing
> effort to review all IETF documents being processed by the IESG.  These
> comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments just
> like any other last call comments.
> This document describes the behavior of signaling intermediaries in RTC
> deployments when performing hosted NAT traversal (HNT).	
> The document begins with summarizing the problems with NAT traversal for
> protocols such as SIP, and then outlines HNT and the latching mechanism that
> approach the problems.
> Nevertheless, this document is not recommending the use of latching.
> Instead, the document alerts its use and elaborates its security concerns in
> Section 5 "Security considerations" by showing several examples.
> The security consideration covers issues such as DoS-resistance/resource
> exhaustion, impersonation and addresses the use of encryption mechanism.
> It is an interesting, tutorial-like document, and I think this document is
> ready.
> According to the mmusic mailing list, the security consideration section has
> been discussed from the early stage of this draft, so the section also seems
> to be mature, IMHO.
> A bit of editorial review would be helpful.
> 1. It could be helpful if you could spell out the abbreviations when they
> appear at the first time (e.g., UAC, UAS, SIP, SDP, and SBC), not at the
> second time.

Right. SDP and SIP were indeed transgressing (fixed now) but all of the 
others seem to be expanded on first use. Or am I missing something?

> 2. In section 1: " and described in [RFC3424]" should be "as described in
> [RFC3424]"?


> 3. In section 4: "from from" -> "from" ?


> The review was based on the document uploaded at
> .
> By the way, if RTC and SBC are used as the identical terms in this document,
> why do we use the term RTC (Real Time Communication) in the document tile
> while we use the term SBC in the main body texts?

Well, they actually refer to quite different things. RTC, as you point 
out, refers to real-time communication. SBC on the other hand stands for 
session border controller (which is a signalling entity used by some RTC 

Did I misunderstand the question, or do you believe the text is somehow 

> In any case, it is a very minor comment, and I think the draft is ready to
> move forward.
> Take

Thanks again, all fixes will be available in the next submission.