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

Tom Henderson <tomhend@u.washington.edu> Tue, 23 February 2016 14:28 UTC

Return-Path: <tomhend@u.washington.edu>
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 DDEC61B2F7B for <hipsec@ietfa.amsl.com>; Tue, 23 Feb 2016 06:28:17 -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, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 PpPIoIlN9-fH for <hipsec@ietfa.amsl.com>; Tue, 23 Feb 2016 06:28:16 -0800 (PST)
Received: from mxout26.s.uw.edu (mxout26.s.uw.edu [140.142.234.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E70D1B2F7A for <hipsec@ietf.org>; Tue, 23 Feb 2016 06:28:16 -0800 (PST)
Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW15.02) with ESMTP id u1NEOjln020612 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Feb 2016 06:24:46 -0800
Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW14.04) with ESMTP id u1NEOhad007624; Tue, 23 Feb 2016 06:24:43 -0800
Received: from localhost (Unknown UID 10745@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u1NEOhpb007621; Tue, 23 Feb 2016 06:24:43 -0800
X-Auth-Received: from [73.239.169.224] by hymn04.u.washington.edu via HTTP; Tue, 23 Feb 2016 06:24:43 PST
Date: Tue, 23 Feb 2016 06:24:43 -0800 (PST)
From: Tom Henderson <tomhend@u.washington.edu>
To: miika.komu@ericsson.com
Message-ID: <alpine.LRH.2.01.1602230624430.18671@hymn04.u.washington.edu>
User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="-1903409144-786124079-1456237483=:18671"
X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.2.23.141816
X-PMX-Server: mxout26.s.uw.edu
X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, MIME_TEXT_ONLY_MP_MIXED 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_MIXED 0, __FORWARDED_MSG 0, __FRAUD_COMMON 0, __FRAUD_REFNUM 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0'
Archived-At: <http://mailarchive.ietf.org/arch/msg/hipsec/tWCNa9RT0p4St6TFaqEAa5QdiAk>
Cc: hipsec@ietf.org
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, 23 Feb 2016 14:28:18 -0000

Hi Miika, inline below.

On 02/22/2016 07:41 AM, Miika Komu wrote:
> 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.

Agree, we had this discussion many years ago and I don't think much has changed.  It seems that some level of STUN server infrastructure has been deployed since then, but no one (AFAIK) has implemented RFC 5770 to make use of it.
 
> 
>>>> 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?
> 

As I mentioned in the other post, I question whether we can get away from this extra effort, but I'd like to set aside the editorial work issue for the moment to try to decide about what the technical status should be about the 5770 STUN solution.

- Tom