Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec

Stephen Kent <kent@bbn.com> Fri, 06 April 2012 14:42 UTC

Return-Path: <kent@bbn.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC68F21F855D for <ipsec@ietfa.amsl.com>; Fri, 6 Apr 2012 07:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTUs-lJGVJxn for <ipsec@ietfa.amsl.com>; Fri, 6 Apr 2012 07:42:54 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C1F6421F84D6 for <ipsec@ietf.org>; Fri, 6 Apr 2012 07:42:54 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:46614 helo=[192.168.1.6]) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1SGAN2-0006tX-1e; Fri, 06 Apr 2012 10:42:36 -0400
Mime-Version: 1.0
Message-Id: <p06240801cba4af56ce3e@[192.168.1.6]>
In-Reply-To: <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com>
References: <20336.40486.516402.44061@fireball.kivinen.iki.fi> <a75ef412a8addbbf9cdfd495b2ebc5c2.squirrel@www.trepanning.net> <20337.35271.746249.402746@fireball.kivinen.iki.fi> <efc316aaa7bbc447f6fb3f00d605aa4c.squirrel@www.trepanning.net> <20337.53508.89005.604501@fireball.kivinen.iki.fi> <7aa224f3b90062aabf6dea821c57d8a4.squirrel@www.trepanning.net> <20339.3159.442125.142134@fireball.kivinen.iki.fi> <7C4DFCE962635144B8FAE8CA11D0BF1E05B2DFAD08@MX14A.corp.emc.com> <00E6CDB229A4CF4487D6E0326EDE5A0320A0EDF9@dfweml511-mbx.china.huawei.com> <p06240806cba38891fd20@[128.89.89.180]> <00E6CDB229A4CF4487D6E0326EDE5A0320A0F581@dfweml511-mbx.china.huawei.com>
Date: Fri, 06 Apr 2012 10:39:22 -0400
To: Xiangyang zhang <xiangyang.zhang@huawei.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 06 Apr 2012 14:42:55 -0000

At 4:44 AM +0000 4/6/12, Xiangyang zhang wrote:
>Steve,
>
>Your understanding is partially right.  Only that anti-replay window 
>could possibly be bigger if two paths go along the different routes. 
>If two paths go along the same route, it is no difference from the 
>traditional single SA.  But the attacker does not know two paths 
>carry the same flow of traffic.

when you take a sequence of packets and spread them over multiple SAs, you
create new opportunities for the packets to arrive out of order at 
the destination. They have to be merged at the destination, either at 
the host or at an SG. If they are merged at an SG, new functionality 
is required to buffer the packets and re-order them. If not, then 
variances in traffic handling at each end creates new opportunities 
for reordering or traffic, and/or added jitter. OOO arrival is not 
good for TCP connections, irrespective of the IPsec anti-replay 
window. Jitter is also not great, especially for some realtime apps 
that run over UDP.

>   For security consideration, could you point out what is in error?

your text refers to multiple paths, when you mean multiple SAs.

>Thanks,
>
>Victor