Re: [Hipsec] proposed changes to RFC5206-bis

Rene Hummen <> Mon, 15 December 2014 10:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D02611A1AA2 for <>; Mon, 15 Dec 2014 02:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.46
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CLuTwuRAHujJ for <>; Mon, 15 Dec 2014 02:20:24 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (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 ([]) by with ESMTP; 15 Dec 2014 11:20:00 +0100
Received: from ( []) by (Postfix) with ESMTP id 9174F13D9DB; Mon, 15 Dec 2014 11:20:00 +0100 (CET)
Received: from ([fe80::d4e:bb9d:9e0:bfee]) by ([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: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_C2080A0F-F689-4EDB-9340-A1C4444D869E"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: HIP <>
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: Mon, 15 Dec 2014 10:20:28 -0000

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;


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

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


What about mandating a _single_ LOCATOR_SET parameter per HIP packet?

> 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’?

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


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

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

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


Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426