Re: MOBIKE WG Agenda for IETF-64, take 1

Hi Mohan,

>>From what i can remember reading the transport draft
>last time, it is not clear to me what it was trying to
>address. It talked about how MOBIKE can be used for
>MIPv6 BU protection and SCTP which are both transport
>mode. Today, it already works with IKEv1/IKEv2. So,
>why do we need MOBIKE ? 
>  
>
And Francis wrote:

>So MOBIKE is not needed but simplifies the world.
>
These are precisely the type of questions we'd
have to figure out before starting work.

>Another *possibility* for transport mode MOBIKE is the
>following. Today NAT-T works for transport mode SAs
>also. This means if you establish a TCP connection
>across a NAT to the server on a public address, and
>the NAT changes the mapping and the TCP connection
>would still work. TCP connection on the server is
>still bound to the old NAT public address but IPsec
>has updated itself to the new address. Now i don't
>know how many implementations really work for this
>case. (Perhaps it works only for L2TP, GRE over IPsec
>like tunnels). With MOBIKE, one can still change
>the address and send an UPDATE to the peer. The
>transport connection should work without a change.
>I have not thought out all the details. Is this an
>interesting case to be solved by MOBIKE ?
>  
>
Possibly. What I'd like to see before taking
on any new work is a rationale why some
function is needed and a scenario where this
is used. I can see what you are saying technically,
but we'd have to figure out who would use
it. Where is transport mode IPsec used today,
and would it benefit from MOBIKE support?
Would potential users adopt it?

--jari