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

 In your previous mail you wrote:

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

=> hum, it seems we are in complete misunderstanding...
In MIPv6 the MN-HA IKE is run over the CoA but the IPsec SA
pair in transport mode must be established with the HoA.
So IKE has to check if the MN has the authorization to use
this particular HoA. In place to have a dedicated code for MIPv6
in IKE I simply propose to use the MOBIKE framework to add the
HoA as an additional address and to check (not using RR please :-)
if it is authorized.

   But SCTP has to
   solve the authorization issue anyway because you
   may not use IPsec with SCTP always.
   
=> I am talking about authorization of additional peer addresses
in IKE/IPsec.

   > => 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 ? 
   
=> I believed there was no NAT-T support for transport mode because
there is no NAT-OA but you are right:

      The original source and destination IP address required for the
      transport mode TCP and UDP packet checksum fixup (see [Hutt04])
      are obtained from the Traffic Selectors associated with the
      exchange.

Note this makes more complex to path the Traffic Selectors (:-).

   But should be less of an issue with "IP-IP"
   transport mode like tunnels i guess.

=> yes, the IP-IP transport mode is clearly a special case.
(there is a comment by Joe Touch about this in issue #7)
   
   Issue 7 is about transport mode. You have to reopen
   it for your draft too :-)
   
=> the issue #7 question is a bit ambiguous but as it is from
a comment of mine, the real issue is about peer address change
for transport mode SAs (so not addressed by my draft)
So can we agree that to reopen the issue #7 is to look at
if/how to update transport mode SAs?

BTW my opinion is the complexity is too high and the current
solution (reestablish SAs with new addresses) is enough
in the general case.
   
Regards

[email protected]

PS: for the tunnel special case (the traffic is selected by it is
in the tunnel, i.e., a particular interface and protocol) we have
two choices:
 - write a specific document
 - add it in the transport document (I can provide the current
   version in xml2rfc to a co-author who shall write the text).