Re: [IPsec] Comments on draft-ietf-ipsecme-esp-null-heuristics-01

Vishwas Manral <vishwas.ietf@gmail.com> Thu, 19 November 2009 18:42 UTC

Return-Path: <vishwas.ietf@gmail.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 6E2E93A677E for <ipsec@core3.amsl.com>; Thu, 19 Nov 2009 10:42:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.426
X-Spam-Level:
X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 1AkEpuHHdg6v for <ipsec@core3.amsl.com>; Thu, 19 Nov 2009 10:42:32 -0800 (PST)
Received: from mail-gx0-f228.google.com (mail-gx0-f228.google.com [209.85.217.228]) by core3.amsl.com (Postfix) with ESMTP id 7F7823A6405 for <ipsec@ietf.org>; Thu, 19 Nov 2009 10:42:32 -0800 (PST)
Received: by gxk28 with SMTP id 28so2312850gxk.9 for <ipsec@ietf.org>; Thu, 19 Nov 2009 10:42:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=bJPJZpo6QaBu6vCPYABhqJQWG/4pIa/qSIF7qyvp1oI=; b=MMQaC6n+mGoOsH4WSoM2GsPpj62XWAibaJNK9PuNYzaYe/5rsTEkI5NRH8tsIz8BpR +tSQ8EmEVIQ24FiCY0r1IvdJvd6HPsZeQ5m4yICXaDQp6Hv6pc3GjLnqOPvxpKtPt0so SOSe/RbIzHcMpUyma7wAEl4LbNFwp9/6Kkn78=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VZ4B+JCNXzzJ3glyY3zwV2a+P/4f6jT0ZVAIcECsl7dA0HxAQ7j+9LkJmRLuVLTPXm hDe60PW91TiH0ycHj1gDF85wqrm1FOwRH5/wpG2IYh7Og8hJQcjK9WDSkSI8+evvkLkg jY0oW1Ow/tFx1ILLaY0ZzA4dRh2uj8Qcfnr5M=
MIME-Version: 1.0
Received: by 10.150.26.42 with SMTP id 42mr675328ybz.302.1258656147177; Thu, 19 Nov 2009 10:42:27 -0800 (PST)
In-Reply-To: <4B050533.5030102@iki.fi>
References: <4B050533.5030102@iki.fi>
Date: Thu, 19 Nov 2009 10:42:27 -0800
Message-ID: <77ead0ec0911191042o68759777o81af6bc8d7fa8a6b@mail.gmail.com>
From: Vishwas Manral <vishwas.ietf@gmail.com>
To: Tero Mononen <tmo@iki.fi>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Comments on 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: Thu, 19 Nov 2009 18:42:33 -0000

Hi Tero,

Let me answer the very relevant question you have raised and got no
reply for yet. Let me first give you a short background.

We had a similar discussion on ESP-NULL versus AH and merits of a
heuristics  approach in 2007 on the SAAG list. You can have a look at
the discussion
http://www.ietf.org/mail-archive/web/saag/current/msg01933.html and
the related mails.

Tero Kivinen's point at that time too was that we can do heuristics
based approach. Also look at the archive
http://www.ietf.org/mail-archive/web/ipsec/current/msg01902.html of
the question I had raised.

>  Raises a question, why is this all needed? What is the use case?
>  Neither this, nor WESP draft can give a simple answer for the
>  question. If encrypted traffic is allowed to pass traffic
>  analyzer/intrusion detector/intrusion prevention/firewall/whatever,
>  the malicious end nodes will use encryption. If encrypted traffic
>  is dropped by intermediate, then there is an end node policy
>  issue.  Detection whether an ESP packet payload is encrypted or
>  not should already be fast on deep inspection packet matching
>  hardware.

Like mentioned in the mail assume an application that runs within an
enterprise and uses ESP-NULL only service. We could filter out all
packets for that application port at the firewall itself as we can
look deeper into the packet if we had a mechanism to know if the
packet is encrypted or not.

So if an encrypted packet came for an SA which used ESP-NULL, it would
not be processed properly and dropped like you mentioned by the
application anyway. However by knowing ESP-NULL at the edge we could
drop packets for applications from domains disallowed to send packet
in (even though the packets are replayed packets and so will actually
be treated as correct packets by the application).

This is also one reason an application may use ESP-NULL, that way
firewalls can do their work and the application is safe from being
bombarded by packets from outside the domain. The use cases of doing
the detection of ESP-NULL versus encrypted packets however are
limited.

Thanks,
Vishwas