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

Miika Komu <miika.komu@ericsson.com> Fri, 01 July 2016 14:48 UTC

Return-Path: <miika.komu@ericsson.com>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2485F12D671 for <hipsec@ietfa.amsl.com>; Fri, 1 Jul 2016 07:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IOsxGP_PJn6g for <hipsec@ietfa.amsl.com>; Fri, 1 Jul 2016 07:48:38 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBE112B00A for <hipsec@ietf.org>; Fri, 1 Jul 2016 07:48:34 -0700 (PDT)
X-AuditID: c1b4fb2d-f79936d0000030e4-11-577682c00d23
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B0.E0.12516.0C286775; Fri, 1 Jul 2016 16:48:32 +0200 (CEST)
Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.294.0; Fri, 1 Jul 2016 16:48:21 +0200
To: <hipsec@ietf.org>
References: <alpine.LRH.2.01.1606292244590.18841@hymn04.u.washington.edu>
From: Miika Komu <miika.komu@ericsson.com>
Organization: Ericsson AB
Message-ID: <577682B5.7090008@ericsson.com>
Date: Fri, 1 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: <alpine.LRH.2.01.1606292244590.18841@hymn04.u.washington.edu>
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: <https://mailarchive.ietf.org/arch/msg/hipsec/Y5WTFcwXkn8hUHnt4PCwWusBvLo>
Subject: Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2016 14:48:40 -0000

Hi,

On 06/30/2016 08:44 AM, Tom Henderson wrote:
> Hi Miika,
>
>>
>> trying to recap your complete opinion... do you think the
>> UDP-ENCAPSULATION should be MUST and ICE-HIP-UDP SHOULD? And
>> 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:

https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-12#section-4.7.2

> 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
UDP-ENCAPSULATION and ICE-HIP-UDP modes."

> 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.