RE: Security draft issue (4) - IPsec

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