headers
Michael Krause | 24 Jul 2002 17:30
Picon

RE: comments on draft-black-rdma-concerns-00.txt

At 11:54 AM 7/22/2002 -0400, Black_David <at> emc.com wrote:
>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.

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 this end, I believe RDDP/RDMA mechanisms will need to
> > > >> track buffer ownership very carefully, in particular
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Sommerfeld | 27 Jul 2002 12:03
Picon

Re: comments on draft-black-rdma-concerns-00.txt

> If one is concerned about malicious attacks, then security should be 
> provided such as IPSec which is not a RDMA protocol issue.

This represents a fundamental misunderstanding.  IPsec provides a
mechanism to allow for confidentiality and integrity.  It is not
"magic pixie dust" which protects applications against buffer
overruns, etc.,

The mere fact that a peer may be authenticated and even authorized to
talk with an application does not mean that the peer is authorized to
hijack the application.

> > >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.

The WG charter says:

   The working group will ensure that the resulting technology will be
   secure and will not enable new attacks on systems supporting RDDP.

An overwrite race condition sounds to me like a "new attack".

						- Bill
Permalink | Reply | 1 comment |
headers
Caitlin Bestler | 27 Jul 2002 18:19

Re: comments on draft-black-rdma-concerns-00.txt

On 7/27/02, Bill Sommerfeld wrote:

>The WG charter says:
>
> The working group will ensure that the resulting
> technology will be secure and will not enable new attacks
> on systems supporting RDDP.
>
>An overwrite race condition sounds to me like a "new
>attack".

This is a local interface issue, not a protocol issue.

Fundamentally, the Data Source does not need, nor should
it have, the complete semantics of the STag that is part
of the buffer advertisement it received.

The only knowledge it requires is the extent of permission
given to it by the ULP. DAFS is probably typical of the
rules most ULPs will establish:

-- the client sends a request to an anonymous buffer that
   contains a buffer advertisement and a request for some
   work to be done using that buffer.

-- the server performs that work.

-- the server sends a reply back to client, also to an 
   anonymous buffer,  thereby terminating its rights to
   the advertised buffer.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Black_David | 27 Jul 2002 23:06

RE: comments on draft-black-rdma-concerns-00.txt

A few comments:

> This is a local interface issue, not a protocol issue.

That doesn't rule it out of scope - if properties of the local
interface are important to the secure use of the protocol, those
properties need to be specified.  It's not necessary to specify
the local interface itself - functional requirements/constraints
on it are sufficient to get the job done.  One example can be found
in the IPsec architecture RFC - see Section 4.4 (and subsections)
of RFC 2401.

> The ULP Data Sink / Client MUST ensure that it has used
> local interfaces to enable RDDP layer memory access with
> sufficient rights to match the advertised buffers.
> 
> There is no *protocol* justification for mandating that all
> Data Sinks MUST protect the rest of their memory. The
> protocol MUST NOT *prevent* them from doing so.

The actual situation may be somewhere in between:
- It's probably appropriate to require (MUST implement) suitable
	data protection mechanisms even if their use is OPTIONAL.
	As I noted earlier, if the RDDP mechanisms are being used
	only to transfer data and not control, this overwrite
	attack can't cause application integrity problems and
	hence protecting against it may not be necessary.
- The "Security Considerations" section of the protocol
	specification(s) will need to discuss this overwrite
	possibility, when/how it poses a risk, and what to do
(Continue reading)

Permalink | Reply | 2 comments |
headers
Bill Sommerfeld | 28 Jul 2002 18:33
Picon

Re: comments on draft-black-rdma-concerns-00.txt

> 	As I noted earlier, if the RDDP mechanisms are being used
> 	only to transfer data and not control, this overwrite
> 	attack can't cause application integrity problems and
> 	hence protecting against it may not be necessary.

In thinking some more about this, the "data"/"control" distinction
doesn't quite capture the risks involved with overwrites.  It's more
of a a "read once" vs "read multiple" case -- overwrites which come in
between multiple reads may cause unexpected application behavior.

So, one could conceivably write a parser for a protocol which loads
each byte at most once -- in which case, overwrites are irrelevant.

Consider anther hypothetical system where a checksum is computed by
the receiving application and stored as part of metadata.

An app is notified of rddp'ed data, computes a checksum over the data,
and then schedules the data to be written to stable store (presumably
with another DMA operation).  Thus, despite being "bulk data", each
byte is read twice -- once by whatever computes the checksum, and
again by the disk controller writing it out to stable store.

So, in parallel with this (during or after the checksum computation),
another rddp/rdma message comes in and overwrites one of the pages
being written, causing the image in stable store to not match the
checksum...

Depending on the scope of the checksum (this may be a checksum over a
batch of transactions being written to a journal), this may
effectively deny future access to more than just the data which the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Caitlin Bestler | 28 Jul 2002 23:47

Re: comments on draft-black-rdma-concerns-00.txt

On 7/28/02, Bill Sommerfeld wrote:

