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

Vijay Devarapalli writes:
> > 
> > However, that's the part that the rest of the stack is
> > telling MOBIKE. The second level is what happens after
> > MOBIKE has been told something. For instance, lets say
> > that it has been told that there's two usable addresses
> > at this end and one at the other end; that's two possible
> > address pairs. Now we get a problem -- ESP tells IKE
> > that there's no packets, IKE attempts DPD which fails.
> > There's no information coming from IPv6/DNA/DHC/MIP6
> > (and presumably there will not be any information coming
> > soon either, because the DPD process took a while).
> 
> I dont agree with this statement. IMHO, if IPv6/DNA/DHC/MIP6 
> are not able to figure out what happened, MOBIKE should just 
> keep quiet.
> ...
> I think (2) is the way to go. I dont want MOBIKE making a
> decision that conflicts with IPv6/DNA/DHC/MIP6/SCTP/whatever.

I think we need to clearly separate host-internal implementation
issues and specifying interoperability-enabling protocols here.

This issue was not about whether the "MOBIKE module" should keep 
quiet or decide something or conflict with someone else; it was
whether we should make it possible for a _host_ to recover from 
a situation where its IKE endpoint and the peer IKE endpoint 
cannot communicate using the current addresses.

Whether that recovery is "controlled" by the "MOBIKE module",
or perhaps some "general mobility/multihoming module" (possibly 
using information from some "DNA module") in the host is 
completely besides the point.

I do agree that actual implementations might work e.g. so that 
when DPD seems to fail, the "MOBIKE module" notifies the "mobility
and multihoming control module" that "we seem to have a problem;
but the peer said it also has addresses B2,B3,B4; please tell 
me what to do". The control module could then tell MOBIKE module 
that "based on your report, and information I may have received 
from other modules, my decision is to start using local address
A2 and remote address B3".

The interface between those modules is of course not MOBIKE WG's
business, but I hope you're not opposing that we allow such
interfaces to be built?

BTW, if we were adding MOBIKE to IKEv1, nothing extra would be 
needed in the protocol to allow hosts to handle this "no packet 
from other end" case; the R-U-THERE dead peer detection messages 
[RFC3706] would be enough.

But currently it seems (to me at least) that in IKEv2, the ability 
to send some kind of R-U-THERE/Hello/Ping/Heartbeat/Path test
messages outside the IKEv2 window would be necessary, or at 
would simplify the protocol considerably. (And since we decided 
not to assume full connectivity, something like that message may 
be needed anyway.)

Best regards,
Pasi