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, 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: <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.
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Tom Henderson
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal Gonzalo Camarillo
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Gonzalo Camarillo
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Ari Keränen
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Ari Keränen
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Tom Henderson
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Tom Henderson
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Gonzalo Camarillo
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Jeff Ahrenholz
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Gonzalo Camarillo
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Gonzalo Camarillo
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Derek Fawcus
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Gonzalo Camarillo
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Ari Keränen
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Miika Komu
- Re: [Hipsec] WGLC: draft-ietf-hip-native-nat-trav… Gonzalo Camarillo