Re: issues with IKE that need resolution

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

Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id PAA11973 for ipsec-outgoing; Tue, 15 Sep 1998 15:39:55 -0400 (EDT)
Message-Id: <199809151956.MAA12801@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 15:37:35 EDT." <35FEC1FF.633C5CFF@ire-ma.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12799.905889415.1@cisco.com>
Date: Tue, 15 Sep 1998 12:56:55 -0700
From: Daniel Harkins <dharkins@cisco.com>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk

  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