This email is about the second major issue discussed in San Diego.
Here's the summary of the potential attack from the draft minutes:
Issue is around having data sink buffer contents getting changed
before the buffer [STag] is invalidated. If protocol or
application logic depends on the contents not changing, this may
open up attacks on the protocol. IPsec doesn't help because one
has to protect against a less than fully trusted peer who can
authenticate and use IPsec if required.
Requiring all Stags to be One-Shot (single RDMA operation) has
been discussed and rejected on the list. Discussion in San Diego
reinforced that rejection. I believe that rejection is the
rough consensus of the RDDP Working Group.
Two approaches beyond stiff warnings to ULP implementers were
discussed in San Diego. This is slightly summarized from the
minutes:
a) Receive and Invalidate.
Problem: This won't work when data transfers can complete in
non-deterministic order, because the exact sequence of
completion has to be known in advance. Both iSCSI and
NFS exhibit this non-deterministic order behavior.
Sense of room: Not worth pursuing further due to limited
applicability.
b) RDMA Write & Invalidate:
Defining RDMA Writes that do and don't invalidate the
appropriate STag still requires a receiver check for
invalidation and hence provides no leverage.
Sense of room: Not worth pursuing.
Conclusion of issue: Need to make sure security and protocol
drafts contain stiff warnings about the need for any ULP using
RDDP to invalidate receive STags prior to using data they cover.
This is an opportunity for anyone on the list to object to
the conclusions from the San Diego meeting, but please read
the entire San Diego minutes on this topic before objecting.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[email protected] Mobile: +1 (978) 394-7754
----------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.