Re: [IPsec] WESP - Roadmap Ahead

Jack Kohn <kohn.jack@gmail.com> Sun, 22 November 2009 23:17 UTC

Return-Path: <kohn.jack@gmail.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 19D6A3A680E for <ipsec@core3.amsl.com>; Sun, 22 Nov 2009 15:17:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level:
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 WMV4YGVAfGB6 for <ipsec@core3.amsl.com>; Sun, 22 Nov 2009 15:17:50 -0800 (PST)
Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by core3.amsl.com (Postfix) with ESMTP id 2EFCA3A67F5 for <ipsec@ietf.org>; Sun, 22 Nov 2009 15:17:50 -0800 (PST)
Received: by ywh15 with SMTP id 15so4789891ywh.5 for <ipsec@ietf.org>; Sun, 22 Nov 2009 15:17:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=taiHBEhgVEYezjX0C6oJTcoDz82ZvKePKcyYVHzHRGI=; b=WqhtQKuiYtwFozv7HhU7e909tLs841cUsRl1u0tihv52KTrvLbAhzyPNXO7FKx6MCJ /e7lNh/IZwq2DKEKYDCq3HaMqbapJtmXOE0H+s9F4B+4wxUX5xTb5KLzIMaGOAlJzCrb 0uOh4xEHh4gvMm3Z5f9Rp/1MK2jbBW1McE3UM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V+r7b8OR7CY/RUUML4YplFkmS31xQq2B5pb4gMZr91lyliy7vaR0sj5GJ8ImLXh5dY uTHHGVEfC2g7MyqU8tiSAL23Vj/nRTg/mpxJcm4e3ztsr0+Vk08NOqXUjo0KRvAFaoJ3 3TT7cjRNtg+RH94OBOK2lKoLq4JFjkkzUEROM=
MIME-Version: 1.0
Received: by 10.90.217.13 with SMTP id p13mr5559852agg.108.1258931862110; Sun, 22 Nov 2009 15:17:42 -0800 (PST)
In-Reply-To: <p06240804c72ef7906c90@192.168.1.3>
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> <p06240804c72ef7906c90@192.168.1.3>
Date: Mon, 23 Nov 2009 04:47:42 +0530
Message-ID: <dc8fd0140911221517j1ad39eeaje143b80c860b8681@mail.gmail.com>
From: Jack Kohn <kohn.jack@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
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 23:17:51 -0000

>>
>> 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,

http://www.ietf.org/mail-archive/web/ipsec/current/msg05070.html

This is one example, we could think of some more.

>
>        -it fails to explain how WESP is relevant, since a receiver has the

This has already been discussed in this email thread earlier.

> ability to process encrypted packets. WESP is a protocol that has been
> promoted as designed to aid middle boxes, not end systems

Border Gateway Protocol (BGP) (http://www.ietf.org/rfc/rfc4271.txt)
was originally designed to work as an Exterior Gateway Protocol (EGP).
Today besides working as an EGP it is used in myriad other
applications, from discovering nodes in a VPN to distributing advisory
messages to remote network operators. So, i dont see a reason why we
should restrict ourselves to the applications for which a protocol can
be used ..

Jack

>
> Steve
>