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

Ari Keränen <ari.keranen@ericsson.com> Tue, 16 February 2016 14:22 UTC

Return-Path: <ari.keranen@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 902AF1A871A for <hipsec@ietfa.amsl.com>; Tue, 16 Feb 2016 06:22:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level:
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 K8esa9eS-qyG for <hipsec@ietfa.amsl.com>; Tue, 16 Feb 2016 06:22:51 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE541A6F3B for <hipsec@ietf.org>; Tue, 16 Feb 2016 06:22:50 -0800 (PST)
X-AuditID: c1b4fb2d-f794c6d000006f31-5e-56c330b8f21a
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id C4.74.28465.8B033C65; Tue, 16 Feb 2016 15:22:48 +0100 (CET)
Received: from m46.nomadiclab.com (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.248.2; Tue, 16 Feb 2016 15:22:48 +0100
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, Tom Henderson <tomhend@u.washington.edu>, HIP <hipsec@ietf.org>
References: <alpine.LRH.2.01.1602121354030.16926@hymn03.u.washington.edu> <56BF0BEA.4050709@ericsson.com>
From: Ari Keränen <ari.keranen@ericsson.com>
Message-ID: <56C330B8.8070706@ericsson.com>
Date: Tue, 16 Feb 2016 16:22:48 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56BF0BEA.4050709@ericsson.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFLMWRmVeSWpSXmKPExsUyM2K7t+4Og8NhBt1HLS2mLprMbDHz/EE2 ByaPJUt+Mnm0XI8JYIrisklJzcksSy3St0vgyvjfIVpwh79iz/ojrA2MJ3m6GDk4JARMJF4+ 0Opi5AQyxSQu3FvP1sXIxSEkcJhRoudBLzOEs45RYkv7ZkaQKmEBe4mT+26xgzSLCFRKbD7H ChIWEsiWOPvnFRtImFkgRmJmIzdImE3AVuJ3+x4mEJtXQFvizZ6LYFNYBFQlVj2bxAJiiwqk Seyf/RuqRlDi5MwnYHFOAR2JxQ2P2CFG2ks82FoGEmYWkJfY/nYOM8RWVYmr/14xTmAUnIWk exZCxywkHQsYmVcxihanFhfnphsZ66UWZSYXF+fn6eWllmxiBIbowS2/dXcwrn7teIhRgINR iYe3IOJQmBBrYllxZe4hRgkOZiUR3n+vgEK8KYmVValF+fFFpTmpxYcYpTlYlMR51zivDxMS SE8sSc1OTS1ILYLJMnFwSjUwmjPsi7+/enOa4r7JakW/ubep/fq+9K62PePRNWU5xkzPjSVe zqkIvfW1xPhNaRg3o+5ysxVTHitPVf7QcS8675WAwMmEtzG7Dyw4uP/tl4A94Zvql8T4/o6t ef8y8uTH2K+F6bsupkuef7Buc1NTyqrue+WyG9N7+G79+Hi44/xGhbn97nqsaUosxRmJhlrM RcWJABsYjHlNAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/mgYwMm__o217Cr_5qAI6qUMH0bY>
Cc: Jan Melen <jan.melen@ericsson.com>
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: Tue, 16 Feb 2016 14:22:52 -0000

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.

>> 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.


Cheers,
Ari