Re: [Hipsec] proposed changes to RFC5206-bis

[Rene Hummen <[e-mail]>]

Hi Tom, hi all,

please find my feedback in-line.

On 12 Dec 2014, at 02:09, Tom Henderson <[e-mail]> 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;

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

> 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
>    ACTIVE, VERIFIED, or DEPRECATED state.
> 
> '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 
> (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.

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.

+1

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.

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

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

BR
René


--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: [phone]
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/