IETF Logo Mail Archive

Re: [IPsec] WESP - Roadmap Ahead

Richard Graveman <rfgraveman@gmail.com> Fri, 13 November 2009 01:36 UTC

Return-Path: <rfgraveman@gmail.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 3929F3A691A for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 17:36:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 0FDheKm9hHXb for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 17:36:58 -0800 (PST)
Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id 2DBF93A67F0 for <ipsec@ietf.org>; Thu, 12 Nov 2009 17:36:58 -0800 (PST)
Received: by iwn16 with SMTP id 16so2331322iwn.29 for <ipsec@ietf.org>; Thu, 12 Nov 2009 17:37:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ludoHXDB3xdVB3vtEYQLHuvA0l2rKrKzDR4At2ELP0E=; b=RtelFkzpLZI78nSjdX5E+zr+DeHNfwmSfIbF0etoS7bGZNzTS/k957B0kgaE66Lc9l QQkQkaBOlnA8Cm5NNnLgWh/LDgA6HcQx1gEk+FM7Mlx897fRbjYwRT5ygLpNYMdkx5++ w0dBGvvYmcarqpnyUNZuscXpwUKqx/buOli5s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CxfKZ2xwu/ZK1nJRw1eDNpDVQYAQAXbb30hFM/L/Lkr8Sozb9iydFygRzHyxtMK8xT Jgkus+JMN3aI3GZ9/qndeg1h2BUQ8bFqOPBDyMNAkz9jrp5VV98AISmx+3y8LcHdQsJY Kaxs0U9/DNUMNil4a/bXoA7c8g+izL5gSUlvQ=
MIME-Version: 1.0
Received: by 10.231.26.131 with SMTP id e3mr3299806ibc.0.1258076245111; Thu, 12 Nov 2009 17:37:25 -0800 (PST)
In-Reply-To: <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> <7C362EEF9C7896468B36C9B79200D8350AB2C85E06@INBANSXCHMBSA1.in.alcatel-lucent.com>
Date: Thu, 12 Nov 2009 20:37:25 -0500
Message-ID: <45c8c21a0911121737v1659cc01vd716ab401023af1e@mail.gmail.com>
From: Richard Graveman <rfgraveman@gmail.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, Merike@core3.amsl.com, Kaeo <merike@doubleshotsecurity.com>, Stephen Kent <kent@bbn.com>, Daniel Migault <mglt.ietf@gmail.com>
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:36:59 -0000

I think this argument implicitly assumes unicast.

Rich Graveman

On Thu, Nov 12, 2009 at 8:18 PM, Bhatia, Manav (Manav)
<manav.bhatia@alcatel-lucent.com> wrote:
> 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
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

v2.23.0 | Report a Bug | By Email