RE: New issue 16: No packets from other end?

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