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

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

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

   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.

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

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

Regards

[email protected]