Hi Tom,

see below.

> Am 18.09.2016 um 18:40 schrieb Tom Henderson <tomh...@u.washington.edu>:
> 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
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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.


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


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

>> 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…


> - Tom

Hipsec mailing list

Reply via email to