[Hipsec] proposed changes to RFC5206-bis

Tom Henderson <tomh@tomh.org> Fri, 12 December 2014 01:09 UTC

Return-Path: <tomh@tomh.org>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id ECEA61A86F1 for <hipsec@ietfa.amsl.com>; 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-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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mcMSag2v8uKf for <hipsec@ietfa.amsl.com>; Thu, 11 Dec 2014 17:09:30 -0800 (PST)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com []) by ietfa.amsl.com (Postfix) with SMTP id A05221A1B25 for <hipsec@ietf.org>; 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) ( by gproxy5.mail.unifiedlayer.com with SMTP; 12 Dec 2014 01:09:26 -0000
Received: from box528.bluehost.com ([]) 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 [] (port=43504 helo=[]) by box528.bluehost.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <tomh@tomh.org>) 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 <tomh@tomh.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: HIP <hipsec@ietf.org>
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 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." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec/>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 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

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

'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:

    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

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.