[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
new draft about address management for IKv2
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
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.
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.