Re: [IPsec] Avoiding Authentication Header (AH)

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Wed, 11 January 2012 14:55 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 82FC521F8629 for <ipsec@ietfa.amsl.com>; Wed, 11 Jan 2012 06:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.581
X-Spam-Level:
X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 GhyMcVwIOmfS for <ipsec@ietfa.amsl.com>; Wed, 11 Jan 2012 06:55:55 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8C021F8616 for <ipsec@ietf.org>; Wed, 11 Jan 2012 06:55:54 -0800 (PST)
Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q0BEtoK8027646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2012 08:55:52 -0600 (CST)
Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0BEtmW3029479 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 11 Jan 2012 20:25:49 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 11 Jan 2012 20:25:49 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Tero Kivinen <kivinen@iki.fi>
Date: Wed, 11 Jan 2012 20:25:47 +0530
Thread-Topic: [IPsec] Avoiding Authentication Header (AH)
Thread-Index: AczLuyC/EgUphpP2QVSlneRcOtGfCAEtPs6w
Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A3767@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <12533D04-6B3F-490F-935B-4F1FA612C938@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB46F@INBANSXCHMBSA1.in.alcatel-lucent.com> <F1B15794-3291-4E71-BE26-A3559F408B01@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D027BB484@INBANSXCHMBSA1.in.alcatel-lucent.com> <23AFA108-5B72-4CB0-8498-6CC27FC79F96@gmail.com> <CAA1nO734gfXYJLeLU9iYxoArPZJ3Xo3MsXy0Rt9zgoTciBCZbQ@mail.gmail.com> <CAK3OfOg0Gsxxf8T66XNVLHtR1Tk9yHFDGw96tr0UkEh6x5uYpQ@mail.gmail.com> <48CB2A9F-D59C-462F-8C7A-82127A217703@gmail.com> <7C362EEF9C7896468B36C9B79200D8350D028A2AE4@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.44292.629825.7429@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350D028A2D56@INBANSXCHMBSA1.in.alcatel-lucent.com> <20229.48028.145994.197136@fireball.kivinen.iki.fi>
In-Reply-To: <20229.48028.145994.197136@fireball.kivinen.iki.fi>
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.39
Cc: IPsec ME WG List <ipsec@ietf.org>
Subject: Re: [IPsec] Avoiding Authentication Header (AH)
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: Wed, 11 Jan 2012 14:55:55 -0000

Hi Tero,

[clipped]

> And why would routing protocols need to use WESP, I would assume 
> they use ESP-NULL instead. In addition if you use manual keying 

Sigh. We've gone through this before I think on the KARP mailing list (am not sure though).

Routing protocols could "potentially" use WESP since they need to prioritize certain control protocols over the other protocol packets (like OSPF hellos and acks over other OSPF packets). Using WESP just makes deep inspection easy. One could argue that routers know that incoming ESP-NULL packets are not "encrypted" since they are the end points, however, that means that routers need to install filter rules per SPI values, which is not scalable. So, while ESP-NULL *would* work, WESP just makes it a tad easier.

Cheers, Manav