Subject: RE: [Mobike] New issue 16: No packets from other end?

From: <[email-masked]>
Date: Tue, 24 Aug 2004 18:01:21 +0300

Hi Vijay (and sorry for a long delay in replying),

> I am not sure how you can do that. what if the application
> prefers "failing" to using an expensive link?
> 
> for example, lets assume my mobile device has a low bandwidth
> GPRS link (address IP1 on that link) and a high bandwidth WLAN
> link (address IP2 on that link). I have set it up so that my
> email is downloaded only when I connect to my Enterprise
> through a VPN connection when I have the WLAN link. if the
> WLAN link is not available, I dont want the email client to
> download email. lets assume I am in the middle of downloading
> email. I lose WLAN coverage. with your proposal, the MOBIKE
> protocol switches to using IP1. I dont want that.

I agree, certainly we should have enough flexibility in
the specs to handle both cases here (switching to another
path and failing), depending on local policies.

> > We don't need to specify exactly how this works, and as Francis
> > pointed out, there are many complex issues in e.g. handoff 
> > decisions that we don't want to put in MOBIKE specs.
> > 
> > What we IMHO do need to specify are the parts required for 
> > interoperability, like what is sent/received to/from the other 
> > node, and some parts of how those messages are processed. 
> > I think this should be specified in the MOBIKE spec; that is, we
> > should not assume that there is some other unspecified protocol 
> > (in addition to IKEv2 and ESP/AH) running between the parties.
> 
> IMHO, I prefer "something in the Mobile Node" telling MOBIKE,
> "switch to using this address with this VPN GW". then a MOBIKE
> update should be sent. this is the model I had in my mind.
> 
> for "something in the Mobile Node" I had assumed DNA, MIP6,
> Multi6, new address configuration, default router change, etc...

Those are the things Jari called "local knowledge": 
something in the mobile node knows what should be done
("switch to this address"), based on information
that's "local" in the sense that it's not a result
of an end-to-end protocol between the IKEv2 nodes.

I don't think there's any disagreement about handling those: 
we just assume that there's "something" in the mobile node 
that triggers appropriate MOBIKE messages to be sent.

But issue 16 is more about what to do if we know there 
is a problem (==we don't receive any replies to our IKE 
requests, even after retransmissions), but we don't know 
what address change would correct the situation (because
the "local knowlege" is either not reliable enough,
or the failure is in the "middle" where local knowledge
does not reach).

Here the options seem to be: (1) fail, (2) send some 
IKEv2 message(s), either new ones or the one we were 
retransmitting, along some other path, and use information
about their delivery to help deciding what should
be done, or (3) send some non-IKEv2 message(s) along 
some other path.

Now, option 1 would be the right choice only if we 
assume that the "local knowledge" is reliable enough, 
and we do not care about non-local failures. (Is this
the choice you prefer?)

Option 3 means we don't have interoperability unless the
nodes also agree what that non-IKEv2 end-to-end (between
IKEv2 peers) protocol is. 

So my opinion is strongly something like option 2: if 
we don't receive replies to our IKEv2 request(s), try 
sending them along some other path (unless the current 
path is the only one acceptable to us, of course).

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 24 Aug 2004 19:00:40 +0300

This is a good summary, thanks Pasi.

I would add that in some cases we have also option 4:
wait until the local knowledge gets a chance to
be updated. For instance, even standard (not
RFC 3775 or DNA WG-enhanced) IPv6 neighbor discovery
will eventually detect a movement, even if this can
be slow. This also makes a feature interaction
possible where MOBIKE decides to do something (e.g.,
move to GPRS) while in fact we were still in the
DNA process and were going to tell MOBIKE to do
something else (e.g., move to this new local LAN
link).

But I personally would also like option 2, as long
as we also assume basic local link movement detection
from a non-MOBIKE mechanism.

Seems like most people want to rely on some sort of
standard movement detection process outside MOBIKE
(= the local knowledge). Question: how are we going
to specify this, just as an assumption that its outside
the MOBIKE protocol, or as a hard requirement to do
<something>? It seems that the former is the only
option, given that movement detection is somewhat of
a moving target (no pun intended). IPv4 and IPv6 have
different capabilities, several enhancements are being
worked in different places (MIP6/DHCP/DNA WGs), etc.

--Jari

---

From: Francis Dupont <[email-masked]>
Date: Mon, 30 Aug 2004 17:07:35 +0200

In your previous mail you wrote:

   (= the local knowledge).

=> = what I called "generic mobility/multi-homing control".

   Question: how are we going
   to specify this, just as an assumption that its outside
   the MOBIKE protocol, or as a hard requirement to do
   <something>?

=> clearly outside.

   It seems that the former is the only
   
=> we should also consider multi-homing which is not so easy...
At least for mobility we have some practice (:-)!

Thanks

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