Re: issue 4: how to signal support for MOBIKE

I think we ought to choose either Vendor ID or Notify. While I support
Notify (since this is a standardized, and not a vendor specific, option), I
would rather go with Vendor ID if that's what a majority of the WG wants
rather than have both.

            jak

----- Original Message ----- 
From: "Dondeti, Lakshminath" <[email protected]>
To: "Tschofenig Hannes" <[email protected]>
Cc: "MOBIKE Mailing List" <[email protected]>; <[email protected]>;
"Tero Kivinen" <[email protected]>
Sent: Monday, December 06, 2004 10:23 AM
Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE


> This sounds good.  I was initially leaning toward Notify only, but there
> is no harm in allowing Vendor ID.  I wouldn't necessarily suggest the
> use of "critical bit" here.  Clearly, an implementation may choose to
> use that feature, but there is no need to make that suggestion in each
> context. Thanks.
>
> regards,
> Lakshminath
>
> Tschofenig Hannes wrote:
>
> > 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
> > >
> > _______________________________________________
> > Mobike mailing list
> > [email protected]
> > https://www.machshav.com/mailman/listinfo.cgi/mobike
> >
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
>