RDDP Security - misc comments 17-29

This is the second email in a multi-email series to answer the lengthy
review that Michael Krause did on the security draft. The questions here
are questions 17-29, except those that bring up document organizational
questions. Those will be in a separate email.

 

 

> (17) 7.2  My reaction was "so".  Not clear why this section is there
given

> the limited information provided.

> 

 

It is actually critical - the whole point is to identify that an entire
class of attacks can essentially not be done against RDMAP - thus we
don't need to include them in this security draft.

 

> (18) 7.2.1 Need to think about this more but it seems there could be
nasty

> middle-box attacks which are outside the scope of RDMA and DDP.  It
would

> also be good to separate authentication from integrity protection as
the

> two provide different protections and the associated protections
should be

> clearly attributed to each if you are going to list out the various

> attacks.

> 

 

Thanks. I had a typo where I incorrectly in one sentence stated
"authentication" when it should have been "integrity protection".  The
sentence now reads: "If integrity protection is not used, then a
man-in-the-middle attack can occur, enabling spoofing, and tampering."

 

> (20) 7.2.2. STag of zero is a local, not remote value and thus should
not

> be part of the allocation algorithm.

> 

I changed the example to one. I'd prefer not to bring verbs semantics
into this document.

                                                        

> (21) 7.3.2 This may be a bit of implementation but it may be possible
that

> a RNIC could have multiple execution paths such that the invalidate

> executes in parallel or serial to other operations thus a subsequent
RDMA

> operation could access memory prior to the invalidate being

> completed.  Same applies if the invalidate or access rights changes
are

> implemented in software which is asynchronous the subsequent hardware

> packet processing operations.  This might lead to a race condition and

> thus

> exposure.

> 

> One question: What if the remote stated it would invalidate but does
not

> do

> so?  It is clear that remote peers should not be trusted but one may

> appear

> to be fully compliant with the ULP needs and then simply not
invalidate

> thus enabling the memory to be read / updated.  This can be dealt with
via

> the implementation - a couple of simple techniques come to mind - but
it

> may need to be discussed a bit further.

> 

 

I don't understand the comment. The text specifically addresses what
should happen if the remote peer doesn't invalidate? Specifically:

 

"...or by checking to make sure the Remote Peer Invalidated the STag
through the RDMAP Invalidate capability, and if it did not, the Local
Peer then explicitly revokes the STag remote access rights." 

 

Does this not answer the above question?

 

> (22) 7.4.2 Zeroing of a data buffer or providing valid data with all

> non-used buffer memory being invalidated / zero should be noted.

> 

 

The text specifically states:

 

Because of this, it is RECOMMENDED that the Local Peer ensure that no
stale data is contained in the buffer when remote read access rights are
initially granted (this can be done by zeroing the contents of the
memory, for example). 

Are you reviewing an old version of the spec? This is from the
draft-ietf-rddp-security-00.

 

> (23) 7.5.2.2 Note that this is only for a shared CQ in the header
though

> the subsequent header does make this more specific.

> 

 

Good catch. I've updated the introduction to be shared completion queue
specific.

 

> (25) Not sure if I agree with the note in 7.5.3 that indicates that
there

> isn't risk for some resources.  For example, a ULP may negotiate use
of

> large receive buffers and potentially large number of receive buffers
and

> then not make forward progress.  These types of consumptions are
problems

> for both local and remote attacks.

> 

 

I added your example to the spec.

 

"This could also be caused by ULP negotiation with the Remote Peer,
which causes the Local Peer to consume resources which are never
consumed by the Remote Peer. "

 

> (26) 7.5.4 One could also see an attack where one purposely transmits
out

> of order packets or delays the  packet retransmission quite often.
This

> could force some implementations to take the slow path quite often
thus

> causing a performance degradation attack.  This is an

> implementation-specific problem that is also applicable to non-RDMA

> network

> stacks so it isn't necessarily new but might be beneficial to note.

> 

 

The problem with this is that you can use the exact description above to
describe a normal application (ignoring the out-of-order packets since
that is a TCP thing, not RDMA/DDP thing). To me the above example is
more like what I was trying to describe in the previous section -
"Resource Consumption by Idle Applications". You don't necessarily not
use them at all - just use them extremely slowly. In any case, it's
unclear to me that any new text is needed?

 

> (27) 7.5.5 The last sentence says that the remote peer just can't use
the

> STag but it can also cause a connection to be shut down on error thus

> while

> true, there is another potential consequence.

> 

 

To me this isn't a security issue - if a malicious application can cause
his own connection to be torn down by sending bad STags, there are no
security holes.

 

> (28) 7.5.6 Should note the high and low-water marks per connection
sharing

> a receive queue to detect and allow corrective action to take place.

> 

 

Will do.

 

 

> (29) 7.6 Not sure if this applies but if the system supports dynamic

> patching of a subsystem, then one might replace the executable with a

> trojan horse thus enabling one to take over the system / resources.
Might

> be worthwhile to have a note that such patching solutions should have
all

> RDMA / DDP resources released so that the LLP establishment process is

> required thereby providing some level of new authentication to occur
to

> the

> previous remote peers.

> 

This seems extremely OS specific to me. It's a slipperly slope to start
talking about all the local OS specific issues. In general, when you
tear out a dynamicly linked library you have to make sure all resources
allocated by the library have been freed first. 

 

 

 

 

Jim