Re: [Hipsec] proposed changes to RFC5206-bis

Miika Komu <> Sat, 27 December 2014 18:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 07FD51A908C for <>; Sat, 27 Dec 2014 10:32:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.311
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e_6o6MRUSvI4 for <>; Sat, 27 Dec 2014 10:32:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 89E181A9087 for <>; Sat, 27 Dec 2014 10:32:23 -0800 (PST)
Received: from [] ( []) by (Postfix) with ESMTP id 6A441308A45 for <>; Sat, 27 Dec 2014 20:32:20 +0200 (EET)
Message-ID: <>
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
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Hipsec] proposed changes to RFC5206-bis
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
>>> 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 
keep the mobility extensions simple enough to be implemented e.g. for 

>>> 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
>>> '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
>>> ( 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?

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.


>>> 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.

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 
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.

I think we can move this to the multihoming draft.