RDMA MIB?

 

From Mike Krause's comments on the security draft:

 

> (24) 7.5.3 It is not clear to me that a RDMA MIB is required.  One can

> understand whether a LLP or a physical interface are making forward

> progress through the existing MIBs.  Providing additional statistics
isn't

> really of value as one knows the connections / streams and layer 2 are

> making forward progress.  After that, one checks to see if the ULP is

> making forward progress and therefore we have a complete picture
without

> requiring yet another MIB to implement / manage.

> 

 

 

Anyone else have comments?  Here's what's currently in the security
draft. I can rewrite it if appropriate. One possibility would be to add
an additional example of monitoring the existing transport stream with
the enhanced MIBs that allow monitoring a specific flow. Traditional
MIBs don't enable monitoring of a specific flow though, so would not
necessarily give insight into resource starvation.

 

 


1.1.1         Resource Consumption by Idle Applications


The simplest form of a DOS attack given a fixed amount of resources is
for the Remote Peer to create a RDMAP Stream to a Local Peer, request
dedicated resources then do no actual work. This allows the Remote Peer
to be very light weight (i.e. only negotiate resources, but do no data
transfer) and consumes a disproportionate amount of resources in the
server.

A general countermeasure for this style of attack is to monitor active
RDMAP Streams and if resources are getting low, reap the resources from
RDMAP Streams that are not transferring data and possibly terminate the
connection. This needs to be under administrative control, and
demonstrates the need for a MIB for RDMAP so this condition can be
detected and acted upon.