RE: IPsec and RDDP as a transport

[email protected] said:
>> If one shot STags would have been an acceptable solution,
>> why wouldn't making one shot STags a "MUST implement"
>> be adequate?
>
> Because that would allow long-lived STags without requiring
> the countermeasures for the security exposures they create.
>

An existing TCP or SCTP application is not required to
use IPsec, even if it is present.

If a "MUST Implement IPsec" requirement is added to RDDP,
the application would still be free not to use it.

Applications that choose not to use security counter-measures
will be free to do so independently of whether you force
IPsec circuitry onto RNICs. Therefore it cannot see how
it can be cited as a justification for such a mandate.

This sounds like very much like "IPsec should be a requirement,
but we don't have an excuse to force that, so we'll just
require it on every new protocol wihthout exception."

If one-shot STags are availabe as a "MUST Implement"
feature then there is *no* additional vulnerability
created by use of RDDP. All exposed buffers are exposed
by action of the ULP itself. If one-shot STags are always
available, and perhaps even made the default, then there
is no inadvertant exposure of ULP memory. That leaves
only the same application layer security issues that
any TCP or SCTP application running over plain IP
would face.

Whether or not you believe such applications should
run over plain IP is irrelevant, the simple fact is
that this is a legitimate deployment decision.

Unlike the storage specialized protocols, RDDP as a
solution will be in direct competition with non-RDDP
applications using TCP and SCTP. Placing a requirement
on RDDP deployments that is *not* placed on non-RDDP
deployments can *only* be justified to the extent
that RDDP has created a security vulnerability that
would not be faced by the equivalent TCP/SCTP application.

Even without enhancing the local interface requirements
that is essentially already true. The local ULP has full
control over the exposure of its local buffers. If it
only examines those buffers *after* the permission has
expired, or when it has other reasons to believe that
the connection has not been compromised, then there is
*no* additional security vulnerability.

I do not believe you have disputed the above assertion,
only that with the existing requirements for the local
interface (and existing local interfaces) it is easy for
an application designer to lose track of what buffers they
have left exposed.

That limited  concern can be addressed by a handful of
requirements on the local interface. In what way has any
more radical solution been justified?

--
Caitlin Bestler
http://asomi.com/