IETF Logo Mail Archive

Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 13 October 2009 19:13 UTC

Return-Path: <Nicolas.Williams@sun.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D91563A67B6 for <ipsec@core3.amsl.com>; Tue, 13 Oct 2009 12:13:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.821
X-Spam-Level:
X-Spam-Status: No, score=-4.821 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qznG44haIKek for <ipsec@core3.amsl.com>; Tue, 13 Oct 2009 12:13:49 -0700 (PDT)
Received: from sca-ea-mail-3.sun.com (sca-ea-mail-3.Sun.COM [192.18.43.21]) by core3.amsl.com (Postfix) with ESMTP id 1D8D73A67F8 for <ipsec@ietf.org>; Tue, 13 Oct 2009 12:13:49 -0700 (PDT)
Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n9DJDlRO014184 for <ipsec@ietf.org>; Tue, 13 Oct 2009 19:13:47 GMT
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n9DJDkWd016579 for <ipsec@ietf.org>; Tue, 13 Oct 2009 13:13:46 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n9DIswgt008887; Tue, 13 Oct 2009 13:54:58 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n9DIswkq008886; Tue, 13 Oct 2009 13:54:58 -0500 (CDT)
X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f
Date: Tue, 13 Oct 2009 13:54:58 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Yaron Sheffer <yaronf@checkpoint.com>
Message-ID: <20091013185457.GD8079@Sun.COM>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC80190AD328329@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC801BD9338E802@il-ex01.ad.checkpoint.com> <20091013183424.GH887@Sun.COM>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20091013183424.GH887@Sun.COM>
User-Agent: Mutt/1.5.7i
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] WG last call: draft-ietf-ipsecme-esp-null-heuristics-01
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2009 19:13:49 -0000

On Tue, Oct 13, 2009 at 01:34:24PM -0500, Nicolas Williams wrote:
> Done.

One more comment:

 - State keeping by intermediate nodes is described as an optimization,
   however: a) I'm not sure that that necessarily follows, since state
   keeping and cache index lookups are not free, and anyways, b) in some
   cases, particularly where the next header is TCP or UDP, state
   keeping appears to be a requirement for establishing confidence in
   heuristics results.

   (b) is the key issue.  Some advice on state cache sizing may be
   useful.  E.g., if an entry is dropped out of the cache due to cache
   pressure, how costly will that be in terms of additional inspection
   effort for future packets for that flow, and in terms of resulting
   future cache pressure?

Nico
--

v2.23.0 | Report a Bug | By Email