Re: Issue: Should MOBIKE react to problems not known locally (#NEW)

Greg Daley <[email protected]>
Newsgroups gmane.ietf.mobike
Message-ID <[email protected]>
Hi, 

----- Original Message -----
From: Tero Kivinen <[email protected]>
Date: Tuesday, June 22, 2004 7:52 pm
Subject: Re: [Mobike] Issue: Should MOBIKE react to problems not known 
locally (#NEW)

> Greg Daley writes:
> > Hi Jari,
> > 
> > Jari Arkko wrote:
> > > 
> > > Should MOBIKE only react to problems that are known
> > > to the nodes locally? For instance, if an interface
> > > in a host goes down, or it is assigned a new address,
> > > then the node knows about this and can tell its peer.
> > > 
> > > Or should MOBIKE also deal with other problems, typically
> > > based on the symptom of not getting packets through?
> > > For instance, should MOBIKE attempt to do a failover
> > > upon seeing
> > > 
> > > - DPD failure
> > > - ICMP error
> > > - No response to the MOBIKE protocol messages
> > > - No incoming payload packets
> > 
> > I think that there's obviously an issue with
> > using a mechanism which isn't in itself secured
> > to indicate changes.
> 
> To indicate that there might be change, and we should start checks and
> perhaps a recovery. I.e. if we do not get any replies for out IKE
> packets then we should try to use other address for the other end,
> even when it have not send notification asking us to move to that
> address. The reason that address might be broken could be some router
> alogn the path which is dropping all packets. The other end cannot
> know that, thus it cannot send notifications to us, asking us to move
> to another address.
> 
> ICMP host unreachable, can also used to trigger a dead peer detection
> check for the IKE sa, just to verify whether the IP-addresses still
> work. 

Indeed.

When there are other reasons to believe that the peer is alive
though (packet exchange is actually occurring, or occurs a
short period after the ICMP message), then these
should be ignored.

It may be that the DPD callback timer is shortened temporarily,
and confirmed data exchange within the period resets it to normal
levels without sending the R-U-Theres.
  
Greg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.