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

Miika Komu <> Mon, 29 February 2016 14:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2C5321B3281 for <>; Mon, 29 Feb 2016 06:41:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id w-v4GgC54gtS for <>; Mon, 29 Feb 2016 06:41:29 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E35581B3280 for <>; Mon, 29 Feb 2016 06:41:28 -0800 (PST)
X-AuditID: c1b4fb2d-f79836d000006396-9c-56d45896e63b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A4.76.25494.69854D65; Mon, 29 Feb 2016 15:41:26 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 29 Feb 2016 15:41:25 +0100
References: <> <> <> <>
From: Miika Komu <>
Organization: Ericsson AB
Message-ID: <>
Date: Mon, 29 Feb 2016 16:41:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms090604090806030705010009"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2J7lO60iCthBmc6xSymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDm7+5kL3llWHHvQx9rAuNysi5GTQ0LAROL2r10sELaYxIV7 69m6GLk4hAQOM0p03+plhXBWM0ocvb4FrEpYwF7i5L5b7CC2iICoxJQPp5lBbCGB04wSn6+6 gdhsAloSq+5cB4vzC0hKbGjYDWbzCmhL/JoLMpSTg0VAVWLm3ItMILaoQITE4c4udogaQYmT M5+A7eIU0JG4/ns22BHMAt2MEj33lwI5HEDLVCQuHguewCgwC0nLLGRlIAlmAVuJO3N3M0PY 2hLLFr6Gsq0lZvw6yAZhK0pM6X7IDmGbSrw++pERwjaWWLbuL9sCRo5VjKLFqcXFuelGxnqp RZnJxcX5eXp5qSWbGIHhf3DLb90djKtfOx5iFOBgVOLh3eB8OUyINbGsuDL3EKMK0JxHG1Zf YJRiycvPS1US4V3neSVMiDclsbIqtSg/vqg0J7X4EKM0B4uSOC/bJ6BOgfTEktTs1NSC1CKY LBMHp1QD45SAmXM7ptczyRrVTnvCeOLUlzLt9kmMW1R6Zlf5pVbcMO8+dKT6xc77tm5C147b bLBpFEx+151jf2TOi7nJDjWTj+hyyu/31dP9XnetmWHBD++DM05EBH7aJODCMpmHdWeJ87Pl UaoeRi29+Vu3u63r6tWfe6np5scjtWufeE5hFSm0e5N/TImlOCPRUIu5qDgRAG8VVKmHAgAA
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: Mon, 29 Feb 2016 14:41:31 -0000


On 02/27/2016 10:49 AM, Gonzalo Camarillo wrote:
> Hi Jeff,
> thanks for your feedback.
>> Regarding pros/cons:
>> How widely-deployed is STUN/TURN? Are public servers widespread?
> there are several of them. They are mostly used for VoIP. You can google
> for "public stun turn servers" or something similar. There are a few
> lists out there.

I guess the situation is like this:

HIP control plane relay:
* new critical infrastructure that needs to be deployed anyway (TURN 
server cannot be used for this)

Gathering of address candidates:
* from a STUN server (many available)
* ...or from control plane relay registration (which is mandatory anyway)

Data plane relay:
* using TURN server (it seems some are available)
* ...or using the ESP relay as specified in native NAT spec (none 
deployed, but I guess could co-locate with the HIP control plane relay)

So, the critical part are the HIP control plane relays which provide 
also similar functionality as STUN servers (i.e. provide server 
reflexive candidates). So I guess the question boils down to the 
availability of TURN servers.

P.S. Nothing really prevents to use STUN servers to discover address 
candidates in the native NAT traversal version. The discovery process is 
independent of the NAT penetration process.