Subject: RE: [rddp] comments on draft-black-rdma-concerns-00.txt

From: [email-masked]
Date: Mon, 22 Jul 2002 11:54:34 -0400

Mike,

> > >> In particular, my main concern here is that there may be
> > >> a new class of overwrite attacks for applications which
> > >> check a received message for integrity, then trundle on
> > >> assuming that it will remain intact and well formed.  If
> > >> a malicious peer does a carefully-timed overwrite, it
> > >> may then trigger some sort of stack/buffer overrun and
> > >> take over the application.
> 
> If one is concerned about malicious attacks, then security should be 
> provided such as IPSec which is not a RDMA protocol issue.

That appears to assume that malicious attacks would never come
from peers that are authorized to use the RDDP-enhanced service,
and that's not a good general assumption to make.  For example,
fileservers usually don't completely trust clients that access
files -- having misbehavior by a single client take down the entire
fileserver is usually regarded as undesirable.

> > >> To this end, I believe RDDP/RDMA mechanisms will need to
> > >> track buffer ownership very carefully, in particular
> > >> prohibiting remote writes to a buffer once an
> > >> application has been notified that it has been filled..
> > >
> > >But the RDDP/RDMA layer doesn't know when the buffer is
> > >filled. The ULP may utilize several RDMA ops to fill a
> > >buffer.
> > >
> > >Wouldn't it be better for the ULP just to deregister the
> > >buffer before it checks its integrity ?
> 
> Absolutely not.  Bind / unbind of a window is not necessarily 
> cheap though 
> optimizations can be made.  Anything dealing with allocation / 
> de-allocation windows or registration / deregistration of 
> regions would be prohibitive.

It may be useful to separate the control and data cases.  The
overwrite risk to application integrity applies to control
information, where the application does something different
depending on what it receives (e.g., if DDP were used for some
sort of command data structure).  This overwrite risk probably
does not apply to data that is being passed through (e.g., if a
client overwrites an iSCSI write buffer while the server is
writing it out, the junk that results on the disk is the client's
problem and doesn't affect the server's operational integrity -
the client will get its junk back when it asks for it).

This suggests that the need to prevent this sort of overwrite
depends on the situation, so it may be reasonable to get
the application involved in both the prevention and deciding
when to use it -- for example, "the ULP deregisters the buffer
before it checks its integrity" when buffer integrity matters,
or in situations where it matters, the ULP instructs the stack
to deregister the buffer when the writes to it are complete.

> In general, one should only receive a message once from the transport -
see 
> the requirements document.  The transport prevents duplicates from 
> overwriting the memory.  For non-duplicates, there is no method at the
RDMA 
> / DDP layers to distinguish good / bad packets other than what is provided

> by the transport and lower layers.

I think this is an exercise in strawman demolition.  The concern is
that applications not go down in the face of incorrect input - if
the "bad packets" come first, they have to be dealt with.

> Hence, if there is a malicious attack 
> concern, the lower layer implementation should provide a security solution

> such as IPSec.

I agree that there are some threats that require IPsec or the like to
counter, but one cannot rely on IPsec to ensure that no attacks are
ever attempted through the transport.

> My general comment is the document does not highlight new information not 
> already stated within the current requirements document.  Perhaps there
are 
> areas that should be tightened within the requirements document if there
is 
> any ambiguity which might have been the motivation for this new document 
> but I'd prefer to keep the number of documents to a minimum and focus on 
> getting them correct from the start if possible.

The draft is "input" to the WG - it's not intended to be published as an
RFC.  The text it contains may be useful for things such as the security
considerations sections that will be needed for the main protocol drafts.

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[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: Mon, 22 Jul 2002 13:02:54 -0500

On 7/22/02, [email-masked] wrote:

>
>That appears to assume that malicious attacks would never
>come from peers that are authorized to use the
>RDDP-enhanced service, and that's not a good general
>assumption to make.  For example, fileservers usually
>don't completely trust clients that access files -- having
>misbehavior by a single client take down the entire

The DAFS protocol specifically avoid having the file server
expose its own memory resources.

The reasons for this go beyond preventing deliberate
attacks. An advertised buffer is essentially a dedicated
buffer credit. Granting credits to a very large number of
clients who may be using your services on a sporadic basis
is not a good strategy.

This is one of the best justifications for RDMA Reads, BTW.

I would agree that the source of the attack is a critical
factor in analyzing the risk.

An outside attacker would either have to forge *multiple*
packets that were part of the same connection or *replace* a
tagged put packet.

If an 'extra' ddp put is forged, the ack counts on the
connection will be off, and there will be no completion
before the connection is torn down.

Yes, the data would have been put. But the contents of
exposed buffers should be considered undefined until the
completion is received.

An insider, could of course simply perform excess DDP puts
before sending the reply to an anonymous buffer. To prevent
this a local interface would be required that fully
understood the ULP buffer rules.

This *could* be done for any given set of ULP rules. But
realistically, existing NIC/memory interfaces were designed
for InfiniBand. I would not anticipate any great vendor
enthusiasm for adding new features to the NIC/memory
interface.

This is especially true because this is *not* an
interoperabiilty issue. As I pointed out previously:

1) A compliant ULP uses ONLY buffers that have been properly
advertised for its use.

2) Those buffers MUST have been enabled for access by the
remote peer.

3) How much more of the peers memory is also exposed is not
relevant to a compliant ULP, because it will not test those
memory locations.

---

From: Michael Krause <[email-masked]>
Date: Wed, 24 Jul 2002 08:30:57 -0700

>fileserver is usually regarded as undesirable.

Each client should only be given access to a window at a given time thus 
one cannot take down anything other than what has been exposed to that 
client.  File servers should only expose windows and not the entire memory 
region.  Thus if the communication is over a single stream and targeting a 
given window within the region, it does not seem that RDMA creates any new 
security issues that are at least new in this respect.

>to deregister the buffer when the writes to it are complete.

Sounds like an application / ULP issue and not a RDMA issue.

>the "bad packets" come first, they have to be dealt with.

Agreed - an application / ULP issue in this regard.

>ever attempted through the transport.

Not suggesting IPSec solves all problems but if security is an issue, it 
seems a security layer should deal with it as nothing mentioned within the 
document suggests that RDMA is somehow creating security issues or causing 
non-application / ULP control data corruption.

Mike