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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Tom,

see below.

> Am 18.09.2016 um 18:40 schrieb Tom Henderson <[e-mail]>:
> 
> Mirja, thank you for your comments; replies again are inline below.
> 
> On 09/13/2016 07:40 AM, Mirja Kuehlewind wrote:
>> Mirja Kühlewind has entered the following ballot position for
>> draft-ietf-hip-multihoming-11: No Objection
>> ----------------------------------------------------------------------
>> 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.
> 
> OK
> 
>> 
>> 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. 
> 
> In the above case, the rationale for placing that text in the multihoming draft is that the possible need to expose additional locators during the base exchange arises in a multihoming context.  I don't think that draft-ietf-hip-rfc5206-bis-13 implementations (without multihoming support) need to support inclusion in the base exchange.
> 
> I'm fine with moving this sentence: 
> 
>  "Hosts MUST NOT announce broadcast or multicast addresses in LOCATOR_SETs. "
> 
> to RFC 5206-bis, and I agree to write some introductory paragraph to this document that points to the necessary parts of 5206-bis to support.
> 

Okay.

>> 
>> 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.
> 
> Can you or someone suggest specific RFCs to cite here?

I’m not aware about an respective RFC out of my head. I was also thinking about research papers, e.g. I know this one:

Experimental evaluation of multipath TCP schedulers
by Christoph Paasch, Simone Ferlin, Ozgu Alay, Olivier Bonaventure

http://dl.acm.org/citation.cfm?id=2631977

> 
>> 
>> 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?
> 
> I believe that the reason for this was to try to keep the implementation simpler, and keep the inbound/outbound SA lifetimes consistent.  This recommendation removes the decision point in the implementation, when receiving a request to rekey, whether or not to rekey the corresponding SA.
> 
> There is less operational experience with multihoming extensions, which was one of the reasons to split RFC5206 originally (to complete mobility specification but perhaps allow multihoming specifications to evolve further over time).  It is possible to create lots of pairwise SAs between various locators, but it is not as clear when to do that versus when to try to reuse SAs across multiple locators.  For instance, when multihoming is used actively for load balancing, perhaps multiple SA pairs are favorable (to avoid anti-replay checks failing from reordered packets), but maybe in a fault tolerance situation, they are less needed.
> 
> I believe that the text in section 4.4 that you cite could have a pointer that section 4.11 later discusses this issue in more detail.

Yes. Also maybe just don’t use normative language here, if you are actually not sure.

> 
>> 
>> 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?
> 
> I think that 4.9-4.11 are more refinements or special cases than the subsections preceding them, so I would refrain from reordering them.  However, I'll take a stab at adding a 'master scenario overview' that could be used as a roadmap to the rest of the subsections.

That might help. Thanks! Otherwise no strong opinion here, so whatever you do should be fine.

> 
>> 
>> 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. ""
> 
> OK 
> 
>> 
>> 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."
> 
> This comment arises from the consideration of (future) HIP-aware NATs that might perform parameter inspection.  I'm not sure that there are any solid ways to know about whether these exist, other than operational knowledge about the networks where HIP is deployed.
> 
> How about rephrasing such as this?
> 
> "If hosts are deployed in an operational environment in which HIP-aware NATs (that may perform parameter inspection) exist, and different NATs may exist on different paths, hosts may take that knowledge into consideration about how addresses are grouped, and may send the same LOCATOR_SET in separate UPDATEs on the different paths.  However, more detailed guidelines about how to operate in the presence of such HIP-aware NATs is a topic for further study.“

Already much better.

> 
> The alternative might be to delete this topic entirely since it is a bit speculative.

Also an option…

Thanks!
Mirja


> 
> - Tom