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

Miika Komu <miika.komu@ericsson.com> Mon, 22 February 2016 15:41 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C13E31B36ED for <hipsec@ietfa.amsl.com>; Mon, 22 Feb 2016 07:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 7jBhy3W3-DV1 for <hipsec@ietfa.amsl.com>; Mon, 22 Feb 2016 07:41:17 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8120A1B3158 for <hipsec@ietf.org>; Mon, 22 Feb 2016 07:41:16 -0800 (PST)
X-AuditID: c1b4fb3a-f79ce6d000005138-cc-56cb2c1a57d4
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 35.FB.20792.A1C2BC65; Mon, 22 Feb 2016 16:41:14 +0100 (CET)
Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.248.2; Mon, 22 Feb 2016 16:41:13 +0100
To: <hipsec@ietf.org>
References: <alpine.LRH.2.01.1602121354030.16926@hymn03.u.washington.edu> <56BF0BEA.4050709@ericsson.com> <56C330B8.8070706@ericsson.com>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <56CB2C19.7060000@ericsson.com>
Date: Mon, 22 Feb 2016 17:41:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56C330B8.8070706@ericsson.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070102040108010602060003"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7q66UzukwgwMTjC2mLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHnr9zEXbHWueHBuHWsD4y/bLkZODgkBE4lfazYxQdhiEhfu rWfrYuTiEBI4zCjxaH0TWEJIYDWjxORnQSC2sIC9xMl9t9hBbBEBUYkpH04zQzR0M0rsnLKL FSTBJqAlserOdWYQm19AUmJDw24wm1dAW6LlXQ9YDYuAqsSUWVPA4qICERKHO7vYIWoEJU7O fMICYnMK6EisW7GfHWQBM8iCDZtvA13EAbRNReLiseAJjAKzkLTMQlYGkmAWsJW4M3c3M4St LbFs4Wso21pixq+DbBC2osSU7ofsELapxOujHxkhbGOJZev+si1g5FjFKFqcWlycm25kpJda lJlcXJyfp5eXWrKJERj+B7f8ttrBePC54yFGAQ5GJR5eA85TYUKsiWXFlbmHGFWA5jzasPoC oxRLXn5eqpIIb53U6TAh3pTEyqrUovz4otKc1OJDjNIcLErivGuc14cJCaQnlqRmp6YWpBbB ZJk4OKUaGA0zPoYJpG67NVmbySRO19XFzLpxzjo+49/JnrUzeNdVuLXcsjIPsLltXGPHenq3 Tq94pPOyc6xaT0+Urkmqe1t29sWCTQrFCWIfitNnTGd6m773xb7rE3VnmLPsWiFSb7k/c2L5 jtOWmu8PGb10lvzieqPW5e95kbWPupN+TPu351XPksyfKUosxRmJhlrMRcWJANUI6zqHAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/1FOWtkhMou29bnQ8wcJ6J5tah4o>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 22 Feb 2016 15:41:18 -0000

Hi,

On 02/16/2016 04:22 PM, Ari Keränen wrote:
> Thank you for the review Tom! Please see below.
>
>> On 12/02/2016 11:54 PM, Tom Henderson wrote:
>>> Gonzalo and all,
>>>
>>> My understanding is that the WG reached consensus several years ago
>>> that the standards-track NAT traversal variant would be the native
>>> NAT traversal and not the RFC5770-based ICE/STUN/TURN version.
>>>
>>> I reviewed the above draft and noticed that it still contains
>>> normative references to RFC5770 (pointers to material found only in
>>> RFC5770) throughout, and contains RFC5770 as a normative reference
>>> in Section 8.1.  It seems to me that the WG ought to produce a
>>> specification that can stand alone from RFC5770, because as it
>>> stands now, it seems to me that someone implementing it would need
>>> to consult both drafts and may be uncertain about what is still
>>> applicable from RFC5770.  For example, is the UDP-ENCAPSULATION
>>> mode still valid?
>
> Indeed this variant is the standards-track solution, but I think it
> makes sense to not obsolete the RFC5770. For example, in some scenario
> the STUN based solution could be better than native HIP based. And also
> the UDP-ENCAPSULATION mode should be still valid.

I think the main benefit of the STUN-based solution is the available 
infrastructure. From a protocol engineering perspective, RFC5770 is more 
complex to implement.

>>> ICE (RFC 5245) is also still listed as normative but it seems to me
>>> that it should also be informative in this draft.
>
> The details of e.g., how ICE checklists are used are defined in RFC5245
> so I think it needs to be normative.
>
>>> I think it would be appropriate to just reference 5770 in the
>>> Introduction, stating that this specification replaces RFC 5770
>>> with a different mechanism than ICE/STUN/TURN, and then try to
>>> avoid referencing 5770 from then on.
>
> Avoiding RFC 5770 altogether would require lots of editorial work with
> this draft for a questionable amount of benefit, so I think it's better
> if we simply have it as normative reference. The maturity level of 5770
> (experimental) is an issue, but I think it is possible - and makes sense
> - to make an exception here.

If it is not a problem from the viewpoint of IETF process, I would 
suggest to keep the native NAT traversal mode as a delta to RFC5770 but 
add more introductory text. Reworking the draft as a replacement for 
RFC5770 would require quite much extra effort. Tom are you volunteering?