Re: [IPsec] Avoiding Authentication Header (AH) (was Moving Authentication Header (AH) to Historic)

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Mon, 02 January 2012 01:45 UTC

Return-Path: <manav.bhatia@alcatel-lucent.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9649311E8096 for <ipsec@ietfa.amsl.com>; Sun, 1 Jan 2012 17:45:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.566
X-Spam-Level:
X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgCaquNn6IrQ for <ipsec@ietfa.amsl.com>; Sun, 1 Jan 2012 17:45:07 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 91FAB11E808C for <ipsec@ietf.org>; Sun, 1 Jan 2012 17:45:02 -0800 (PST)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q021iwcq022411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 1 Jan 2012 19:45:01 -0600 (CST)
Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q021ivwW018305 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 2 Jan 2012 07:14:57 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Mon, 2 Jan 2012 07:14:57 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>, IPsecme WG <ipsec@ietf.org>
Date: Mon, 02 Jan 2012 07:14:58 +0530
Thread-Topic: [IPsec] Avoiding Authentication Header (AH) (was Moving Authentication Header (AH) to Historic)
Thread-Index: AczI4xMatJFKFbHGQRe9i6xoeGZt+QADIObw
Message-ID: <7C362EEF9C7896468B36C9B79200D8350D027BB27C@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <7C362EEF9C7896468B36C9B79200D8350D027BB14E@INBANSXCHMBSA1.in.alcatel-lucent.com> <4EFCBE95.8040408@gmail.com> <8521357F-B4E3-4D14-9D1E-996713C2F027@checkpoint.com> <CAA1nO71n5QHJ5GzHe6qVhVNGcvK-vkOgwEi4Y2i81vXmzON-xg@mail.gmail.com> <C72CBD9FE3CA604887B1B3F1D145D05E0122FEF3@szxeml528-mbx.china.huawei.com> <4EFF61B5.2030604@gmail.com> <7C4DFCE962635144B8FAE8CA11D0BF1E05A5CC9B26@MX14A.corp.emc.com> <6E38F4E9-8335-43F9-BA7A-9BB1E209E987@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB274@INBANSXCHMBSA1.in.alcatel-lucent.com> <24EFE65B-86E0-4473-AF48-98B0C50F7041@vpnc.org> <7C362EEF9C7896468B36C9B79200D8350D027BB27B@INBANSXCHMBSA1.in.alcatel-lucent.com> <20536.1325463074@marajade.sandelman.ca>
In-Reply-To: <20536.1325463074@marajade.sandelman.ca>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
Subject: Re: [IPsec] Avoiding Authentication Header (AH) (was Moving Authentication Header (AH) to Historic)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 02 Jan 2012 01:45:07 -0000

Hi Michael,

> I do not agree that WESP provides the service desired. 
> WESP requires cooperation (and therefore upgrade) of the end points.
> 
> What AH does that ESP NULL does not, is that it guarantees that the things after the AH header are in fact in the clear.  One can in fact, ignore the AH > header completely (even on the receiving node!), and still process the entire packet.  Not so with ESP!  

You have this information with WESP as well. You definitely know that the packet is sent in clear with WESP. Just as you can use ESP with manual keying, you can use WESP too.

Obviously the end nodes need to implement WESP, but then they also need to implement AH if that's what they want to use.

Cheers, Manav