Re: issue 4: how to signal support for MOBIKE

Jari, Tero, Hannes, Kempf and others:
 
I see the benefit of using either of the approaches - Vendor ID vs. Notify and am fine with either one.
 
However, just a question or "food for some more thought", here is a scenario:
 
1) Client Peer establishes a Mobike Session with Remote Peer (or server)
2) Client Peer moves to a new access point and due to change in the IP address, re-registers with the Remote Peer (or server) - session type now however (for ANY reason) is not to be Mobike Session any more :- It could be anything let's say a simple IKEv1/IKEv2 session
3) Client Peer moves again causing the IP address change again, re-registers with Remote Peer (or server) again - BUT the session type now "for some reason can and should be" a Mobike Session
 
How will this scenario be supported with the existing recommendtions in Mobike?
Will Notification vs. Vendor ID approach have any positive or negative impact in the afore mentioned scenario?
 
Regards,
-Tarique Mustafa
 
 
 


Jari Arkko <[email protected]> wrote:
Yes. We shall only have one. 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

James Kempf wrote:
> 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" 
> To: "Tschofenig Hannes" 
> Cc: "MOBIKE Mailing List" ; ;
> "Tero Kivinen" 
> 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
>>
> 
> 
> 
> _______________________________________________
> 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

		
---------------------------------
Do you Yahoo!?
 Read only the mail you want - Yahoo! Mail SpamGuard.

_______________________________________________
Mobike mailing list
[email protected]
https://www.machshav.com/mailman/listinfo.cgi/mobike