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

From: <[email-masked]>
Date: Thu, 12 Aug 2004 16:01:12 +0300

I've created a new issue in the issue list:

   "Can the protocol recover from situations where the only 
   sign of problems is lack of packets from the other end?"

   (http://www.vpnc.org/ietf-mobike/issues.html)

Many people at the WG meeting expressed opinions that this 
should be handled somehow (in addition to handling e.g. 
link-down triggers from layer 2, or something similar).

So far, I do not remember anyone saying that the protocol
does not need to handle this situation. But comments
are welcome.

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

---

From: Francis Dupont <[email-masked]>
Date: Thu, 12 Aug 2004 16:43:23 +0200

In your previous mail you wrote:

   
   
=> note that this issue applies only if we decide that the protocol
should handle everything by itself, i.e., there is no generic control
of the mobile/multi-homed environment (what should be likely the
case for a not-dedicated-to-IPsec box).

Regards

[email-masked]

PS: the action related to issue 7 is done. IMHO we can stop here the
possible interactions between Mobike and transport mode but we'll
talk about that when my draft will be available in repositories, i.e.,
tomorrow or next week?
PPS: IMHO it is not a good idea to put everything into mobike tools:
we should not re-invent all the movement detection and multi-homing
handling. For example SCTP tried and even failed to specify a complete
peer dead detection. We should only specify what kind of events or
conditions should be reported to the generic control ("lack of packets
from the other end" is a good example) and what kind of actions should
be proposed to the generic control (tear-down, update, addition of a
new peer address, etc), but not the control itself!
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 12 Aug 2004 20:36:12 -0700

Are we assuming that triggers for these are going to come from outside of mobike or
mobike itself will detect such things ?

-mohan

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Thursday, August 12, 2004 6:01 AM
Subject: [Mobike] New issue 16: No packets from other end?

Best regards,
Pasi

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 Aug 2004 08:38:17 +0300

Triggering something known locally (interface down etc)
needs an external trigger. Lack of packets could be triggered
either by external triggers or MOBIKE/IKEv2 itself. I
personally prefer the latter, because there would be
less reliance on APIs and other protocol layers.

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 Aug 2004 11:25:39 +0300

> less reliance on APIs and other protocol layers.

Modify that MOBIKE/IKEv2 to include also IPsec then I agree... The
most common way to get the information is to notice that there is no
ESP packets coming in....
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 Aug 2004 11:21:28 +0200

=> IMHO this is a dangerous path to follow because it shall give
a monster for the MOBIKE/IKEv2 tool. I understand you are more interested
by MOBIKE SGs than by more generic mobile/multi-homed boxes where
MOBIKE is only a small part of the whole thing but please don't
specialize MOBIKE as some are always trying to specialize IPsec to VPNs.

Regards

---

From: Jari Arkko <[email-masked]>
Date: Fri, 13 Aug 2004 13:15:48 +0300

> specialize MOBIKE as some are always trying to specialize IPsec to VPNs.

This is a good point.

One way to look at this is to talk about what observations
must be supported by a MOBIKE implementation and what
observations are optional. For instance, local knowledge
could still be allowed even if MOBIKE/IKEv2/IPsec was
mandated to deliver observations about problems. Or are
you suggesting that local knowledge would be mandatory
and 'lack of packets' optional?

--Jari

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 13 Aug 2004 13:16:42 +0300

> specialize MOBIKE as some are always trying to specialize IPsec to VPNs.

The MOBIKE/IKEv2 will be used along with IPsec, I do not even consider
and option that we would create MOBIKE to be used without IPsec. Most
of the IPsec implementations already check out the flow if ESP
packets, and can start actions if they are missing for too long (for
example IKEv1 you used that for crash recovery and dead peer
detection).

Why we cannot allow that same mechanism to be used in the MOBIKE? I
don't think we want to mandate that thing, but we do want to say that
MOBIKE implementations are allowed to consider the connection to be up
if there is ESP packets coming from the other end.
-- 
[email-masked]
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 Aug 2004 13:14:14 +0200

This is a good point.

=> I don't know what you call "local knowledge".

=> MOBIKE should not specify anything about IPsec itself,
i.e., it should be a hint in the design document only.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 13 Aug 2004 13:18:45 +0200

=> I believe you missed my point: I have no concern about the mechanism
itself but I have a concern about where it is implemented and as a side
effect how it is specified.

Regards

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 15 Aug 2004 17:18:03 -0700

> less reliance on APIs and other protocol layers.
There are already other working groups like DNA, multi6 etc. that would
come up with mechanisms to detect link changes, path changes etc. MOBIKE
could just use that. But your concern is how will MOBIKE interface with other
modules to learn the information ? i.e., if there is no mechanism to learn about
link up/link down in the system or MIP4/MIP6 is not implemented in the node,
what should MOBIKE do ? Also, what does it mean if there are other mechanisms,
should MOBIKE use that or invent something new or take into consideration both ?

It would  be simpler if we just document what sort of triggers ( a few examples)
are needed for MOBIKE to work. Whether it is implemented as part of MOBIKE or
outside of MOBIKE is an implementation detail.  I guess this is what Francis is getting
at. If so, i agree.

-mohan