[Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT)

["Mirja Kuehlewind" <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-hip-multihoming-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-hip-multihoming/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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