Re: IPsec and RDDP as a transport

On May 29, 2004, at 1:02 AM, [email protected] wrote:
>>
>
> In essence, if the RDDP protocols can reasonably be used in
> situations that create security exposures (e.g., on the public
> Internet), then the IESG requires that countermeasures to those
> exposures be "MUST implement".  At the London IETF in 2001, an
> attempt was made in the IESG plenary to remove a similar "MUST
> implement" requirement for IPsec for one of the IP Storage protocols
> on roughly the above basis (if you want IPsec, use an external
> IPsec gateway, but don't make it a protocol requirement).  The
> IESG shot this attempt down in flames.  Unless one is a glutton
> for punishment, I don't recommend repeating this experiment.
>
>

There is an important difference between RDDP and iSCSI.
iSCSI was introducing new traffic to the network, it effectively
replaces a *local* SCSI connection (or a simulation of one
over another *non-public* non-IP network).

Therefore *any* security vulnerability is new.

RDDP is providing a new method of exchanging data between
applications. The very same data exchanges could have been
performed using the LLP directly. The fact that doing so would
have been less efficient does not, in my opinion, make them
more secure. And if we accept that logic, then a 10 GigE
port is obviously in need of encrypted Ethernet packets
because it is far more vulnerable than a simple GigE port.

The only additional exposure created by RDDP is that an
application *might* not be fully aware of what memory
exposure it has enabled -- something that is true of any
form of middleware anyway (Is Java RMI required to use
IPsec?).

I personally believe that clearly detailing these issues in
the Securities draft is adequate. But even if that is not
acceptable to the IESG, there are far less severe restrictions
that can be imposed on the local interface to ensure that
applications do not enable STags for multiple messages
inadvertently.

I believe there is consensus that there is no additional
vulnerability to an application that is fully aware of what
memory it has exposed to remote access. In that case the
proper minimal response is to propose local interface
requirements that match that goal.

It would be something along the lines of:

    The local interface MUST provide a capability where
    the ULP can specify that completion of a given Receive
    operation MUST NOT be reported back to the ULP
    until after the ULP specified STag has been invalidated
    and there can be no further remote access to ULP
    memory enabled by that STag until the ULP has
    explicitly re-enabled it.





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