RE: PS & Arch drafts: status and security issues

> >>> I'm not sure this is true -- the question quoted in David's
> >>> original message was (in effect) whether an attacker could sneak
> >>> bytes past a packet authentication stage in a way that would not
> >>> be possible if RDMA were not used.  Whether or not the application
> >>> *should* look at such bytes is not the issue; the problem arises
> >>> when the application can be tricked into looking at them.
> >>
> >> A given byte in user memory space is either exposed for read
> >> and/or write or it is not. The ULP validity of the packet
> >> that takes advantage of that enabled access is irrelevant.
> >>
> >> Developing packet steering logic for each ULP creates *more*
> >> of a vulnerability because there are more algorithms that can
> >> be fooled.
> >
> > Unfortunately, that's not the comparison that the AD who wrote the
> > original comment is concerned with.  The comparison of interest
> > is whether RDDP introduces additional security issues by comparison
> > to a protocol stack that does no direct placement.  Jeff's outlined
> > a scenario in which a corrupted buffer that the ULP would not
> > ordinarily look at could be used as part of an attack on the ULP.
> >
> > The first-order response to this threat should be a
> > recommendation to use IPsec and run the packet authentication/
> > integrity check *before* placement when this threat is a concern.
> > The "*before*" is a good idea anyhow, as the IPsec check also covers
> > the placement data.  Beyond this, Jeff's suggestion to overwrite
> > placed data that has failed this sort of check seems reasonable,
> > and the possible need to do that overwrite can be added to the
> > discussion we already need on why TLS and in-order security
> > mechanisms like may not be good fits to RDDP.
> >
> 
> DDP works on packets presented to it by the LLP. They can be
> presented out-of-order, but they have to have passed LLP
> validation.
> 
> So LLP or lower security/authentication is transparent to DDP.
> Admittedly serial methods aren't likely to present packets to
> DDP out-of-order. If they are using host memory for their own
> packet processing then the benefits of RDMA will be minimized.
> But many "before" packet authentication/integrity checks can
> essentially be performed as though they were in the network
> rather than on the host itself.

That looks like violent agreement - the best thing to do if injection
of invalid traffic is a concern is to arrange the security functionality
so that invalid data is rejected prior to placement.

> Voiding invalid data post RDMAP/DDP is exactly that, a post
> RDMAP/DDP step. But ultimately it is the same issue for any
> application that applies application layer security/authentication
> above the transport layer.

There's one very important difference.  In error cases, RDMAP/DDP
will place data in buffers that are never successfully received
for ULP processing, including application security/authentication;
a vanilla (e.g., sockets) interface does not do that - in the error
case, the unreceived data is in unpredictable system buffers that
the system cleans up as a routine matter.  RDMAP/DDP has
more junk that may have to be cleaned up in error cases, and this
will need to be noted as a potential security concern.

> But the bottom line is that incorrect STags, MOs or TOs do NOT
> pose a security problem -- whether they result from packet
> injection, undetected packet corruption, a peer software
> bug or a peer with less than honorable intent.
> 
> All local memory access is enabled by the ULP using the local
> interface. The STag/TO, MSN/MO can only select bytes within
> the enabled local memory.
> 
> Ease of packet injection is determined by the LLP, and is not
> affected by RDMA. The ability of a peer to supply payload that
> is not what was expected also exists with or without RDMA.
> 
> The ULP must adjust to the fact that is not bothered with
> the details. It does not know which bytes of the advertised
> buffer were written in what order, but this is not a security
> problem if the buffer is being used properly.
> 
> The ULP can decide to trust its peer, and simplify its use
> of the local interface resulting is some excess exposure of
> its buffers. But they are user buffers, the negative impact
> of their abuse can easily be evaluated on an application
> specific basis.
> 
> So an application that is perfectly capable of treating
> a void buffer as a void buffer should not have to pay the
> overhead of having their iWarp provider zeroing out voided
> buffers.

In other words, it's a ULP by ULP decision, and the possible
security consequences of deciding whether or not to void out the
buffers in the error cases needs to be discussed in the security
considerations section.  I never said that this voiding out
would need to be mandatory - it should suffice to have a solid
discussion of the security exposure here (and there is a security
exposure based on the fact that placement can occur without the
ULP being told about it in error cases), and ways to deal with it,
with voiding out of placed but unreceived data as a possible means
of doing so.

OTOH, announcing that this does "NOT pose a security problem"
is an invitation to a lengthy discussion with the Security
ADs, who happen to be correct that there is a potential security
issue here that needs attention in the security considerations
section of the architecture draft (and also in the security draft).

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email protected]        Mobile: +1 (978) 394-7754
----------------------------------------------------