Re: [IPsec] WESP - Roadmap Ahead
Stephen Kent <kent@bbn.com> Mon, 16 November 2009 16: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 3CBC03A6AE0 for <ipsec@core3.amsl.com>; Mon, 16 Nov 2009 08:40:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.166
X-Spam-Level:
X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.434, 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 0ooeCx7pghhZ for <ipsec@core3.amsl.com>; Mon, 16 Nov 2009 08:40:02 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5626C3A6ADE for <ipsec@ietf.org>; Mon, 16 Nov 2009 08:40:02 -0800 (PST)
Received: from dhcp89-089-228.bbn.com ([128.89.89.228]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NA4cP-0007A0-Cd; Mon, 16 Nov 2009 11:39:58 -0500
Mime-Version: 1.0
Message-Id: <p06240800c723d673384e@[10.11.1.91]>
In-Reply-To: <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]> <B71940AB-C732-4240-98CB-75E8C6AAF815@cs.columbia.edu>
Date: Mon, 16 Nov 2009 11:39:30 -0500
To: Steven Bellovin <smb@cs.columbia.edu>
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>
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: Mon, 16 Nov 2009 16:40:03 -0000
>... > >Divine guidance is, I suppose, one way to do protocol design, but it >could lead to *real* religious wars.... an appropriate caution given my typo :-). > > >> 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. There are various options here. I know of devices that have opted to use ESP in tunnel mode to ensure the binding, and that is what I noted during the IPSECME WG session. I may know of an instance or two where AH has been used to do this, because if introduced less (bandwidth) overhead than tunnel mode. Implementations that make use of IPSO or CIPSO should negotiate the labels as part of the SA. The label should be part of the SPD, and be checked based on SAD entry data cached form the SPD. (Can you tell that I've been through al of this?) We had a presentation by Joy (remotely) on adding label support, as a new work item, which would explore these issues in more detail, if we choose to adopt this as a new Wg item. >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. I am not suggesting that any aspect of your analysis is flawed. I am suggesting that before the WG chooses to further deprecate AH, it needs to document the analysis supporting this decision, not just cite a couple of examples and make general statements in support of such an action. Steve
- [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Scott C Moonen
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Merike Kaeo
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Daniel Migault
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Steven Bellovin
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Richard Graveman
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Venkatesh Sriram
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Steven Bellovin
- [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Bhatia, Manav (Manav)
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Dan McDonald
- Re: [IPsec] WESP - Roadmap Ahead Gregory Lebovitz
- Re: [IPsec] WESP - Roadmap Ahead Gregory Lebovitz
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Daniel Migault
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Tero Kivinen
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent
- Re: [IPsec] WESP - Roadmap Ahead Jack Kohn
- Re: [IPsec] WESP - Roadmap Ahead Stephen Kent