Re: TCP RDMA option to accelerate NFS, CIFS, SCSI, etc.

[Charles Esson <charlese@cvs.com.au>]

I must have missed something.

If we don't have this, you can take the destination port, convert to a
table address, use the sequence number,
do some calculations and come up with a buffer address and an offset. If
you want to mess up the layering
of your stack, they are all things you can do now.

or using RDMA

You tell the would the contents of your table, have the server play with
the data so detailed,
the server sends back info in this option.

--->An attacker plays with the data so returned.

The client instead of doing the port to table translation to determine
where to send the data
from the packet , does a port to table translation to find the table to
detect malicious corruption's
of the option.

How can you assume anything in the option is nothing but rubbish until
such
a translation and check is done?


1) Haven't you only changed the reason to do the port to table
translation.
2) Have completely messed up the layering of your stack. Ok people do it,
but as an option?
3) Provided a whole new farm yard of bugs and potential attacks?

As I read more and more RFC's one question I am constantly asking, why are
people making this terrific
protocol more and more complicated.

Isn't it difficult enough to implement already ( I think it is anyway).



Costa Sapuntzakis wrote:

> The TCP RDMA option reduces the overhead of receiving data over
> TCP-based protocols such as NFS and HTTP.
>
> It enables the construction of a simple hardware accelerator that
> copies data directly from the incoming packet into application
> buffers, avoiding expensive copies in the protocol stack.  Even
> without hardware acceleration, the option enables the protocol stack
> to decrease the number of copies it must do.

1) I think your a bit game if you assume the data in the option is
anything other than a story that aims to mislead.
2) If you want to play this game why can't you use the port, sequence
number and a table? All things available
to you without advertising the state of your system.

>
>
> The TCP RDMA option is an annotation and requires no modifications to
> higher layer protocols. It can be used with popular protocols such as
> HTTP, NFS, and CIFS, along with new protocols.

>
>
> The TCP option also provides a bit to indicate application-level
> message boundaries. The bit enables out-of-order processing of the TCP
> receive queue, potentially decreasing service times in the presence of
> packet drops and improving performance on parallel systems.

Out of order processing assumes the data that didn't arrive one day will.
Is that a valid
assumption on the internet? What happens with packets that are received
more than once,
do you DMA over the previous data thus corrupting the changes that have
been made
by the application? Do you make the rule the application may not alter the
DMA buffers?
Or do you check for this condition? Is this check in your acceleration
hardware?

I assume you believe you still only move the sequence number forward if
all data has
been received to that sequence number. Is this done in the acceleration
hardware?

By the time you have checked that the option is valid, updated your
received
sequence number, and made sure you are not DMAing  over data the
application already
has, what have you gained that could not be had without this option and a
restructure of a stack.

P.S. Maximum of two copies in the stack I wrote, one from card to
ip_buffer, and an
optional copy from ip_buffer to application_buffer. I don't believe I am
partially smart.
I deceive the introduction is misleading.


>
>
> A draft describing the TCP RDMA option can be found at:
> ftp://ftpeng.cisco.com/pub/rdma/draft-csapuntz-tcprdma-00.txt
>
> -Costa