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

From: <[email-masked]>
Date: Mon, 16 Aug 2004 14:24:34 +0300

Hi Vijay,

IKEv2 already triggers an informational exchange if 
there's no incoming ESP traffic for some time (how long
you wait is not specified).

We're not changing that part, I hope. The main issue
for MOBIKE is what to do if we don't receive a reply 
to the informational request (even after some number 
of retransmissions).

If we don't do anything, the SAs will be closed. In my 
opinion, that's not acceptable. The lack of replies 
should trigger changing to some other addresses (if a 
working path is available).

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.

Best regards,
Pasi

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Friday, August 13, 2004 11:40 PM
> To: Tero Kivinen
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Subject: Re: [Mobike] New issue 16: No packets from other end?
> 
> what is "lack of ESP packets"? for how long do you wait?
> isnt this dependent on the application?
> 
> do you want to trigger an IKEv2 informational request everytime
> the application "pauses"?
> 
> MOBIKE shouldnt decide. I agree with Francis, that the "lack
> of ESP packets" should be handled elsewhere in the stack (and
> not in MOBIKE).
> 
> Vijay
> 
> Tero Kivinen wrote:
> > [email-masked] writes:
> > 
> >>Do you mean that lack of ESP packets would trigger an IKEv2
> >>informational request and lack of response to that would trigger 
> >>MOBIKE to change paths, or that lack of ESP packets
> >>would directly trigger MOBIKE to change paths?
> > 
> > 
> > The first. I.e. we need to still do the dead peer detection 
> > to verify if it just so that the other end is simply silent. 
_______________________________________________
Mobike mailing list
[email-masked]
https://www.machshav.com/mailman/listinfo.cgi/mobike

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 16 Aug 2004 16:30:30 -0700

hi Pasi,

> you wait is not specified).

you are right. I mixed it up.

> working path is available).

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.

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

Vijay

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 16 Aug 2004 20:20:20 -0700

> update should be sent. this is the model I had in my mind.
But we don't want to restrict MOBIKE to do it this way. This means we
should keep MOBIKE flexible enough to use any external trigger it wants. 

> Multi6, new address configuration, default router change, etc...
Agreed.

-mohan