The Architecture of Direct Data Placement (DDP) and Remote Direct Memory Access (RDMA) on Internet Protocols
draft-ietf-rddp-arch-07

[Ballot comment]
I did not find this document clear at all.  I was unable to easily
tell whether Steve Bellovin's discuss text had been addressed because
I found the document too confusing.  I suspect that at some technical
level the text has been address in that you could find changes in the
document and understand how they address Steve's comments.  However
I'm not convinced that anyone who read the document without Steve's
comments would be aware of the issues.

[Ballot discuss]
I believe that the authors added the following text:

  A registered buffer is identified within DDP by its stag_t, which
    in turn is associated with a socket.  This registration therefore
    grants a capability to the DDP peer, and the socket (using the
    underlying properties of its chosen transport and possible
    security) identifies the peer and authenticates the stag_t.

to handle the discuss comment below.  In the context of multidestination
data delivery or SCTP-style semantics, I'm not sure how this handles
the question.  I recognize that this is just the architecture document
and that actual protocol documents will get this right, but I remain
concerned that failure to handle the "what is a peer" question right
will make this work very difficult.


Original text:

It's always a bit hard to read an architecture document without the full
protocol description, as you don't have the luxury of seeing what the
bits on the wire would look like.  I think that's biting me here, as it
is not really clear to me at what layer they intend peers to be identified.
The document describes the buffer as the central component of the
architecture; reading the description of buffer, we see:


          typedef struct {
            const address_t start;
            const address_t end;
            void            set(address_t a, data_t v);
          } ddp_buffer_t;


    address_t

          a reference to local memory

    data_t

          an octet data value.

So the buffer, as expected, is only interpretable
in the local context and its identifier is , in fact, defined to
be opaque.  So no one could derive a peer identifier
from stag_t.  Yet the whole point of this is to go from
buffer @peer1 to buffer' @ peer2.  Is the peer identifier
meant to be derived from the transport layer (and, if so,
what do we do with multidestination transports)?  Or is
the peer identifier derived from a layer above DDP/RDMA
(and, if so, are there particular constraints that are placed
on that identifier, e.g. that both peer1 and peer3 would
use the same identifier for peer2)?

Any clue on this would be gratefully received....

[Ballot comment]
The use of TLS (as discussed briefly in the security considerations) or
  any other protocol that provides authentication will not fit well into
  the proposed architecture.  The integrity check cannot be performed until
  the entire packet (or record in the case of TLS) is available in memory.
  So, the data must be copied from the I/O interface to memory, which may
  involve some reassembly, before the integrity check can be performed.
  This issue should be discussed in the security considerations.

[Ballot discuss]
I"m not convinced the security considerations is adequate.

I see several threat issues.  The first is the tension between direct copy and packet authentication.  In many cases, it is not possible to authenticate a packet until the entire thing has been read.  But here, the data is being copied to a receiving buffer directly from the wire, before authentication takes place.  This is especially a challenge to a multi-threaded interface --- ATM where the cells for some packet are not consecutive, perhaps -- where you might get interleaving.

More generally, authorization for access to storage has to be dependent on the connection as well as the steering tag.  Otherwise, you introduce new vulnerabilities.  This is especially problematic given that receive buffers may (according to the document) be used for data from a different socket.

Aside: I think that many of these issues, as well as the multiple receiver problem (and I do not accept the argument that requiring many different clients to use the same address is in any way comparable to any existing problem in that space), would go away if the steering tag sent over the wire to the receiver were not just opaque, but by intent a random 64- or 128-bit tag to a local buffer descriptor.  That permits easy local revocation of capabilities, as well as a defense against remote contamination attempts if the value were communicated previously over an encrypted channel.

[Ballot discuss]
It's always a bit hard to read an architecture document without the full
protocol description, as you don't have the luxury of seeing what the
bits on the wire would look like.  I think that's biting me here, as it
is not really clear to me at what layer they intend peers to be identified.
The document describes the buffer as the central component of the
architecture; reading the description of buffer, we see:


          typedef struct {
            const address_t start;
            const address_t end;
            void            set(address_t a, data_t v);
          } ddp_buffer_t;


    address_t

          a reference to local memory

    data_t

          an octet data value.

So the buffer, as expected, is only interpretable
in the local context and its identifier is , in fact, defined to
be opaque.  So no one could derive a peer identifier
from stag_t.  Yet the whole point of this is to go from
buffer @peer1 to buffer' @ peer2.  Is the peer identifier
meant to be derived from the transport layer (and, if so,
what do we do with multidestination transports)?  Or is
the peer identifier derived from a layer above DDP/RDMA
(and, if so, are there particular constraints that are placed
on that identifier, e.g. that both peer1 and peer3 would
use the same identifier for peer2)?

Any clue on this would be gratefully received....