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

From: "Culley, Paul" <[email-masked]>
Date: Wed, 31 Jul 2002 08:31:01 -0500

I suspect that many folks are expecting STags to have a NIC wide scope, that is, any connection on the NIC can use any STag.  That definitely opens up guessing attacks.  While likely implementations MAY do that, a much better choice will be to limit the STag scope to an individual connection.

If connection scope is chosen, then an attacker must both "hijack the TCP connection" and guess the correct STag.  This is where careful use of IPSEC can help; it can make it nearly impossible to hijack the connection.

For an example of how the STag scope might be made variable, see VIA Ptags, or InfiniBand Protection Domains.  Note that I don't believe that these mechanisms belong in a wire level specification; but it might be instructive to provide a pointer to, or include a "verbs" level description of these in the security sections of the RDDP document.

Paul Culley
HP Sr. Fellow
281-514-5543

-----Original Message-----
From: H.K. Jerry Chu [mailto:[email-masked]]
Sent: Tuesday, July 30, 2002 8:28 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rddp] comments on draft-black-rdma-concerns-00.txt 

>It is NICE if the STag deregistration can be automatically
>applied at the earliest possible moment. But it does not
>close any security holes. The buffers are exposed until the
>trailing SEND *and* the deregisration have completed.
>Consolidating those two completions is a *local*
>optimization, it has no interoperabilty implications.
>
>It is A REALLY GOOD IDEA to use STags exactly once, and it
>is also A REALLY GOOD IDEA to deregister them as prompty as
>possible. It is also A REALLY GOOD IDEA to have the fastest
>processor possible and a few spare GB of DDRAM for your host
>processor. Redundant power supplies are nice too.
>
>The point is that how many STags are available, how quickly
>they must be reused and how efficiently they can be reused
>are all economic tradeoffs. The market should be allowed to
>determine those answers, not the IETF.

It seems that the last defense here is a good selection of STags
to export. 32 bit STag seems too small for security purpose. In
the least one should analyze the implication on security and
recommend some algorithm for selecting STags that is better against
spoofing. E.g. a simple tag index into a page table will not be
random at all and be trivial to spoof. (But a randomized STag may
be hard to implement on NICs efficiently.) This is similar to
hijacking a TCP connection except that the latter still seems much
hard. One must guess the correct seq# and port # at the right time
and also manage to shut out the other end of the TCP connection...
But here once a valid STag is guessed no other protection is there.
On a busy system the working set of transient network buffers could
be in many megabyte range making the probability of guessing a valid
32 bit STag >> 0. Even with IPsec, a malicious user on an
authenticated system or a buggy application may stomp on some
random place in remote memory causing data corruption that will be
impossible to debug.

Rgds,

Jerry

>
>
>
>
>
>
>Caitlin Bestler
>http://www.asomi.com/CaitlinBestler.html

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

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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 31 Jul 2002 10:41:31 -0500

On 7/31/02, Culley, Paul wrote:

>I suspect that many folks are expecting STags to have a
>NIC wide scope, that is, any connection on the NIC can use
>any STag.  That definitely opens up guessing attacks.
>While likely implementations MAY do that, a much better
>choice will be to limit the STag scope to an individual
>connection.
>

The local interface SHOULD allow the ULP to control which
connections an STag will be valid on.

With my application developer hat on, I would like to make
that a MUST. As a NIC developer I would strongly resist
anything more complex than InfiniBand Protection Domains.

This needs to be combined with:

    Any use of an STag on a connection other than the one
    on which it was delivered MUST be explicitly authorized
    by the Upper Layer Protocol.
    
In other words, you cannot assume the STag is valid anywhere
other than the obvious connection except as agreed upon in
advance in a ULP specific fashion.

An STag being valid on exactly one connection is an
excellent default. However, in terms of requirements, it is
important to recognize that there are some major exceptions:

- An STag may be delivered on a primary connection and then
used on an auxiliary connection. DAFS supplies buffer
advertisements on the primary connection to be used on the
RDMA Read channel. While it is possible to plan the STag
reference for the connection it will be used upon, it would
be very error prone to do so.

-- An client connected to each member of a server cluster
may deliver a request with an STag to one member of the
server cluster, which could then pass the work to the
cluster member most capable of fulfillnig the request.

>
>For an example of how the STag scope might be made
>variable, see VIA Ptags, or InfiniBand Protection Domains.
> Note that I don't believe that these mechanisms belong in
>a wire level specification; but it might be instructive to
>provide a pointer to, or include a "verbs" level
>description of these in the security sections of the RDDP
>document.
>

Protection Domains are a very flexible tool, which is why
the DAT Collaborative basically adopted that model for its
model of transport independent RDMA.

A Protection Domain can be NIC wide, one connection or
anythign in-between.

One thing missing from the InfiniBand model is the ability
to create an STag that is valid across multiple NICs. This
can be easily addressed by adding the following:

    The local interface SHOULD allow the ULP to request
    a specific STag value.
    
The ULP would still have to map each NIC to the same memory,
but that is strictly a local interface.

Caitlin Bestler

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 31 Jul 2002 11:18:27 -0500

>    by the Upper Layer Protocol.

Very shortly after hitting 'send' a more concise wording hit
me over the head:

    An exported STag has ONLY the meaning conveyed by its
    exporter. There are no valid presumptions about the
    scope or duration of its validity beyond those supplied
    through the ULP used to convey the STag.