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

Jeff Ahrenholz <> Fri, 26 February 2016 15:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2CDF01A9240 for <>; Fri, 26 Feb 2016 07:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Le_aymw4TJ8X for <>; Fri, 26 Feb 2016 07:48:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6308E1A923A for <>; Fri, 26 Feb 2016 07:48:10 -0800 (PST)
Received: from ( by MBX081-W5-CO-1 ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 26 Feb 2016 07:48:08 -0800
Received: from ([]) by ([]) with mapi id 15.00.1130.005; Fri, 26 Feb 2016 07:48:08 -0800
From: Jeff Ahrenholz <>
To: Gonzalo Camarillo <>, Tom Henderson <>, "" <>, "" <>
Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
Thread-Index: AQHRbkOgfoNu5ryIFEuihd2cfTcswZ87yFaAgAK1TwA=
Date: Fri, 26 Feb 2016 15:48:08 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
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: Fri, 26 Feb 2016 15:48:12 -0000

Hi all,
We’ve been discussing the NAT traversal approaches here at Tempered Networks (Seattle-based company using HIP to build secure overlays between customer networks.) We like the native HIP-based approach proposed in draft-ietf-hip-native-nat-traversal. Mostly due to the simplicity of implementing this — by extending existing HIP messages versus using the ICE/STUN/TURN machinery.

We currently use UDP encapsulation of HIP and IPsec, so to implement the native NAT-traversal draft, it may be a matter of supporting the control/data relaying server. We may implement this some time in the future.

Regarding pros/cons:
How widely-deployed is STUN/TURN? Are public servers widespread?

Jeff Ahrenholz
Jeff Costlow
Orlie Brewer

On 2/24/16, 6:26 AM, "Hipsec on behalf of Gonzalo Camarillo" < on behalf of> wrote:

>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
>Hipsec mailing list