Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
I agree with Steve Kent's recent postings about this draft. Ran ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 10:11 PM + 4/9/12, Xiangyang zhang wrote: 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. and yet there are adverse affects ... 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. you're giving examples of intermediate nodes doing things that can cause problems. Just like TCP/IP, the ordered arrival is not a requirement. This is similar to IPsec. IPsec does not intrinsically reorder packets. At worst is may discard packets that arrived very much out of order, a situation where TCP probably would have requested retransmission anyway. Please check my comments inline starting with "victor>". ... 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. You're creating new opportunities to make the problem worse. ... 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. You say that, but you have failed to provide any analysis to support this claim. ... 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. pick an argument and stick with it :-). when this began you didn't seem to know about multi-path TCP, so your proposal can't be assuming its use. 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 have watched a number of vendors produce non-compliant IPsec implementations since I wrote 2301. That perspective provides me with a basis for arguing that this proposal adds complexity for questionable benefit. 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. SA bundles were removed because most vendors felt they were too complex and did not offer enough benefits. So, saying that this proposal is simpler than SA bundles does not make it simple :-). Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
That is also the common case. When you want to offload something for destination, you have to do IP reassembly. -Original Message- From: Stephen Kent [mailto:k...@bbn.com] Sent: Monday, April 09, 2012 2:50 PM To: paul_kon...@dell.com Cc: Xiangyang zhang; ipsec@ietf.org Subject: RE: [IPsec] draft-zhang-ipsecme-multi-path-ipsec At 9:49 AM -0500 4/9/12, wrote: > >At 4:50 PM + 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. > >In fact, reassembly at intermediate nodes is not possible at all, >because IP can route packets on several routes. The full stream of >packets is only available at the end points, so that is the only place >where reassembly can be done. > > paul Paul, I agree in general, but I was considering the case where the intermediate node is very enough to the destination. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
Paul, The packets or fragments can go different route, but there is aggregate point where assembly could be done. For example, usually firewall/IPsec are integrated in the same network device. And reassembly must be done when flow-based processing comes into picture. Thanks, Victor -Original Message- From: paul_kon...@dell.com [mailto:paul_kon...@dell.com] Sent: Monday, April 09, 2012 7:50 AM To: k...@bbn.com; Xiangyang zhang Cc: ipsec@ietf.org Subject: RE: [IPsec] draft-zhang-ipsecme-multi-path-ipsec >At 4:50 PM + 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. In fact, reassembly at intermediate nodes is not possible at all, because IP can route packets on several routes. The full stream of packets is only available at the end points, so that is the only place where reassembly can be done. paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Stephen Kent Sent: Sunday, April 08, 2012 7:27 AM To: Xiangyang zhang Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec At 4:50 PM + 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 9:49 AM -0500 4/9/12, wrote: >At 4:50 PM + 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. In fact, reassembly at intermediate nodes is not possible at all, because IP can route packets on several routes. The full stream of packets is only available at the end points, so that is the only place where reassembly can be done. paul Paul, I agree in general, but I was considering the case where the intermediate node is very enough to the destination. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
>At 4:50 PM + 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. In fact, reassembly at intermediate nodes is not possible at all, because IP can route packets on several routes. The full stream of packets is only available at the end points, so that is the only place where reassembly can be done. paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 4:50 PM + 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. 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. 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. Steve ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Xiangyang zhang Sent: Friday, April 06, 2012 9:50 AM To: Stephen Kent Cc: ipsec@ietf.org 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: ipsec-boun...@ietf.org [mailto:ipsec-boun...@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 + 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 ___ 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
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-boun...@ietf.org [mailto:ipsec-boun...@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 + 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 ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 4:44 AM + 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
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
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 + 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
Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec
At 1:12 AM + 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] draft-zhang-ipsecme-multi-path-ipsec
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. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
