about draft-ietf-mobike-protocol-01.txt

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.

Regards

[email protected]