RE: issue 4: how to signal support for MOBIKE

hi all, 

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.

-----------------------

ciao
hannes
 

> -----Original Message-----
> From: Tero Kivinen [mailto:[email protected]] 
> Sent: Dienstag, 30. November 2004 11:41
> To: [email protected]
> Cc: MOBIKE Mailing List
> Subject: [Mobike] issue 4: how to signal support for MOBIKE
> 
> Jari Arkko writes:
> > So I would suggest that we use the Vendor ID approach.
> 
> 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.
> --
> [email protected]
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>