RE: Security draft issue (4) - IPsec

[email protected] said:
> Caitlin,
>
>> >> 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.
>
> That's unfortunately not true.  Buffer overflow exploits usually
> target privileged demons running in user mode (e.g., ftp).
>
>> >> 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.
>
> If that's correct, it would suggest that implementations
> that restrict *all* STags to one-shot usage may not need
> to implement IPsec or anything similar.
>

If one-shot STags are available for use, then it is the
ULP that chooses to use longer lasting STags. That
is the same ULP that would be free to decide not to
use IPsec.

It would make sense to  require IPsec support for
any implementation that did not offer a local interface
support for one-shot STags (for example, one that
supported only heavy-weight Memory Regions as
opposed to Memory Windows).

>> 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.
>
> Or undesirable side effects being inflicted on unrelated
> clients.
>
>> 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.
>
> If proper/intended use of RDDP (STags enabled on a wider
> basis) creates security issues, the IETF view is likely
> to be that the security countermeasures for those issues
> have to be mandatory to implement.  I've recently run
> into a situation with another draft where the IESG viewed
> "don't use this in situations where there's a risk of it
> causing security problems" as insufficient.
>

I have posted before in defense of these application
models and I am clearly on record as wanting these
capabilities supported by the protocol and the local
interface. However, I have also pointed out that typical
applications will only need one-shot STags.

I believe the security draft is clear that STags should
be used such that the exposure is no larger than what
the ULP requires, and that excess exposure should
be examined by the application designer.

Should we go farther and mandate that one-shot
STags be the *default* interface, so that the ULP
could not inadvertently over-expose its memory?

But such a requirement would only apply to the
iWarp-specific local interface. In my estimation,
most applications will be developed using transport
neutral APIs designed to work over iWarp or InfiniBand
(such as the APIs defined by DAT and the ITWG).


>> 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.
>
> The DDP layer would not "insist" - any requirement for
> IPsec would be "MUST implement", not "MUST use".
>
But it would be insisting that the underlying IP
layer MUST have this capability.

Bottom line, should an RDDP implementation
*refuse* to operate over a separately packaged
IP layer because it fails to implement IPsec
(or IPv6 for that matter).


I still see no justification for requiring RDDP to
somehow enforce something that is technically
outside of its scope, especially when the ULP
already has adequate tools to ensure that an
RDDP application over unauthenticated transport
can be just as secure as a TCP or SCTP application
over the same unauthenticated transport.

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