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 <t...@tomh.org> 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.
_______________________________________________
Hipsec mailing list
Hipsec@ietf.org
https://www.ietf.org/mailman/listinfo/hipsec
