From nobody Mon Dec 1 08:19:26 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BEE11A6F47; Mon, 1 Dec 2014 08:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 9RINeCwbvDbs; Mon, 1 Dec 2014 08:19:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 07A691A037B; Mon, 1 Dec 2014 08:19:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141201161904.6707.55599.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 08:19:04 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/PfwMFH1vLEotglh9veO_tYcAlRA Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5206-bis-07.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 16:19:12 -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 Working Group of the IETF. Title : Host Mobility with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-rfc5206-bis-07.txt Pages : 34 Date : 2014-11-12 Abstract: This document defines mobility extensions to the Host Identity Protocol (HIP). Specifically, this document defines a general "LOCATOR_SET" parameter for HIP messages that allows for a HIP host to notify peers about alternate addresses at which it may be reached. This document also defines elements of procedure for mobility of a HIP host -- the process by which a host dynamically changes the primary locator that it uses to receive packets. While the same LOCATOR_SET parameter can also be used to support end-host multihoming, detailed procedures are out of scope for this document. This document obsoletes RFC 5206. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5206-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5206-bis-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5206-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/ From nobody Mon Dec 1 08:20:43 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8B91A6F6E; Mon, 1 Dec 2014 08:20:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 mIpggXGueCX9; Mon, 1 Dec 2014 08:20:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E46DB1A6F52; Mon, 1 Dec 2014 08:19:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141201161952.5998.60482.idtracker@ietfa.amsl.com> Date: Mon, 01 Dec 2014 08:19:52 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/4iQ5okq9DQqmib9O1ZvmeFbSSkU Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-multihoming-04.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 01 Dec 2014 16:20:38 -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 Working Group of the IETF. Title : Host Multihoming with the Host Identity Protocol Authors : Thomas R. Henderson Christian Vogt Jari Arkko Filename : draft-ietf-hip-multihoming-04.txt Pages : 22 Date : 2014-11-12 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: http://tools.ietf.org/html/draft-ietf-hip-multihoming-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-multihoming-04 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 Wed Dec 10 14:26:32 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D857E1A9308 for ; Wed, 10 Dec 2014 14:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gXHT4bbQFuXz for ; Wed, 10 Dec 2014 14:26:24 -0800 (PST) Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [IPv6:2607:f4b8:3:3:67:15ff:fe00:180]) (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 AE1781ABD8F for ; Wed, 10 Dec 2014 14:26:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id CA5A860964 for ; Wed, 10 Dec 2014 17:25:56 -0500 (EST) X-Virus-Scanned: amavisd-new at htt-consult.com Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FKqg8U7wxV8j for ; Wed, 10 Dec 2014 17:25:49 -0500 (EST) Received: from lx120e.htt-consult.com (nc4010.htt-consult.com [208.83.67.156]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 24B71620BF for ; Wed, 10 Dec 2014 17:25:49 -0500 (EST) Message-ID: <5488C86B.9060304@htt-consult.com> Date: Wed, 10 Dec 2014 17:25:47 -0500 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/Nm01ql3mvsOXsLejpWzdlg-pVfE Subject: [Hipsec] Verizon employment ending Jan 5 2015 X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 10 Dec 2014 22:26:27 -0000 I have been silent the past month for a sad, work, reason. On Oct 24, Verizon did a major product realignment and the group I am in was tagged for termination the end of the year. We were told that there would be openings in other groups. I have spent the past 6 weeks putting together resumes, CVs, and presentations. I found out yesterday that internal hirings are limited to only the 15 'new' development centers. None are in Michigan. No telecommuting will be accepted. So I perhaps misspent much of the past 6 weeks, other than getting a current resume together. I AM getting a nice severance; my employment goes back 17 years to when I started with ICSA in '98. But I am still now looking for a job, looking to start a consulting business, looking to form a start-up, retiring. TBD. I will be a little busy still this month wrapping up some loose ends, including the IEEE 802.15.9 balloting and HIP-DEX ID. I REALLY need to create an ID for my SSE, as then Verizon will issue an LOA on it; thus really need to get that out this month. I don't know yet about March meeting; too far out to plan. I will probably be going anyway to IEEE 802 wireless next month. From nobody Thu Dec 11 17:09:38 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECEA61A86F1 for ; Thu, 11 Dec 2014 17:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 mcMSag2v8uKf for ; Thu, 11 Dec 2014 17:09:30 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id A05221A1B25 for ; Thu, 11 Dec 2014 17:09:26 -0800 (PST) Received: (qmail 23717 invoked by uid 0); 12 Dec 2014 01:09:26 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy5.mail.unifiedlayer.com with SMTP; 12 Dec 2014 01:09:26 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw4 with id SR9L1p00m2molgS01R9PYD; Thu, 11 Dec 2014 18:09:26 -0700 X-Authority-Analysis: v=2.1 cv=B+wqjodM c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=PdJOFUKxnPcA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=9VENNUqBgry2dJJcw0UA:9 a=Ta4hM8-xO06OMDAQ:21 a=Ct2QYcW0vpTrrPUK:21 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=9Q5zPwXL2BHFxKWaZijcNnhSmDZcx+0ral6M9Sn1LN8=; b=CPoniPU+zm9axSuWf2GUVfyeuAA1ERbqnhKqvEreugqDfrW5lcIbIFbbhzD1APixgCPZYbx+hHD9/1/EgReCoK4sYy1bAUzTwS1bUVcCYVdoA1asvMzp/jQgq3sMIW6F; Received: from [50.135.59.40] (port=43504 helo=[192.168.168.43]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XzEjQ-0002qu-MQ; Thu, 11 Dec 2014 18:09:20 -0700 Message-ID: <548A403D.1060309@tomh.org> Date: Thu, 11 Dec 2014 17:09:17 -0800 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 50.135.59.40 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/IF-sxvtczxYCq9b3XQvLLZtZta4 Subject: [Hipsec] proposed changes to RFC5206-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 12 Dec 2014 01:09:37 -0000 Hi all, I recently published the version -07 draft of RFC5206-bis (mobility support in HIP). This was merely a refresh of -06; I'd like to now start moving through and closing the remaining open issues so we can get the document into shape for WGLC. I made a pass through the document and plan to publish the following (IMO) minor changes in version -08 next week, if there are no objections. Separately, I will start threads on remaining open issues that require some discussion on the list. Section 3.2 Protocol Overview ------------------------------ The draft states: However, some implementations may want to experiment with sending LOCATOR_SET parameters also on other packets, such as R1, I2, and NOTIFY. I propose to delete this sentence since we are no longer experimental; later in the document (section 5.3), it states that: A host SHOULD be prepared to receive a LOCATOR_SET parameter in the following HIP packets: R1, I2, UPDATE, and NOTIFY. and it leaves open to the implementation (Section 5.2) when to send such a packet. More on this later. (also) Section 3.2: ------------------ The draft states: The scenarios below at times describe addresses as being in either an ACTIVE, VERIFIED, or DEPRECATED state. 'VERIFIED' is a typo; it should be 'UNVERIFIED' 3.2.1 Mobility with a Single SA Pair (No Rekeying) --------------------------------------------------- The draft states: This first example considers the case in which the mobile host has only one interface, IP address, a single pair of SAs (one inbound, one outbound), and no rekeying I propose to clarify 'IP address' as rather 'one IP address in use within the HIP session', since it is seldom the case now that hosts have one IP address system-wide, and what is really intended here is to talk about the case for which there is only one IP address in use. 3.2.3. Using LOCATOR_SETs across Addressing Realms -------------------------------------------------- I propose to delete this section for now; we have an open issue (http://trac.tools.ietf.org/wg/hip/trac/ticket/5) to better define cross-family handovers, and I'd like to later propose different text based on the work published in "Secure and Efficient IPv4/IPv6 Handovers Using Host-based Identifier-Locator Split" by Varjonen et al. 4.3 UPDATE Packet with Included LOCATOR_SET -------------------------------------------- There is a sentence that says: The sending of multiple LOCATOR_SET and/or ESP_INFO parameters is for further study; receivers may wish to experiment with supporting such a possibility. I propose to delete this since supporting it is more complicated and I am not sure of the use case. 5.1. Locator Data Structure and Status -------------------------------------- The draft states: In a typical implementation, each outgoing locator is represented by a piece of state that contains the following data: I propose to clarify this by deleting 'outgoing locator' and replacing with 'locator known about the peer' since outgoing might be interpreted instead as the source address. I would also like to add these two sentences to the end of this subsection: In addition, an implementation would typically maintain similar state about its own locators offered to the peer. Finally, the locators used to establish the HIP association are by default assumed to be the initial preferred locators in ACTIVE state, with an unbounded lifetime. 5.2. Sending LOCATOR_SETs ------------------------- The lead sentence states: The decision of when to send LOCATOR_SETs is basically a local policy issue. I propose to add: "LOCATOR_SET parameters MAY be included in HIP packet types of R1, I2, R2, UPDATE, and NOTIFY." We have previously not included R2 in this list, but the work published in "Secure and Efficient IPv4/IPv6 Handovers Using Host-based Identifier-Locator Split" by Varjonen et al. discussed some benefits found by allowing the parameter also in R2. There is also a paragraph that states: Note that the purpose of announcing IP addresses in a LOCATOR_SET is to provide connectivity between the communicating hosts. In most cases, tunnels or virtual interfaces such as IPsec tunnel interfaces or Mobile IP home addresses provide sub-optimal connectivity. Furthermore, it should be possible to replace most tunnels with HIP based "non-tunneling", therefore making most virtual interfaces fairly unnecessary in the future. Therefore, virtual interfaces SHOULD NOT be announced in general. On the other hand, there are clearly situations where tunnels are used for diagnostic and/or testing purposes. In such and other similar cases announcing the IP addresses of virtual interfaces may be appropriate. I'd like to reduce this to the following: Locators corresponding to tunnel interfaces (e.g. IPsec tunnel interfaces or Mobile IP home addresses) or other virtual interfaces MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid announcing such locators as preferred locators if more direct paths may be obtained by instead preferring locators from non-virtual interfaces. 5.3. Handling Received LOCATOR_SETs ----------------------------------- The draft states: A host SHOULD be prepared to receive a LOCATOR_SET parameter in the following HIP packets: R1, I2, UPDATE, and NOTIFY. Similar to the proposal in 5.2 above, I'd like to change to: A host SHOULD be prepared to receive a LOCATOR_SET parameter in the following HIP packets: R1, I2, R2, UPDATE, and NOTIFY. From nobody Sat Dec 13 13:46:28 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87431A1AA7; Sat, 13 Dec 2014 13:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 7eWG5W3h0rfD; Sat, 13 Dec 2014 13:46:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5631A1B47; Sat, 13 Dec 2014 13:46:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141213214622.25809.98500.idtracker@ietfa.amsl.com> Date: Sat, 13 Dec 2014 13:46:22 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/D2_pkhcDSzjkNeKiIdYQIQoI25k Cc: hipsec@ietf.org Subject: [Hipsec] I-D Action: draft-ietf-hip-rfc5204-bis-05.txt X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 13 Dec 2014 21:46:26 -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 Working Group of the IETF. Title : Host Identity Protocol (HIP) Rendezvous Extension Authors : Julien Laganier Lars Eggert Filename : draft-ietf-hip-rfc5204-bis-05.txt Pages : 14 Date : 2014-12-13 Abstract: This document defines a rendezvous extension for the Host Identity Protocol (HIP). The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. Rendezvous servers improve reachability and operation when HIP nodes are multi-homed or mobile. This document obsoletes RFC5204. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hip-rfc5204-bis-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-hip-rfc5204-bis-05 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 Mon Dec 15 02:20:28 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02611A1AA2 for ; Mon, 15 Dec 2014 02:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CLuTwuRAHujJ for ; Mon, 15 Dec 2014 02:20:24 -0800 (PST) Received: from mx-out-1.rwth-aachen.de (mx-out-1.rwth-aachen.de [134.130.5.186]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA7D1A1A42 for ; Mon, 15 Dec 2014 02:20:20 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,579,1413237600"; d="p7s'?scan'208";a="364125302" Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-1.rz.rwth-aachen.de with ESMTP; 15 Dec 2014 11:20:00 +0100 Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.nets.rwth-aachen.de (Postfix) with ESMTP id 9174F13D9DB; Mon, 15 Dec 2014 11:20:00 +0100 (CET) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee]) by MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee%12]) with mapi id 14.01.0218.012; Mon, 15 Dec 2014 11:19:59 +0100 From: Rene Hummen To: Tom Henderson Thread-Topic: [Hipsec] proposed changes to RFC5206-bis Thread-Index: AQHQFahQmjfwQLNyJU+3PUeDpxMZbpyQZUYA Date: Mon, 15 Dec 2014 10:19:59 +0000 Message-ID: <74B051F5-368A-4BC3-9370-459D9DE415AF@comsys.rwth-aachen.de> References: <548A403D.1060309@tomh.org> In-Reply-To: <548A403D.1060309@tomh.org> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [137.226.12.44] Content-Type: multipart/signed; boundary="Apple-Mail=_C2080A0F-F689-4EDB-9340-A1C4444D869E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/M6yWWNg70JMpWgvxk_5vQifnjjI Cc: HIP Subject: Re: [Hipsec] proposed changes to RFC5206-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 15 Dec 2014 10:20:28 -0000 --Apple-Mail=_C2080A0F-F689-4EDB-9340-A1C4444D869E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Tom, hi all, please find my feedback in-line. On 12 Dec 2014, at 02:09, Tom Henderson wrote: > Hi all, I recently published the version -07 draft of RFC5206-bis=20 > (mobility support in HIP). This was merely a refresh of -06; I'd like=20= > to now start moving through and closing the remaining open issues so = we=20 > can get the document into shape for WGLC. >=20 > I made a pass through the document and plan to publish the following=20= > (IMO) minor changes in version -08 next week, if there are no=20 > objections. Separately, I will start threads on remaining open issues=20= > that require some discussion on the list. >=20 > Section 3.2 Protocol Overview > ------------------------------ > The draft states: >=20 > However, some implementations may want to experiment with sending > LOCATOR_SET parameters also on other packets, such as R1, I2, and > NOTIFY. >=20 > I propose to delete this sentence since we are no longer experimental; +1 I would actually propose to completely remove all mentioning of the = LOCATOR_SET parameter from any message type but UPDATE within the = context of this document in order to simplify host mobility to a single = procedure (UPDATE with LOCATOR_SET). If, e.g., multi-homing, prefers the = LOCATOR_SET parameter in other messages, a separate document can specify = this message flow. > later in the document (section 5.3), it states that: >=20 > A host SHOULD be prepared to receive a LOCATOR_SET parameter in the > following HIP packets: R1, I2, UPDATE, and NOTIFY. >=20 > and it leaves open to the implementation (Section 5.2) when to send = such=20 > a packet. More on this later. See comment above. > (also) Section 3.2: > ------------------ > The draft states: >=20 > The scenarios below at times describe addresses as being in either = an > ACTIVE, VERIFIED, or DEPRECATED state. >=20 > 'VERIFIED' is a typo; it should be =91UNVERIFIED' +1 > 3.2.1 Mobility with a Single SA Pair (No Rekeying) > --------------------------------------------------- > The draft states: >=20 > This first example considers the > case in which the mobile host has only one interface, IP address, a > single pair of SAs (one inbound, one outbound), and no rekeying >=20 > I propose to clarify 'IP address' as rather 'one IP address in use=20 > within the HIP session', since it is seldom the case now that hosts = have=20 > one IP address system-wide, and what is really intended here is to = talk=20 > about the case for which there is only one IP address in use. +1 > 3.2.3. Using LOCATOR_SETs across Addressing Realms > -------------------------------------------------- > I propose to delete this section for now; we have an open issue=20 > (http://trac.tools.ietf.org/wg/hip/trac/ticket/5) to better define=20 > cross-family handovers, and I'd like to later propose different text=20= > based on the work published in "Secure and Efficient IPv4/IPv6 = Handovers=20 > Using Host-based Identifier-Locator Split" by Varjonen et al. Why don=92t you simply replace this section with your text in an = upcoming revision? I don=92t see the benefit in removing this section = right now without a proper replacement. > 4.3 UPDATE Packet with Included LOCATOR_SET > -------------------------------------------- > There is a sentence that says: >=20 > The > sending of multiple LOCATOR_SET and/or ESP_INFO parameters is for > further study; receivers may wish to experiment with supporting = such > a possibility. >=20 > I propose to delete this since supporting it is more complicated and I=20= > am not sure of the use case. +1 What about mandating a _single_ LOCATOR_SET parameter per HIP packet? > 5.1. Locator Data Structure and Status > -------------------------------------- > The draft states: >=20 > In a typical implementation, each outgoing locator is represented = by > a piece of state that contains the following data: >=20 > I propose to clarify this by deleting 'outgoing locator' and replacing=20= > with 'locator known about the peer' since outgoing might be = interpreted=20 > instead as the source address. What about saying =91each locator announced in a LOCATOR_SET parameter=92?= > I would also like to add these two sentences to the end of this = subsection: >=20 > In addition, an implementation would typically maintain similar > state about its own locators offered to the peer. I wouldn=92t mind about adding this text. > Finally, the locators used to establish the HIP association are > by default assumed to be the initial preferred locators in > ACTIVE state, with an unbounded lifetime. +1 > 5.2. Sending LOCATOR_SETs > ------------------------- > The lead sentence states: >=20 > The decision of when to send LOCATOR_SETs is basically a local = policy > issue. >=20 > I propose to add: "LOCATOR_SET parameters MAY be included in HIP = packet=20 > types of R1, I2, R2, UPDATE, and NOTIFY." >=20 > We have previously not included R2 in this list, but the work = published=20 > in "Secure and Efficient IPv4/IPv6 Handovers Using Host-based=20 > Identifier-Locator Split" by Varjonen et al. discussed some benefits=20= > found by allowing the parameter also in R2. I admit that I didn=92t read the referenced paper. Still, I think we = should make the mobility procedure plain simple. I therefore suggest to = only specify the use of the LOCATOR_SET parameter in UPDATE messages. > There is also a paragraph that states: >=20 > Note that the purpose of announcing IP addresses in a LOCATOR_SET = is > to provide connectivity between the communicating hosts. In most > cases, tunnels or virtual interfaces such as IPsec tunnel = interfaces > or Mobile IP home addresses provide sub-optimal connectivity. > Furthermore, it should be possible to replace most tunnels with HIP > based "non-tunneling", therefore making most virtual interfaces > fairly unnecessary in the future. Therefore, virtual interfaces > SHOULD NOT be announced in general. On the other hand, there are > clearly situations where tunnels are used for diagnostic and/or > testing purposes. In such and other similar cases announcing the = IP > addresses of virtual interfaces may be appropriate. >=20 > I'd like to reduce this to the following: >=20 > Locators corresponding to tunnel interfaces (e.g. IPsec tunnel > interfaces or Mobile IP home addresses) or other virtual > interfaces MAY be announced in a LOCATOR_SET, but implementations > SHOULD avoid announcing such locators as preferred locators if > more direct paths may be obtained by instead preferring locators > from non-virtual interfaces. +1 but I would replace =93 more direct paths may be obtained by instead = preferring locators from non-virtual interfaces=94 with =93non-tunneling interface and = their locator(s) provide more direct path to the HIP peer=94. > 5.3. Handling Received LOCATOR_SETs > ----------------------------------- > The draft states: >=20 > A host SHOULD be prepared to receive a LOCATOR_SET parameter in the > following HIP packets: R1, I2, UPDATE, and NOTIFY. >=20 > Similar to the proposal in 5.2 above, I'd like to change to: >=20 > A host SHOULD be prepared to receive a LOCATOR_SET parameter in the > following HIP packets: R1, I2, R2, UPDATE, and NOTIFY. See my above comment. BR Ren=E9 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_C2080A0F-F689-4EDB-9340-A1C4444D869E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDEyMTUxMDE5NThaMCMGCSqGSIb3DQEJBDEWBBQOvIxPjAyS f37BjbZHWipoanE/CjB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQC9phmaFD89 Ikg0T7dn7FxMXgHUr28IAJARm1iM3rhsQTtWsTj/uEIZRavFN9Mw0VXbl51D1sRnYbgZ61d3pIhp Gt6pNn2d2BBQpoj3N+VrO8SxwIY9oSt3vywDs6dEd8nKWvsDoczsMS2wvtT76aKJXeX4YawzdS0J /kkTsB2TF5pgM/Pk2MDPtdIYvJ1a3d9a+UTO2mxixlWWaokB2cQaDuUlHdrYVerbEYmBGz+d+tKM qni3CvEiQpQTkPMLbN/AiMq+BD7zfkmfcQpmBhBELrGyHzVZLXquzNcPFm6yNukchw+6oCN3vcuZ jwOchfAy4GiFhUi6YnGB7JgQw93OAAAAAAAA --Apple-Mail=_C2080A0F-F689-4EDB-9340-A1C4444D869E-- From nobody Tue Dec 16 07:18:28 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D4B1A1B44 for ; Tue, 16 Dec 2014 07:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 Ar2VUh9JuHuT for ; Tue, 16 Dec 2014 07:18:24 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 617891A1B22 for ; Tue, 16 Dec 2014 07:18:23 -0800 (PST) Received: (qmail 9868 invoked by uid 0); 16 Dec 2014 15:18:22 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 16 Dec 2014 15:18:22 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw2 with id UFJF1p0112molgS01FJJtv; Tue, 16 Dec 2014 08:18:22 -0700 X-Authority-Analysis: v=2.1 cv=OLu0g0qB c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=N659UExz7-8A:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=tP-JmWiy0YsA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=3rQS-n5u3AbvIFAnls8A:9 a=Dm2zyYDtp9-OXMBm:21 a=CaVIcsBKU5lkFU5S:21 a=pILNOxqGKmIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=rQtZK66RPwtmmsJUEjG5BiLJMp/SK/ejJRzhF7c3Gnw=; b=tgTn8HN44PVCbFaq4CzKbaPcFYOuyLAdwU1NH6J9DiGc9Kq4p03uQgWuQ/573YRDkCXunJuX/WN+9OHd4P7NB2Z7kZRs401YpUmDKH2vifu7LTa2R9ICwFyrpb/lz+Rx; Received: from [73.181.150.17] (port=51935 helo=[192.168.168.45]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0tt9-000220-K2; Tue, 16 Dec 2014 08:18:15 -0700 Message-ID: <54904D34.6090407@tomh.org> Date: Tue, 16 Dec 2014 07:18:12 -0800 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Rene Hummen References: <548A403D.1060309@tomh.org> <74B051F5-368A-4BC3-9370-459D9DE415AF@comsys.rwth-aachen.de> In-Reply-To: <74B051F5-368A-4BC3-9370-459D9DE415AF@comsys.rwth-aachen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 73.181.150.17 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/YfO4t1C1r8rGC907dkvGRB_aKZs Cc: HIP Subject: Re: [Hipsec] proposed changes to RFC5206-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 15:18:26 -0000 Thanks Rene for your comments; responses inline below. On 12/15/2014 02:19 AM, Rene Hummen wrote: > Hi Tom, hi all, > > please find my feedback in-line. > > On 12 Dec 2014, at 02:09, Tom Henderson wrote: >> Hi all, I recently published the version -07 draft of RFC5206-bis >> (mobility support in HIP). This was merely a refresh of -06; I'd >> like to now start moving through and closing the remaining open >> issues so we can get the document into shape for WGLC. >> >> I made a pass through the document and plan to publish the >> following (IMO) minor changes in version -08 next week, if there >> are no objections. Separately, I will start threads on remaining >> open issues that require some discussion on the list. >> >> Section 3.2 Protocol Overview ------------------------------ The >> draft states: >> >> However, some implementations may want to experiment with sending >> LOCATOR_SET parameters also on other packets, such as R1, I2, and >> NOTIFY. >> >> I propose to delete this sentence since we are no longer >> experimental; > > +1 > > I would actually propose to completely remove all mentioning of the > LOCATOR_SET parameter from any message type but UPDATE within the > context of this document in order to simplify host mobility to a > single procedure (UPDATE with LOCATOR_SET). If, e.g., multi-homing, > prefers the LOCATOR_SET parameter in other messages, a separate > document can specify this message flow. I hadn't considered this, but it would be in keeping with the mobility/multihoming scope split that we have already agreed to do. I'll look into migrating the use of additional messages from this draft to the multihoming draft if there are no other comments. > >> later in the document (section 5.3), it states that: >> >> A host SHOULD be prepared to receive a LOCATOR_SET parameter in >> the following HIP packets: R1, I2, UPDATE, and NOTIFY. >> >> and it leaves open to the implementation (Section 5.2) when to send >> such a packet. More on this later. > > See comment above. > >> (also) Section 3.2: ------------------ The draft states: >> >> The scenarios below at times describe addresses as being in either >> an ACTIVE, VERIFIED, or DEPRECATED state. >> >> 'VERIFIED' is a typo; it should be ‘UNVERIFIED' > > +1 > >> 3.2.1 Mobility with a Single SA Pair (No Rekeying) >> --------------------------------------------------- The draft >> states: >> >> This first example considers the case in which the mobile host has >> only one interface, IP address, a single pair of SAs (one inbound, >> one outbound), and no rekeying >> >> I propose to clarify 'IP address' as rather 'one IP address in use >> within the HIP session', since it is seldom the case now that hosts >> have one IP address system-wide, and what is really intended here >> is to talk about the case for which there is only one IP address in >> use. > > +1 > >> 3.2.3. Using LOCATOR_SETs across Addressing Realms >> -------------------------------------------------- I propose to >> delete this section for now; we have an open issue >> (http://trac.tools.ietf.org/wg/hip/trac/ticket/5) to better define >> cross-family handovers, and I'd like to later propose different >> text based on the work published in "Secure and Efficient IPv4/IPv6 >> Handovers Using Host-based Identifier-Locator Split" by Varjonen et >> al. > > Why don’t you simply replace this section with your text in an > upcoming revision? I don’t see the benefit in removing this section > right now without a proper replacement. Partly because I hadn't come up with that replacement text yet, or concluded that we should keep it in this draft. I think the use case in the current draft is not very well defined (one host has only a IPv6 locator, while the other host has only an IPv4 locator, and some middlebox manages the translation), so I would propose to delete this case. If so, the question is whether to try to add something back about mobility across addressing realms in this draft. Another possibility would be to move this topic over to the multihoming draft, since it involves coordination across locator sets. Any objection if we descope it from this draft and make an cross-family handover a use case in the multihoming draft? > >> 4.3 UPDATE Packet with Included LOCATOR_SET >> -------------------------------------------- There is a sentence >> that says: >> >> The sending of multiple LOCATOR_SET and/or ESP_INFO parameters is >> for further study; receivers may wish to experiment with supporting >> such a possibility. >> >> I propose to delete this since supporting it is more complicated >> and I am not sure of the use case. > > +1 > > What about mandating a _single_ LOCATOR_SET parameter per HIP > packet? I'd agree with that proposal. > >> 5.1. Locator Data Structure and Status >> -------------------------------------- The draft states: >> >> In a typical implementation, each outgoing locator is represented >> by a piece of state that contains the following data: >> >> I propose to clarify this by deleting 'outgoing locator' and >> replacing with 'locator known about the peer' since outgoing might >> be interpreted instead as the source address. > > What about saying ‘each locator announced in a LOCATOR_SET > parameter’? Agree, that is even more precise. > >> I would also like to add these two sentences to the end of this >> subsection: >> >> In addition, an implementation would typically maintain similar >> state about its own locators offered to the peer. > > I wouldn’t mind about adding this text. > >> Finally, the locators used to establish the HIP association are by >> default assumed to be the initial preferred locators in ACTIVE >> state, with an unbounded lifetime. > > +1 > >> 5.2. Sending LOCATOR_SETs ------------------------- The lead >> sentence states: >> >> The decision of when to send LOCATOR_SETs is basically a local >> policy issue. >> >> I propose to add: "LOCATOR_SET parameters MAY be included in HIP >> packet types of R1, I2, R2, UPDATE, and NOTIFY." >> >> We have previously not included R2 in this list, but the work >> published in "Secure and Efficient IPv4/IPv6 Handovers Using >> Host-based Identifier-Locator Split" by Varjonen et al. discussed >> some benefits found by allowing the parameter also in R2. > > I admit that I didn’t read the referenced paper. Still, I think we > should make the mobility procedure plain simple. I therefore suggest > to only specify the use of the LOCATOR_SET parameter in UPDATE > messages. If we follow your proposal, this could migrate to the multihoming draft. > >> There is also a paragraph that states: >> >> Note that the purpose of announcing IP addresses in a LOCATOR_SET >> is to provide connectivity between the communicating hosts. In >> most cases, tunnels or virtual interfaces such as IPsec tunnel >> interfaces or Mobile IP home addresses provide sub-optimal >> connectivity. Furthermore, it should be possible to replace most >> tunnels with HIP based "non-tunneling", therefore making most >> virtual interfaces fairly unnecessary in the future. Therefore, >> virtual interfaces SHOULD NOT be announced in general. On the >> other hand, there are clearly situations where tunnels are used for >> diagnostic and/or testing purposes. In such and other similar >> cases announcing the IP addresses of virtual interfaces may be >> appropriate. >> >> I'd like to reduce this to the following: >> >> Locators corresponding to tunnel interfaces (e.g. IPsec tunnel >> interfaces or Mobile IP home addresses) or other virtual interfaces >> MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid >> announcing such locators as preferred locators if more direct paths >> may be obtained by instead preferring locators from non-virtual >> interfaces. > > +1 but I would replace “ more direct paths may be obtained by instead > preferring locators from non-virtual interfaces” with “non-tunneling > interface and their locator(s) provide more direct path to the HIP > peer”. I'm finewith the suggested wording change. > >> 5.3. Handling Received LOCATOR_SETs >> ----------------------------------- The draft states: >> >> A host SHOULD be prepared to receive a LOCATOR_SET parameter in >> the following HIP packets: R1, I2, UPDATE, and NOTIFY. >> >> Similar to the proposal in 5.2 above, I'd like to change to: >> >> A host SHOULD be prepared to receive a LOCATOR_SET parameter in >> the following HIP packets: R1, I2, R2, UPDATE, and NOTIFY. > > See my above comment. Understood. Thanks, Tom From nobody Tue Dec 16 07:32:05 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBE51A1B66 for ; Tue, 16 Dec 2014 07:32:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 ITVmip2k72u0 for ; Tue, 16 Dec 2014 07:31:56 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id B3A4D1A1B4E for ; Tue, 16 Dec 2014 07:31:56 -0800 (PST) Received: (qmail 2062 invoked by uid 0); 16 Dec 2014 15:31:56 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy9.mail.unifiedlayer.com with SMTP; 16 Dec 2014 15:31:56 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by CMOut01 with id UFXo1p00X2molgS01FXrtR; Tue, 16 Dec 2014 08:31:55 -0700 X-Authority-Analysis: v=2.1 cv=OJu0g0qB c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=8nJEP1OIZ-IA:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=tP-JmWiy0YsA:10 a=A92cGCtB03wA:10 a=48vgC7mUAAAA:8 a=vat5zW2C817gVElhHcoA:9 a=wPNLvfGTeEIA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Pax3ryKRg7BPKeNfEumKjECStEhzsZq8bwqxt53fzYM=; b=JgsnAQ6F9gPZCV2LPm08J3mwxIq8buRrGJSpQTIYxVKxlJAoInquda7oFN9FsSP6pkX/zT+8zWc35V5+jm+fz9B5aILFknPzMsadKics3eNb3kuHr4dZjiEUtHQk28cr; Received: from [73.181.150.17] (port=51968 helo=[192.168.168.45]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y0u6F-0002Lu-N0 for hipsec@ietf.org; Tue, 16 Dec 2014 08:31:47 -0700 Message-ID: <54905061.1010200@tomh.org> Date: Tue, 16 Dec 2014 07:31:45 -0800 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: HIP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 73.181.150.17 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/RPXu4FQfhe5b0UXZGtkjsC0wNRM Subject: [Hipsec] RFC5204-bis open issues? X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 16 Dec 2014 15:32:04 -0000 I noticed that the draft for RFC5204-bis (rendezvous extension) was recently refreshed, and was wondering what the remaining open issues are for this draft? I know of only one, which is a longstanding question of whether we want to cover RVS relaying of UPDATE messages in this specification. https://tools.ietf.org/wg/hip/trac/ticket/1 Some choices appear to be: * do not support double jump in these specifications, leaving it for further study * add specification in RFC5204-bis that refers to UPDATE relaying * add specification in RFC5206-bis that refers to UPDATE relaying - Tom https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5204-bis/ From nobody Sat Dec 27 10:32:29 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FD51A908C for ; Sat, 27 Dec 2014 10:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 e_6o6MRUSvI4 for ; Sat, 27 Dec 2014 10:32:23 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id 89E181A9087 for ; Sat, 27 Dec 2014 10:32:23 -0800 (PST) Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8]) by mail.cs.hut.fi (Postfix) with ESMTP id 6A441308A45 for ; Sat, 27 Dec 2014 20:32:20 +0200 (EET) Message-ID: <549EFB33.8060701@cs.hut.fi> Date: Sat, 27 Dec 2014 20:32:19 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: hipsec@ietf.org References: <548A403D.1060309@tomh.org> <74B051F5-368A-4BC3-9370-459D9DE415AF@comsys.rwth-aachen.de> <54904D34.6090407@tomh.org> In-Reply-To: <54904D34.6090407@tomh.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/OVX1mGOR55mNm7t7sqkgPTdTSnw Subject: Re: [Hipsec] proposed changes to RFC5206-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2014 18:32:27 -0000 Hi Tom and Rene, On 12/16/2014 05:18 PM, Tom Henderson wrote: > Thanks Rene for your comments; responses inline below. > > On 12/15/2014 02:19 AM, Rene Hummen wrote: >> Hi Tom, hi all, >> >> please find my feedback in-line. >> >> On 12 Dec 2014, at 02:09, Tom Henderson wrote: >>> Hi all, I recently published the version -07 draft of RFC5206-bis >>> (mobility support in HIP). This was merely a refresh of -06; I'd >>> like to now start moving through and closing the remaining open >>> issues so we can get the document into shape for WGLC. >>> >>> I made a pass through the document and plan to publish the >>> following (IMO) minor changes in version -08 next week, if there >>> are no objections. Separately, I will start threads on remaining >>> open issues that require some discussion on the list. >>> >>> Section 3.2 Protocol Overview ------------------------------ The >>> draft states: >>> >>> However, some implementations may want to experiment with sending >>> LOCATOR_SET parameters also on other packets, such as R1, I2, and >>> NOTIFY. >>> >>> I propose to delete this sentence since we are no longer >>> experimental; >> >> +1 >> >> I would actually propose to completely remove all mentioning of the >> LOCATOR_SET parameter from any message type but UPDATE within the >> context of this document in order to simplify host mobility to a >> single procedure (UPDATE with LOCATOR_SET). If, e.g., multi-homing, >> prefers the LOCATOR_SET parameter in other messages, a separate >> document can specify this message flow. > > I hadn't considered this, but it would be in keeping with the > mobility/multihoming scope split that we have already agreed to do. > > I'll look into migrating the use of additional messages from this draft= > to the multihoming draft if there are no other comments. I would suggest to move complexity to the multihoming draft in order to=20 keep the mobility extensions simple enough to be implemented e.g. for=20 sensors. >> >>> later in the document (section 5.3), it states that: >>> >>> A host SHOULD be prepared to receive a LOCATOR_SET parameter in >>> the following HIP packets: R1, I2, UPDATE, and NOTIFY. >>> >>> and it leaves open to the implementation (Section 5.2) when to send >>> such a packet. More on this later. >> >> See comment above. >> >>> (also) Section 3.2: ------------------ The draft states: >>> >>> The scenarios below at times describe addresses as being in either >>> an ACTIVE, VERIFIED, or DEPRECATED state. >>> >>> 'VERIFIED' is a typo; it should be =91UNVERIFIED' >> >> +1 +1 >>> 3.2.1 Mobility with a Single SA Pair (No Rekeying) >>> --------------------------------------------------- The draft >>> states: >>> >>> This first example considers the case in which the mobile host has >>> only one interface, IP address, a single pair of SAs (one inbound, >>> one outbound), and no rekeying >>> >>> I propose to clarify 'IP address' as rather 'one IP address in use >>> within the HIP session', since it is seldom the case now that hosts >>> have one IP address system-wide, and what is really intended here >>> is to talk about the case for which there is only one IP address in >>> use. >> >> +1 +1 >>> 3.2.3. Using LOCATOR_SETs across Addressing Realms >>> -------------------------------------------------- I propose to >>> delete this section for now; we have an open issue >>> (http://trac.tools.ietf.org/wg/hip/trac/ticket/5) to better define >>> cross-family handovers, and I'd like to later propose different >>> text based on the work published in "Secure and Efficient IPv4/IPv6 >>> Handovers Using Host-based Identifier-Locator Split" by Varjonen et >>> al. >> >> Why don=92t you simply replace this section with your text in an >> upcoming revision? I don=92t see the benefit in removing this section >> right now without a proper replacement. > > Partly because I hadn't come up with that replacement text yet, or > concluded that we should keep it in this draft. > > I think the use case in the current draft is not very well defined (one= > host has only a IPv6 locator, while the other host has only an IPv4 > locator, and some middlebox manages the translation), so I would propos= e > to delete this case. If so, the question is whether to try to add > something back about mobility across addressing realms in this draft. > > Another possibility would be to move this topic over to the multihoming= > draft, since it involves coordination across locator sets. Any > objection if we descope it from this draft and make an cross-family > handover a use case in the multihoming draft? I suggest to move to the multihoming draft (as I reasoned earlier). >> >>> 4.3 UPDATE Packet with Included LOCATOR_SET >>> -------------------------------------------- There is a sentence >>> that says: >>> >>> The sending of multiple LOCATOR_SET and/or ESP_INFO parameters is >>> for further study; receivers may wish to experiment with supporting >>> such a possibility. >>> >>> I propose to delete this since supporting it is more complicated >>> and I am not sure of the use case. >> >> +1 >> >> What about mandating a _single_ LOCATOR_SET parameter per HIP >> packet? > > I'd agree with that proposal. +1 >>> 5.1. Locator Data Structure and Status >>> -------------------------------------- The draft states: >>> >>> In a typical implementation, each outgoing locator is represented >>> by a piece of state that contains the following data: >>> >>> I propose to clarify this by deleting 'outgoing locator' and >>> replacing with 'locator known about the peer' since outgoing might >>> be interpreted instead as the source address. >> >> What about saying =91each locator announced in a LOCATOR_SET >> parameter=92? > > Agree, that is even more precise. +1 >>> I would also like to add these two sentences to the end of this >>> subsection: >>> >>> In addition, an implementation would typically maintain similar >>> state about its own locators offered to the peer. >> >> I wouldn=92t mind about adding this text. >> >>> Finally, the locators used to establish the HIP association are by >>> default assumed to be the initial preferred locators in ACTIVE >>> state, with an unbounded lifetime. >> >> +1 +1 >>> 5.2. Sending LOCATOR_SETs ------------------------- The lead >>> sentence states: >>> >>> The decision of when to send LOCATOR_SETs is basically a local >>> policy issue. >>> >>> I propose to add: "LOCATOR_SET parameters MAY be included in HIP >>> packet types of R1, I2, R2, UPDATE, and NOTIFY." >>> >>> We have previously not included R2 in this list, but the work >>> published in "Secure and Efficient IPv4/IPv6 Handovers Using >>> Host-based Identifier-Locator Split" by Varjonen et al. discussed >>> some benefits found by allowing the parameter also in R2. >> >> I admit that I didn=92t read the referenced paper. Still, I think we >> should make the mobility procedure plain simple. I therefore suggest >> to only specify the use of the LOCATOR_SET parameter in UPDATE >> messages. > > If we follow your proposal, this could migrate to the multihoming draft= =2E Please move. I recall that having locators only in UPDATE packets is not = sufficient for cross-family handoffs, but this can be specified in the=20 multihoming draft. >>> There is also a paragraph that states: >>> >>> Note that the purpose of announcing IP addresses in a LOCATOR_SET >>> is to provide connectivity between the communicating hosts. In >>> most cases, tunnels or virtual interfaces such as IPsec tunnel >>> interfaces or Mobile IP home addresses provide sub-optimal >>> connectivity. Furthermore, it should be possible to replace most >>> tunnels with HIP based "non-tunneling", therefore making most >>> virtual interfaces fairly unnecessary in the future. Therefore, >>> virtual interfaces SHOULD NOT be announced in general. On the >>> other hand, there are clearly situations where tunnels are used for >>> diagnostic and/or testing purposes. In such and other similar >>> cases announcing the IP addresses of virtual interfaces may be >>> appropriate. >>> >>> I'd like to reduce this to the following: >>> >>> Locators corresponding to tunnel interfaces (e.g. IPsec tunnel >>> interfaces or Mobile IP home addresses) or other virtual interfaces >>> MAY be announced in a LOCATOR_SET, but implementations SHOULD avoid >>> announcing such locators as preferred locators if more direct paths >>> may be obtained by instead preferring locators from non-virtual >>> interfaces. >> >> +1 but I would replace =93 more direct paths may be obtained by instea= d >> preferring locators from non-virtual interfaces=94 with =93non-tunneli= ng >> interface and their locator(s) provide more direct path to the HIP >> peer=94. > > I'm finewith the suggested wording change. +1 >>> 5.3. Handling Received LOCATOR_SETs >>> ----------------------------------- The draft states: >>> >>> A host SHOULD be prepared to receive a LOCATOR_SET parameter in >>> the following HIP packets: R1, I2, UPDATE, and NOTIFY. >>> >>> Similar to the proposal in 5.2 above, I'd like to change to: >>> >>> A host SHOULD be prepared to receive a LOCATOR_SET parameter in >>> the following HIP packets: R1, I2, R2, UPDATE, and NOTIFY. >> >> See my above comment. > > Understood. I think we can move this to the multihoming draft. From nobody Sat Dec 27 10:49:09 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37441A90E2 for ; Sat, 27 Dec 2014 10:49:07 -0800 (PST) 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MdyXFUONKeS8 for ; Sat, 27 Dec 2014 10:49:06 -0800 (PST) Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id ADB8D1A8971 for ; Sat, 27 Dec 2014 10:49:06 -0800 (PST) Received: from [127.0.0.1] (mannerheim.cs.hut.fi [130.233.193.8]) by mail.cs.hut.fi (Postfix) with ESMTP id A9083308A77; Sat, 27 Dec 2014 20:49:05 +0200 (EET) Message-ID: <549EFF21.2030707@cs.hut.fi> Date: Sat, 27 Dec 2014 20:49:05 +0200 From: Miika Komu User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Tom Henderson , HIP , Julien Laganier References: <54905061.1010200@tomh.org> In-Reply-To: <54905061.1010200@tomh.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/nezsdam3kZI1XVfhqIrwnjGR0MI Subject: Re: [Hipsec] RFC5204-bis open issues? X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 27 Dec 2014 18:49:08 -0000 Hi Tom, On 12/16/2014 05:31 PM, Tom Henderson wrote: > I noticed that the draft for RFC5204-bis (rendezvous extension) was > recently refreshed, and was wondering what the remaining open issues are > for this draft? > > I know of only one, which is a longstanding question of whether we want > to cover RVS relaying of UPDATE messages in this specification. > > https://tools.ietf.org/wg/hip/trac/ticket/1 > > Some choices appear to be: > > * do not support double jump in these specifications, leaving it for > further study > * add specification in RFC5204-bis that refers to UPDATE relaying > * add specification in RFC5206-bis that refers to UPDATE relaying I suggest the third option (unless Julien wants to write it in RFC5204). Besides UPDATE relaying, we need also some text for the other side, i.e., the registered host moves and updates its registration. From nobody Tue Dec 30 11:10:23 2014 Return-Path: X-Original-To: hipsec@ietfa.amsl.com Delivered-To: hipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A574C1A1AB5 for ; Tue, 30 Dec 2014 11:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.033 X-Spam-Level: * X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 B1tO-S5yDvv0 for ; Tue, 30 Dec 2014 11:10:21 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 63E161A1A7D for ; Tue, 30 Dec 2014 11:10:20 -0800 (PST) Received: (qmail 861 invoked by uid 0); 30 Dec 2014 19:10:20 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 30 Dec 2014 19:10:20 -0000 Received: from box528.bluehost.com ([74.220.219.128]) by cmgw2 with id ZvAE1p00J2molgS01vAH01; Tue, 30 Dec 2014 12:10:20 -0700 X-Authority-Analysis: v=2.1 cv=eOCA0hZ1 c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=vP6ySPhpAh4A:10 a=N659UExz7-8A:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=Ua3Zc11GhZYA:10 a=A92cGCtB03wA:10 a=riEhs54-fUy1ILbtHvcA:9 a=pILNOxqGKmIA:10 a=RLQ-03TEUh0A:10 a=bihvG6g-yDYA:10 a=fg5Io1_oNpEA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tomh.org; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=fYv0xbuqczdcFOViII73A/gAHZkXk/1pyAFKbNtxxzc=; b=sX6/4T8bfd/AySLu1FNG9g8fyBSoVaEXFq0GZs/fv27F1dsxEikkluUm4RJJg0Lj4fo7VvNKjPzmTg+Zn3g4Fa+TpjrB6pajquuKTDH4z9YkyXWRBBtQ3u6tBELHPl3E; Received: from [66.91.78.210] (port=33751 helo=[10.0.1.48]) by box528.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Y62BK-0005nM-2b; Tue, 30 Dec 2014 12:10:14 -0700 Message-ID: <54A2F88F.8090708@tomh.org> Date: Tue, 30 Dec 2014 11:10:07 -0800 From: Tom Henderson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Miika Komu , Rene Hummen References: <548A403D.1060309@tomh.org> <74B051F5-368A-4BC3-9370-459D9DE415AF@comsys.rwth-aachen.de> <54904D34.6090407@tomh.org> <549EFB33.8060701@cs.hut.fi> In-Reply-To: <549EFB33.8060701@cs.hut.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {3122:box528.bluehost.com:tomhorg:tomh.org} {sentby:smtp auth 66.91.78.210 authed with tomh@tomh.org} Archived-At: http://mailarchive.ietf.org/arch/msg/hipsec/oWP_wkxFO5KxRWhWotiu52O-ztY Cc: hipsec@ietf.org Subject: Re: [Hipsec] proposed changes to RFC5206-bis X-BeenThere: hipsec@ietf.org X-Mailman-Version: 2.1.15 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, 30 Dec 2014 19:10:22 -0000 Miika and Rene, Thanks for the comments; I'll plan to revise both drafts (mobility and multihoming) along the lines suggested by next week. - Tom