Re: [secdir] Review of draft-ietf-ipsecme-esp-null-heuristics-06.txt

Dan McDonald <> Wed, 03 March 2010 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69FED28C117; Wed, 3 Mar 2010 07:42:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LJeCwAf628aO; Wed, 3 Mar 2010 07:42:25 -0800 (PST)
Received: from (brmea-mail-2.Sun.COM []) by (Postfix) with ESMTP id 79ED83A8ABD; Wed, 3 Mar 2010 07:42:24 -0800 (PST)
Received: from ([]) by (8.13.6+Sun/8.12.9) with ESMTP id o23FgPlr004119; Wed, 3 Mar 2010 15:42:25 GMT
Received: from kebe.East.Sun.COM (kebe.East.Sun.COM []) by (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id o23FgOtV007783; Wed, 3 Mar 2010 10:42:24 -0500 (EST)
Received: from kebe.East.Sun.COM (localhost []) by kebe.East.Sun.COM (8.14.4+Sun/8.14.4) with ESMTP id o23FT9b7003774; Wed, 3 Mar 2010 10:29:09 -0500 (EST)
Received: (from danmcd@localhost) by kebe.East.Sun.COM (8.14.4+Sun/8.14.4/Submit) id o23FT8up003773; Wed, 3 Mar 2010 10:29:08 -0500 (EST)
X-Authentication-Warning: kebe.East.Sun.COM: danmcd set sender to using -f
Date: Wed, 3 Mar 2010 10:29:08 -0500
From: Dan McDonald <>
To: Tero Kivinen <>
Message-ID: <20100303152908.GC23551@kebe.East.Sun.COM>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Organization: Sun Microsystems, Inc. - Solaris Networking & Security
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Mailman-Approved-At: Wed, 03 Mar 2010 08:38:38 -0800
Subject: Re: [secdir] Review of draft-ietf-ipsecme-esp-null-heuristics-06.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Mar 2010 15:42:26 -0000

On Wed, Mar 03, 2010 at 01:45:54PM +0200, Tero Kivinen wrote:
> > - The discussion of failure modes for the heuristics is in section 3,
> >   with no reference from the Security Considerations section.
> Do you have any concrete proposal what text to add to security
> considerations section?

Tero -- I will add some of your text below to both Section 3 and the Security

> > - The discussion of failure modes for the heuristics in section 3 is
> >   also incomplete: while it (correctly, I think) concludes that
> >   misclassifying traffic as ESP-NULL is no worse than a DoS attack
> >   which an attacker could have launched anyway, it does not discuss
> >   the other failure mode: what happens if a stream is misclassified as
> >   non-NULL ESP, thus (depending on policy) allowing it through without
> >   inspection, or dropping it on the floor?
> It does say that valid ESP-NULL stream cannot be misclassified as
> non-ESP-NULL stream. The only way for valid ESP-NULL stream to be
> classified as non-ESP-NULL is that the packet does not look valid
> ESP-NULL packet (i.e. for example has garbage in the ESP padding), but
> then it is not valid ESP-NULL packet anymore.

Actually, it's possible that using an authentication algorithm of which the
inspector is not aware can cause ESP-NULL to be misclassified.  Other than
that, we catch everything else.

> I.e. valid EPS-NULL packets cannot be misclassified, but of course
> attacker can easily send packets which cause those packets to be
> misclassified as encrypted ESP, but on the other hand attacker can
> most likely also use encrypted ESP instead (as is listed in the
> security considerations section) if encrypted ESP packets are to be
> allowed to that host.

Rob -- are you also worried about flow-poisoning?  If an attacker manages (by
chance?) to trick an inspecting node into considering a flow encrypted, and
then the inspecting node *caches* that flow as poison (a bad implementation
choice, to be sure, but possible given how much crap is out there), then
legitimate ESP-NULL packets could be dropped.

> All of those depends very much about what kind of the policy is used
> in the intermediate devices. If the policy says drop all packets which
> cannot be inspected, then attacker does not gain anything by getting
> flow misclassified.

The attacker gains denial-of-service, which may be all he/she wants.