-------------------- IETF59 MOBIKE WG minutes: [discussing whether to create a new payload or use Notification payloads --secretary] Francis Dupont: A payload is needed, because payloads can be marked as critical (IKEv2 payload bit). Pasi Eronen: IKEv2 spec has a method for signalling the other end which extensions are supported. -------------------- Jari Arkko (2004-11-29): I don't think we officially closed this issue yet, but it seems that when we discussed it in the past meetings we converged on using the vendor IDs as specified in the IKEv2 spec: A Vendor ID payload MAY announce that the sender is capable to accepting certain extensions to the protocol, or it MAY simply identify the implementation as an aid in debugging. A Vendor ID payload MUST NOT change the interpretation of any information defined in this specification (i.e., the critical bit MUST be set to 0). Pasi's draft contains an example of how this would be done for MOBIKE: Implementations that support this specification MUST include a Vendor ID payload in the IKE_SA_INIT exchange (first two messages). The value for this payload is XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX (TBD). The other alternative that has been discussed is the use of the critical bit. We would define a new payload and mark it critical. Here's my reasoning why the Vendor ID payload approach seems slightly better: First, we need to remember that the initial IKEv2 exchange is at least four messages. This means that if we want to exchange capabilities and addresses, we can exchange the capabilities in the first round and then alternative address information in the second round. So I would suggest that we use the Vendor ID approach. Below you'll find my suggested text for the design draft. (A quick search revealed no previous text about the matter, but I may have missed something.) X. Indicating Support for MOBIKE A node needs to be able to trust that its address change messages are understood by the peer. Otherwise an address change may render the connection useless, and it is important that both sides realize this as early as possible. Ensuring that the messages are understood can in be arranged either by marking some IKEv2 payloads critical so that they are either processed or an error message is returned, or by using Vendor ID payloads. In the latter approach a specific string denoting MOBIKE will signal the support of the MOBIKE protocol. (Should there be optional, separable parts in the protocol there may be a need for more than one Vendor ID; this is left for further study). The recommended solution is to use Vendor ID payloads during the initial IKEv2 exchange, perhaps in the first round, so that the second round can be used for actual MOBIKE signaling, if necessary. This ensures that in all cases a MOBIKE capable node knows whether its peer supports MOBIKE or not. If the peer does support MOBIKE, the node can then use MOBIKE-specific messages and payloads, with the critical bit set to zero or one depending on the semantics of the message. If the peer does not support MOBIKE, then the node knows that, at least without NATs, a movement implies need to rerun IKEv2 from the start. Note that the node could also attempt MOBIKE optimistically with the critical bit set to one when a movement has occurred. The drawback of this approach is, however, that the an unnecessary MOBIKE message round is introduced on the first movement. -------------------- Tero Kivinen (2004-11-30): I would suggest NOTIFY approach. I.e we send notify saying MOBIKE_SUPPORTED and thats it. Similar thatn what is done for the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc. In most cases we do not want to fail the negotiation even if the other end does not support MOBIKE, we simply revert back to redoing the authentication every time IP-addresses changes. If our final protocol is going to use notifies to send the IP-addresses, then we can use those notifies to signal the use of MOBIKE instead of separate MOBIKE_SUPPORTED notify. -------------------- Hannes Tschofenig (2004-12-06): i went thought about the two most important options: notify and vendor id they both seem to provide the same capability. notify is used for errors but also for indicating sender capabilities. the same is true for the vendor id. as a text proposal i suggest to enhance the text offered by jari as follows: X. Indicating Support for MOBIKE A node needs to be able to guarantee that its address change messages are understood by the peer. Otherwise an address change may render the connection useless, and it is important that both sides realize this as early as possible. Ensuring that the messages are understood can in be arranged either by marking some IKEv2 payloads critical so that they are either processed or an error message is returned, by using Vendor ID payloads or via a Notify. The first solution approach is to use Vendor ID payloads during the initial IKEv2 exchange using a specific string denoting MOBIKE to signal the support of the MOBIKE protocol. This ensures that in all cases a MOBIKE capable node knows whether its peer supports MOBIKE or not. The second solution approach uses the Notify payload which is also used for NAT detection (via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP), . Both, a Vendor ID and a Notify payload, might be used to indicate the support of certain extensions. Note that the node could also attempt MOBIKE optimistically with the critical bit set to one when a movement has occurred. The drawback of this approach is, however, that the an unnecessary MOBIKE message round is introduced on the first movement. -------------------- Jari Arkko (2004-12-06): Based on Hannes' analysis, both options seem to provide the same functionality. I am personally fine with either approach. Given that we are writing a design draft, perhaps we should make a design decision and pick one? It seems that a few people preferred the Notify. I'm not sure I understood Tero's objection to Vendor ID, but at least Notify sounds nicer. Pick that and move one to the next issue? -------------------- Jari Arkko (2004-12-16): My interpretation of this thread is that most people prefer the Notify approach, and it is sufficient for our needs. Based on the question from Tarique, I would add that we need to allow MOBIKE support to be notified at any time (but never turned off, it does not seem to make sense). -------------------- Closed issue with resolution "Use Notify payloads". --------------------