RE: IPsec and RDDP as a transport

Barron, Dwight said:
> Caitlin wrote:
>> > Or more generally, a buffer that the application intends to use is
>> > still exposed to update from non-authenticated DDP packets.
>>
> David Black responded:
>> The latter is the better statement of the vulnerability, as
>> it includes man-in-the-middle traffic injection, e.g., via a
>> connection hijack.
>
> Is there a distinction between defined ULP's (e.g. NFS, iSER, SDP, MPI)
> and ad-hoc applications in determining responsibility of implementing
> protocol behaviors that do not leave themselves vulnerable? I believe it
> is quite innoccuous and appropriate to require that IETF (or other)
> ULPs be designed in a matter that does not notify ULP consumers of
> available data while an Stag is still mapped to that data. Both remote
> and local Stag invalidations are envisioned to be very
> lightweight operations. I also believe that the vast majority of data
> movement and usage of DDP will occur through these and other
> defined ULPs.
>

The difference between NFS/iSER/SDP/DAFS/MPI/etc and a specialty
application is intuitively obvious, but I'm not sure how you would
phrase it in a draft.

For one thing, the RDMAP/DDP local interface has no way to validate
that the Consumer calling it is an implementation of a protocol that
supplies its own IETF-compliant security procedures beyond putting
a comment in the header file saying "don't use this routine unless..."

So ultimately I think this an example of why we should be concentrating
on *enabling* the ULP to protect its own buffers rather than *preventing*
the ULP from doing things, and then making sure that a decision *not*
to use these tools is based on a true lack of need (I'm solving it myself)
rather than lack of understanding or laziness ("oh, I was supposed to
invalidate the STag? Why bother, I'll be exiting after two more iterations
anyway.")