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

Gonzalo Camarillo <> Wed, 24 February 2016 14:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 557D81B3058 for <>; Wed, 24 Feb 2016 06:26:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.201
X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pF9XMyshX49o for <>; Wed, 24 Feb 2016 06:26:44 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 008631B302E for <>; Wed, 24 Feb 2016 06:26:43 -0800 (PST)
X-AuditID: c1b4fb3a-f79ce6d000005138-a8-56cdbda20f65
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id EA.D6.20792.2ADBDC65; Wed, 24 Feb 2016 15:26:42 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 24 Feb 2016 15:26:41 +0100
To: Tom Henderson <>,,
References: <>
From: Gonzalo Camarillo <>
Message-ID: <>
Date: Wed, 24 Feb 2016 16:26:41 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="iso-8859-15"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM2K7qO6ivWfDDI5eF7SYumgys8XM8wfZ HJg8liz5yeTRcj0mgCmKyyYlNSezLLVI3y6BK2Pe8uWMBZ3SFYu3fmZsYLwi2sXIySEhYCIx Z38jE4QtJnHh3nq2LkYuDiGBw4wS83b9gXJWM0r0dZ9jB6kSFrCXOLnvFpgtIpAi0Xl9KVi3 kICnxJ9Jn4EaODiYBUQlts+qAgmzCVhIbLl1nwXE5hXQluh9dYoNxGYRUJW4vmQSM4gtKhAj cbHzCBNEjaDEyZlPwOo5BbwkLmw/ARZnFtCXWN1wgA3Clpdo3jqbGWKttsTyZy0sExgFZyFp n4WkZRaSlgWMzKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYxAoP14JbfVjsYDz53PMQowMGo xMNb8ORMmBBrYllxZe4hRgkOZiUR3rhpZ8OEeFMSK6tSi/Lji0pzUosPMUpzsCiJ865xXh8m JJCeWJKanZpakFoEk2Xi4JRqYFzbrRgg2Kzqvm/aIz+HdxsKQ/5/kvC+MetzxnY+1qP5mWvu 7Nhr+NvryY9w02N8NxQ7F+3OfVm/7pR9dL9dzPH6u3ocD5xmBH9ibvz+/VCUtPgJ6QvGE/95 /LS+pxGeMl89ZNfKXO31q/f1VL9z2nz//nz23VzekY7XF5u8PPVN7lX977VJ9heVWIozEg21 mIuKEwEY/zNoUgIAAA==
Archived-At: <>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
X-Mailman-Version: 2.1.15
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, 24 Feb 2016 14:26:46 -0000

Hi Tom,

I agree it is better to separate both questions: the right thing to do
from a technical point of view and how to document it.

Let's focus on doing the right thing, regardless of what each of you
think the group agreed to do years ago. What are the pros and cons of
obsoleting the old STUN-based approach?



On 23/02/2016 4: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.
> - Tom