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

In general, I find the function proposed by this draft very
useful. Although its clear that more work is needed. In
particular, we can be more concrete when the Mobike base
protocol exists.

Some comments below:

> 3.  Two examples

I did not understand the SCTP example. Can you expand on it?

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

  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?

> 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.
I can see how SCTP and Mobile IPv6 can survive address
changes, but is the proposal to limit this function to
those two examples, or be more generic?

Some nits:

> But transport mode IPsec security associations are end-to-end and
>    have no outer addresses: they cannot be managed by Mobike, for
>    instance, they cannot be updated. 

Perhaps s/they cannot be managed by Mobike/current designs
for Mobike do not support their management/

>  This document uses the standard keywords
>    [keywords] to indicate requirement levels.

Move this to its own section or subsection.

>  to put transport mode ouside of its immediate scope.  But as

s/ouside/outside/

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

> A
>    multi-homed peer can register using a Mobike mechanism its addresses
>    as peer addresses and is authorized to use them to build transport
>    mode IPsec security associations using only one IKE session, aka IKE
>    security association. 

Maybe say instead: "Using Mobike, a multi-homed peer can register its
addresses as peer addresses. It is then also authorized to use them to
build multiple transport mode IPsec security associations within the same
IKEv2 security association."

--Jari

P.S. Is anyone else having trouble with the mobike mailing list?
I've sent several e-mails today and at least for now they are not
getting through, nor is there anything in the archive for October.