Subject: RE: [rddp] PS & Arch drafts: status and security issues

From: [email-masked]
Date: Fri, 20 Feb 2004 22:42:14 -0500

> > 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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Sat, 21 Feb 2004 09:30:59 -0600

> mechanisms like may not be good fits to RDDP.

DDP works on packets presented to it by the LLP. They can be
presented out-of-order, but they have to have passed LLP
validation.

So LLP or lower security/authentication is transparent to DDP.
Admittedly serial methods aren't likely to present packets to
DDP out-of-order. If they are using host memory for their own
packet processing then the benefits of RDMA will be minimized.
But many "before" packet authentication/integrity checks can
essentially be performed as though they were in the network
rather than on the host itself.

Voiding invalid data post RDMAP/DDP is exactly that, a post
RDMAP/DDP step. But ultimately it is the same issue for any
application that applies application layer security/authentication
above the transport layer.

But the bottom line is that incorrect STags, MOs or TOs do NOT
pose a security problem -- whether they result from packet
injection, undetected packet corruption, a peer software
bug or a peer with less than honorable intent.

All local memory access is enabled by the ULP using the local
interface. The STag/TO, MSN/MO can only select bytes within
the enabled local memory.

Ease of packet injection is determined by the LLP, and is not
affected by RDMA. The ability of a peer to supply payload that
is not what was expected also exists with or without RDMA.

The ULP must adjust to the fact that is not bothered with
the details. It does not know which bytes of the advertised
buffer were written in what order, but this is not a security
problem if the buffer is being used properly.

The ULP can decide to trust its peer, and simplify its use
of the local interface resulting is some excess exposure of
its buffers. But they are user buffers, the negative impact
of their abuse can easily be evaluated on an application
specific basis.

So an application that is perfectly capable of treating
a void buffer as a void buffer should not have to pay the
overhead of having their iWarp provider zeroing out voided
buffers.