Re: [IPsec] WESP - Roadmap Ahead

"Bhatia, Manav (Manav)" <> Fri, 13 November 2009 01:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D2D928C140 for <>; Thu, 12 Nov 2009 17:18:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.426
X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KQU3CulA6dyR for <>; Thu, 12 Nov 2009 17:18:08 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7AD2C28C0FC for <>; Thu, 12 Nov 2009 17:18:08 -0800 (PST)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id nAD1IJLa011386; Thu, 12 Nov 2009 19:18:19 -0600 (CST)
Received: from ( []) by (8.13.8/emsr) with ESMTP id nAD1IHkQ025163; Thu, 12 Nov 2009 19:18:18 -0600 (CST)
Received: from ( []) by (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAD1Gkid015393; Fri, 13 Nov 2009 09:16:47 +0800
Received: from ([]) by ([]) with mapi; Fri, 13 Nov 2009 06:48:15 +0530
From: "Bhatia, Manav (Manav)" <>
To: Daniel Migault <>
Date: Fri, 13 Nov 2009 06:48:13 +0530
Thread-Topic: [IPsec] WESP - Roadmap Ahead
Thread-Index: AcpjWzY1tlG9w3GDRPO2LkSZ8gmclAAoTEfQ
Message-ID: <>
References: <> <p06240800c720d4538dd2@> <p0624080ac7212e67c860@> <> <p0624080ec7213743dc05@> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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
X-Scanned-By: MIMEDefang 2.64 on
Cc: "" <>, Stephen Kent <>, Kaeo <>, Merike
Subject: Re: [IPsec] WESP - Roadmap Ahead
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 13 Nov 2009 01:18:09 -0000


> 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 [] 
	Sent: Thursday, November 12, 2009 11.14 AM
	To: Jack Kohn
	Cc: Stephen Kent;; Bhatia, Manav (Manav); Merike Kaeo
	Subject: Re: [IPsec] WESP - Roadmap Ahead
	On Thu, Nov 12, 2009 at 5:30 AM, Jack Kohn <>; 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?
	Daniel Migault
	Orange Labs -- Security
	+33 6 70 72 69 58