Subject: [rddp] RDMA MIB?

From: "Jim Pinkerton" <[email-masked]>
Date: Wed, 21 Jan 2004 16:18:16 -0800

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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 21 Jan 2004 23:03:53 -0600

On Jan 21, 2004, at 6:18 PM, Jim Pinkerton wrote:

>  
>
> From Mike Krause’s comments on the security draft:
>
>  
>
> 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.
>
>  

There is a need for *some* method of monitoring forward progress, but I 
agree
with Mike that any applicable existing monitors would solve the problem.
Forward LLP progress is very correlated with forward RDMAP/DDP progress.

However, I don't believe we should imply that LLP statistics SHOULD be
gathered on these connections. In many environments it might be easier
to monitor forward progress at the DDP layer. We should not mandate that
the tracking occur at the lower layer, even though inertia will very
heavily favor doing it there.

The important thing is that we not require implementations to make MIB
tallies at *both* the LLP and iWarp layers.

-- 
Caitlin Bestler - [email-masked] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html

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

---

From: Michael Krause <[email-masked]>
Date: Thu, 22 Jan 2004 05:53:28 -0800

At 11:03 PM 1/21/2004 -0600, Caitlin Bestler wrote:

>> > progress through the existing MIBs.  Providing additional statistics isn't
>>
>> > making forward progress and therefore we have a complete picture without
>>
>>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.
>>
>>
>
>There is a need for *some* method of monitoring forward progress, but I agree

I agree that inertia will favor using the existing methods as many iWARP 
implementations may expose their LLP protocol off-load interface directly 
thus would prefer a single method be provided to track forward 
progress.  My preference though, remains not spending resources on 
developing an iWARP MIB unless someone can demonstrate strong value for 
consumers or that the LLP methods are significantly deficient.  I do not 
believe there is a strong case being driven from a security aspect.

>tallies at *both* the LLP and iWarp layers.

Strongly agree that this would be impractical due to very low cost / value.

Mike