Re: Long-lived Stags: Why?

[email protected] asked:

>
> Would someone remind us why long-lived STag support should be retained
> given the security pain and suffering it's causing (e.g., what is the
> compelling use for this functionality)?  The simplest solution here
> is to take it out, especially if there's no compelling use for it ...
>

In my opinion there is no justification for the most common use
of persistent STags: registering a global heap once, and then simply
using it. It leaves *all* validation of that buffer access is legitimate
to the ULP iteself. As you pointed out, even when there is no chance
of a man-in-the-middle attack, this practice is still highly vulnerable
to bugs.

There are however, numerous uses of STags that have a life cycle that
is not easily understood by the RDDP layer.

Generically, the Data Sink advertises a buffer. The Data Source updates
that buffer, and informs the Data Sink that it has completed doing so
with an untagged message.

In the most common case, which tagged buffer will be completed by
which untagged message is actually fully predictable by the local ULP.
This is where a "local Receive with Invalidate" verb would be the most
useful. The best example of this type of application would be DAFS.

The next case is where the Data Sink advertises a pool of buffers,
but the Data Source is free to choose which buffer to use with each
message. Typically this would involve transfers that vary in size,
and presumably the Data Source is selecting the target buffer based
on how big the requested file/asset/whatever turned out to be.

This is the model that the "Send with Invalidate" message was
designed to support (it also covers the simpler earlier case if
the Data Source is a good citizen and always uses Send with
Invalidate).

The third case would be where the Data Sink advertises a circular
buffer to deal with a variable rate transfer. The primary example
that comes to mind would be a streaming media transfer.
The sustained rate of the transfer, and hence the total buffer
size is quite predictable. But the amount that needs to be
transferred in any tenth of a second can vary considerably.

Further, existing application logic may already be accustomed
to "playing" the received content from a circular buffer, and
merely wants the transport to place the content in the buffer
and inform it of how far it is allowed to play.

The Data Sink cannot pre-designate an STag that matches
the nth untagged message because it does not know its size,
and because it wants it to follw the portion completed by
untagged message n-1.

WIth current verbs, such an application would have little choice
but to leave itself open to MITM attacks. One of my proposed
local interface enhancements would allow the Data Sink ULP
to shrink an STag without invalidating it. That would fully
address this type of application.

Beyond that, theoretically an STag *could* represent any
set of byte storage assets designated by the ULP.

Realistically, we all know that this must be a contiguous
range of bytes within a virtual address space. Some verbs
will essentially allow a virtual address space to be formed
out of physical pages to make a new virtual address space
that would not have otherwise existed, but a cautious ULP
designer would not rely on such a capability being available
(and if it is available, it will typicallly only be available to
highly privileged applications and/or kernel modules).

I believe we can ignore this set of applications, and in
describing the requirements for a secure local interface
simply leave a loop-hole for "those running in the kernel
or with full physical memory access are presumed to know
what they are doing".

I do not believe it is necessary for RDDP to *prevent* applications
from doing stupid things. It should be adequate to provide
adequate tools to enable the application to protect itself,
and to make sure that the application is not encouraged
to avoid these tools in any way. That is, by default, protection
must be enabled.

That said, once you get past the simplest STag life cycle,
I do not believe it is possible for the RDDP layer to detect
the difference between a valid, but complex, STag allocation
plan and a sloppy/lazy "we don't need no security here"
STag allocation plan.

This is much akin to the requirement for ULP flow control
on untagged messages. We can state that a ULP MUST have
it, but there is no way to enforce it at run-time. The only
effect of such statements is to encourage good design, and
perhaps constrain IETF approved ULP drafts to conform.

Also keep in mind, that the lazy/sloppy application that is
recklessly leaving STags open *is* exposing its own memory.

I believe that existing "custodian ULPs" that are exposing the
memory of *their* ULP rather than their own memory have
already specified proper use of non-persistent STags.



--
Caitlin Bestler
http://asomi.com/