[Hipsec] review of tracker issues for RFC 5206-bis

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Fri, 11 March 2011 23:20 UTC

Return-Path: <thomas.r.henderson@boeing.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id B97523A6A33 for <hipsec@core3.amsl.com>; Fri, 11 Mar 2011 15:20:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.559
X-Spam-Status: No, score=-106.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id uBPfX+i3B8Un for <hipsec@core3.amsl.com>; Fri, 11 Mar 2011 15:20:08 -0800 (PST)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com []) by core3.amsl.com (Postfix) with ESMTP id F07FE3A6778 for <hipsec@ietf.org>; Fri, 11 Mar 2011 15:20:07 -0800 (PST)
Received: from blv-av-01.boeing.com (blv-av-01.boeing.com []) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p2BNLOtV014898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 11 Mar 2011 15:21:24 -0800 (PST)
Received: from blv-av-01.boeing.com (localhost []) by blv-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id p2BNLO2G011878; Fri, 11 Mar 2011 15:21:24 -0800 (PST)
Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com []) by blv-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p2BNLOb4011873 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Fri, 11 Mar 2011 15:21:24 -0800 (PST)
Received: from XCH-NW-10V.nw.nos.boeing.com ([]) by XCH-NWHT-04.nw.nos.boeing.com ([]) with mapi; Fri, 11 Mar 2011 15:21:23 -0800
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: HIP <hipsec@ietf.org>
Date: Fri, 11 Mar 2011 15:21:23 -0800
Thread-Topic: review of tracker issues for RFC 5206-bis
Thread-Index: AcvgQwmNAkXQCZb4ThqFqsGvjxVK6g==
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CED25AFBF@XCH-NW-10V.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Christian Vogt <christian.vogt@ericsson.com>, Jari Arkko <jari.arkko@ericsson.com>
Subject: [Hipsec] review of tracker issues for RFC 5206-bis
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 11 Mar 2011 23:20:09 -0000

I would like to make an update of the RFC5206-bis draft by Monday's cutoff.  I will not make any technical changes between now and then so that there is time for people to discuss any changes, but I would like to review the open issues in this mail with a proposal for how to handle each of them.  I hope that, by the end of the Prague meeting, we could close most or all of the mobility-related issues.

For reference, the tracker issues are logged here:


If you would like to start a thread on any of these proposals, can you please start one with a new subject line? 

I will discuss the issues related to mobility in particular; multihoming can be left for another time.

Ticket2:  inclusion of LOCATOR in R2 vs. R1

This is a proposal by Miika to shift the load balancing feature of the R1 LOCATOR to DNS-based schemes.  I am neutral to slightly against this proposal on the grounds that we try to avoid DNS reliance in HIP in general, and I am not convinced it is a burden on implementations.  I suggest no change, but feel free to convince me otherwise.

Ticket 4:  make before break use case missing
Ticket 5:  cross-family handovers missing from RFC5206-bis
Ticket 6:  specify peer-locator exposure policies and sending from unannounced locators
Ticket 8:  decouple locator announcement from SA creation

I support adding text for these four cases and will try to come up with a specific proposal for review on the list before adding to the published draft.  So, this would be added for the subsequent draft version (the next one past Monday's IETF-80 version).

Ticket 10:  LOCATOR/locator terminology in RFC 5206

I would like to suggest changing the name of this parameter to "LOCATOR-SET" but I will wait for comments on this suggestion before implementing it.  This would also need to change in the RFC5770-bis.

Tickete 11:  review ESP_INFO/SPI issues in RFC5206

this is a request to clarify whether the mappings of SPI to interface or locator are one-one or one-many.  draft-melen-hip-nat-mm-00 recommended to avoid assigning locators on different interfaces to a single SPI (this may be more an issue for the multihoming draft).

Ticket 12:  should UPDATE be sent via rendezvous server?

This requires coordination with RFC5204-bis but I support adding text to document this.

Ticket 13:  SEQ/ACK handling with respect to UPDATE

I do not really understand the concern so would like to request specific text change proposal.

Ticket 14:  can actual IP addresses of UPDATEs be used as locators, even if not in LOCATOR set?

In principle, it seems like this should be permitted; I do not see a reason why an implementation should be precluded from trying a locator found on the inbound IP packet, perhaps as a last resort.  I would suggest to add a statement along these lines.

Ticket 15:  suggestion for naming UPDATE packets

I believe that the basic request here is to reduce the number of possible different UPDATE scenarios, document them better, and modularize the separate concepts.  I will have a look at this in the subsequent revision.


So, in summary, I propose to do the following
- publish draft-ietf-hip-rfc5206-bis-02.txt by Monday, with updated references
- work on a suggested -03 draft for possible publishing during IETF 80 week or shortly thereafter, covering the above topics.