>>  As I noted earlier, if the RDDP mechanisms are being
used
>>  only to transfer data and not control, this overwrite
>>  attack can't cause application integrity problems and
>>  hence protecting against it may not be necessary.
>
>In thinking some more about this, the "data"/"control"
>distinction doesn't quite capture the risks involved with
>overwrites.  It's more of a a "read once" vs "read
>multiple" case -- overwrites which come in between
>multiple reads may cause unexpected application behavior.
>
>So, one could conceivably write a parser for a protocol
>which loads each byte at most once -- in which case,
>overwrites are irrelevant.
>
>Consider anther hypothetical system where a checksum is
>computed by the receiving application and stored as part
>of metadata.
>
>An app is notified of rddp'ed data, computes a checksum
>over the data, and then schedules the data to be written
>to stable store (presumably with another DMA operation). 
>Thus, despite being "bulk data", each byte is read twice
>-- once by whatever computes the checksum, and again by
>the disk controller writing it out to stable store.
>
>So, in parallel with this (during or after the checksum
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.K. Jerry Chu | 30 Jul 2002 04:07
Picon

Re: comments on draft-black-rdma-concerns-00.txt

>On 7/27/02, Bill Sommerfeld wrote:
>
>
>>The WG charter says:
>>
>> The working group will ensure that the resulting
>> technology will be secure and will not enable new attacks
>> on systems supporting RDDP.
>>
>>An overwrite race condition sounds to me like a "new
>>attack".
>
>This is a local interface issue, not a protocol issue.
>
>Fundamentally, the Data Source does not need, nor should
>it have, the complete semantics of the STag that is part
>of the buffer advertisement it received.

Yes and no. On one extreme the minimal semantic of the STag
the data source needs to know is simply its validity wrt the
given RDMA transaction where the tag is exposed. THe rest is
all left to the implementation. E.g. in an environment where
malicious attacks are possible, implementations must
invalidate/deregister STag at the end of every RDMA transaction.
In other environment and/or application paradigm where attacks
are not an issue, implementations may choose to defer tag
invalidation or reuse/remap tags in order to attain higher
performance. These different levels of protection can be
negotiated upfront.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Caitlin Bestler | 30 Jul 2002 04:38

Re: comments on draft-black-rdma-concerns-00.txt

On 7/29/02, H.K. Jerry Chu wrote:

>>On 7/27/02, Bill Sommerfeld wrote:
>>
>>
>>>The WG charter says:
>>>
>>> The working group will ensure that the resulting
>>> technology will be secure and will not enable new
attacks
>>> on systems supporting RDDP.
>>>
>>>An overwrite race condition sounds to me like a "new
>>>attack".
>>
>>This is a local interface issue, not a protocol issue.
>>
>>Fundamentally, the Data Source does not need, nor should
>>it have, the complete semantics of the STag that is part
>>of the buffer advertisement it received.
>
>Yes and no. On one extreme the minimal semantic of the
>STag the data source needs to know is simply its validity
>wrt the given RDMA transaction where the tag is exposed.
>THe rest is all left to the implementation. E.g. in an
>environment where malicious attacks are possible,
>implementations must invalidate/deregister STag at the end
>of every RDMA transaction. In other environment and/or
>application paradigm where attacks are not an issue,
>implementations may choose to defer tag invalidation or
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.K. Jerry Chu | 30 Jul 2002 05:11
Picon

Re: comments on draft-black-rdma-concerns-00.txt

>>>>The WG charter says:
>>>>
>>>> The working group will ensure that the resulting
>>>> technology will be secure and will not enable new
>attacks
>>>> on systems supporting RDDP.
>>>>
>>>>An overwrite race condition sounds to me like a "new
>>>>attack".
>>>
>>>This is a local interface issue, not a protocol issue.
>>>
>>>Fundamentally, the Data Source does not need, nor should
>>>it have, the complete semantics of the STag that is part
>>>of the buffer advertisement it received.
>>
>>Yes and no. On one extreme the minimal semantic of the
>>STag the data source needs to know is simply its validity
>>wrt the given RDMA transaction where the tag is exposed.
>>THe rest is all left to the implementation. E.g. in an
>>environment where malicious attacks are possible,
>>implementations must invalidate/deregister STag at the end
>>of every RDMA transaction. In other environment and/or
>>application paradigm where attacks are not an issue,
>>implementations may choose to defer tag invalidation or
>>reuse/remap tags in order to attain higher performance.
>>These different levels of protection can be negotiated
>>upfront.
>>
>>But the above more liberal approach has the drawback of
(Continue reading)

Permalink | Reply | 6 comments |
headers
Caitlin Bestler | 30 Jul 2002 06:03

Re: comments on draft-black-rdma-concerns-00.txt

On 7/29/02, H.K. Jerry Chu wrote:

>>
>>The scope of each STag is explicitly defined, and it is
>>explicitly conveyed to the other side. But that can be
>>done by the ULP without complicating the RDDP layer.
>
>If the scope of STag is defined by a ULP, how would a RNIC
>know when to invalidate (i.e. deregister) a STag without
>understanding the ULP? (Not having followed discussions in
>iWARP I may have missed something here.)
>

Exactly the point.

The Data Sink ULP is responsible for invalidating the STag.

It MAY/SHOULD have a local interface to allow it  do to so
without having to turn around and place a new asynchronous
request back to the NIC.

But the RDDP layer CANNOT know when to invalidate the STag
unless told by the ULP.

This is especially true on the Data Source end, where the
RDDP layer does not even know what STags have been delivered
to the ULP. Only he Data Sink RDDP layer knows about the
STag,  it is a meaningless opaque tag to the Data Source
RDDP layer that is dealt with on a per-RDDP-put basis.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane