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 >> ---------------------------------------------------------------------- >> 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 _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
