[IPsec] WESP - Roadmap Ahead

Tero Kivinen <kivinen@iki.fi> Sun, 15 November 2009 15:46 UTC

Return-Path: <kivinen@iki.fi>
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 87FCF3A67AA for <ipsec@core3.amsl.com>; Sun, 15 Nov 2009 07:46:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.53
X-Spam-Level:
X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 wrBuXq3UsXPG for <ipsec@core3.amsl.com>; Sun, 15 Nov 2009 07:46:02 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 540783A68D7 for <ipsec@ietf.org>; Sun, 15 Nov 2009 07:46:01 -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 nAFFkRs9014891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Nov 2009 17:46:27 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAFFkQfN016576; Sun, 15 Nov 2009 17:46:26 +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="unknown"
Content-Transfer-Encoding: quoted-printable
Message-ID: <19200.8786.266973.313959@fireball.kivinen.iki.fi>
Date: Sun, 15 Nov 2009 17:46:26 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Jack Kohn <kohn.jack@gmail.com>
In-Reply-To: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com>
References: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 12 min
X-Total-Time: 15 min
Cc: ipsec@ietf.org
Subject: [IPsec] WESP - Roadmap Ahead
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: Sun, 15 Nov 2009 15:46:03 -0000

Jack Kohn writes:
> From operational perspective if we are supporting both v4 and v6 (and we
> will) then having different protocols ESP and AH is and will be a
> nightmare.  Common denominator is ESP-Null. However, there were issues with
> ESP-Null as it couldnt be deep inspected which has now been solved with
> WESP.

ESP-NULL and AH will still have different properties. AH will also
protect data which is not protected by the ESP-NULL, i.e. IP-header
including IP-addresses (unless ESP-NULL is used with tunnel mode). 

> In short, the argument that "Oh, but we can inspect AH packets" is not
> relevant anymore.

I do not think it was never really relevant... AH was not used because
it offers ability to inspect packets, it was used when encryption was
not necessarely and where protection of the IP header was needed. 

> Given this, should we still have AH as a MAY for IPSEC - Cant we deprecate
> it?

I do not see any reason why it should be deprecated. It is already MAY
which means it does not need to be implemented unless your environment
or use scenario needs it. I was earlier in favor of changing it to
MAY, but I do not think we need to move it further than that. 

> WESP is ESP++, and it offers everthing that ESP offers plus more. What is
> our stance for ESP moving forward?

I am very sceptical for the WESP getting lots of implementations
quickly, so I do not really consider WESP as competitor for ESP. Also
I do not see any reason to wasting bytes for extra WESP header for
encrypted traffic, so I assume WESP will be used (if it will be used)
for ESP-NULL traffic not for encrypted traffic. 

> Also, I see that a lot of work done in other WGs is still using ESP
> (primarily for data integrity). Shouldn’t they be moving to WESP, as WESP
> offers more flexibility?

It will take several years before implementations start to implement
WESP, and even more years before hardware chips support WESP. Most of
the IPsec users are still using IKEv1, even when we published IKEv2
2005, i.e. 4 years ago. And IKEv2 draft was finished and publication
was requested at end of 2003.

So stable draft which could be used to implement IKEv2 was ready 6
years ago, and while there are several implementations out, people are
still using IKEv1. Also before WESP can be used people would first
need to move to IKEv2 anyways... 
-- 
kivinen@iki.fi