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

Miika Komu <> Fri, 01 July 2016 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2485F12D671 for <>; Fri, 1 Jul 2016 07:48:40 -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 IOsxGP_PJn6g for <>; Fri, 1 Jul 2016 07:48:38 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DBE112B00A for <>; Fri, 1 Jul 2016 07:48:34 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-11-577682c00d23
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B0.E0.12516.0C286775; Fri, 1 Jul 2016 16:48:32 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 1 Jul 2016 16:48:21 +0200
References: <>
From: Miika Komu <>
Organization: Ericsson AB
Message-ID: <>
Date: Fri, 01 Jul 2016 17:48:21 +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="------------ms070209040406000308080105"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyM2K7nO6BprJwg7/7tC2mLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPX9TcwFvxwrmld+ZGtgvGHTxcjJISFgIrHg8gcWCFtM4sK9 9WxdjFwcQgJHGCWunj/CAuGsYpTYeOo+WJWwgL3EyX232EFsEQFRiSkfTjN3MXIAFXlKTHzn CBJmE9CSWHXnOjOIzS8gKbGhYTeYzSugLbHkRz8biM0ioCLReOILmC0qECExa/sPJogaQYmT M5+AreIU8JKY2/mcFcRmFuhmlNj8rg5ilYrExWPBExgFZiHpmIWkCsK2lbgzdzczhK0tsWzh ayjbWmLGr4NsELaixJTuh+wQtqnE66MfGSFsY4ll6/6yLWDkWMUoWpxaXJybbmSsl1qUmVxc nJ+nl5dasokRGPgHt/zW3cG4+rXjIUYBDkYlHt4F50rDhVgTy4orcw8xqgDNebRh9QVGKZa8 /LxUJRFe9caycCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTByc Ug2MvbOW7zr/yDm9Ojz8R77g8q/qjh9dnlVye7yYwhIX9P1cm8/yjpu2i3/yHmN9Unr3pazS sovrL/6JqA4wq7CqEXe+Etww6WzrtGcCcnk/nz5+vefwuUfKie1M1qod20+kxtVufHjKSe/F Lplw5tCpNuecXTNf3VDUf7v7/6o1B5gjpzv5X1F4pcRSnJFoqMVcVJwIAEC0T8WEAgAA
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: Fri, 01 Jul 2016 14:48:40 -0000


On 06/30/2016 08:44 AM, Tom Henderson wrote:
> Hi Miika,
>> trying to recap your complete opinion... do you think the
>> RFC5770 MAY? Or do you think the draft should just deprecate
>> RFC5770?
> I think that UDP-ENCAPSULATION should be a MUST option because that
> option is sufficient if the implementation does not have to deal with
> inbound connections.

Ok. Btw, you mean "Responder" by inbound? I think you're referring to 
this section:

> ICE-HIP-UDP should be a MUST for implementations that wish to support
> inbound, and I don't think that RFC5770 solutions for inbound should
> be suggested as options.

Added the following to the NAT Traversal Mode Parameter" section:

"Implementations conforming to this specification MUST implement both

> Maybe the use of STUN servers for candidate
> gathering is fine as a MAY since it doesn't affect HIP
> interoperability, but otherwise, why suggest to support two parallel
> implementations for the same function?

A host behind a NAT will need a HIP relay anyway which can provide STUN 
functionality. The draft currently says:

    Gathering of candidates MAY also be performed as specified in
    Section 4.2 of [RFC5770] if STUN servers are available, or if the
    host has just a single interface and no TURN or HIP data relay
    servers are available.

Do you want this to be removed or is it ok?

> I would be fine with making an allowance for RFC5770 implementations
> to live on as an option; by this I mean to not overwrite RFC5770
> codepoints, etc. but stop short of suggesting it as a MAY in this
> document.

The draft does not reference RFC5770 as MAY implement. The current draft 
is completely a parallel to the RFC, and is described in a 
self-sufficient way.

>> Btw, RFC5770 is still a normative reference because we are
>> redundantly explaining some parts of the RFC in the draft.
> I still believe that it would be better if this draft did not depend
> on reading RFC5770.

It doesn't anymore. RFC5770 is mostly referenced because some parameters 
are borrowed from there, but are always redundantly described in the draft.