Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06

Ari Keränen <ari.keranen@ericsson.com> Wed, 29 May 2013 09:51 UTC

Return-Path: <prvs=886125c88c=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 CDE5721F8FAF for <mmusic@ietfa.amsl.com>; Wed, 29 May 2013 02:51:44 -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 4eHm9AmZvBnR for <mmusic@ietfa.amsl.com>; Wed, 29 May 2013 02:51:38 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5404321F85BF for <mmusic@ietf.org>; Wed, 29 May 2013 02:51:33 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-c1-51a5cfa332a5
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 74.49.18006.3AFC5A15; Wed, 29 May 2013 11:51:32 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 29 May 2013 11:51:32 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 97A97247A; Wed, 29 May 2013 12:51:31 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F3E235515E; Wed, 29 May 2013 12:51:29 +0300 (EEST)
Received: from tri62.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A84AB54A35; Wed, 29 May 2013 12:51:29 +0300 (EEST)
Message-ID: <51A5CFA2.30801@ericsson.com>
Date: Wed, 29 May 2013 12:51:30 +0300
From: =?ISO-8859-1?Q?Ari_Ker=E4nen?= <ari.keranen@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <518BB81A.8090608@cisco.com> <51965190.10900@ericsson.com> <519E2BF8.7040500@ericsson.com> <519E58D1.6080600@ericsson.com> <51A3278D.8060402@ericsson.com>
In-Reply-To: <51A3278D.8060402@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM+Jvre6S80sDDe5MYLe42/uCyWLq8scs DkweS5b8ZPL4cvkzWwBTFLdNUmJJWXBmep6+XQJ3xo79T5gLFgpXHHg6mbGBsY+/i5GDQ0LA RGLFXIcuRk4gU0ziwr31bCC2kMApRommb0VdjFxA9gZGiadrNrFDOLsZJV4dusAG4axjlFj0 eD2Us4JR4vucrcwgY3kFNCV6t6qCjGIRUJXo/3edFcRmE7CXuDnhOjuILSqQLDF56goWEJtX QFDi5MwnYLaIgJnEwwn7wc5gFgiV+HNxDZgtLOAn0XdoJxPErmWMEmfOrmMCSXAK6Ei8ODmD FaLBVuLCnOssELa8RPPW2cwQv6lJXD23iRniN1WJq/9eMU5gFJ2FZPcsJO2zkLQvYGRexcie m5iZk15utIkRGPgHt/xW3cF455zIIUZpDhYlcV493sWBQgLpiSWp2ampBalF8UWlOanFhxiZ ODhBBJdUA2MDR9r+hbf7Y2dp5BVfiTjxabnmXS81dUU5b8Y3Fw57ar+fyBGRYTP35oaWnSc7 OnfP+Sh8NW+ZtswbtyLXF8/TBdX8RZqCs2emTWb4Uf9osc/GbEaNyYru799msj1Z2fhk1e/i qRY1rCU1cZNPFS89ojUrxFpeO6yrpaHV5kHo3Zl71WY9slJiKc5INNRiLipOBADDOrSETwIA AA==
Cc: mmusic <mmusic@ietf.org>, draft-ietf-mmusic-rtsp-nat-evaluation@tools.ietf.org
Subject: Re: [MMUSIC] 1 Week WGLC for draft-ietf-mmusic-rtsp-nat-evaluation-06
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: Wed, 29 May 2013 09:51:46 -0000

Hi Magnus,

The diff looked good. Couple of quick nits:

    5.  The RTSP Client uses the RTSP Servers response to create TURN

s/Servers/Server's/

    7.  The first media packet to arrive at the TURN server on the
        external port; If matching established permissions the TURN
        server forwards the media packets to the RTSP client.

s/If matching/If there exists a matching/
or /If the packet matches an/


Cheers,
Ari

On 5/27/13 12:29 PM, Magnus Westerlund wrote:
> Hi,
>
> Sorry for missing the other changes. I think I gotten all the lock down
> changed now. This has resulted in some significant changes in the text
> for TURN relays, including a server implementation requirement. I
> recommend that people do take a look at the diff:
>
> http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-rtsp-nat-evaluation-08
>
> Cheers
>
> Magnus
>
>
> On 2013-05-23 19:58, Ari Keränen wrote:
>> On 5/23/13 5:47 PM, Magnus Westerlund wrote:
>>> On 2013-05-17 17:49, Ari Keränen wrote:
>>>
>>>>
>>>>
>>>> 4.9.1.  [TURN] Introduction
>>>>
>>>>      On the external side this is
>>>>      limited to the source address/port pair of the first packet arriving
>>>>      on the binding.  After the first packet has arrived the mapping is
>>>>      "locked down" to that address.  Packets from any other source on
>>>> this
>>>>      address will be discarded.
>>>>
>>>> This doesn't sound right. This behavior was changed (eventually into
>>>> using permissions) somewhere back in draft-rosenberg-midcom-turn-06. See
>>>> http://tools.ietf.org/html/rfc5766#section-2.3 for up-to-date behavior.
>>>> Check also steps 5 & 7 in the next section and section 4.9.4 for more
>>>> lock down text.
>>>
>>> I changed this to:
>>>
>>> To prevent DoS attacks on either recipient, the packets forwarded are
>>> restricted to the specific source address. On the client side it is
>>> restricted to the source setting up the allocation. On the external side
>>> this is limited to the source address/port pair that have been given
>>> permission by the TURN client creating the allocation. Packets from any
>>> other source on this address will be discarded.
>>>
>>> I will shortly submit an updated draft.
>>
>> Looks good to me. However, also the following sections had some "lock
>> down" text that should be updated (see details on my original mail above).
>>
>>
>> Cheers,
>> Ari
>>
>>
>>
>
>