[Hipsec] preview of draft-ietf-hip-mm-00 for review

[[e-mail] (Henderson, Thomas R)]

I plan to submit this draft as WG version -00 in a few days,
but have put it up for any early comments:

http://hip4inter.net/documentation/drafts/draft-nikander-hip-mm-02.txt

I have tried to address the issues that people have raised on
the list, and issues that have been discovered upon implementing
the previous draft version.  Below is a summary of open issues:


Update on HIP mobility management open issues
---------------

Note:  The first four issues are logged at the issue tracker.
The remainder are issues that have arisen during revision
of the text, and open issues raised on the mailing list.

On the hip-mm issue tracker, I would suggest to keep issues
1, 2, and 3 open, close issue 4, and add 6, 10, and 11 (below)
to the issue tracker.

1.  (Roundup issue tracker #1):  Potential conflict in updating
SPI values

Suggested resolution:  Keep open.  This issue pertains to whether=20
we can abandon the address group abstraction.  We agreed to leave it
open until we had more insight.

2. (Roundup issue tracker #2):  Problems with middleboxes

Suggested resolution:  Keep open.  Middlebox traversal needs
to be considered more carefully before this issue can be closed.
For example, should one-way REAs be deprecated?

3.  (Roundup issue tracker #3):  address check RR design

Suggested resolution:  Keep open.  The use of ECHO_REQUEST/REPLY
has plugged the main issue raised here, but additional work
ongoing in mobike and multi6 design team on failover detection
and validation of alternate addresses that may apply also to HIP.

4.  (Roundup issue tracker #4):  Use of multiple SAs

Suggested resolution:  Close this issue (resolved).

5.  REA parameter type is "to be defined"

Suggested resolution:  Tentatively, we have used the value
"3" in our implementation.  The desire has been to keep REA
forward in the list of parameters, to make middlebox parsing
easier.  Whether REA should precede SPI (value "1") or
vice versa might be debatable. =20

6.  Bidirectionality of NES conflicting with unidirectionality
of SAs and REA in multihoming case

Mika has suggested in a recent mail that, when there are
multiple SAs in a REA, and REA is paired with NES, that
it can become ambiguous as to which SA should be rekeyed
upon receipt of a REA/NES.

Suggested resolution:  Add a note to the text that, in the
case of multihoming with multiple SAs, it is RECOMMENDED to
associate SAs in pairs, and that when a NES is received for
a particular SA, the peer should rekey the paired SA.
Also, state that using asymmetrically set up SAs is experimental,=20
and may fail to interoperate.

Also, issue should be opened in issue tracker.

7.  The issue was raised on the list whether there needs
to be an API to allow an application to select the source
or destination IP address when there are multiple choices.

Suggested resolution:  Should be left outside of the draft,
or discussed in an appendix.  For now, there is no proposed
text that would address this issue. =20

8.  Discussion on the use of multihomed SAs for load balancing

Suggested resolution:  There are many unsolved issues with
respect to load balancing across multiple addresses.  For now,=20
we recommend that multihoming is just used/specified for=20
failover purposes, although experimentation is recommended.

9.  If HIP negotiates base exchange using link locals, and one
host moves, it will not be able to find its peer

Suggested resolution:  State that a host SHOULD provide its
peer with a globally reachable IP address instead of relying
exclusively on link-local addresses.

10.  Should REA be included in R2 or R1 (R1 is presently
specified in text)?

Note that there is some conflict in saying that, when REA=20
is included in R1 and it includes a new preferred address,=20
that the puzzle solution MUST be valid for both responder=20
addresses.  The conflict is in using Appendix D (base spec)=20
mapping functions.

Suggested resolution:  Open, but leaning towards recommending
inclusion in R2 instead of R1, unless the reason for putting
it in R1 is (re)discovered.

Also, issue should be opened in issue tracker.

11.  Use of SPI parameter when REA is present-- is it necessary?

Suggested resolution:  Open until middlebox implications are
better understood.

Also, issue should be opened in issue tracker.