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