Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Thu, 31 March 2016 14:47 UTC

Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DED212D186 for <hipsec@ietfa.amsl.com>; Thu, 31 Mar 2016 07:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.221
X-Spam-Level:
X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6j-zaQgodeh for <hipsec@ietfa.amsl.com>; Thu, 31 Mar 2016 07:47:07 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3EBE12D1CF for <hipsec@ietf.org>; Thu, 31 Mar 2016 07:47:04 -0700 (PDT)
X-AuditID: c1b4fb25-f79f86d00000400a-82-56fd3867ca1b
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F0.86.16394.7683DF65; Thu, 31 Mar 2016 16:47:03 +0200 (CEST)
Received: from [148.135.149.145] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Thu, 31 Mar 2016 16:46:22 +0200
To: Miika Komu <miika.komu@ericsson.com>, <hipsec@ietf.org>
References: <alpine.LRH.2.01.1602230608110.18671@hymn04.u.washington.edu> <56CDBDA1.7050207@ericsson.com> <3CEE85EA-C996-4B28-B0A3-DA8B158BD159@temperednetworks.com> <56D1630A.7000209@ericsson.com> <56D45895.2060503@ericsson.com> <56DD757B.8050002@ericsson.com>
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Message-ID: <56FD383D.8050200@ericsson.com>
Date: Thu, 31 Mar 2016 17:46:21 +0300
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56DD757B.8050002@ericsson.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM2K7rm66xd8wg3+NQhZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq9pP1gKrolWrHt+mbGBcYVgFyMnh4SAicTaS7dYIGwxiQv3 1rN1MXJxCAkcYZS483kjI4SzllHi4ffVYFXCAvYSJ/fdYgexRQSsJT5cXs4EUdTLJPF61iY2 kASbgIXEllv3wRp4BbQlNt2YC9bAIqAqMXH9N7C4qECMxPF35xghagQlTs58AhbnFNCRWLSk jwnEZhYwkDiyaA4rhC0vsf3tHGYQWwho5vJnLSwTGAVmIWmfhaRlFpKWBYzMqxhFi1OLk3LT jYz1Uosyk4uL8/P08lJLNjECw/Dglt+qOxgvv3E8xCjAwajEw7ug5U+YEGtiWXFl7iFGCQ5m JRFePfO/YUK8KYmVValF+fFFpTmpxYcYpTlYlMR5WT9dDhMSSE8sSc1OTS1ILYLJMnFwSjUw tn1mWn8+KDjSw/h5jFdCyTVn1i/BPqmdkzks9pdF75wTOfnvRKGpy5aIH/p21CalW+jJgbqv K1dMdF7Yxe5v88z/ZsefX0wyi3bfd3m0SPFpyztHNs+fi7co3s3bIzC3ROJid3nXAYPt9Sdv ds2R0XycfjGl/mnkcpntamI7jQOU80sCJx8PVWIpzkg01GIuKk4EACSSxYo/AgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/XXLytmq2EXx-3EO0ydwnkGXGtDk>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Mar 2016 14:47:17 -0000

Hi Miika,

what is the status of this?

Thanks,

Gonzalo

On 07/03/2016 2:35 PM, Gonzalo Camarillo wrote:
> Hi,
> 
> I have just talked with Miika and he has volunteered to take the pen and
> add the necessary clarifications to the draft so that it is more
> readable. Thanks, Miika!
> 
> First he will look into adding clarifications to the existing draft
> while still referencing the old RFC. If the group is not happy with the
> readability after the editorial pass (or our AD does not finally let us
> downref the old RFC), we can consider bringing material from the old RFC
> directly into the new one.
> 
> I would also like the group to comment on the following two proposals:
> 
> 1) the draft will allow implementers to use HIP native relays only. In
> addition, the use of STUN and TURN relays will be optional.
> 
> 2) in addition to covering the base exchange, the draft will also cover
> the mobility readdressing exchange.
> 
> Thanks,
> 
> Gonzalo
> 
> On 29/02/2016 4:41 PM, Miika Komu wrote:
>> Hi,
>>
>> On 02/27/2016 10:49 AM, Gonzalo Camarillo wrote:
>>> Hi Jeff,
>>>
>>> thanks for your feedback.
>>>
>>>> Regarding pros/cons:
>>>> How widely-deployed is STUN/TURN? Are public servers widespread?
>>>
>>> there are several of them. They are mostly used for VoIP. You can google
>>> for "public stun turn servers" or something similar. There are a few
>>> lists out there.
>>
>> I guess the situation is like this:
>>
>> HIP control plane relay:
>> * new critical infrastructure that needs to be deployed anyway (TURN
>> server cannot be used for this)
>>
>> Gathering of address candidates:
>> * from a STUN server (many available)
>> * ...or from control plane relay registration (which is mandatory anyway)
>>
>> Data plane relay:
>> * using TURN server (it seems some are available)
>> * ...or using the ESP relay as specified in native NAT spec (none
>> deployed, but I guess could co-locate with the HIP control plane relay)
>>
>> So, the critical part are the HIP control plane relays which provide
>> also similar functionality as STUN servers (i.e. provide server
>> reflexive candidates). So I guess the question boils down to the
>> availability of TURN servers.
>>
>> P.S. Nothing really prevents to use STUN servers to discover address
>> candidates in the native NAT traversal version. The discovery process is
>> independent of the NAT penetration process.
>>
>>
>>
>> _______________________________________________
>> Hipsec mailing list
>> Hipsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/hipsec
>>
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec
>