Re: [IPsec] WESP - Roadmap Ahead

Stephen Kent <kent@bbn.com> Wed, 25 November 2009 14:40 UTC

Return-Path: <kent@bbn.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 A074D3A6AC5 for <ipsec@core3.amsl.com>; Wed, 25 Nov 2009 06:40:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.523
X-Spam-Level:
X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 Gsz1Wgk3Dl0G for <ipsec@core3.amsl.com>; Wed, 25 Nov 2009 06:40:11 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DF06E3A68D3 for <ipsec@ietf.org>; Wed, 25 Nov 2009 06:40:10 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.5]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NDJ2J-0007xa-Ar; Wed, 25 Nov 2009 09:40:03 -0500
Mime-Version: 1.0
Message-Id: <p06240809c732f07d5ac6@[192.168.1.5]>
In-Reply-To: <51eafbcb0911250311h5465f034q5bcfd01ad826987b@mail.gmail.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-luce nt.com> <51eafbcb0911250311h5465f034q5bcfd01ad826987b@mail.gmail.com>
Date: Wed, 25 Nov 2009 09:40:00 -0500
To: Daniel Migault <mglt.ietf@gmail.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>, Merike Kaeo <merike@doubleshotsecurity.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: Wed, 25 Nov 2009 14:40:11 -0000

At 12:11 PM +0100 11/25/09, Daniel Migault wrote:
>Hi Manav,
>
>I agree that for an already negotiated SA, the SPD lookup detects IP 
>source address spoofing. So in that case ESP detects the address 
>spoofing during the SPD check whereas AH would detect it while 
>checking the signature check.
>
>However SAD lookup is done with the longest match rule, and section 
>4.1 of RFC4301 specifies :
>       "3. Search the SAD for a match on only SPI if the receiver has
>          chosen to maintain a single SPI space for AH and ESP, and on
>
>          both SPI and protocol, otherwise."
>
>This seems to enable a ESP or AH datagram with spoofed IP addresses 
>to match the SAD and SPD.

I'm confused at this juncture.  The 4301 inbound processing algorithm 
(section 5.2 in RFC 4310) refers to SAD entries for processing 
IPsec-protected packets; the SPD inbound cache (SPD-I) is used only 
for bypass and discard traffic. So there should be no reference to 
the SPD in the sentence immediately above, right?

Also, you should remind folks that this rule applies only to 
multicast SAs. That's relevant to the OSPFv3 discussion we are 
having, but it seems inconsistent with the comment below of a 
middlebox that changes addresses, i.e., does one really expect to 
encounter a NAT on a link between two routers running OSPF?

I am not criticizing your later comments about AH vs. ESP 
applicability in mobile environments, just trying to keep the various 
arguments straight.

Steve