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

Stephen,

You understand this method very well.  The disadvantage is the possible severity of out of order delivery.  Even with single SA, it can also cause the out of order problem.  As for re-order, just like TCP reorder or IP reassembly, it can be done at intermediate node or end host.  If it is done at SGW, RFC 6471 may help to mitigate the issue.

In your previous mail, this is potentially very complex feature.  As a matter of fact, it is simpler comparing with SA bundle in implementation.  For SA bundle with two SAs, it must go through the processing two times.  For SA cluster, packet just needs to be processed one time.  Here I do not intend to deny the out of order claim. 

This is another option comparing with SA or SA cluster.  The product developers can choose what method they need, or it can be configurable.  I submitted the draft to see if it exhibits some benefit.  It does not intend to be necessarily absolute better or replace the existing method.

Thanks,

Victor

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Stephen Kent
Sent: Friday, April 06, 2012 7:39 AM
To: Xiangyang zhang
Cc: ipsec@ietf.org
Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec

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

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec