IETF Logo Mail Archive

Re: [IPsec] WESP - Roadmap Ahead

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Fri, 13 November 2009 01:18 UTC

Return-Path: <manav.bhatia@alcatel-lucent.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 5D2D928C140 for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 17:18:09 -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 KQU3CulA6dyR for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 17:18:08 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by core3.amsl.com (Postfix) with ESMTP id 7AD2C28C0FC for <ipsec@ietf.org>; Thu, 12 Nov 2009 17:18:08 -0800 (PST)
Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id nAD1IJLa011386; Thu, 12 Nov 2009 19:18:19 -0600 (CST)
Received: from mail.apac.alcatel-lucent.com (h202-65-2-130.alcatel.com [202.65.2.130]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAD1IHkQ025163; Thu, 12 Nov 2009 19:18:18 -0600 (CST)
Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAD1Gkid015393; Fri, 13 Nov 2009 09:16:47 +0800
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Fri, 13 Nov 2009 06:48:15 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Daniel Migault <mglt.ietf@gmail.com>
Date: Fri, 13 Nov 2009 06:48:13 +0530
Thread-Topic: [IPsec] WESP - Roadmap Ahead
Thread-Index: AcpjWzY1tlG9w3GDRPO2LkSZ8gmclAAoTEfQ
Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com> <p06240800c720d4538dd2@133.93.112.234> <p0624080ac7212e67c860@133.93.16.246> <8CCEE8E4-9AC4-46FB-93E4-FE61E0135EB7@doubleshotsecurity.com> <p0624080ec7213743dc05@133.93.16.246> <dc8fd0140911112030y46aa24f9hf3715d57446e96c0@mail.gmail.com> <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.com>
In-Reply-To: <51eafbcb0911112144u6e25b826w4ec8110d1f73e652@mail.gmail.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 172.22.12.28
X-Scanned-By: MIMEDefang 2.64 on 202.65.2.130
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Stephen Kent <kent@bbn.com>, Kaeo <merike@doubleshotsecurity.com>, Merike
Subject: Re: [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: Fri, 13 Nov 2009 01:18:09 -0000

Daniel,

> AH is a security feature we need to keep for header authentication
 
Am really not sure about the value that AH adds even in case of header authentication.
 
So what fields does AH protect:
 
Version, Payload length, Next Header, Source IP and dest IP
 
The only field worth modifying is the source and the dest IP. Now note that an IPSec SA is established between a pair of source IP and dest IP. Upon receipt of a packet containing an AH header, the receiver determines the appropriate (unidirectional) SA, based on the dest IP, security protocol (AH), and the SPI (it could also include the source IP). If the attacker modifies (or spoofs) either of the source or the dest IP, the SA lookup will fail and the receiver will regardless discard the packet. So what are we gaining by AH "header authentication"?

AH can only add value over ESP-NULL if there are instances where despite address spoofing we erroneously process the IPSec packet. I don't see that happening, so is this really an issue?

Cheers, Manav
________________________________

	From: Daniel Migault [mailto:mglt.ietf@gmail.com] 
	Sent: Thursday, November 12, 2009 11.14 AM
	To: Jack Kohn
	Cc: Stephen Kent; ipsec@ietf.org; Bhatia, Manav (Manav); Merike Kaeo
	Subject: Re: [IPsec] WESP - Roadmap Ahead
	
	On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn <kohn.jack@gmail.com> wrote:
		>
		> Whoops, I was wrong. I looked at 4552 and they do cite ESP-NULL (although
		> they never refer to it that way) as a MUST, and AH as a MAY.
		
		Ok, so can we work on deprecating AH? This way new standards defined
		in other WGs dont have to provide support for AH.
	

	AH is a security feature we need to keep for header authentication. Other WG may chose not to deal with AH and only consider ESP. I don't see what's wrong with that?
	
	 Regards
	
	Daniel
	-- 
	Daniel Migault
	Orange Labs -- Security
	+33 6 70 72 69 58

v2.23.0 | Report a Bug | By Email