Re: comments on draft-dupont-mobike-transport-00.txt

 In your previous mail you wrote:
   
   In general, I find the function proposed by this draft very
   useful. Although its clear that more work is needed.

=> I know but I believe only the form (i.e., better wording,
clarifications, etc) needs to be improved.

   In particular, we can be more concrete when the Mobike base
   protocol exists.
   
=> IMHO we need only few properties of it, not a concrete proposal.

   Some comments below:
   
   > 3.  Two examples
   
   I did not understand the SCTP example. Can you expand on it?
   
=> I'll rework it (followup in private).

   >    IKEv2 and Mobike mechanisms do verify that the primary peer address
   >    (for IKEv2) and further alternate peer address (for Mobike
   >    mechanisms) are correctly authenticated and authorized, so they MAY
   >    safely be used for transport mode IPsec security associations as
   >    endpoint addresses.
   
   I'd like to understand this better. Is it correct to say that
   the folllowing issues are involved:
   
=> note that the verification is done by the Mobike protocol and
the details are not *relevant*.

     o  Verification that the claimed IP address actually exists.
        FOr instance, the peer has not just manufactured a bogus
        address. The IKE negotiations and/or address tests take
        care of this.
   
     o  Verification that its really this peer that is behind
        this IP address. It would be bad if I could grab
        someone else's IP address because, say, if that someone
        else needed to communicate with the node in future
        but couldn't do so because I already had a connection
        open with that address pair.
   
     o  Verification that a number of different addresses A,
        B, C, etc. all are the same entity. This is actually
        the main issue, right?
   
=> these are details so these are irrelevant: the Mobike protocol
is supposed to be safe.

   > 2.  Transport mode and addresses
   
   Maybe I'm missing something obvious but I think we also
   need a discussion on how this impacts upper layer protocols.

=> until an upper layer protocol will fully survive to address changes
we can assume there is no interest to transport mode to survive
to address changes.

   I can see how SCTP and Mobile IPv6 can survive address
   changes,

=> note this is not really true for SCTP: SCTP has only limited
readdressing support.

   but is the proposal to limit this function to
   those two examples, or be more generic?
   
=> the proposal is to do nothing today to solve the issue, i.e.,
to put transport mode stuff out of the immediate scope of Mobike.

   >    Using a Mobike peer address management (as in [ADDRMGT]) a mobile
   
   Pending the appearance of a WG draft for the base MOBIKE solution,
   I think it would be appropriate to list a couple of other alternative
   address management protocol proposals too, just to make it clear
   that what you say in this draft is not bound to [ADDRMGT] but could
   also be used with the other drafts.
   
=> I give the reference only as an example, or in other words
the reference is here to avoid a long explaination about what I mean
by "peer address management".

Thanks

[email protected]