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

Miika Komu <miika.komu@ericsson.com> Wed, 29 June 2016 19:01 UTC

Return-Path: <miika.komu@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 338D512DDD0 for <hipsec@ietfa.amsl.com>; Wed, 29 Jun 2016 12:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.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] 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 F_7AVJFk2Wn2 for <hipsec@ietfa.amsl.com>; Wed, 29 Jun 2016 12:01:46 -0700 (PDT)
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 9C8A212D9FF for <hipsec@ietf.org>; Wed, 29 Jun 2016 12:01:31 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-b3-57741b09ac63
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 24.58.12516.90B14775; Wed, 29 Jun 2016 21:01:30 +0200 (CEST)
Received: from [100.94.2.57] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.294.0; Wed, 29 Jun 2016 21:01:29 +0200
To: <hipsec@ietf.org>
References: <alpine.LRH.2.01.1602230608110.18671@hymn04.u.washington.edu>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <57741B09.2080209@ericsson.com>
Date: Wed, 29 Jun 2016 22:01:29 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.01.1602230608110.18671@hymn04.u.washington.edu>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050909070603010801040306"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2K7hy6XdEm4wdItjBZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpTZ/xgL1npV/H38lr2B8YRzFyMnh4SAicTLdd9YIWwxiQv3 1rN1MXJxCAkcYZS4vGAZlLOSUeLJtpNMIFXCAvYSJ/fdYgexRQREJaZ8OM0MYgsJeEr8mfSZ DcRmE9CSWHXnOlicX0BSYkPDbjCbV0BbouXnU6BeDg4WAVWJbft5QMKiAhESs7b/YIIoEZQ4 OfMJC4jNKeAlcWH7CSaQG5gFuhkl1r3axwrSKySgInHxWPAERoFZSFpmISsDSTAL2Ercmbub GcLWlli28DWUbS0x49dBNghbUWJK90N2CNtU4vXRj4wQtrHEsnV/2RYwcqxiFC1OLS7OTTcy 1kstykwuLs7P08tLLdnECAz+g1t+6+5gXP3a8RCjAAejEg/vAp6ScCHWxLLiytxDjCpAcx5t WH2BUYolLz8vVUmE10YCKM2bklhZlVqUH19UmpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFq EUyWiYNTqoGxvL874MPfhrbGE7/uTQ+Py7LfNPnrv0fLIoQEuoSmLneeUyjh8tvxS8wCpr8C eVOmrE4VvbPexaI0y6mDIXCXzR/LupNWb1YYuLiu05xicWqaSvjSDi8Rg8kenfwZpWG+nTc1 5uo1Xpi78pKcEcf3BnPBPN6D2SWCc8R5Vu6bYFbKe8hrW4cSS3FGoqEWc1FxIgCwD/7rhgIA AA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/hipsec/CspxJtANw3bjEFL3NxU4CfXQkFk>
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: Wed, 29 Jun 2016 19:01:49 -0000

Hi,

On 02/23/2016 04:08 PM, Tom Henderson wrote:
>
>
> On 02/16/2016 06:22 AM, 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.
>>
>>>> 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.
>
> Ari, I have thought about this and it seems to me that there are two
> issues to discuss.
>
> There is a technical issue to resolve, which is whether the WG wants
> to keep RFC5770 solutions as non-obsolete, and how to express these
> options to future implementers.  I had thought that the WG position
> was to drop support for STUN-based solutions, but you are suggesting
> now to keep it active, perhaps as a MAY implement?   It seems to me
> that the basic UDP-ENCAPSULATION mode should still be kept mandatory
> since it is the basis for the other approach and is useful by
> itself.
 >
> Then there is the editorial issue about how to meet IETF guidelines
> on how things are cross-referenced and use of informative/normative
> references, which seems to me risky at the moment (i.e., I am
> anticipating a downstream reviewer expressing this same concern).
> Plus there is the goal of making it clearer to implementers.

trying to recap your complete opinion... do you think the 
UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And RFC5770 
MAY? Or do you think the draft should just deprecate RFC5770?

Btw, RFC5770 is still a normative reference because we are redundantly 
explaining some parts of the RFC in the draft.