Re: [IPsec] Avoiding Authentication Header (AH)

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Thu, 05 January 2012 16:05 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 EAB6621F8688 for <ipsec@ietfa.amsl.com>; Thu, 5 Jan 2012 08:05:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.579
X-Spam-Level:
X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 L7n-djNpMEkz for <ipsec@ietfa.amsl.com>; Thu, 5 Jan 2012 08:05:01 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5243C21F8679 for <ipsec@ietf.org>; Thu, 5 Jan 2012 08:05:01 -0800 (PST)
Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q05G4AEB024180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2012 10:04:13 -0600 (CST)
Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q05G48AF003499 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 5 Jan 2012 21:34:09 +0530
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.38]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 5 Jan 2012 21:34:08 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Yoav Nir <ynir@checkpoint.com>
Date: Thu, 05 Jan 2012 21:34:09 +0530
Thread-Topic: [IPsec] Avoiding Authentication Header (AH)
Thread-Index: AczLwVN04G0kKlviQciXtNQtpM/mAwAAESAg
Message-ID: <7C362EEF9C7896468B36C9B79200D8350D028A2D67@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> <6B16D76E-A432-497D-A9A2-DF3465449247@checkpoint.com>
In-Reply-To: <6B16D76E-A432-497D-A9A2-DF3465449247@checkpoint.com>
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>, Tero Kivinen <kivinen@iki.fi>
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: Thu, 05 Jan 2012 16:05:02 -0000

Hi Yoav,

I see some potential of using WESP in the routing protocols where it helps the end nodes in prioritizing certain control packets over the others. 

One could argue that the end nodes know that the packets are NULL encrypted and could use regular ESP as well. The problem with this is that the end nodes then need to install per SPI filter entries which is not scalable. Packets need to be punted to separate queues since Ipsec processing is often done in SW after the packets have been dequeued from the CPU queues.

This is not a completely sorted idea and I need to spend more time on this to see if it makes sense ..

Cheers, Manav

P.S.
BTW, one vendor recommends AH for OSPFv3 (despite 4522 stating that as a MAY) since it helps their implementation to prioritize OSPFv3 packets.

-----Original Message-----
From: Yoav Nir [mailto:ynir@checkpoint.com] 
Sent: Thursday, January 05, 2012 9:18 PM
To: Bhatia, Manav (Manav)
Cc: Tero Kivinen; IPsec ME WG List
Subject: Re: [IPsec] Avoiding Authentication Header (AH)

On Jan 5, 2012, at 4:37 PM, Bhatia, Manav (Manav) wrote:

> 
>> Getting WESP implemented to the boxes will require a lot of time.
>> There are still lots of boxes which do not even support IKEv2 (which 
>> is required for
>> WESP) and IKEv2 has been out for 6 years already. AH might already be
> 
> WESP can be used with manual keying the way routing protocols today use ESP and AH.

Hi Manav.

I guess it can, but ESP (and AH and presumably WESP) would be implemented at a lower layer than IKE. For some boxes that would be ESP implemented in silicon and IKE implemented in software.

So getting your own box to start doing IKEv2 is relatively straightforward - a software fix (even if it's referred to as "firmware"), while WESP would require a new box. Even in software implementations the IPsec is usually considered more "stable" than the IKE code.

The big vendors have taken years to implement IKEv2 in regular boxes (as opposed to lab curiosities). I don't see them rushing to implement WESP just to please the middlebox makers.

Yoav