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.
For security consideration, could you point out what is in error? Thanks, Victor -----Original Message----- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Stephen Kent Sent: Thursday, April 05, 2012 12:29 PM To: Xiangyang zhang Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec At 1:12 AM +0000 4/3/12, Xiangyang zhang wrote: >A new version of I-D, draft-zhang-ipsecme-multi-path-ipsec-00.txt >has been successfully submitted by Xiangyang Zhang and posted to the >IETF repository. > >Filename: draft-zhang-ipsecme-multi-path-ipsec >Revision: 00 >Title: Multiple Path IP Security >Creation date: 2012-04-02 >WG ID: Individual Submission >Number of pages: 7 > >Abstract: > This document presents one approach to enhance data protection when > transmitting IPsec datagrams across the insecure networks. The method > affords the stronger protection to the traffic by splitting it among > a set of sub-tunnels. All the Security Associations (SAs) are set up > independently for all sub-tunnels. Both the sending and receiving > entity combine all the sub-tunnels to one clustered tunnel. As > different sub-tunnel uses different crypto key materials and > processing parameters, it may achieve the stronger protection of the > traffic across the insecure networks. In addition, it could possibly > bring more benefits in terms of the network control. This seems like a potentially very complex feature that creates added opportunities for packet arrival reordering (of added jitter) without a good analysis of the security rationale. Also, as others have noted, this is not a "multi-path" feature, but a multi=-tunnel feature, so the doc name is inappropriate. The comment on multiple paths in the secruity considerations section is also in error. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
