Steve Even though TCP or IP does not envision it, the ordered processing is very common now. In an intermediary node, IP reassembly and TCP reorder must be done some time. In flow-based technology (for example, stateful firewall), without IP reassembly, it could not work. You know flow is based on 5 tuples, non-first fragments has no TCP or UDP port information in it. Without IP reassembly, the only way is to drop the packet. No customer will accept this kind of network product.
In NAT device, no matter it is large scale (LSN) or others, it could break some application like FTP, VOIP etc. TCP payload must be extracted. If TCP segments do not arrive in order, it must wait for it. In our GGSN product, there are also some cases where TCP reorder must be done. Just like TCP/IP, the ordered arrival is not a requirement. This is similar to IPsec. Please check my comments inline starting with "victor>". Thanks, Victor -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Sunday, April 08, 2012 7:27 AM To: Xiangyang zhang Cc: [email protected] Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec At 4:50 PM +0000 4/6/12, Xiangyang zhang wrote: >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. The TCP and IP specs do not envision an intermediary trying to put packets back in order or performing reassembly. When middle bioxes do this performance often suffers. Victor> Current network is much more complicated than old one. It could not be avoided in some situation even though you do not want to do that. > 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. note that 4301 removed the requirement to support SA bundles, so the comparison seems out of place. Victor> I note that too. If we do not compare SA bundle and cluster, we can just compare SA and SA cluster. The later is an option to enhance the security. >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. as I noted in prior messages, this seems awfully complex and has the potential to degrade performance, so a very string secruity argument needs to be made to justify considering this proposal. I have not seen that argument. Victor> I do not want to deny that it has the potential to degrade the performance. But I want to say it also has the potential to improve the performance, for example, when congestion happens. This is why multi-path TCP comes into picture. SA cluster should not be awfully complex. If there are two SA, it just group them together. I implemented one IPsec stack before. If I update the code, it does not need much change at both sending side and receiving side. If you see it is awfully complex, how do you come to that conclusion? I use SA bundle as an example, just want to say that it is simpler than SA bundle. And the performance should be better in most cases. Steve _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
