Re: [Hipsec] proposed changes to RFC5206-bis

[Miika Komu <[e-mail]>]

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

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

+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

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

+1

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

+1

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

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

+1

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