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

From: "H.K. Jerry Chu" <[email-masked]>
Date: Tue, 30 Jul 2002 18:27:37 -0700 (PDT)

>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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 31 Jul 2002 14:47:54 -0500

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

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

If RDDP is carried over a secure transport then the density
of STags is not relevant. Authentication is provided by the
transport itself.

If RDDP is not carried over a secure transport the size of
the STag is almost irrelevant because it is easily observed,
and almost always used multiple times. It is just as easy to
observe 64 bits, or even 256 bits, as 32 bits.

Providing a valid hamming distance is desirable to minimize
the risk of unintentional collisions.  But, I believe that
32 bits is more than adequate for that purpose.

The local interface can enhance that even more in two ways,
both of which are fully compatible with everything defined
about STags to date:

-- define STags only for the connections on which they are
   valid. 2**32 is an exteremely large number of STags for
   any single session.
   
-- Define an S-Key like sequence such that a difference STag
   must be computed for each put based upon a shared secret,
   but no single STag is used more than once. (Hey, we never
   said that ULP conveyance of the STag had to be *simple*).

I do not believe the added benefit of a larger STag
justifies introducing a different size than is used for
InfiniBand.

The first option can be translated to an IB like "verbs"
layer as allowing creation of "R-Protection Domains", i.e.
low cost Protection Domains that are different only for
checking remote connections. They access the same memory.
Essentially the same relationship as between R-Key and
L-Key.