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

Miika Komu <> Wed, 29 June 2016 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F323B12D0C0 for <>; Wed, 29 Jun 2016 11:41:17 -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 2-LbrzuEMkeZ for <>; Wed, 29 Jun 2016 11:41:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D40D612D611 for <>; Wed, 29 Jun 2016 11:41:14 -0700 (PDT)
X-AuditID: c1b4fb3a-f79386d00000467b-9e-577416484779
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 51.66.18043.84614775; Wed, 29 Jun 2016 20:41:13 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 29 Jun 2016 20:41:12 +0200
References: <> <> <>
From: Miika Komu <>
Organization: Ericsson AB
Message-ID: <>
Date: Wed, 29 Jun 2016 21:41:11 +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="------------ms000907040700060101000206"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM2J7iK6nWEm4wf9f3BZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoW/S1kL/jhXrG75zN7AuM2ui5GTQ0LAROJE/18mCFtM4sK9 9WxdjFwcQgJHGCWeXPvDCuGsZJR49/0UC0iVsIC9xMl9t9hBbBEBUYkpH04zQxR1M0rsnLKL FSTBJqAlserOdWYQm19AUmJDw24wm1dAW2L9m1lgNouAqsTCs58ZQWxRgQiJWdt/MEHUCEqc nPkEbBmngI7EuhX7wZYxgyy4dEG7i5EDaJmKxMVjwRMYBWYh6ZiFpArCtpW4M3c3M4StLbFs 4Wso21pixq+DbBC2osSU7ofsELapxOujHxkhbGOJZev+si1g5FjFKFqcWlycm25kpJdalJlc XJyfp5eXWrKJERj8B7f8ttrBePC54yFGAQ5GJR7eBTwl4UKsiWXFlbmHGFWA5jzasPoCoxRL Xn5eqpIIb6QwUJo3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vFcCGB9MSS1OzU1ILUIpgsEwen VAPj9KkNLDx7K+19Gz9LGd6YcSSveFPntObFk1QPv7rfkcp9xWEmu9YyvTmSpreqv6xomR3V /K/m0wFBDoVrRS1Xo3infDrY/zOoZVsYe87spkWK7IwJn/MyvZ/dsTLhvbozqSPX5MAGT1lH psjqfz0Hn8X83t/x2UVK3sdy/qxji03F2tkeR0grsRRnJBpqMRcVJwIAaABxyIYCAAA=
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 18:41:18 -0000


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.

the draft does not replace RFC5770, but offers a parallel/independent 
way to implement NAT traversal. UDP-ENCAPSULATION mode is 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.

You're right, and new ICE (rfc5245bis) is now 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.

The draft has been improved radically from the viewpoint of readability 
and it is more independent from RFC5770. The old draft is somehow more 
mature in the sense that it has been implemented and successfully 
interoperated. However, it is based on the old ICE specification that is 
going to be deprecated this year.