Host Multihoming with the Host Identity Protocol
draft-ietf-hip-multihoming-12

I agree with Mirja that the split sounds a bit artificial.

Carlos Pignataro <cpignata@cisco.com>

performed the opsdir review

I'm wondering if split-tunneling should be listed as a security consideration.  I see the following in section 4.1 that might be used to help prevent split tunneling:
   In the outbound direction, as a result of SPD processing, when
   an outbound SA is selected, the correct IP destination address for
   the peer must also be assigned.

Then also the entirety of section 4.3.

I read this as split tunneling could be an issue in some circumstances depending on policy and it might be good to mention this in the security considerations section.  Or let me know if I am missing some background that would prevent split tunneling so implementers don't need to be made aware of this consideration.

Thanks.

One big general comment:

The split between this document and draft-ietf-hip-rfc5206-bis-13 (still) seems a little artificial. draft-ietf-hip-rfc5206-bis-13 describes some general parts that actually covers both use cases. I guess it would be at least nice to spell out clearly in this document which parts of draft-ietf-hip-rfc5206-bis-13 are required to read (section 4 and parts of section 5) if that's is somehow clearly separately.

E.g. I believe the following should be in draft-ietf-hip-rfc5206-bis-13 and not in this doc:
"Hosts MUST NOT announce broadcast or multicast addresses in
   LOCATOR_SETs. "
I this is more relevant for the case described in this document but is true for the general case. draft-ietf-hip-rfc5206-bis-13 stated the following but that's not the same because it only describes the peer side:
"  For
   each locator listed in the LOCATOR_SET parameter, check that the
   address therein is a legal unicast or anycast address.  That is, the
   address MUST NOT be a broadcast or multicast address."

What worries me more is that I believe that one would need to always read both documents to implement the peer functionality correctly. E.g. this documents says the following:
"An Initiator MAY include one or more LOCATOR_SET parameters in the I2
   packet, independent of whether or not there was a LOCATOR_SET
   parameter in the R1.  These parameters MUST be protected by the I2
   signature.  Even if the I2 packet contains LOCATOR_SET parameters,
   the Responder MUST still send the R2 packet to the source address of
   the I2."
However, when I read draft-ietf-hip-rfc5206-bis-13, it is not clear that there are specifications in this document that are important for a correct implementation. 

Smaller comments:
1) Regarding the following sentence:
"In summary, whether and how a host decides to leverage additional
   addresses in a load-balancing or fault-tolerant manner is outside the
   scope of the specification."
I agree that it is out of scope for this doc. But maybe it would be useful to provide pointers to existng work. The scheduling problem is well know and e.g. basically the same for MPTCP.

2) Regarding the following recommendation:
"Although the protocol may allow for configurations in which there is
   an asymmetric number of SAs between the hosts (e.g., one host has two
   interfaces and two inbound SAs, while the peer has one interface and
   one inbound SA), it is RECOMMENDED that inbound and outbound SAs be
   created pairwise between hosts.  When an ESP_INFO arrives to rekey a
   particular outbound SA, the corresponding inbound SA should be also
   rekeyed at that time."
I believe I agree but why?

3) I (again) would find it easier to have section 4.9, 4.10, and 4.11 before 4.2-4.8. However, I guess that's a matter of taste. Alternatively maybe have most of the text from 4.2-4.8 in a separate supersection first and call it 'usage scenarios' or something like this, while summerizing the protocol actions in one subsection in the 'protocol overview' section because it seems that the actions are actually quite similar for all use cases, no?

4) Maybe indicate clearly what is recommendated in draft-ietf-hip-rfc5206-bis the following way:
OLD
"[I-D.ietf-hip-rfc5206-bis]
   recommends that a host should send a LOCATOR_SET whenever it
   recognizes a change of its IP addresses in use on an active HIP
   association, and assumes that the change is going to last at least
   for a few seconds. "
NEW
"[I-D.ietf-hip-rfc5206-bis]
   recommends that "a host should send a LOCATOR_SET whenever it
   recognizes a change of its IP addresses in use on an active HIP
   association, and assumes that the change is going to last at least
   for a few seconds. ""

5) How does a host know about this? Can you give examples?
"The grouping should consider also whether middlebox
   interaction requires sending the same LOCATOR_SET in separate UPDATEs
   on different paths."

- I think section 6 ought note the privacy issue that
was relatively recently with WebRTC and ICE where a
client might not want all of it's IP addresses
exposed, as doing so could expose the fact that the
client e.g. is using Tor or another VPN service. The
issue being that in some locations, that information
may be quite sensitive.  4.2 notes this but in a quite
opaque way, ("may be held back") but it'd be better to
say some more. 5.1 is also relevant maybe in that it
says one "SHOULD avoid" sending info about virtual
interfaces. Anyway, I think it'd be good to add some
recognition of this privacy issue to section 6. I am
not arguing that this draft ought specify the one true
way to avoid this problem, but only that it be
recognised.

- 4.11: what's the concern about anti-replay windows?
I didn't get that fwiw, not sure if that just my
relative ignorance of HIP or if more needs to be said
in the document.