IETF Logo Mail Archive

Re: [IPsec] WESP - Roadmap Ahead

Stephen Kent <kent@bbn.com> Sat, 21 November 2009 13:03 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 12DF53A682D for <ipsec@core3.amsl.com>; Sat, 21 Nov 2009 05:03:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level:
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 vC4lNNh3GtlD for <ipsec@core3.amsl.com>; Sat, 21 Nov 2009 05:03:09 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 1EFC43A6819 for <ipsec@ietf.org>; Sat, 21 Nov 2009 05:03:09 -0800 (PST)
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.1.3]) by smtp.bbn.com with esmtp (Exim 4.63) (envelope-from <kent@bbn.com>) id 1NBpcE-0005AC-A3; Sat, 21 Nov 2009 08:03:02 -0500
Mime-Version: 1.0
Message-Id: <p06240804c729109c4f93@[10.1.231.26]>
In-Reply-To: <f1548840911171103m4d39e544q236448d4b1c8eefe@mail.gmail.com>
References: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com> <19200.8786.266973.313959@fireball.kivinen.iki.fi> <19201.20208.563706.519993@fireball.kivinen.iki.fi> <p06240805c7272bb53718@128.89.89.228> <f1548840911171103m4d39e544q236448d4b1c8eefe@mail.gmail.com>
Date: Sat, 21 Nov 2009 08:03:02 -0500
To: Gregory Lebovitz <gregory.ietf@gmail.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-953313913==_ma============"
Cc: "ipsec@ietf.org" <ipsec@ietf.org>, "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>, Tero Kivinen <kivinen@iki.fi>
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: Sat, 21 Nov 2009 13:03:10 -0000

At 11:03 AM -0800 11/17/09, Gregory Lebovitz wrote:
>inline...
>
>On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent 
><<mailto:kent@bbn.com>kent@bbn.com> wrote:
>
>At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote:
>
>This is an implementation specific optimization that has already 
>been solved in multiple implementations.
>
>Cheers, Manav
>
>
>Is the phrase "implementation specific" a euphemism for non-standard?
>
>
>GML>  Or perhaps, a local security policy decision to ease up on the 
>size of the enforcement window -- aka ease security requirements -- 
>in order to get more QoS enforcement capability -- aka convenience 
>-- ??

4301 contains We have explicit directions on how to use multiple SAs 
when the peers know that they want to send traffic with different QoS 
parameters. This appears to be an instance where the middle boxes are 
to examining traffic, and putting in into different QoS queues. That 
raises the question of how a receiver would know that this is 
happening, so that a bigger enforcement window is needed.

ESP and AH already allow a receiving peer to select any size window 
that it wants, bigger than the specified minimum. So that is not an 
issue.

Steve

v2.23.0 | Report a Bug | By Email