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
- [IPsec] Comments on draft-ietf-ipsecme-esp-null-h… Tero Mononen
- Re: [IPsec] Comments on draft-ietf-ipsecme-esp-nu… Vishwas Manral
- [IPsec] Comments on draft-ietf-ipsecme-esp-null-h… Tero Kivinen