Re: issues with IKE that need resolution

Daniel Harkins <dharkins@cisco.com> Tue, 15 September 1998 20:08 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id QAA12100 for ipsec-outgoing; Tue, 15 Sep 1998 16:08:56 -0400 (EDT)
Message-Id: <199809152026.NAA14560@chip.cisco.com>
To: Bronislav Kavsan <bkavsan@ire-ma.com>
cc: ipsec@tis.com
Subject: Re: issues with IKE that need resolution
In-reply-to: Your message of "Tue, 15 Sep 1998 16:08:21 EDT." <35FEC935.DF4AB143@ire-ma.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14558.905891199.1@cisco.com>
Date: Tue, 15 Sep 1998 13:26:40 -0700
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

  There is no recovery logic in IPSec, I guess. This sounds like an
IPSecond issue (and is also not really IKE-specific).

  Dan.

On Tue, 15 Sep 1998 16:08:21 EDT you wrote
> Dan,
> 
> Thanks for pointing out this statement in the standard, but.....what will be 
>the
> connection recovery logic for an IPsec Client, which rebooted in the middle o
>f
> receiving IPsec traffic? If IPsec Client keeps silent - tt make take sender h
>ours
> before figuring out what happened.
> 
> Daniel Harkins wrote:
> 
> >   Slava,
> >
> >   Section 5.2.1 of draft-ietf-ipsec-arch-sec-07.txt states:
> >
> >       Use the packet's destination address (outer IP header), IPsec
> >       protocol, and SPI to look up the SA in the SAD.  If the SA
> >       lookup fails, drop the packet and log/report the error.
> >
> >   Dan.