IETF Logo Mail Archive

Re: [IPsec] WESP - Roadmap Ahead

Venkatesh Sriram <vnktshsriram@gmail.com> Tue, 17 November 2009 04:21 UTC

Return-Path: <vnktshsriram@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 139CB3A6A61 for <ipsec@core3.amsl.com>; Mon, 16 Nov 2009 20:21:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 10k-FbIoIv+a for <ipsec@core3.amsl.com>; Mon, 16 Nov 2009 20:21:21 -0800 (PST)
Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by core3.amsl.com (Postfix) with ESMTP id 480293A6A30 for <ipsec@ietf.org>; Mon, 16 Nov 2009 20:21:21 -0800 (PST)
Received: by qyk41 with SMTP id 41so2869600qyk.29 for <ipsec@ietf.org>; Mon, 16 Nov 2009 20:21:17 -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=gaP2yhIUYzihEQn0YcrKM2Ai61Ora0xWl3CZ7uTmf+c=; b=BRbzNO4gYmnJ5nFXiwt2oamlMGVOfw5ANmfOfPxc/tJmhiXu3zyYqyv80k5//GqABX bqIb+3AF+sQ8WblQoeqnqtdHLtSyo23psA3SsASub4M0xApiOrUDtt3DhqvZ57pJK2rD H0rRCr4X+JrkkfiPs8B6eAYEWbUKHgeGFVsvU=
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=PeOFr8LNNMwu6kuYI8I0JIGVRwpIhZX45nRMk0gRRfR2tBh6P67Zwd7RP+thb105gw d+aUipYfkL9MeIZefCIaESMRX/Ro54z3RJi5QThzjlwHlfGI3VFxHyPzS3KgjE//1N4e mfov3FC4QbqTfjz4he05ARdD+ebCT3VsFPZaE=
MIME-Version: 1.0
Received: by 10.224.33.3 with SMTP id f3mr5308199qad.24.1258431677674; Mon, 16 Nov 2009 20:21:17 -0800 (PST)
In-Reply-To: <19201.20208.563706.519993@fireball.kivinen.iki.fi>
References: <dc8fd0140911110805q67759507t6cf75a1e9d81c5aa@mail.gmail.com> <19200.8786.266973.313959@fireball.kivinen.iki.fi> <7C362EEF9C7896468B36C9B79200D8350AB2C86306@INBANSXCHMBSA1.in.alcatel-lucent.com> <19201.20208.563706.519993@fireball.kivinen.iki.fi>
Date: Tue, 17 Nov 2009 09:51:17 +0530
Message-ID: <bb34331b0911162021r53942d69mbfa56f4426ddf999@mail.gmail.com>
From: Venkatesh Sriram <vnktshsriram@gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Content-Type: text/plain; charset="ISO-8859-1"
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: Tue, 17 Nov 2009 04:21:22 -0000

Tero,

On Mon, Nov 16, 2009 at 6:39 PM, Tero Kivinen <kivinen@iki.fi> wrote:
> Bhatia, Manav (Manav) writes:
>> And the reason why you might want to use WESP is to prioritize
>> certain protocol packets over the others, as is normally done for v4
>> control packets (e.g. OSPFv3 HELLOs and ACKs over other OSPFv3
>> packets)
>
> You cannot do that, as if the packets get reordered more than what is
> the replay window size of the responder, then older packets will get
> dropped. If you want to do QoS you need to use multiple IPsec SAs each
> carrying only one traffic for one QoS level.

Since processing of the sequence number fields is at the discretion of
the receiver, it can always elect not to enable the anti-replay
service for a specific SA for which it needs to prioritize certain
packets.

Also if the keys have been manually distributed, which would most
probably happen if WESP is being used as a standalone protocol then
compliant implementations SHOULD NOT provide anti-replay service.

In addition to this, we are discussing a multi-sender SA in which case
replay protection is anyways NOT recommended.

Sriram

v2.23.0 | Report a Bug | By Email