Re: about draft-ietf-mobike-protocol-01.txt (issue 40)

 In your previous mail you wrote:

   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.
   
=> I am afraid that the issue is not only on wording, i.e.,
if you change the wording to reflect the real goal of the
document we'll be in real trouble with the charter (the IETF
one).

   > - 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... ?
   
=> no, I mean simultaneous multiple peer addresses for different
IPsec SAs, something I've called the SCTP model for multihoming
(note it is not only for SCTP, it was just accurately described
in SCTP documents).

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

=> this is covered by my "pointer to 2.4". IMHO some introduction
statements will be fine...

   > - 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").
   
=> IMHO there is no choice here: the formal description is in 2401bis
and we have to use it even when we know the implementations have only
to provide the same behavior and can use very different structures.

   > - in 2.3 it should be clearer that NAT_XXX notifications are
   > mandatory.
   
   Do you mean the NAT_DETECTION_*_IP or NAT_PREVENTION
   notifications?
   
=> yes.

   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_*).
   
=> I agree, my concern is there must be no case without any NAT_XXX.

   > - 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?
   
=> multihoming.

   > - 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).
   
=> the problem is if the intention is not to support multihoming
(and it seems there is a rough consensus about this :-) the charter
must be updated. Or we'll get IESG comments or even an appeal
about the document and its lack of support for anything else
than mobility.

   > - 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.
   
=> as I wrote the term here is "requires" which is stronger than
the SHOULD we agree about.

Thanks

[email protected]