Re: [IPsec] WESP - Roadmap Ahead

"Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com> Fri, 13 November 2009 04:42 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 A071D3A6A38 for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 20:42:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level:
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=0.156, 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 pXe2xhhbhfBW for <ipsec@core3.amsl.com>; Thu, 12 Nov 2009 20:42:34 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by core3.amsl.com (Postfix) with ESMTP id B76333A676A for <ipsec@ietf.org>; Thu, 12 Nov 2009 20:42:34 -0800 (PST)
Received: from horh1.usa.alcatel.com (h172-22-218-55.lucent.com [172.22.218.55]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id nAD4gtXI005475; Thu, 12 Nov 2009 22:42:56 -0600 (CST)
Received: from mail.apac.alcatel-lucent.com (aprelay03.apac.alcatel-lucent.com [202.65.2.133]) by horh1.usa.alcatel.com (8.13.8/emsr) with ESMTP id nAD4grC0013133; Thu, 12 Nov 2009 22:42:54 -0600 (CST)
Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by mail.apac.alcatel-lucent.com (8.13.7/8.13.7/Alcanet1.0) with ESMTP id nAD4jjqD014942; Fri, 13 Nov 2009 12:45:46 +0800
Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Fri, 13 Nov 2009 10:12:50 +0530
From: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
To: Stephen Kent <kent@bbn.com>
Date: Fri, 13 Nov 2009 10:12:47 +0530
Thread-Topic: [IPsec] WESP - Roadmap Ahead
Thread-Index: AcpkByQNmvb9tFQzS8OQWAWEttLuSAADUvvg
Message-ID: <7C362EEF9C7896468B36C9B79200D8350AB2C85E59@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-luce nt.com> <p06240805c72267851254@[133.93.16.246]>
In-Reply-To: <p06240805c72267851254@[133.93.16.246]>
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.27
X-Scanned-By: MIMEDefang 2.64 on 202.65.2.133
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Merike@core3.amsl.com" <Merike@core3.amsl.com>, Kaeo <merike@doubleshotsecurity.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 04:42:35 -0000

> >
> >So what fields does AH protect:
> >
> >Version, Payload length, Next Header, Source IP and dest IP
> 
> you forgot IPv4 and IPv6  options that have predictable values at the 
> destination

Lets start with the IPv6 Type 0 Route Header (aka "Source Routing" in v4 parlance), which is a mutable but a predictable extension header. It has been discovered and is widely known that these functionalities can be exploited in order to perform remote network discovery, can be used to bypass firewalls and can be used for DoS attacks. RFC 5095 has more details on this. This has been deprecated and nobody is really using this.

Hop-by-Hop Options and Destination Extension Headers

These options contain a bit that indicates whether the option might change (unpredictably) during transit.  For any option for which contents may change en-route, the entire "Option Data" field must be treated as zero-valued octets when computing or verifying the ICV.  The Option Type and Opt Data Len are included in the ICV calculation. All options for which the bit indicates immutability are included in the ICV calculation.  

If we were to use ESP-NULL instead then there is no way to validate whether the Option Type and Opt Data Len is valid or not till the processing is done at the receiving end.

So, what kind of attack can be possibly done by changing these values? What is the real risk involved here?

Fragmentation Header

Fragmentation occurs after AH processing and the reassembly, before AH processing on the other end. So, there is really no gain there too.

Cheers, Manav