IETF Logo Mail Archive

Re: [IPsec] WESP - Roadmap Ahead

Stephen Kent <kent@bbn.com> Sun, 22 November 2009 14:25 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 7B7B63A6819 for <ipsec@core3.amsl.com>; Sun, 22 Nov 2009 06:25:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level:
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 2OdgUApUWrpp for <ipsec@core3.amsl.com>; Sun, 22 Nov 2009 06:25:56 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id BED0A3A67A2 for <ipsec@ietf.org>; Sun, 22 Nov 2009 06:25:56 -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 1NCDNv-0000wK-A7; Sun, 22 Nov 2009 09:25:51 -0500
Mime-Version: 1.0
Message-Id: <p06240804c72ef7906c90@[192.168.1.3]>
In-Reply-To: <dc8fd0140911210939i4113200ckbfadb5e0a5ea9b50@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> <p06240804c729109c4f93@10.1.231.26> <dc8fd0140911210939i4113200ckbfadb5e0a5ea9b50@mail.gmail.com>
Date: Sun, 22 Nov 2009 09:25:47 -0500
To: Jack Kohn <kohn.jack@gmail.com>
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>, 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: Sun, 22 Nov 2009 14:25:57 -0000

At 11:09 PM +0530 11/21/09, Jack Kohn wrote:
>Steve,
>
>>
>>  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
>
>You got it all wrong. The sender is sending packets with the same QoS
>parameters; its the receiver thats trying to prioritize some packets
>over the others. One would typically do this for the Hellos/KeepAlives
>that are associated with a protocol, so that the  adjacency/peering
>session are not timed out.
>
>Jack

Jack,

Maybe I got it "all wrong" because the explanation provided in the 
messages was, at best, ambiguous :-).

Your description above is only marginally better:

	- it fails to characterize the range of protocols for which 
you believe this argument applies,

	-it fails to explain how WESP is relevant, since a receiver 
has the ability to process encrypted packets. WESP is a protocol that 
has been promoted as designed to aid middle boxes, not end systems

Steve

v2.23.0 | Report a Bug | By Email