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

Tero Kivinen <kivinen@iki.fi> Wed, 03 March 2010 11:46 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFAB3A8D93; Wed, 3 Mar 2010 03:46:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 DkCZh9mi-pIw; Wed, 3 Mar 2010 03:46:04 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id AB5413A8D92; Wed, 3 Mar 2010 03:46:00 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o23BjteP002364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2010 13:45:55 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o23Bjs2N019086; Wed, 3 Mar 2010 13:45:54 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19342.19442.798794.603092@fireball.kivinen.iki.fi>
Date: Wed, 3 Mar 2010 13:45:54 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Rob Austein <sra@hactrn.net>
In-Reply-To: <20100302194822.EA82A22807@thrintun.hactrn.net>
References: <20100302194822.EA82A22807@thrintun.hactrn.net>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 13 min
X-Total-Time: 12 min
Cc: ipsecme-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-ipsecme-esp-null-heuristics@tools.ietf.org, secdir@ietf.org
Subject: [secdir] Review of draft-ietf-ipsecme-esp-null-heuristics-06.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2010 11:46:05 -0000

Rob Austein writes:
> The Security Considerations section is OK as far as it goes, but could
> benefit from some additional text or references to other parts of the
> document.  Specifically:
> 
> - 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?

> - 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.

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.

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. If policy is allow those through, then attacker
can use encrypted ESP to bypass the deep inspection device anyways,
which means the other end should have its own ways of inspecting the
packets anyways, as middle box cannot inspect them.
-- 
kivinen@iki.fi