Re: [IPsec] WESP - Roadmap Ahead

Tero Kivinen <kivinen@iki.fi> Wed, 25 November 2009 14:00 UTC

Return-Path: <kivinen@iki.fi>
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 1837E28C24A for <ipsec@core3.amsl.com>; Wed, 25 Nov 2009 06:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level:
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 2OYkMoELX8+S for <ipsec@core3.amsl.com>; Wed, 25 Nov 2009 06:00:23 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id E0C5F28C241 for <ipsec@ietf.org>; Wed, 25 Nov 2009 06:00:22 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id nAPDxxZm015138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 15:59:59 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id nAPDxwkk015157; Wed, 25 Nov 2009 15:59:58 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <19213.14430.479067.369482@fireball.kivinen.iki.fi>
Date: Wed, 25 Nov 2009 15:59:58 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Daniel Migault <mglt.ietf@gmail.com>
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-lucent.com> <51eafbcb0911250311h5465f034q5bcfd01ad826987b@mail.gmail.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 6 min
X-Total-Time: 6 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Bhatia, Manav \(Manav\)" <manav.bhatia@alcatel-lucent.com>, Stephen Kent <kent@bbn.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:00:24 -0000

Daniel Migault writes:
> I agree that for an already negotiated SA, the SPD lookup detects IP source
> address spoofing.

Not quite true, as you point out yourself. 

> 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.

Yes, and this is very important to get NAT-T and MOBIKE to work as
there the source address might change (either because NAT box rebooted
or otherwise forgot the mapping, and gave new IP address for the IPsec
connection, or because host moved around using MOBIKE).

> If we consider a middleboxe that changes the IP address,
> then using ESP will not detect the IP address spoof. On the other hand using
> AH the spoofing attack will be detected.

Yes. 

> Thus I would not consider AH as ESP_NULL equivalent, and thus feel AH should
> not be removed. Nevertheless, AH has a major drawback which is NAT. For now
> we can only hope IPv6 will bring an end-to-end connectivity. At least AH
> would take considerable advantage of this statement!

To reiterate for others, the major drawback in AH is that it actually
detects changes in the source / destination IP addresses, thus it
breaks if there is evil attackers (called NATs) in the middle who try
to modify source and/or destination addresses...

> IMO, rather then removing AH I would see if future use of the Internet make
> it "historical" or not. For now it might be too soon to take such a
> decision. Furthermore, AH does not cause "problems" with other protocols,
> since they can chose not to use it.

I agree.
-- 
kivinen@iki.fi