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

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 protected]]
> Sent: Friday, August 13, 2004 11:40 PM
> To: Tero Kivinen
> Cc: Eronen Pasi (Nokia-NRC/Helsinki); [email protected]
> 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 protected] 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.