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

From: "H.K. Jerry Chu" <[email-masked]>
Date: Mon, 29 Jul 2002 20:11:11 -0700 (PDT)

>>>>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
>>putting too much risk and burden on the users of RDDP to
>>"do the right thing". A better approach might be to define
>>explicitly the scope of each STag and convey that as well
>>as the STag to the other side. The scope can be a single
>>RDMA transaction, or higher (such as a SCTP/TCP session).
>>Implementations must invalide a STag when the transport
>>state machine runs beyond the scope of the STag. This
>>approach may further complicate the RDMA protocol, but
>>seems to provide much more flexibility to ULPs.
>>
>
>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.)

>
>Further, by keeping it a pure ULP issue, we preserve the
>right of the Data Sink to tell the Data Source that the STag
>is  only valid for a transaction, but then to be lazy about
>deregistering it.
>
>How can it enhance security to require the Data Sink to
>publish the exact scope of its exposure? Suppose the Data
>Sink's NIC has a limited number of available STags, and
>therefore it must use a single STag for multiple buffer
>advertisements? Of what benefit is it to inform the Data
>Source?

No benefit. Defining the scope explicitly is more for the local
implementation to comply with. E.g. the local implementation
MUST enforce the EXACT scope.

I guess my (and a number of others') concern is to minimize
security exposure, which is stated as one of the goals in the
WG charter. How that goal can be achieved is up for debate.

>
>IMHO, this is akin to posting "Speed Limit 55", and then
>adding a sign stating "No officers available after 6:00 PM,
>please be extra vigilant in monitoring your own speed."
>
>
>
>Whether the same STag is used for other buffers, or even on
>different connections, is not relevant to the Data Source.
>The Data Source must be informed of what *it* is being given
>permission to do with the STag -- but that is a ULP issue.
>DAFS, for example, delivers buffer advertisements in
>requests that are only valid until the reply is sent.
>
>All of this can be handled strictly with local interfaces.
>We can suggest local interfaces, but definitely should not
>mandate them. InfiniBand, for example, only defines verbs
>for those Channel Adapters that choose to classify
>themselves as Host Channel Adapters. There is no attempt to
>specificy the local interface for specialized executatiaon
>environments such as embedded devices (they are Target
>Channel Adapters, or TCAs). Any processing environment that
>finds the resource models for HCAs can simply declare itself
>to have a TCA instead. Any RDDP local interface needs a
>similar escape clause.

Ok.

Jerry

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

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 29 Jul 2002 23:03:58 -0500

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

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

The Data Source ULP *can* know when it is done using an
STag, but there is no need for it to convey this information
any time earlier than its sending the reply to an untagged
buffer, After all, as far as the Data Sink ULP is concerned,
the advertised buffer is indeterminant until it receives
notification of the reply message.

The concern here is not truly security, but completeness.
The buffer is exposed for a long period of time. The period
that an automatic release would close is statistically
insignificant.

The valid concern is that notification is supposed to mean
that prior RDDP puts have completed. To maximize the meaning
of that, it would be theoretically desirable to know that
the buffer could be closed at the same time as the
notification.

The notification says all writes have been placed, automatic
STag release would add *and no others*. (Assuming of course
that the STag was the only reference to the target memory).

That goal can be accomplished strictly with a local
interface. The problem going beyound a MAY/SHOULD
description of the local interface is that it is next to
impossible to describe an STag's meaning *locally* without
making fundamental presumptions about the local hosts memory
addressing.