Re: [IPsec] WESP - Roadmap Ahead

Steven Bellovin <smb@cs.columbia.edu> Fri, 13 November 2009 17:46 UTC

Return-Path: <smb@cs.columbia.edu>
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 0BD453A67B4 for <ipsec@core3.amsl.com>; Fri, 13 Nov 2009 09:46:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 ub0KMfcHA6MR for <ipsec@core3.amsl.com>; Fri, 13 Nov 2009 09:46:39 -0800 (PST)
Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 0EEAE3A672E for <ipsec@ietf.org>; Fri, 13 Nov 2009 09:46:38 -0800 (PST)
Received: from [172.20.33.20] ([208.51.118.2]) (user=smb2132 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.3/8.14.3) with ESMTP id nADHl3iE024025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 13 Nov 2009 12:47:04 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset=us-ascii
From: Steven Bellovin <smb@cs.columbia.edu>
In-Reply-To: <p06240825c7229aead977@[133.93.16.246]>
Date: Fri, 13 Nov 2009 12:47:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <B71940AB-C732-4240-98CB-75E8C6AAF815@cs.columbia.edu>
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]> <7C362EEF9C7896468B36C9B79200D8350AB2C85E59@INBANSXCHMBSA1.in.alcatel-luce nt.com> <p06240825c7229aead977@[133.93.16.246]>
To: Stephen Kent <kent@bbn.com>
X-Mailer: Apple Mail (2.1077)
X-No-Spam-Score: Local
X-Scanned-By: MIMEDefang 2.65 on 128.59.29.6
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Bhatia, Manav \(Manav\)" <manav.bhatia@alcatel-lucent.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 17:46:40 -0000

On Nov 13, 2009, at 12:16 AM, Stephen Kent wrote:

> My message pointed out that there was no mention of options,  Your reply picked a couple of option examples and argued that they were either not used or did not pose a security problem.
> 
> The right way to generate a god answer is to construct a table of all the options, and provide a rationale for why each one is not covered, deprecated, or not secruity relevant.

Divine guidance is, I suppose, one way to do protocol design, but it could lead to *real* religious wars....
> 
> Also, note that IPSO and CIPSO are examples of options that were discussed at the IPSECME meeting this week, where there is a need to bind the options to the payload.  I observed that using tunnel mode (ESP) addresses this concern, but one could also note that using AH would do the same, with lower per-packet bandwidth overhead.

Or put the labels in the SA, since especially for IPSO you probably want cryptographic separation of different security levels.

I did go through the analysis you suggest for IPv4 and concluded that nothing was both protectable and useful.  I also noted the following issue:

	Furthermore, the AH spec says that we can't
	enumerate the v4 options, and hence whether or not they should
	be included or not -- but RFC1122 says that unknown IP options
	MUST be silently ignored.  So an implementation can receive an
	option that it doesn't recognize, doesn't know if it changes
	en route, must be ignored anyway -- but may or may not be included
	in the AH calculation, and the receiver doesn't know.

Note, of course, that that was from 1995; I have not repeated the analysis for newer AH or IPv6 specs.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb