Subject: RE: [Mobike] issue 4: how to signal support for MOBIKE

From: Tschofenig Hannes <[email-masked]>
Date: Mon, 6 Dec 2004 10:16:18 +0100

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-masked]] 
> Sent: Dienstag, 30. November 2004 11:41
> To: [email-masked]
> 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-masked]
> _______________________________________________
> Mobike mailing list
> [email-masked]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Mon, 06 Dec 2004 13:23:24 -0500

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 6 Dec 2004 10:33:26 -0800

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-masked]>
To: "Tschofenig Hannes" <[email-masked]>
Cc: "MOBIKE Mailing List" <[email-masked]>; <[email-masked]>;
"Tero Kivinen" <[email-masked]>
Sent: Monday, December 06, 2004 10:23 AM
Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE

---

From: "Dondeti, Lakshminath" <[email-masked]>
Date: Mon, 06 Dec 2004 13:42:37 -0500

Just wanted to note that a clarification might be in order around the 
"critical bit" usage.  That would only be applicable if a new payload 
type were to be defined for MOBIKE signaling, right? 

So, are 3 options on the table: 1) new payload type that might be marked 
critical 2) vendor ID, and 3) notify payloads?  I think 2 options: 
vendor ID and notify payloads, would be sufficient for MOBIKE signaling; 
there is no need for a new payload type for this!

regards,
Lakshminath

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 6 Dec 2004 10:50:28 -0800

> Notify (since this is a standardized, and not a vendor specific, option), I

Yes. Also, as this is in sync with other features of IKEv2, it makes sense
to use NOTIFY.

-mohan

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Dec 2004 22:06:33 +0200

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 went thought about the two most important options: notify and vendor
> 
> id
> 
>>>A node needs to be able to guarantee that its address change messages
> 
> are
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Dec 2004 22:45:54 +0200

Tarique Mustafa wrote:

> 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?

I don't think this particular choice has an effect to your
scenario.

As far as your scenario goes, switching on and off support for
some feature (such as MOBIKE) probably does have some ill effects.
In this particular case Step 2 may cause the earlier session to
be thrown away, so you have to re-establish everything.

But the interesting case is Step 3. The question is *when* do
you signal support for MOBIKE? If you did not signal it earlier,
can you switch in mid-session? I believe the answer for that
should be that you can send the notification at any time. But
the notification turns MOBIKE support on -- I don't think we
need a notification to turn it off.

--Jari

---

From: Tarique Mustafa <[email-masked]>
Date: Mon, 6 Dec 2004 12:34:05 -0800 (PST)

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-masked]> wrote:

--Jari

James Kempf wrote:
> From: "Dondeti, Lakshminath" 
> To: "Tschofenig Hannes" 
> Cc: "MOBIKE Mailing List" ; ;
> "Tero Kivinen" 

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2004 11:59:21 +0100

In your previous mail you wrote:

=> it seems the IPsec WG was not in favor of vendor ids so I vote for
notify.

=> IMHO the critical bit will simply kill the session when it is not
supported (i.e., there is no recovery). This is why the idea to negociate
MOBIKE support ASAP is the right one.
BTW the discussion was between a new payload or a new exchange for
SA updates (I believe the best is a new payload but I have no strong
argument).

Regards

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Dec 2004 16:54:46 +0200

> there is no need for a new payload type for this!

Its hard for me to imagine a situation where we'd want to
fail the connection if the other end does not support
MOBIKE. So for capability discovery we don't want to turn
the critical bit on. And after we have discovered the
capabilities, we can either use or not use the critical
bit, but it should never fail, given a correct implementation.

In any case, this issue was about the capability discovery,
not about how to represent the other MOBIKE messages. We
haven't gone that far yet...

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 16 Dec 2004 16:58:20 +0200

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).

Pasi, I think you can mark this issue closed on the issues
page.

Hannes, I think you can use the text that you posted
a while ago, updated with the decision to use Notify
and a discussion of the timing of this Notify.

--Jari

Jari Arkko wrote:
>> ----- Original Message ----- From: "Dondeti, Lakshminath" 
>> <[email-masked]>

---

From: Tarique Mustafa <[email-masked]>
Date: Sat, 18 Dec 2004 01:19:49 -0800 (PST)

Jari,
My original set of questions regarding this issue somehow did not get sent on the group so I am including here my questions again for everybody's input.

=======

 

Regards,
-Tarique Mustafa

--Jari

---------------------------------
Do you Yahoo!?
 The all-new My Yahoo! – What will yours do?