From nobody Sat Apr 2 05:21:50 2016 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 4F9B612D175 for ; Sat, 2 Apr 2016 05:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 VltM8op6NYZG for ; Sat, 2 Apr 2016 05:21:48 -0700 (PDT) Received: from mxout26.s.uw.edu (mxout26.s.uw.edu [140.142.234.176]) (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 D3DF212D0BA for ; Sat, 2 Apr 2016 05:21:47 -0700 (PDT) Received: from hymn03.u.washington.edu (hymn03.u.washington.edu [140.142.9.111]) by mxout26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u32CL3Ru019502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Apr 2016 05:21:03 -0700 Received: from hymn03.u.washington.edu (localhost [127.0.0.1]) by hymn03.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u32CKxJJ005651; Sat, 2 Apr 2016 05:20:59 -0700 Received: from localhost (Unknown UID 15408@localhost) by hymn03.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u32CKxhl005641; Sat, 2 Apr 2016 05:20:59 -0700 X-Auth-Received: from [73.239.169.224] by hymn03.u.washington.edu via HTTP; Sat, 02 Apr 2016 05:20:58 PDT Date: Sat, 2 Apr 2016 05:20:59 -0700 (PDT) From: Tom Henderson To: Gonzalo.Camarillo@ericsson.com Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.2.121517 X-PMX-Server: mxout26.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODYTEXTP_SIZE_400_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_300_399 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 0' Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] Status of our next batch 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 12:21:49 -0000 On 03/31/2016 07:44 AM, Gonzalo Camarillo wrote: > Hi Tom, > > what is the status of the multihoming draft? When do you think you will > get around to submitting a version that is ready for WGLC? > > Thanks, > > Gonzalo > Gonzalo, I plan to publish a revision next week. - Tom From nobody Mon Apr 4 12:49:23 2016 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 ABF5112D1EB for ; Thu, 31 Mar 2016 23:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.312 X-Spam-Level: X-Spam-Status: No, score=-4.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.helsinki.fi 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 emc5yQPwAPgi for ; Thu, 31 Mar 2016 23:58:36 -0700 (PDT) Received: from script.cs.helsinki.fi (script.cs.helsinki.fi [128.214.11.1]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D997312D1D8 for ; Thu, 31 Mar 2016 23:58:35 -0700 (PDT) X-DKIM: Courier DKIM Filter v0.50+pk-2016-01-27 mail.cs.helsinki.fi Fri, 01 Apr 2016 09:58:30 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.helsinki.fi; h=subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= dkim20130528; bh=GHywFJYux+3Uxop3DmUxGf3rhnjzVfl1ba9r6fSQhJ8=; b= OUNYVio1dvDEWXSCnnUW7X1rWDW5+CH+27gqUhDtuHmx/0HNgQDDHkjnDSGqVR8U EHpI7JWbHgrOCiZNmJaA/cl/GgDffTmgRGdRbTBUrA6Gtg3lz0lrrVf5nXSVJNpw GjAf55RqZrnX27V43luEbBnLgBiGQKMtuX3wm90h3n0= Received: from [128.214.10.115] (hpf-7.cs.helsinki.fi [128.214.10.115]) (AUTH: PLAIN sklvarjo, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by mail.cs.helsinki.fi with ESMTPSA; Fri, 01 Apr 2016 09:58:30 +0300 id 00000000005A1B9A.0000000056FE1C16.00007A25 To: Gonzalo Camarillo , hipsec@ietf.org References: <20160226092518.23119.26137.idtracker@ietfa.amsl.com> <56D01ACE.50907@cs.helsinki.fi> <56FD36BA.9020002@ericsson.com> From: Varjonen Samu Message-ID: <56FE1C16.2070806@cs.helsinki.fi> Date: Fri, 1 Apr 2016 09:58:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FD36BA.9020002@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Mon, 04 Apr 2016 12:49:22 -0700 Subject: Re: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-07.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 06:58:38 -0000 Hi, still waiting for the final clarification comment from Sean Turner (Secdir). Sent a reminder now. Otherwise done. -Samu On 31/03/16 17:39, Gonzalo Camarillo wrote: > Hi Samu, > > what is the status of this? > > Thanks, > > Gonzalo > > On 26/02/2016 11:28 AM, Varjonen Samu wrote: >> Hi all, >> >> addressed the GenArt, OPSdir, SecDir, and IANA comments. Still waiting >> for one clarification to one last comment. >> >> -Samu >> >> On 26/02/16 11:25, 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 : Host Identity Protocol Certificates >>> Authors : Tobias Heer >>> Samu Varjonen >>> Filename : draft-ietf-hip-rfc6253-bis-07.txt >>> Pages : 11 >>> Date : 2016-02-26 >>> >>> Abstract: >>> The Certificate (CERT) parameter is a container for digital >>> certificates. It is used for carrying these certificates in Host >>> Identity Protocol (HIP) control packets. This document specifies the >>> certificate parameter and the error signaling in case of a failed >>> verification. Additionally, this document specifies the >>> representations of Host Identity Tags in X.509 version 3 (v3). >>> >>> The concrete use cases of certificates, including how certificates >>> are obtained, requested, and which actions are taken upon successful >>> or failed verification, are specific to the scenario in which the >>> certificates are used. Hence, the definition of these scenario- >>> specific aspects is left to the documents that use the CERT >>> parameter. >>> >>> This document updates RFC7401 and obsoletes RFC6253. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ >>> >>> There's also a htmlized version available at: >>> https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-07 >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-07 >>> >>> >>> 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 7 23:00:06 2016 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 4DA0B12D1BA; Thu, 7 Apr 2016 23:00:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160408060005.10059.27145.idtracker@ietfa.amsl.com> Date: Thu, 07 Apr 2016 23:00:05 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-multihoming-08.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 08 Apr 2016 06:00:05 -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 : Host Multihoming with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-multihoming-08.txt Pages : 22 Date : 2016-04-07 Abstract: This document defines host multihoming extensions to the Host Identity Protocol (HIP), by leveraging protocol components defined for host mobility. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-multihoming-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-multihoming-08 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 Thu Apr 7 23:04:06 2016 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 AA2A312D0AE for ; Thu, 7 Apr 2016 23:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 GKPGmKf9LXZI for ; Thu, 7 Apr 2016 23:04:03 -0700 (PDT) Received: from mxout23.cac.washington.edu (mxout23.cac.washington.edu [140.142.32.140]) (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 BAC6A12D095 for ; Thu, 7 Apr 2016 23:04:03 -0700 (PDT) Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout23.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u3862wKX006623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Apr 2016 23:02:58 -0700 Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u3862taC003522; Thu, 7 Apr 2016 23:02:55 -0700 Received: from localhost (Unknown UID 10745@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u3862t1N003519; Thu, 7 Apr 2016 23:02:55 -0700 X-Auth-Received: from [73.239.169.224] by hymn04.u.washington.edu via HTTP; Thu, 07 Apr 2016 23:02:54 PDT Date: Thu, 7 Apr 2016 23:02:54 -0700 (PDT) From: Tom Henderson To: hipsec@ietf.org Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.8.55116 X-PMX-Server: mxout23.cac.washington.edu X-Uwash-Spam: Gauge=X, Probability=10%, Report=' TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, SUPERLONG_LINE 0.05, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_INTRO 0, __HAS_FROM 0, __HAS_MSGID 0, __HTTPS_URI 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_URI_TEXT 0, __PHISH_SPEAR_GREETING 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_IN_BODY 0, __URI_NO_MAILTO 0, __URI_NO_WWW 0, __URI_NS , __URI_WITH_PATH 0, __USER_AGENT 0' Archived-At: Subject: Re: [Hipsec] HIP multihoming status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 06:04:05 -0000 Below I am replying inline to my message from November regarding the HIP multihoming issues, and how they are addressed in newly published draft version -08. On 11/22/2015 11:01 PM, Tom Henderson wrote: > > > On 11/17/2015 11:52 PM, Gonzalo Camarillo wrote: >> Authors of the following drafts, >> >> could you please let the WG know their status and what needs to >> happen next for each of them in order to be able to WGLC them at >> some point in the future? >> >> https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ >> http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ > > Recall that we split multihoming from mobility for this version of > the HIP specifications. The HIP multihoming draft has received less > attention than the mobility draft over the years. > > The open tracker issues are listed here: > https://trac.tools.ietf.org/wg/hip/trac/query?component=multihoming > > The first one (#3) is one that somewhat prompted the draft split. > RFC5206 advocates creating full mesh of SAs for multihoming use > cases. That has led to a lot of overhead/complexity, so this tracker > item is a reminder to revisit that issue. There were several complaints that the recommendations for multihoming in RFC5206 led to the formation of too many SAs. For instance, the scenario of two hosts with two addresses each recommended that four pairs of SAs (a full mesh) be set up between the address combinations. In this revision, the two use cases of fault tolerance and load balancing are distinguished. For the fault tolerance scenario, it is no longer recommended that hosts set up SAs in parallel, but that they keep the addresses in reserve in case an address failure is detected. For the load balancing scenario, it is recommended to create different SA pairs for different paths to be used for load balancing, but stops short of recommending a full mesh of SAs. > > Issue #5 suggests to add support for cross-(address)-family > handovers, as outlined in a paper several years ago. I reviewed the paper by Samu, Miika, and Andrei, and included their recommendations to allow the LOCATOR_SET in the R2 packet, and to allow hosts to avoid setting the preferred bit if they choose to do so. Related to address families, I removed draft text about supporting associations and SAs that cross address family realms (e.g. one host has IPv4 address, one has IPv6 addres), since there is no description for how that would work in practice. > > Issue #7 raises the issue of incorporating support for load-balancing > across multihomed scenarios. See above; load balancing is explicitly listed as a scenario in the new draft. > > Issue #11 points out that the draft should better clarify the > relationships between SPIs, interfaces, and locators when multihoming > is available. This is related to issue #3 and hopefully has been improved in the rewrite. > > Issue #16 suggests to add support for sending UPDATEs in parallel, to > lower latency in finding working locator pairs. Perhaps what should > be done initially is to review whether there is any specification on > the receiving side that would preclude such operation in the future. I did not include this (previously called the 'shotgun' approach) and suggest that we leave it for further study. > > Issue #17 suggests to review two drafts on fault tolerance that may > contribute to the multihoming specification. I haven't looked at > these for several years so I am not sure what specific changes might > be needed now. I read these drafts again. I included fault tolerance as a use case supported by the new draft. I did not try to include failure detection protocols such as REAP or the other proposed protocol, and suggest to leave failure detection protocols for further study. > > So in summary, there still seems to be some work to do to resolve the > above open issues. I guess that we could perhaps reduce the work by > avoiding scope increase (e.g. issues 5, 7, 16, 17) but we should > still review the basic complexity issue that prompted this split and > led to issues 3 and 11. Are there any other opinions or > recommendations about proceeding with the multihoming open issues? I believe that if this draft passes review by the WG, we could close the open issues as either resolved or wontfix based on the above discussion. - Tom From nobody Sat Apr 9 23:29:01 2016 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 67C6712D5C3 for ; Sat, 9 Apr 2016 23:29:00 -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 loNlWX_yJ7rc for ; Sat, 9 Apr 2016 23:28:58 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3170F12D5C0 for ; Sat, 9 Apr 2016 23:28:57 -0700 (PDT) X-AuditID: c1b4fb25-f79f86d00000400a-c5-5709f2a7ca5c Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 20.33.16394.7A2F9075; Sun, 10 Apr 2016 08:28:55 +0200 (CEST) Received: from ESESSMB205.ericsson.se ([169.254.5.173]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0248.002; Sun, 10 Apr 2016 08:28:55 +0200 From: =?Windows-1252?Q?Ari_Ker=E4nen?= To: Miika Komu Thread-Topic: [Hipsec] WGLC: draft-ietf-hip-native-nat-traversal Thread-Index: AdFowpWe9jrdmw5kTlK+lzLVKf/ImwEuwOgACUx9fYA= Date: Sun, 10 Apr 2016 06:28:54 +0000 Message-ID: References: <56AB5BCD.7060803@ericsson.com> <56BE47BE.9070406@ericsson.com> <56C32BCC.9070105@ericsson.com> <56CB299E.5030704@ericsson.com> In-Reply-To: <56CB299E.5030704@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1D97AB8A8E8C5F4883DB2B9A26FFC85B@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7uu7yT5zhBu1rzCymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN4NlxgL5hhXfFy4namB8Yt6FyMnh4SAicTXw3uZIWwxiQv3 1rN1MXJxCAkcYZQ48O0hlLOEUeLPrHdsIFVsAo4Spx6uZQWxRQQ0JBpPbgKzmQW8Jfrv3WAC sYUF7CVO7rvFDlHjILF58zKoeiuJk5t6wbaxCKhK3Ll5ESzOC1Tfu+woK8SyXkaJ5s4/YEWc AjoSkyZtZQGxGYHO+35qDRPEMnGJW0/mM0GcLSCxZM95qBdEJV4+/scKYStJrD28nQWi3kDi /bn5zBC2tcSv7otQc7Qlli18zQxxhKDEyZlPWCYwis9CsmIWkvZZSNpnIWmfhaR9ASPrKkbR 4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzA+Dq45bfqDsbLbxwPMQpwMCrx8CZUc4YLsSaWFVfm HmKU4GBWEuH99AEoxJuSWFmVWpQfX1Sak1p8iFGag0VJnDc78l+YkEB6YklqdmpqQWoRTJaJ g1OqgdHxXrRymmDf/nWMF6b4v9hT575X5uu8w/q8B+ZLTrE9yVD3wptxS58d9yyuchkPkQ7m i3/nLTuy7mA0280fayPvT/S65LN/AeeHTIHXfOUnVB6va7Gd8fNN3a8fnRuWdQR3cx/0z2ze XaDQ+8fDMyROabW/+ktOV195k0ZPh5NTPRMmxOSmb1JiKc5INNRiLipOBAARVWT9qwIAAA== Archived-At: Cc: "hipsec@ietf.org" , Jan Melen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 06:29:00 -0000 Hi, Thanks Miika and sorry for belated answer. Your suggestions sound good. See= inline for comments on the questions. I clipped out parts that needed no c= omments. > On 22 Feb 2016, at 12:30, Miika Komu wrote: [...] > I would also suggest to explain the ICE term "permission" here. OK. TURN RFC has text for that. [...] > > 3.2. Forwarding Rules and Permissions > > > > Permissions are not required for the connectivity checks, but if a > > relayed address is selected to be used for data, the registered host > > MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION > > parameter (see Section 4.2) with the address of the peer and the > > outbound and inbound SPI values the host is using with this peer. >=20 > PEER_PERMISSION is not a part of RFC5770, why is it introduced here? Because that's needed for the data relay in order to have the same function= ality as TURN server (c.f. PEER_PERMISSION in TURN RFC), i.e., to allow onl= y explicitly singled peers to connect to the host via relay. [...] > > 3.3. Relaying UDP Encapsulated Data and Control Packets >=20 > > When a host wants to send a HIP control packet (such as a > > connectivity check packet) to a peer via the data relay, it MUST add >=20 > * wants -> intends (machines don't have a will, at least yet :) > * it -> ambiguous, should be "the host" > * via the *peer's* data relay, right? I mean both hosts may have their ow= n data relays. No, RELAY_TO is used only with own relay. With peer's relay you don't need = the parameter but can send plain connectivity check. This should be clarifi= ed. > > send it to the data relay's address. The data relay MUST send the >=20 > address of the data relay of the peer (right?) No, own relay. Let's clarify that. >=20 > > When a host wants to send a UDP encapsulated ESP packet to a peer via > > the data relay, it MUST have an active permission at the data relay > > for the peer with the outbound SPI value it is using. >=20 > *peer* data relay Own again. > > The host MUST send the UDP encapsulated ESP packet to the data relay's = address. >=20 > What host? Whose data relay? The whose whose data relay is being used. > * wants -> intends > * peer's data relay (right? please correct twice) >=20 > The third ("If the data relay..."), fourth (When a host) and fifth ("When= the data relay...") paragraphs appear a bit of redundant/overlapping, perh= aps it is better to merge them together. >=20 > Please state the owner of the data relay (i.e. registered host) in all ca= ses. The data relay only relays data traffic to one way (to the registered = host), right? Return traffic from the host that is registered with PEER_PERMISSION is rel= ayed too. [...] > > If the controlling host > > does not have any data to send, it SHOULD send an ICMP echo request >=20 > ICMPv6 inside the tunnel - right? Yes. > > stop checks and start using the nominated pair. When the controlled > > host receives the first ESP packet, it MUST select that pair for use > > and send back an ESP packet to acknowledge a working candidate pair. > > If the controlled host does not have any data to send, it SHOULD send > > an ICMP echo request. >=20 > ICMPv6 inside the tunnel? Yes (also other instances). > > If the connectivity checks failed the hosts SHOULD notify each other > > about the failure with a CONNECTIVITY_CHECKS_FAILED Notify Message > > Type [RFC5770]. >=20 > ... failed, the hosts SHOULD ... >=20 > It would also worthwhile to explain how the connectivity end in the case = of success, maybe through an example. That's explained in 5770 and 5245. But perhaps little redundancy would not = hurt here. [...] > > 3.10. Handling Conflicting SPI Values >=20 > > Since the HIP data relay determines from the SPI value to which peer > > an ESP packet should be forwarded, the outbound SPI values need to be > > unique for each relayed address registration. Thus, if a registered > > host detects that a peer would use an SPI value that is already used > > with another peer via the relay, it MUST NOT select the relayed > > address for use. >=20 > This is a bit confusing, do you mean inbound SPI values? Or from which vi= ewpoint is this written? It's the inbound SPI from the peer's perspective. > > However, a host with many peers MAY decrease the odds of a conflict > > by registering more than one relayed address using different local > > addresses. >=20 > local addresses? Do you mean in the case the host is multihomed? Or just = by using different SPI values? Yes, multiple IP addresses. Could be just different IP address from the sam= e interface too. [...] > > 4.2. PEER_PERMISSION Parameter >=20 > > The parameter is used for setting up and refreshing forwarding rules > > and permissions at the data relay for data packets. >=20 > ... and the permission for data packets at the data relay. >=20 > > OSPI the outbound SPI value the registered host is using for > > the peer with the Address and Port > > ISPI the inbound SPI value the registered host is using for > > the peer with the Address and Port >=20 > What happens if both of the end-host have their own data relays? Then I t= hink the OSPI could be zero. The SPIs would still be the SPIs both endpoints use when sending ESP packet= s like in other cases. The relays don't touch the SPI values; just read the= m to know where to forward. > Why do you need to open both directions explicitly? I think the registere= d host should be allowed to send through the relay after successfuly data r= elay registration. So just opening the inbound direction should be sufficie= nt and OSPI could be removed? You want to also send data to the peer and then there's only OSPI in ESP pa= ckets. The relay works both ways. > > 4.3. HIP Connectivity Check Packets >=20 > Why is the priority included separately in a new parameter since it was a= lready exhanged in the locator? For peer-reflexive priorities (see RFC 5245). The priority for those is dif= ferent from the host priorities in the locator. >=20 > > 5. Security Considerations >=20 > I didn't find the described issue from RFC5770, but I would add that you'= re talking about non-HIP aware firewalls. Also, the relay listens at a fixe= d port for registered clients, but it can decide about the port facing the = peer host. Yes. Cheers, Ari From nobody Tue Apr 12 07:42:48 2016 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 552F112E62B for ; Tue, 12 Apr 2016 07:42:47 -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 vJZfq61hmWDE for ; Tue, 12 Apr 2016 07:42:46 -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 8091112E0E9 for ; Tue, 12 Apr 2016 07:42:45 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-a3-570d096250fa Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 8A.53.26920.2690D075; Tue, 12 Apr 2016 16:42:43 +0200 (CEST) Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.248.2; Tue, 12 Apr 2016 16:42:18 +0200 To: =?UTF-8?Q?Ari_Ker=c3=a4nen?= References: <56AB5BCD.7060803@ericsson.com> <56BE47BE.9070406@ericsson.com> <56C32BCC.9070105@ericsson.com> <56CB299E.5030704@ericsson.com> From: Miika Komu Organization: Ericsson AB Message-ID: <570D094A.3070309@ericsson.com> Date: Tue, 12 Apr 2016 17:42:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090909060202060004010900" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdXTeZkzfc4MhZKYupiyYzOzB6LFny kymAMYrLJiU1J7MstUjfLoEr4/22H2wF180q3s5/ztjAeMu4i5GTQ0LARGJj7x8mCFtM4sK9 9WxdjFwcQgJHGCWOrD7MBOGsZpR4OXMZO0iVsIC9xMl9t4BsDg4RAWuJ/+9VIWoOM0o8n/AC bBKzgLdE/70bYDabgJbEqjvXmUFsfgFJiQ0Nu8FsXgFtib6jRxhBbBYBVYnOp29YQWxRgQiJ J3NPMkLUCEqcnPmEBcTmFHCQOHToLdhBzALdjBKvur4yghwhJKAicfFY8ARGwVlIWmYhK5sF dpOtxJ25u5khbG2JZQtfQ9nWEjN+HWSDsBUlpnQ/ZIewTSVeH/0I1WsssWzdX7YFjByrGEWL U4uLc9ONjPVSizKTi4vz8/TyUks2MQLj4uCW37o7GFe/djzEKMDBqMTDuyCMJ1yINbGsuDL3 EKMK0JxHG1ZfYJRiycvPS1US4TVh5w0X4k1JrKxKLcqPLyrNSS0+xCjNwaIkzpsT+S9MSCA9 sSQ1OzW1ILUIJsvEwSnVwFh8t0Vh29Rji3fO23XW8E/csbnJpxQNZ+zvbbYs5j7cwHw8Kq/R Pe2q0xx2Xb93m36c8lfoXHJo/zwXbo5bBwJ+7+V53CitoPLA6k7kSiEG5rcl76rtpzi/85qQ yr7z4Nr8Cfpav/gE4qP0OO38t69e5OOcG9ziPJ3hukPVD8MtPRdfPUoQy1RiKc5INNRiLipO BADdby+FkwIAAA== Archived-At: Cc: "hipsec@ietf.org" , Jan Melen 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:42:47 -0000 --------------ms090909060202060004010900 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Ari, On 04/10/2016 09:28 AM, Ari Ker=E4nen wrote: >>> 3.2. Forwarding Rules and Permissions >>> > > >>> > >Permissions are not required for the connectivity checks, but if a= >>> > >relayed address is selected to be used for data, the registered ho= st >>> > >MUST send an UPDATE message [RFC7401] with a PEER_PERMISSION >>> > >parameter (see Section 4.2) with the address of the peer and the >>> > >outbound and inbound SPI values the host is using with this peer. >> > >> >PEER_PERMISSION is not a part of RFC5770, why is it introduced here? > Because that's needed for the data relay in order to have the same func= tionality as TURN server (c.f. PEER_PERMISSION in TURN RFC), i.e., to all= ow only explicitly singled peers to connect to the host via relay. I would also suggest mentioning that PEER_PERMISSION must include a SEQ=20 parameter to make sure that we have retransmissions (data relay sends an = ACK). --------------ms090909060202060004010900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDEyMTQ0MjE4 WjAvBgkqhkiG9w0BCQQxIgQgErNUB8v0IO6zwk3YRqOUqIyHGvVRqB6PGSr5Jj0sbGYwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQAVhur/Y8Cy AkWn72fSOCayiqvSpaw37NI/YuypylLjd9I+avW8KW+wvJZdwZ7nPlQkh9+osiz4D6aX8Zaa KFZklKkon088fOwomYVizeaT2YaTQRe3CNSdAwIOMT06LydjE1TgxN45gTHxWkSROeQp+wox ejQRVXgs2UqMfaJywHQJwskSEWb/4pxMmw18xkysWjceE4ViKcPbWZ2quenT0v68Su7ZpurT ME2dTLLB8oC68uIdkygtJArIO1M/FniwN+kFhR4NN0QWRN3K7kaJh1q55gTQcoBbJ1kbX58q gQj8QNN/IjKwLDxlpBHZZmQwDB+63ONByjTbjpgpgmmYAAAAAAAA --------------ms090909060202060004010900-- From nobody Fri Apr 15 03:19:12 2016 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 9D62A12D839 for ; Fri, 15 Apr 2016 03:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.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, USER_IN_WHITELIST=-100] 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 tQ1cmzqiDtMm for ; Fri, 15 Apr 2016 03:19:09 -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 CFDEB12D6DC for ; Fri, 15 Apr 2016 03:19:07 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-59-5710c019ec8c Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 69.AF.26920.910C0175; Fri, 15 Apr 2016 12:19:05 +0200 (CEST) Received: from [131.160.126.87] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.248.2; Fri, 15 Apr 2016 12:18:16 +0200 To: HIP From: Gonzalo Camarillo Message-ID: <5710BFE8.5010705@ericsson.com> Date: Fri, 15 Apr 2016 13:18:16 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM2K7oq7kAYFwgwcdMhZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvOb69kL/jBW9J36ydTAeJWxi5GTQ0LAROL0rG/sELaYxIV7 69m6GLk4hASOMEqc+PyXHcJZwyjRumwOM0iViICkRM/dpSwgNpuAhcSWW/fBbGEBP4lJN2+C TeUV0JY4+xlkEgcHi4CqxPe/ySBhUYEYicYHp5ggSgQlTs58wgJSwiygKbF+lz5ImFlAXmL7 W4hNQkBTlj9rYZnAyDcLSccshI5ZSDoWMDKvYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3ZxAgM p4NbfuvuYFz92vEQowAHoxIPb0KzQLgQa2JZcWXuIUYJDmYlEV6mfUAh3pTEyqrUovz4otKc 1OJDjNIcLErivDmR/8KEBNITS1KzU1MLUotgskwcnFINjJmlZocmKu1Z2irMc37yFZdFa+wN rt97brJLdzVjv2JL4porjwMmzMlYbvBv8vLl7pbaqyrZVrEybdackTZ3a56jgdONOX6Ppd9L ZtT27HWZ3NyyIXq62I9tJ5awGdXMLROze+Rpyr++r27J4dyZqfdP5U73schY7bRrx7QdgaxL l3QLN22tm6TEUpyRaKjFXFScCACijqDrIwIAAA== Archived-At: Subject: [Hipsec] WGLC: draft-ietf-hip-multihoming-08 and draft-ietf-hip-rfc5206-bis-10 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 10:19:10 -0000 Folks, I would like to start a WGLC on the following two drafts. This WGLC will end on April 29th: https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ Thanks, Gonzalo From nobody Sun Apr 17 13:27:22 2016 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 6C41012D806 for ; Sun, 17 Apr 2016 13:27:21 -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 TUiJOkL1pLy6 for ; Sun, 17 Apr 2016 13:27:19 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8E912D771 for ; Sun, 17 Apr 2016 13:27:18 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-c1-5713f1a49bec Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id C7.85.12926.4A1F3175; Sun, 17 Apr 2016 22:27:16 +0200 (CEST) Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Sun, 17 Apr 2016 22:26:40 +0200 To: hip WG From: Miika Komu Organization: Ericsson AB Message-ID: <5713F17F.1060405@ericsson.com> Date: Sun, 17 Apr 2016 23:26:39 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020506060408060302040805" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvje6Sj8LhBusb9CymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujLMH57EWrO5krPi/aAFjA+PNki5GTg4JAROJ5taJ7BC2mMSF e+vZuhi5OIQEjjJKPDhxhx3CWc0ocXPxdhaQKhEBGYkNm16wgthsAloSq+5cZwaxhQV0JP5P WsYEYvMLSEpsaNgNFucV0JY4snQvI4jNIqAqcezMLjYQW1QgQuLJ3JOMEDWCEidnPmEBWcYs 0M0oMWH9H6DNHECbVSQuHguewMg3C0nZLGRlIAlmATOJeZsfMkPY2hLLFr6Gsq0lZvw6yAZh K0pM6X4IVW8q8froR0YI21hi2bq/bAsYOVYxihanFiflphsZ66UWZSYXF+fn6eWllmxiBAb0 wS2/VXcwXn7jeIhRgINRiYdX4Z1QuBBrYllxZe4hRhWgOY82rL7AKMWSl5+XqiTC+/O1cLgQ b0piZVVqUX58UWlOavEhRmkOFiVx3uzIf2FCAumJJanZqakFqUUwWSYOTqkGxpL+xB3XzOYm fk09oz8/k5tHO+Ok8+k3+kf6clar53Ck3Vntt2S2/VIWRvNLGuHJ1kejl55ZcmRym22XQ9Hm nxuMPRzW75kkN7cwttq5JEAw+Xljz+S/u/76VORNdJmTsXNVuwZ7c0Dl6alJDyfOimks9lzr HXzi1ucnLManvrRHn5dkmXL+lxJLcUaioRZzUXEiABwvRzBwAgAA Archived-At: Subject: [Hipsec] a review of ietf-hip-rfc5206-bis-10 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 20:27:21 -0000 --------------ms020506060408060302040805 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I read through ietf-hip-rfc5206-bis-10, and it is in pretty good shape.=20 Below are a few nits. > 3.1. Operating Environment > > [...] > > Consider next a mobility event, in which a host moves to another IP > address. Two things must occur in this case. First, the peer must > be notified of the address change using a HIP UPDATE message. > Second, each host must change its local bindings at the HIP sublayer > (new IP addresses). It may be that both the SPIs and IP addresses > are changed simultaneously in a single UPDATE; the protocol described > herein supports this. However, elements of procedure to recover from I think simultaneous mobility is covered as already mentioned in the intr= o? > 3.2.3. Mobility messaging through rendezvous server > > 3. A host receiving an UPDATE packet MUST be prepared to process the > FROM and RVS_HMAC parameters, and MUST include a VIA_RVS > parameter in the UPDATE reply that contains the ACK of the UPDATE > SEQ. (I would add that the return routability test should be invoked to the end-host's addresses rather than the ones in VIA_RVS) > 4. This scenario requires that hosts using rendezvous servers also > take steps to update their current address bindings with their > rendezvous server upon a mobility event. > [I-D.ietf-hip-rfc5204-bis] does not specify how to update the > rendezvous server with a client host's new address. > [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host may > send a REG_REQUEST in either an I2 packet (if there is no active > association) or an UPDATE packet (if such association exists). (Maybe this should have been actually step 0) > The procedures described in [I-D.ietf-hip-rfc5203-bis] for > sending a REG_REQUEST and REG_RESPONSE to the rendezvous server > apply also to this mobility scenario. This was a bit vague, how? > 3.2.4. Network Renumbering > > It is expected that IPv6 networks will be renumbered much more often > than most IPv4 networks. From an end-host point of view, network > renumbering is similar to mobility. =2E..and? > 3.3. Other Considerations > > 3.3.1. Address Verification > > When a HIP host receives a set of locators from another HIP host in a > LOCATOR_SET, it does not necessarily know whether the other host is > actually reachable at the claimed addresses. In fact, a malicious > peer host may be intentionally giving bogus addresses in order to > cause a packet flood towards the target addresses [RFC4225]. > Therefore, the HIP host must first check that the peer is reachable > at the new address. > > An additional potential benefit of performing address verification is > to allow middleboxes in the network along the new path to obtain the > peer host's inbound SPI. > > Address verification is implemented by the challenger sending some > piece of unguessable information to the new address, and waiting for > some acknowledgment from the Responder that indicates reception of > the information at the new address. This may include the exchange of > a nonce, or the generation of a new SPI and observation of data > arriving on the new SPI. I suggest would move the second paragraph after the third one. > 3.3.2. Credit-Based Authorization > > On this basis, rather than eliminating malicious packet redirection > in the first place, Credit-Based Authorization prevents > amplifications. This is accomplished by limiting the data a host can > send to an unverified address of a peer by the data recently received > from that peer. Redirection-based flooding attacks thus become less > attractive than, for example, pure direct flooding, where the > attacker itself sends bogus packets to the victim. Reference section 5.6? > 4.3. UPDATE Packet with Included LOCATOR_SET > > A number of combinations of parameters in an UPDATE packet are > possible (e.g., see Section 3.2). In this document, procedures are > defined only for the case in which one LOCATOR_SET and one ESP_INFO > parameter is used in any HIP packet. Furthermore, the LOCATOR_SET > SHOULD list all of the locators that are active on the HIP > association (including those on SAs not covered by the ESP_INFO > parameter). What do you mean by "including those on SAs..."? > Any UPDATE packet that includes a LOCATOR_SET parameter > SHOULD include both an HMAC and a HIP_SIGNATURE parameter. Please add a paragraph break here. > The UPDATE MAY also include a HOST_ID parameter (which may be useful f= or > middleboxes inspecting the HIP messages for the first time). If the > UPDATE includes the HOST_ID parameter, the receiving host MUST verify > that the HOST_ID corresponds to the HOST_ID that was used to > establish the HIP association, and the HIP_SIGNATURE must verify with > the public key assodiated with this HOST_ID parameter. assodiated -> associated Please add a paragraph break here. > The relationship between the announced Locators and any ESP_INFO > parameters present in the packet is defined in Section 5.2. This > draft does not support any elements of procedure for sending more > than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE. draft -> document > 5.4. Verifying Address Reachability > > A host typically starts the address-verification procedure by sending > a nonce to the new address. For example, when the host is changing > its SPI and sending an ESP_INFO to the peer, the NEW SPI value SHOULD > be random and the value MAY be copied into an ECHO_REQUEST sent in > the rekeying UPDATE. (The copying is an implementation strategy) > However, if the host is not changing its SPI, > it MAY still use the ECHO_REQUEST parameter in an UPDATE message sent > to the new address. For what? > 5.5. Changing the Preferred Locator > > [...] > > 3. If the peer host has not indicated a preference for any address, > then the host picks one of the peer's ACTIVE addresses randomly > or according to policy. This case may arise if, for example, local policy > 5.6. Credit-Based Authorization > > To prevent redirection-based flooding attacks, the use of a Credit- > Based Authorization (CBA) approach is mandatory when a host sends > data to an UNVERIFIED locator. The following algorithm meets the > security considerations for prevention of amplification and time- > shifting attacks. Other forms of credit aging, and other values for > the CreditAgingFactor and CreditAgingInterval parameters in mandatory or MUST? > 6. Security Considerations > > In Section 6.1 and Section 6.2, we assume that all users are using > HIP. In Section 6.3 we consider the security ramifications when we > have both HIP and non-HIP users. Security considerations for Credit- > Based Authorization are discussed in [SIMPLE-CBA]. users -> hosts? > 6.1. Impersonation Attacks > > An attacker wishing to impersonate another host will try to mislead > its victim into directly communicating with them, or carry out a man- > in-the-middle (MitM) attack between the victim and the victim's > desired communication peer. Without mobility support, both attack > types are possible only if the attacker resides on the routing path > between its victim and the victim's desired communication peer, or if > the attacker tricks its victim into initiating the connection over an > incorrect routing path (e.g., by acting as a router or using spoofed > DNS entries). Without HIP and its mobility support, ... By the way, I didn't get why the lack of mobility support can lead MiTM attacks? > The HIP extensions defined in this specification change the situation > in that they introduce an ability to redirect a connection (like > IPv6), both before and after establishment. If no precautionary like in IPv6 (why is this an issue for IPv6, btw?) > measures are taken, an attacker could misuse the redirection feature > to impersonate a victim's peer from any arbitrary location. The > authentication and authorization mechanisms of the HIP base exchange > [RFC7401] and the signatures in the UPDATE message prevent this > attack. Furthermore, ownership of a HIP association is securely > linked to a HIP HI/HIT. If an attacker somehow uses a bug in the > implementation or weakness in some protocol to redirect a HIP what protocol? > MitM attacks are always possible if the attacker is present during > the initial HIP base exchange and if the hosts do not authenticate > each other's identities. However, once the opportunistic base =2E..once such an opportunistic... > exchange has taken place, even a MitM cannot steal the HIP connection > anymore because it is very difficult for an attacker to create an > UPDATE packet (or any HIP packet) that will be accepted as a > legitimate update. UPDATE packets use HMAC and are signed. Even > when an attacker can snoop packets to obtain the SPI and HIT/HI, they > still cannot forge an UPDATE packet without knowledge of the secret > keys. Also, replay attacks are impossible because the HMAC keys are and nonces echo_requests are new. > 6.2.1. Flooding Attacks > > > An effective DoS strategy is distributed denial of service (DDoS). > Here, the attacker conventionally distributes some viral software to > as many nodes as possible. Under the control of the attacker, the > infected nodes, or "zombies", jointly send packets to the victim. > With such an 'army', an attacker can take down even very high > bandwidth networks/victims. zombies -> botnets > With the ability to redirect connections, an attacker could realize a > DDoS attack without having to distribute viral code. Here, the > attacker initiates a large download from a server, and subsequently > redirects this download to its victim. via HIP mobility UPDATE, right? > 6.2.2. Memory/Computational-Exhaustion DoS Attacks > > We now consider whether or not the proposed extensions to HIP add any > new DoS attacks (consideration of DoS attacks using the base HIP > exchange and updates is discussed in [RFC7401]). A simple attack is > to send many UPDATE packets containing many IP addresses that are not > flagged as preferred. The attacker continues to send such packets > until the number of IP addresses associated with the attacker's HI > crashes the system. Therefore, there SHOULD be a limit to the number > of IP addresses that can be associated with any HI. where there? > A central server that has to deal with a large number of mobile > clients may consider increasing the SA lifetimes to try to slow down > the rate of rekeying UPDATEs or increasing the cookie difficulty to > slow down the rate of attack-oriented connections. may or MAY? > 6.3. Mixed Deployment Environment > > We now assume an environment with both HIP and non-HIP aware hosts. > Four cases exist. > > 4. A HIP host attempts to steal a non-HIP host's session. A HIP > host could spoof the non-HIP host's IP address during the base > exchange or set the non-HIP host's IP address as its preferred > address via an UPDATE. Other possibilities exist, but a simple > solution is to prevent the use of HIP address check information > to influence non-HIP sessions. er... how? --------------ms020506060408060302040805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDE3MjAyNjM5 WjAvBgkqhkiG9w0BCQQxIgQgO4yyq2m122Ij19MTk/kLxE0ME/AVgly1fUXfSPb1FPwwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBMUb3q1BPa zeUG61Qg2pvHcOKssOajeiqwvBSLXi9ctFuNGNLzYEcysXos/rwnJTgUP/6x1y6HAcIeFcwG ZXoYJ32ShIM1qu5mdcQFfgrSiFhhD5XBWozkkOBFcUc+JAK5nV/Y/Q2hUksyBbQIWh/sn3WY 3pKVeSuDxhrvhnRB26rjtyvVPucBOim6UpyOhVP3j7dz9UYg/Xk34CqpbgZHc3M+Jrwu7rgc 5XCmcuiNr8uuieDZBZU0JF5gKUsC80XEcDEGj9lDRMZlrSNvLUk/BGme3MRpLYl7ijWD3JHV u1T3Ga/9m1dldxBA9Kmb150QPhNtDN2onI+tVhqC0NinAAAAAAAA --------------ms020506060408060302040805-- From nobody Sun Apr 17 13:35:23 2016 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 E12F912D140 for ; Sun, 17 Apr 2016 13:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 qi7XYagBtoDo for ; Sun, 17 Apr 2016 13:35:20 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D3412D130 for ; Sun, 17 Apr 2016 13:35:19 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-c3-5713f38673cb Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 61.EF.16963.683F3175; Sun, 17 Apr 2016 22:35:18 +0200 (CEST) Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.248.2; Sun, 17 Apr 2016 22:35:17 +0200 To: References: From: Miika Komu Organization: Ericsson AB Message-ID: <5713F385.1000806@ericsson.com> Date: Sun, 17 Apr 2016 23:35:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080508090802020505030308" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7n27bZ+Fwg6Wb5SymLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujK6XExkLLttXPLowmbGB8Z9VFyMnh4SAicS05YvZIWwxiQv3 1rOB2EICRxgl1n1S72LkArJXM0r8frkSrEhYQENi4a9eJhBbREBUYsqH08xdjBxARZ4SX2cG gYTZBLQkVt25zgxi8wtISmxo2A1m8wpoS6yZ8J4FxGYRUJX493w6I4gtKhAh8WTuSUaIGkGJ kzOfgNVwCnhJbN0xiRnkBmaBbkaJtf9usEPsUpG4eCx4AqPALCQts5CVgSSYBWwl7szdzQxh a0ssW/gayraWmPHrIBuErSgxpfshVL2pxOujHxkhbGOJZev+si1g5FjFKFqcWlycm25kpJda lJlcXJyfp5eXWrKJERj6B7f8ttrBePC54yFGAQ5GJR5ehXdC4UKsiWXFlbmHGFWA5jzasPoC oxRLXn5eqpII790PwuFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeXMi/4UJCaQnlqRmp6YWpBbB ZJk4OKUaGA1T/89J5DyY3sVuf4QxfVJTfvTWA0dW3Kl7VbSq9cHsODefmPA39VV6qlkt1+Z9 f3WTgeukT7jDifebpn1jfG4dlPyleNKO+b6rXp+80MRq6qkoXHn4oPadFfcYzJvK169ZnNrq 8sD13SqFFWddCq+2xWVJ1L6tD3GR0mJqWzDV2aAic0ryCyWW4oxEQy3mouJEANmypTGFAgAA Archived-At: Subject: Re: [Hipsec] RFC5206-bis status 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 20:35:22 -0000 --------------ms080508090802020505030308 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 11/23/2015 09:05 AM, Tom Henderson wrote: > Well, the previous message's formatting certainly wasn't what I had > in mind, so let's try again below. > > > On 11/17/2015 11:52 PM, Gonzalo Camarillo wrote: >> Authors of the following drafts, >>> could you please let the WG know their status and what needs to >>> happen >> next for each of them in order to be able to WGLC them at some >> point in the future? >>> https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/ >> http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ > > There are six open issues on RFC5206-bis, listed here: > https://tools.ietf.org/wg/hip/trac/query?component=3Drfc5206-bis > > One of them (#12) probably should be closed now based on the draft > version 09 published in July. Agreed. > One related to flow bindings (#23) probably can be left for further > study, with no action at this time, since it hasn't been pursued for > many years. Ok by me. > One (#21) suggests to include HI parameter in the UPDATE, for benefit > of middleboxes. Any objection to adding specification text that HI > MAY be included in UPDATE? MAY is fine. > One (#15) suggests to name UPDATE packets with different names such > as UPDATE1, UPDATE2, and UPDATE3, for clarity. I wonder whether this > can be handled editorially without requiring code point allocation. I read the mobility draft through and I don't this is necessary. > One (#9) suggests to make some mandatory features optional, since at > least one implementation does not implement all mandatory features. I > think that perhaps this will require a review of both of the open > source implementations to see whether any should be relaxed. I think this can be closed since mobility and multihoming drafts are=20 separated now. > One (#8) asks to allow that locator announcement may be decoupled > from SA creation. This requires the definition of another example use > case and extending the specification. There hasn't been more work on this, so I suggest just closing this issue= =2E --------------ms080508090802020505030308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDE3MjAzNTE3 WjAvBgkqhkiG9w0BCQQxIgQgYuTK8uIVVj4dJoh5TTYycMfsMVPIG/5bjx3rBNLsnNswXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCXwbeqM7fR 88CG9P/i60aKQ3fhox4rYv9l2K4wcD/yosMnuEz6QZBEA7l7i+hPv9jk896LU3DKIr7+GqKS DW32tsZl4tWp7Bgsk+dLYO9qDn1ubm7h5LWPQfhEiGCgBWafzjy6LIzF8hhVaAjtVbkBuBct UdRZMbDgP60dLy7fvaI7lx0TLquIygs+iESE/c+mHmgt3mV7AOnvH+rN/rXMIVG4sg5Sigk8 Xfc4+QjPx9KwLxf2xFc+CQ8MU5ytci0rsrTGazTdH3xo6TXDHUuVbZChrQ4n7s74BRG9RcDM 9xlQFP6R2THR5J+fF13FQt29RgiAHjRznp/OqH+JitxxAAAAAAAA --------------ms080508090802020505030308-- From nobody Mon Apr 18 05:56:27 2016 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 C52EC12DCF1 for ; Mon, 18 Apr 2016 05:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.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, USER_IN_WHITELIST=-100] 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 IGMTWUUMWi_G for ; Mon, 18 Apr 2016 05:56:23 -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 DEAEB12DC6D for ; Mon, 18 Apr 2016 05:56:22 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-ca-5714d974bc31 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.4A.26920.479D4175; Mon, 18 Apr 2016 14:56:20 +0200 (CEST) Received: from [131.160.50.191] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.248.2; Mon, 18 Apr 2016 14:55:34 +0200 To: , References: <20160321203627.12199.62928.idtracker@ietfa.amsl.com> <56F98E90.10601@ericsson.com> From: Gonzalo Camarillo Message-ID: <5714D946.4070303@ericsson.com> Date: Mon, 18 Apr 2016 15:55:34 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <56F98E90.10601@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM2K7lm7JTZFwg2t7tCymLprMbLFs9hwm i4Z1nxkdmD22Pv3C4rF7UhO7x5IlP5kCmKO4bFJSczLLUov07RK4Mr4u2cZasPU8Y8XdeXtY GxgPL2TsYuTkkBAwkbjU8YUJwhaTuHBvPVsXIxeHkMARRon1F7YwQzhrGCXur+5kBqkSFrCW mPrhJjuILSJgLPF7+WewSUICiRLnpv9hAbGZgWper70MZrMJWEhsuXUfzOYV0JY49aGBFcRm EVCVuH/qAdgcUYEYicYHp5ggagQlTs58AlbPKaAlMXVrNyPETAOJI4vmsELY8hLb385hhtir LbH8WQvLBEbBWUjaZyFpmYWkZQEj8ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwEA+uOW3 7g7G1a8dDzEKcDAq8fAmsIuEC7EmlhVX5h5ilOBgVhLhNbkOFOJNSaysSi3Kjy8qzUktPsQo zcGiJM6bE/kvTEggPbEkNTs1tSC1CCbLxMEp1cDYevL9ej8j+cLOhR6FKV3r580OORzxyJOv 5VNkTcWzWwte2ob+uFWj3RMitMs6j93N6UNcnn80p9/CJ5k6b3z1Jn2zT+B2V91aNXvKZfOX 8k6sSzU5jiXEzP49IaNJmsk8L+K1Z/PLZZtmdnEam5ieCNr9VdxPs5QrhP2/xsMpds8kZj1e zq/EUpyRaKjFXFScCAB3p63YYAIAAA== Archived-At: Cc: hipsec@ietf.org Subject: Re: [Hipsec] A review of draft-ietf-hip-dex-02.txt 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 12:56:27 -0000 Rene, Bob, could you please have a look at Miika's comments below? Thanks, Gonzalo On 28/03/2016 11:05 PM, Miika Komu wrote: > Hi, > >> 1.1. The HIP Diet EXchange (DEX) > >> Data packets start to flow after the 4th packet. The 3rd and 4th HIP >> packets may carry data payload in the future. However, the details >> of this may be defined later. > > Similarly as in RFC7401, data packets start to flow... > > (I guess you could also mention RFC6078 as another further work item) > >> An existing HIP association can be updated with the update mechanism >> defined in [RFC7401]. Likewise, the association can be torn down >> with the defined closing mechanism for HIPv2 if it is no longer >> needed. HIP DEX thereby omits the HIP_SIGNATURE parameters of the >> original HIPv2 specification. > > Why "thereby"? I don't see the connection. > >> HIP DEX does not have the option to encrypt the Host Identity of the >> Initiator in the 3rd packet. The Responder's Host Identity also is >> not protected. Thus, contrary to HIPv2, there is no attempt at >> anonymity. > > The anonymous bit still exists, so I suggest changing the wording: > > there is no attempt at anonymity -> such Responder anonymity is not > preserved in HIP DEX. > >> 2.1. Requirements Terminology > > In section 6.3, you are introduce also -> notation, which was > not explained. > >> 2.3. Definitions > > I suggest to add also the definitions of both MAC and CMAC because they > are used throughout the document. They are also used in this section. > >> 3.1. Host Identity Tag (HIT) > > Just thinking aloud... should a DEX HIT have a different context ID? > Probably not. > >> 4.1. Creating a HIP Association > >> The HIP Diet EXchange serves to manage the establishment of state >> between an Initiator and a Responder. The first packet, I1, >> initiates the exchange, and the last three packets, R1, I2, and R2, >> constitute an authenticated Diffie-Hellman [DH76] key exchange for >> the Master Key SA generation. This Master Key SA is used by the >> Initiator and the Responder to wrap secret keying material in the I2 >> and R2 packets. Based on the exchanged keying material, the peers >> then derive a Pair-wise Key SA if cryptographic keys are needed, >> e.g., for ESP-based protection of user data. > > (Suggest replacing "user data" with e.g. "data plane" in the entire > document since you're talking about machines (sensors) that may not > have a user) > >> In the I2 packet, the Initiator MUST display the solution to the >> received puzzle. Without a correct solution, the I2 packet is >> discarded. The I2 also contains a key wrap parameter that carries a >> secret keying material of the Initiator. This keying material is >> only half the final session key. The packet is authenticated by the >> sender (Initiator) via a MAC. > > ...half *of* the... > >> The R2 packet acknowledges the receipt of the I2 packet and completes >> the handshake. The R2 contains a key wrap parameter that carries the >> rest of the keying material of the Responder. The packet is >> authenticated by the sender (Responder) via a MAC. > > key wrap parameter -> parameter with encrypted contents > >> 4.1.1. HIP Puzzle Mechanism >> >> The puzzle mechanism enables a Responder to immediately reject an I2 >> packet if it does not contain a valid puzzle solution. To verify the >> puzzle solution, the Responder only has to compute a single CMAC >> operation. After a successful puzzle verification, the Responder can >> securely create session-specific state and perform CPU-intensive >> operations such as a Diffie-Hellman key generation. By varying the >> difficulty of the puzzle, the Responder can frustrate CPU or memory >> targeted DoS attacks. > > ...can frustrate *an Initiator*... > >> Conceptually, the puzzle mechanism in HIP DEX is the same as in >> HIPv2. Hence, this document refers to Sections 4.1.1 and 4.1.2 in >> [RFC7401] for more detailed information about the employed mechanism. >> Notably, the only difference between the puzzle mechanism in HIP DEX >> and HIPv2 is that HIP DEX uses CMAC instead of a hash function for >> solving and verifying a puzzle. The implications of this change on >> the puzzle implementation are discussed in Section 6.1. > > The other difference is mentioned in section 6.1: > > "The only exceptions are that HIP DEX does not use pre-computation of > R1 packets and that RHASH is set to CMAC. As a result, the pre- > computation step in in Section 6.3 of [RFC7401] is skipped in HIP DEX." > >> 4.1.2.1. HIP DEX Retransmission Mechanism > >> The potentially high processing time of an I2 packet at a (resource- >> constrained) Responder may cause premature retransmissions if the >> time required for I2 transmission and processing exceeds the RTT- >> based retransmission timeout. Thus, the Initiator should also take >> the processing time of the I2 packet at the Responder into account >> for retransmission purposes. To this end, the Responder MAY notify >> the Initiator about the anticipated delay once the puzzle solution >> was successfully verified and if the remaining I2 packet processing >> incurs a high processing delay. The Responder MAY therefore send a >> NOTIFY packet (see Section 5.3.6. in [RFC7401]) to the Initiator >> before the Responder commences the ECDH operation. The NOTIFY packet >> serves as an acknowledgement for the I2 packet and consists of a >> NOTIFICATION parameter with Notify Message Type I2_ACKNOWLEDGEMENT >> (see Section 5.2.19. in [RFC7401]). The NOTIFICATION parameter >> contains the anticipated remaining processing time for the I2 packet >> in milliseconds as two-octet Notification Data. This processing time >> can, e.g., be estimated by measuring the computation time of the ECDH >> key derivation operation at Responder boot-up. After the I2 >> processing has finished, the Responder sends the regular R2 packet. > > ( boot-up -> start-up procedures (it doesn't have to be a boot) ) > >> 4.1.2.3. Simplified HIP State Diagram > >> The following diagram shows the major state transitions. Transitions >> based on received packets implicitly assume that the packets are >> successfully authenticated or processed. > > Is the new NOTIFY illustrated also in the figure? > >> 5.2.1. DH_GROUP_LIST >> >> The DH_GROUP_LIST parameter contains the list of supported DH Group >> IDs of a host. It is defined in Section 5.2.6 of [RFC7401]. With >> HIP DEX, the DH Group IDs are restricted to: >> >> Group KDF Value >> >> NIST P-256 [RFC5903] CKDF 7 >> NIST P-384 [RFC5903] CKDF 8 >> NIST P-521 [RFC5903] CKDF 9 >> SECP160R1 [SECG] CKDF 10 >> Curve25519 [RFC7748] CKDF 11 >> Curve448 [RFC7748] CKDF 12 >> >> The ECDH groups 7 - 9 are defined in [RFC5903] and [RFC6090]. ECDH >> group 10 is covered in [SECG] and Appendix D of [RFC7401]. These >> curves, when used with HIP MUST have a co-factor of 1. > > I suggest to change the "value" column title to "group id" or change the > text > as follows: "The ECDH groups with *values* 7 - 9..." > >> The ECDH groups 11 and 12 are defined in [RFC7748]. These curves >> have cofactors of 8 and 4 (respectively). > > Same comment as previously. > >> 5.2.3. HOST_ID >> >> The HOST_ID parameter conveys the Host Identity (HI) along with >> optional information about a host. It is defined in Section 5.2.9 of >> [RFC7401]. >> >> HIP DEX uses the public portion of a host's static ECDH key-pair as >> the HI. Correspondingly, HIP DEX limits the HI algorithms to the >> following profile: > > I would add "*new* profile" since this is not part of RFC7401. > >> 5.2.4. HIT_SUITE_LIST >> >> The HIT_SUITE_LIST parameter contains a list of the supported HIT >> suite IDs of the Responder. Based on the HIT_SUITE_LIST, the >> Initiator can determine which source HIT Suite IDs are supported by >> the Responder. The HIT_SUITE_LIST parameter is defined in >> Section 5.2.10 of [RFC7401]. > >> The following HIT Suite IDs are defined for HIP DEX, and the >> relationship between the four-bit ID value used in the OGA ID field >> and the eight-bit encoding within the HIT_SUITE_LIST ID field is >> clarified: > > ...the following *new* HIT Suite IDs... > > ...is clarified: -> ...is defined as follows: > >> Note that the HIP DEX HIT Suite ID allows the peers to distinguish a >> HIP DEX handshake from a HIPv2 handshake. The Responder MUST respond >> with a HIP DEX HIT suite ID when the HIT of the Initiator is a HIP >> DEX HIT. > > The details are a bit unclear. Which packet are you talking about here? > > I mean the suite id is in R1 (and not in I1), so I guess you're > referring that > Responder must respond to I2 with an R2 that contains HIP DEX HITs? > > In general, I'd urge the authors to write a separate "Compatibility with > HIP base exchange" section in the end of the document with the two > (problematic) use cases: > > 1. Initiator=DEX, Responder=BEX > 2. Initiator=BEX, Responder=DEX > > How what happens in each case? Can the Initiator still try to > communicate (in case the Responder could potentially support both > protocols) or should it just abort? When exactly each party knows and > from which parameters both of the parties detect incompatibilities? > Consider also the opportunistic mode. Bits and pieces of this > discussion was scattered here and there, but it would useful to recap > this is one single section due to compatibility issues with RFC7401. > >> 5.2.5. ENCRYPTED_KEY >> >> [...] >> >> The ENCRYPTED_KEY parameter encapsulates a random value that is later >> used in the session key creation process (see Section 6.3). This >> random value MUST have a length of at least 64 bit. The puzzle value >> #I and the puzzle solution #J (see [RFC7401]) are used as the >> initialization vector (IV) for the encryption process. To this end, >> the IV is computed as FOLD(I | J, 128). The AES-CTR counter is a 16 >> bit value that is initialized to zero with the first use. > > The initialization vector is a explicit, separate field in RFC7401. Why > I and J > are implicitly reused here? To save bits? > > The AES-CTR counter pops out a bit suddenly here. Perhaps you could > "bridge" it to the text in a bit more smoother way. > >> Once this encryption process is completed, the "encrypted value" data >> field is ready for inclusion in the Parameter. If necessary, >> additional Padding for 8-byte alignment is then added according to >> the rules of TLV Format in [RFC7401]. > > The key could be also included in ENCRYPTED parameter, which can > accommodate multiple parameters... unless it is very important to > keep the IV implicit. > >> 5.3. HIP Packets >> >> [...] >> >> In the future, an optional upper-layer payload MAY follow the HIP >> header. The Next Header field in the header indicates if there is >> additional data following the HIP header. > > RFC6078 is also future work. > >> 5.3.1. I1 - the HIP Initiator Packet >> >> [...] >> >> As a compression of the employed HIs, the Initiator's and the >> Responder's HITs both determine the DH group ID that must be used in >> order to successfully conclude the triggered handshake. HITs, >> however, only include the OGA ID identifying a HIP DEX HIT. They do >> not include information about the specific DH group ID of the >> corresponding HI. [...] > > Something wrong here, the first sentence is contradicting with the > second and third one. > >> 5.3.2. R1 - the HIP Responder Packet >> >> [...] >> >> The R1 packet generation counter is used to determine the currently >> valid generation of puzzles. The value is increased periodically, >> and it is RECOMMENDED that it is increased at least as often as >> solutions to old puzzles are no longer accepted. > > Section 6.1 describes: "The only exceptions are that HIP DEX does not > use pre-computation of R1 packets and that RHASH is set to CMAC. As a > result, the pre- computation step in in Section 6.3 of [RFC7401] is > skipped in HIP DEX. > > I guess R1 packet generation counters are still meaningful for the > Initiator (despite Responder does not pre-generate R1s)? > >> [...] >> >> The HOST_ID parameter depends on the received DH_GROUP_LIST parameter >> and the Responder HIT in the I1 packet. Specifically, if the I1 >> contains a Responder HIT, the Responder verifies that this HIT >> matches the required DH group based on the received DH_GROUP_LIST >> parameter. > > "...included in the I1". Right? > >> 5.3.3. I2 - the Second HIP Initiator Packet >> >> [...] >> >> The HIP_CIPHER contains the single encryption transform selected by >> the Initiator that it uses to encrypt the ENCRYPTED and ENCRYPTED_KEY >> parameters. The chosen cipher MUST correspond to one of the ciphers >> offered by the Responder in the R1. All implementations MUST support >> the AES-CTR transform [RFC3686]. >> >> [...] >> >> The TRANSPORT_FORMAT_LIST parameter contains the single transport >> format type selected by the Initiator. The chosen type MUST >> correspond to one of the types offered by the Responder in the R1 >> packet. Currently, the only transport format defined is the ESP >> transport format [RFC7402]. > > Should all of the cipher suites and transport formats still be echoed > to the Responder for security reasons? See also my next comment. > >> 5.3.4. R2 - the Second HIP Responder Packet >> >> [...] >> >> The Responder repeats the DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, >> and TRANSPORT_FORMAT_LIST parameters in the R2 packet. These >> parameters MUST be the same as included in the R1 packet. The >> parameter are re-included here because the R2 packet is MACed and >> thus cannot be altered by an attacker. For verification purposes, >> the Initiator re-evaluates the selected suites and compares the >> results against the chosen ones. If the re-evaluated suites do not >> match the chosen ones, the Initiator acts based on its local policy. > > Ok, so now the full list of parameters is included, so forget about my > previous comment. > >> 6.1. Solving the Puzzle >> >> The procedures for solving and verifying a puzzle in HIP DEX are >> strongly based on the corresponding procedures in HIPv2. The only >> exceptions are that HIP DEX does not use pre-computation of R1 >> packets and that RHASH is set to CMAC. As a result, the pre- >> computation step in in Section 6.3 of [RFC7401] is skipped in HIP >> DEX. > > in in -> in > >> 6.2.1. CMAC Calculation >> >> [...] >> >> >> 5. Set Checksum and Header Length fields in the HIP header to >> original values. Note that the Checksum and Length fields >> contain incorrect values after this step. > > I guess also the values following HIP_MAC should be restored since > they were wiped in the step 2. > >> 6.3. HIP DEX KEYMAT Generation > > (this section was a bit hard to understand) > >> The HIP DEX KEYMAT process is used to derive the keys for the Master >> Key SA as well as for the Pair-wise Key SA. The keys for the Master >> Key SA are based from the Diffie-Hellman derived key, Kij, produced > > from -> on > >> The keys of the Pair-wise Key SA are not directly used in the HIP DEX >> handshake. [...] > > used -> exposed in plaintext? > >> Some payload protection mechanisms have their own >> Key Derivation Function, and if so this mechanism SHOULD be used. > > this -> such > >> The HIP DEX KEYMAT process consists of two components, CKDF-Extract >> and CKDF-Expand. The Extract function compresses a non-uniformly >> distributed key, as is the output of a Diffie-Hellman key derivation, > > as is -> such as > > >> The key derivation for the Master Key SA employs both the Extract and >> Expand phases, whereas the Pair-wise Key SA MAY need both the Extract >> and Expand phases if the key is longer than 128 bits. Otherwise, it >> only requires the Expand phase. > > Suggest: > > The key derivation for the Master Key SA employs always both the > Extract and Expand phases. The Pair-wise Key SA needs only the Extract > phase when key is smaller or equal to 128 bits, but otherwise requires > also the Expand phase. > >> The CKDF-Extract function is the following operation: >> >> CKDF-Extract(I, IKM, info) -> PRK > > What does the arrow operator signify? I thought that it produces PRK, > but PRK is actually defined below. > >> where >> >> I Random #I from the PUZZLE parameter >> IKM Input keying material, i.e., either the Diffie-Hellman >> derived key or the concatenation of the random values >> of the ENCRYPTED_KEY parameters in the same order as >> the HITs with sort(HIT-I | HIT-R) > > So how to choose between the D-H key and ENCRYPTED_KEY? Use always the > KEY if present, otherwise D-H? > >> info sort(HIT-I | HIT-R) | "CKDF-Extract" > > Is "CKDF-Extract" an octet string? > >> PRK a pseudorandom key (of RHASH_len/8 octets) >> | denotes the concatenation >> >> The pseudorandom key PRK is calculated as follows: >> >> PRK = CMAC(I, IKM | info) > > Based on this, I don't really know how to extract key material (the > arrow notation is confusing). > >> The CKDF-Expand function is the following operation: >> >> CKDF-Expand(PRK, info, L) -> OKM > > What does the arrow mean? > > Maybe name "info" as "info2" because it is different variable. > >> where >> >> PRK a pseudorandom key of at least RHASH_len/8 octets >> (either the output from the extract step or the >> concatenation of the random values of the >> ENCRYPTED_KEY parameters in the same order as the >> HITs with sort(HIT-I | HIT-R)) > > How to choose between the extract output vs encrypted key? > > Maybe you should rename this as "PRK2" in order to distinguish the > variable from the Extract phase. > >> info sort(HIT-I | HIT-R) | "CKDF-Expand" > > Is "CKDF-Expand" an octet string? > >> L length of output keying material in octets >> (<= 255*RHASH_len/8) >> | denotes the concatenation >> >> The output keying material OKM is calculated as follows: >> >> N = ceil(L/RHASH_len/8) >> T = T(1) | T(2) | T(3) | ... | T(N) >> OKM = first L octets of T >> >> where >> >> T(0) = empty string (zero length) >> T(1) = CMAC(PRK, T(0) | info | 0x01) >> T(2) = CMAC(PRK, T(1) | info | 0x02) >> T(3) = CMAC(PRK, T(2) | info | 0x03) >> ... > > The Expand was a bit more clear, but still didn't understand how to get > to the > Expanded key material due the arrow notation. > >> (where the constant concatenated to the end of each T(n) is a >> single octet.) > > Is there a max value? > >> The initial keys are drawn sequentially in the order that is >> determined by the numeric comparison of the two HITs, with the >> comparison method described in the previous paragraph. HOST_g >> denotes the host with the greater HIT value, and HOST_l the host with >> the lower HIT value. > > This is just for Master keys, right? > >> The number of bits drawn for a given algorithm is the "natural" size >> of the keys. For the mandatory algorithms, the following sizes >> apply: >> >> AES 128 or 256 bits > > I would clarify that this depends on the negotiated HIP_CIPHER. > >> 6.5. Processing Incoming I1 Packets >> >> 5. If the received Responder's HIT in the I1 packet is not NULL, the >> Responder's in the R1 packet HIT MUST match the destination HIT > > ...the Responder's HIT in the R1 packet MUST match... > >> 6.6. Processing Incoming R1 Packets >> >> [...] >> >> 1. A system receiving an R1 MUST first check to see if it has sent >> an I1 packet to the originator of the R1 packet (i.e., it has a >> HIP association that is in state I1-SENT and that is associated >> with the HITs in the R1). Unless the I1 packet was sent in >> opportunistic mode (see Section 4.1.8 of [RFC7401]), the IP >> addresses in the received R1 packet SHOULD be ignored by the R1 >> processing and, when looking up the right HIP association, the > > right -> correct > >> 8. The R1 packet may have the A-bit set - in this case, the system >> MAY choose to refuse it by dropping the R1 packet and returning >> to state UNASSOCIATED. The system SHOULD consider dropping the >> R1 packet only if it used a NULL HIT in the I1 packet. > > I didn't understand the logic in the last sentence. > >> Note that step 4 from the original processing rules of HIPv2 >> (signature verification) has been removed in the above processing >> rules for HIP DEX. Moreover, step 7 of the HIPv2 processing rules >> has been adapted to account for the fact that HIP DEX uses ECDH >> public keys as HIs. > > Step 7 in the *original* processing rules, what is the ordinal in DEX? > It is not 7. > >> 6.7. Processing Incoming I2 Packets >> >> [...] >> >> 5. If the system's state machine is in the I2-SENT state, the >> system MUST make a comparison between its local and sender's >> HITs (similarly as in Section 6.3). If the local HIT is smaller >> than the sender's HIT, it should drop the I2 packet, use the >> peer Diffie-Hellman key, ENCRYPTED_KEY keying material and nonce >> #I from the R1 packet received earlier, and get the local >> Diffie-Hellman key, ENCRYPTED_KEY keying material, and nonce #J >> from the I2 packet sent to the peer earlier. Otherwise, the >> system should process the received I2 packet and drop any >> previously derived Diffie-Hellman keying material Kij and >> ENCRYPTED_KEY keying material it might have generated upon >> sending the I2 packet previously. The peer Diffie-Hellman key, >> ENCRYPTED_KEY, and the nonce #J are taken from the just arrived >> I2 packet. The local Diffie-Hellman key, ENCRYPTED_KEY keying >> material, and the nonce #I are the ones that were sent earlier >> in the R1 packet. > > Please replace "sender" with "peer" (or remote host) in this section > for more symmetric terminology. > > get -> obtain > >> 11. The implementation SHOULD also verify that the Initiator's HIT >> in the I2 packet corresponds to the Host Identity sent in the I2 >> packet. (Note: some middleboxes may not be able to make this >> verification.) > > Why SHOULD? Why not MUST? I think we're talking about end-hosts here > anyway. > >> Note that steps 11 (encrypted HOST_ID) and 15 (signature >> verification) from the original processing rules of HIPv2 have been >> removed in the above processing rules for HIP DEX. Moreover, step 10 >> of the HIPv2 processing rules has been adapted to account for >> optional extension of the retransmission mechanism. Step 16 has been >> added to the processing rules. > > ...in this document. > >> 6.10. Processing UPDATE, CLOSE, and CLOSE_ACK Packets > >> UPDATE, CLOSE, and CLOSE_ACK packets are handled similarly in HIP DEX >> as in HIP BEX (see Sections 6.11, 6.12, 6.14, and 6.15 of [RFC7401]). >> The only difference is the that the HIP_SIGNATURE is never present >> and, therefore, is not required to be processed by the receiving >> party. > > How does rekeying work with the extract and expand functions? > >> 6.11. Handling State Loss > >> Implementors MAY choose to use non-volatile, secure storage for HIP >> states in order for them to survive a system reboot. If no secure >> storage capabilities are available, the system SHOULD delete the >> corresponding HIP state, including the keying material. If the >> implementation does drop the state (as RECOMMENDED), it MUST also >> drop the peer's R1 generation counter value, unless a local policy >> explicitly defines that the value of that particular host is stored. >> An implementation MUST NOT store a peer's R1 generation counters by >> default, but storing R1 generation counter values, if done, MUST be >> configured by explicit HITs. > > MUST NOT -> SHOULD? Otherwise the part after this is kinda void. > >> 7. HIP Policies > >> There are a number of variables that will influence the HIP exchanges >> that each host must support. All HIP DEX implementations SHOULD >> provide for an ACL of Initiator's HI to Responder's HI. This ACL >> SHOULD also include preferred transform and local lifetimes. >> Wildcards SHOULD also be supported for this ACL. > > Why ACLs are mandatory? > > ACL -> ACL consisting of > >> The value of #K used in the HIP R1 must be chosen with care. Values >> of #K that are too high will exclude clients with weak CPUs because >> these devices cannot solve the puzzle within a reasonable amount of >> time. #K should only be raised if a Responder is under high load, >> i.e., it cannot process all incoming HIP handshakes any more. If a >> Responder is not under high load, #K SHOULD be 0. > >> 8. Security Considerations > >> o The HIP DEX HIT generation may present new attack opportunities. > > They cannot be used in ACLs. Maybe this could be mentioned. Can this > be mitigated by always using full HIs? > > > Some additional comments related to Appendix: > > I think you could reference the SLIMFIT extension from Rene Hummen in > the appendix. And possibly mention the following related work > extending DEX that was done in the context of Convince Celtic+ > project: > > P. Porambage, A. Braeken, P. Kumar, A. Gurtov and M. Ylianttila, > "Efficient Key Establishment for Constrained IoT Devices with > Collaborative HIP-Based Approach," 2015 IEEE Global Communications > Conference (GLOBECOM), San Diego, CA, 2015, pp. 1-6. doi: > 10.1109/GLOCOM.2015.7417094 > > The work includes also benchmarks on energy consumption. > > P.S. My review can be credited to Convince Celtic+. > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Mon Apr 18 06:10:56 2016 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 37C1B12D678 for ; Mon, 18 Apr 2016 06:10:55 -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 a_kT5je9Sef7 for ; Mon, 18 Apr 2016 06:10:53 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D1F12D5C3 for ; Mon, 18 Apr 2016 06:10:51 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-ac-5714dcd85cb9 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 29.26.12926.8DCD4175; Mon, 18 Apr 2016 15:10:49 +0200 (CEST) Received: from [131.160.51.22] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Mon, 18 Apr 2016 15:10:48 +0200 To: References: <56CDBDA1.7050207@ericsson.com> <3CEE85EA-C996-4B28-B0A3-DA8B158BD159@temperednetworks.com> <56D1630A.7000209@ericsson.com> <56D45895.2060503@ericsson.com> <56DD757B.8050002@ericsson.com> <20160328235106.GA79648@cowbell.employees.org> From: Miika Komu Organization: Ericsson AB Message-ID: <5714DCD8.7050907@ericsson.com> Date: Mon, 18 Apr 2016 16:10:48 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160328235106.GA79648@cowbell.employees.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060500010207000509020509" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM2K7ru7NOyLhBt/vs1hMXTSZ2YHRY8mS n0wBjFFcNimpOZllqUX6dglcGdf617AVbHesmL/5N1sD41/rLkZODgkBE4kfb9vZIGwxiQv3 1gPZXBxCAkcYJW7t/M8MkhASWM0ocex1BYgtLGAvcXLfLXYQW0RAVGLKh9PMEA37mCR6vn9n AUmwCWhJrLpzHayZX0BSYkPDbjCbV0BbYs/aLawgNouAqsSt06fA4qICERJP5p5khKgRlDg5 8wnYHE4Ba4nrrzoYQRYwC3QzSvQ1PmLqYuQA2qYicfFY8ARGgVlIWmYhKwNJMAvYStyZu5sZ wtaWWLbwNZRtLTHj10E2CFtRYkr3Q3YI21Ti9dGPjBC2scSydX/ZFjByrGIULU4tTspNNzLW Sy3KTC4uzs/Ty0st2cQIDP+DW36r7mC8/MbxEKMAB6MSD28Cu0i4EGtiWXFl7iFGFaA5jzas vsAoxZKXn5eqJMJrch0ozZuSWFmVWpQfX1Sak1p8iFGag0VJnDc78l+YkEB6YklqdmpqQWoR TJaJg1OqgdFMYeXHx8nKX7Yxt89cwr/o05YSdjfeOJ0D3fHNjIVvxKd/LPsabPVjnY1RXfuH Wd3zX/94bKlt5H2x+LDn21nH+cUC67dFK7Wb25y8oxcw2+e8eZFRrNP96UeynsjqdMvo6T+M 06hnnCXcNq3tTtaxw62eqgwKi1bLvZocfWgN/6k4HvnQOCWW4oxEQy3mouJEAAyK22SHAgAA Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:10:55 -0000 --------------ms060500010207000509020509 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi, On 03/29/2016 02:51 AM, Derek Fawcus wrote: > On Mon, Mar 07, 2016 at 02:35:07pm +0200, Gonzalo Camarillo wrote: >> First he will look into adding clarifications to the existing draft >> while still referencing the old RFC. If the group is not happy with th= e >> readability after the editorial pass (or our AD does not finally let u= s >> downref the old RFC), we can consider bringing material from the old R= FC >> directly into the new one. > > Sorry, that I'm quite late in looking at these, but have been doing > so recently... > > I have to say that I find the it difficult to decode simply because > of having to refer to 3 (the draft, 5770, 5245) plus possibly the > STUN/TURN docs at once. > > I'd certainly find it easier to comprehend if the text from 5770 was > incorporated (suitably modified to account for not doing STUN/TURN) > within the draft. That way the references to the significant pieces > of 5245 text would be easier to nail down. > > As it is, I currently find it a bit like reading an Act of Parliament!= > > e.g. $3.8 Connectivity Checks > refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to= > $5.7 of 5245 and $7 of 5245, where the exceptions (use of UPDATE inste= ad > of STUN) have to be applied to that $7 referencing 5389, so possibly > I don't have to read 5389, since hopefully it would just be packet form= ats. > >> I would also like the group to comment on the following two proposals:= >> >> 1) the draft will allow implementers to use HIP native relays only. In= >> addition, the use of STUN and TURN relays will be optional. > > I'd suggest the draft be native only, but say with an appendix referen= cing > 5770 for use of STUN/TURN, maybe indicating which bits of the 5770 > to take heed of. > >> 2) in addition to covering the base exchange, the draft will also cove= r >> the mobility readdressing exchange. > > Not having read that recently, I can't really comment. I am going to join the author list and help to improve the draft=20 according the comments on the mailing list. Another change we plan to do is to adjust the current specification to=20 new ice-bis recommendations (smaller delays, for instance). This will=20 cause some delays because it's not yet an RFC. --------------ms060500010207000509020509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDE4MTMxMDQ4 WjAvBgkqhkiG9w0BCQQxIgQgYXEWxk8r/Cmu+oF/dow4qhBHCASYlqU4gns0pDwAHKswXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQARpHWFBsH9 wVVa9q3tNmENJYZnBD90kJOQDDVoOnQP8kzzDrNfy5VFbqYXxLDQqM3Pl00tJRVW3r4BcJbq qaJfFGNZmdXxpvAvurcj7b+WHFtU7OBS2jRtWG/j7cSLgXIwQw4/N1LGS+5i/4PX68oCmNIE mBOxoyvPTA1GijwFVvSCZnjiDNaEGLG/vqBPfWWEQIBEl2anB/5VFH63oGVnHhah92N2DLga 3QasLpR76WoHTHfQpXMeTGdu3E0awa7wma0CnfuqSZokh2VS0H5iQ/EkUwZunMkQAHKlWh7F O0DnMb/ikrjU7yKlioBe8RBMVtqaVtO+X68leENnwkZxAAAAAAAA --------------ms060500010207000509020509-- From nobody Mon Apr 18 06:13:49 2016 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 8B6EE12D0A7 for ; Mon, 18 Apr 2016 06:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 WfAFbJkKW-B1 for ; Mon, 18 Apr 2016 06:13:46 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F3312DE2F for ; Mon, 18 Apr 2016 06:13:32 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-3e-5714dd7ab8d2 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 42.70.16963.A7DD4175; Mon, 18 Apr 2016 15:13:30 +0200 (CEST) Received: from [131.160.50.191] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.248.2; Mon, 18 Apr 2016 15:13:29 +0200 To: Miika Komu , References: <56CDBDA1.7050207@ericsson.com> <3CEE85EA-C996-4B28-B0A3-DA8B158BD159@temperednetworks.com> <56D1630A.7000209@ericsson.com> <56D45895.2060503@ericsson.com> <56DD757B.8050002@ericsson.com> <20160328235106.GA79648@cowbell.employees.org> <5714DCD8.7050907@ericsson.com> From: Gonzalo Camarillo Message-ID: <5714DD79.3020202@ericsson.com> Date: Mon, 18 Apr 2016 16:13:29 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5714DCD8.7050907@ericsson.com> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM2K7rm7VXZFwg0kz+S2mLprM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIm/b7IVHBateHvlImMD4w+BLkZODgkBE4nfvx8xQdhiEhfu rWfrYuTiEBI4wihxsGUiK4SzhlGi/Ug3O0iVsIC9xMl9t8BsEQFriQ+XlzNBFD1gkliybBYb SIJNwEJiy637LCA2r4C2xO1t98EaWARUJS4tXM0MYosKxEg0PjjFBFEjKHFy5hOwek4BHYne mZ1gNcwCBhJHFs1hhbDlJba/nQMWFwKaufxZC8sERoFZSNpnIWmZhaRlASPzKkbR4tTi4tx0 IyO91KLM5OLi/Dy9vNSSTYzAMDy45bfVDsaDzx0PMQpwMCrx8Cawi4QLsSaWFVfmHmKU4GBW EuGVuQMU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzpsT+S9MSCA9sSQ1OzW1ILUIJsvEwSnVwOgg oLx6caTBVen2nPut97//LG7POhRQuec1j37HhPZ5O5f9+yIn1Z6c865niRUT2w3jko2rPL5X +a+/EPz1xeGcNxP5nq3/N1n8dHNAXLLtxpnv/8wOnzs/00l10qa7R3R6Qvd/4HNQPfFkrZT/ AqV9qavMpsz/trt7ZZNq3FyFRo6UQ7f+tNQrsRRnJBpqMRcVJwIAj7K2QD8CAAA= Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:13:47 -0000 Hi, yes, the plan of the ICE WG with ICE bis is that it will be WGLCed after the Berlin IETF meeting. That should give us enough time to get this spec into a pretty good shape. Cheers, Gonzalo On 18/04/2016 4:10 PM, Miika Komu wrote: > Hi, > > On 03/29/2016 02:51 AM, Derek Fawcus wrote: >> On Mon, Mar 07, 2016 at 02:35:07pm +0200, Gonzalo Camarillo wrote: >>> First he will look into adding clarifications to the existing draft >>> while still referencing the old RFC. If the group is not happy with the >>> readability after the editorial pass (or our AD does not finally let us >>> downref the old RFC), we can consider bringing material from the old RFC >>> directly into the new one. >> >> Sorry, that I'm quite late in looking at these, but have been doing >> so recently... >> >> I have to say that I find the it difficult to decode simply because >> of having to refer to 3 (the draft, 5770, 5245) plus possibly the >> STUN/TURN docs at once. >> >> I'd certainly find it easier to comprehend if the text from 5770 was >> incorporated (suitably modified to account for not doing STUN/TURN) >> within the draft. That way the references to the significant pieces >> of 5245 text would be easier to nail down. >> >> As it is, I currently find it a bit like reading an Act of Parliament! >> >> e.g. $3.8 Connectivity Checks >> refers to $4.6 of 5770 with some exceptions, $4.6 of 5770 refers to >> $5.7 of 5245 and $7 of 5245, where the exceptions (use of UPDATE instead >> of STUN) have to be applied to that $7 referencing 5389, so possibly >> I don't have to read 5389, since hopefully it would just be packet >> formats. >> >>> I would also like the group to comment on the following two proposals: >>> >>> 1) the draft will allow implementers to use HIP native relays only. In >>> addition, the use of STUN and TURN relays will be optional. >> >> I'd suggest the draft be native only, but say with an appendix >> referencing >> 5770 for use of STUN/TURN, maybe indicating which bits of the 5770 >> to take heed of. >> >>> 2) in addition to covering the base exchange, the draft will also cover >>> the mobility readdressing exchange. >> >> Not having read that recently, I can't really comment. > > I am going to join the author list and help to improve the draft > according the comments on the mailing list. > > Another change we plan to do is to adjust the current specification to > new ice-bis recommendations (smaller delays, for instance). This will > cause some delays because it's not yet an RFC. > > > > _______________________________________________ > Hipsec mailing list > Hipsec@ietf.org > https://www.ietf.org/mailman/listinfo/hipsec > From nobody Tue Apr 19 10:12:12 2016 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 6BA8312EC75 for ; Tue, 19 Apr 2016 10:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 wLbmZbDROD4k for ; Tue, 19 Apr 2016 10:12:10 -0700 (PDT) Received: from mxout26.s.uw.edu (mxout26.s.uw.edu [140.142.234.176]) (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 D86B112EBB0 for ; Tue, 19 Apr 2016 10:12:10 -0700 (PDT) Received: from hymn04.u.washington.edu (hymn04.u.washington.edu [140.142.8.72]) by mxout26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u3JHBajJ029101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Apr 2016 10:11:36 -0700 Received: from hymn04.u.washington.edu (localhost [127.0.0.1]) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id u3JHBUuh031099; Tue, 19 Apr 2016 10:11:30 -0700 Received: from localhost (Unknown UID 17623@localhost) by hymn04.u.washington.edu (8.14.4+UW14.03/8.14.4+Submit-local) with ESMTP id u3JHBUkF031083; Tue, 19 Apr 2016 10:11:30 -0700 X-Auth-Received: from [73.239.169.224] by hymn04.u.washington.edu via HTTP; Tue, 19 Apr 2016 10:11:30 PDT Date: Tue, 19 Apr 2016 10:11:30 -0700 (PDT) From: Tom Henderson To: hip WG , Miika Komu Message-ID: User-Agent: Web Alpine 2.01 (LRH 1302 2010-07-20) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT X-PMX-Version: 6.2.1.2493963, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.19.170315 X-PMX-Server: mxout26.s.uw.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_00_01 0.05, HTML_00_10 0.05, BODY_SIZE_6000_6999 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_CTA_URI_FOUND 0, NO_URI_FOUND 0, NO_URI_HTTPS 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __FRAUD_BADTHINGS 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __USER_AGENT 0' Archived-At: Subject: Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 17:12:12 -0000 Hi Miika, thanks for the review; some responses are inline below. I will continue later in a second message. - Tom On 04/17/2016 01:26 PM, Miika Komu wrote: > Hi, > > I read through ietf-hip-rfc5206-bis-10, and it is in pretty good shape. > Below are a few nits. > > > 3.1. Operating Environment > > > > [...] > > > > Consider next a mobility event, in which a host moves to another IP > > address. Two things must occur in this case. First, the peer must > > be notified of the address change using a HIP UPDATE message. > > Second, each host must change its local bindings at the HIP sublayer > > (new IP addresses). It may be that both the SPIs and IP addresses > > are changed simultaneously in a single UPDATE; the protocol described > > herein supports this. However, elements of procedure to recover from > > I think simultaneous mobility is covered as already mentioned in the intro? Fixed > > > 3.2.3. Mobility messaging through rendezvous server > > > > 3. A host receiving an UPDATE packet MUST be prepared to process the > > FROM and RVS_HMAC parameters, and MUST include a VIA_RVS > > parameter in the UPDATE reply that contains the ACK of the UPDATE > > SEQ. > > (I would add that the return routability test should be invoked to the > end-host's addresses rather than the ones in VIA_RVS) I added another numbered item: An initiator receiving a VIA_RVS in the UPDATE reply should initiate address reachability tests (described later in this document) towards the end host's address and not towards the address included in the VIA_RVS. > > > 4. This scenario requires that hosts using rendezvous servers also > > take steps to update their current address bindings with their > > rendezvous server upon a mobility event. > > [I-D.ietf-hip-rfc5204-bis] does not specify how to update the > > rendezvous server with a client host's new address. > > [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host may > > send a REG_REQUEST in either an I2 packet (if there is no active > > association) or an UPDATE packet (if such association exists). > > (Maybe this should have been actually step 0) It really should not be in the sequential list; I moved it outside of the list. > > > The procedures described in [I-D.ietf-hip-rfc5203-bis] for > > sending a REG_REQUEST and REG_RESPONSE to the rendezvous server > > apply also to this mobility scenario. > > This was a bit vague, how? Here is how I clarified it; do you agree? According to procedures described in [I-D.ietf-hip-rfc5203-bis], if a mobile host has an active registration, it may use mobility updates specified herein, within the context of that association, to readdress the association. > > > 3.2.4. Network Renumbering > > > > It is expected that IPv6 networks will be renumbered much more often > > than most IPv4 networks. From an end-host point of view, network > > renumbering is similar to mobility. > > ...and? added " , and procedures described herein also apply to notify a peer of a changed address." > > > 3.3. Other Considerations > > > > 3.3.1. Address Verification > > > > When a HIP host receives a set of locators from another HIP host in a > > LOCATOR_SET, it does not necessarily know whether the other host is > > actually reachable at the claimed addresses. In fact, a malicious > > peer host may be intentionally giving bogus addresses in order to > > cause a packet flood towards the target addresses [RFC4225]. > > Therefore, the HIP host must first check that the peer is reachable > > at the new address. > > > > An additional potential benefit of performing address verification is > > to allow middleboxes in the network along the new path to obtain the > > peer host's inbound SPI. > > > > Address verification is implemented by the challenger sending some > > piece of unguessable information to the new address, and waiting for > > some acknowledgment from the Responder that indicates reception of > > the information at the new address. This may include the exchange of > > a nonce, or the generation of a new SPI and observation of data > > arriving on the new SPI. > > I suggest would move the second paragraph after the third one. OK > > > 3.3.2. Credit-Based Authorization > > > > On this basis, rather than eliminating malicious packet redirection > > in the first place, Credit-Based Authorization prevents > > amplifications. This is accomplished by limiting the data a host can > > send to an unverified address of a peer by the data recently received > > from that peer. Redirection-based flooding attacks thus become less > > attractive than, for example, pure direct flooding, where the > > attacker itself sends bogus packets to the victim. > > Reference section 5.6? OK > > > 4.3. UPDATE Packet with Included LOCATOR_SET > > > > A number of combinations of parameters in an UPDATE packet are > > possible (e.g., see Section 3.2). In this document, procedures are > > defined only for the case in which one LOCATOR_SET and one ESP_INFO > > parameter is used in any HIP packet. Furthermore, the LOCATOR_SET > > SHOULD list all of the locators that are active on the HIP > > association (including those on SAs not covered by the ESP_INFO > > parameter). > > What do you mean by "including those on SAs..."? This is related to multihoming and can be deleted here. > > > Any UPDATE packet that includes a LOCATOR_SET parameter > > SHOULD include both an HMAC and a HIP_SIGNATURE parameter. > > Please add a paragraph break here. OK > > > The UPDATE MAY also include a HOST_ID parameter (which may be useful for > > middleboxes inspecting the HIP messages for the first time). If the > > UPDATE includes the HOST_ID parameter, the receiving host MUST verify > > that the HOST_ID corresponds to the HOST_ID that was used to > > establish the HIP association, and the HIP_SIGNATURE must verify with > > the public key assodiated with this HOST_ID parameter. > > assodiated -> associated > > Please add a paragraph break here. OK > > > The relationship between the announced Locators and any ESP_INFO > > parameters present in the packet is defined in Section 5.2. This > > draft does not support any elements of procedure for sending more > > than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE. > > draft -> document OK (remainder of comments will be addressed in a second message) From nobody Wed Apr 20 01:19:13 2016 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 DBED212B05F for ; Wed, 20 Apr 2016 01:19:12 -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_H4=-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 Cg0bOHVolhsF for ; Wed, 20 Apr 2016 01:19:02 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43E7812DD80 for ; Wed, 20 Apr 2016 01:19:02 -0700 (PDT) X-AuditID: c1b4fb3a-f795d6d000004243-9a-57173b731cb4 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 52.D1.16963.37B37175; Wed, 20 Apr 2016 10:19:00 +0200 (CEST) Received: from [153.88.190.38] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.248.2; Wed, 20 Apr 2016 10:18:59 +0200 To: hip WG References: From: Miika Komu Organization: Ericsson AB Message-ID: <57173B73.3020808@ericsson.com> Date: Wed, 20 Apr 2016 11:18:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050006010501040003040101" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM2K7om6JtXi4wcUv7BZTF01mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqw3j5gLPqdXzFyzjqWBcWdEFyMnh4SAicTmBY/ZIWwxiQv3 1rN1MXJxCAkcYZR4uqGDGSQhJLCaUeLdv6IuRg4OYQFLifs7i0DCIgIyEhs2vWCFKPGU+Dhv N9gcNgEtiVV3roO18gtISmxo2A1m8wpoS8z59g7MZhFQlVi9/C4LiC0qECHxZO5JRogaQYmT M5+AxTkFvCTeTWgBu4dZoJtR4ual0+wgNwgJqEhcPBY8gVFgFpKWWcjKQBLMArYSd+buZoaw tSWWLXwNZVtLzPh1kA3CVpSY0v0Qqt5U4vXRj4wQtrHEsnV/2RYwcqxiFC1OLS7OTTcy0kst ykwuLs7P08tLLdnECAz9g1t+W+1gPPjc8RCjAAejEg+vwkTRcCHWxLLiytxDjCpAcx5tWH2B UYolLz8vVUmEt9hCPFyINyWxsiq1KD++qDQntfgQozQHi5I4b07kvzAhgfTEktTs1NSC1CKY LBMHp1QDo5K0qvUj80t5z1weRGkE9zrqXq564+rxY8PZtWkOEw3Tflp3trWZlJgUzBOcu9fU ZuXd5+L8kcf/ONvGK744Lvs+6tdZB24PBeF96n+lav5bVF8Mm7auxmvp5gXFPxgWbtt4oo4p f7HfqwfRs44m7LDZ9llTPevNnneatvL5Bk8LHnHVTFisq8RSnJFoqMVcVJwIAAm4R3WFAgAA Archived-At: Subject: Re: [Hipsec] a review of ietf-hip-rfc5206-bis-10 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 08:19:13 -0000 --------------ms050006010501040003040101 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Hi Tom, your changes are fine, thanks for the quick response. On 04/19/2016 08:11 PM, Tom Henderson wrote: > Hi Miika, thanks for the review; some responses are inline below. I wi= ll continue later in a second message. > > - Tom > > On 04/17/2016 01:26 PM, Miika Komu wrote: >> Hi, >> >> I read through ietf-hip-rfc5206-bis-10, and it is in pretty good shape= =2E >> Below are a few nits. >> >> > 3.1. Operating Environment >> > >> > [...] >> > >> > Consider next a mobility event, in which a host moves to another I= P >> > address. Two things must occur in this case. First, the peer mus= t >> > be notified of the address change using a HIP UPDATE message. >> > Second, each host must change its local bindings at the HIP sublay= er >> > (new IP addresses). It may be that both the SPIs and IP addresses= >> > are changed simultaneously in a single UPDATE; the protocol descri= bed >> > herein supports this. However, elements of procedure to recover f= rom >> >> I think simultaneous mobility is covered as already mentioned in the i= ntro? > > Fixed > >> >> > 3.2.3. Mobility messaging through rendezvous server >> > >> > 3. A host receiving an UPDATE packet MUST be prepared to process = the >> > FROM and RVS_HMAC parameters, and MUST include a VIA_RVS >> > parameter in the UPDATE reply that contains the ACK of the UPDATE >> > SEQ. >> >> (I would add that the return routability test should be invoked to the= >> end-host's addresses rather than the ones in VIA_RVS) > > I added another numbered item: > > An initiator receiving a VIA_RVS in the UPDATE reply should > initiate address reachability tests (described later in this= > document) towards the end host's address and not towards the= > address included in the VIA_RVS. > >> >> > 4. This scenario requires that hosts using rendezvous servers als= o >> > take steps to update their current address bindings with their >> > rendezvous server upon a mobility event. >> > [I-D.ietf-hip-rfc5204-bis] does not specify how to update the >> > rendezvous server with a client host's new address. >> > [I-D.ietf-hip-rfc5203-bis] Section 3.2 describes how a host may >> > send a REG_REQUEST in either an I2 packet (if there is no active >> > association) or an UPDATE packet (if such association exists). >> >> (Maybe this should have been actually step 0) > > It really should not be in the sequential list; I moved it outside of t= he list. >> >> > The procedures described in [I-D.ietf-hip-rfc5203-bis] for >> > sending a REG_REQUEST and REG_RESPONSE to the rendezvous server >> > apply also to this mobility scenario. >> >> This was a bit vague, how? > > Here is how I clarified it; do you agree? > > According to procedures described in [I-D.ietf-hip-rfc5203-b= is], > if a mobile host > has an active registration, it may use mobility updates spec= ified > herein, within the context of that association, to readdress= the > association. > >> >> > 3.2.4. Network Renumbering >> > >> > It is expected that IPv6 networks will be renumbered much more oft= en >> > than most IPv4 networks. From an end-host point of view, network >> > renumbering is similar to mobility. >> >> ...and? > > added " , and procedures described herein also apply to notify a peer = of > a changed address." >> >> > 3.3. Other Considerations >> > >> > 3.3.1. Address Verification >> > >> > When a HIP host receives a set of locators from another HIP host i= n a >> > LOCATOR_SET, it does not necessarily know whether the other host i= s >> > actually reachable at the claimed addresses. In fact, a malicious= >> > peer host may be intentionally giving bogus addresses in order to >> > cause a packet flood towards the target addresses [RFC4225]. >> > Therefore, the HIP host must first check that the peer is reachabl= e >> > at the new address. >> > >> > An additional potential benefit of performing address verification= is >> > to allow middleboxes in the network along the new path to obtain t= he >> > peer host's inbound SPI. >> > >> > Address verification is implemented by the challenger sending some= >> > piece of unguessable information to the new address, and waiting f= or >> > some acknowledgment from the Responder that indicates reception of= >> > the information at the new address. This may include the exchange= of >> > a nonce, or the generation of a new SPI and observation of data >> > arriving on the new SPI. >> >> I suggest would move the second paragraph after the third one. > > OK > >> >> > 3.3.2. Credit-Based Authorization >> > >> > On this basis, rather than eliminating malicious packet redirectio= n >> > in the first place, Credit-Based Authorization prevents >> > amplifications. This is accomplished by limiting the data a host = can >> > send to an unverified address of a peer by the data recently recei= ved >> > from that peer. Redirection-based flooding attacks thus become le= ss >> > attractive than, for example, pure direct flooding, where the >> > attacker itself sends bogus packets to the victim. >> >> Reference section 5.6? > > OK > >> >> > 4.3. UPDATE Packet with Included LOCATOR_SET >> > >> > A number of combinations of parameters in an UPDATE packet are >> > possible (e.g., see Section 3.2). In this document, procedures ar= e >> > defined only for the case in which one LOCATOR_SET and one ESP_INF= O >> > parameter is used in any HIP packet. Furthermore, the LOCATOR_SET= >> > SHOULD list all of the locators that are active on the HIP >> > association (including those on SAs not covered by the ESP_INFO >> > parameter). >> >> What do you mean by "including those on SAs..."? > > This is related to multihoming and can be deleted here. > >> >> > Any UPDATE packet that includes a LOCATOR_SET parameter >> > SHOULD include both an HMAC and a HIP_SIGNATURE parameter. >> >> Please add a paragraph break here. > > OK > >> >> > The UPDATE MAY also include a HOST_ID parameter (which may be usef= ul for >> > middleboxes inspecting the HIP messages for the first time). If t= he >> > UPDATE includes the HOST_ID parameter, the receiving host MUST ver= ify >> > that the HOST_ID corresponds to the HOST_ID that was used to >> > establish the HIP association, and the HIP_SIGNATURE must verify w= ith >> > the public key assodiated with this HOST_ID parameter. >> >> assodiated -> associated >> >> Please add a paragraph break here. > > OK >> >> > The relationship between the announced Locators and any ESP_INFO >> > parameters present in the packet is defined in Section 5.2. This >> > draft does not support any elements of procedure for sending more >> > than one LOCATOR_SET or ESP_INFO parameter in a single UPDATE. >> >> draft -> document > > OK > > (remainder of comments will be addressed in a second message) > --------------ms050006010501040003040101 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DKMwggXlMIIDzaADAgECAhAJdtiEOz4F3oNPssxObH7GMA0GCSqGSIb3DQEBBQUAMDoxETAP BgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MB4XDTE0MTIxNTEyNDQwMVoXDTE3MTIxNTEyNDQwMFowYjERMA8GA1UECgwIRXJpY3Nzb24x EzARBgNVBAMMCk1paWthIEtvbXUxJjAkBgkqhkiG9w0BCQEWF21paWthLmtvbXVAZXJpY3Nz b24uY29tMRAwDgYDVQQFEwdlbWlpa29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAsf2pgwYbVXxhx+wwvwrS5q56tLoEhnBUsb3JG3KHYATjfQryyJsDfn90YHMl49fXFORD tFO1PPA+QB22yusgCLhjgawckYn3XBzipClxTq1UHxNq01i/RzBotdrVWYMyP4KmsBzsg/vp 0Bu5KjltP6VBGpcOi8juVeXL10uNh4XpnBbaEq2uViZJOH9+mSr0IEgh4y/lEZKnlIGpcy3v lYL4S4Vhm8Ix9X8INveWuTMdo2od1j9fdEJgtv3cg5KN2+h+pI3oN8n5ikv1xs5kaDCYFunL UnMDglkcAT8k1ebqLV0jQUNSlvDCB2hrOzVFPyEycb0ZNbX1AkOTVnlrNwIDAQABo4IBvTCC AbkwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50ZWxpYS5jb20vZXJpY3Nz b25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0MCgGCCsGAQUFBzABhhxo dHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAChjxodHRwOi8vY2EudHJ1 c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jZXIwIgYDVR0R BBswGYEXbWlpa2Eua29tdUBlcmljc3Nvbi5jb20wVQYDVR0gBE4wTDBKBgwrBgEEAYIPAgMB ARIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMB0GA1UdDgQWBBQTnHDg 6XexOtdZ/qMkn3QHKZCVZDAfBgNVHSMEGDAWgBSxDcrURrevhgLDL28Gyg52cX9LNzAOBgNV HQ8BAf8EBAMCBaAwDQYJKoZIhvcNAQEFBQADggIBALSVMD6C/sZZz43wJ2r/Hp8BtBigpKc6 CuX60vmkzQ8vGrxeNbPJmkC56FSeGtFo85DtF56xyBd704T18jr1tHTXra8cNP37qABYzgaL aLuGjtqcOnGQY//0ZQfLJBfKJnlJHX9ZB+QFPbhwpOFm9QM2oRYFse0Gjc8LV3WJ0jMUMvZD FyYoZeQ+sak+mObsTRfkR2vsuuB4Elo4MSudCmZqqFUU7gBmp36G2ySJLt/tJlJDld+egJJP 1gXnGkwW2n33Gkcy+SVLj0CSTyy76GibPp72AiuR/wz+GIaCgQ3APVbWXkB3ld4avno+Mq2u 6+2qYphYsmYwIs5SUsh6Zn1OQWNKUtbZbs2z4ALQbA3rHmndI8eLf4z7ZqML6UBzrQjukWi0 6D8yV7OXLz/TzBrp1sdPpNpDVSEWmuC0dJ3Ro8UJOLiO91KtLKwTYOPVlg+u62A5vYN6DVyT nBksz5CpUiVN7x3DDAcjarORQnteoIwBaOeZd/JZJbr900UEOmt9aLXnh8vFZOOx7db0Xccb WO473yOnt/Kr9XX5t2kvFQnNSEI3RkFqM06z+r5WiZd+BhGJPSU80QNOJzzoEXT69DihhWhF pSirFDV6CdUSxKoFD/8qIkB2QXuQUESN0WUBuGy2HOuIqnx+BIR5fGFsaiFEY5pXLHeSvByA b3yTMIIGtjCCBJ6gAwIBAgIRAKAMy8ybmZjs4jpw9HzBwFkwDQYJKoZIhvcNAQEFBQAwNzEU MBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRlbGlhU29uZXJhIFJvb3QgQ0EgdjEw HhcNMTQwNTI3MDc0NjIxWhcNMjQwNTI3MDc0NjIxWjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjCCAiIwDQYJKoZIhvcNAQEB BQADggIPADCCAgoCggIBANq6U+tfSJZTn4k46qN13HgaeXXsMmGSWShc6A5IEyFboXMZW3lF Hso+/6uO3ZilvB2ipZJhrhU+RL/va+5Chay/PZq9ZZeE9N03OsHfOzlwk7uwojJ34tHLiX/y QoriI+b5DXxfIYXTFO5zlZLdaIxJwlLEQp0g4/zF6EGtodlpusaH07FAcLiIEeTMPRgXcn+8 GoFOvtuVHNh/WHePlrupUgcI9/P54ITXvmZF6xcNBEjsu8yJm1VqqK0GXSgAmInJ4Ga8S6ME 2wgSBRDolxAUbmfLQRrMvLC/tyXBvuLO8uChdzpIWt3QPtMYm2R2V1Um0zANhenIUwYCKNPq 5/yHaS48jCsOBAU0TIhBnirnZmlEbC6ALqwzGAcQMaMD8LFf1oLlWLUQxEmI4YXqBXdP5XnI cMdIEF5BtUBebzBJMMF9dDB2uj8BeoRPSYbpGl7irYUYFpq4TyocQ7qpHdYASC+NV8VTaTrF nHWqa/CGRdp3GHpkgxfOBvpamOK8udHQYQo2uA3YNd2+j7p4C3jkGG+Z6RrZOskPEwtaIHLx BiA141dhCy5EScOyNajrAXQupsDnvr2ib2ef+4nObPFvedPWIe57lyj0n3e1rTqTGIBIe9wj NnAA6MqeaTS9HchPtBvOrah/cTWzXzGjwMz0P3UJqTQ2r5EAu12/W5kpAgMBAAGjggG4MIIB tDCBigYIKwYBBQUHAQEEfjB8MC0GCCsGAQUFBzABhiFodHRwOi8vb2NzcC50cnVzdC50ZWxp YXNvbmVyYS5jb20wSwYIKwYBBQUHMAKGP2h0dHA6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlh c29uZXJhLmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNlcjASBgNVHRMBAf8ECDAGAQH/AgEA MFUGA1UdIAROMEwwSgYMKwYBBAGCDwIDAQECMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMEsGA1UdHwREMEIwQKA+oDyGOmh0 dHA6Ly9jcmwtMy50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j cmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA4GA1UdDwEB/wQEAwIBBjAdBgNV HQ4EFgQUsQ3K1Ea3r4YCwy9vBsoOdnF/SzcwHwYDVR0jBBgwFoAU8I9ZOACz9Y+algzV6/p7 qhfoExIwDQYJKoZIhvcNAQEFBQADggIBAG4HIGyvrHc9kEKyYZtxJn9cv7S2dUxuUiegmAvU GHc+JGJyB2jyX7py9an8CsHAxg3BI3Ku9j0h7DJpXyfrlzmg36XYkNS7Ot0A1UqdjGFrtnII SI+Zj3ywHZudmDF8ktdBihHAjuk47B/Kg/Z8JhUJ37GGx/KxiIiXg5HMTdOl6mlDbJaTIEGa gdRcmH3u57r5snZ+qdVSg5UxWdhgS2+zPru/vDbPd+91zLTj9GejKXFJ6fEAOLW1j2IjJ0cy DI67d1/OzFTwCK8wYbhopK2wJ9QTKDQuWRuGoyt2d6yzd7WoAS55JE0BIt+kXDJGbOaK42H2 ifO6ERHbJiEr/oh4KzgdAes+GRjwlSaG2Z0va4Ss5lY6zfwVCEZYdZcjSDpKB0M5tTQYQeO7 QyQPOI6Gb4FXA9ko3sHvAPs4+Pq+UtWjp3y8sYr1vLCER9ePEsgLdCG27mUk9OAijkG6n5oE GOIn+70F+qvKpmm52dZ8b7DELfbuuk0CrY4p0WxH3bBt6FJkPeZJIB6YNXAYHZi7RcdBjLJh +lawbIYTJFIcoWFHAl0g0/NYsjz3DLhZz4+CrJ6SQSYmp7qDhdJAWPiaq3C+qE/h2DZAJwoz 9uHrZHB8zsZ5JL8sUZ7zgqYmNMN+9PxzasrycTJn96Y63AIZdDq1kIHIw0vF4PBTVMZtMYID FDCCAxACAQEwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwg SW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjANBglghkgBZQMEAgEFAKCCAZcw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNDIwMDgxODU5 WjAvBgkqhkiG9w0BCQQxIgQgiHVgZSBjBjdLI5Rg/lROWHMtXjvMIAtt3IgAjvpTE7cwXQYJ KwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQSB2MgIQCXbYhDs+Bd6DT7LMTmx+xjBfBgsqhkiG9w0BCRACCzFQ oE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1 YWwgQ0EgdjICEAl22IQ7PgXeg0+yzE5sfsYwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQCuyJ8Y7oYw dMAY9Tz7u/wDZTrcZ2aPzX2oqFWEeiXx2libqPxtRIhlFUab3DlaNY0df/MB3CNfvzS1lvoZ 0E81+x/03tboFaLN00bzpwVg5dwtWLSSL4AkwDdm4OQJMJB+Qe1zEUXNIJi6RR+lz583mvRz qEYSrZKTgpgG78SVqTFrKqlshdWW3mrMfpVl0miS1D/5xZ/SrLGDtfnHQfuwhDjpktI3PHWi jJdTJohpCQJHJhsCOHK3ygtvQlr7WH1luMZ+3VAGu0kGYiW7g0ggkZclq+5CxwDSoUnXzuR0 V7oOanrYkU5qYE03EXjeZ9495hkvgtq5ZnOcUjJu25GmAAAAAAAA --------------ms050006010501040003040101-- From nobody Fri Apr 22 01:04:21 2016 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 AA8E512E141; Fri, 22 Apr 2016 01:04:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160422080408.7722.76324.idtracker@ietfa.amsl.com> Date: Fri, 22 Apr 2016 01:04:08 -0700 Archived-At: Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc6253-bis-08.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.17 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, 22 Apr 2016 08:04:09 -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 : Host Identity Protocol Certificates Authors : Tobias Heer Samu Varjonen Filename : draft-ietf-hip-rfc6253-bis-08.txt Pages : 11 Date : 2016-04-22 Abstract: The Certificate (CERT) parameter is a container for digital certificates. It is used for carrying these certificates in Host Identity Protocol (HIP) control packets. This document specifies the certificate parameter and the error signaling in case of a failed verification. Additionally, this document specifies the representations of Host Identity Tags in X.509 version 3 (v3). The concrete use cases of certificates, including how certificates are obtained, requested, and which actions are taken upon successful or failed verification, are specific to the scenario in which the certificates are used. Hence, the definition of these scenario- specific aspects is left to the documents that use the CERT parameter. This document updates RFC7401 and obsoletes RFC6253. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc6253-bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-hip-rfc6253-bis-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc6253-bis-08 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/