From nobody Mon Apr 10 04:26:08 2017 Return-Path: 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 0A27F12948B for ; Mon, 10 Apr 2017 04:26:07 -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 Sdkant9bk_de for ; Mon, 10 Apr 2017 04:26:05 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007BA129492 for ; Mon, 10 Apr 2017 04:26:04 -0700 (PDT) X-AuditID: c1b4fb25-c27a798000006af2-8f-58eb6bcb543f Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 0E.7A.27378.BCB6BE85; Mon, 10 Apr 2017 13:26:03 +0200 (CEST) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.339.0; Mon, 10 Apr 2017 13:26:02 +0200 To: Jeff Ahrenholz , "hipsec@ietf.org" References: <149060027598.7984.1316463177816365455@ietfa.amsl.com> <06cb187b-4741-5115-498f-6b67bdcba084@ericsson.com> <73B2E25D-4444-46ED-8428-D07DBB9F22AC@temperednetworks.com> From: Miika Komu Organization: Ericsson AB Message-ID: Date: Mon, 10 Apr 2017 14:26:02 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <73B2E25D-4444-46ED-8428-D07DBB9F22AC@temperednetworks.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUyM2K7h+7p7NcRBjMmSVpMXTSZ2aJ1yk1m ByaPJUt+Mnls3dPJEsAUxWWTkpqTWZZapG+XwJVxZuYbxoJ1EhWXelkbGM8KdjFycEgImEg8 /STexcjFISSwnlFi0satTBDOGkaJP6tnMXcxcnIIC/hIPD8ylR3EFhGIkbg4bw0LRNE2Rom1 b9aygiTYBLQkVt25DtbALyApsaFhNzPIBl4Be4nXM8BKWARUJe6ePAQ2R1QgQuJh5y4wm1dA UOLkzCcsIDangIfE/ysLwMYwC1hIzJx/nhHC1pZYtvA12EghARWJi8eCJzAKzELSPQtJxywk HQsYmVcxihanFiflphsZ66UWZSYXF+fn6eWllmxiBIbkwS2/VXcwXn7jeIhRgINRiYf3wbpX EUKsiWXFlbmHGCU4mJVEeLtWAIV4UxIrq1KL8uOLSnNSiw8xSnOwKInzOu67ECEkkJ5Ykpqd mlqQWgSTZeLglGpgzFyXX35L5SjfvSs6AWkbHR9G2VhLSU97m3va0nF1hdmpySlZBhvmR652 87Ffo3XD+vM1RhXTLXtLfxpd2Gu45L68pfL17vD0CVIJp78slggOndTOP0Fw8pcSJ3MBDtNM 7varEj0PNM99LTZSOh4eZdfQoC/+ofE2zyOrvVtMU7RKGs/tOVqsxFKckWioxVxUnAgALQa2 mUUCAAA= Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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, 10 Apr 2017 11:26:07 -0000 Hi Jeff, thanks, good catch. This change will be in the next version. On 03/28/2017 06:11 PM, Jeff Ahrenholz wrote: > Hi Miika, > The new paragraph on keepalives (Section 5.3) looks good. > > For the NOTIFY code, NAT_KEEPALIVE value (=E2=80=9CTBD by IANA: 16384=E2= =80=9D) maybe suggest 16385? ...since we already have =E2=80=9CI2_ACKNOWL= EDGEMENT 16384=E2=80=9D in RFC 5201 and RFC 7401. > > thanks, > -Jeff > > On 3/27/17, 12:41 AM, "Hipsec on behalf of Miika Komu" wrote: > > Hi, > > the preliminary version is now published as it is (except I had to > change publication the date). The suggestions from Christer are not= yet > here and will require some time to be fixed. > > On 03/27/2017 10:37 AM, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Draft= s directories. > > This draft is a work item of the Host Identity Protocol of the IE= TF. > > > > Title : Native NAT Traversal Mode for the Host = Identity Protocol > > Authors : Ari Keranen > > Jan Mel=C3=A9n > > Miika Komu > > Filename : draft-ietf-hip-native-nat-traversal-19.txt > > Pages : 53 > > Date : 2017-03-27 > > > > Abstract: > > This document specifies a new Network Address Translator (NAT)= > > traversal mode for the Host Identity Protocol (HIP). The new = mode is > > based on the Interactive Connectivity Establishment (ICE) meth= odology > > and UDP encapsulation of data and signaling traffic. The main= > > difference from the previously specified modes is the use of H= IP > > messages for all NAT traversal procedures. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traver= sal/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-1= 9 > > https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-t= raversal-19 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-tra= versal-19 > > > > > > Please note that it may take a couple of minutes from the time of= submission > > until the htmlized version and diff are available at tools.ietf.o= rg. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > https://www.ietf.org/mailman/listinfo/hipsec > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > > From nobody Tue Apr 25 04:05:42 2017 Return-Path: X-Original-To: hipsec@ietf.org Delivered-To: hipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E474F12EBB9; Tue, 25 Apr 2017 04:05:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: hipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149311833389.6988.1171409574524350946@ietfa.amsl.com> Date: Tue, 25 Apr 2017 04:05:33 -0700 Archived-At: Subject: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-20.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 25 Apr 2017 11:05:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Host Identity Protocol of the IETF. Title : Native NAT Traversal Mode for the Host Identity Protocol Authors : Ari Keranen Jan Melén Miika Komu Filename : draft-ietf-hip-native-nat-traversal-20.txt Pages : 56 Date : 2017-04-25 Abstract: This document specifies a new Network Address Translator (NAT) traversal mode for the Host Identity Protocol (HIP). The new mode is based on the Interactive Connectivity Establishment (ICE) methodology and UDP encapsulation of data and signaling traffic. The main difference from the previously specified modes is the use of HIP messages for all NAT traversal procedures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-20 https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traversal-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-native-nat-traversal-20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 25 04:50:53 2017 Return-Path: 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 937A012EC3E for ; Tue, 25 Apr 2017 04:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 CDYP6P_0rpMn for ; Tue, 25 Apr 2017 04:50:51 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B754A12EC3C for ; Tue, 25 Apr 2017 04:50:50 -0700 (PDT) X-AuditID: c1b4fb25-2b64e98000004efc-0d-58ff37cdec80 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id E7.92.20220.DC73FF85; Tue, 25 Apr 2017 13:49:33 +0200 (CEST) Received: from [131.160.51.186] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.3.339.0; Tue, 25 Apr 2017 13:47:24 +0200 To: References: <149311833389.6988.1171409574524350946@ietfa.amsl.com> From: Miika Komu Organization: Ericsson AB Message-ID: <0744a2be-4100-e7dc-57df-02823b024542@ericsson.com> Date: Tue, 25 Apr 2017 14:47:25 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149311833389.6988.1171409574524350946@ietfa.amsl.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM2J7oO5Z8/8RBqvf61tMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGYdmvWcpmCRQsX/FCtYGxsM8XYycHBICJhI7Fp9kArGFBNYz Smy/7dPFyAVkr2GUON10hx0kISzgI7Hr8lM2EFtEQFRiyofTzBANThLHDrwDs9kEtCRW3bkO ZvMLSEpsaNgNZvMK2Evs3PwNbA6LgKrE2dVPwOaICkRIPOzcxQ5RIyhxcuYTFhCbU8BZ4saL uawgNrOAhcTM+ecZIWxtiWULXwPN5ADaqyJx8VjwBEaBWUi6ZyHpmIWkYwEj8ypG0eLU4qTc dCNjvdSizOTi4vw8vbzUkk2MwAA8uOW36g7Gy28cDzEKcDAq8fA+YPkXIcSaWFZcmXuIUYKD WUmE9xJIiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBsag X9MuMxlP390yr6ZH+Mnmd/F7a9jvHq1wUjogIW/2TXuT/HHlnnAnfq4j/z4sz4hs9fM6/JfT /zTLvV+XOysWHq6YPq9RYtv1oIP1T45em7NjyT6RkqCwMH+fCOb/gc+urv0448G/2Z1pL9ac ma9t9ONigJfTdt51Ovlz2W3uSB1pXiQtIMypxFKckWioxVxUnAgAW6nahDwCAAA= Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-20.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 25 Apr 2017 11:50:52 -0000 Hi, this version addresses Christer's earliers comments and fixes some other = issues I discovered while reviewing the draft. I'll send a summary of=20 the comments a bit later. On 04/25/2017 02:05 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the Host Identity Protocol of the IETF. > > Title : Native NAT Traversal Mode for the Host Identi= ty Protocol > Authors : Ari Keranen > Jan Mel=C3=A9n > Miika Komu > Filename : draft-ietf-hip-native-nat-traversal-20.txt > Pages : 56 > Date : 2017-04-25 > > Abstract: > This document specifies a new Network Address Translator (NAT) > traversal mode for the Host Identity Protocol (HIP). The new mode i= s > based on the Interactive Connectivity Establishment (ICE) methodolog= y > and UDP encapsulation of data and signaling traffic. The main > difference from the previously specified modes is the use of HIP > messages for all NAT traversal procedures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-20 > https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-travers= al-20 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversal= -20 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Tue Apr 25 06:04:53 2017 Return-Path: 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 90B51126557 for ; Tue, 25 Apr 2017 06:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 sy1IieKoQ_wj for ; Tue, 25 Apr 2017 06:04:48 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 793701294E6 for ; Tue, 25 Apr 2017 06:04:47 -0700 (PDT) X-AuditID: c1b4fb30-1aff698000002705-43-58ff496de074 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 3E.C5.09989.D694FF85; Tue, 25 Apr 2017 15:04:45 +0200 (CEST) Received: from [100.94.2.41] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.339.0; Tue, 25 Apr 2017 15:04:44 +0200 From: Miika Komu To: References: <7594FB04B1934943A5C02806D1A2204B4CB2C90B@ESESSMB109.ericsson.se> Organization: Ericsson AB Message-ID: Date: Tue, 25 Apr 2017 16:04:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB2C90B@ESESSMB109.ericsson.se> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2K7tG6u5/8Ig9+f1CymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujB27v7MWdGdVnF91i7mBcXZwFyMnh4SAicSiNx2sXYxcHEIC 6xkldh5cygLhrGSU+LnvJhtIFZuAlsSqO9eZuxg5OIQFnCU2TvcGCYsIiEpM+XAaLCwk4Ctx fJUOSJhfQFJiQ8NuZhCbV8BeYs6EuUwgNouAqsSexT/AJooKREg87NzFDlEjKHFy5hMWEJtT wE/iyoNJrCAjmYF6H2wtAwkzC2hLLFv4GmqTisTFY8ETGAVmIWmehdAwC0nDAkbmVYyixanF SbnpRkZ6qUWZycXF+Xl6eaklmxiBoXdwy2+DHYwvnzseYhTgYFTi4X3A8i9CiDWxrLgy9xCj BAezkgjvVsn/EUK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfddiBASSE8sSc1OTS1ILYLJMnFw SjUwltqe5ZuSuWOFmnngrYZPm5/u83n47NXkinqtho5/2os++ER/KHhetmV+Uv2D30pCp6/8 +nRv/9O97o7+R2pCZ2lwvLeIzst8b70sZeKqMHvmNwsvq57eaNaxovrO1xvsRqXaPJKZvyIX 2b1lnmq5K3fGzihmgxwffhe9w7v2rpevsfr+d0PeSyWW4oxEQy3mouJEAAdaLHg5AgAA Archived-At: Subject: Re: [Hipsec] Comments on draft-hip-native-nat-traversal-19 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 25 Apr 2017 13:04:51 -0000 Hi Christer, On 03/26/2017 02:34 AM, Christer Holmberg wrote: > Hi, > > As co-author for the ICEbis draft, I was asked to review > draft-hip-native-nat-traversal-19. > > I have not had time to review the whole document. However, many of my > comments are generic, and apply to the whole document. thanks for the feedback! Your (editorial) comments should be addressed=20 in this version: https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-20 The diff is here: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversal-2= 0 > I have no knowledge of HIP, so I will not comment on HIP issues like > messages, parameters etc used. If one implements this, some digging into the HIP documents is needed.=20 From a design perspective, the document should be readable as it is (I=20 hope). > General: =3D=3D=3D=3D=3D=3D=3D > > QG0: Throughout the document, you use RFC 2119 terminology (SHOULD, > MUST etc with capital letters) when you refer to procedures and rules > defined elsewhere. I think that is wrong, and it also makes it very > difficult what exactly is defined in this document, and what is > defined in some other specification. I am keeping the SHOULD/MUST/etc for HIP documents (since this is an=20 extension of HIP) but ICE references are now with small letters (there=20 actually weren't too many). > QG1: You say that the mechanism in the draft is based on ICE. I think > it would be good to give a name to the mechanism. "HIP-ICE", or > something similar. Done: ICE: Interactive Connectivity Establishment (ICE) protocol as specified= in [I-D.ietf-ice-rfc5245bis] Legacy ICE-HIP: Refers to the "Basic Host Identity Protocol (HIP) Extensions for Traversal of Network Address Translators" as specified in [RFC5770]. The protocol specified in this document offers an alternative to Legacy ICE-HIP. Native ICE-HIP: The protocol specified in this document (Native NAT Traversal Mode= for HIP). > QG2: I would also like to have a dedicated section which on a > high-level describes the differences/restrictions between legacy ICE > and HIP-ICE. It helps very much when later reading the details in > section 4. That section should at least list the different types of > functions (HIP relays etc) are used for gathering candidates, what > protocol (HIP messages) is used instead of STUN, what types of > candidates are used and how they are retrieved. The ICE comparison has been already in the previous version in Appendix=20 B ("Differences with respect to ICE") and now the intro also references=20 this section ("Appendix B explains the differences to ICE."). I think=20 it's not good to start the document with a diff to ICE. We have to=20 assume that the reader is familiar with HIP since this is an extension=20 to it. > It would also be good to give a short overview of the HIP messages > used for the connectivity checks. It is very useful when later > reading the details. The intro now includes a really short intro to HIP, but I don't think we = should introduce the messaging formats here again. This is an extension=20 to HIP, so some familiarity with HIP is required. (Btw, the ICE specification does not describe STUN/TURN messaging=20 formats either, so the situation is the same for that document) > QG3: You should use consistent terminology when you talk about > endpoints and relays. Sometimes the text says "host", sometimes "HIP > relay server client", sometimes "relay client", sometimes > "end-host". Sometimes you say "HIP relay", sometimes "HIP server > relay", etc. Sometimes you say "non-relay host", which suggests that > the relay is also a host. the document has over 300 occurrences of host, could you be a bit more=20 specific where this is a problem? "End-host" means "non-relay host", and = yes, a relay is a host too. I agree the client/server relay terminology was a bit sloppily used. In=20 general, I think the terms were a bit asymmetrical: * HIP vs. data relay, why not just "control" and "data" * HIP relay vs HIP relay client (why not HIP relay *server*) So I came up with a better relay terminology that is now applied=20 consistently throughout the document: Control Relay Client: A requester host that registers to a Control Relay Server requesting it to forward control-plane traffic (i.e. HIP control messages). In the Legacy ICE-HIP specification, this is denoted as "HIP Relay Client". Data Relay Server: A registrar host that forwards HIP related data plane packets, such as Encapsulating Security Payload (ESP) [RFC7402], between two hosts. This host implements similar functionality as TURN servers. Data Relay Client: A requester host that registers to a Data Relay Server requesting it to forward data-plane traffic (e.g. ESP traffic). > Section 3: =3D=3D=3D=3D=3D=3D=3D=3D > > Q30: The text says: > > "The hosts may use HIP relay servers (or even STUN or TURN servers) > for gathering the candidates." > > This is confusing, as you have earlier said that HIP-ICE doesn't use > STUN. > > (Implementations may of course provide both STUN- and HIP > functionality, but that is outside the scope of the document.) I hope this is now better: Gathering of candidates MAY also be performed by other means than described in this section. For example, the candidates could be gathered as specified in Section 4.2 of [RFC5770] if STUN servers are= available, or if the host has just a single interface and no STUN or Data Relay Server are available. How the candidates are gathered does not really affect interoperability. > Q31: The text says: > > "To be contacted from behind a NAT, the Responder must be registered > with a HIP relay server reachable on the public Internet, and we > assume, as a starting point, that the Initiator knows both the > Responder's Host Identity Tag (HIT) and the address of one of its > relay servers=94 > > First, when you say "its relay servers", I assume you mean the relay > servers of the Responder? yes > Second, doesn't the Initiator need to know the address of the relay > to which the Responder is actually registered, in case there are > multiple relays but the Responder is not registered with all of > them? Maybe someone thinks it's obvious, but I think it should be > make clear. > > Could you simply say: > > "To be contacted from behind a NAT, the Responder must be registered > > with a HIP relay server reachable on the public Internet. It is > assumed that > > the Initiator knows the address of the relay server(s) to which the > Responder > > is registered." The text is now a bit rearranged, but this is now changed as follows: To be contacted from behind a NAT, at least the Responder must be registered with a Control Relay Server= reachable on the public Internet. [..] We assume, as a starting point, that the Initiator knows both the Responder's Host Identity Tag (HIT) and the address(es) of the Responder's Control Relay Server(s) (how the Initiator learns of the Responder's Control Relay Server is outside of the scope of this document, but may be through DNS or another name service). > Q32: The section introduces the "base exchange" concept, but it is > not clearly defined. Is it something defined in HIP, is it HIP-ICE > specific? I think you should add a description/reference somewhere. Defined in HIP and briefly now introduced and referenced in the=20 introduction. > Q33: The text says: > > "At the end of the procedure, if successful, the hosts will have > established a > > UDP-based tunnel that traverses both NATs, with the data flowing > directly from NAT to NAT or via a HIP data relay server." > > What if the responder has only registered to a HIP server relay? The > text in the section seems to suggest that it is optional to register > to a data relay. > > The text needs to be more clear on whether the endpoints need to > register to a server relay and/or data relay. I think this should be clear now: The Responder may have also registered to a Data Relay Server that can forward the data plane in case NAT penetration fails. [..] To be contacted from behind a NAT, *at least* the Responder must be registered with a Control Relay Server reachable on the public Internet. [..] Relayed candidates SHOULD be gathered in order to guarantee successful NAT traversal, and implementations SHOULD support this functionality even if it will not be used in deployments in order to enable it by software configuration update if= needed at some point. > Section 4.2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Q421: In general, I think it would be useful to split the section > into HIP client procedures and HIP relay server procedures. Actually now the section just includes client procedures, so I changed=20 the name. > Q422: I think the following text should be in the beginning of the > section: > > "ICE guidelines for candidate gathering MUST be followed as described > in section 4.1.1 in [I-D.ietf-ice-rfc5245bis]. A number of host > candidates (loopback, anycast and others) should excluded as > described in section 4.1.1.1 of the ICE specification > [I-D.ietf-ice-rfc5245bis]." I think moving this text does not improve readability of the section, so = I didn't do this. Currently, there is some intro text before this. > Q423: The text says: > > "However, if no data relay is used, and the host has only a single > local IP address to use, the host MAY use the local address as the > only host candidate" > > I am not sure what is meant by "as the only host candidate". So if the host has no clue on the server reflexive/relayed addresses, it = should use the address as seen from the network interface as the (only)=20 host candidate. I change this if needed if some other wording works bette= r? > Q424: The text says: > > "Relayed candidates SHOULD be gathered in order to guarantee > successful NAT traversal. It is RECOMMENDED for implementations to > support this functionality" > > If you say SHOULD use, why do you then only say RECOMMEND support? > Doesn't the support need to be stronger than the usage? Fixed, both are now SHOULD. > Q425: The text says: > > "Unlike ICE, this protocol only creates a single UDP flow between > the two communicating hosts, so only a single component exists." > > This is confusing. What is meant by "unlike ICE"? You are using ICE > :) I assume you are referring to ICE usage for non-multiplexed > RTP/RTCP? ICE is now defined in the terminology (I-D.ietf-ice-rfc5245bis) > I think you simply need to say that HIP only uses a single UDP flow, > using a single component, with a value of 1. I can remove the ICE comparison if this is still confusing... Unlike ICE, this protocol only creates a single UDP flow between the two communicating hosts, so only a single component exists. Hence, the component ID value MUST always be set to 1. > Section 4.3: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Q431: The text says: > > "This section describes the usage of a new non-critical parameter > type." > > Shouldn't it say that the section defines a new parameter type? No, just the usage. The actual format/definitions are in section 5. > Q432: If I understand correctly, the NAT mode negotiation between an > endpoint and a relay takes place during registration. yes. Registration =3D base exchange with some registration parameters. > But, when does the NAT mode negotiation between two endpoints (shown > in the call flow) take place? During connectivity checks? I think > you should clarify that. During base exchange again, in steps 3-6 as defined in section: 4.5. Base Exchange via Control Relay Server I am not sure what is unclear. > Section 4.6: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Q460:The text says: > > "but UDP encapsulated HIP control messages are used instead of ICE > messages." > > What do you mean by "ICE messages"? STUN? ICE refers to I-D.ietf-ice-rfc5245bis, so yes. I can change this if neede= d. > Section 4.6.2: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Q4620: The text says: > > "The HITs of the two communicating hosts MUST be used as credentials > in this protocol (in contrast to ICE which employs username-password > fragments)." > > Again, "contrast to ICE" sounds confusing, because you are using ICE. > Maybe you should say "legacy ICE", or something similar, when > referring to 5245bis procedures. ICE refers to I-D.ietf-ice-rfc5245bis in the terminology, so let me know = if this is still unclear... > Section 4.7: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Q470: The name of the section ("NAT traversal alternatives") is > confusing, because one may think it talks about something else than > HIP-ICE. > > I would suggest to call it something like "Optimizations". Done. > Section 4.9: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Q490: I think Mobiliy should be described in a separate main > section. The document is structured the same way as the other HIP related RFCs,=20 so all protocol interaction is described in "Protocol Description". From nobody Tue Apr 25 06:06:46 2017 Return-Path: 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 A9052129417 for ; Tue, 25 Apr 2017 06:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 CDcN-5x7Rere for ; Tue, 25 Apr 2017 06:06:44 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E19D126557 for ; Tue, 25 Apr 2017 06:06:40 -0700 (PDT) X-AuditID: c1b4fb25-2b64e98000004efc-d4-58ff49de7ef3 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 49.A4.20220.ED94FF85; Tue, 25 Apr 2017 15:06:38 +0200 (CEST) Received: from [100.94.2.41] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.339.0; Tue, 25 Apr 2017 15:06:31 +0200 To: Christer Holmberg , "hipsec@ietf.org" References: <149060027598.7984.1316463177816365455@ietfa.amsl.com> <06cb187b-4741-5115-498f-6b67bdcba084@ericsson.com> <7594FB04B1934943A5C02806D1A2204B4CB32D46@ESESSMB109.ericsson.se> From: Miika Komu Organization: Ericsson AB Message-ID: <05f6345c-32d6-a9e7-9036-9cc726121c8f@ericsson.com> Date: Tue, 25 Apr 2017 16:06:31 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB32D46@ESESSMB109.ericsson.se> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM2J7lO49z/8RBu9a1CymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFk9W1gKtotV9P/ZyNTAeF2wi5GTQ0LARGL1x2+sXYxcHEIC 6xkl2tffYodwVjJKPFuwlBWkSljAR+L5kansILaIQKzE9Iun2UBsIYE9jBIfmuRAbDYBLYlV d64zg9j8ApISGxp2g9m8AvYSCy6/ZgGxWQRUJTa+ngRmiwpESDzs3MUOUSMocXLmE7A4p4Cf xJrHfUwgNrOAhcTM+ecZIWxtiWULXwPN5ADaqyJx8VjwBEaBWUi6ZyHpmIWkYwEj8ypG0eLU 4qTcdCNjvdSizOTi4vw8vbzUkk2MwBA8uOW36g7Gy28cDzEKcDAq8fA+YPkXIcSaWFZcmXuI UYKDWUmE9xJIiDclsbIqtSg/vqg0J7X4EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6p BsaWkxpMOzc7Gy8UimETYJ29Nd8o61Tdh7faon3MKcf8bL4oCR3LPjhnlsSji2HqF/Xnh66/ dbIxQ053yuLQtenPzy/reHWSt+/LEv+3Qmd2iYUUCB77dj+ZfUMoT02jm7eInteXR+uDL+z9 HLfYTj1M28pVwJZTfnb7WjFV3kUucqu1xd39s5VYijMSDbWYi4oTAd8FGwA9AgAA Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-19.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 25 Apr 2017 13:06:45 -0000 Hi, I have commented out the section numbers. On 03/28/2017 07:16 PM, Christer Holmberg wrote: > Hi, > > Another comment: > > The draft references specific sections in draft-ice-5245bis. > > Note that there is some ongoing re-structuring of 5245bis, which means = the section numbers may change. > > Regards, > > Christer > > -----Original Message----- > From: Hipsec [mailto:hipsec-bounces@ietf.org] On Behalf Of Miika Komu > Sent: 27 March 2017 10:41 > To: hipsec@ietf.org > Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-1= 9.txt > > Hi, > > the preliminary version is now published as it is (except I had to chan= ge publication the date). The suggestions from Christer are not yet here = and will require some time to be fixed. > > On 03/27/2017 10:37 AM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the Host Identity Protocol of the IETF. >> >> Title : Native NAT Traversal Mode for the Host Ident= ity Protocol >> Authors : Ari Keranen >> Jan Mel=C3=A9n >> Miika Komu >> Filename : draft-ietf-hip-native-nat-traversal-19.txt >> Pages : 53 >> Date : 2017-03-27 >> >> Abstract: >> This document specifies a new Network Address Translator (NAT) >> traversal mode for the Host Identity Protocol (HIP). The new mode = is >> based on the Interactive Connectivity Establishment (ICE) methodolo= gy >> and UDP encapsulation of data and signaling traffic. The main >> difference from the previously specified modes is the use of HIP >> messages for all NAT traversal procedures. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-19 >> https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traver= >> sal-19 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversa= l- >> 19 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at tools.= ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Tue Apr 25 12:44:58 2017 Return-Path: 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 626F7131792 for ; Tue, 25 Apr 2017 12:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, URIBL_BLOCKED=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 ntnZk7F5t6dC for ; Tue, 25 Apr 2017 12:44:54 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D17831316D3 for ; Tue, 25 Apr 2017 12:44:53 -0700 (PDT) X-AuditID: c1b4fb30-1aff698000002705-09-58ffa733b3e5 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id B9.82.09989.337AFF85; Tue, 25 Apr 2017 21:44:52 +0200 (CEST) Received: from [100.94.2.41] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.23) with Microsoft SMTP Server id 14.3.339.0; Tue, 25 Apr 2017 21:45:35 +0200 To: References: <149311833389.6988.1171409574524350946@ietfa.amsl.com> <0744a2be-4100-e7dc-57df-02823b024542@ericsson.com> From: Miika Komu Organization: Ericsson AB Message-ID: <927132a1-76ae-fe58-482b-55e1019085bf@ericsson.com> Date: Tue, 25 Apr 2017 22:44:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0744a2be-4100-e7dc-57df-02823b024542@ericsson.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM2K7qK7J8v8RBhcnsVlMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGXsnvWQpmKxQMW2vfQPjfckuRk4OCQETiS0rupm7GLk4hATW M0psn7KECcJZySgx89dtdpAqYQEfiV2Xn7KB2CICohJTPpxmBrGFBCoklh+bwQJiswloSay6 cx0szi8gKbGhYTeYzStgL7H3xRmwXhYBVYkVkzeD2aICERIPO3exQ9QISpyc+QRsDqeAg8SV Y2fAbGYBC4mZ888zQtjaEssWvgaayQG0V0Xi4rHgCYwCs5B0z0LSMQtJxwJG5lWMosWpxUm5 6UZGeqlFmcnFxfl5enmpJZsYgQF4cMtvgx2ML587HmIU4GBU4uFNCPsfIcSaWFZcmXuIUYKD WUmE9+ISoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFex30XIoQE0hNLUrNTUwtSi2CyTBycUg2M i77VyZQz671bwhIk6m61cY6Vya+VsjUX7vaHTmk8wLAu+XFZm/zChz/EbVg+q6lznF/gbsdl /fBi5Q+111ln95ybedo1WKYu27su9UrLJGf/Tyzu6+q1/Zz/tuy/c6V7fe9cjXmGRSYCzms/ nDiiOeHTpAIRszk2m03z4vx8ZGb6n/2tMs9LiaU4I9FQi7moOBEAv5Q8UDwCAAA= Archived-At: Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-native-nat-traversal-20.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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: Tue, 25 Apr 2017 19:44:56 -0000 Hi, so in addition to Christer's comments... https://mailarchive.ietf.org/arch/msg/hipsec/iPSdqgR6e2lK7LZqUfCBnkLxZn8 https://mailarchive.ietf.org/arch/msg/hipsec/LLsY1BqJdmc5foSk9QhYzUWRDvE =2E..I took the liberty of improving the draft editorially while reviewin= g=20 it (+ one paragraph was removed): 1. Introduction * Added a note that legacy ICE-HIP refers to HIPv1 and this is one=20 refers HIPv2 explicitly 2. Terminology: * HIP connectivity checks, Controlling host, Controlled host (minor=20 editorial improvements) 3. Overview: * Data Relay Server is not mandatory * What the Data Relay Server actually does (translates source address) * Strictly speaking only Responder requires the Data Relay Server 4.2. Transport Address Candidate Gathering at the Relay Client * CANDIDATE_DISCOVERY parameter requires multihoming capabilities which=20 is out of scope, so I removed it 4.5. Base Exchange via Control Relay Server * "It is RECOMMENDED to use the same Control Relay Server throughout the = lifetime of the host association that was used for forwarding the base=20 exchange if the Responder includes it in the locator parameter of the R2 = message." 4.6.1. Connectivity Check Procedure * Added this section: "It should be noted that in the case both=20 Initiator and Responder both advertising their own relayed address=20 candidates [..]" to clarify what happens in this case of both ends=20 advertise their own TURN servers and that asymmetric paths are possible 4.12.3. Handling Conflicting SPI Values * Editorial fixes to make the two cases more understandable If you want to see the diff in detail, please check from here: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversal-2= 0 On 04/25/2017 02:47 PM, Miika Komu wrote: > Hi, > > this version addresses Christer's earliers comments and fixes some othe= r > issues I discovered while reviewing the draft. I'll send a summary of > the comments a bit later. > > On 04/25/2017 02:05 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Host Identity Protocol of the IETF. >> >> Title : Native NAT Traversal Mode for the Host >> Identity Protocol >> Authors : Ari Keranen >> Jan Mel=C3=A9n >> Miika Komu >> Filename : draft-ietf-hip-native-nat-traversal-20.txt >> Pages : 56 >> Date : 2017-04-25 >> >> Abstract: >> This document specifies a new Network Address Translator (NAT) >> traversal mode for the Host Identity Protocol (HIP). The new mode = is >> based on the Interactive Connectivity Establishment (ICE) methodolo= gy >> and UDP encapsulation of data and signaling traffic. The main >> difference from the previously specified modes is the use of HIP >> messages for all NAT traversal procedures. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-hip-native-nat-traversal/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-hip-native-nat-traversal-20 >> https://datatracker.ietf.org/doc/html/draft-ietf-hip-native-nat-traver= sal-20 >> >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hip-native-nat-traversa= l-20 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Hipsec mailing list >> Hipsec@ietf.org >> https://www.ietf.org/mailman/listinfo/hipsec >> > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec From nobody Thu Apr 27 04:14:59 2017 Return-Path: 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 4BC0C1293D8 for ; Thu, 27 Apr 2017 04:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 mOGfwHgYblZe for ; Thu, 27 Apr 2017 04:14:56 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F02128C81 for ; Thu, 27 Apr 2017 04:14:55 -0700 (PDT) X-AuditID: c1b4fb25-466159a000006049-fb-5901d2ad0705 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 25.14.24649.DA2D1095; Thu, 27 Apr 2017 13:14:53 +0200 (CEST) Received: from [147.214.160.20] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.339.0; Thu, 27 Apr 2017 13:14:51 +0200 To: =?UTF-8?Q?Ren=c3=a9_Hummen?= References: CC: Tom Henderson , HIP From: Gonzalo Camarillo Message-ID: <2a03c2d9-5a92-f630-d445-54313a231123@ericsson.com> Date: Thu, 27 Apr 2017 13:14:50 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM2K7n+7aS4yRBo2rNCymLprMbPHu6HcW i5nnD7I5MHvsnHWX3WPJkp9MHi3XYwKYo7hsUlJzMstSi/TtErgyvk1rZypYbFKxc8lf5gbG PSpdjJwcEgImEh9XvGfsYuTiEBI4wihxccECFghnDaPE5yvnWUCqhAUMJdqntLOB2CICdhJL jjxkhSg6zCRxYOE3oCIODmYBZ4nf5xNBatgELCS23LoP1ssrYC9xZ9UbdhCbRUBV4l7PHmYQ W1QgRqJlyQdGiBpBiZMzn4DVcwoEShw6080IMVJTYv0ufZAws4C8RPPW2WCtQgLaEsuftbBM YBSYhaR7FkLHLCQdCxiZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIEhunBLb9VdzBefuN4 iFGAg1GJh1fhAUOkEGtiWXFl7iFGCQ5mJRFeyZ2MkUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 HfddiBASSE8sSc1OTS1ILYLJMnFwSjUwcpx/YHXPfJd+5MsQpSfV8ezJ3UWyu+79Lr52ufJs 6GE1jT3njjptspJbxdh7wVthia1J0uagx9e8fUWaE75FfN0n9VX604uO5vR1pX1XNvffPvdZ PEtmlsApPd6PqybNuS5VKS3GOlf7rcu5zRyv5qqESb5XWv7sYUrXxX3aFQ392rlXfRl1lViK MxINtZiLihMBzs3wLU8CAAA= Archived-At: Subject: Re: [Hipsec] WGLC: draft-ietf-hip-dex-04 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.22 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: Thu, 27 Apr 2017 11:14:58 -0000 Hi Rene, to be clear, you had 3 questions on your email below and you said you needed further input from the group. Do you mean version 05 of the draft is ready to be sent to the IESG (i.e., ready for publication request), or you will revise the draft once more before it is ready? Thanks, Gonzalo On 26/03/2017 7:16 PM, René Hummen wrote: > Hi Gonzalo, > > I did not receive any comments indicating the need to make further > changes. From my side, we are ready to finalize the draft. > > BR > René > > 2017-03-16 16:25 GMT+01:00 Gonzalo Camarillo > >: > > Hi Rene, > > did you get answers to your questions below and, in general, enough > input to finalize the draft? > > Thanks, > > Gonzalo > > On 05/02/2017 11:59 PM, René Hummen wrote: > > Hi Tom, > > > > thanks for your review! > > > > I have addressed most of your comments in the new revision 05 that I > > just uploaded before. For your remaining comments, I need additional > > input from you and the rest of this group: > > > > 1) The text from Section 6.3 that you refer to is the same as in > RFC5201 > > (HIPv1). I agree with you on the endianess. However, I assume that > there > > was a good reason why the sort() was specified this way in the > original > > HIP version. I would therefore prefer to keep the text as is. > > Concerning the 96 vs. 128 bit issue, the draft defines HITs the > same way > > as HIPv2, which from my understanding are the full 128bit. > > > > 2) Concerning Sec. 6.5 through 6.8, I consciously chose to provide the > > full specification here in order to significantly increase the > > readability of these sections. When only stating the differences, I > > found myself constantly changing between two documents (RFC7401 > for the > > content and the DEX draft to see if the content was relevant, removed, > > or modified). To support those interested in the changes between > RFC7401 > > and the DEX draft, I specifically call out the main differences at the > > end of each section. Does this satisfy your comment? > > > > 3) If your suggestion for Section 10 is purely cosmetic in nature, I > > would prefer to not put additional effort into the IANA section. > So, are > > these changes cosmetic or mandatory? > > > > BR > > René > > > > 2016-11-20 3:32 GMT+01:00 Tom Henderson > > >>: > > > > Gonzalo, I have reviewed HIP DEX again and believe it is ready to > > publish, although I spotted a few minor items below that can be > > handled in the next revision. > > > > - Tom > > > > Editorial/minor: > > > > Section 1: The numbered list is somewhat tersely written and may be > > hard to interpret by the newcomer to HIP specifications. Consider > > to elaborate more (using fuller sentences and not sentence > > fragments). e.g.: > > > > "Forfeit of Perfect Forward Secrecy with the dropping of an > > ephemeral Diffie-Hellman key agreement." could be > > "Forfeit of the HIPv2 Perfect Forward Secrecy property due to the > > removal of the HIPv2 ephemeral Diffie-Hellman key agreement." > > > > Section 1.1, spell out 'DoS' first time usage > > > > Section 4.1: "Note that x and y each constitute half the final > > session key material." (change to 'half of the') > > > > The figure in 4.1 does not have a caption, and also, why is 'mac' > > lowercased? > > > > Sec 4.1.3.1 : "Since only little data is > protected > > by this SA" (perhaps s/little/a small amount/) > > > > Sec. 5.2.4: "The following new HIT Suite IDs are defined..." > (s/IDs > > are/ID is/ because there is only one defined) > > > > Sec. 6.3: "sort(HIT-I | HIT-R) is defined as the network byte > order > > concatenation of the two HITs... comparison of the two HITs > > interpreted as positive (unsigned) 128-bit integers in network > byte > > order" what does it mean to define a sort on a network byte order > > concatenation? It seems perhaps clearer to leave endian > issues out > > (they are implicit everywhere in a protocol) and just define > it as a > > comparison on HITs interpreted as unsigned 128-bit integers > (and by > > the way, is the full 128 bits including prefix included or > just the > > 96 bits)? > > > > Sec. 6.5 through 6.8: Unlike much of this draft, these > sections do > > not just specifically call out the differences from the > > corresponding RFC 7401 sections, but instead restate the modified > > processing flow, and it is hard to spot what is different here. I > > wonder whether it would be clearer to just refer to those > processing > > steps in RFC 7401 that are changed. > > > > Sec. 8: Can a MITM reply to I1 with ICMP parameter problem, > causing > > the true response (coming later) to be ignored because the > initiator > > already gave up? Maybe clarify here or in sec 5.4 to wait a > little > > while before accepting the result of an ICMP. > > > > Sec. 10: Consider to update the IANA section in the style > that RFC > > 8003 (and others) used, stating the history of the registry > and what > > exactly is requested to be changed. For example, something like > > "RFC 5201 and later RFC 7401 established the following registry > > .... This document defines the following new codepoints for that > > registry ..." > > > > > > _______________________________________________ > > Hipsec mailing list > > Hipsec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/hipsec > > > > > > > > > >