[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: issues with IKE that need resolution
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 of
receiving IPsec traffic? If IPsec Client keeps silent - tt make take sender hours
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.
>
> On Tue, 15 Sep 1998 15:37:35 EDT you wrote
> > Question to IPsec implementors:
> >
> > What is the "proper" behaviour of the IPsec implementation upon receiving an
> > IPsec-transformed packet for which there is no IPsec SA, but there is an SPD
> > entry and/or IKE SA for the IP address of the sender (or the associated IP
> > Range or IP Subnet)? I couldn't find anything in the standards on this.
> >
> > - Should the packet be discarded?
> > - Should it trigger MM (or QM) initiation? - may be good for some recovery
> > cases , but bad for denial-of-service or other attacks.
> > - Should the sending end be notified?
> >
> > I think this is an important interoperability issue.
> > .
> > --
> > Bronislav Kavsan
> > IRE Secure Solutions, Inc.
> > 100 Conifer Hill Drive Suite 513
> > Danvers, MA 01923
> > voice: 978-739-2384
> > http://www.ire.com
--
Bronislav Kavsan
IRE Secure Solutions, Inc.
100 Conifer Hill Drive Suite 513
Danvers, MA 01923
voice: 978-739-2384
http://www.ire.com
Follow-Ups:
References: