Re: [MMUSIC] [Technical Errata Reported] RFC5245 (3619)

Ari Keränen <ari.keranen@ericsson.com> Tue, 14 May 2013 12:21 UTC

Return-Path: <ari.keranen@ericsson.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 A90E621F901F for <mmusic@ietfa.amsl.com>; Tue, 14 May 2013 05:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 o66zEasnQLpN for <mmusic@ietfa.amsl.com>; Tue, 14 May 2013 05:21:50 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5E56121F8F7B for <mmusic@ietf.org>; Tue, 14 May 2013 05:21:47 -0700 (PDT)
X-AuditID: c1b4fb30-b7f3a6d0000007a4-c5-51922c5b8c07
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A3.4A.01956.B5C22915; Tue, 14 May 2013 14:21:47 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Tue, 14 May 2013 14:21:46 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8C1ED24C4; Tue, 14 May 2013 15:21:46 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 89E7F54E38; Tue, 14 May 2013 15:21:45 +0300 (EEST)
Received: from As-MacBook-Air.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CDF6454E36; Tue, 14 May 2013 15:21:44 +0300 (EEST)
Message-ID: <51922C59.5080309@ericsson.com>
Date: Tue, 14 May 2013 15:21:45 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= <ari.keranen@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: akundu@us.ibm.com
References: <20130514042107.BFAE062106@rfc-editor.org>
In-Reply-To: <20130514042107.BFAE062106@rfc-editor.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+JvrW60zqRAg7WTBC0OPvnMbPH+gq5F 8/Nl7BZTlz9msWja/5XNYmqfrQObx5TfG1k9liz5yeQxeeMsFo/W9TMZPRrajrF6nLvWxxzA FsVlk5Kak1mWWqRvl8CV8eCyU8EdxYpj7/YzNTA+k+pi5OSQEDCR+HzmGBOELSZx4d56ti5G Lg4hgVOMEg293UwQzgZGiRvrNkE5uxklNvT/YIRw1jFK9Fxaxg7SLySwglFi2gpJEJtXQFvi 1PGTzCA2i4CqxOmDvxhBbDYBe4mbE66D1YsKJEss3bmUDaJeUOLkzCcsILaIgKjEl7n7wBYw C8xllLi/eiFQEQeHsIC5xONVjhC7zCSeXpsM1ssJFH767jVYL7OArcSFOdehbHmJ7W/nMEP8 piZx9dwmZoheVYmr/14xTmAUnYVk9Swk7bOQtC9gZF7FyJ6bmJmTXm6+iREYQwe3/DbYwbjp vtghRmkOFiVx3mSuxkAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjK5/w7YGnnZWX/tNeDV/ RFvDs/SDK6P/lFyw38HFfrZv5pXF3pKT/3bdt1STbdm9OizL9979vIusB2a8/yMrpPqtLyq2 7ExZvPKLsx3s1R1BE7mL2ywMCnuXWPy/8euR0eGZCyKyH5f84tTrlPedy/2ulks4ceHSe8aS fkmr1LhDdhuIZ9duUGIpzkg01GIuKk4EAB2X1lVvAgAA
Cc: mmusic@ietf.org, jdrosen@jdrosen.net, gonzalo.camarillo@ericsson.com, fandreas@cisco.com, RFC Errata System <rfc-editor@rfc-editor.org>
Subject: Re: [MMUSIC] [Technical Errata Reported] RFC5245 (3619)
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, 14 May 2013 12:21:56 -0000

Hi Ashish,

Peer Reflexive candidate discovery (see, e.g., Sections 7.1.3.2.1 and 
7.2.1.3. of RFC 5245) should take care of that case.


Cheers,
Ari

On 5/14/13 7:21 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC5245,
> "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5245&eid=3619
>
> --------------------------------------
> Type: Technical
> Reported by: Ashish Kundu <akundu@us.ibm.com>
>
> Section: Section 4, 5
>
> Original Text
> -------------
> Missed candidate pair in ICE standard
>
> Corrected Text
> --------------
> Scenario: X is caller, Z is callee. X is behind a non-full-cone (such as symmetric) NAT, Z is behind a full-cone NAT.
>
> ICE standard: Section 2.1 of RFC5245 describes the addresses that are collected as candidate addresses: (local address, server-reflexive address, TURN relay address).  For X: (X:x, X1:x1, Yx:yx), and for Z: (Z:z, Z1:z1, Yz:yz).
>
> Missed candidate pair in ICE standard:
> 1. X:x sends a connection check message to the Z1:z1 (as part of the process in Section 2.2 of the standard)
> 2. Since X is behind a non-full cone NAT such a symmetric one, NAT of X maps X:x to X2:x2, sends the message to Z1:z1
> 3. Z is behind a full-cone NAT, so packets received at Z1:z1 address is forwarded to Z:z by the NAT
>
> Since X is behind a non-full cone NAT such a symmetric one and Z is behind a full-cone NAT, connection from X:x to Z1:z1 would be via a server-reflexive address X2:x2 of X, which is not a candidate address for X as specified by ICE. X2:x2 should be a candidate address of X, which however can only be determine when X sends a message to Z. The pair (X2:x2, Z1:z1) provides a direct connection option between X and Y.
>
> Conditions on which X2:x2 is a valid candidate address:
> 1. One of the peers (Z) is behind a full-cone NAT, else step 3 above does not succeed.
> 2. X2:x2 is unique, i.e., different from X1:x1 (already covered by Section 2.1) if and only if one of the peers is  behind a non-full-cone NAT.
>
> So I think there should be two stages in the candidate collection process:
> A: Section 2.1 -- candidate addresses independent of the other clients
> B: collection of the candidate pairs with respect to the peer, such as X2:x2 and Z2:z2, if any.
>
> B consists of the following steps including 1, 2, and 3:
> 4. Z:z determines if X2:x2 from which it received the message is a different address than in the candidate set of X.
> 5. If 4 is true, then send an OK message to X2:x2 that it received the message with X2:x2 XOR-encoded.
> 6. X:x receives the OK message in 4, then X:x determines X2:x2 as its new candidate address.
>
> If X:x decides to establish the connection via X2:x2, it sends ACK message to Z2:z2.
>
> Notes
> -----
> This feedback for improvement of ICE candidate gathering and decision process was   sent to Dr. Rosenberg on Nov 09, 2012. However, since I have not received any response from him over my next two followups and this e-mail, I thought it should be reported via this method.
>
> This is not an error mesage, but a method to improve the candidate gathering and decision process of ICE.
>
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5245 (draft-ietf-mmusic-ice-19)
> --------------------------------------
> Title               : Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
> Publication Date    : April 2010
> Author(s)           : J. Rosenberg
> Category            : PROPOSED STANDARD
> Source              : Multiparty Multimedia Session Control
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG
>