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

[email protected] wrote:
> 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.

okay.

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

agree.

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

this is where my concern is.

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

right. my concern is only about MOBIKE going off and making the
decision by itself.

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

ofcourse not.

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

until this I agree, but not with the last paragraph. if the
mobility/multi-homing module is not able to verify IP connectivity
how will the MOBIKE module do it?

Vijay