Stephen, Your comments arouse my interest in multi-path TCP connection (one connection but multiple paths). I will check the out-of-order issues in that case.
Thanks, Victor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Xiangyang zhang Sent: Friday, April 06, 2012 9:50 AM To: Stephen Kent Cc: [email protected] Subject: 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: [email protected] [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Friday, April 06, 2012 7:39 AM To: Xiangyang zhang Cc: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
