Re: issues with IKE that need resolution

Bronislav Kavsan <bkavsan@ire-ma.com> Tue, 15 September 1998 19:29 UTC

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11943 for ipsec-outgoing; Tue, 15 Sep 1998 15:29:56 -0400 (EDT)
Message-ID: <35FEC1FF.633C5CFF@ire-ma.com>
Date: Tue, 15 Sep 1998 15:37:35 -0400
From: Bronislav Kavsan <bkavsan@ire-ma.com>
X-Mailer: Mozilla 4.03 [en] (WinNT; U)
MIME-Version: 1.0
To: Daniel Harkins <dharkins@cisco.com>
CC: ipsec@tis.com
Subject: Re: issues with IKE that need resolution
References: <199809111748.KAA09458@dharkins-ss20.cisco.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: ipsec@tis.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

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