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

Miika Komu <> Wed, 29 June 2016 19:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 338D512DDD0 for <>; Wed, 29 Jun 2016 12:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F_7AVJFk2Wn2 for <>; Wed, 29 Jun 2016 12:01:46 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9C8A212D9FF for <>; Wed, 29 Jun 2016 12:01:31 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-b3-57741b09ac63
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 24.58.12516.90B14775; Wed, 29 Jun 2016 21:01:30 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 29 Jun 2016 21:01:29 +0200
References: <>
From: Miika Komu <>
Organization: Ericsson AB
Message-ID: <>
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: <>
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: <>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Jun 2016 19:01:49 -0000


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