Subject: [Hipsec] proposed changes to RFC5206-bis

From: Tom Henderson <[email-masked]>
Date: Thu, 11 Dec 2014 17:09:17 -0800

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: Rene Hummen <[email-masked]>
Date: Mon, 15 Dec 2014 10:19:59 +0000

Hi Tom, hi all,

please find my feedback in-line.

> Section 3.2  Protocol Overview

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

> a packet.   More on this later.

See comment above.

> 'VERIFIED' is a typo; it should be ‘UNVERIFIED'

+1

> 3.2.1  Mobility with a Single SA Pair (No Rekeying)

+1

> 3.2.3. Using LOCATOR_SETs across Addressing Realms

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

+1

What about mandating a _single_ LOCATOR_SET parameter per HIP packet?

> 5.1. Locator Data Structure and Status

What about saying ‘each locator announced in a LOCATOR_SET parameter’?

>   state about its own locators offered to the peer.

I wouldn’t mind about adding this text.

>   ACTIVE state, with an unbounded lifetime.

+1

> 5.2. Sending LOCATOR_SETs

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.

>   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

See my above comment.

BR
René

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

---

From: Tom Henderson <[email-masked]>
Date: Tue, 16 Dec 2014 07:18:12 -0800

Thanks Rene for your comments; responses inline below.

On 12/15/2014 02:19 AM, Rene Hummen wrote:
>> (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:
>>
> 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.

>> 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.
>>
>> --------------------------------------------------- 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
>>
>> 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
>
>> -------------------------------------------------- I propose to
>> delete this section for now; we have an open issue
>> 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?

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

I'd agree with that proposal.

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

Agree, that is even more precise.

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

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

>> ----------------------------------- The draft states:
>>
>> A host SHOULD be prepared to receive a LOCATOR_SET parameter in
>> the following HIP packets: R1, I2, UPDATE, and NOTIFY.
>>
>> 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: Miika Komu <[email-masked]>
Date: Sat, 27 Dec 2014 20:32:19 +0200

Hi Tom and Rene,

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

+1

+1

> handover a use case in the multihoming draft?

I suggest to move to the multihoming draft (as I reasoned earlier).

+1

+1

+1

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

+1

>>> the following HIP packets: R1, I2, R2, UPDATE, and NOTIFY.

I think we can move this to the multihoming draft.

---

From: Tom Henderson <[email-masked]>
Date: Tue, 30 Dec 2014 11:10:07 -0800

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