-------------------- Francis Dupont (2005-08-01): Some comments about draft-ietf-mobike-protocol-01.txt: - IMHO the WG should pay (again) more attention to its charter: multihoming support is in it and to mention multihoming just before explaining it has nothing to do with the main scenario (and in fact with the document) is not right. So please really fix the Abstract! - motivation 2nd paragraph: the "another example" is a very limited view of what multihoming support needs. I'd like to see the mobike protocol supporting simultaneous multiple peer addresses. (I use the term "peer address" from pki4ipsec documents because it could not confused with addresses in traffic selectors). - in 2.1 the NAT_XXX_IP notifications are mandatory because it is the way the IP addresses in the IP header can be protected against en route modification (what I called the transient NAT attack). As the NAT_DETECTION_* could be interpreted as NAT-T is supported the NAT prevention stuff was introduced... This doesn't matter as soon as the IP addresses which will become the initial peer addresses are reflected in an integrity check. - in 2.2 why the ADDITIONAL_*_ADDRESS are limited to IKE_AUTH? (2.4 is too far, please add a pointer to it) - IMHO we need the capability to remove addresses too. Some care should be taken if we remove all or "important" addresses. (same: pointer to 2.4) - 2.2 is enough to make the transport mode with mobike I-D applicable, so we should progress it? - in 2.3 the SPD entries have to be updated too or expired SAs will be renewed with wrong addresses. - in 2.3 it should be clearer that NAT_XXX notifications are mandatory. - the link between 2.2 and 2.3 is not explained because the new addresses are taken from the IP header. BTW I am afraid the main scenario is the only supported scenario as a consequence... - another limitation of 2.3 is it cannot update selectively a subset of SAs: again a case only is handled! - in 2.4 the case where there is a UPDATE_SA_ADDRESSES before should be explained. I propose to explain that the current peer addresses are IKE_SA parameters and the UPDATE_SA_ADDRESSES echange defines their initial values. - the address update by the responder is a bit complex. It seems to work but I am afraid it should be hard to explain, so I'd like to get a simpler mechanism (IMHO this is again a symptom of mobility vs multihoming problem of the document). - 2.7 is not sound with 2.3 (IMHO the problem is in the wording because the way a NAT_PREVENTION can be associated with a UPDATE_SA_ADDRESSES is clear but is not as described in 2.7). BTW I agree with the TBD (:-). - section 4 misses one of the mobility specific points: the initiator peer address (the MN care-of address) is dynamic/unknown so could not be verified by the responder (VPN server). This is why the protection performed by NAT_XXX notifications are necessary (BTW I have no concern to make it mandatory even in pure multihoming cases). - the fact the ingress filtering works for UPDATE_SA_ADDRESSES because the new addresses are from the IP header should be mentioned (as a justification of this choice or as a point-to-solve if the choice will be changed). - requires != SHOULD. BTW I am against the idea to make MOBIKE less efficient than mobility just because of the FUD of third party flooding attacks. -------------------- Pasi Eronen (2005-09-07): My apologies for the long delay (I was on vacation most of August, and your email somehow slipped through my mind). I've now filed your comments as issue 40 (although since you had quite many comments, some of them might need separate issue numbers later). > - IMHO the WG should pay (again) more attention to its > charter: multihoming support is in it and to mention > multihoming just before explaining it has nothing to do with > the main scenario (and in fact with the document) is not > right. So please really fix the Abstract! Ok, I'll try to rephrase this in the next version. > - motivation 2nd paragraph: the "another example" is a very > limited view of what multihoming support needs. I'd like to > see the mobike protocol supporting simultaneous multiple peer > addresses. (I use the term "peer address" from pki4ipsec > documents because it could not confused with addresses in > traffic selectors). Since the first version of MOBIKE only deals with the outer (tunnel header) addresses, using multiple addresses for an IPsec SA simultaneously would probably mean either load balancing (explicitly ruled out in the WG charter) or sending copies of a single ESP packet over several paths (nobody has expressed any interest in this so far). But this is probably not what you meant... ? > - in 2.1 the NAT_XXX_IP notifications are mandatory because it > is the way the IP addresses in the IP header can be protected > against en route modification (what I called the transient NAT > attack). As the NAT_DETECTION_* could be interpreted as NAT-T > is supported the NAT prevention stuff was introduced... This > doesn't matter as soon as the IP addresses which will become > the initial peer addresses are reflected in an integrity > check. You're right, I forgot to show the NAT_PREVENTION notification in Section 2.1 (Section 2.6 did say that it's also included in IKE_SA_INIT). I'll fix this... > - in 2.2 why the ADDITIONAL_*_ADDRESS are limited to IKE_AUTH? > (2.4 is too far, please add a pointer to it) Ok, I'll add a pointer. > - IMHO we need the capability to remove addresses too. Some > care should be taken if we remove all or "important" > addresses. (same: pointer to 2.4) We already have the _capability_ to remove addresses (you send a new address list that does not contain the address you want to remove). The same capability could be implemented by more complex protocol mechanisms, but I don't currently see any reason to do so... >- 2.2 is enough to make the transport mode with mobike I-D > applicable, so we should progress it? A good question, I'll leave this to the WG chairs... > - in 2.3 the SPD entries have to be updated too or expired SAs > will be renewed with wrong addresses. I'll add a clarification about this (where exactly the addressses have to be updated depends a lot on the implementation; e.g. the VPN client I have on my PC treats the IPsec tunnel as a virtual interface, and stores some of the information RFC 2401 would call "SPD" in what the implementation calls "routing table"). > - in 2.3 it should be clearer that NAT_XXX notifications are > mandatory. Do you mean the NAT_DETECTION_*_IP or NAT_PREVENTION notifications? Currently the idea is that if you support NAT-T, you include NAT_DETECTION_*_IP payloads; if you don't want NAT-T and do want the "NAT prevention" feature, you include NAT_PREVENTION (but not NAT_DETECTION_*). > - the link between 2.2 and 2.3 is not explained because the > new addresses are taken from the IP header. BTW I am afraid > the main scenario is the only supported scenario as a > consequence... Could you give a concrete example of a scenario that can't be done currently? > - another limitation of 2.3 is it cannot update selectively a > subset of SAs: again a case only is handled! Yes, and this is intentional (there was rough consensus in issue 8 to do it this way -- if you want to update a subset of SAs, you need to have several IKE_SAs). > - in 2.4 the case where there is a UPDATE_SA_ADDRESSES before > should be explained. I propose to explain that the current > peer addresses are IKE_SA parameters and the > UPDATE_SA_ADDRESSES echange defines their initial values. I'll try to clarify 2.4 in the next version.. > - the address update by the responder is a bit complex. It > seems to work but I am afraid it should be hard to explain, so > I'd like to get a simpler mechanism (IMHO this is again a > symptom of mobility vs multihoming problem of the document). I agree the explanation is quite complex. I'll try to simplify it in the next version... > - 2.7 is not sound with 2.3 (IMHO the problem is in the > wording because the way a NAT_PREVENTION can be associated > with a UPDATE_SA_ADDRESSES is clear but is not as described in > 2.7). BTW I agree with the TBD (:-). Quite right. I'll work on this for -02. > - section 4 misses one of the mobility specific points: the > initiator peer address (the MN care-of address) is > dynamic/unknown so could not be verified by the responder (VPN > server). This is why the protection performed by NAT_XXX > notifications are necessary (BTW I have no concern to make it > mandatory even in pure multihoming cases). I'm updating the security considerations section in the next version (see also issues 27 and 28), I hope the new text better takes this into account. > - the fact the ingress filtering works for UPDATE_SA_ADDRESSES > because the new addresses are from the IP header should be > mentioned (as a justification of this choice or as a > point-to-solve if the choice will be changed). Good point, I'll add this to the security considerations section. > - requires != SHOULD. BTW I am against the idea to make MOBIKE > less efficient than mobility just because of the FUD of third > party flooding attacks. I fully agree that these flooding attacks are mostly FUD, and I would not mind changing the "return routability check SHOULD be done before updating.." to a MAY or something. But on the other hand, you can ignore the SHOULD if want, too. -------------------- (Issue list maintainer's note: see mailing list for more discussion) --------------------