Subject: RE: [rddp] Re: security-draft : Stale Data

From: [email-masked]
Date: Wed, 25 Jun 2003 17:44:33 -0600

Caitlin,

What I suggested isn't anything different then what you are saying - the important thing is protecting from data left from a prior application or sessions use of the memory (which I called "stale" data because that is what the original text used). There are at least two ways to protect against that security hole:
a) initialize the memory to zero before advertising it, or
b) ensure that the new data has been written to the buffer before advertising it.

For memory that is dynamically moved around between sessions, (a) can entail a lot of unnecessary extra work while (b) just requires being careful about the order of execution of the operations one has to do anyway or that one may sometimes have to do a separate operation to enable remote read access. Both (a) and (b) are good examples of how to provide the protection and both should be included in the text. 

My suggestion only addressed what should be done before enabling the first access and not anything about how a ULP coordinates successive modifications and accesses of the same memory for a session so I don't understand your objection.

Pat

-----Original Message-----
From: Caitlin Bestler [mailto:[email-masked]]
Sent: Wednesday, June 25, 2003 4:10 PM
To: [email-masked]; [email-masked]
Subject: RE: [rddp] Re: security-draft : Stale Data

On Wednesday, June 25, 2003, [email-masked] wrote:

> If it is advertised once and updated multiple times, then the
> ULP can meet the requirement by ensuring that data for the
> first Read has been put into the buffer (e.g. any stale data
> from another session) before it enables remote read access.
> Even if this involves extra operations to separately enable
> remote read access, this may be less of a burden then zeroing
> out the memory.

How an application chooses to prepare a buffer that it has
enabled for read is a ULP issue. The tradeoffs between enabling/
disabling in the ULP versus doing so with the local interface
are really out of scope.

But it is not a *security* issue.

Obviously a ULP should ensure that a buffer is not read before
the contents are actually there. But if the wrong contents are
read that is a program error. It is no more a "security" issue
than any program error is. The section in question was dealing
with ensuring that the remote peer not gain access to unitialized
bytes that might contain data that was not supposed to be known
to them. If in fact the only risk is that the remote peer might
read *old* data that was *previously* offered to them, then
there really is no security issue.

My position is that ULP developers are looking for advice that
is specific to RDMA, not general tips on robust programming.
Initializing the buffer *before* it is enabled the *first*
time accomplishes this. There is no *security* reason why
it cannot remain enabled from that point forward even if
its contents are logically void. Just because one component
in a distributed system MUST NOT do X does not mean that
the system MUST, or even SHOULD, be actively configured
to detect/prevent it from doing so. This is especially
true if a violation put no other sessions at any risk.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 25 Jun 2003 18:51:48 -0500

>Caitlin,
<<snip>>
>
>My suggestion only addressed what should be done before enabling the 
>first access and not anything about how a ULP coordinates successive 
>modifications and accesses of the same memory for a session so I don't 
>understand your objection.
>
>Pat
>
OK, in the context of the original text I read your statement to
imply that DDP-level enabling should be done *each* time that the
buffer was advertised. As we both agree, this is not necessary.
Rereading your comment, I agree that it is not implied in your
answer, just in the originl draft text.