> > I'm not sure this is true -- the question quoted in David's
> > original message was (in effect) whether an attacker could sneak
> > bytes past a packet authentication stage in a way that would not
> > be possible if RDMA were not used. Whether or not the application
> > *should* look at such bytes is not the issue; the problem arises
> > when the application can be tricked into looking at them.
>
> A given byte in user memory space is either exposed for read
> and/or write or it is not. The ULP validity of the packet
> that takes advantage of that enabled access is irrelevant.
>
> Developing packet steering logic for each ULP creates *more*
> of a vulnerability because there are more algorithms that can
> be fooled.
Unfortunately, that's not the comparison that the AD who wrote the
original comment is concerned with. The comparison of interest
is whether RDDP introduces additional security issues by comparison
to a protocol stack that does no direct placement. Jeff's outlined
a scenario in which a corrupted buffer that the ULP would not
ordinarily look at could be used as part of an attack on the ULP.
The first-order response to this threat should be a
recommendation to use IPsec and run the packet authentication/
integrity check *before* placement when this threat is a concern.
The "*before*" is a good idea anyhow, as the IPsec check also covers
the placement data. Beyond this, Jeff's suggestion to overwrite
placed data that has failed this sort of check seems reasonable,
and the possible need to do that overwrite can be added to the
discussion we already need on why TLS and in-order security
mechanisms like may not be good fits to RDDP.
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.