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

--- Francis Dupont <[email protected]>
wrote:

>  In your previous mail you wrote:
> 
>    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 ? 
>    
> => MIPv6 BU protection and SCTP have an
> authorization issue
> (remember the zillion of messages in the mip WG
> mailing list
> about this). The address management provided my
> MOBIKE
> is a clean and simple solution to this issue.
> So MOBIKE is not needed but simplifies the world.
> (you should reread the draft, even you are one of
> the few
> persons I know they have read it :-).
> 
In the case of MIP6 it might make sense because
MN-HA MUST use IPsec to protect BUs and MOBIKE
provides the RR check for the CoA. But SCTP has to
solve the authorization issue anyway because you
may not use IPsec with SCTP always.

>    Another *possibility* for transport mode MOBIKE
> is the
>    following. Today NAT-T works for transport mode
> SAs
>    also.
> 
> => not in the IKEv2 framework (i.e., NAT-T support
> for
> transport mode is an extension).
> 
I am not sure i understand this.
Can you point me to a section in IKEv2 draft which
states this ? 

>    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.
> 
> => only a little number because the IPsec marker is
> VPN,
> i.e., tunnel mode only.
> 
Agreed.

>    (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.
> 
> => note with transport mode you don't change the
> endpoint
> addresses but the traffic selectors.
> 
Not in this case. In this case the traffic selectors
don't change across mobility. I just realised that
this has the same problems as the "spi collisions"
issue. The transport connection is still bound to the
original address which can be reused by some other
node. But should be less of an issue with "IP-IP"
transport mode like tunnels i guess.

>    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 ?
>    
> => this is the issue #7 and I explicitely didn't
> propose
> to reopen it (you can but please don't mix this with
> my
> transport mode/MOBIKE draft).
> 
Issue 7 is about transport mode. You have to reopen
it for your draft too :-)

-mohan

> Regards
> 
> [email protected]
>    
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>