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

--- Jari Arkko <[email protected]> wrote:

> Francis Dupont wrote:
> 
> >=> I don't believe it is very useful to discuss
> about the
> >transport mode/Mobike I-D (according to comments
> about it in
> >the list, BTW the I-D does not address issue #7).
> >
> >For SCTP it is clear there is something to do but
> not so clear what...
> >BTW is the RFC 3554 supported? (if it is we should
> get the feedback
> >from an implementor)
> >
> >For multi-homing in general I believe we should
> reconsider
> >the issues #8 and #20. Of course the issue #63
> could apply.
> >(who should present this? IMHO we mainly need a
> discussion)
> >  
> >
> The transport draft does not have too many details.
> We do not have a written proposal on the table for
> SCTP support nor issue #8 extension of MOBIKE*.
> 
>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 ? 

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 ?

-mohan