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

From: Xiangyang zhang <[email-masked]>
Date: Tue, 3 Apr 2012 01:12:58 +0000

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.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 5 Apr 2012 15:29:08 -0400

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.
>

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

---

From: Xiangyang zhang <[email-masked]>
Date: Fri, 6 Apr 2012 04:44:31 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Thursday, April 05, 2012 12:29 PM
To: Xiangyang zhang
Cc: [email-masked]
Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec

>   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
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Fri, 6 Apr 2012 10:39:22 -0400

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.

---

From: Xiangyang zhang <[email-masked]>
Date: Fri, 6 Apr 2012 16:50:20 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Friday, April 06, 2012 7:39 AM
To: Xiangyang zhang
Cc: [email-masked]
Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec

At 4:44 AM +0000 4/6/12, Xiangyang zhang wrote:
>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.

---

From: Xiangyang zhang <[email-masked]>
Date: Fri, 6 Apr 2012 17:04:25 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Xiangyang zhang
Sent: Friday, April 06, 2012 9:50 AM
To: Stephen Kent
Cc: [email-masked]
Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec

Stephen,

Thanks,

Victor

---

From: Stephen Kent <[email-masked]>
Date: Sun, 8 Apr 2012 10:27:19 -0400

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.

>  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

---

From: <[email-masked]>
Date: Mon, 9 Apr 2012 09:49:34 -0500

>>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

---

From: Stephen Kent <[email-masked]>
Date: Mon, 9 Apr 2012 17:50:28 -0400

At 9:49 AM -0500 4/9/12, <[email-masked]> wrote:
>>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

---

From: Xiangyang zhang <[email-masked]>
Date: Mon, 9 Apr 2012 22:11:22 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Sunday, April 08, 2012 7:27 AM
To: Xiangyang zhang
Cc: [email-masked]
Subject: Re: [IPsec] draft-zhang-ipsecme-multi-path-ipsec

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.  

>In your previous mail, this is potentially very complex feature.  As a 
>matter of fact, it is simpler comparing with SA bundle in 

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.

>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

---

From: Xiangyang zhang <[email-masked]>
Date: Mon, 9 Apr 2012 22:14:02 +0000

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: [email-masked] [mailto:[email-masked]] 
Sent: Monday, April 09, 2012 7:50 AM
To: [email-masked]; Xiangyang zhang
Cc: [email-masked]
Subject: RE: [IPsec] draft-zhang-ipsecme-multi-path-ipsec

>>TCP reorder or IP reassembly, it can be done at intermediate node or end host.
>

	paul

---

From: Xiangyang zhang <[email-masked]>
Date: Mon, 9 Apr 2012 22:18:14 +0000

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:[email-masked]] 
Sent: Monday, April 09, 2012 2:50 PM
To: [email-masked]
Cc: Xiangyang zhang; [email-masked]
Subject: RE: [IPsec] draft-zhang-ipsecme-multi-path-ipsec

At 9:49 AM -0500 4/9/12, <[email-masked]> wrote:
>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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Apr 2012 03:55:02 -0400

At 10:11 PM +0000 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 

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.

>...
>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.

>...
>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.

>...
>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