RE: Security draft issue (4) - IPsec

[email protected] said:
> Caitlin,
>
> Could you explain a couple of things:
>
>> Nothing, except that the intermediate system buffering is
>> far less likely. That *improves* security, not worsens it.
>
> How does this improve security?  What is(are) the threat(s) whose
> risk is reduced by eliminating intermediate buffering?
>

Getting a code snippet into a user mode data buffer almost
never does an attacker any good.

>> What has not changed is that no matter what is in the network
>> packet, the exposure of application buffers to those packets
>> is under control of the application -- not of the network
>> packet.
>>
>> How precisely the application control the exposure of its
>> buffer space, relative to its security requirements, is the
>> real issue. The vulnerability of network packets is not
>> an RDDP specific issue.
>>
>> If the application has tailored its exposure, the attacker
>> can modify the headers endlessly. They will still only be
>> able to deposit the payload in the buffers the Data Sink
>> ULP intended them to be deposited into.
>
> What are the implications of that "If"?  What does an application
> have to do to match the buffer exposure of TCP or SCTP via the
> sockets interface?  Under what circumstances is that reasonable
> (e.g., what other usage patterns does RDDP intend to enable)?
> What are the potential consequences of allowing more buffer
> exposure?
>
There is no need to achieve an exact match for TCP or SCTP
placement.

What matters is that when the application is ready to respond
to a single "exchange" from its peer (consisting of zero or
more RDMA transfers and a single untagged message) it
merely has to ensure that it has ended remote accessiblity
of the associated buffers.

One-shot STags, whether invalidated remotely or locally,
fully achieve this goal -- independently of whether
transport layer authentication services are in use.

Once STag invalidation is confirmed, and before the target
buffers have been acted upon, the ULP has just as much
confidence in the contents of those buffers as if they
had been delivered by TCP or SCTP alone using the
classic sockets interface.

The only difference is that there were probably fewer
intermediate application states. From the application's
viewpoint the data went from "not there" to "there"
in a single completion event. It was not aware of when
"100 KB out of 300 KB" had been transferred.

An application may *choose* to leave STags enabled
on a wider basis, if it believes that there is no real
vulnerability from the extended exposure. For example
an application may have determined that an "attack"
on an over-exposed buffer would at worst cause
the current session to be aborted with no false
results being committed to permanent memory.

In my opinion the security draft provides clear and
sufficient advise to application designers to enable
them to tailor their STag exposure to meet their
application specific needs.


Even when an application wishes to have proof that
all packets originated from the machine that its peer
is running on, there are many ways to achieve that.
I do no see any benefit from having the DDP layer
insist on a specific method of solving a transport
layer problem. Those should be solved at the
transport layer.

For example, source authentication can be
achieved at the network layer with a variety
of tools including managed switches in addition
to IPsec. Ideally the application only knows that
IP spoofing has been prevented. It does not need
to know, and should not care, how.

I could see requiring that the DDP layer invoke
any existing interface of the IP layer to request
anti-spoofing services be used, but I do not believe
it is appropriate to require RDDP to insist that the
IP layer it is using support IPsec (or any other
specific anti-spoofing method).

In any event, how would the RDDP layer confirm
that capability? If the application does not request
the sevice, is it obligated to do a test IPsec connection
first just to make sure that it could have? If there
are 10 existing connections before RDDP discovers
that the dastardly IP layer it is using does not really
support IPsec, is is required to terminate the
existing connections?

RDDP implemenations are likely to ride on top of
the LLP, be rototilled with the TCP or SCTP layer
and ride on top of the IP layer, or rototilled thru
the IP layer and ride on top of the Ethernet layer.

Only in the latter case is the RDDP implementation
able to enforce IPsec availability. For the others
to do so, there would have to be a *standard*
interface between RDDP and the next lower layer
that included such a query capability. And if
we are going to spend the efforts definining
the requirements for local interfaces I believe
that the ULP to RDMAP layer is much more
worthwhile.



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