Subject: RE: [rddp] Security draft issue (4) - IPsec

From: [email-masked]
Date: Fri, 14 May 2004 08:52:22 -0400

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.

> 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.

> 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".

> 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?

It would not be necessary to confirm this at runtime.
As I said earlier, this is a matter of what the implementer
must do in order to honestly claim that an implementation
meets the requirements of the specification.

Thanks,
--David

> 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/
> 

_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: "Caitlin Bestler" <[email-masked]>
Date: Mon, 17 May 2004 02:11:28 -0500 (CDT)

> 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).

> 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).

> 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/