Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT)
Hi Tom, see below. > Am 18.09.2016 um 18:40 schrieb Tom Henderson : > > 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 mult
Re: [Hipsec] Mirja Kühlewind's No Objection on draft-ietf-hip-multihoming-11: (with COMMENT)
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. > > 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? > > 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. > > 3) I (again) would find it easier to have section 4.9, 4.10, and 4.11 > before 4.
