new draft about address management for IKv2

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

I've just submitted a new version of my draft,
its name is draft-dupont-ikev2-addrmgmt-03.txt
and as it should not be available so soon in the I-D
repositories I've put a copy on
ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ikev2-addrmgmt-03.txt

I've tried to make it compatible with current IKEv2 draft (i.e.,
minimize changes) and with Tero/Jari's proposal:
 1- NAT traversal is fully handled by the (fixed) IKEv2 draft
 2- if IKE is launched over UDP 4500, go to 1
 3- if IKE is launched over UDP 500, NAT detection (using the
    two NAT_DETECTION_*_IP notification) is mandatory
    (=> small change is needed in the IKEv2 draft)
 3a- if a NAT is detected, go to 1
 3b- if no NAT is detected: the context where my proposal applies:

   The peer addresses (the addresses IKE runs over) are IKE SA parameters,
   and they are specified implicitly in the IKE_SA_INIT messages where
   BTW they are implicitly protected by the mandatory NAT_DETECTION
   notifications. (=> a small clarification is needed in the IKEv2 draft)

   IPsec SAs are set up for these peer addresses, i.e., they become
   the endpoint addresses of any new SA. (=> another small
   clarification, I suggest to define once what is an IKE SA).

   Here we have two very similar ways we can follow in a postponed
   specification activity: what to do when one'd like to change
   a peer address (note: *no* required change in the IKEv2 draft):

    * (Tero/Jari's) a new mechanism (notification/payload) can update
      the endpoint addresses of all SAs, including the IKE SA.

    * (mine) two new notifications can explicitly protect the peer
      addresses for the setup of one IKE SA or one IPsec SA pair.
      A new payload can update the endpoint of all or a subset of SAs.

   Notes: the update mechanism uses or integrates some ways to
   protect new peer addresses. An IKE SA update implicitly updates
   the peer addresses for further SA establishments.
   My proposal includes some extensions for multi-homing, it should
   avoid the need of an "IKEv2 extensions for SCTP" document.

Regards

Francis.Dupont@enst-bretagne.fr

PS: I've cross posted this message in the mobile-ip WG list because
I believe we'd like to get a new version of IKE which is secure and
efficient in mobile environments.